S02E12 纠偏 项目思维 VS 产品思维
欢迎大家收听PM网事，今天我们开启一个新的板块，那就是纠偏系列，为什么要开纠偏系列呢？是因为我经常会看到和听到一些关于互联网行业项目管理的不正确的认识，这些不正确的认识会从一定程度上误导我们的创业者和从业者，并且可能会导致我们的失败。大家知道，PM网事希望可以帮助互联网行业的创业者和从业者取得更大的成功，所以如果我在行业里、在媒体上发现了一些不正确的认识，我就会通过节目发表我的观点。
今天我们纠偏的对象是一篇文章，这篇文章的标题是‘Product Thinking vs. Project Thinking’，是一个名叫Kyle Evans的外国人发表在了国外的网站上，因为这篇文章在国外受到了欢迎，所以国内就把这篇文章翻译成了中文，并发表在了几个著名的互联网媒体平台上，翻译过来的文章标题就是‘项目思维 VS 产品思维’。
我最开始看到这篇文章大概是在两个月前，看完之后我就觉得不大对，想看一下英文原文，这样好判断是否是翻译的问题，但我马上就发现中文版的文章里面附带的原文链接根本打不开，所以只好作罢。本来一开始我没打算去纠偏这个文章，但是当最近我再次在一个著名的互联网社区看到这篇文章的时候，我发现这篇文章已经有了一个很高的浏览量，不仅有人在收藏、点赞，更多的是在转发，我在想，这样一个通篇都充满了对于互联网行业项目管理有着错误认知的文章不知道又要误导多少人，所以今天我打算聊聊这篇文章，建议大家先搜索一下这篇文章，看完之后，再来听后面的内容。
我们先来看看这篇文章的主要结论是什么，总结下来主要有两个：
第一个结论：这篇文章认为，项目思维只关注交付，项目管理专注于日程表和产出，也就是output，而产品管理并不关注日程表，而是专注于要完成的目标和结果，也就是outcome。
第二个结论：项目思维注重预测，例如在项目的一开始就要预知如何实现预期结果，而预测很多时候是不准确的，一旦出现不准确的预测，就要花费很多的精力去弄清楚原因，并且还要按照原有计划完成项目，而产品思维完全不用确定日期和时间点，只需要专注于研究和实现结果，总之就是见招拆招、拥抱变化。
以上就是这篇文章最主要的两个结论，我初步总结了一下，至少有3个错误：
第1个错误：翻译的错误。这篇文章里到底有几个地方翻错了我不知道，但至少有一个地方一定是翻错了，那就是outcome翻成了结果。从这个错误可以看出，这篇文章的译者应该不是一名专业的项目管理者，因为，专业的项目管理者会有极高的概率把outcome翻译为成果，而不是结果，翻译成结果，就很容易把产出和结果这两个概念相混淆，事实上，我在这篇文章的评论区已经看见有读者弄不清这两者的关系了。
第2个错误：这篇文章对于项目管理缺少基本的概念。
项目管理，不管是传统IT还是互联网，其实都专注于商业价值的实现，在项目一开始的时候，就需要评估项目的商业价值以及对应的项目方案，在定义商业价值的时候，有三个基本的名词，前两个上面已经提到了，那就是产出、成果，还有就是收益，这三个词是依次排序的，对应到英文，就是output、outcome和benefit，在定义商业价值的时候，作为一个项目管理者，弄清楚output是第一步，另外我们至少要弄清楚项目的outcome是什么，也就是项目成果是什么，更进一步，最好是带着各个利益相关者弄清楚项目的benefit是什么，也就是收益最好能清楚，如果项目的收益清楚了，就表明项目的商业价值基本上也就清楚了。如果实在弄不清楚benefit，至少也要弄清楚outcome，如果outcome都弄不清楚，这个项目就不要做了，因为如果在项目开始前都想不清楚项目的商业价值，后面同样会想不清楚，不清楚商业价值的项目是不应该被启动的，这是项目思维的最基本要求。但是反观这篇文章，里面提到项目思维只关注最基本的output，产品思维貌似已经升高到了outcome，但最为奇怪的是，这篇文章却对更加重要的benefit只字不提，而且还建议项目思维应该提升到产品思维，说到这里我就真的搞不懂了，项目思维要是转换到了产品思维，这思维到底是提升了还是降低了？
第3个错误：这篇文章在潜意识里认为产品团队是封闭的，产品团队在所有的团队里面是最重要的。
我问大家一个问题：互联网时代对于组织和团队的基本要求是什么？我不知道大家的答案是什么，我初步总结了三点，就是开放、共享和协作，在之前的节目里我就提到过，项目是产品的基础，而项目恰恰非常好地满足了刚才提到的这3点，所以我看好以项目为基础和载体的产品团队，现在有些互联网组织出于效率和成本的考虑，将产品团队设计成了一个封闭的团队，对于提升效率的做法我是认同的，但是长期封闭的产品团队我是不看好的，因为这样的团队已经从根本上违背了互联网的精神。
另外，这篇文章提到，在做产品的时候，没有必要去做计划，而是应该去拥抱变化。这个观点其实并不是一点儿道理都没有，但是我想问一个问题：计划到底是干什么的？计划的作用非常多，在这里我只说一个，那就是，站在某个角度上看，计划其实是一个协作的工具和手段。
就拿没有计划来讲，没有计划就没有协作，除非是一个简单的产品或者是一个小版本，否则就会有比较大的概率涉及到多团队的协作，例如我们要发一个大版本，里面可能涉及到多个跨专业的团队，开发、UI、质量、运维这些团队就不说了，如果涉及到云端服务、设备、人力外包等方面的采购，和采购部门、法务部门、财务部门、外部供应商的协同是少不了的，如果涉及到用户的预热、引流等等，运营团队更是要按照一定的节奏去做准备，这还不包括业务部门，如果这些协作没有计划做支撑的话，具有产品思维的团队应该怎么去推进项目，怎么去实现outcome呢？具有产品思维的人不会真的认为，只要产品一声令下，所有团队的人都要放下自己手中的工作，第一时间来配合你吗？即便是第一时间来配合你，谁又能保证马上就能见到配合的成效呢？毕竟采购是要签合同的、审批是要走流程的、用户预热和流量的导入也是需要时间的。
另外，这篇文章对于计划也产生了很大的误解，认为强调计划就是拒绝变化，实际上恰恰相反，计划是在保障团队更有效地拥抱变化，计划是在保障拥抱变化之后还有可能实现项目的目标，没有计划的拥抱变化在相当的概率上会迷失方向，站在项目思维的角度上来看，一个迷失方向的产品将会被叫停。
说到这里，这篇文章中一些非常明显的错误我已经说完了，其实这篇文章里还隐藏着一些错误，但这些错误今天就不说了。
在这期节目的最后，我还是要声明，我尊重原作者Kyle Evans的观点和翻译的辛苦付出，但是，我并不认同这篇文章的观点。另外，同样是这一篇文章，可能不同的人站在不同的角度来解读会有不同的结论，无论是什么观点，我相信我们的初衷都是为了那些正在互联网行业拼搏的创业者和从业者们。
好了，今天我们就聊到这里，我们下期节目见。
