項目管理筆記-開發的自我修養

1.是否要接需求的問題
咱們的測試階段分爲測試環境\線上環境\bugbash三個
原則上來說在測試環境的測試階段能夠在評估工做量以後適當修改需求,後兩個階段不能修改需求.
a 視覺由於很難在第一階段介入,比較特殊.能夠容許在第二三階段提出修改.若是要進行視覺微調,視覺須要單獨和開發商量,開發修改也必須以不影響進度爲準(不由於需求變動而減小正常開發任務).
b 邏輯的問題請策劃在設計時想清楚,或在第一階段時和開發溝通,提出修改.
c 非策劃和視覺直接提出的需求所有拒絕,需經過前二者來提出

2.需求確認的問題

a 負責人制度
每一個版本設立一個策劃負責人(屬於策劃組成員),任何在開發\測試階段對需求的不瞭解都向他詢問.在討論過程當中擁有對策劃案的最終決定權.

b 需求確認
若是交互確認階段沒涉及的細節,開發人員不明確的,請在實際開發前主動找負責人詢問.

若是開發階段看錯交互稿,或者沒有主動找負責人繼續明確(需求確認),致使到測試階段時發現所作的內容和策劃想法不一致,開發人員承擔所有責任.若是常常發生此狀況則對相應開發提出批評.

開發在需求確認過程當中,一些複雜邏輯討論須要叫上測試同窗.
簡單邏輯能夠和策劃討論完後通知測試同窗.
討論完畢後最好在qq上和策劃再次發一遍討論結果.這是開發保護本身權益的最好辦法,防止策劃賴帳:)

c 砍需求的意識
這是更高級的開發自我修養.
當認爲某個需求很難實現的時候,不悶頭實現,首先想到去和策劃再次確認.由於策劃可能並不瞭解該邏輯的實現成本,致使提需求的時候沒有考慮最高的性價比.開發能夠提出一個性價比更高的方案.這要求開發看待需求不單單是一個任務,而是策劃在需求背後的思考,背後爲了解決的問題.