10倍团队（二）：在家办公是软件研发组织的“敏捷试金石”之项目管理篇
前言
在上一篇文章（沟通篇）中，我们讲了有关软件研发组织“在家办公”受到的沟通方面的挑战。
可能是在一家敏捷的公司待得久了，所以我很长一段时间认为“敏捷”在中国已经是家喻户晓不需要再去谈的东西。可是直到我后来做了技术顾问，开始为客户提供架构和工程能力的咨询服务时才发现，绝大多数技术架构和持续交付实践难以落地的问题，最后都会遇到团队不够敏捷这个关键障碍，而真正敏捷的团队，在整个中国的IT行业中，则是极少的。
因为不够敏捷，所以能够用于改进的带宽就不足，因为改进的带宽不足，所以就难以应用更好的技术实践，如此反复就变成了死循环……
而在众多导致不敏捷的原因中，首当其冲的，就和软件研发组织的项目管理方法和项目管理人员的能力有直接的关系。
而本次新型冠状病毒（2019-nCoV）疫情导致的“在家办公”的要求，则瞬间放大了相关影响——尤其是那些依赖于传统项目管理方法的软件研发组织。
那么，在这一篇中，我们就聚焦“传统的项目管理方法”和“敏捷的项目管理方法”的区别，来谈谈对于在家办公的影响：
- 传统管理方法的缺陷
- 敏捷管理方法为什么更适合在家办公？
传统管理方法的缺陷
传统的项目管理方法以资源投入为着眼点，强调按约定进行交付
说起项目管理三角形（Project Management Triangle），我相信很多学过项目管理的人，都会脱口而出：时间（Time），范围（Scope），成本（Cost）。
PS：在实际中，很多团队的项目管理人员过去都是从开发人员干上来的，我特别喜欢在客户现场问这个问题，相当一部分团队所谓的项目管理人员，则根本回答不上来这个项目管理的基本概念，这也是一个国内软件研发企业很有意思的一个现象，屡试不爽……
但是在“脱口而出”的时候，却很少有人记得或者忽略了，作为“传统的项目管理三角形”，时间、范围、成本所构成的三角形中间，是非常重要的：质量（Quality）。
这个三角形告诉我们了这样一个相互影响的关系：
在项目质量要求不变的情况下（一般来说，在传统的工程类项目中质量要求都是一经确定难以变更的）：
- 如果需要缩短项目时间，那么就要减少项目范围或增加项目成本投入；
- 如果要节约项目成本，那么就需要减少项目范围或延长项目时间；
- 如果要增加项目范围，那么就要增加项目成本或延长项目时间。
这个“传统的项目管理三角形”非常科学，就拿这次抗击新型冠状病毒（2019-nCoV）的“雷神山”和“火神山”两个医院的神速建设来说：
首先，两个医院的建设标准和质量是不可妥协的，同时，施工范围是不可变的，工期也是不可变的，那么在这个基础上，只能不计成本的动用体制优势进行建设。
是不是特别有道理！
但是呢？这个“传统的项目管理三角形”（注意我一直在用引号强调“传统”二字），在我们的软件工程中，则通常是不能正常工作的！
为什么呢？因为传统的工程项目，其项目本身的范围更加可控，经验或资源的“复用性”更强，项目过程中的变化相对稳定；而软件工程，是属于“知识型工作”，其“创新性”更高，项目过程中的变化往往非常频繁，所以项目的范围则通常很难控制。
所以，这也是为什么“雷神山”和“火神山”两个医院的建设工程，能够在2天左右的时间出图纸，然后在5-7天基本完工的关键，因为这里面有大量现成的经验和方案组合，完全依据设计图纸进行施工的方式，以及固定的施工工艺和预制件的使用——这一切能够确保所有参战工人和施工队，按照统一的标准进行快速的建设工作。
而作为一个软件项目，想要从0开始，做到这两个医院的建设方式，则是极其困难的。首先我们就很难完全按照详尽的设计图纸或者严格的工程标准进行工作——除非此类软件所解决的问题已经在业内属于通用型问题，有大量的现成产品、开发套件或者开源方案拿来改改就能用（嗯，尤其是开发套件这个东西，往往是误入歧途，成为未来变更瓶颈的开始）。
一般来说，如果一个软件研发组织，在平时进行项目管理的时候，是基于“甘特图”的管理方式，那么大概率的就是在用以资源为核心的传统管理方法，来错误的管理以价值为核心的软件研发项目。（嗯，曾经做项目管理时的我也年少轻狂甘特图过……）
在实际中，“甘特图式”的项目管理，与强调精准管控，基于严格阶段划分和详尽文档的瀑布式软件开发流程往往密不可分。在这种开发流程中，一个可工作的软件，往往只有在某个开发节点到达后，其全部的功能才有可能被集成完毕，然后进行批量测试和验收。而在这个节点前的过程中，是难以集成甚至是“可工作”的，所以更不用提测试和验收了。正所谓越是想精确，越是十万八千里。
在这种管理模式下，由于项目精准管控的需要，往往项目管理人员都具备相当的管理权力或职级，属于比较强势的管理人员，而很多程序员八卦中那些对于项目管理人员声嘶力竭和官僚式的管理风格的描述，往往也是反映的这种管理风格下的研发团队。
而一旦转入在家办公，随着现场办公的便利性的消失，工作透明度的降低，以及各种协作难度的增加，软件研发的进度将变得愈发不可控，能否按时完成所有工作项的开发、集成、测试和验收，就变成了一个更加“烧香拜佛听天由命”的事情。
到时候项目管理人员怎么办呢？嗯……买套非常“好用”的在线协作工具，靠更多的视频会议来继续“声嘶力竭”和“追着屁股”的“连环Call”吗？
（你要是再不赶紧搞定，就在家里永远不要来公司上班了！！！手动滑稽……）
敏捷管理方法为什么更适合在家办公？
敏捷的项目管理方法以价值交付为着眼点，强调适应变化。
与“传统的项目管理方法”相比，“敏捷”类的软件项目管理办法，强调“以价值交付为核心”，通过“适应”的方式，着眼提升应对需求变化的能力。
PS：我的同事，ThoughtWorks中国区CTO徐昊曾经总结过针对“敏捷”价值观的经典一句话描述，就是“Value delivery over follow practice（价值交付优于循规蹈矩）”，这也体现了“适应”的精髓。换句话说，如果有人告诉你，敏捷就一定要做……（例如迭代式开发），那就是有问题的了，必须要综合多方考虑，在不同的环境下，找到最利于价值交付的方式，才是真正的敏捷。
如何做到“以价值交付为核心”和“适应”呢？仅就项目管理的方式来讲，在我看来，这里面有两个非常关键的区别，我们分别来讲一讲：
- 敏捷三角形（Agile Triangle）
- 可视化卡片系统（kanban）
敏捷三角形
首先，我们来讲一讲用“敏捷三角形（Agile Triangle）”代替“传统的项目管理三角形”。
如上图所示，“敏捷三角形”所关注的三个角是：价值（Value）、质量（Quality）和约束（Constraints），其中约束就是以前的“传统项目管理三角形”。从这张图上我们可以看到，敏捷三角形在传统三角形的基础上将质量和价值进行了显式的关注。
简单来说（我所总结的）：
因为在软件领域，随着时间的推移，影响
约束变化的东西太多了，敏捷的项目管理，应该在约束的条件下，优先关注以适合的质量为客户交付优先级最高的价值。而另一方面，由于精准的度量实在是太难了，所以我们应当以更轻量级的手段，来跟踪和度量价值的交付速度（例如燃烧图、燃尽图、累积流图等等），从而获得虽然模糊但是相对更准的预测。
PS：有关敏捷三角形的相关概念，这里不展开讲，感兴趣的话可以参考这篇文章：https://www.infoq.cn/article/2009/08/agile-triangle
那么这样做的好处是什么呢？
首先，敏捷的管理办法，强调整个团队关注价值交付的进度，发挥团队中每个个体的优势，通过集体的力量来跟踪和度量项目交付。这样能够降低中心化管理的依赖，不再依赖由具体的一个人来进行项目的管理（嗯，就是那个权力很大的项目管理人员)，为更松散的管理方式提供便利。（这对在家办公时的分布式协作提供了一个关键保障，少一个吼叫的人是一件多么令人开心的事情啊！）
其次，以价值交付为导向，能够降低过去关注资源的利用的复杂性，使得管理方法更加轻量和易于操作，进一步降低了项目管理的工作量和学习成本。（这会有助于降低在家办公所增加的管理压力）
同时，另一个好处，就是更轻量级的管理方式，能够更容易应用让整个团队（而非少数项目管理人员）共享和关注的可视化手段，来增强团队工作的透明度，让每个人的工作暴露在阳光之下——这个就是基于“可视化卡片系统”的管理办法。（嗯，上一篇说了，工作的透明度是在家办公特别重要的依赖）
可视化卡片系统
由于以关注“价值的交付”代替了“关注资源的使用”，所以我们可以用以卡片为可视化单元的“可视化卡片系统”进行项目进度的跟踪和度量，也就是我们常说的“卡墙”或者“看板”，如图所示：
有关可视化的好处，我们在上一篇文章（沟通篇）中已经有过介绍，这里不再展开讲。
在基于卡片的可视化系统中，我们所关注的，主要是：
- 团队的工作流程（纵向分栏）
- 当前的卡片数量（累积工作）
- 卡片的状态（工作的进度）
而我们所要做的事情，就是要去想办法让卡片系统中的卡，尽快的从左边一步一步的挪到右边的“完成（Done）”一栏。
这种只需要便利贴和大白板的管理办法，比基于“甘特图”这种需要依赖重量级管理工具（Microsoft Project等）还不直观的方式，简直是轻量级太多啊！嗯，而且这种轻量级的办法，特别有利于协作，让对于项目管理这件事变成团队每个人都可以关注和参与的事情！
正因为敏捷的可视化卡片系统具有这样的好处，所以大家会注意到当今以Trello和Jira为代表的在线可视化项目管理工具，都是以卡片系统的方式来实现的（嗯，包括最近因为在家办公大火的各种在线协作产品也是这样的）。
PS：特别需要注意的是，敏捷的卡片系统一定是以价值交付为核心的，卡片代表的是价值。我曾经在客户现场见过一种非常典型的“伪敏捷看板”（很可惜因为保密原因不能拍照）——在看板的左侧从上往下以每个人的名字为一栏进行拆分（横列俗称泳道），然后跟踪每个人所负责的卡片，这种就是一种典型的将人作为关注的核心（把人当资源用），将卡片系统用成了甘特图。（嗯，各位赶紧回去自查一下自己的看板是不是这种……）
总结
洋洋洒洒围绕项目管理说了这么一大堆，综上所述，如果一个软件研发组织，不能以敏捷的项目管理方法来管理项目，如何能够降低在家办公的项目管理成本呢？
最起码的就是：你就算现买一个在线协作办公的产品，也用不起来嘛！
但很遗憾，现实中，我们还是能够看到大量的软件研发组织，还是依靠传统的项目管理方法来管理软件开发，或者使用错误的方式来应用敏捷的项目管理方法。
按理来说，以上内容但凡是看过基本敏捷方法相关的书籍都应该知晓，但是非常残酷的是，通过我在实际咨询工作中的观察，现实中的绝大多数软件研发团队项目管理人员，除了是从开发人员转过来的以外，还有大量的是从传统的项目管理转过来的（或者学的是传统的项目管理方法论），所以能够说清楚以上项目管理方法论区别的人，则属于少数。
由于篇幅原因，我无法对影响在家办公的项目管理问题进行一一讲解，这里只能专注于最基本的传统项目管理与敏捷项目管理的差异，但还是那句话：
以绝大多数软件研发组织的敏捷实践水平之低，还谈不上如何在家办公。
希望本文能为众多因为“被在家办公”搞得鸡飞狗跳的软件研发组织提供一些参考和帮助。
后续文章，我会从另外的方面，来继续讲一讲，为什么在家办公是软件研发组织的“敏捷试金石”。
相关阅读
欢迎关注我的个人公众号
微信搜索：枪炮与代码，或者搜索公众号ID：guns_n_code
