一个产研团队的成长-概要设计篇

我之前在接手一个研发团队时，该研发团队已经有两年的时间了，我缺省认为这应该是一个比较成熟的产研团队。然后经过一段的时间的了解，发现这个团队的产研过程，就是一个典型的小公司的小作坊模式在运行。

大概的产研情况是这样的，有一个强势的产品经理，将产品需求用脑图的形式输出；然后召集研发团队，然后给研发团队讲需求，讲完需求后，将需求列表发出来，让研发团队对着需求列表填写工作量和排期。经常在提测的前夕，研发经常会在沟通群里说，有些功能没考虑，需要延期，然后就是产品经理的挑战，为什么开发这么慢；或者是提测了，测试发现功能和需求不一致，然后产品经理有开始挑战研发，说为什么开发出来的功能和需求不一致；又或者是上线了，系统非常脆弱，时不时的出现各种异常，然后又是紧急修复，紧急上线，以上种种。

然而大家似乎都非常习惯这种开发过程，并享受这种繁忙的感觉。

大家可以对照下自己的团队，是不是也是这样的。相信有很多产研团队都是在进行这样一种作坊式的产研活动。

我之前是在外企，研发流程极其繁琐冗长，效率非常底，大家对此也是频频吐槽。然后国内的一些互联网公司，却是从一个极端走向另一个极端，以业务为导向，对研发的要求就是快，研发团队只要能够快速交付功能，反而对线上质量问题容忍度更高，对研发过程关注度很低，也或许是人员素质的问题，还没有对研发过程管理有一个较好的认知。

如果直接把外企的的流程全拿过来，肯定会收到非常大的阻力，包括产品和研发本身。那我们从产研过程过程中出现的问题，着手来分析。

1.  产品挑战研发开发进度慢；
2. 研发说有些功能没考虑到，导致延期；
3. 开发的功能和需求不一致；
4. 系统脆弱，上线后问题频出；

问题1，其根本原因是开发的评估工作量不准。为什么不准，因为评估的过程是看着需求，拍脑子估计。如果能够能够将需求转化成研发的功能，并将功能解耦拆解，这样是不是就能够更加准确估计出工作量；

问题2的原因在于，研发的理解没有经过评审, 尤其是和产品的评审确认；另外，产品的需求输出是一个脑图，并非是按照场景对需求进行描述，也就是说需求文档不够明确，具体。

问题3和问题2的原因差不多。

问题4，原因在于各个研发按照自己负责的需求进行开发，没有一个完整的，整体的设计，互相之间缺乏高效的沟通。结果就是系统稳定性很差。

经过分析，我觉得在两点上改进下，在不影响版本周期的前提下，应该能够快速有效的较大程度的缓解这些问题。

1、产品prd在原来脑图的基础上，对重点的业务场景按use case进行描述；

2、研发经过需求评审后，要做概要设计，然后拉上产品，研发和测试进行概要设计评审；最后再排期。

先在研发内部推动概要设计，也遇到了一些阻力，大家会觉得浪费了很多时间。最开始是苦口婆心的解释，后来我就强推了，我设计好概要设计模板，要求他们就按着这个格式填内容。

然后和产品沟通，婉转的要求他们对prd进行规范。

结果是好的，经过一年的运转，大家都已经基本习惯了这种模式。产研团队感触颇深，以前产品挑战的进度慢的情况大幅减少，由于在设计评审时，拆的比较细，所以工作量的评估也比较充分，产品也容易接受；概要设计评审的过程也是和产品、测试确认需求的过程，较大成都避免了需求理解不一致的情况；设计评审过程让设计更加完整，考虑更全面，通过这个过程，大家感受到技术氛围越来越好他，每个人的技术能力也有了比较快的提高。

关于概要设计文档，后面再写一篇来说下文档里需要包括的内容。