本文所要分享的是軟體開發過程中，親身經歷過的「怪現象」。為什麼說怪呢，人多力量大，似乎才符合常理，但是往往在軟體專案開展的過程中會出現人多、事少、工作量大的情況，這跟我們以往的認知大相徑庭。
此處輸入描述
首先，要解釋下標題的意思。人多，指的是同乙個專案團隊、同乙個小組或者同乙個部門的範圍內；事少， 指的是做出的效果，真正的產出少；工作量大，指的是，工作時間長，工作忙，實際的投入大。
其實，人多事少工作量大，說白了就是效率低，而影響效率的，原因千萬種，有人員問題、溝通問題、流程問題、管理問題、技術問題，下面零散地列舉下博主親身經歷過的問題：
文章基本純文字，需要空閒的時候，精心閱讀哦。
● 一線工作人員，沒讓專業的人做專業的事，導致效率低
沒讓專業的人做專業的事情， 是工作開展的大忌，在工業上，早已證明了一切，在工廠生產中，工**水化作業，乙個人只專注一件事情，會越做越熟練，越做越快，越做效率越高。
在軟體開發分工越來越明確的今天，讓後端人員搶前端人員的飯碗，去寫網頁、樣式，效率能高嗎？讓後端人員去搶dba的飯碗，去做資料庫優化，效率能高嗎？
不專業的人做不專業的事情，可能和公司的發展歷程、組織架構、人員規劃有關；也可能和任務安排有關。
公司發展初期，養不起很多專業的人，可能更需要「全棧」工程師，啥都一把捉；公司發展的過渡期，有點錢了，也意識到了要讓專人做專業的事情，但是人員還沒招齊，那沒辦法，你也得兼職著做各種各樣的事情。如果公司有錢了，發展也成熟了，不是屬於以上兩種階段，在it組織中，連前端、後端、測試、架構、dba、網路、伺服器運維、技術支援、安全、產品，這些職能都沒區分好的話，就會對工作效率有影響。it一線工作人員，每個坑位，都需要一顆專業的螺絲釘。
● 開發人員不注重**質量，導致後期返工，導致效率低
有時候，快即是慢，對於經驗不足或者習慣不好的開發人員，開發前期，被迫或者自己沒意識到，為了追求進度，邏輯沒考慮周全，沒做好自測，**能跑起來就算完成任務了，表面上任務完成得很快。但是在專案後期，測試階段，問題大規模爆發，甚至要返工，由於測試後期，離自己寫**的時候，可能隔了一段時間，有的東西自己都忘了，再回過頭去重新「熟悉」，效率能不低嗎？更為嚴重的後果是讓專案進度不可控。因此，就算進度再緊張，也頂住壓力，必須要做最基本的測試，再進入下乙個任務點。
● 個體組織人員膨脹，出現溝通成本大的問題，導致效率低
溝通成本是人員膨脹後，暴露出來的首要問題。
舉個簡單的栗子，很多公司都有每天晨會習慣，如果乙個組有5個人，開晨會匯報工作，平均乙個人匯報2分鐘，就需要10分鐘，現在乙個組增加到10個人，一人匯報兩分鐘，都要20分鐘才能匯報完。時間就這樣過去。
再舉個栗子，30人天的工作，分給2個人做，可能需要15天，共耗費30人天，但是分給5個人做，6天能完成嗎？
資訊在溝通、傳遞的過程中，可能會「失真"，你想的，不一定能100%說出來，你說出來了，別人也不一定能100%理解，而且每個人的理解能力、知識體系都不一樣，理解起來容易產生偏差，產生偏差就容易做錯事情。
因此，如果人員出現膨脹，要以專案為單位，進行合理的專案拆分、人員拆分。同乙個「小專案」最好不要超過4個人負責。溝通的時候，推薦使用口頭+書面+複述，減少溝通過程中的資訊失真。
● 上、下屬之間相互不信任，做事有阻礙或者導致重複工作，導致效率低
上下屬相互信任是一切工作的基礎。如果上級不信任下屬，不敢授權給下屬，凡是都要自己過一遍，而上級往往是一對多的關係，這個時候，工作瓶頸會出現在上級身上；如果上級不信任下屬，搞一堆監督機制，為了下屬不做錯事情，又讓別人同事過一遍，又要耗費額外的成本，勞民傷財，而下級得不到信任，做事受阻，久而久之就會畏手畏腳，很難獨當一面，或覺得自己有能力沒地方使，乾脆走人。
上級應該充分信任下級，放心授權讓下級去做事情，但這些都乙個前提就是要有乙個較好的軟體管理過程，包括開發環境和測試團隊和在完成任務的過程中進行一些輔導和進行重要節點管控和監督。
上級不信任下級，經常碰到，而下級不信任上級也很要命。程式設計師是很有個性的工種，不好管理，往往特別多想法。就好像車輪子陷入泥潭中，上級說車子往前推，有的人又說，往後拉，各自發力，估計車子永遠都擺脫不了泥潭，還談何效率？
因此，如果有意見，前期可以提，但是解決方案一旦定下來，應該上下一心（即使有意見也埋在心底吧），朝著目標一起去努力。
● 不同部門之間溝通存在隔閡與障礙
軟體開發過程中，在it範疇內，不同部門難免有交集，例如開發與運維、開發與測試，不同崗位承擔的責任、掌握的知識體系、考慮問題的角度往往不一樣，導致處理事情受阻。
舉個栗子，有一次，開發人員為了驗證某個問題，需要運維人員協助重啟某個站點。對於開發人員來說，這個站點，用的人比較少，而重啟也是一瞬間的事情，風險為基本為0，但是由於運維人員掌握的知識體系不一樣，怕重啟了會造成很大影響，甚至害怕出了問題要自己承擔責任，明明可以瞬間操作解決問題的，又要等到中午或者半夜三更沒人的時候才敢重啟，效率就是這樣降低了。這個時候，需要運維人員，去學習一下相關知識，或者引入新流程，例如，重啟站點，需要某個專業人士口頭同意，即可立即執行。
因此，不同部門之間的人，應該互相學習，才能更好地溝通；做事情，盡量做輕量級的流程化、標準化。
● 上級工作安排不到位
上級工作安排不到位，也會導致工作效率低。有時候會有這種怪現象，可能很多事情沒做，但是下面的人沒事可做；或者有的人很忙，有的人很閒。
軟體開發分工，不像搬磚頭，一人搬一車就行了。軟體開發，工作量化本身就是乙個很難的地方，如果專案經理沒有做專案計畫，沒有做工作點、任務點拆分工作就很難安排到位。特別是剛剛從程式設計師轉型做專案經理的人，過程性思維，不會對專案做整體的把握、整體規劃，想到**就做到**，想到什麼就分配什麼工作，最後一團糟，一會把下面的人累死，一會又讓下面的人閒死。
● 需求傳達不明確或者理解有偏差導致返工
探知客戶內心潛在的需求很難，而需求確定後，資訊傳遞的媒介，往往是需求文件。語言文字這種東西，傳遞的過程中容易失真，丟失原有的意思。這種情況盡可能比較，需求傳遞跨越太多層次才到最終到達開發人員身上。如果是這種結構，每層資訊丟失2%都不得了，做錯了，返工的效率和代價就十分巨大。
很多時候往往是這種傳達方式：
此處輸入描述
我們需要的是這種方式：
此處輸入描述
最終的研發人員，應該接受到需求後，應該是反向和使用者、產品經理、研發經理溝通，最終才能確定的。
● 技術架構過於落後、過於複雜
先進的技術架構、統一高效地開發標準，是系統建設的基石，會大大提高軟體的生產力，讓開發人員專注於實現業務、商業邏輯，做更有價值，更高產出的事情。
當你還在糾結頁面相容性，糾結這個介面必填怎麼實現的的時候，人家通過工具簡單配置，介面就自動生成了；當你還在糾結併發量大，分布式事務如何實現的時候，人家訊息機制、兩段式提交已經用的飛起來；當你還在糾結分布式系統，資料庫拆分，如果做垮庫查詢的時候，人家orm自動分庫路由，資料分發機制已經用爛了；當扯不清、道不明各個系統之間的呼叫關係，猜不透單點改動的影響範圍、運維上壓力巨大的時候，人家服務治理框架應運而生。。。。。。。這所有的所有，都依賴於先進的軟體架構，有現成的或者自主研發的。這一切的一切，都可以讓開發人員如虎添翼，事半功倍。
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
1.程式設計師寫出自認為沒有bug的 2.軟體測試，發現了20個bug。3.程式設計師修改了10個bug，並告訴測試組另外10個不是bug。4.測試組發現其中5個改動根本無法工作，同時又發現了15個新bug。5.重複3次步驟3和步驟4。6.鑑於市場方面的壓力，為了配合當初制定的過分樂觀的發布時間表，...
軟體開發過程
軟體生命週期 1 問題定義 使用者需要解決什麼問題?2 可行性分析 使用者需要解決的問題是否可行 技術可行性 市場可行性 3 需求分析 將使用者提出的問題進行細化 4 系統設計 確定細化問題的實現方法 5 編碼 依據需求和設計穩定進行開發，解決問題 6 測試 驗證是否已經解決使用者提出的問題 單元測...