專案經理修鍊之道(1) — 給軟體開發建模

#成為專案經理是需要積累的，如果你想快，但不想付出，那求神拜佛比較好。

#這系列文章是寫給想成為專案經理，但又願意努力的人的。

當我們開發軟體的時候，很多人知道要為目標軟體建模，好開發需求。

而成為專案經理自身也是一種需求，為進一步開發其關鍵點，事實上也需要建模---為軟體開發自身建模。

專案經理更類似帥才，單項未必是最優的，但在開發軟體時必須統籌全域。

而統籌全域的前提則是對軟體開發自身形成了自己的想法，自己的道，這裡的“道”，即是屬於你自己的軟體開發模型。

讓我們從最簡單的開始。

軟體項目的基本輸入是：人，需求和工具。

其中人是團隊成員，需求是原始需求，工具則是Visual Studio這樣的東西。

這三者不是不可改變，但在限定時空背景下，選擇有限，因此認為他們是一種輸入。

與軟體構建相關聯的主要手段有：管理，流程，估算，開發模型（瀑布，迭代），需求開發，設計編碼，測試

軟體項目的輸出是：軟體產品，軟體產品可以用功能和非功能兩個品質維度進行度量。

而從輸入轉向輸出的過程中則受三個維度因數影響：

商業因素，項目政治因素，技術因素。

商業因素是指和賺錢相關的事。比如：一個需求可能做的很好，但最終被取消了，因為準備在下一個版本中放出來。

項目政治是指和人情有關的東西。比如：A和B就可能有點個人恩怨，沒法合作，但偏偏項目有同時需要這兩個人。

技術因素則是指各個環節的內在合理性。比如：設計就應該符合高內聚，低耦合的原則。

單純的任何一個維度都不足以保證項目的成功，都只是一種籌碼。

你手裡的籌碼越多，天平越向勝利這一端傾斜。傾斜到一定程度後，結局出現，或贏或輸。

上面的各個因素還可以進一步細分，比如管理又可以分為：管人，管事，管物。

其中管人最重要，所以所謂管理項目，首先是管人，人管不好，別的是扯淡。

假如隊伍中沒一個人有基本的責任感，那麼即使把PMBOK，CMMI倒背如流，項目該失敗，還是失敗。

這是後話，這次不提。

如果想成為專案經理，首先要形成一個屬於自己的，覆蓋軟體開發各個領域的模型。

並給出一個屬於自己的，對模型中每個角色的定位。

相信專案經理每天只要喝喝咖啡，不需要懂什麼就可以了，就和相信趙括同學能打好仗一樣，是危險的。

上面的模型遠不完善，但故事已經很長，因此說修鍊這事需要點耐心和積累。

眼下似乎沒有把軟體開發關聯要素作為一個整體進行考察，協助每個人形成自己的“道”的書。

更多的書，強調的是某個單獨的維度：物件導向，程式設計語言，設計模式，敏捷，種種開發平台等等。

事實上在項目面前，所有這些都只是籌碼，在不違反法律和社會道義的前提下，做項目本就應該“不擇手段”。

但只有形成了自己的道，才能很好的駕馭這些手段，一旦反過來被這些東西所駕馭，那就容易偏狹。

------------------------------------------------------------------------------------------------------------------------------------

理想流 + 軟體 = 《完美軟體開發：方法與邏輯》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和邏輯推演本質，追求真理。