项目经理值得一试的思维方式：项目成功方程式
原创
“有没有一个一劳永逸的项目管理实践？”
“我怎样才能找到一个能够解决所有问题的方法？”
“为什么我用的都是同样的方法，但有的项目延期了？”
……
在很多敏捷群中，经常会有人问这些问题。那有没有一个可以解决所有问题的方法呢？答案是：没有，因为没有银弹。
早在1986年，弗雷德·布鲁克斯就曾在学术角度提出：没有能解决软件危机的银弹。为什么呢？其最根本的原因在于，软件本身有以下固有特性：
- 复杂度：软件复杂度会随着规模呈现非线性增长，出现项目成本超支、人员状态不同步、功能可用性差、结构复杂等问题；
- 一致性：软件系统需要与现有系统进行交互，这就需要让新软件系统的接口与原有软件系统保持一致；
- 可变性：由于用户需求、市场等外在因素是持续变化的，这要求软件需要具备可变性；
- 不可见性：每个人对软件、需求或任务都有不同的理解，这会让沟通变得异常困难。
这些特性在软件交付项目中会产生诸多挑战，降低团队效能，甚至会导致项目失败。
面对这些挑战，我们并非没有办法。虽然在软件交付项目中没有银弹，但项目成功是一系列因素共同作用的结果。我们只要找出能够影响项目过程的因素，并立刻行动，就能推动项目成功率提高。我们可以通过一个思维方式——打造团队的项目成功方程式来推动项目成功：
从上面这个项目成功方程式，我们可以得知，项目是否成功交付，取决于各个因素的界限值。在项目中，低界限的因素将决定整个项目的上限。也就是说，如果将项目中每一个因素都能从1提升到1.01，多项的相乘也将产生巨大的成果。相对应的，如果将每一项都降低为0.99，比如管理粗糙“一点”、价值降低“一点”、行动慢“一点”……这样的项目就会漏洞百出。
那如何将项目中的因素从1提升到1.01呢？以下行动路径可以给大家一些帮助：
项目因素 | 具体行动措施 | 要求 | |
|---|---|---|---|
立即行动 | Plan-Do-Check-Action | Talk is cheap. Show me the code. | |
项目管理过程 | 需求阶段 | 规范用户故事进行需求评审确认需求优先级缩短迭代周期合理估算规模 | 合理把控产品交付计划。 |
开发阶段 | 代码规范代码集体所有源代码管理代码评审重构现场客户 | 通过众多工程实践提高项目成功率。 | |
测试阶段 | 尽早测试自动化测试为测试人员赋权 | 通过提高测试质量，加速项目成功。 | |
过程改进 | 回顾会议 | 不断优化整个项目过程，实现过程改进。 | |
团队 | 避免分布式团队组建跨职能团队每日站会或看板 | 与团队中其他成员及时同步自己的任务状态，及时发现并解决日常问题。 | |
工具 | 通用的禅道项目管理工具Axure、墨刀等原型制作工具XMind、FreeMind等思维导图GitHub、GitLab等源代码管理工具Selenium等自动化测试工具ZenData等测试数据生成工具 | 借助工具，提升工作效率。 | |
时商 | 在热门与价值中间做出选择保持自律奉行长期主义 | 合理运用时间，创造更大价值。 | |
管理方式 | 学会倾听向下放权拥有同理心正确的价值观树立全局观 | 通过打造服务型领导，鼓励团队之间的信任与合作，充分调动团队成员的主动性与积极性。 | |
产品价值 | 用户价值商业价值社会价值 | 产品价值在整个项目成功方程式中是最特殊的一环：只有产品产生了价值，项目成功才会有意义。 | |
项目成功方程式只是帮助项目经理们更好地思考问题的一种方式，项目成功受多方因素影响，上面列举出来的并非影响项目成功的全部因素，因此项目相关成员可以根据自己的经验和教训，不断地扩充这一项目成功方程式，改进团队项目管理方式。和我们一起来寻找每个项目的最佳实践吧。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。