2018年有寫過一篇文章提到IT部門的業(yè)務(wù)和開發(fā)之爭：Who am I瞭空？模软，居于當時的情況我想了一些解決方案躺涝，一年過去了厨钻，今天補上后續(xù)事件的發(fā)展。
上文說到坚嗜，我們公司有一個讓項目中的各個角色“搞不清自己是誰”的關(guān)鍵問題夯膀，其實追根溯源會發(fā)現(xiàn)在招聘的根源上這個問題必然會產(chǎn)生。公司喜歡招BAT苍蔬、華為棍郎、SAP、IBM等大廠出來的解決方案架構(gòu)師和開發(fā)工程師银室，但招進來后往往又沒有對應(yīng)的崗位，于是很多招進來的人不得不學習其他類似甚至不相關(guān)的業(yè)務(wù)或開發(fā)方向。如我蜈敢，是以Android移動端開發(fā)工程師的定位招進公司的辜荠，但進公司到現(xiàn)在過了2年半的時間，我可以“自豪”的說“我從來沒有為公司提交過一句Android代碼”抓狭。
其實就算招進來的人有對口的崗位伯病，但如果整個業(yè)務(wù)流程或開發(fā)流程沒有成套的崗位，那么零散的幾個“有模有樣”的崗位否过，并不一樣能發(fā)揮應(yīng)用的作用午笛，最容易的結(jié)局往往就是東施效顰、畫虎不成反類犬苗桂。
也許成長型的公司必須經(jīng)歷這樣的陣痛药磺。
敏捷其實還不夠
針對成長型的公司，面對快速變化的需求煤伟，大家最容易想到的解決方案往往就是拋棄傳統(tǒng)的瀑布式開發(fā)癌佩，轉(zhuǎn)而擁抱敏捷。我在很多公司（包括大廠）實施過敏捷便锨，敏捷從來都不是隨隨便便就能成功围辙。
用敏捷來解決公司里IT項目開發(fā)，并不能解決問題放案。我們的問題不是需求變化快姚建，而是缺上很多重要環(huán)節(jié)，搞不清自己是什么需求是什么吱殉。很多公司搞敏捷開發(fā)都是從開發(fā)和測試團隊搞起的掸冤，這注定了搞出來的是先天發(fā)育不良的敏捷，大概率結(jié)局是除了有幾個“站會”考婴、“回顧”等會議形式外一切照舊贩虾。
如果我們從開發(fā)的角色不能搞定各方“利益人”參與進來，敏捷無從談起沥阱。我曾經(jīng)讓業(yè)務(wù)在軟件開發(fā)開始階段就參與使用每日迭代發(fā)布的產(chǎn)品缎罢，卻遭到對方的質(zhì)疑：“你沒有經(jīng)過測試驗證過沒有達到交付要求的產(chǎn)品為什么讓我用？”
也許考杉，我實施敏捷的能力和手段太差策精，但現(xiàn)實中沒有足夠的利益代表方支持，敏捷很難名副其實崇棠。開發(fā)這類角色在敏捷過程中真的沒有你想象的那么重要咽袜。
我實踐的兩個解決方案
但總要做一些自己能做且能發(fā)揮一定影響的事情來讓項目的開發(fā)過程和結(jié)果變的更好。我努力的方向是讓溝通更有效枕稀！既然大家之間有明顯的裂痕（gap）询刹，而又無法推動對方去修補好谜嫉，那就用技術(shù)解決些裂痕。而爭吵是我首要解決的問題凹联。
我其實很不喜歡爭吵沐兰，因為我了解語言的特性，大家有各自的過濾器蔽挠，你聽到的不一定是你理解對方要表達的意思住闯，同理對方也很難從話語（哪怕是文字）上聽懂你要表達的意思。很多爭吵完全都不能算是真正的爭吵澳淑，說大家在“各抒己見”比原、“雞同鴨講”更加合適。
我的解決方式就是讓爭吵的東西所見即所得!
第一：項目管理實現(xiàn)業(yè)務(wù)需求和代碼“同步”
既然公司沒有專業(yè)的業(yè)務(wù)和需求分析杠巡，寫出來的需求文檔也不規(guī)范量窘，那就讓他們連需求文檔都不用寫（其實是剝奪了他們的某項權(quán)利，但一定要說成：幫助你生成需求文檔）忽孽。
我們Team自己做了一個項目管理的平臺绑改，和業(yè)務(wù)談需求的時候直接按DDD（領(lǐng)域驅(qū)動開發(fā)）的方式將他們的需求分解成對應(yīng)的問題和規(guī)則描述。然后用Python編寫的腳手架工具將這些問題兄一、業(yè)務(wù)事件等生成模版代碼厘线，而且是可直接部署上線的工程項目代碼。以此彌補業(yè)務(wù)和開發(fā)人員之間的裂痕出革。
而且造壮，當對方需求或問題發(fā)生變化時，我們在這個系統(tǒng)上做修改就好骂束，然后開發(fā)的模版代碼會發(fā)生改變耳璧，業(yè)務(wù)也可以直接獲得這個工具實時生成的需求文檔（doc格式）。最終展箱，通過這個項目管理工具實現(xiàn)了需求和代碼的同步旨枯。
做到這一步有一個重要的前提：你的項目實現(xiàn)了自動化部署和測試驅(qū)動開發(fā)。
為此混驰，我花了很多時間改進公司的項目部署流水線攀隔，并通過引進DDD模式讓業(yè)務(wù)代碼和平臺特性（數(shù)據(jù)庫、網(wǎng)絡(luò)等）分離栖榨，實現(xiàn)管理平臺根據(jù)業(yè)務(wù)需求規(guī)則自動生成單元測試代碼昆汹，由測試驅(qū)動開發(fā)。不要試圖讓沒有做好代碼高內(nèi)聚低耦合的項目開發(fā)人員去寫好單元測試代碼婴栽，那樣的單元測試基本上只有滿足代碼測試覆蓋率的功能满粗。
也不要試圖讓一般的開發(fā)工程師理解代碼分離，直接用模版代碼“強制”隔離愚争，否則累積到后面的意大利面式的代碼能直接讓你崩潰映皆。
第二：開發(fā)和業(yè)務(wù)的共同語言：圖
代碼的維護是一件很讓人頭疼的事情挤聘，而“成長型”的公司肯定喜歡頻繁修改上線后的應(yīng)用，而且“理所當然”的認為修改劫扒、添加個小功能比原來的開發(fā)不要太容易檬洞！但看別人的代碼進行項目維護或二次開發(fā)往往比讓自己重寫一遍還要痛苦萬分。項目是否能成功沟饥，除了按時交付外，是否能有效控制維護成本湾戳、能靈活升級也很重要贤旷。
從業(yè)務(wù)和開發(fā)理解的角度，降低項目的業(yè)務(wù)理解認知負荷都很有必要砾脑。如果能有效的降低業(yè)務(wù)和對應(yīng)的業(yè)務(wù)代碼的認知負荷幼驶，那么代碼的維護和改動也將變得更容易和更可控。
我做的第二件事情韧衣，就是解決認知負荷的問題盅藻。
我的目標是讓新的人員接觸這個項目時，不管是新的業(yè)務(wù)或是新的開發(fā)畅铭、測試人員都能很快就了解這個業(yè)務(wù)的流程和規(guī)則氏淑。我不想讓他們?nèi)プx一遍需求文檔，不想讓他們必須通過需求文檔的文字了解業(yè)務(wù)規(guī)則硕噩。
回到我前面說的“讓爭吵的東西所見即所得”假残，我的第二個技術(shù)彌補裂痕的方式就是讓業(yè)務(wù)規(guī)則實時化、圖形化炉擅！
只讓人看到最終的結(jié)果辉懒，只按某個最終的結(jié)果來討論和理解業(yè)務(wù)都是很片面的。很難對業(yè)務(wù)有全局的理解谍失，最容易的就是維護時顧此失彼眶俩，改一個BUG產(chǎn)生一兩個新的的BUG，BUG永遠生生不息快鱼。所以颠印，我們的理解的過程應(yīng)該是可以交互的，不同的輸入應(yīng)該要向我們展示不同的業(yè)務(wù)流程分支攒巍，并要把邊界異常標明清楚嗽仪。
如下圖，一個實際中生成項目預測的業(yè)務(wù)流程柒莉，界面除了展示最終的結(jié)果數(shù)據(jù)闻坚，還根據(jù)不同的項目編號向用戶展示不同的數(shù)據(jù)獲取和解析流程。
結(jié)局
其實兢孝，還在進行中窿凤。
