TomWang的部落格

在軟體開發中，需求搞不清楚的狀況是很常見
可能一開始談都好像談得好好的，把談的結果稍微弄出一點出來才發現完全不對
然後就要一直改改改

1.撰寫出良好的需求文件，給提出需求者確認後，然後再寫出詳細的SPEC讓工程師開發
2.先寫簡單且關鍵的需求(像用user story)，然後讓工程師一直找提出需求的人確認
3.用由上而下的開發，先做出雛形系統，ok後再往下做

寫出詳盡的系統文件是件很花時間的事情，過程可能花好幾天的時間但是工程師可能花不到半天就做完了
(因為寫規格時可能要一直花時間跟提出需求的人玩鬼打牆遊戲，工程師不用玩所以很快)
如果採取user story的話，工程師需要花較多時間在跟提出需求的人溝通，而不用像第一種一樣單純的依照規格開發即可
由上而下的方式可以和第二種合用，雖然我這樣開發都沒啥效果，原因是決定是否符合需求的人都不想花時間看

不管哪種做法，關鍵都在需要溝通，但不是每個決定需求的人都方便一直溝通的
這部分牽涉的層級可能會很高，正常不會是一個程式設計師或系統分析師能控制的
提出需求者對於溝通最容易產生反感的原因會是:
1.要花時間
2.要負責
因為提出需求者平常都會有很多事情要忙，所以不想花太多時間在上頭。他也未必想為自己說過的話負責，這可能導致無限的開會，直到某一方願意屈服(例如即使規格還沒確認，但因為時間來不及就先做了)
當然，也可能是要做需求訪談的人有問題，因為很忙，所以不想花太多時間了解需求...不一定是提出需求者的問題

如果能找出問題根源，並且面對的話，那還有解決機會
但如果根源是不能說的秘密，那問題很可能就一直存在下去
(你相信放棄治療就會病痛自己消失嗎?感冒可能會，其他疾病不一定)