研发同学应该如何负责好一个项目

引言

时间回到6年前，我在京东第一次独立负责项目的前端开发。当时的我可谓雄心壮志，希望表现和证明自己，结果第一次上线就造成了生产事故。

后来半年里，我几乎把所有可能的错误都犯了个遍：老板让我搞一个技术方案，我闷头搞了两周也没有给出任何结论；本来安排好的开发计划，被各种插进来的需求搞得手忙脚乱；参加需求评审没有充分的准备全程提不出问题……那段时间我很苦恼，明明很累很辛苦，但依然拿不到想要的结果。

一晃6年，自己已经从一个小白成长为技术Leader。当我站在更高的视角，我发现身边很多同学不停地重复犯着自己当年类似的错误。经过一段时间的观察与思考，我得出的结论是：他们在工作中缺少方法论的沉淀和指导。

“方法论”这个看似虚无缥缈的东西，却犹如指引行动的灯塔，连接着我们的价值观与行动。对于很多研发同学来说，“ 如何负责好一个项目” 是一门只可意会不可言传的玄学，其实不然。

我将我个人经历以及对身边同事的观察，做了一些总结，希望能够给大家带来一些启发，更好地在项目推进过程中指导我们的行动。

一 负责人的定位

这里的负责人不是指的项目经理，而是研发侧牵头和统一对外的那个人，往往是虚线Lead一个项目。

初阶的负责人通常只是做一些需求拆解、任务分配、问题收集和反馈这样一些基础的工作。因为缺乏方法论的指引和对业务的理解，过程中毫无章法、顾此失彼，表现就是像一个救火队长，永远都被事情推着走，很忙很累却拿不到结果。

在我看来，优秀的负责人是这样的：把自己负责的项目当作是一次创业，自己是这个初创团队的CTO，职责是带领这些同学打胜仗（打胜仗是指在产品和技术方案上少走弯路、做出来的东西真的有人用、帮助团队提高效率降低成本、帮助业务带来更多收入和利润）。

难点在于，上面这个表述虽然有了画面感，但具体应该怎么做呢？

二 技术负责人的三大能力

我常和团队的同学讲：技术人的三大支柱是专业技术、项目管理和业务理解。对于负责人而言，则一定是这三项均衡发展。

1、专业技术能力

负责人不见得技术很强，但有深度、有广度、有影响力会走更远。深度很容易理解，广度是指什么呢？

技术负责人需要有广度。广度一方面是 “跨领域” 的部分；比如：大多数情况负责人由后端同学担任，那么最好对前端、质量、算法也了解些，至少跟在讨论方案的时候要有得聊；另一方面是抬高自身视野：在方案评估和决策的时候，能不能看到公司内部其他团队的方案或者行业内部的方案；在做一个决策之前，都了解了哪些方案、不同方案间的对比维度和选择逻辑是什么，现成方案不满足需求时如何处理等。

技术负责人需要有影响力。影响力会让你有足够的自信去把控技术方案：如果自己提出的方案频频被挑战，或者面对别人方案的时候提不出问题和建议，则是削弱技术影响力的行为。在项目中，技术影响力主要体现在三个方面：

(1)内容和技术方案输出的专业性。我见过很多同学在沟通技术方案时都是“口述”，这样的方式既低效又不专业；

(2)工作中要有技术沉淀的意识。比如：效率和质量的提升、稳定性建设等；力争量化结果，拿数据说话；

(3)对技术的场景转化能力。专业性不在于用了哪些高大上的技术，而是用合适的工具解决实际问题，同时能反向推导这一类技术其他的适用场景。

2、项目管理能力

研发项目管理是个很专业的事，我对此的理解是：在有限资源限定的条件下，协同好上下游（包括运营、产品、设计、研发、质量），综合运用专业技能、方法和工具达成项目目标。整个研发项目管理的内容很多，通过观察，我总结出一些负责人在工作中常见问题及注意事项：

(1) 要不卑不亢，对结果负责。既不是高高在上的存在，又不是老好人，在项目中团结好大家，倾听并尊重每一位成员的意见和建议。

负责人在这个过程中要保持空杯心态。初入职场的小白，可能会非常谦虚，但是工作几年之后，专业技能逐步提升，可能还取得了一些小成就，人就会越来越自信。如果不能始终保持“空杯心态”，这种自信就会逐步演变为自满，往往表现为：工作中把别人的建议当成是批评、不喜欢听反对的声音。这样一来，团队里的声音就少了，缺少了交流碰撞，负责人就会成为团队的瓶颈。

(2) 要有敏锐的问题意识以及全局观。可以识别出项目过程中存在的问题和风险、看问题的视角要更高、也要更客观。当遇到问题，不是简单指责哪一方的问题，而是把事情经过还原，弄明白真实原因是什么。

是流程问题、依赖的问题、还是个人能力和态度的问题？在问题归因上干系人是否也这么认为、在解决问题的同时，思考这类问题今后如何规避。当项目遇到风险，不是简单的报备有风险存在，而是如何管理这个风险、过程中做什么努力。

研发面对的绝大多数都是项目延期风险，作为负责人不能单一维度的思考问题。 “上线要delay了通过加班赶工” 这种事情没有任何技术含量，即使刚入职场的实习生都知道。问题和风险不分家，作为负责人不要只看表面因，要多思考过渡原因、根本因是什么，在项目中对症下药。

(3) 要懂“外交”，要学会沟通。自己搞不定的事情，要学会向上沟通和对等沟通，跟什么样的人，说什么样的话。

对等沟通不是职级的对等，而是角色的对等，比如：负责前端的同学在沟通跟测试相关的问题时，最高效的方式是找测试中负责的同学，而不是负责执行的那个同学。

受限于客观条件，项目团队的人员配比不见得是合理的。比如：有的项目或阶段重前端、有的阶段重质量，当某一方相对弱势，除了申请追加资源外，要有补位意识，或者通过技术手段寻找出路。当有一方长期弱势，严重拖累项目进度，要及时识别出来并上升给管理者。

3、业务理解能力

作为负责人，就是要想办法让业务能更好，能让技术的价值有更大的体现。对业务有深刻理解，才知道业务更需要什么，也会更有使命感去推进。

需要特别说明的一点是，理解需求并不意味着理解业务，需求是业务经过产品消化后的产物，可能已经经过演绎，或者是其中某个拆解环节，因此需求并不是业务本身**。当然了解的需求越多，可以让你更清楚业务的全貌。

要理解业务，先要理解用户：他们在干什么、为何而来、到何处去、获得何种收益；然后，了解这里面的商业模式：流量如何来的、内容如何来的、生态情况怎么样、如何商业化的；再站在宏观角度去了解：行业情况怎么样、竞争对手怎么样；最后回到产品和技术：这个业务什么产品在承载、主要对技术的依赖和诉求又是什么。

以上信息了解过后，接下来最好还能够有一些洞察和思考，比如：现在业务发展遇到了什么瓶颈？打算如何破局？基本上把这些摸清楚了，你对这个业务就有个比较清楚的脉络了。

负责人要达到这种程度是需要下苦功夫的，搞清楚上面的问题，接下来要指导自己的行动，比如：要在过程中识别真伪需求、并控制好节奏，要判断哪些功能是一定要做的、哪些是现在这个阶段没必要做但将来可以做的、哪些是完全没必要做的。这里面第二个情况最难识别的。

有了前面这些认知，负责人要做好技术上的规划。优秀的负责人会抬高视野，从思考眼前的事，变成思考未来的事，预判业务未来发展对技术的挑战在哪里。

规划不是空想，是基于对业务理解，预测业务未来发展对技术的挑战，比如：可以通过一系列技术储备，做一些业务方原以为技术不能干、干不好的那些能够直接促进业务发展的事情；还可以发掘业务痛点或机会，然后用技术力量去改善。这里的技术可以是有很大厚度的，比如算法与机器学习、区块链，也可以是不需要技术厚度，但是需要产品设计和链接的，哪怕是简单的技术解决了业务问题。

作为负责人，要有经营意识：通过对数据的洞察寻找问题的答案。在项目中资源永远都是有限的，重要的不是做了多少功能，而是做的东西有多少人用。所以要学会用数据说话，大到交易规模、小到UV/PV等行为埋点，要定期的看，用它来指导你的行为。

一个需求评审前，你是否了解过这个功能的用户量是什么规模？上线后你是否有分析过是否符合最初的假设？这次产品功能上线给业务带来的实际结果是什么？当真实情况和假设间存在偏差，你是否有跟产品了解过背后的原因？当这种问题频频出现，你是否会质疑当前的产品路线和建设节奏有问题？有了这些思考和行动，才会保证项目往正确的方向推进。

三 总结

大家做业务，都有很大的业务压力，但对于技术人的要求，是除了完成技术实现外最大化的体现业务价值，这就需要我们做事情之前有充分的思考，在做事的过程中有正确的章法。

在负责一个项目的时候，要想清楚3个问题：

· 业务的目标是什么；

· 技术团队的策略是什么；

· 我们在里面的价值是什么。

如果3个问题都想明白了，前后的衔接也对了，这事情才靠谱。

回顾自己这7年的成长历程，我总结出技术人的成长诀窍，那便是：不混日子，有自驱；不求安逸，爱折腾

最后，希望大家还是能像最初的时候一样，能多折腾，保留这种折腾劲，甚至是孩子气，如果你还有的话。

来源：李志阳-京东云

原文：mp.weixin.qq.com/s/83qFIDTNCAGxzRzmcm4m_Q