在進入到開發成面的東西之前我想先聊聊產品探索，也就是軟體要做哪些功能

軟體因需求而生，因此開發之前一定要將需求搞清楚，而把需求搞清楚這件事本身其實是需要一點技巧的，很多時候連提出需求的人都不知道自己想要的是什麼，也不知道軟體可以怎麼解決他們的問題。

造成這種情況的原因可能很複雜，處理起來也很棘手，不過問題終究要被解決，面對這樣的囧境身為工程師的我們該如何處理呢？

現在的科技日新月異，技術成長速度之快，很多使用者覺看似自然的功能，可能對於我們來說並不容易。在釐清需求的當下，事實上是工程師單方面的在接收需求方的需求(問題)，使用者並不了解工程師會遇到什麼問題，然而有趣的是，工程師天生就能夠把需求編譯成系統架構與程式，幾乎在聽到一個需求的當下幾乎能夠瞬間知道成本(可行性)，當成本很高的時候，造成即便當下沒有打斷需求方說話，其實也已經沒再仔細聽需求(問題)。

會有這樣的問題產生，主要是因為開發者就是實作的人(承擔成本的人)，也難怪會出現這樣的情況，如果你也有類似的情況，可以試著先把預估的成本放一邊不要一直想，在與需求方溝通時，我們要專注的應該是使用者們遇到的問題，至於他們所提出的解決方案，其實是他們覺得的解答，當需求方提出的方案難以實現時，工程師必須與需求方耐心的討論直到取得共識。

所謂的取得共識並不是雙方覺得好就結束的，而是在此之後將由專人將共識內容記錄起來，且雙方讀過後覺得沒有問題才算告一個段落。

補充1：紀錄共識的專人最好是做事的人，原因是這個人對需求的理解必須完全與需求方相同。

補充2：需求方指的是開發者以外的所有人，他們可能是老闆、業務、專案經理 ….。

軟體只是問題解決方案的一種，有些時候使用者的需求可能不需要透過軟體來解決而是他們流程上、做法上本身就有問題，這種情況相當依賴與會者們的洞察能力，盲目地接收、拒絕需求都是不對的。