小猿日记（6） - 技术方案成长篇

口水记

今天参加了团队内一个新功能的技术评审，虽然自己不参与开发&设计，不过去蹭蹭经验也是挺好的，关于一些需求/设计提下自己的建议。

从需求评审一直跟到了技术评审。

由于时间比较紧急，属于倒推项目，虽说后面增加了几个后端开发，但是懂的都懂。

他们各自负责一部分功能的开发，技术方案出的也是比较急的，且最近的几个周六都需要加班。

相较于正常的开发这次功能，这次的项目整体时间，压缩了30%左右吧。

在技术评审的时候就体现了一些出来。

首先说说明显的不足吧，然后再说说改进

不足：

• 由于时间问题，技术评审明显缺少了一些设计，想哪写哪，直接写的接口，技术评审完全变成了接口评审

• 开发人员分工协调问题，相同功能，两个人重复过了，在会上才确认人

• 开发对于需求不思考目的，不关心后续的一个发展，该功能上线便万事大吉

第一点

首先针对第一点的问题，虽然时间很紧，但是必要的一些方案还是不可少的。
简单的描述，就是下面几点：

• 功能的UML图

• 系统整体架构

• 数据库设计

• 核心功能的流程图

• 是否使用了团队之前未使用到的新技术（发现在很多团队并没有这点的一个说明，这点其实挺重要的，特别是对于一些倒推项目，很容易导致延期）

上面几点是基于整个团队来思考的，文档中应该要有的。
而且在技术方案中，应该是需要过的。这次的技术评审，只有一个开发，我看到了一个UML图，至于整体的架构，那是完全没有，功能的流程图，也是没有，数据库设计，更是没有说明。

对于这样的技术方案，其实应该是要打回的。这次的一个技术评审，完全开成了接口评审。

后端和前端过了过接口，然后就完了。。。

第二点

其次第二点，相同功能，多个人同时做了技术方案。

原因我分析一下：应该是这次的功能跨了小组。

很明显就是前期没有进行一个后端开发的内部协调，这是技术经理的一个失职。

• 多人合作，分工要明确，提前协调好，确定技术经理/项目经理，需要有一个整体把控的人

第三点

第三点，其实很多开发都有，不思考为什么我们要做这个需求，这个功能在团队/公司层面看来，需要达到一个什么目的或者说是预期结果，值不值得（这也是为什么，很多开发不敢去怼产品，在我看来，很多情况下应该怼产品，怼需求，这说明你去思考了，你不只是站在一个开发的角度去思考需求的实现了）。

后续这个功能要怎么发展，按照现在的一个技术方案，能不能支撑后续的一个数据量/并发。这些其实在技术方案中都是应该去思考的一件事情。

正常来说，一个新功能的架构和设计，应该要支撑至少2-3年。这个是需要数据来评估的，普通开发可能不在意，但是作为一个技术经理，是应该去考虑的事情。

需求评审

今天还另外参加了一个需求评审，这次是我需要参加开发了，虽说手上并行着项目开发，但是没办法。

不过这个需求中有几个功能被怼回去了（对于自己怼不回去的，直接反馈到上级说明情况，不要一直和产品经理扯些没用的，一般来说，扯不过），为什么要怼。花费大力气开发一个无法达到效果的功能，对于团队来说，就是在浪费资源。
（注意，这里的怼并不是破口乱骂，而是用正当的理由去说服产品。我和公司的产品，私下关系还是不错的。但是要分清楚不能因为私下关系好，就偷偷接需求哈，这是两码事）

现在产品正在改那几个需求功能了。

小结

今天感触还是挺多的

主要还是技术评审，以及和产品之间的互怼。

今天记了挺多了，总结就两句话。

技术评审不是接口评审，该有的技术方案都应该在技术评审中体现出来，技术评审要达到的效果是能够让没做过这个需求的人，看完技术方案，可以很快的明白技术架构，功能流程以及数据库设计；

参加需求评审，多思考需求的目的，预期，解决什么问题。

不正经语录

• 怼产品，怼需求，说明你对需求有了自己的思考，而不是对产品经理有意见

• 评价技术方案怎么样，就看团队新人看到这个技术方案，能多快接手这个功能，需不需要开小灶

• 倒推项目，加人是没问题的，加时间就不要想了

声明

本文故事纯属遐想，如有雷同，我是原创。

欢迎转载。
转载请务必注明以下信息。
原作者：谙忆
原文地址：https://copyfuture.com/blogs-details/20200521194057394736l4log7y6utwj

公众号

更多精彩内容、活动、程序猿的小故事，欢迎扫码关注公众号