一個研發工程師眼中的專案管理

一個研發工程師眼中的專案管理

我是一名研發工程師，在專案裡，只要有明確的需求，我就可以開展工作，並在規定的時間完成，也許我加了一週的班，也許我只花了幾個小時，但無所謂，最終我還是把東西交給了專案經理，一切都很簡單，直到最近，我有機會做了一些專案管理的工作。

一份不會更改的專案計劃？

作為一名研發，我希望專案有一個明確的不會改變的計劃，我會關注我所負責的那部分的里程碑並安排時間，但如果你告訴我一個月的工作量要在兩週內完成，那就意味著用降低程式碼質量的代價去縮短開發時間，同時其他工作安排也必將受到影響，我將會變得很不開心。

理所當然，在我所負責專案的初期，我希望能制定出一份不會變更的計劃，設想所有的工作都將按照計劃去進行，但很快我就意識到我錯了。 我沒有辦法制定第二個月的工作計劃，沒錯，從今天開始的這個月，有許多事情已經是基本確定的，尤其是在前兩週，我有信心可以讓專案按照我的計劃去運作，兩週之後我雖然不太確定，但大體上偏差不會太大，而在一個月之後，我已經很難去估計了，因為可以影響到進度的因素太多了。例如客戶需求的變更，物料不齊，人員問題等等。

所以不會更改的專案計劃根本不存在。

也許並不全面，但下面是我總結出的幾條經驗：

1. 確定專案比較重要的里程碑，在任何情況下都應該避免推遲
2. 制定計劃時前細後粗
3. 週期性的review並按照實際情況進行調整，避免計劃成為擺設

他不肯給我幹活！

一個研發同時在幾個專案組裡是一件很平常的事，除此之外可能還有一些自身所處的部門的工作需要去完成，這個時候優先順序就成了問題。

例如你給你的專案成員A安排了工作，但當A臨時有了優先順序更高的工作你的專案工作就會受到影響，尤其是在序列開發的情況下會變得更糟糕，因為所有後面的工作都依賴於A。我恰巧就遇到了這樣的問題，所有的人都在等他，而他告訴我有其他的事情要忙，這讓我很惱火，他不肯幹我的活，但當事情過去後，我想那也許不是他的錯，我本該有機會避免這樣的情況發生，為此我總結了如下幾點：

1. 讓專案成員的直接領導知道你的在什麼時間要佔用他，這樣即使他臨時有了其他工作，領導去協調其他的人力可能比專案經理要更容易
2. 獲取專案成員的承諾，他承諾給你，很大程度上他就會想辦法去完成
3. 明白自己所需要的專案成員所具備的技能，假如真的需要，這有助於找到可以替代的人

客戶根本不知道他想要什麼！

客戶根本不知道他想要什麼，這種情況時有發生，雖然你認為已經確認了需求，客戶可能根本沒明白他所確認的地方會影響到什麼。

做研發時我可能會覺得這樣的客戶很蠢，雖然很不應該。我習慣於從技術的角度去思考，去解決問題，大部分時候，工作的內容已經拆解好，我思考的是如何去實現。而作為專案經理（也許同時也是系統工程師）時，我需要與客戶交涉，什麼要做，什麼不做，做成什麼樣子，而單純從技術方面已經不能給我一個很好的答案，我需要從客戶的角度去看問題，去分析他為什麼需要我這麼做， 這麼做為他帶來的好處是什麼？
從技術到客戶的需求，有時候這個轉變很難。

假如你所處的公司很強勢，是你提供什麼客戶就接受什麼的模式，那這種客戶一點也不可怕，但假如情況恰恰相反，那就要小心了。

這樣的客戶也可以分為幾類：
1. 這個東西我不懂，但好用就好，你怎麼做我不關心
2. 這個東西我不懂，聽你講了之後好像明白了一些，但好用就可以
3. 這個東西我不懂，聽你講了之後好像明白了一些，那你為什麼不...這個地方可不可以....，然後需求悄悄的變的不一樣了

大家當然都希望遇到前兩種，但遇到第三種怎麼辦？

假如這個專案本身就是個政治任務，那基本沒得選，客戶要求什麼就是什麼。

如果還有討價還價的餘地：
1. 客戶要求合理，且工作量不大那就滿足客戶的需求
2. 客戶要求合理，但工作量很大，那需要告訴客戶這與前期確認的需求不符，屬於變更，可能對專案進度造成影響，需要雙方確認
3. 客戶要求不合理，應該更深層次的瞭解客戶提出這一需求的原因，從客戶的角度向他解釋，為何這個要求是不合理的

最後

實際上專案管理本身理論內容就很多，與實際的專案結合起來更是千差萬別，以上只是一些個人的見解和想法，在我看來，雖然專案管理並不適合所有的研發人員，但如果能瞭解專案經理每天都在關注些什麼對工作還是很有幫助的。