前言

当我做为一个比较大的项目的主程之后，我萌生了一个想法，我要当一个项目的牵头人。为什么会这么想呢？

从之前的一篇文章中提到，层级。你得清楚在你当前这个层级的上一层是什么样子，它需要什么能力，这个过程也需要去探索出来的。我认为主程是高级开发的一个进阶版，它需要把控项目的质量，资源分配，项目进度，这些都是高开（我定义为coding方向的高级开发）所不具备的。

那么牵头人或者负责人，对于主程来讲，又有哪些是主程不具备的能力或者要求呢？我觉得对整个业务的思考，这包括业务模块的定位，业务的规模，业务的可行性。

主程更多是站在完成业务需求的角度去执行，但是负责人应该站在业务角度进行技术类思考。

研发层级	任务	具备能力
coding高级开发	保证任务完成✅，代码质量	代码、技术上能力
主程	保证项目的质量、进步	资源把控能力
负责人	关注需求背后业务难点，业务前景	思考能力、深入一线业务，对整体业务熟悉程度

项目负责人的尝试

全局观

首先我负责的是对账相关的业务，我们从负责人的角度来看，或者把它当一场生意来看，首先我需要清楚这个业务定位是什么，也就是这个生意做的是啥业务，有没有竞争对手，清楚大环境。

对账按常规属于财务模块，但是由于内部一些问题，财务不管，那么现在就很清晰了，接管了财务的对账，这个是狭义上的对账，广义上的包括第三方接口调用量也可以对账，比如说之前我一个shein的同学跟我讲，它们的短信功能被蹭流量了，损失了很多钱，后面通过对账找到问题的。广义上的对账，只要有加就有减，这里就看业务价值了。

其次，业务的前景，它说能解决的问题有多大？

比如说一个个业务方都说他自己的业务很多困难，很多需求，它们衡量标准是什么？可能是工作量，可能是业务量，可能是供应商数量，就是我们需要摸清这个生意有多大的前景，决定了业务的价值。比如说做的业务只服务一小部分的客户，那意义比较少。所以这里还有一个是推进过程的覆盖率的问题。

最后是可行性，可以从大到小，也可以从小到大，这个具体场景具体抉择。怎么理解这句话呢？

从大到小，从占比大头的入手，比如说某个供应商占到总销售额很高的比例，那么我只要把它解决了，意味着基本把业务做下来了。有些领导会觉得需要覆盖率，但是我的想法跟考试一样，我拿到我应该拿的60分，比起一个个去拿5分，10分已经强很多了。当然不能算优秀，只能说业务已经有雏形。

从小到大，我觉得是没有把握的情况下，先从简单的入手，从量上去覆盖业务，当然最大的那块骨头也最难啃了。

我觉得这是两个思路，需要从具体情况去分析。

细节观

有一方面是关于需求背后的业务价值思考，可能是业务难点，可能是之前业务不足导致的缺陷。

当然这里我也要聊几句，并不是什么需求都去纠结背后价值，东西总有主次之分，人的精力真的是有限。需要清楚哪些是主要业务。

鱼和熊掌不可兼得

有头有尾，之前我面试大厂的时候，经常听到一个词：量化

有头有尾，怎么理解呢？就是做完项目需要跟进项目的推广情况，收集问题，然后作为下一次解决的切入点。

就是你做这个项目它的价值体现在哪里，又有多少？这个多少指标是什么，需要量化。比如说有500个供应商需要接入，现在只接入10家，这个价值覆盖率可以算出来。

需要去深入业务发现问题

作为程序员常常为了完成需求，其实还站得不够高，正常的情况是站在业务的角度，用技术去解决业务难题。

在架构组我们也有讨论过技术跟业务的关系，聊聊我的想法：站在架构组角度，一定是技术重要，它的价值在哪里，降本提效。体现在规范上面，基础架构上面，让程序井井有条，即使随着业务发展也可以扩展，不会加大研发的重复开发成本。

如果站在项目角度，绝大多数是业务是大头，技术只是驱动、赋能作用。只有当业务做起来了，技术才有用武之地，不可能说我一个简单的功能，你直接搬上一个非常牛逼的技术方案吧，这属于过度设计了。

所以我的思考：要想技术有所深造，必须把业务搞大，才能谈技术上更高的追求。（这是站在负责人角度）如果作为研发角度，你可以无限过度设计，然后吹多牛逼，当然也可以，但是本篇是站在负责人角度来阐释。

举个很现实的例子，我上家公司用户数上千万，这么大的用户量，催生了业务需求，促进技术快速发展。

项目负责人往上的层级？

那就是多个项目或者一个bg的负责人，他需要对公司业务有更深的认识，然后炮制之前项目负责人的思路之后，还需要对各个项目之后的关系有清晰的理解，对整个大环境有所理解。

说白了，一屋不扫何以扫天下

它不是简单几个项目之间的叠加，可能会有覆盖，这时需要梳理出它们的关系，协调好资源，比如说哪个项目是重点，资源需要往哪里倾斜。我发现有些大项目仿佛大家没有思考好，一会说这是一个紧急需求，大家赶紧做，做完发现没人用，好家伙。或者说做到快上线前，把方案干掉，说行不通。还有些就是现在说紧急项目，过段时间又不紧急了。