最近在公司內帶乙個還算較大的專案，目前正處於專案的計畫和文件編寫階段，因為之前都是作為專案組的成員來參加專案，這次是完全自己負責整個專案，所以有一些特別的感想
1.需要全面了解整個團隊的水平
相信每個團隊都一樣，有比較資深的老傢伙，技術資歷比較深，也有些剛畢業不久的實習生，工作1－2年的小生，這次專案裡一開始沒有事先過多考慮到這個問題，雖然在工作量分配時作了一些傾斜－－如比較核心的功能模組還是分配給老人，但是現在感覺下來還是感覺對某幾個新人的工作有些便多，導致這兩天他們在加班搞,感覺有些過意不去－－因為有些東西他們的熟悉程度不是非常深刻，這一點沒有事先考慮清楚，後期會讓幾個老人有重點的關注一下－－不是監視他們，而是幫助他們如何能在壓力下快速的成長起來
－－後續的經驗：
專案開始前pm就要對整個團隊的實力作乙個整體評估，根據每個人的特點去分配不同的任務－－即能讓新人得到成長，又能給團隊帶來最大的價值
2.專案組的成員是否對需求還有疑惑
我們公司的流程是產品經理會發出prd（product requirement document產品需求文件），然後組織會議評審，每個人對需求的理解不一定一致的，有很多細節的東西可能在寫usecase時候甚至是編碼測試時才發現，發現問題的時間點越早，花費的成本就越少，但是並不是每個人都能發現這個問題，有時候prd評審的時候被產品經理忽悠的雲裡霧裡的，似懂非懂，寫uc的時候遇到了問題，如果不主動去問他，很少主動的來暴露問題，這是很可怕的，程式設計師按照自己的理解寫出來了**，結果卻不是產品設計的初衷
－－經驗之談
1）帶著問題去評審。一般會要求產品經理將prd在評審前1－2天發出來，這樣開發同學可以先了解一下大致的東東，把有疑惑的地方記錄下來，然後在評審的時候一併把問題丟擲來，一來問題計較集中，產品方面可以當面解決，另乙個可以做到心中有數，對整個需求有框架的了解
2）積極主動發現問題，解決問題。作開發的同學性格相對悶一些，有了問題不及時去和產品確認，等你問到他有沒有問題的時候才說，這裡那裡可能不是很了解，這是非常不可取的，有了問題一定要第一時間去找相關的人確認掉，解決掉，迷惑的東西越多，後期專案的風險就月大。
3.設計文件什麼時候做？
這次的專案裡幾乎沒有安排大家系統設計的時間，設計和uc的時間是黏在一起的，prd評審過後就uc去了，目前發現這種弱化設計的方式是很有壞處的，對於小的需求的日常來說是可以的，但是對於專案這個環節是不能缺少的，看到專案組的成員在uc時就遇到了一些問題，如資料從**取的，本來以為是簡單的查表得到，但是經過多方糾結以後才發現需要繞n個彎路依賴多個系統才能實現，這些東西其實是需求在uc前去考慮的
－－經驗教訓
系統設計絕不能弱化，特別是專案，需要分配時間來對關鍵的功能點作設計方案出來，然後去評估各種方案的利弊，選擇最優方案，把問題和風險提前化，透明化
4.uc文件的規範是否了解一致？
專案的uc階段後，簡單看了一下各個專案組成員寫的東東，參差不齊，主要有以下幾個問題
1)uc的命名不規範
2)對於uc文件中各個文件塊的功能描述不是很清晰，如有頁面互動部分，業務規則部分，發現很多同學把業務規則的東西寫到頁面互動中去了，分支流和異常流的理解也不一致
3)對業務邏輯描述的不夠清晰完善。我抓了幾個uc然後採用我問你答的方式進行溝通，發現我從當前uc上問到的很多問題在uc中都沒有描述到或者有歧異－－這就給**實現階段埋下了伏筆，uc必須完整的實現prd裡的功能，而且保證產品開發和測試理解的都是一致的
4)uc＝詳細設計
在我們公司內部uc文件的作用被放大化了，要求uc裡必須詳細到每個顯示字段對應到資料庫的哪個字段，問題就是寫文件成本增高了，優勢也很明顯就是可以在寫uc時詳細知道每乙個細節是怎麼實現
－－經驗之談
1)剛開始以這種方式來寫的時候很牴觸，總感覺這個uc文件寫起來怪怪的，uc應該是寫給使用者看的，使用者管你資料庫的哪個表哪個欄位是什麼意思幹嘛？但是基於我們公司目前的現狀，需求方是即懂技術又懂業務的人員，測試人員也需要關心db，所以這種方式還是有意義的
2)uc階段就可以了解每個功能的實現方案，這就極大的降低了**階段帶來的迷惑，還是那句話－盡早發現問題，把問題扼殺在搖籃裡
5.外部溝通
問題：目前公司的現狀是乙個部門作一件事情，我們要作的功能需要其他部門協助才能完成，怎樣驅動其他部門來協作呢
1).產品經理會在專案前和各個部門協調配合人員－－只管圈人，配合的時間點由專案pm來協調完成
這個就對pm有了更高的要求，專業打雜的，到處**找人協調時間點，各個部門的響應不一樣，有的很積極配合，有問必答形的，有的卻愛理不理，有的雖然答應給做，但是優先順序排的卻很低
2).專案過程中的溝通如何高效的完成？
需求階段不可能估測到所有的問題，uc和編碼階段也會不斷的有問題浮現出來，這些問題怎麼解決，何時去解決？
3)怎麼問問題？
看到幾個同學，包括我有時候也是，有問題拿起**一頓說，別的部門有時候並不了解我們的需求，可能我們講了半天，對方還雲裡霧裡的，這種溝通方式是很低效的。
－－經驗之談
1)對於外部的東西，一定盡早的去確認時間點，包括發布時間點，聯調時間點，如果有風險，盡早的暴露出來，如果自己搞不定，找各方的老大協調資源，各方溝通結論性的東西一定要郵件的形式發出來，用於存檔(證據~~)
2)問別人問題前先把問題考慮清楚，如果有多個問題最好1，2，3簡單羅列下，用簡潔的形式給自己默默的解釋一遍，然後再去問
3)問別人之前自己考慮一下對方可能怎麼答覆，我們的目標是怎樣的，如他人無法滿足我們需求的時候是否然他提供其他方案或者其他介面人，自己要準備多重方案，對方的時間也是有限的，一次能把所有的問題都搞清楚是最好的了
教訓：這次專案目前有幾個外部時間點還沒有最終確認下來，所以需要加油了~~
6.需求的取捨
產品有時候會生活在共產主義社會裡，呼裡哇啦大講一坨，但是作為專案的管理人員一定要注意，有時候乙個很小的功能就可能導致系統大篇幅的改動，這個時候就要從需求的優先順序，實現的成本，系統的可維護性來考慮了，對於那些非主流程的功能點如果改動量很大，要花費大量的人力物力去實現，而且這個功能不見得就是使用者需要的，這個時候就需要和需求方來確認，是否要保留這個功能或者其他備選方案來實現
專案剛開始沒幾天，一切也都在摸索中，過程中也接到不少外部同學的挑戰，這個也正常，有人願意來幫你指出錯誤，這是個好事情，這樣成長的更快，問題只會越來越少的，加油
做好專案溝通計畫
回想一下你所經歷的專案，有沒有出現過以下這樣的情況 客戶在檢查專案階段成果時，指出曾經要求的某個產品特性沒有包含在其中，並且抱怨說早就以口頭的方式反映給了專案組的成員，糟糕的是作為專案經理的你卻一無所知，而那位成員解釋說把這點忘記了 或者，你手下的程式設計師在設計評審時描述了他所負責的模組架構，然而...
專案前期需求 1
專案前期需求工作首先應該是風險導向的，即 的風險最大就先從那裡下手 1 必不可少的基礎工作 客戶組織架構和使用者代表的了解。術語叫專案干係人或專案涉眾 應獲得組織架構圖 各部門的業務職責 各部門的行政隸屬關係 各部門的業務領導關係 各部門的主要流程角色 主要使用者的姓名 年齡 性別 職務 業務職責 ...
專案工作日誌（1）
今天清晨坐福州至南昌的火車抵達南昌，雖然走過很多省會城市，南昌我還是第一次來。下了火車以後隨同事打車到了住處，我還是大吃了一驚，我們公司駐南昌辦事處選擇的是南昌最好的乙個住宅小區，到達駐點的20層樓，極目眺望，風景盡收眼底，一種不錯的好心情。八點過後南昌駐點的一位小姑娘帶了早餐進來，一頓南昌早餐就展...