簡單談談開發流程和管理中幾個一般性的原則。

?

1.? 前松后緊原則
??? 做事情有時候真的要看好方向。方向錯了，會嚴重影響項目進度和投入產出比，你努力工作的成果也許幾乎無用，這也是很多項目失敗的根本原因之一。所以，負責任的PM們總是小心翼翼地反復評審著需求文檔和設計文檔，因為這是項目或產品成型的前提，是開發的最原始驅動力。從項目時間分配的角度來講，這就存在一個前松后緊原則。多預留點時間在此處要害，總比做完了又推翻來得有余地。不愿意花功夫在這上面，早晚必自食惡果。
??? 由此也衍生出來一個架構設計的行當，它完成系統和平臺選型、總體方案設計、關鍵業務邏輯分析和風險點評估等重方向的工作。然而架構設計不是憑空而來的，它需要長期產品優化和改進積累起來的寶貴經驗，需要迅速搭建模型驗證方案關鍵技術的實施能力。所以一般來講，優秀的架構師首先是優秀的產品優化人員。沒有做過系統的性能優化，你都不好意思說你是架構師。

?

2.? 分離原則
??? 談到性能調優，首先要重視程序結構和業務邏輯，其次才是程序細節。如果程序的架構都有問題，優化不知從何談起。
??? Daemon進程是一種比較普遍的設計，但是也會帶來一些隱患，比如內存泄露的話就會一直泄露，直到系統內存耗盡。解決的辦法之一是分解daemon程序，只將監聽和接收部分留下，繁雜的具體業務處理另由其它程序處理，只在需要時才調用它，用完了馬上銷毀。這是通常說的分離原則應用場景之一。
??? 還有一個結構性的問題也應重視，那就是主機的應用種類。應用不同，決定了性能調整的方向不同；而對于不同的調整方向，調優使用的方法和工具也可能大不相同。比較常見的有兩種典型應用，服務器（server）型和終端（terminal）型。不要迷惑于某些優秀的工具為什么你一直用不上，也許你的環境和資源本就不允許。
??? 回到研發流程管理方面來說，一般的IT研發過程是：需求分析-系統設計-詳細設計-編程實現-單元測試-集成測試-交付使用-產品服務，再加上編程設計與測試的反復迭代。很顯然，研發流程的按步就班本身就是分離原則的一種體現。對某些關鍵步驟的再分解，細化一些業務和分工，跳開傳統PM的一個人一條龍到底的觀念，做出有針對性的部署和處理，會大大地提高研發效率和團隊的創新視野。

??? 分離原則在很多地方在默默地應用著，各有說法。但相信所有的分離，都是為了更好的整合。?

?

3.? 前緊后松原則
??? 如果設計與編程是程序員的主要工作的話，那么接下來的Debug調試（Test測試則重點不同，由Integration Test專業人員完成），也許是產品化過程之中交付成果之前，程序員的臨門一腳了。此步看似簡單，實則暗流涌動。對于一個真正的項目來講，沒有哪份代碼可以直接通過，而是必須經歷一段不輕松的Debug歷程。而且即使交付給Test人員后，反饋回來的必將是一堆問題，仍然要繼續De-bug。有經驗的PM一般將調試與編程的任務時間比例定得很高（2~5），這叫做前緊后松原則。
??? 當然在中國，特殊的發展階段和豐富廉價的人才使得Boss們將Debug時間定得很緊，至于Test反饋問題后的Debug時間一般不在項目規劃內，碼農們只能通過無窮無盡的免費加班來完成。這是閑話，還是少說為妙。

??

????最后簡單說，如果想一個項目成功，請PM們重視需求和調試，而不僅僅是完成編碼，不然害人害己。當然，說說總是容易，而且沒有一成不變的原則，有些具體事務的處理總是相對的。比如模塊和業務分離，在資源相對緊張的情況下，過度的分離也許會拖慢程序的啟動速度。

總結

以上是生活随笔為你收集整理的前松后紧和前紧后松——想起PM的点滴的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。