老板给你一个需求,你该怎么做?

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 结束语

这里花了一些时间进行总结,当一个需求到来的时候,我们应该怎么做,希望能够给大家一些帮助,同时也是希望能够得到大家的指点。

 

posted @ 2016-06-23 09:33 小学徒V 阅读(...) 评论(...) 编辑 收藏