1 引言
就我瞭解大多數軟件企業的項目管理模式，仍然採用瀑布模型。在傳統的瀑布模型“需求——設計——編碼——測試——發佈”中，一些規模企業爲了規範管理，將每個環節的每個角色的職責定義的非常清楚，通過工程的方式解決了分工和協作問題，使得大型軟件研發和維護成爲可能，但是也引入了新的問題——各種糾結。
2 時間 時間
時間就是金錢。在軟件產品市場，時間就是客戶滿意，時間就是領先競爭對手！
在軟件研發過程中，時間，很糾結。
對於大多數中國軟件企業而言，都處在買方市場，買軟件產品的企業都是大爺。爲了更清晰的表述，請允許我把買方等同於甲方，把軟件研發屌絲所在的企業稱爲乙方。根據甲方各種情況帶來的時間節點，就很容易成爲軟件產品研發過程中的deadline。
就乙方來說，有兩大類：
1） 做的產品比較成熟，甲方的需求變化小；做關係產品，基本能用即可，需求的偏差靠酒杯或者其他方式進行修正。
2） 做大量新產品；現有產品需求變化大。
當然，本文需要談的是第2類，大部分苦逼屌絲程序員所在的軟件企業。
OK，把思路理一下：甲方市場；簽單時明確deadline；產品需求變化大。
這就很糾結了，一方面，甲方給的時間點是確定的；另一方面，產品需求變化大。或者即使產品需求變化不大，給的時間確出奇的少，還美其名曰體現乙方的實力。與此同時，就少量的幾個程序員在吭哧吭哧幹活，擦！
當然，這裏出現的時間糾結，是對程序員而言的。
對於這種情況，仔細讀過《人月神話》的同學可能會得出這樣的結論：項目必然失敗。但是，在中國，大多數類似的項目，雖然不能說是成功，但都是在deadline到的時候完成了交付，爲啥呢？因爲有我們最可愛的程序員——把青春與身體奉獻給加班的人們！
所謂糾結，是時間不夠，而又不得不完成項目。
所謂糾結，是企業的“收益”與程序員的“損失”。
所謂糾結，是年輕的程序員如何平衡“收益”和“損失”。
無論無任何，在時間上，乙方現在、將來都將處於弱勢。而乙方的兄弟，又是弱勢中的弱勢。
所以，對於有節操的乙方企業，在這種情況下，儘量對員工，錢，給到位。一個項目告一段落或者工作間隙，儘量讓員工爽一點（比如，靈活的換休政策，鼓勵旅遊等放鬆活動）
所以，如果程序員，你夠遇到一個關心你這種糾結，理解你這種糾結的領導，你就從了吧。
3 割還是不割
當前版本交付deadline洶涌來襲，時間不夠了，割功能吧。不行！因爲甲方說不可以割。
那就割研發環節吧！
需求，可以寫簡單點；設計，可以把概要設計省略；編碼，不講究可維護、可擴展、可複用、靈活性，只要實現功能就極好了；測試，按照甲方驗收手冊來整，乙方企業原來的規範，都可以變成浮雲。時間緊張的時候，割研發環節，當下是爽歪歪，V1.0順利發佈。
可糾結來了：軟件產品，一般而言，不是一錘子買賣。還需要演進，還需要新增/變化功能。
V1.0上線，甲方既定的計劃得到了保證，一堆甲方自家的KPI漂亮的像花兒一樣。V1.1提上議事議程。
V1.1的需求來了，真的來了。乙方的程序員一手新需求，一手老代碼，欲哭無淚！這是要鬧哪樣，需要重啓爐竈啊……
那割還是不割呢？
割的好處顯而易見，可以在有限的時間，儘快完成可運行的軟件的交付。
不割呢，要麼你增加研發資源（貌似又有人月神話的陷阱）；要麼你搞定甲方，延長時間或者減少功能需求。
就本人的個人經驗而言，甲方很難搞定，如果不能顯著增加研發資源，在當下的版本眼中，最好還是把能割的割了。
割，新問題來了。
1）割掉的東東，要不要抽空補上？
2）割出問題來了，誰來擔責？
對於問題1，一般來說，至少口頭上，企業流程上都會選擇補上。但是，實際情況是，一旦割掉，不是想補就能補得回來的。特別像有些企業，每個人都是有並行任務的。A產品V1.0交付後，可能B產品的V1.0又來了。總之，你會感覺有很多更重要的事情，去阻礙你補作業。另外，無論是對於搞需求還是軟件的兄弟來說，比較傾向於搞新鮮東東。對於補作業這種沒有啥新鮮感的東東，在潛意識裏面的拒絕的。或者即使補，由於很多東西都已經實現了，會補得比較潦草——簡單，跟不補也沒啥兩樣。
要把這個問題解決，一方面企業要有這個環境來保證這個補作業流程，例如，企業的要求；另一方面，需要基層管理人員有能力把這個動作落到實處。更重要的是，不要把這種臨時的割當成常態，一旦成爲常態，研發人員就會習慣與裁剪或者弱化過程，就會給企業的軟件質量帶來致命的損傷。
對於問題2，責任的問題。這個問題比較好處理，就是領導負責制。誰給項目團隊發錢，誰就有權拍板，有就擔這個責任。對於這個問題，需要提醒一點的是，要避免掉入分權陷阱。因爲不少公司，管項目和管人是兩撥人。要避免除了問題推諉的情況。如果不幸出了這種問題，企業老總必須首先進行流程和權力梳理。如果流程沒有問題，對不起，哪個部分人有問題，最好請他早走，或者至少要態度嚴肅的懲罰一下。
4 堅持還是放棄
割還是不割，是個短期的行爲。
堅持還是放棄，我想討論的是長期的行爲。
某些研發過程，做起來索然無味，看起來真的沒有必要堅持下去，例如，代碼走查。當然，代碼走查的必要性，我想只要有3年以上工作經驗的兄弟，一定可以列舉10條以上的理由。但是，你所在的企業，是否真正做好了代碼走查，並且一直堅持在真正的做呢？
軟件產品在交付給客戶時，有兩個方面直接貢獻價值：一是軟件產品本身，二是用戶手冊。隱藏在這兩個東東下面的東西，間接貢獻着產品價值：需求、設計、同行評審，測試以及上面提到的代碼走查（實際上代碼走查也可以看做一種同行評審）。
在什麼樣的情況下我們會降低對間接價值過程的要求甚至放棄呢？
可能有這麼幾種情況：
1） 重複勞動。部分工作在團隊看來價值不明顯。例如，對於數據維護類的WEB應用，大部分功能是增刪改查，代碼走查就和編程過程一樣，顯得有點重複並且價值不高。久而久之，做此類工作的開發人員就會降低對代碼走查的重視程度，甚至認爲代碼走查沒有必要搞。
2） 人員能力。對於客戶來說，只關注是否可以按里程碑、按質量要求完成產品交付。我們的軟件產品研發，也會以這個爲最重要的目標。所以，有的時候，部分人員能力不夠的時候，團隊內部可能會選擇容忍一下，也就是降低對間接價值過程的要求。例如，寫需求的兄弟，可能對業務不熟悉（新招的）或者本身能力還達不到；同時這個事情爲整個團隊所共知。我們那麼，在需求評審的時候，就會減低對需求的質量要求。我們當然可以選擇幹掉這個寫需求的兄弟，但是這個要領導發話。我們目前最主要的是滿足客戶需求，而且還有里程碑在這裏等着。所以忍一忍，也就過去了。我想，類似的事情可能其他團隊多多少少遇到過。
3） 過程考覈侵蝕。這個也比較麻煩。對於這些間接價值過程，做得如何，如何評判。一些有規模的公司就會弄一堆的過程考覈指標來。對於過程考覈，我覺得這樣一種說服比較中肯“過程考覈本身是好的，但是爲了考覈而考覈，就會演變成無節操的追求數字，最後就變成了領導的自娛自樂和員工的無聊旁觀”。比如說，需求的評審時的缺陷率。本身這個東東是希望推動需求質量提升。但是如果過分追求，就會出現不管需求文檔本身好壞，大家一窩蜂的去找缺陷。這樣的結果，就是在過程數據中遺留一堆分不清價值的缺陷記錄。
4） 不合理的考覈指標。例如代碼行數。考覈開發人員的工作量，代碼行數可以作爲參考，但是一旦作爲考覈（觀察）指標，就變味了。搞開發的兄弟都知道，要想提高代碼行數，那是so easy！但是，代碼行數多的開發人員就是好開發？在類似的考覈指標驅動下，本來大家追求優秀開發的熱情就會搜到嚴重損傷。
面對上述種種，有些團隊就會放棄對某些研發過程的堅持。當然，即使沒有上述種種，能夠把所有研發過程做到位的國內軟件研發企業，應該可以稱得上是鳳毛菱角。
是堅持還是放棄，這是個問題。但是，對於有追求的團隊來說，這就是挑戰，就是理想。
上述的四種情況，除了第三種。我們都應該堅持做好間接價值過程。
第一種情況。應對方式是儘可能將簡單/重複的工作交給工具做。例如第一種情況中的重複功能，可以考慮以模板的方式生成，將代碼走查的重點聚焦到相對複雜的流程。
第二種情況。首先就是招聘的時候，用人單位能很好的參與。如果上下游環節也能參與一下就更理想了。當然，每個人加入一個新團隊，都需要一點成長的時間。就個人的體會而言，敏捷團隊運作方式，對個人能力的迅速成長很有幫助。但是需要小心敏捷團隊的人員考評（據說360環評比較好，沒有實際操作過，不做評論）。另外，對於不適合團隊的人員，特別是經過一段時間培養，達不到要求的人員，該剔除還是得剔除，不能手軟。
第三種情況。團隊領導者要擔負更多的責任，將無聊的過程數據對團隊的影響降到最低，做好研發過程中最精華的部分。親，如果你的團隊領導是這樣的，那你就幸福了。
5 對立還是統一
研發過程中，各角色：搞需求的、搞設計的、搞代碼的、搞測試的、搞支持的本是同根生。卻總會有那麼一部分人，相煎的不亦樂乎。在一定規模的公司尤爲突出。
公司大了，一起煮酒論英雄的場景少了，屁股決定腦袋的事情多了。
這事兒，良好的規章制度，清晰的角色分工好像都不太好解決。好像唯有超讚的企業文化，纔是最優解。
回過頭來看。理論上，如果分了這麼多撥人，又有上下游“工序”關係，只要建立好各環節的輸入輸出質量標準即可。
可惜的是：
1） 需求，是自然語義，很難完全精確界定質量。
2） 代碼。代碼質量的評判，從來都是一個一直都存在，從未被解決的課題。
3） 測試。不是所有缺陷，都叫做BUG。只有測試出來的，暴露出來的才叫。有些可能在編碼時就處於潛伏狀態，甚至到產品退出市場可能還是這種狀態。
正因爲如此，爲了進行質量管控，上下游“工序”的兄弟，在企業制度的號召下，某些時候就成了敵人：搞編碼的人，提一堆需求缺陷；搞測試的人，提一堆代碼缺陷。
那這事兒怎麼玩呢？還得靠企業文化。當然，企業文化的背後，如要有給到位的薪水支撐，企業和員工共苦的氛圍。如果有了優秀的企業文化，把研發團隊的各個角色都整到像打了雞血，大家都本着對最終用戶負責的態度，並從這個態度出發，梳理各環節的目標和工作輸出，最終做到各角色其樂融融，也不是難事。（當然，這裏是作者在YY，實際上能做好這一點的，在大公司中屈指可數）
6 結語
在軟件研發管理的實際工作，過去有，現在有，將來也必定會有各種糾結。但是，總有一些企業，可以超脫於這些糾結之外。這些，企業，無論大小，都有一個鮮明的特點，就是外面的人想進去，裏面的人不想出來。如果你的公司具備了這樣的特點，那就請兄臺好好幹吧。