事情要从一次软件研发团队早会讲起……
早会上，老板正在询问自己关心的几个功能的进展。一个程序员汇报说，目前这个代码已经写完了，正在等待代码评审。

老板随口一问：怎么这么久，还要多长时间，什么问题？

没想到这么简单的一句话，咣当一声砸在了地板上，差点把视频会议给砸断线了。

一个初级程序员一脸懵逼：我负责写功能，代码写完了，功能都调通了，测试也过了，我又不负责评审，我不背这个锅。

研发小组长心想：这tmd说的是哪个PR？链接在哪，现在assign给了谁？？？

组里的资深程序员的思绪则压根没在线：早上的咖啡还没喝完，脑袋还不清醒，昨天刚解决的那几个问题，今天还得再看看，哎怎么没人说话了，是不是网卡了，今天还得这帮人又瞎扯什么呢，能不能赶紧结束我这还一堆事呢。

项目经理尴尬的跳出来打圆场：我们下次的标准版本发布日期是下周四，现在刚刚周三，应该能赶上没问题吧？最后还是老板尴尬的咳了一声：抓紧抓紧！我们接着说下一个事吧。

上面的这个场景，我相信大家都不陌生吧：作为一名混迹江湖的资深老码农，团队里面的各个层级对我来说都不陌生。作为旁观者，我们到底从这个简单的例子里读出什么来呢？

作为系列文章的第一篇，我想先说说第一点 “什么叫做 Done ?”

01 什么叫做 Done?

Done 是JIRA工单系统里的工单的一个最终状态，也就是说这个工作做完了。这里我们借用这个标准来想想到底怎样才算把工作做完了。

有的程序员认为：代码写完了，编译没问题，测试也通过了，PR也发送了，你看你在我电脑上打开浏览器点这里、点这里、点这里，是不是就完事了？

我在这里请读者试着换位思考一下，从老板的角度出发，什么才叫把这个事情真正做完？说到底，老板招聘技术团队开发，当然是要让产品功能上线获得收益才算做完。

对下（执行）来说，夸张一点讲，决定是把大象放到冰箱里，还是把犀牛、河马放进冰箱里以便获得收益，是产品部门经理、总监的职责；而造冰箱，放大象，到底能不能做，怎么做？这些就是研发负责人、研发总监、小组长的职责。

而对上（战略）来说，帮助公司和产品部门找到技术和市场正确的结合点，不要经常搞出大象进冰箱这种天马行空又不一定可行的产品思路，也是技术部门不可或缺的职责。

02 软件团队的岗位、职责

软件团队里的各个岗位，职责各不相同。

初级程序员对自己的职责解读，可能就是基于现在的代码架构下开发某个功能，修复某个bug。而另外一个资深程序员手头的任务，则可能是正在重构某个底层框架，重写某个重要的功能实现。

• 这种情况下，初级程序员的代码是否需要评审？谁来负责评审？

• 按什么标准来评审？是先合并这个PR还是先合并另外一个PR？

这些都是很现实的问题，需要有人去解决。一个高效的团队中需要有人去思考和推动这一点，这也就是为什么团队需要一个研发小组长、需要技术总监这样的领导型、管理型角色。更不要说对外沟通、向上沟通这样的职责了！

在笔者职业生涯中经历的几个或大或小的公司中，大部分团队都逐渐实行了第一责任人制度：把某个功能分配给某个程序员去实现，那么你就要去负责推动整个团队来落地实现这个功能，需要写代码你就要写代码，需要写测试你就要写测试，需要前后端联调你就要去张罗联调。

当然，这里是说推动这些事情是程序员的职责所在，如果你确实需要帮助，无论是技术上还是人事上、资源上、政治上的，都应该主动和自己的上级联系，他们会帮助你做成这些事。对应的，你在公司内的职级，直接对应的就是你能推动多大的项目落地。就硅谷公司来说，常见的职级划分如下。

• L3/L4级：刚毕业，或是刚入职场一两年的新人，他们一般缺乏独立推动项目的能力，只是一个被动参与的角色。对应的，公司需要他们尽快升职L5，否则就会别淘汰。

• L5级：对应的是 Senior Engineer, 资深工程师，他们必须有独立规划和推动一个简单项目落地的能力。

• L6及更高级：对应的是 Staff Engineer，Senior Staff Engineer 等，他们必须要有在公司内部推动复杂项目、甚至跨部门项目落地的能力。

而对应的 M5、M6 则是小组负责人，研发总监等管理级别，他们主要负责协调资源，内外沟通，保障项目的实施。管理岗位是否承担编码职责则因人、因公司而异。这样两套并行职业发展路线能够帮助团队成员找准自己的定位，规划自己的职业发展路线。

希望这些信息能对大家有所启发。接下来我还会试着从其他角度解读，咱们下期见。

如果想要了解更多关于技术管理、技术人成长的话题，各位小伙伴可以阅读《技术为径：带领公司走向卓越的工程师》这本书。

这是一本技术管理方向不可多得的好书，不管读者身处哪个级别，相信都能找到和自己目前处境相符的职业建议。

这本《技术为径》的内容融合了“技术”与“管理”。

从普通软件工程师，成长为技术导师，再到技术小组长，之后继续晋升并管理一个团队，再到多团队管理，最终升至 CTO，作者这一路的经验及感悟一定可以让你产生了很强的共鸣，并对自己未来的技术管理职业生涯有了更多期待。

书中涵盖了少见的针对 IT 团队技术管理的经验之谈，在此，强烈地将它推荐给同行们。