接觸項目管理2年時間，項目經理小P以前被給定的項目都是已經有明確團隊組成，明確需求，明確目標的項目，重點關注的是如何更好的去執行，把目標保質保量的按時完成。所以對于需求的確定過程，團隊的建立過程都沒什么概念也沒有太多的思考。當然也怕自己被給定那些什么都不確定的項目去跟進。但是怕什么就來什么。突然有一天他的老大找到他說：小P啊，老板X有一個新的項目M要做，半年內要完成上線，你去幫他跟進一下這個項目吧。
老板只是說有個項目要跟進，實際上卻沒有給資源。小P的第一步就是去要資源。但是該要多少呢？小P不熟悉這類產品，沒法給出預估。于是他找到了老板手下一個資深的開發人員，經過與這名開發人員的溝通之后，基本上確定了交互，開發，測試等資源的數量。接下來就是要資源了。這個項目是老板親自發起的，理所當然問老板要資源了。但是老板又不直接帶交互，開發和測試人員。于是小P召集了老板，交互負責人，開發負責人，測試負責人一起碰頭明確項目的目標和上線時間以及關于資源分配的問題。老大向大家介紹了一下他想做這個項目的目的，并且表示項目要在6個月后交付上線，讓各負責人提供資源上的支持，當場大家都承諾會提供資源，并且確定了產品經理，但是對于資源的到位時間都無法保證。不過總算是有對應的責任人了，為后續的工作開展奠定了基礎。
解讀
其實在要資源之前，小P等了一個禮拜，因為他覺得老板既然要做事情，總得給資源吧。但是一個禮拜過去了，老大什么動靜也沒有。小P只好硬著頭皮主動去向老板要資源。其實很多時候老板是不會主動來問你要不要幫助的，只有自己拿著需求和依據去找老板，老板才會給予支持。
自我授權
小P是從自己老大處接到項目的，雖然是經過老板默許的，但是并沒有在公開場合宣布他成為這個項目的項目經理，其他人并不了解他的角色。在最前期跟進的過程中，每一次跟新的團隊成員接觸都要向其解釋一下自己的角色。小P總覺得很別扭，因為沒被公開授權，如果一直以一個不明不白的身份跟進項目，不僅給團隊成員帶來困惑，也不利于開展后續的項目管理工作。小P左思右想，覺得不能繼續做“黑戶”呀。老板不授權，那是不是得自己找機會跟大家說明自己是經過老板默許的，而且必須是在老板也在場的情況下。于是這就有了小P自我授權的過程。那天，小P借著前期的一次已到位人員碰頭會上向大家做了自我介紹并說明了自己以后會跟進這個項目。他說完，老板也應和到：小P后續會幫忙跟進這個項目，大家要全力配合。大功告成，從此告別“黑戶”！
解讀
跟要資源一樣，老板真的不會管你缺什么，我們必須自己去爭取自己需要的東西。
需求可視化
過去小P在跟進項目時，對于需求制定的過程跟進的比較少，因為需求一般是產品經理或者策劃人員，一兩個人的工作，只是讓他們給定一個預期時間，到了時間去跟進一下是否完成就行了。但是這樣的后果是，到了時間點，需求制定人員總會說：還沒做好，還在想。然后時間就會一拖再拖，最終將開發和測試的時間給壓縮了，有的時候甚至會引起開發人員的不滿。這一次，小P覺得是不是需要做點什么來幫助改善這種情況。于是定了每周一次的需求溝通會，各個角色都會參與進來，不管需求進行到了什么程度，有多少內容就看多少，大家群策群力來做需求。
解讀
當一件事情被提上議程，它的進度往往會比較快。想象一下，讓你有兩件事情同時在做，有一件事情需要每周給大家展示你的進度，而另外一件只需要在截止日期前拿出來成果就行，當你的時間不夠用的情況下，你會先做哪一件？另外要是每周團隊一起來看和討論需求，這會給需求人員更多思路，更及時的調整需求。
固定溝通渠道
項目前期，主要是需求制定和一些準備工作，貌似沒什么好溝通的。小P曾經也是這么以為的，直到需求第一部分發出來以后。需求發出來后，沒有人回郵件提出自己的意見和疑問，小P以為這個需求會很順利的走下去。但是那天小P無意間和團隊成員聊起需求，那個成員馬上提出來自己的異議，巴拉巴拉說了一通。這個時候小P才意識到，其實是需要給團隊一個溝通的機會來聊這些東西。于是小P立馬召集了一次會議，想不到不止這一位成員有異議，其他成員也有不少疑問和建議。隨后團隊就固定了每周一次的周會習慣。
解讀
有的時候你不去問，別人是不會主動來告訴你他的想法的。就例如小P需要的需求問題，其實需求是需求人員own的，其他人自然不會主動的來“指手畫腳”，一方面是怕“得罪”了需求人員，另一方面，不是自己的東西，他們也懶得去提意見，做的不好也不是自己的責任。周會其實就是給了他們一個溝通的平臺，每周給團隊成員一個機會來相互溝通。也許這也是那些周會，月會，雙月會等看似形式化的東西存在的意義。
項目的啟動階段，由于需求和計劃都還沒定，有的時候甚至連團隊都沒定，自然它的不確定性要比其他階段大很多。一些項目經理可能對這個過程跟進的會比較少，但是也并不表示這個階段不需要項目管理。以上幾點小P的經驗談希望在這方面能給大家帶來更多的思路。
(本文于2016-12-09首次發布)
