研发人员应对需求的言与行

引言

工作三年多，没呆过什么大型的互联网公司，有幸经历了众多因项目环节缺失所引发的种种问题，内心深恶痛绝，打算用几篇博客记之。总结下自己工作，捋一捋收获。

分享自己的认识，供大家参考借鉴，当然会有很多不对的地方（比如说错别字），也望各位指正。

前段时间在几大教学网站购买了几套关于 项目集成管理工程师 的教学视频，深有所感。

版权所有：_ OE _, 转载请注明出处：http://blog.csdn.net/csnd_ayo

关于需求

需求，这个词看着又爱又恨。因为没有需求就没有我们软件开发者存在的必要；而不假思索的需求，又在蚕食着我们那些不为人知的劳动力。作为一个脑力工作者，我们该如何面对这些繁杂错乱的需求。

需求的定义

首先，我们的需求不是指那些一两天不到就可以搞定的事情，而是需要8天至10周，甚至更长的时间去完成，才算的上是需求。需求是单指对功能的增加或补充，不是对原功能的修改。

以上是我个人对需求的定义

为需求设置门槛

• 需求文档化

  简而言之就是让提需求的人写一份文档

  1. 让提需求的人明白自己的想法

     不要怀疑这个点，因为他真实存在。有很多需求都起于一念之间，有的时候他自己根本没有认识到需求会对哪些资源有影响，心里只是觉得这个点子不错，根本没有深思熟虑。

  2. 以表慎重

     如果连一份文档都不愿意写，甚至是写不出来，那它还有什么可以执行的价值可言呢？

  3. 可重复查阅

     靠嘴巴说出来的需求，是不具备确定性的，就是说前十分钟说的内容，再说一遍的时候可能会变了一个味道，虽然中心脉络一致，但不具备可以推敲的实质内容。听的人就更不用说了，前一分钟说的，下一分钟可能就忘记百分之六七十了。
     “转述失真”的道理都已经烂大街了，而文档也是目前最好的解决方法。

• 让大家知道

  简而言之就是做一个评审

  一个需求的提出，不应该是两个人私下敲定，
  这个主意很好吧？ 可是.. 先做再说嘛，不做怎么知道？，这种僵持之后的 先做再说 叫人胆寒。
  如果具备真正的执行条件，应当广而告之，集思广益。而且这样也可以对这个需求进行很好的扩充或修补。

阐明需求的利弊

对于一个需求的提出，作为一个有经验的研发人员，应该会有一个初步轮廓性的认识（这是前提）。

• 阐明原因

  对于项目方提出的需求，我们可以少谈利，因为作为一个研发人员，你要讲述的是别人不能讲述，或无法轻易阐述的事实。
  应该用通俗易懂的话阐明其中利害关系，让普通的业务人员对需求有清晰的认识。

• 阐明方法

  这里以 引入第三方平台 为需求驱动。

  忌 这样的引入会打破原有的设计， 这个需求会大幅度延缓我们的工期

  在阐明的时候，不具备专业知识的人是无法清晰的认识到上面的损失的。
  可以做以下的修改。

  • 这样的引入会打破原有的设计

    1. 该需求的引入与什么相关联的

       基于第三方平台开发，我们开发的A、B、C、D … 模块全部都要作废。因为 A 模块针对解决的是 xxxx， B模块解决的是 xxxx …，而第三方平台已经包含了我们这些模块相似的功能。

    2. 前瞻性的影响

       若引用并基于第三方平台进行开发，我们分别有 i、e、g、h、c…功能会受到影响，其中还可能会影响到我们关键的 o 功能，这次平台的引入还没有经过准确计算，估计会进入大概为期 n 个月的开发中。
       开发周期计算的关联因素有：第三方SDK的文档的完整性、新软件架构设计方案（精细版）、与第三方的交流成本 …
       影响开发周期不确定因素有：第三方的配合度，第三方SDK的稳定程度、第三方的专业程度 …

       并且在接下来的开发中，若遇到底层模块的错误，不易及时修复。

    3. 给予建议

       因改动量大，涉及面广，建议走变更流程或重新立项。（从小公司的角度来说就是，改的太多了，这东西有可能要重新做，大幅度的改，损失很显然，你慎重考虑一下。）

  • 这个需求会大幅度延缓我们的工期

    1. 具体的影响范围

    2. 工期的计算方式

    3. 影响的具体时长

    4. 不确定的影响因素

    5. 给予建议

记录需求

需求的记录，也显得尤为重要，他不单单要记录通过的需求，那些需求提出来，但是被否了的需求，也要加以记录并说明，对于整个项目来说，可以作为很好的回顾材料。（当然他还有比这更大的好处）

总结

面对需求，探讨是必须的，除探讨之外，稍微需要时长的工作，你可以做如下应对。

1. 需求方提供一份书面说明（若工期长的，应书写正规的需求文档格式）
2. 聚拢关系人以及与需求方同级的领导，对需求进行深一步的探讨
3. 根据需求，提出自己的疑虑，问题关联性强，且关系成败的，要求需求方给予准确的回复

结语

我将用亲身实例来讲解项目过程中所遇到的各个环境的重要性

• 关于需求 1 [点击前往]

• 关于变更 2 [点击前往]

作者： @_ OE _

---

1. Wiki - 软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。
   (2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
   (3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。 ↩
2. 原有项目以及具体做法，在实施过程中都可能有所改变，这称为项目变更。 ↩