如今各互聯網公司普通都使用敏捷開發，采用小步快跑的形式來進行專案開發，如果是小專案或者小需求，那一個開發可能就搞定了，但對于電商等復雜的系統，其功能多，結構復雜，一個人肯定是搞不定的，所以都是很多人來共同開發維護，以我曾經待過的商城團隊為例，光是后端開發就有七十多人，
為了更好地開發這類大型系統，往往把這種大型系統拆分為多個模塊，團隊成員也進行分組，每個組負責開發其對應的模塊，于是，當有涉及到多個模塊的需求進來時，往往就需要多個組的人協同開發，
這里我想談兩個問題：
1、假如有涉及到多個模塊的需求進來時，有的組需求已經拉滿了，所有人都在做別的需求，當前沒有空閑的人力，這個時候怎么辦？
2、參與此次需求的每個開發同學，是否都應該對這個需求有足夠的了解，知道需求的來龍去脈以及各個模塊之間如何做配合的？
對于問題1，通常是由PM或者專案owner去找到對應組的組長去做資源協調，組長給出一個可以進行開發和聯調的時間，PM或owner再根據這個時間來協調其它組的時間，制定出整個專案的開發、聯調、測驗與上線的時間，
但我曾經待過的一個開發團隊，在某個組當前沒有人力時，就把這個組的開發需求分配給其它有人力的組，直接讓其它組去把這個組的代碼一起開發了，于是后來大家都這么干了之后，慢慢的，當有多模塊的需求再進來時，直接就分給某個組了，然后這個組就去改其它組的代碼，把所有的模塊都給開發了，
但這樣就衍生出了許多問題，首先，你去改其他組的代碼，你不清楚他們原來的代碼邏輯，所以你的先花一定的時間去熟悉被人的代碼，假如你改到了一些隱藏的邏輯，那就容易出線上問題，而且別人來改你的代碼，也會有相同的問題，其次，別人把你的代碼改了之后，可能就破壞了你原有的邏輯，當你的同一段代碼多其他人多次修改之后，你可能都不知道它現在是什么邏輯了，如果此時出現線上問題，你又改去找誰來看這個問題呢，
所以，如果開發去跨模塊的進行代碼開發，就會存在以上的問題，開發效率低，并且容易出線上問題，所以大家經常說：一個人走得快，一群人走得遠，多人協同開發雖然增加了溝通與協調的成本，但當公司達到一定的體量，當專案達到一定的規模，靠一個或少數幾個人是很難完成的，它一定需要很多人協同開發，共同完成，所以我們現在看大廠社招的開發崗位，很多都要求開發人員具有良好的溝通與協調能力，
對于問題2，比較理想的情況，是參與開發的每個同學都清楚的知道當前需求具體是做什么，整個系統每個模塊都要該什么，我的模塊該怎么改，但從我這幾年的開發經歷來看，要做到這一點比較難，尤其是在產品快速迭代的時期，
通常當有需求來的時候，會先叫組長去溝通需求，等這個需求確定了，組長就會看看當前組內誰有時間去做這個需求，就安排誰去做，但在業務發展初期，產品都在快速迭代，開發同學的作業基本都處于飽和的狀態，一般做完一個需求后馬上就做下一個需求，有的甚至是幾個需求并行在開發，開發同學會趁著一個需求在聯調或者測驗的間隙去做另外的需求，假如這個時候組長又安排了一個需求讓你去做，你會從頭到尾的仔細研究這個需求嗎？
對于大多數人來說是不會的，這個時期為了追求迭代速度，開發質量都是可以做一定犧牲的，更何況去研究需求的細節，當組長讓他去對接需求的時候，他這個時候可能還在忙別的需求，都沒時間去仔細看這次的需求是什么，只了解到它大概是什么，現在讓他去參加具體的需求評審，他不想關心為什么要做這個需求，也不想關系其它模塊怎么做什么，他只想知道他該做什么，然后定個開發與聯調時間，他就可以去做了，做完后再去對接下一個需求，這個狀態下，開發人員缺少了對專案的思考，其實已經淪為工具人角色了，但目前的高強度迭代，也沒有時間給你去思考需求了，
這種情況其實也不僅僅是專案初期才會有，在專案穩定之后也會存在，我之前做過一個大需求，商城要增加一種商品的營銷玩法，光是把后端導購、商品、營銷、交易等幾個組參與開發的同學拉到一起，就有十幾個人，在產品溝通完需求，各模塊都對接好了，準備進行開發的時候，我們的領導在當天晚上給我們來了個突擊檢查，要求我們每個人必須了解整個需求的互動流程，以及各個模塊的具體實作，明天上班時開會檢查成果，于是那天晚上我們十幾個人就放下了手頭的作業，開始研究這個需求的每個細節，每個模塊的人互相介紹各自模塊的實作邏輯，一直熬到了凌晨幾點，第二天上午十點剛上班，就進到會議室，領導隨機抽一個人來做需求的各個模塊實作細節的講解，
其實領導的想法是好的，讓大家了解到其它模塊的設計，能對專案需求有一個更充分的認識，在具體開發實作的時候也能考慮到更多的因素，但在大體量的業務部門，團隊之間按照功能模塊分組，系統也按照模塊進行拆分，組內成員所做的開發內容其實已經固化了，因為開發同學只做了本組所對應模塊的開發，本組的專案有問題你可以去找他，其它組的模塊是怎么做的，他或許能了解個大概，但細節問題他沒做過也不知道，這個時候再來需求，他也只想知道自己的模塊該做什么，然后去把它做出來，
現在的產品功能這么多，各個系統也拆分出這么多的模塊，多數開發一般也只關注自己模塊以及上下游模塊，要清楚的了解每個模塊的細節還是很難的，當然了，也不能排查一些比較優秀的開發同學，他們會去了解其它模塊的功能以及實作，對系統整體有個清晰的認識，這樣的同學一般都是組長或者晉升組長的潛力股，但代價就是會花費更多的時間與精力，
回到問題2，對于參與某個模塊開發的同學，讓組長或者專案owner直接告訴他要改的內容，讓他去改，這種方式效率會高很多，雖然這樣會犧牲掉開發人員的主觀能動性，但很多情況下都是采用的這種方式，不會單獨安排時間讓每個開發去熟悉整個專案的細節，直接安排具體作業，提升整體的效率，如果開發想要自我提升，想去了解其它模塊，就得自己去花時間了，有的開發可能就去花時間研究了，有的就沒有，于是開發人員之間的差距就慢慢拉開了，
那你說要不要讓所有開發都去花時間做這樣研究呢？我個人的看法是沒必要的，因為這需要額外花費更多的時間，增加開發的成本，對于業務團隊，開發人員的時間是寶貴的，對于大多數的開發，應該讓他去做更多有價值的需求，產生更多的收益，誰想要做提升，那就得自己去花時間，這種情況下，也就不應該再要求每個開發同學去掌握其它模塊，了解整體系統的原理了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/550271.html
標籤：其他