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 结束语
这里花了一些时间进行总结，当一个需求到来的时候，我们应该怎么做，希望能够给大家一些帮助，同时也是希望能够得到大家的指点。