人們常說人多力量大，似乎這才符合常理，但是往往在軟件項目開展的過程中依舊會出現(xiàn)人多、事少、工作量大的情況，這跟我們以往的認(rèn)知大相徑庭。

?

　　首先，要解釋下標(biāo)題的意思。人多，指的是同一個項目團(tuán)隊、同一個小組或者同一個部門的范圍內(nèi)；事少，?指的是做出的效果，真正的產(chǎn)出少；工作量大，指的是，工作時間長，工作忙，實際的投入大。

　　其實，人多事少工作量大，說白了就是效率低，而影響效率的，原因千萬種，有人員問題、溝通問題、流程問題、管理問題、技術(shù)問題.....

　　一線工作人員，沒讓專業(yè)的人做專業(yè)的事，導(dǎo)致效率低；沒讓專業(yè)的人做專業(yè)的事情，?是工作開展的大忌，在工業(yè)上，早已證明了一切，在工廠生產(chǎn)中，工人流水化作業(yè)，一個人只專注一件事情，會越做越熟練，越做越快，越做效率越高。

　　在軟件開發(fā)分工越來越明確的今天，讓后端人員搶前端人員的飯碗，去寫網(wǎng)頁、樣式，效率能高嗎？讓后端人員去搶DBA的飯碗，去做數(shù)據(jù)庫優(yōu)化，效率能高嗎？

　　不專業(yè)的人做不專業(yè)的事情，可能和公司的發(fā)展歷程、組織架構(gòu)、人員規(guī)劃有關(guān)；也可能和任務(wù)安排有關(guān)。

　　公司發(fā)展初期，養(yǎng)不起很多專業(yè)的人，可能更需要“全棧”工程師，啥都一把捉；公司發(fā)展的過渡期，有點錢了，也意識到了要讓專人做專業(yè)的事情，但是人員還沒招齊，那沒辦法，你也得兼職著做各種各樣的事情。如果公司有錢了，發(fā)展也成熟了，不是屬于以上兩種階段，在IT組織中，連前端、后端、測試、架構(gòu)、DBA、網(wǎng)絡(luò)、服務(wù)器運維、技術(shù)支持、安全、產(chǎn)品，這些職能都沒區(qū)分好的話，就會對工作效率有影響。IT一線工作人員，每個坑位，都需要一顆專業(yè)的螺絲釘。

?

●?開發(fā)人員不注重代碼質(zhì)量，導(dǎo)致后期返工，導(dǎo)致效率低

　　有時候，快即是慢，對于經(jīng)驗不足或者習(xí)慣不好的開發(fā)人員，開發(fā)前期，被迫或者自己沒意識到，為了追求進(jìn)度，邏輯沒考慮周全，沒做好自測，代碼能跑起來就算完成任務(wù)了，表面上任務(wù)完成得很快。但是在項目后期，測試階段，問題大規(guī)模爆發(fā)，甚至要返工，由于測試后期，離自己寫代碼的時候，可能隔了一段時間，有的東西自己都忘了，再回過頭去重新“熟悉”，效率能不低嗎？更為嚴(yán)重的后果是讓項目進(jìn)度不可控。因此，就算進(jìn)度再緊張，也頂住壓力，必須要做最基本的測試，再進(jìn)入下一個任務(wù)點。

?

●?個體組織人員膨脹，出現(xiàn)溝通成本大的問題，導(dǎo)致效率低

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

　　舉個簡單的栗子，很多公司都有每天晨會習(xí)慣，如果一個組有5個人，開晨會匯報工作，平均一個人匯報2分鐘，就需要10分鐘，現(xiàn)在一個組增加到10個人，一人匯報兩分鐘，都要20分鐘才能匯報完。時間就這樣過去。

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

　　信息在溝通、傳遞的過程中，可能會“失真"，你想的，不一定能100說出來，你說出來了，別人也不一定能100理解，而且每個人的理解能力、知識體系都不一樣，理解起來容易產(chǎn)生偏差，產(chǎn)生偏差就容易做錯事情。

　　因此，如果人員出現(xiàn)膨脹，要以項目為單位，進(jìn)行合理的項目拆分、人員拆分。同一個“小項目”最好不要超過4個人負(fù)責(zé)。溝通的時候，推薦使用口頭?書面?復(fù)述，減少溝通過程中的信息失真。

?

●?上、下屬之間相互不信任，做事有阻礙或者導(dǎo)致重復(fù)工作，導(dǎo)致效率低

　　上下屬相互信任是一切工作的基礎(chǔ)。如果上級不信任下屬，不敢授權(quán)給下屬，凡是都要自己過一遍，而上級往往是一對多的關(guān)系，這個時候，工作瓶頸會出現(xiàn)在上級身上；如果上級不信任下屬，搞一堆監(jiān)督機(jī)制，為了下屬不做錯事情，又讓別人同事過一遍，又要耗費額外的成本，勞民傷財，而下級得不到信任，做事受阻，久而久之就會畏手畏腳，很難獨當(dāng)一面，或覺得自己有能力沒地方使，干脆走人。上級應(yīng)該充分信任下級，放心授權(quán)讓下級去做事情，但這些都一個前提就是要有一個較好的軟件管理過程，包括開發(fā)環(huán)境和測試團(tuán)隊和在完成任務(wù)的過程中進(jìn)行一些輔導(dǎo)和進(jìn)行重要節(jié)點管控和監(jiān)督。

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

　　因此，如果有意見，前期可以提，但是解決方案一旦定下來，應(yīng)該上下一心（即使有意見也埋在心底吧），朝著目標(biāo)一起去努力。?

?

●?不同部門之間溝通存在隔閡與障礙

　　軟件開發(fā)過程中，在IT范疇內(nèi)，不同部門難免有交集，例如開發(fā)與運維、開發(fā)與測試，不同崗位承擔(dān)的責(zé)任、掌握的知識體系、考慮問題的角度往往不一樣，導(dǎo)致處理事情受阻。

　　舉個栗子，有一次，開發(fā)人員為了驗證某個問題，需要運維人員協(xié)助重啟某個站點。對于開發(fā)人員來說，這個站點，用的人比較少，而重啟也是一瞬間的事情，風(fēng)險為基本為0，但是由于運維人員掌握的知識體系不一樣，怕重啟了會造成很大影響，甚至害怕出了問題要自己承擔(dān)責(zé)任，明明可以瞬間操作解決問題的，又要等到中午或者半夜三更沒人的時候才敢重啟，效率就是這樣降低了。這個時候，需要運維人員，去學(xué)習(xí)一下相關(guān)知識，或者引入新流程，例如，重啟站點，需要某個專業(yè)人士口頭同意，即可立即執(zhí)行。

　　因此，不同部門之間的人，應(yīng)該互相學(xué)習(xí)，才能更好地溝通；做事情，盡量做輕量級的流程化、標(biāo)準(zhǔn)化。?

?

●?上級工作安排不到位

　　上級工作安排不到位，也會導(dǎo)致工作效率低。有時候會有這種怪現(xiàn)象，可能很多事情沒做，但是下面的人沒事可做；或者有的人很忙，有的人很閑。軟件開發(fā)分工，不像搬磚頭，一人搬一車就行了。軟件開發(fā)，工作量化本身就是一個很難的地方，如果項目經(jīng)理沒有做項目計劃，沒有做工作點、任務(wù)點拆分工作就很難安排到位。特別是剛剛從程序員轉(zhuǎn)型做項目經(jīng)理的人，過程性思維，不會對項目做整體的把握、整體規(guī)劃，想到哪里就做到哪里，想到什么就分配什么工作，最后一團(tuán)糟，一會把下面的人累死，一會又讓下面的人閑死。

?

●?需求傳達(dá)不明確或者理解有偏差導(dǎo)致返工

　　探知客戶內(nèi)心潛在的需求很難，而需求確定后，信息傳遞的媒介，往往是需求文檔。語言文字這種東西，傳遞的過程中容易失真，丟失原有的意思。這種情況盡可能比較，需求傳遞跨越太多層次才到最終到達(dá)開發(fā)人員身上。如果是這種結(jié)構(gòu)，每層信息丟失2都不得了，做錯了，返工的效率和代價就十分巨大。

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的为什么做软件类项目，会出现人多，事少，工作量大的情况？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。