1 前言
由於個人之前的職位是測試開發工程師，所有的需求都是來自內部的，也許是來自你的老大，也許是來自你的同事，所以本篇文章主要講解，當我接到一個需求的時候，我會怎么去做？
由於我不是專門做產品經理或者項目管理，所以下面沒有那么多的專業術語，也許有什么不當的地方，還是希望大家多多指點。
2 職業生涯的五個階段
對於剛從學校步入社會的童鞋們來說，前面的三年是最重要的，也是可塑性最強的黃金時期。而這三年里，一般大家都會經歷以下五個階段：
1> 入行半年內，這個時候一般是打雜的菜鳥，大部分的任務都需要老大那邊經過細分，然后一步步的安排並且分派給你去做；
2> 入行半年后，慢慢的學習並且知道該怎么做，是一個比較優秀的執行者，一般這個時候，老大給你的任務是比較大的，具體的需求了解、任務分解和安排得靠自己；
3> 入行一年后，已經開始能夠自己挖掘需求，自主思考“做不做，做多少，怎么做”，與此同時還會不斷的提高自己的影響力；
4> 入行兩年后，已經能夠獨當一面，並且知道個人的能力是有限的，能夠參與到項目中，並且充分發揮團隊力量，出色的完成任務，並且提高整個團隊的影響力；
5> 入行三年后，能夠開始跟公司比較高層進行交流，能夠知道公司的戰略方向，懂的根據戰略去規划和安排，由於要做的事情太多，會根據價值觀、戰略果斷的放棄很多極具誘惑的事情，做好核心的事情
對於我來說，出來工作已經兩年了，目前處於第三階段，正在努力的提高個人的影響力，對於第四階段，處於知識儲備階段，一方面是還沒有機會給我帶團隊進行實踐，另一方面是因為沒有人能夠給予我指導，只能靠自己去探索，思考和成長。
OK，題外話就不多說了，回歸我們的正題，當老板給你一個需求的時候，你該怎么做？
3 一個需求的奮斗史
3.1 從用戶來，到用戶中去
1> 確認你的目標用戶
首先，我們得區分好客戶和用戶
客戶：一般是購買產品、為產品付錢的人
用戶：真正使用產品的人
舉個例子，QQ的普通用戶你當的不爽，這個時候你會去購買QQ會員，此時你是QQ的用戶，同時也是QQ的客戶；
再舉個例子，你在天貓購買了一部iPhone，這時，你是蘋果的用戶，而天貓是蘋果的客戶。
從例子中，我們可以看出，客戶和用戶可能是同一人，也可能不是同一個人，所以大家一定要區分好這個概念，做到真正的以用戶為中心，為用戶服務！
當然，對於做內部應用，解決業務痛點的我們來說，“從業務中來，到業務中去” 會更加准確。也許對於我們來說，客戶和用戶還是有點抽象，那么我們只要知道，提需求的人，不一定就是這個工具或者系統的用戶，比如提需求的人可能是你的上級，可能是另外一個團隊的上級，但他們只是知道了團隊里面的痛點，向你提出了需求，但他本人卻不是你將要做出來的工具或者系統的用戶，真正的用戶是他們的團隊成員。
2> 了解需求的背景
明確了你的目標用戶以后，你需要開始深入到用戶中，了解這個需求的背景，直有了解需求的背景，你才知道用戶的痛點是什么，需求的本質是什么。
那么我們了解需求背景的方式大概有哪些呢？
a> 對用戶進行訪談：可以先猜想下用戶是怎么想的，怎么做的。然后自己根據這些准備好自己想要了解的，通過跟用戶的訪談，解決自己心中的疑問，更好的了解需求本質
b> 真正的到用戶中，跟着用戶做一次，讓自己也跟着痛一次，
3> 該不該做
了解需求的本質后，我們也知道要解決什么問題了，這個時候我們不應該立馬去做，去幫用戶實現這個功能，如果是對外的項目，我們應該先考慮商業價值，但如果是對內的，我們就應該去考慮業務價值、投入產出比，以此來評估該需求該不該做
4>設定目標、方案、計划
a> 當你了解需求的本質以后，確認可以做以后，你需要根據你了解到的信息去制定一個目標，比如能解決目標就好，又或者，發現你這個東西可以做得更深入一些，不僅僅能夠解決業務當前的痛點，還能順帶解決其他問題，當然啦，這個跟每個人的工作經驗有關。
b> 目標制定好后，你需要制定好可以解決這個問題的方案，一定要記住“聽用戶的但不要照着做”，你可以根據你了解到的，站在用戶的角度去思考，看看有沒有更好的方案
c> 當方案制定好后，你就開始要把你的需求轉換成任務，並且形成計划去執行了，注意還要進行任務分解，這個時候如果你有小伙伴的話，也方便任務分派
5> 設計、開發
完成上面一步后，基本上可以開始設計和開發了，但是不要一下子就去進行敲代碼，可以嘗試按照以下步驟進行：
a> 可以先畫個原圖，或者告訴用戶你“想要做成什么樣子的，怎么做”，必需保證你的想法是用戶認可的
b> 快速實現一個版本，給用戶試用，看是否能夠真正解決問題，快速實現問題並不是說不用考慮質量問題，也並不是說不考慮代碼設計問題，只是這方面不是當前考慮的重點
c> 當發現做的方向符合用戶需求后，開始要注重好質量、設計、效率，跟你一起結伴的同事一起討論，設計，review
d> 開發過程中不斷的跟用戶溝通，擁抱變化
6> 持續交付
在我們實現這個工具或者系統的時候，我們不可能一步到位后再交付給用戶的，一方面是因為這樣子很可能我們花了很長的時間開發，但最終不是用戶想要的，另一方面，往往這種開發模式需要的時間會比預估的長太多。
所以我們需要以可用的最小的功能單位交給用戶，讓他們能夠盡早嘗試，持續交付，這樣子的好處是：
a> 保障我們的前進的方向跟用戶需要的是一致的
b> 逐步的解決用戶的痛點，給用戶的感覺就是你一直在為解決它的問題努力着，避免由於長時間沒有反饋而給用戶遙遙無期的感覺，避免留給用戶響應慢的印象
c> 用戶可以充當你的測試人員，幫你測試一遍，但是這樣不代表着我們可以不管質量，反而自測一定要充分，以最高的質量交付給用戶
注意哦，這里強調的是持續交付。它的意思是：
我們交付出去不代表我們的事情就完成了，我們還需要繼續持續跟進我們的工具、系統的使用情況，同時要主動跟用戶了解使用情況，留意用戶的使用反饋，對我們的工具不斷的改進。接下來就是重復上面的第三到現在的第七步了。
4 結束語
這里花了一些時間進行總結，當一個需求到來的時候，我們應該怎么做，希望能夠給大家一些幫助，同時也是希望能夠得到大家的指點。