管理之痛

当你的研发团队只有几个人时，作为管理者，你不会考虑这么多。凡事直接安排就好，不需要工具、不需要流程、不需要指标。直接干就对了！

但当你的研发团队增长到几十个人甚至上百人时，如果前期一直不注重流程规范、工具使用和疏于管理和把控，以往的随意和凭感觉的做法，就会容易让快速扩张的团队陷入混乱。当业务快速增长、新人大量加入、旧的研发流程还不健全时，就会明显感知到管理上的乏力、团队士气低下和来自业务部门的催促不满压力。

尤其，当你作为技术管理者，也是企业经营者时，这种痛苦和担忧、焦虑就越发明显。这就是技术管理者，都会面临或已经遇到过的痛点问题。

极度公开透明

最近，和一位大佬在沟通时，他突然在开会前和我提到要有“极度公开透明”的原则。事后，我意识到，结合这么多年的技术管理经验，“极度公开透明”和XP编程提倡的“沟通、简单、反馈、尊重和勇气”、和敏捷开发的“畅所欲言、实事求是”、以及DDD领域驱动设计中的大声地“通用语言”是如出一辙的。又如同，钉钉宜搭在企业组织协同上所主张的“共同看见”。

我觉得，结合“极度公开透明”这个原则作为出发点，作为指导我们提升内部研发架构的思想之一，是很有参考、借鉴和落地的价值。

原则、思想和经验，对于几个人的研发团队，它是一个虚的东西，因为你还不需要它；创业团队更需要的是先活下去、能赚钱。而对于几十个人的研发团队，尤其是当前正在经历管理之痛的团队，就需要获得一些有价值的经验指导来改善当下团队的开发效率和交付质量。

打个比喻，还没买车的时候，别人和你怎么讲开车的故事和技巧经验，你是没感觉的；当你刚提新车时，作为新手上路，你会对开车的注意事项很有需要；当你又是新手又是在高速路上时，具体往哪个方向走，这时如果有老师傅给你具体的经验和指引，就会非常有迫切和意义。

故而，“极度公开透明”的原则，对于正处于混乱、管理之痛的技术管理者和研发团队，我相信它会有参考价值。

团队协同透明

在研发过程中，我们应当首先树立一个共同的关注点，这个关注要清晰、统一且可执行。同时，能满足开发者个人高效工作、团队成员之间进行流转协作，以及管理者进行管控和计划，甚至能和客户、业务部门一起，共同参与、共同看见。

经过多年的总结，我发现这个共同关注点，就是：项目。项目是一个集合，是一个共同的目标，是对整体负责的发力点。

技术管理者和项目经理，会重点关注项目对，项目最终结果负责。其他项目成员，例如：开发人员、测试人员、产品经理、设计师等，则会参与项目其中，进行具体事务和工作项的执行。细分拆解下去，就会有任务、工时、问题、Bug、需求这些常见的工作项。

因此，在YesDev这款协同工具中，我们重点以项目为全部研发团队的共同关注点，并且只关注当前激活的项目、关注和自己相关的项目、关注最新有发生变化和进展的项目。

对于每一个项目，在项目概览一栏中，团队可以共同看见当前项目的整体进度，例如：需求进度、任务进度、工时进度、Bug修复进度，以及项目的更新动态情况。这些简明的指标，给研发项目提供了当前最为核心的几个日常指标。

再进一步，为了让团队拥有透明的协同，最大限度消除信息不对等的情况，YesDev充分发挥了“信息找人”的精神，在项目进行了多功能协作和智能聚合。除了看到当前和自己有关的项目外，YesDev联合周报助手、测试计划助手、PRD助手、文档助手、管理助手等，为每个不同岗位、不同角色和团队成员都提供了贴切的、及时、恰到好处的协助。

简而言之，以项目为核心、共同的关注点，向下拆解细分需求、任务、Bug等可执行、可量化的工作项；向上形成内部研发团队当前最值得关注和协同的项目集；横向再扩展延伸研发协同过程中可能需要用到的文档、测试计划、周报总结等。

那么：

作为技术管理者和项目，你应该关注最终的项目进度、交付情况，关注当前产品迭代升级以及技术侧需求和其他一系列的专项的协调和安排，在更高的公司目标和层面，以项目为单元，进行统筹、计划和推进。

作为项目参与人员，你应该关注自己在每个项目的待办工作项，看一下，我分别在每个项目有多少个待开发的需求、有多少个待修复的bug、有多少个待完成的任务。这些都是实实在在需要执行的工作。

最后，作为项目的干系人，你可能需要了解掌握项目的最新动态。那么，相比以前老是问技术、问开发、问技术管理者，这时你可以直接查看YesDev协同工具，就能同步及时掌握项目的最新、最真实的动态。当然，工具以外的未知信息，还需要在内部多充分沟通和交流。

工作透明

现如今，就垂直领域的研发协同工具来说，可谓是“百家齐放，百家争鸣”。从国外的Jira、Trello，到国内大厂的腾讯TAPD、阿里Teambition，各厂商提供的PingCode、Ones、ezOne、Tower等，还有禅道、Readmine等开源软件，还有企业内部自主研发的项目管理系统。

讲真的，我们现在不缺协同工具，但我们缺少能正确使用这些工具的人员、团队和管理者。

以YesDev的任务工时为例，我们应该知道在什么时候，应该使用什么工具和看什么数据。为了让工作极度透明，我们需要关注以下几个最为常用的工作场景。

每个人，每位成员，每个员工，都应该清晰地知道，自己的这一天、这一周需要做什么工作。只有实习生和刚毕业的学生，才会被动地每天做一些工作。有2年及以上工作经验的人员，都应该让他们自己填写、登记和做好他自己这一周的工作计划。不能都是空空如此，不能一个任务做40个小时。只有他本人排好了自己的工作计划，知道了每个需求做多久，才有后面更顺畅的协作。

每一次在进行需求工作量评估和排期时，我都会重复再三地和技术开发人员讲，你们在进行需求排期时，不能只关注自己的时间，还要结合前后端联调、开发提测的时间一起进行综合评估。在上面有了每个人真实的任务工时评估后，接下来就可以让需求的前端后端开发人员，一起再结合联调的时间，进行协商和排期。对于需求交付和整体的项目交付，只看单个任务的具体时间没有太大意义，只有组合联动起来，才有价值。这时，在任务工时登记，就可以根据团队的需要，查看对应工作组的成员每日任务。这样，对于大家每个人的工作安排，都是透明的。

有了人员各自的任务，也有了联调确认后的工作计划排期，在期间当需要开站会或协调人员之间的任务分配时，我们可以使用熟悉的敏捷任务看板，也可以使用YesDev专门提供的任务对比。

敏捷任务看板，既可以按人员，也可以按项目、按任务类型，快速切换我们所关注的维度。

而任务对比，则是技术管理者，站在协调角度进行成员之间的任务分配的调配。谁忙谁不忙，共同承担或主动承担。

从成员自身出发，到成员之间的联调，再到技术管理员的任务调配，继续再向上一个台阶，就是项目经理或者项目负责人，需要从整体上把控项目的进度和计划。

这时，在每个项目中，我们就可以用到项目排期表、项目燃烧图和项目甘特图。

项目排期表，可以在人员或需求的维度，告诉我们汇总和拆解的项目工时进度，方便知道当前项目的开发压力在谁那里，可以知道谁的开发进度最为落后。

项目燃尽图，可以告诉我们，项目的整体进度落后多少，以及未来的进度走势如何。

而项目甘特图，不仅在时间合理安排和人员工作量安排上，都有很大的参考指导意义。例如在春节过年前后的工作安排，或者需要进行冲刺交付阶段，结合项目甘特图，我们可以“知未来”，看一下每一天、每个人的时间安排是否合理。合理很重要，不要想着一天一个人能干40个小时的活，那是不可能的。谁能告诉我们，排期明显不合理？甘特图。

到了每周五或每月底，我们再从YesDev导出各成员的工作任务，就能更清楚地回顾和知道，他们每个人这段时间的主要工作内容了。对于管理者，可以形成闭环管理。对于成员，他们也可以快速编写每周的周报。

这是从任务工时，核心以时间为主线，介绍了结合工具、团队，可以怎么进行协作、协同和管理。管理者和开发人员之间更好的搭配是：你懂管理，我能执行。

信息透明

协同不同审批。协同是一个开放、透明的过程。在研发团队内，需要彼此信任、共享信息。

我需要知道你在做什么，以及将要做什么。以前做技术管理时，包括现在也是，经常都要问开发人员，XXX事情，进度怎么样了？半天了，他回复了：“还没做”。吐血。

为了让更多的技术管理者，不要经历我的痛苦，我们特意在YesDev进行了深层次、人性化的产品设计。

曾经我到佛山某一传统的工厂去洽谈一个ERP项目，那里的老板和我们说：“根据我多年的经验，现在的流水线每日的产能是远不止这个数和。但我不知道怎么改善它，因为我们没有数据的支持。所以需要引入ERP，让产能可视化”。广告主也有类似的话：“我知道我的钱有一半是浪费的，但不知道浪费在哪”。研发团队的成员，其实也是需要指点的。但需要的是指点，而不是指指点点。那通过什么方式，管理者和开发人员之间，都能有一个透明的信息，一起来对研发工作进行共同探讨和提升呢？

我看来，脑图是一个好工具。

一方面，人员方面，技术管理者，可以留意和对比每个成员的工作脑图。除了任务工时，还有需求、bug、项目等。哪些是积压的？哪些是还没来得及做的？哪些是重点花时间、花精力攻克的？了解情况，再从旁协助，让团队成员有更加清晰的发力点。

另一方面，在项目内部混乱时，借助项目脑图、需求脑图，再纵向和横向，静下心来，和团队一起分析下，当前项目和团队遇到的问题。回过头看一下，是沟通没清楚，还是需求有误解，还是其他事项耽误了？

在对新项目，或复杂核心的功能进行测试时，维护好测试计划后，通过测试计划的脑图，在脑海中重新梳理和规划一下用例的覆盖面和执行情况，以及对应的bug修复进度。

这些脑图，不仅自己可以查看，还可以共享，也可以在项目评审、需求评审、测试评审时，结合使用。

通知反馈透明

当产品经理提出一个新需求时，要想想，这个需求，开发人员知道了吗？老板知道了？业务方知道了吗？当这个需求进行测试或上线时，产品经理知道了吗，项目经理知道了吗？当这个需求中途有变更、优先级有调整，开发人员知道了吗？

如果每一次信息和调整和改动，都要人工去知会和通知，这样的组织效率，可想而知，是低下的、是不对等的，是不透明的。不是我们不想让反馈透明，是实在没时间，忙不过来。

那怎么办？

让你的协同工具，结合群通知和邮件通知，是一个满足日常办公和沟通最为直接的方式。

在实时群通知方面，你可以在组织内部任意创建自己的群。通过机器人助手，接收和这一个群有关的项目通知和消息。

另一方面，可以针对员工，同步接收更加精准的工作指派和流转重要通知。

研发透明

很多研发团队，正经历项目泥潭、正在被历史问题困扰、正在被当下的混乱内耗。原因在哪里？本质又是什么呢？

正如《风吹半夏》里面的赵总在餐桌上提到：“买了一台小轿车，都不会开，怎么办？难道4个人推送走吗？”。我们不缺协同工具，但缺少能正确使用的人员、团队和管理者。又或许，我们不缺会正确使用的人员，但缺少有经验、能指导、能负责的管理者。

结合流程、团队和工具，让研发透明，拒绝黑洞。