从零开始：程序员带项目时不可忽视的关键技巧！

作为一个程序员什么时候时最幸福最轻松的呢？一般是在工作的前3年。

这个时间段一般你只需要专心写代码做需求就行了，期间还会不间断地获得从脑海中的一次创造（想到）到现实中进行二次创造（做到）带来的愉悦，以及觉得自身能力持续成长的喜悦，总之身体可能是疲惫的，但身心大概率是愉悦的。

当你跨过3年这个门槛，变得能独挡一面，能完全负责一个项目甚至某块业务的研发时，往往这个时候会被要求试着带1～3个人做项目，开始有意识地让你接触项目研发管理的东西。

毕竟在国内的职场讲究一个“学而优则仕”，当然不是让你当官，只是让你带项目。

这个时候就有意思啦，你自己加上带的两个人做项目，往往会产生1 + 1 + 1 ≈ 1.5 的效果，而你自己的感受是，感觉比你平时写两个人的代码还累。因为在这之前你的工作是像下面这张图里的接需求、开发、交付。

分析需求在图里画成了虚线，因为这个需求只有你自己做，你自己想明白了就可以，不需要跟别人去沟通该怎么实现，顶多跟前端、测试聊一下接口，写写接口文档。

那么现在你除了自己开发还要管项目的研发，假如说项目现在一共三个人，由你负责项目研发的管理。这时你的工作就变成了下面这张图：

多了一半的流程，而且分析需求再也不能是自己想想就行了，为了保证质量还得来个技术评审对齐你们在功能和技术实现上的认知。当然需求分析可以简单的在工位上用嘴说说，但是保不齐你说的别人只能理解个七八成，而这两三成的理解误差就是你们上线前加班的隐患。

而且这还是你们内部直接的对接，因为你们从一个人变三个人了，保不齐是业务好，前端和测试也扩张了从以前的一个前端、一个测试跟你对接，变成了两个前端两个测试跟你们三个对接。

那这时候事情突然变得复杂了， 你怎么能保证你们之间的理解是一样的，这个时候就得整个稍微正式的技术评审啦。那技术评审也不能让人接直接看代码或者听你口述呀，一来人家也看不懂，二来效果也不好。这个时候就需要一个能在大家之间建立统一语言的方式来做这个技术评审。

迭代类的项目做技术评审无非就是：

• 分析流程

• 分析技术实现

分析流程是分析大面上的流程，让人们对这个需求的总体流程有个认知，这个时候一般会用到流程图，如果你对UML有所了解的话会用UML的活动图来分析需求的大流程。

比如说你们现在做的是OA系统的需求，要在OA系统里增加员工请假的功能，我们就可以用一张这样的活动图边分析需求边把整个流程列出来，等你分析完了活动图也就完成了。

UML活动图更专注软件领域，所以它的表达力比流程图强一些，即使并行之类的逻辑也能表达出来。

同理如果这个请假的状态远远多于3个，一般超过3个状态，人就要不停的看表中状态字段的注释，才能不会把状态搞错，而且写代码实现逻辑的时候执行到某个流程，状态不对导致的BUG是最多的。

针对这种情况最好的解决方案就是能够随着流程梳理一下状态的流转，把那些写在注释里躺着不动的枚举值，让他们动起来，所以我们在梳理状态流转的时候必须整明白状态的转换是什么动作产生的。

针对这种情况最好的工具是使用UML的状态机图，把状态的流转过程都整理出来，标清楚状态发生转换的动作。

而这些动作其实就是你未来实现需求时要写的那些CRUD的操作。

流程分析完了，接下来就是要给大家说明具体的技术方案啦，关键流程的实现细节是什么？尤其现在很多公司是微服务，功能实现时服务的调用关系、调用细节是什么也是需要讲明白的。

比如前端调用了下单接口，但下单接口内部实现下单时会查询库存、查询优惠信息、计算金额操作。这个时候我们该怎么才能把这些东西跟其他人表达清楚呢？尤其是和你一开发的前后端同事。讲清楚了这些就相当于说清楚了这个功能前端怎么跟你对接，你在后端内部怎么实现来完成功能。

我们来看一下微信的开发文档是怎么说清楚这类细节的，下面是一个微信支付文档中对商户使用微信支付完成订单支付整个流程的描述。

它这里使用的是UML的顺序图，特别适合用来发掘和表达内部流程是怎么实现的，在表达比如单个接口内部逻辑上有相较于上面的活动图更有优势，因为它能表达清楚时间线、角色和角色之间的交互、发送的请求、接收到的返回值这些细节。

UML的活动图、状态机图和顺序图被IT领域被叫做流程分析三剑客，三种图分别有不同的特点和适合的场景，结合起来使用能让我们通过不同的视角更透彻地分析流程。

这些内容在我推荐的《程序员的全能画图课》中都有详细讲解以及带练，课程中更有针对大型项目的技术评审案例分析和带练演示，无论是小型项目和大型项目都通过实际的案例分析讲解带你掌握这些技能。

与书本上和网上的各种UML教程不同的是，课程内容不会过于关注UML的各种语法让大家死记硬背，而是采用理解优于记忆的方式，用平时开发中常见的案例分析，教会大家对他们的使用。甚至还会手把手教你画系统架构图，业务架构图的心法要诀，让你能轻松应对各种研发工作中的非编码需求。

课程中最新提供了 15个 拿来即用的在线画图模版，涵盖需求分析、技术方案评审、述职汇报和甲方商务对接的支持，这些我们经常会接触到的工作。

现在扫描下方海报二维码订阅，即可享用所有这些内容。

课程订阅后可无限回看，所有章节已经更新完结，不存在烂尾的可能，后面会不定时加更一些新的总结。

关于内容质量，大家可以看一下真实读者的反馈。

好了，连招完成触发，咱们继续说回正题。带项目时一味地只知道带队冲当然累了，那怎么才能不累呢？下面说一下我的一个思考。

如果你能把研发流程靠一个个环节的标准化、然后管理起来，整体就会轻松很多。当然想管别人首先得自己会，在只带一两个人做项目的阶段，杂事还不算多，趁机先把上面说的这些技能掌握了，甚至还得教会一两个徒弟，让他们用这些工具表达自己负责的功能的思考，让大家都维持这套运作模式才会轻松。

不然的话还是每天站会问大家怎么样？答曰：挺好的。但是真的好吗，怎么评判做的好，不可能每天review写的代码吧！这就是为什么一临近ddl就各种手忙脚乱，不是大家前期偷懒而是没有消除大家之间的信息差，研发过程没有一个客观的评判标准。

等未来你真的能带10个人左右做项目的时候，比起一行行的看他们的代码，盯他们的进度，上线前当救火队员，远不如靠你已经掌握并运转起来的制度管理来的轻松。

国内为什么很多研发团队逢上线必加班，稍微大点的项目就封闭，就是因为只会铺人垒工时，用最笨的办法来让多人协作开发项目，当然这样对管理者也最简单，不用讲究方式方法带着团队一味地努力冲就够了，不需要学太多技能，主打一个陪伴和盯进度。

很多人会讲倒排期哪有时间搞这些，这种风气的形成正是因为你的开发过程没办法量化让别人看见或者让别人看明白，让别人以为压一压还可以省，所以老板还是以工厂计件算工资的思维来管理和驱动研发人员。但是这些中间环节省了，必然会以一种更猛烈的方式反射回来。

别的不说至少你学会这些技能了，能让自己变得更有条理、做好中间环节，上线更丝滑，不用每次都当救火队员。

未来有一天有机会去更规范的团队或者是需要直接对接甲方客户啦，这些现在学到的东西就会像乔布斯说的 connecting the dots 理论一样，到时候都会反刍给你。

---

最后，推荐扫码订阅，程序员画图课，我最近做技术评审画图还时不时翻出来看下，少有的好课。