标签： 项目

首先我想澄清的是：项目管理本身没什么问题，但是把项目管理用在产品管理上这就是问题了，可惜90%的软件开发都是软件产品开发。在我接触到的公司或案例中，项目管理在软件产品开发中带来的伤害要远多于好处。 项目管理 维基百科上项目管理以及项目的定义： Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time. A project is a temporary endeavor designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. https://en.wikipedia.org/wiki/Project_management 这里面有几个关键：明确的开始，明确的结束，明确的目标，临时的。据我所知，这些在大多数的软件产品开发中都很少见。多大概率你在工作中碰到的需求、产品、功能说在一个时间点结束就真的在这个时间点结束了？总会有各种形式的修改，修Bug，增加，删减等。软件开发中也几乎没有什么临时的，很多时候我们碰到一些“临时”的功能或任务实际存在的时间可都不短，有的甚至比我在公司待的时间都长。 项目管理的思维包含着可预测性。大家可能都知道项目管理的铁三角：范围、时间、成本。 需求的范围，各种时间节点，需要的成本（主要是人力成本），这些是评估一个项目管理是否成功的重要因素。一个项目在预期的时间内按照一定的成本完成了全部的功能，从项目管理的角度来看确实很棒。但是这个项目就真的成功了吗？某大型企业有过一次回顾讨论，他们有个项目按时按量交付了，还没有bug！但是大家都不觉得这个项目成功了，为什么？没有人买也没有人用，当然没bug了。 项目管理的思维方式可能会带来的问题： 长时间的计划 项目管理需要控制成本，因此需要一开始分析或“翻译”需求，明确范围，估算工作，制定预算，我见过不少项目在计划上的时间都多于开发交付的时间。 大量并行项目 计划的时间长，往往意味着同时进行的项目多。我还见过有的公司里一个需求就是一个项目，同时有几十个项目并行很常见。大量并行的项目会使这些项目的计划，追踪等更加的复杂。你可以想想许多公司根据项目抽调人员，还有很多角色是共享的，比如UI/UX，测试，运维等等，再加上项目和项目之间还会有些依赖，要做所谓的“排期”就已经十分的头大了，再稍微有些延期或其它变化就一团乱了。 争夺人员与资源 前面也说道按项目抽调人员是比较常见的现象，因为每个项目为了每个项目的成功都会尽可能的争夺对该项目最有帮助的人员或资源。因此产生的斗争和内耗也会很多，这是典型的局部优化。往往公司里能力越强的人同时做的项目越多，这个人会自己决定手头上事情的优先级。而且也会导致这类人的工作效率的下降，因为需要频繁的切换工作上下文。 关注在需求范围而非目的 项目结束时，大家更关注需求是否做完，也就导致项目过程中关注于计划的执行情况，这些需求本身有没有完成。大家会更少关注于这些需求背后的目的是否达成，是否有在产生价值。我们需要更多的关注产生的影响（Outcome），而不是我们的工作产出本身（Output）。这就要我们不断的验证假设，收集反馈，调整方向。 实现不必要的功能 项目就像一个容器，我们会对里面的“所有东西”进行计划，分析，设计，实现，测试，发布。但是从产品或业务的角度来看，这些都是成本，但是不是都产生价值呢？而且这些不必要功能的存在也会带来维护成本。我们是不是应该对项目的需求范围进行质疑，而不是一味的遵循呢？ 降低质量 项目管理更加看重时间和成本，所以当截止日期逼近的时候，大多数开发人员会迫于可种压力在时间和质量之间作出选择，这是质量往往是被妥协的。有时他们选择不重构，不做单元测试，甚至不自测，甚至使用各种秘密武器：复制黏贴，从网上抄一段代码等等。技术负债就这样积累起来了，代码库变的难以维护，后续功能调整越来越难，成本越来越高。对于测试也是一样，测试的压力更大，测试强度也会减弱许多，比如不做回归测试或更小范围的回归测试，测试路径覆盖更少等。很多时候这种质量问题的结果并不会立刻显现。 产品负责人与项目负责人 这里产品负责人并不仅仅指Scrum中的Product Owner，项目负责人有可能是Project Manager或Program Manager。通常这两种角色有着天然的冲突，产品负责人关注价值，项目负责人关注计划的执行。项目负责人占上峰时，产品负责人失去对产品的控制力，只是负责管理需求列表；产品负责人占优势时，项目负责人只有职责却缺少实际控制力。我见过有的公司产品负责人还同时管项目，通常产品负责人大多数时间变成各种事情的协调员，甚至前后端的技术协调。 所以，你得弄清楚你真的是做临时项目吗？如果不是，那么你应该用产品思维来管理。产品通常是长期存在，关注于为客户带来价值，你会持续的对其进行修改、改进、扩展。当然你需要持续的迭代，尽快的从客户或最终用户那里收集反馈来调整后续的工作。即使你是做软件外包项目，如果你和客户是长期合作关系，依然你可以用产品的方式来做，因为你的开发过程会更加的顺畅，而客户可以获得更多的价值。 PS，有些公司搞所谓的“敏捷转型”也立个项，用项目管理的方式来做。我也是不赞同的，因为这样很容易变成只是在有限的时间内把一些实践给搬到组织内，未必产生实质性的效果，也不利于持续学习与持续改善。我们应该像开发产品一样，不断的试验调整来进行持续的改善我们的研发过程。...