爲何軟件開發，人多，事少，還會工做量大？

本文所要分享的是軟件開發過程當中，親身經歷過的「怪現象」。爲何說怪呢，人多力量大，彷佛才符合常理，可是每每在軟件項目開展的過程當中會出現人多、事少、工做量大的狀況，這跟咱們以往的認知截然不同。

首先，要解釋下標題的意思。人多，指的是同一個項目團隊、同一個小組或者同一個部門的範圍內；事少， 指的是作出的效果，真正的產出少；工做量大，指的是，工做時間長，工做忙，實際的投入大。

其實，人多事少工做量大，說白了就是效率低，而影響效率的，緣由千萬種，有人員問題、溝通問題、流程問題、管理問題、技術問題，下面零散地列舉下博主親身經歷過的問題：

文章基本純文字，須要空閒的時候，精心閱讀哦。

● 一線工做人員，沒讓專業的人作專業的事，致使效率低

沒讓專業的人作專業的事情， 是工做開展的大忌，在工業上，早已證實了一切，在工廠生產中，工人流水化做業，一我的只專一一件事情，會越作越熟練，越作越快，越作效率越高。

在軟件開發分工愈來愈明確的今天，讓後端人員搶前端人員的飯碗，去寫網頁、樣式，效率能高嗎？讓後端人員去搶DBA的飯碗，去作數據庫優化，效率能高嗎？

不專業的人作不專業的事情，可能和公司的發展歷程、組織架構、人員規劃有關；也可能和任務安排有關。

公司發展初期，養不起不少專業的人，可能更須要「全棧」工程師，啥都一把捉；公司發展的過渡期，有點錢了，也意識到了要讓專人作專業的事情，可是人員還沒招齊，那沒辦法，你也得兼職着作各類各樣的事情。若是公司有錢了，發展也成熟了，不是屬於以上兩種階段，在IT組織中，連前端、後端、測試、架構、DBA、網絡、服務器運維、技術支持、安全、產品，這些職能都沒區分好的話，就會對工做效率有影響。IT一線工做人員，每一個坑位，都須要一顆專業的螺絲釘。

● 開發人員不注重代碼質量，致使後期返工，致使效率低

有時候，快便是慢，對於經驗不足或者習慣很差的開發人員，開發前期，被迫或者本身沒意識到，爲了追求進度，邏輯沒考慮周全，沒作好自測，代碼能跑起來就算完成任務了，表面上任務完成得很快。可是在項目後期，測試階段，問題大規模爆發，甚至要返工，因爲測試後期，離本身寫代碼的時候，可能隔了一段時間，有的東西本身都忘了，再回過頭去從新「熟悉」，效率能不低嗎？更爲嚴重的後果是讓項目進度不可控。所以，就算進度再緊張，也頂住壓力，必需要作最基本的測試，再進入下一個任務點。

● 個體組織人員膨脹，出現溝通成本大的問題，致使效率低

溝通成本是人員膨脹後，暴露出來的首要問題。

舉個簡單的栗子，不少公司都有天天晨會習慣，若是一個組有5我的，開晨會彙報工做，平均一我的彙報2分鐘，就須要10分鐘，如今一個組增長到10我的，一人彙報兩分鐘，都要20分鐘才能彙報完。時間就這樣過去。

再舉個栗子，30人天的工做，分給2我的作，可能須要15天，共耗費30人天，可是分給5我的作，6天能完成嗎？

信息在溝通、傳遞的過程當中，可能會「失真"，你想的，不必定能100%說出來，你說出來了，別人也不必定能100%理解，並且每一個人的理解能力、知識體系都不同，理解起來容易產生誤差，產生誤差就容易作錯事情。

所以，若是人員出現膨脹，要以項目爲單位，進行合理的項目拆分、人員拆分。同一個「小項目」最好不要超過4我的負責。溝通的時候，推薦使用口頭+書面+複述，減小溝經過程中的信息失真。

● 上、下屬之間相互不信任，作事有阻礙或者致使重複工做，致使效率低

上下屬相互信任是一切工做的基礎。若是上級不信任下屬，不敢受權給下屬，凡是都要本身過一遍，而上級每每是一對多的關係，這個時候，工做瓶頸會出如今上級身上；若是上級不信任下屬，搞一堆監督機制，爲了下屬不作錯事情，又讓別人同事過一遍，又要耗費額外的成本，勞民傷財，而下級得不到信任，作事受阻，長此以往就會畏手畏腳，很難獨當一面，或以爲本身有能力沒地方使，乾脆走人。

上級應該充分信任下級，放心受權讓下級去作事情，但這些都一個前提就是要有一個較好的軟件管理過程，包括開發環境和測試團隊和在完成任務的過程當中進行一些輔導和進行重要節點管控和監督。

上級不信任下級，常常碰到，而下級不信任上級也很要命。程序員是頗有個性的工種，很差管理，每每特別多想法。就好像車輪子陷入泥潭中，上級說車子往前推，有的人又說，日後拉，各自發力，估計車子永遠都擺脫不了泥潭，還談何效率？

所以，若是有意見，前期能夠提，可是解決方案一旦定下來，應該上下一心（即便有意見也埋在心底吧），朝着目標一塊兒去努力。

● 不一樣部門之間溝通存在隔閡與障礙

軟件開發過程當中，在IT範疇內，不一樣部門不免有交集，例如開發與運維、開發與測試，不一樣崗位承擔的責任、掌握的知識體系、考慮問題的角度每每不同，致使處理事情受阻。

舉個栗子，有一次，開發人員爲了驗證某個問題，須要運維人員協助重啓某個站點。對於開發人員來講，這個站點，用的人比較少，而重啓也是一瞬間的事情，風險爲基本爲0，可是因爲運維人員掌握的知識體系不同，怕重啓了會形成很大影響，甚至懼怕出了問題要本身承擔責任，明明能夠瞬間操做解決問題的，又要等到中午或者半夜三更沒人的時候纔敢重啓，效率就是這樣下降了。這個時候，須要運維人員，去學習一下相關知識，或者引入新流程，例如，重啓站點，須要某個專業人士口頭贊成，便可當即執行。

所以，不一樣部門之間的人，應該互相學習，才能更好地溝通；作事情，儘可能作輕量級的流程化、標準化。

● 上級工做安排不到位

上級工做安排不到位，也會致使工做效率低。有時候會有這種怪現象，可能不少事情沒作，可是下面的人沒事可作；或者有的人很忙，有的人很閒。

軟件開發分工，不像搬磚頭，一人搬一車就好了。軟件開發，工做量化自己就是一個很難的地方，若是項目經理沒有作項目計劃，沒有作工做點、任務點拆分工做就很難安排到位。特別是剛剛從程序員轉型作項目經理的人，過程性思惟，不會對項目作總體的把握、總體規劃，想到哪裏就作到哪裏，想到什麼就分配什麼工做，最後一團糟，一會把下面的人累死，一會又讓下面的人閒死。

想要了解更多軟件研發過程的開發經驗，能夠加羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，如下的資源都在羣的共享區，目前受益良多。

● 需求傳達不明確或者理解有誤差致使返工

探知客戶心裏潛在的需求很難，而需求肯定後，信息傳遞的媒介，每每是需求文檔。語言文字這種東西，傳遞的過程當中容易失真，丟失原有的意思。這種狀況儘量比較，需求傳遞跨越太多層次纔到最終到達開發人員身上。若是是這種結構，每層信息丟失2%都不得了，作錯了，返工的效率和代價就十分巨大。

不少時候每每是這種傳達方式：

咱們須要的是這種方式：

最終的研發人員，應該接受到需求後，應該是反向和用戶、產品經理、研發經理溝通，最終才能肯定的。

● 技術架構過於落後、過於複雜

先進的技術架構、統一高效地開發標準，是系統建設的基石，會大大提升軟件的生產力，讓開發人員專一於實現業務、商業邏輯，作更有價值，更高產出的事情。

當你還在糾結頁面兼容性，糾結這個界面必填怎麼實現的的時候，人家經過工具簡單配置，界面就自動生成了；當你還在糾結併發量大，分佈式事務如何實現的時候，人家消息機制、兩段式提交已經用的飛起來；當你還在糾結分佈式系統，數據庫拆分，若是作垮庫查詢的時候，人家ORM自動分庫路由，數據分發機制已經用爛了；當扯不清、道不明各個系統之間的調用關係，猜不透單點改動的影響範圍、運維上壓力巨大的時候，人家服務治理框架應運而生。。。。。。。這全部的全部，都依賴於先進的軟件架構，有現成的或者自主研發的。這一切的一切，均可以讓開發人員如虎添翼，事半功倍。