大型軟件開發(fā)心得
對于一個(gè)耗時(shí)較長的項(xiàng)目來說，這種情況難以避免，事出原因私自總結(jié)有三：
a、嚴(yán)重體驗(yàn)性問題：例如某個(gè)流程遭到大量用戶的不滿，為防止用戶流失，不得不做臨時(shí)調(diào)整，而倒霉的是，你也在用這個(gè)流程。
b、相關(guān)項(xiàng)目的影響：包括并行項(xiàng)目和新項(xiàng)目。例如你的同事在設(shè)計(jì)另一個(gè)產(chǎn)品，你們的產(chǎn)品相互牽扯較多，所以需求分析時(shí)做過很多溝通，但有一天，同事告訴你，ta的一個(gè)需求做臨時(shí)調(diào)整了會(huì)影響到你，怎么辦？
c、老板的突然決定：不舉例。
最終的解決方法不外乎三種：立即調(diào)整、延期調(diào)整、不調(diào)整。個(gè)人的處理原則一般是對a種情況進(jìn)行立即調(diào)整，對b、c情況討論并選擇性延期。
為什么這么做呢？a情況是必須要改的，時(shí)間早晚問題，長痛不如短痛，b、c兩種情況必須坐下來細(xì)細(xì)討論。需了解這個(gè)需求為什么要改？是長期對策還是臨時(shí)決定？能否延期，記錄需求等下一版本再開發(fā)？如果b、c情況提出來的需求沒過兩天又有改變，那與你配合的前端和程序員也太沒有安全感了。
這個(gè)時(shí)代能耐心閱讀完枚漢字的人越來越少，較大型項(xiàng)目的產(chǎn)品工作心得[下]未完待續(xù)，歡迎交流……
2、需求變更
承上，需求變更是每個(gè)程序員、產(chǎn)品經(jīng)理、設(shè)計(jì)師等都會(huì)遇到的情況。產(chǎn)品經(jīng)理不是神，項(xiàng)目組也不可能是開了無敵狀態(tài)抵擋任何外界的影響。
當(dāng)遇到不得不變更需求的時(shí)候，產(chǎn)品經(jīng)理應(yīng)該怎樣處理呢？下面是個(gè)人的四條建議：
a、積極處理。往往，當(dāng)一個(gè)設(shè)計(jì)愈是趨于完成，人們愈是傾向于局部調(diào)整，而不是做重新設(shè)計(jì)。當(dāng)一個(gè)需求因?yàn)楸娝苤脑虿坏貌徽{(diào)整的時(shí)候，作為產(chǎn)品經(jīng)理需要做的第一件事便是積極面對問題，積極處理。
項(xiàng)目開發(fā)往往是一個(gè)緊張的過程，每半天甚至每幾個(gè)小時(shí)就有若干個(gè)功能點(diǎn)開發(fā)完成，當(dāng)一個(gè)需求變更傳達(dá)出現(xiàn)“延遲”，這個(gè)變更對項(xiàng)目的正常進(jìn)程的“破壞力”就會(huì)更大一些。
b、保持溝通。“說話容易，溝通很難。很多事除非對方自己想明白，勸是沒有用的。所以，很多時(shí)候，溝通是個(gè)自己掙扎的過程”這話沒錯(cuò)。需求變更直接會(huì)影響到下一道工序，產(chǎn)品經(jīng)理需要將需求變更的細(xì)節(jié)和原因傳達(dá)給相關(guān)人員，包括視覺、前端、程序、測試等。
這是很多產(chǎn)品經(jīng)理表示非常痛苦的過程，因?yàn)榭赡軙?huì)遭到數(shù)落和冷眼，日本有一個(gè)禮儀原則是“不要給別人添麻煩”，但是在項(xiàng)目中，這不可避免。
個(gè)人認(rèn)為所有溝通的障礙都源于思想的不統(tǒng)一，如果讓大家覺得這個(gè)需求修改是在浪費(fèi)時(shí)間，那么溝通上的不暢快在所難免。項(xiàng)目不是這樣算的，需求既然更改一定有所目的，產(chǎn)品經(jīng)理需要將這個(gè)原因講明白，不做修改或節(jié)約溝通時(shí)間導(dǎo)致的返工，后果往往更嚴(yán)重。