临近周末，我们会在茶水间稍作停留，与同事们交流心得。这正是我们「5 问」系列文章的初衷：向经验丰富的项目经理请教他们的最佳实践。
今天我们对话 Jan Fischbach。他是组织咨询公司 CommonSense 的总经理、Scrum 活动培训师，也是面向新工作文化的 freiräume.camp 的共同组织者。
1. Fischbach 先生，您偏好哪种项目管理方法？
我们的客户通常出于两个原因请我们协助：组织类项目（例如引入 ERP 软件或文档管理系统）或引入敏捷工作结构（Scrum 等），后者当然也是一种组织类项目。在这两个领域，我们主要使用 Scrum。
业界并不把 Scrum 视为一种项目管理方法，而是把它看作一种团队流程、一种开发优秀产品的手段。而这正是我们项目所追求的：组建团队，让他们开始交付产品并持续改进。对我们而言，项目工作意味着在不确定性下交付成果。项目不是被「批准」的，而是被「资助」的。在谈论任务和时间规划之前，团队需要先充分理解到底要交付哪些成果。在这方面，我们借鉴 PRINCE2 的基于产品的规划、挣值管理（ANSI 748）、收益管理（Ward/Daniel）、基于绩效的项目管理（Alleman）、用户故事地图（Patton）或影响地图（Adzic）。
不确定性实际有多高，管理者和团队往往会低估。因此我们用 Shenhar/Dvir 的菱形模型来解释项目中的不确定性。对重要项目，我们建议用蒙特卡洛模拟来检验工期和成本的概率。凡是对最重要的工作包采用三点估算、并借助随机数把 1000 种情景看一遍的人，往往会发现最初的计划其实非常不靠谱。
顺便一提，Ken Schwaber 和 Jeff Sutherland 已于 2017 年 11 月发布了新版的 Scrum Guide。
2. 在较大的项目中您会使用软件吗？如果会，是哪些？
我们算不上软件的拥趸。这不在于软件本身，而在于它被使用的方式。我们的目标是稳定的团队在同一地点协同工作。这种情况下，往往一面空墙、一些便利贴和挂图就够了。当团队成员分处多个地点时，电子化支持才有用。但即便如此，我们也更倾向于把白板拍下来，存到共享的归档中。
我们的客户经常使用 JIRA 和 Trello。然而这些工具中的数据量增长速度，往往快于团队能够处理的速度。大家勤勤恳恳地录入数据，而维护却越来越费力，因为必填字段越来越多。到某个时候，没人再看得清到底交付了什么、还有哪些工作待做。页面加载和搜索越来越慢。个别团队成员为了把活干完而绕过软件。在这种情况下，最好先停下来使用、稍作停顿：我们当初到底想用这款软件实现什么？当然，许多产品也能用来管理待办事项和计费工时。但软件真的应该帮我们做这些吗？
3. 项目中您最喜欢的仪式是什么？
我非常喜欢用故事地图（Story Mapping）。在客户那里，我们总能遇到非常优秀的员工。常常缺的是对事物的共同视角。在这方面，我觉得故事地图确实很有帮助。我们花上一两个小时，更好地理解某个流程或产品结构，并据此推导出工作重点。在随后的梳理和规划活动中，我们会再回到这些地图。
4. 在您看来，项目成功最被低估的因素之一是什么？
a) 以结果为导向的思考：当我查看各类关于项目管理的研究（例如普华永道 PWC 的 Insights and Trends: Current Portfolio, Programme, and Project Management Practices, The third global survey on management）时，我得出的结论是：项目并非因 PM 知识不足而失败。我认为，太多时候是我们自己对项目工作的理解挡了路。项目工作远不止于编制和管理任务清单与成本计划。项目工作意味着在不确定性下交付成果。最重要的问题始终是：我们想交付或改变什么？在 ERP 项目中，提供技术系统并不是项目目标。用户需要的是特定功能。他们想打印发货单或发票。在 DMS 项目中，重点不是文档的归档，而是团队中各项事务的完成。为此我们才需要文档。项目结束后，我们想掌握哪些能力，或比之前做得更好？
b) 项目是被资助的，而不是被批准的：太多时候项目被视为成本制造者。敏捷社区在这一点上调整了视角。在他们看来，进行的不是项目，而是（预先）资助能赚钱（或省钱）的产品。从敏捷的视角，乃至 PRINCE2 的视角，经济性（业务价值、商业论证）都居于核心地位。在客户估算出项目成本之后，我常问他们：具体哪些工作方式必须改变，才能让企业从中获得两到三倍的回报？这些都是非常有意思的讨论。在真正敏捷的语境中，Product Owner 不是项目负责人，而是创业者。
5. 您最大的时间杀手是什么？
没有焦点的会议： 我看重 Scrum，因为它让「仪式」重新变回「活动」。每一项 Scrum 活动都有明确的焦点：要么我们在规划，要么我们在审视成果。重点不在于某个人已经做了多少事，而只评估成果。这能释放能量。在糟糕的项目里，会有各种状态例会，把过长的清单逐条嚼一遍。成年人又变回了向老师解释为何没做作业的小学生。糟透了。人们不去消除不切实际的规划的根源，反而对人施压。这个系统行不通。
超负荷： 在我们所有客户那里，在办事项的清单都太长。他们给自己揽的事太多，什么都要同时推进。在不同工地间切换会耗费大量时间。同时进行 5 个项目时，一名员工有 3/4 的时间都耗在项目间的切换上：参加各种项目状态会议、写和读会议纪要、做各种交接。这些都是不为成果增添价值、却极其耗费精力的工作。
非常感谢您抽出时间，祝您下一个项目顺利成功。
如果您对这篇博客文章有任何疑问或希望参与讨论，欢迎您在我们的论坛中发帖。
