剛踏入計(jì)算機(jī)行業(yè)那一年，單純的我覺得“只要技術(shù)足夠牛，就能使項(xiàng)目成功 ?！钡S著時(shí)間這把剃頭刀不斷地推高發(fā)際線，越發(fā)察覺到有一股技術(shù)以外的力量起著更大的作用。這也促使我跳出“寫代碼”邊界，思考代碼以外的發(fā)生的事情，下面是一些不成熟的小思考。
這是代碼人生系列的第五篇，系列文章目錄如下：
價(jià)值鏈流動(dòng)
圖中的直線表示項(xiàng)目價(jià)值鏈的正向流動(dòng)，而曲線表示價(jià)值鏈的反向流動(dòng)，所有的反向流動(dòng)都降低了交付速度和質(zhì)量。
“開發(fā)到需求”：表示在編碼段研發(fā)察覺的需求不完備，不合理的地方，向產(chǎn)品反饋，導(dǎo)致需要的微調(diào)。
“測試到開發(fā)”：表示測試階段發(fā)現(xiàn)的代碼和需求不符的地方。
“測試到需求”：這條反向流動(dòng)有多種情況，比如測試和開發(fā)對需求的理解不一致，誰也說服不了誰，只能一起去找產(chǎn)品。再比如測試階段發(fā)現(xiàn)需求的不合理之處，和產(chǎn)品溝通后，在交付前夕變成新的需求。
如何減少價(jià)值鏈的反向流動(dòng)是所有項(xiàng)目組成員需要思考，努力的方向。
需求共識(shí)
為減少價(jià)值鏈反向流動(dòng)，除了提高個(gè)人業(yè)務(wù)和溝通能力之外，還有一個(gè)值得努力的方向：提高所有人對需求的共識(shí)。
需求就像文學(xué)作品，1000 個(gè) 讀者心里有 1000 個(gè)哈姆雷特。
雖然這個(gè)比喻有點(diǎn)夸張，有也些許吐槽需求文檔不夠詳盡的意味。但這個(gè)鍋產(chǎn)品一個(gè)人背不了。即使產(chǎn)品文檔寫的像數(shù)學(xué)定理一樣嚴(yán)謹(jǐn)，整個(gè)價(jià)值鏈流動(dòng)的過程中，產(chǎn)品、設(shè)計(jì)、開發(fā)、測試，這四方對需求理解的偏差無法徹底消除。所以溝通是必不可少的。
偏差拖慢了項(xiàng)目推進(jìn)的速度，降低的項(xiàng)目的質(zhì)量，偏差越晚發(fā)現(xiàn)對項(xiàng)目影響越大，最壞的結(jié)果是大家對需求理解的不一致拖到測試階段才一起暴露出來。
既然偏差無法避免，是不是可以讓它早點(diǎn)暴露出來。 在整個(gè)價(jià)值流動(dòng)過程中越早發(fā)現(xiàn)理解偏差，越早治療，損失越小。
產(chǎn)品需求會(huì)、測試用例會(huì)、服務(wù)端接口會(huì)都為早崩潰做出了很大貢獻(xiàn)。（若迭代周期只有一周，就沒時(shí)間開這么多會(huì)，歡迎短周期迭代的小伙伴留言，分享下你們?nèi)绾翁幚砝斫馄?。?/p>
產(chǎn)品照本宣科地讀文檔，研發(fā)漫不經(jīng)心地恭聽，冗長的產(chǎn)品會(huì)聽著聽著便掏出了手機(jī)是常見的現(xiàn)象。最要命地是聽產(chǎn)品讀了一遍文檔后并未加深我對需求的理解，動(dòng)手開發(fā)之前還得精讀一遍。
是不是可以先讓研發(fā)精讀產(chǎn)品文檔？深入思考需求甚至構(gòu)思一下詳細(xì)設(shè)計(jì)，以便發(fā)現(xiàn)沒有考慮到的邊界情況、不能自洽的產(chǎn)品邏輯、性價(jià)比低的產(chǎn)品設(shè)計(jì)。
可不可以轉(zhuǎn)換下角色？把產(chǎn)品需求會(huì)變成 “需求答疑會(huì)” ，讓研發(fā)主導(dǎo)，提出對需求的疑問和建議。
這樣會(huì)不會(huì)調(diào)動(dòng)起研發(fā)的主動(dòng)性？在過需求的時(shí)候就把更多的“理解偏差”都暴露出來？
模塊歸屬
在需求答疑會(huì)之前，得先做好開發(fā)分工，這引出了另一個(gè)問題：
“短期的模塊分工要不要變成長期的模塊歸屬？”即業(yè)務(wù)模塊是有產(chǎn)權(quán)的，讓一個(gè)模塊長期的歸屬于一個(gè)研發(fā)，這個(gè)模塊的需求，他主導(dǎo)開發(fā)，這個(gè)模塊的 bug，他主導(dǎo)修復(fù)，所有對該模塊的修改都需要經(jīng)過他的 Review。
在不熟悉的模塊中改動(dòng)代碼是一件事倍功半的事情。就算該模塊代碼邏輯清晰，低耦合，易于擴(kuò)展，也可能因?yàn)椴皇煜ぞ唧w的業(yè)務(wù)邏輯，改出 bug。更何況大部分的代碼是，邏輯混雜，高耦合，牽一發(fā)則動(dòng)全身。
程序員多少都一些工匠情節(jié)，對自己親手打造的代碼都“細(xì)心呵護(hù)”，就好像自己雕琢的工藝品，這種情愫會(huì)推動(dòng)他不斷地自驅(qū)動(dòng)地優(yōu)化代碼。但若是別人的工藝品，這種動(dòng)力則會(huì)大打折扣。
只有分工才能專業(yè)化，只有專業(yè)化才能提高質(zhì)量。
模塊歸屬也讓“集中式的代碼 Review”變成“分布式的代碼 Review”，原來所有的代碼都是讓團(tuán)隊(duì)的 Leader review，但 Leader 怎么可能了解所有業(yè)務(wù)模塊的細(xì)節(jié)？所以只能泛泛地 Review。何不讓最了解這塊代碼的人 Review ？
知識(shí)共享
模塊歸屬也會(huì)增加風(fēng)險(xiǎn)，即會(huì)顯著地降低“巴士因子”。巴士因子描述的是項(xiàng)目知識(shí)的集中程度，即一輛巴士撞死幾個(gè)研發(fā)，整個(gè)項(xiàng)目就可以宣告 GG。
某個(gè)模塊的知識(shí)只掌握在某個(gè)人手里，就好像把所有的籌碼放在一個(gè)籃子里。他生病了、離職了，該模塊就會(huì)癱瘓。
如果團(tuán)隊(duì)的大部分知識(shí)只集中于少數(shù)人手里，不利于提高整個(gè)團(tuán)隊(duì)技術(shù)水平和抗風(fēng)險(xiǎn)能力。
知識(shí)是多種多樣的，業(yè)務(wù)知識(shí)的共享可以降低團(tuán)隊(duì)開發(fā)和維護(hù)成本，通用知識(shí)的共享可以提高團(tuán)隊(duì)的編碼質(zhì)量。
每個(gè)研發(fā)擅長的領(lǐng)域不同，知識(shí)的邊界也不盡相同，如果知識(shí)能夠在團(tuán)隊(duì)中無障礙的流動(dòng)，如果大家的知識(shí)可以做并集，不僅可以提高整個(gè)團(tuán)隊(duì)的技術(shù)水平，還可以形成很好的技術(shù)氛圍和粘性。
“集體Code Review” 可能是一種可以嘗試的知識(shí)共享方式。它鼓勵(lì)雙向溝通：將一段代碼公之于眾，接收大家的 Review。條條大路通羅馬，你實(shí)現(xiàn)的那條可能不是最短路徑，或擴(kuò)展性不佳，或性能不好。這正是集體智慧發(fā)光發(fā)熱的地方，對同一段代碼的集體審視可能會(huì)迸發(fā)出很多思想的碰撞，真理總是越辯越明，集體智慧的光芒可以讓在場的所有人從中受益。
