一、接需求

现在我们在接到一个需求后，先不要急于了解需求具体要做什么要改什么，要先了解了解需求前提，这个需求提出的原因，为什么会有这个需求，为了解决什么样的问题，不解决会有什么后果，解决了会带来什么好处，需要多少代价解决，把需求要解决的问题拿来作为以后项目实施的检验物，在具体做的时候多想一想这样做是否真的能解决问题，项目发布后也可以拿来做结果的验证，通过项目是否真的解决了这个问题。

然后去仔细了解项目/需求具体要做些啥，需求所涉及到的改动范围，涉及到的功能点，针对每一个改动点做细化，深入了解其骨髓。例如：在help改版需求里有一个要增加help搜索功能的改动点，表面上看起来很简单，只要在search框上添加一个help下拉菜单就可以了，实际实现这个改动并不简单，首先我们的help detail数据跟news数据一样，都是通过news后台输入的，如果用户在help里用search,通过什么样的方式过滤掉news 而只调help的数据，如果用户在community里用search来搜news,如果他用的词是news和help交叉的词汇搜索，会把news和help一并搜出来，这时候是否要过滤掉help，如果过滤是否技术可行，投入成本如何，如果不过滤那是否要在前台展示层面做区分。这些问题只有做了深入了解并加以解决，需求才能实施顺利。

二、出方案

在仔细了解过需求后，下面就是出方案了，在具体做方案前，先做一个前期的research,这个可长可短，根据项目实际情况而定。但还是要有的，有必要花一些时间去看一些同类网站同类产品做为参考，可以扩展自己的思路。也能为自己穷举方案提供借鉴。

具体出方案要做到全面，之前做需求出方案往往只出个首页，里面页面认为简单就基本省略了，其实线框方案出全面，有两个好处。一，对自己来讲，有利于将自己脑子里想的东西输理一遍形成于纸上，从而让自己的观察角度放在一个频道整体去看，而不是仅仅在做一个首页的改版；其二，对于线框图方案确认后做精确化时间预估时，为前端估资源提供一个明确的依据，在help项目里这点上其实是做的不好的，help基本上是只出了2种状态的 help首页，里面的页面并没有出最终版的线框图，导致后来新前端进来，对要做的工作是不清楚的，也就没有办法做出资源评估。当然最后的解决办法是只让新前端评估和制作首页的部分，其他的页面是只存在在自己脑子里的东西，就只有自己清楚了，这部分工作是只有自己去搞定了。

三、制定可执行时间计划表

方案确认后，根据方案将需求进行拆分，分解出项目/需求各节点/里程碑，拆分的越精细项目就越可控。需要考虑的是每个节点所需的参与方及具体参与时间，在这个节点上需要协调的因素，然后就到项目中的执行了。

四、项目中的执行

在这一阶段就是去执行你的时间计划表了。逐一对项目各节点进行把控。就像安装windows的进度表，整体进度拆分成若干段逐段完成，控制住了这些节点/里程碑，也就控制了整个项目。要是真的在这中间有什么问题发生，也能清晰的看见是发生在项目的哪个环节，从而方便我们后续分析跟进，找出问题原因并解决。

五、发布后的总结，后期数据检验

项目发布后，看看项目进度表，针对项目各环节里出现的问题，想一想下次如何改进，写项目心得，将体会和感受提炼出来，这样才是自己的。

后期通过数据采集，去检验项目之前制定的目标是否达到了，要解决的问题是否真的解决了，如果没有，需要进一步去分析原因，总结经验。

附注团队里其他同学给的建议的一些节选：

From Heidi:

这些心得，若是我们在书上见到或者听别人说，也许都会觉得稀松平常，经常念叨着，而只有自己亲身经历得到的，才能够引发共鸣，记忆深刻。

Jacky这篇心得，看似也是很简单，但是在日常项目里，也许我们还会不自觉走向反面：

1. 一接到需求不多问几个为什么就迫不及待去做方案
2. 想得不够详细，方案只出了一层皮，日后修修补补
3. 方案缺乏说服力——因为调研不够，在评审的时候，别人问你有没有看过竞争对手的网站，才慌不迭去“研究”
4.  ……

最简单的往往是最容易被忽视的，也往往是最重要的，就像所有知识和技能的“基础”一样。

From rita:

喜欢新版本help，附上的心得体会也很方法论，讲求方法可以帮助我们少走很多弯路，顶“先了解需求前提”，往往很多时候被忽略，一开始就钻进细节里，先把握大局可以让方向更准确。

From yama:

“人类总得不断地总结经验，有所发现，有所发明，有所创造，有所前进。 ” 通过总结可以把零散的、肤浅的感性认识上 升为系统、深刻的理性认识，从而得出科学的结论，以便发扬成绩，克服缺点，吸取经验教训，使今后的工作少走弯路，多出成果。