???? 說老實話，我都不知道什么算是大型項目經(jīng)驗，我也不知道，那些所謂要求有大型項目經(jīng)驗的公司，在做多大的項目，有多NB，但我并不以做過大項目為榮，我這幾年的項目經(jīng)驗告訴我，團(tuán)隊不在于大，在于精，我經(jīng)歷過20人的團(tuán)隊，也有60人的團(tuán)隊，我覺得這樣的項目要做好以下的幾點：
???? 1.項目團(tuán)隊構(gòu)建前，組織架構(gòu)要精細(xì)考量
?????? 各個關(guān)鍵角色的能力有與角色職責(zé)相適應(yīng)，越向上，能力要足夠的全面，要足夠的強(qiáng)勢，這樣才能層層推動。
?????? 上至CTO，GM，下至PM，DBA，TM，要能夠撐得住，靠一個NB的PM，是絕對撐不住的，俺經(jīng)歷過一個60人的項目，4個PM，一個GM，一個GM assistant，結(jié)果是GM，天天躲在自己的辦公室里，發(fā)email, 以為自己是船長，吹個口哨，大家都齊心協(xié)力的向前劃了，結(jié)果是今天向東，明天向西，每次開會，亂成一團(tuán)，一幫SB PM，滿口單元測試，閉口敏捷，開口迭代，誰也不服氣誰。
???? 2. 避免跟著感覺走，
??????? 其實國內(nèi)很多軟件公司都一樣，越向上的領(lǐng)導(dǎo)，技術(shù)層面越來越薄弱，即使一些曾經(jīng)是大N的技術(shù)人員走上了CTO的崗位，但也會逐漸喪失掉技術(shù)的敏感度，很多PM都很少寫程序，何況CTO、GM？估計每天的時間都浪費(fèi)在回復(fù)郵件，開會，評審，會客之類的所謂的很虛的管理之上。
?????? 這樣造成的結(jié)果，就是掌控力度，其實是越來越弱，在用人，更是做不到知人善任，對于不懂技術(shù)的上領(lǐng)導(dǎo)來說，一頭豬和一個高手，是沒有什么區(qū)別的，只能跟著感覺走，對下邊的一些人會特別的依賴，當(dāng)下面的PM發(fā)生爭論時，也搞球不清楚，那個SB說的對，那個SB越的有道理。
?????? 但做人要對得起良心，作為一線的PM，要相對虛心，自己沒有經(jīng)驗的，從書上學(xué)來的，不要輕易亂用，不要拿別人當(dāng)實驗品，更不能現(xiàn)學(xué)現(xiàn)賣，欺騙不懂技術(shù)的上領(lǐng)導(dǎo)，有的時候，也是沒有辦法，會叫的孩子有奶吃，也要講究策略。
????
???? 3. 溝通與協(xié)作
??????? 作為PM向上的領(lǐng)導(dǎo)，有的時候，你感覺自己好像都在天天開會，但有的會，就開的很好，起到了事半功倍的效果，有的會，就開的很糟糕，不僅得罪人，還吃力不討好，在溝通與協(xié)作能力方面，作為稍大的項目以上，PM是必須要把握尺寸的，我見很多囂張的PM，說話節(jié)奏快，語氣比較強(qiáng)勢，經(jīng)常批評其它的PM,結(jié)果在OP會上，很容易遭到攻擊，大家的級別和能力都差不多，誰也不會賣你的賬，更不會給你幫助和施以援手了。有的PM就比較圓滑，在會上很少發(fā)言，聽的比較多，經(jīng)常說的話就是：是的，對，OK，沒問題，盡量吧，等等話語，這樣的PM就很少被攻擊，也更容易得到幫助。
?????? 其實，大家經(jīng)常解釋時說的一句話："我也是就事論事"，但在OP這樣比較高層面的會上，還是盡量不要這樣搞，就事論事，可以在下面一對一的搞，不要動不動都拿到OP會上搞，得不到別人的協(xié)作，要盡量的溝通，不能動不動，就上報給CTO之類的領(lǐng)導(dǎo)，這樣會更糟糕。因為CTO可能會不能罩你一輩子。也并不是每個CTO都是清明的領(lǐng)導(dǎo)。
?????? ?email有email的用處，但它不是command, 也不是communication, 從你的坐位上站起來，在公司內(nèi)走一走，要比一個email強(qiáng)萬倍。
???? 4.架構(gòu)師
???????
??????? 架構(gòu)設(shè)計是個很復(fù)雜的東東，但如何選擇合適的架構(gòu)師，如何進(jìn)行最終的決策，很多公司做的并不好，很多領(lǐng)導(dǎo)在架構(gòu)師的任命上，很容易草率，說你行，你就行，說你不行，你就不行。于是一些不負(fù)責(zé)的、半桶水的人，就在領(lǐng)導(dǎo)的指示下，走上前臺，將項目推向死亡之谷。
??????? 架構(gòu)的設(shè)計依賴你全生命周期項目經(jīng)驗的積累，格局要大，依賴于你對技術(shù)的敏感度，技術(shù)上比較全面，就像參謀長一樣，從軍校畢業(yè)的，就容易紙上談兵，比較激進(jìn)，從士兵，一路殺過來的，就比較慎重，但如果不愛學(xué)習(xí)上進(jìn)，則又屬于野路子，做又不究其理，不善于抽象，不講究方法論。
??????? 總之，在這點上，能找一個NB的，又有理性的，不太容易。
???? 5. 文檔
???????
???????? 項目組與項目組之間，項目組與客戶，項目組與測試部門，項目組與評審組之間的交互，有很重要的部分就是文檔。
???????? 文檔這個東東，說實在話，就是一個雞肋，但不要又不行，客戶要簽字，領(lǐng)導(dǎo)要評審，測試組要拿它寫測試用例，但對于項目組來說，天天在那咬文嚼字的，實在是沒有意義的，俺在原型分析與用例驅(qū)動上探索了很長時間，雖然用例直接了當(dāng)，且很容易轉(zhuǎn)化成功能書、測試用例，但工作量，比之傳統(tǒng)的需求文檔說明書，有過之而無不及，在時間緊的時候，也很難保持實時一致。
??????? 我目前的做法是原型必須與客戶的需求保持一致，基于靜態(tài)頁面的原型，修改起來，速度很快，且更容易被客戶、程度員、設(shè)計者所接收，長篇大論，動不動上百頁的需求文檔，你喊破喉嚨，也沒有人看。
?????? 文檔，有專人寫，專人維護(hù)，但會比較滯后，只要能夠保證在提交測試部門時，有一份完整的文檔，這樣測試部門，也更方便測試。培訓(xùn)的時間也少。
??????? 在評審時，可以評審，但具體文檔要拖一拖了。
??????? 客戶簽字，就以原型為主了。文檔，它也不看。如果動真格，要看，那就抽時間趕出來。
??????? 當(dāng)然對于接口等技術(shù)文檔，還是必須要的。
???????? (未完待續(xù))
??????
????
????
?