想要提升团队效率，第一步要做的就是识别出团队工作过程中的低效场景。
定义低效
我们先来定义一下什么是低效。
效率是和时间、工作成果强相关的。
工作成果或目标确定时，完成该目标用掉的时间越长，效率越低；
工作时间确定时，成果和目标达成度越差，效率越低；
很多时候由于工作本身的复杂性和阶段性，很难定义清楚什么是效率低和效率高。
所以本文仅从开发过程和需求表达的角度，说明可以通过一定科学的手段和工具进行规避的低效场景；
低效场景描述
一般在需求评审会上，产品经理会为大家集中呈现原型和产品设计方案。短期内，让大家记住是没有问题的。马上要做的需求和大框架的部分大家会迅速的达成共识。
然而会后一段时间内，研发人员的时间和精力相对有限，尤其是当需要开发的功能较多，对需求的吸收程度更加无法保证。时间一长，本来记住的需求也容易忘记或记混 。这时候就需要重复沟通确认，甚至返工重做。那些用在重复确认需求和需求细节上的时间，就是低效场景。
▍为什么需求会被忘记呢？
上面阐述的，需求记不住，记混，其实都是记忆的问题。结合记忆的相关规律，我们来分析一下，为什么上述场景中会出现记忆的问题。
艾宾浩斯记忆曲线
比艾宾浩斯遗忘曲线由德国心理学家艾宾浩斯(H.Ebbinghaus)研究发现，描述了人类大脑对新事物遗忘的规律。是人类大脑对新事物遗忘的循序渐进的直观描述。
多数人的记忆是符合这样的规律的。
根据表格呈现的规律，大胆猜测一下：开完需求评审会之后，需求点在研发人员的脑中进行着疯狂的遗忘。仅仅 20 分钟，需求就会损失将近一半。所以按正常的开发进度，他们是永远记不住接下来要开发的需求点的。这也就是为什么多数开发需要一边问一边做，因为是真的忘记了。
既然这种情况是符合科学常识和记忆规律的，我们不应该责怪研发人员记不住需求。那我们应该采取什么样的办法来减少或者避免研发人员的询问，进而提升工作效率呢？
让开发及时复习，努力记住需求么？
记单词的时候为了对抗艾宾浩斯遗忘曲线，会为每个单词区分 List，按照记忆规律去安排时间及时复习。不过我们可以思考一下开发和需求的关系：研发人员的工作任务是实现需求，而实现需求最快的路径是清楚需求，实现需求。记住需求本身非但不是开发实现需求的必须之路，还会花费大量的时间。所以是没有必要的。
下面我们就来看一下具体什么样的文档，从哪些方面能够提升研发人员的工作效率。
▍让研发人员高效的需求文档应该具备哪些特点呢？
需求点颗粒度足够细小
研发人员对于足够大和明显的需求，不太容易忘记，越是细小的需求点，就越容易忘记。没有这些细节，产品功能依旧可以说实现了。所以这些小的需求点被忘记大家都察觉不到，但往往这些被忘记的需求就是会被漏做和做错的需求。就会变成在后续的使用中不断发现的一类“Bug”。
所以这些细小的需求点，需要在文档中有具体的呈现。让开发做之前能够再记需求细节，确保细节被完成。
我们可以看到上图中 Excel 的需求文档，对功能的每个需求点和逻辑都进行了描述。当研发人员做到这个功能的时候，仅需找到该功能模块，再细看后面的需求点，就能够清楚自己开发的功能模块具体有多少个需求点需要做。有效避免因为忘记而造成的功能开发不完善的情况。
需求描述技术化
当我们我们认识到了需求会被自然遗忘，就能够理解研发人员看文档最主要的功能。针对接下来要开发的需求点进行确认和回忆。
一个功能开发完成，或开发到一半时，研发人员需要对照文档去看功能的实现情况是否满足需求。如果文档中全是描述性的语言，就需要他们花费一定的时间去重新理解并且和产品再次确认需求。
world 类型需求文档的特点就是需求描述很细致，很多，像论文一样。但如此多的描述型语言，不仅需要二次确认，而且大量的文字也会让人望而生畏。
好文档的另一个功能就是能够减少研发人员确认需求的时间。Excel 文档语言的特点，就是简洁和技术化。
需求经过产品经理转化后被安排在表格的每一行。像极了代码，很多时候每一行的需求点的描述，就代表着一种或者一个代码逻辑。不需要花费多余时间进行理解和消化，进而提升了工作效率。
确保开发在做的永远是正确的需求
研发人员在开发过程中高频的确认需求还有一个原因：他们不记得到底哪些需求被更改过，那些需求是否还会更改。开发的工作需要被认可，已经开发过需求点就是开发的工作成果。为了产品更加细腻，需求变更不可避免。然而由于需求变更造成的重复开发和资源浪费。因为没有记录需求变更，使得研发人员工作成果不被认可就不应该了。
默默的调整文档，不做变更记录，就会导致开发的工作量得不到认可，工作没有成就感。项目进行中，文档更新不及时，更新没有记录，也成为了研发人员的痛。这种就痛促使着他们在做之前不断的去确认需求。
能够清晰的记录被更改过、删除过、延期过的需求点，的文档会为开发带来安全感。
上图中的文档，灰色是取消的需求，红色是新增的需求。用取消和新增来代替修改。既保证了需求的准确性，又让开发过需求能够清晰的溯源。会让开发对文档充满了信任，进而减少提问和确认需求。
提高团队获取对应需求的效率
IT 产品不管需求多么花哨强大。最终研发人员能够实现的产品需求都需要落到功能上。换句话说，产品经理输出的需求高效的被团队理解、实现，产品才会真正的有变化。
下图我截取了，工作中和学习中见到的 excel 类型的需求文档的表头；我们来看一下它的特点。
首先就是所有的需求点，都归属于具体的功能模块，功能模块归属于需求模块。大家有了具体需求模块和功能模块的基本认知，再到对应的需求点。使得研发人员对每个需求点都能清晰的对应上具体的功能模块。
其次，所有需求点共用一个表头，表头陈列的需求点的不同方面，形成了团队通用的语言框架沟通模式。研发人员通过文档自检当前功能模块和需求的需求点是否有漏做的情况；UI 和测试也可以直接在文档中找到工作需要的，信息展示的字段、相关的说明。很好的衔接自己的工作。
团队有了通用的语言框架，彼此的信息的传达一定是更加明确和畅快的。所以当团队的人都适应的文档以后，整个流程的效率一定会有所提升；
额外功能
Excel 的需求文档，能对需求和功能进行量化，进而粗略的清晰产品和开发的工作量；
记录每个版本的需求数量和效果，那些需求是不够明确？
过程中取消和新增了多少需求？
那些需求难度较大出现了返工或者开发亮点？
客观的总结过去，才能更好的向前前进。
相互学习 共同成长
关注公众号，扫码加好友，
加你进0~3年经验产品交流群！