中大型軟件開發，免不了團隊開發，團隊開發少不了分工合作。在團隊開發中，當然每個人的能力都很重要，但是我認為可信賴的工作是團隊開發的首要條件，也是團隊開發存在的基本保證。沒有可信賴的工作，沒有團隊分工合作，即便有團隊存在，也會變成一只內耗極高的團隊，管理協調的代價超過團隊的優勢，團隊的價值會被堙沒，便沒有存在的價值了。
軟件開發中可信賴的工作，是指：團隊開發中，向小組或者個人分配的一個模塊、一項任務應該開始前應該有可信賴的評估和分工，在開始時候被可信賴的計劃，在執行中可信賴的反饋，執行過程中完成時間應該被可信賴，執行結束后要有可信賴的質量和可信賴的測試與后繼補充性開發和修正工作。相反的為軟件開發中的不可信賴工作或者不可信賴因素。
大多數新團隊的開發工作中的組員的工作是不可信賴的，舉個簡單的離子，架構師或者主程序員分工好以后，交給一個小組一個模塊，或者交給一個人一個模塊。雖然有過反復的叮囑，應該仔細，應該做好細節。但是每次員工遞交上來的模塊后，經過測試，會發現很多的問題，根本不可信賴。有時候一個模塊交給團隊組員去開發，用了三天時間，為了修正他們的錯誤，不得不把所有的代碼去看一遍，后修正工作似乎也用了三天時間，而這些問題中的絕大多數問題為不小心或者不細致導致的問題，這些問題中的絕大多數問題會反復出現在后繼工作中，即便你重申過多次。當你把某項工作交給某個人的時候，你不敢相信他可以按質按時的完成，等他完成后遞交，你不能確認他的工作真的完成了，或者只是為了應付差事，他自己認為完成了。以至于大家都認為完成的東西，到后才發現原來根本沒有完成，讓團隊無法托付工作給組員。讓客戶無法托付產品給公司。這樣的問題非常嚴重，輕則耽誤工期，延誤時機，增加開發成本和團隊管理內耗，重則可能影響到產品成敗，甚至公司的前途，所以不得不把可信賴工作放到所有的管理的首位。
根據以前項目開發的經驗，我做了以下整理，反應到真實的軟件開發中大概如下：
首先、任務開始前，管理者應該對問題的描述、任務的規模、要求、開發完成后的質量和約束有著清晰而深刻的立即。同時對團隊組員的技術水平、時間安排、工作效率和態度有著清晰的認識，知道誰可以勝任，誰不能勝任。應該如何去分配工作，大概需要用時多少，會出現什么狀況有著清晰的認知。這個是可信賴工作的前提。
其次、任務分配后，組員開始開發前，應該確保和管理者進行過有效的溝通，雙方對任務的理解一致而且無歧義。然后組員應該對任務作出基本的計劃和規劃，列出任務要點以及分工的先后次序，同時對任務作出自我評估，判斷是否可以勝任，同時估計該項任務完成的時間和工作量。并且應該以正式報表的形式進行遞交。團隊雖小，個人認為這個報表少不了，不必太過擔心在這樣的報表中花費的時間和成本，切記磨刀不誤砍柴工。
然后、任何開始執行以后，要有一個定時的回報，方便管理者知道的進度。回報的內容應該包括：當前已經完成的工作，剩余的工作以及計劃的調整。以及開發中遇到的難點和遺漏點。回報不是為了趕進度，而是為了準確的了解信息，在回報中，管理者不可過分干預工作進度，但求做到心中有數即可。同時任何團隊的組員應該明白：可信賴的工作不僅僅是在時間上可信賴，而且更應該是在質量上可信賴。質量上的要求要遠遠高于時間上的可信賴。
再次 、任務執行完成以后，必須有一個報表：這個報表要求明確的寫明開發者是誰，測試者是誰。同時要簽入源代碼，因為團隊水平不可能完全一致，允許有無法完成的任務點，但是報表必須寫明什么沒有完成，原因是什么。允許完不成的任務，但是完成的任務一定是可信賴的。即功能上沒任何遺漏、質量上沒任何技術缺陷或者粗心帶來的遺漏性缺陷。同時時間上沒明顯的逾期。
后、對簽入的代碼加入框架進行測試，然后對任務應該有一個基本的評估，根據開發前的報表和開發后的報表，以及軟件模塊的實際質量做一個評估，要求評估客觀有威信。然后做出賞罰。
以上即為可信賴工作的幾個要點，看上去簡單可行，但實際操作中卻很難執行。根據個人帶領團隊的經驗，做出以下幾點措施。
第一、讓團隊每一個人都能明白：一個人能力可以有大小，技術可以有差異，但是服從性和細致性的工作方面的要求沒有區別，不管是技術大牛還是實習小菜，交給的任務，完不成可以提出來超出自己的能力范圍，但是一旦去做，要做好！保證每個細節都不會出現問題，經得起測試和推敲。每個測試人員都應該明白可信賴的重要性，切實把握好關。同時對于任何一次沒有經過嚴格測試而遺留下來的Bug進行評估，如果因為非不可預見因素導致的，要進行懲罰。對于無法勝任可信賴工作的人，建議直接清理。培養可信賴的工作意識，是以第一要務。
第二、分配工作的時候留足余地，考慮到非可信賴發生后的補救工作，同時根據工作的難度和生疏程度，應該乘以一個時間系數，一般工作可以乘以1.2，自己陌生的團隊和陌生的工作，應該乘以 3。同時每次根據以往的工作，對每個組員做一個系數評估。方便以后工作分配。
第三、明確工作內容、范圍和質量的約束，在分工前讓組員明白自己要完成的任務要求，包括功能要求和非功能要求，特別應該了解非功能部分的質量約束，比如魯棒性要求、擴展性和健壯性的要求。同時鼓勵組員提升質量標準和細節標準，確定明確的獎罰制度。
第四、不要把一項工作和任務安排周期太長，每三天到五天應該有一次小規模的驗收行動，確保每個組員的短期可信賴的工作，因為非可信賴因素會慢慢出現和積累，如果安排一個較長期的工作，往往到后容易失去控制。短期非可信賴容易控制和踢出不良因素。
第四、做好獎罰制度，一個團隊中，不可信賴的工作應該是懲罰較重的懲罰點。同時每個小組要指定可信賴度監督和檢測員，保證不良因素在底層解決，而非到上層以后再去解決。任何一個小的Bug在程序設計環節想到如何處理，成本低，后而進入程序開發環節，后進入測試環節，到簽入質量檢測環節，遞交客戶，到售后環節，每增一個環節，增加一份成本。
第五、開發未動，測試先行，我們嘗試過按照接口去分配類庫，后把類庫組合在一起的做法，發現：很多人在無法測試的情況下，去做開發，然后拼裝在一起后去測試，無法發現一些問題，而且這樣過分依賴開發人員的經驗和技術，非常不同。同時問題遞交到軟件上去測試，容易掩蓋問題。并且增加問題解決的復雜度。
第六、建立良好的信賴跟蹤體系，要建立良好的質量跟蹤體系，必須明確每個環節的每個開發人員、測試人員，以及任何形式的決策和貢獻者。對出現問題的原因和人員做記錄和跟蹤，質量體系不僅僅要跟蹤 軟件開發中遇到的bug，還要跟蹤進度、時間、工作量、質量等等。這樣可以方便后期把一些常見的問題規范化和文字化，同時還有助于分工的時候對每個員工的把握以及后期的選拔等等。
