时间: 2021-08-03 10:44:06 人气: 18 评论: 0
在日常工作中，经常**接到明明是坑的项目，但是没有办法正所谓产品不入地狱，谁入地狱呢，关键是别让事情别的更糟就好。
永远不要相信计划**一帆风顺地进行至结束——要么风险已经来到，要么正在孕育更大的风险。
曾看到一句话说：企业家常常看到机**，而投资家则往往关注风险。我认为，产品经理不仅仅需要看到机**，更要看到风险。在项目启动之后，风险往往是导致项目走向失败的不稳定因素。
在吕克•贝松的电影《Léon》（国内翻译作《这个杀手不太冷》）中，马蒂尔达（纳塔丽•波特曼饰演）问了这样一个问题：
人生原本就是如此艰辛，还是只有童年如此？始终如此。
产品经理或许都想问一个类似的问题：所有项目都充满着各种风险，还是仅仅在刚入门时如此？我想借用Léon 的回答：始终如此。风险不可避免，从统计学角度看，项目出现问题的几率不**为零。
这句话不是哪位名人说的，是我个人的感触。经历了如此多的项目和版本迭代之后，我重新认识到了项目风险这个变量是多么麻烦。就拿我写作本书来看，把整本书看成是一个产品项目，已经经历了许多风险：
而在写书计划开始之前，我对于写作的评估还是预留了一个月的缓冲期，得出结论需要半年时间。但显然写作这件事情并非是一种累加工作量和时间就可以保证质量产出的项目，未知的因素太多：时间不够、精力不足、生病、没有灵感、缺乏有力的证据和案例、把时间耗费在查找资料上……而我个人作为项目的工程师，同时也是项目经理，可以随时调整自己的时间计划，尽可能地赶上截稿日，但如果是多人参与的项目呢？或者是真正的产品项目呢？
在经历了如此多的项目之后，我得出了本节开头的那句话，项目出现问题的几率不**为零，即没有不存在风险的项目。
曾经跟进过一个很简单的需求，按照之前的工作量评估只需要3 天就能完成，但由于涉及前后台联调，期间出现了许多意外。开发工程师请假、后台测试环境搭建有问题、联调的时候又出现意外、因为节假日造成拖延，总之这个需求前前后后一共做了10 天。这仅仅是一个小需求，而整个项目肯定不只10 个这样的需求。对于项目来说，这种隐性的未知风险越多，延期的情况**越严重。项目延期可不是一件好事情，不仅有可能错过最佳的发布时机，还有可能引起团队内部的不稳定——毕竟时间越拖越久，每个人都容易产生不满情绪。
出现了问题就需要去解决问题，团队内部存在这样一种角色：项目经理。项目经理的职责很简单：团队和项目的所有事情都和他有关。有的团队可能是由产品经理去兼职项目经理的职务，但对于一些大团队来说，项目经理的出现大大减轻了产品经理的工作。比如，产品经理只需要关注产品并保证质量和用户体验即可，不需要考虑太多排期和资源的问题。但如果需要兼职做项目管理的工作，产品经理就无法很用心地把时间花在产品上，而需要不断开**沟通，不断协调资源。
产品经理同时兼任项目经理的最不好的情况是，为了避免延期而做出砍功能的决策，但往往砍功能又**陷入另一种困境。为了打造最佳的产品体验，每一个功能都有对应的作用，如何决策又成为了一个难题。
那么如何解决问题呢？项目经理常用的手段是建立流程——通过流程来把控项目的进度，这又是一把达摩克利斯之剑。良好的流程的确可以让每个决策、每个风险和难题都拥有处理依据，可以快速定位问题并解决问题。但流程如果不起作用，则是团队中所有人的灾难，产品经理**抱怨流程复杂影响产品迭代；开发人员则抱怨时间太紧张，不允许给出一些缓冲时间；测试人员则**认为整个流程化的结果虽然好，但万一开发阶段就出现了问题，**让测试工作更加难以展开。
项目经理可能**据理力争，你们没有完全按照流程来进行——但流程其实也有缺陷，比如流程化影响了快速迭代的方式。产品经理发现了问题应该直接找开发工程师修改，然后由测试工程师尽快验证并得出结果，但流程意味着这些都需要一步一步通过审批的方式来处理——这也是一种风险。
所以风险无处不在，我们所能做的并非是拒绝风险，而是迎接风险并快速响应。正如下雨天，我们即便没有撑伞，也不应该继续在街头慢悠悠地走着，而是快速跑到避雨处或者寻求雨伞等可以解决问题的方案。
项目中的风险管理提到风险，不得不提到一本书《黑天鹅》。作者塔勒布在书的开头这样描述：在发现澳大利亚黑天鹅之前，所有欧洲人都确信天鹅全部是白色的。这是一个牢不可破的信念，因为它似乎在人们的经验中得到了完全的证实。对一些鸟类学家（以及非常关心鸟类颜色的其他人）来说，看见第一只黑天鹅大概是一种有趣的惊奇体验，但这还不是澳大利亚发现黑天鹅的重要性所在。它说明我们通过观察和经验获得的知识具有严重的局限性和脆弱性。仅仅是一次观察就可以颠覆上千年来对白天鹅的数百万次确定性观察所得出的结论。你所需要的只是看见一次黑天鹅就够了。
但我从中受益最多的是这样一种视角：经验不一定是可靠的。正如我周六下午一如既往地带着猫咪去宠物店洗澡，但宠物店老板告诉我今天这里都是狗，不能给猫洗澡。按照以往6 次经验，周六不**出现如此紧张忙乱的情况，而且狗的数量也大大**过了从前。这不是关键，关键是我今天有一个重要紧急的事情需要处理，顺便出门把猫带去洗澡——这一意外直接干扰了我的计划，导致我不得不花费更多的时间。原本我可以出门一次就完成两件事情，但因为意外，我不得不在路程上多花费一倍的时间。
产品进入项目周期的时候同样**出现这样的问题。有一次开发工程师评估了两个需求，觉得可以一起做，于是就把工作时间缩减了一下。结果在开发过程中发现两个需求的后台机制是不一样的，严重影响开发时间。这就类似“猫咪洗澡”事件。最开始大家都很开心可以在5 个工作日完成两个需求，结果发现这两个需求要花费10 个工作日，这种风险对于项目来说是致命的。
著名的项目管理书《人月神话》提出了一个有意思的问题：在项目中增加更多的人手能不能提高效率，从而在更短的时间内完成项目？100 等于25 乘以4，也等于50 乘以2，这是一种线性计算。但在项目中并非如此。100 人•日的工作量并不**因为开发人数增加一倍而变成50 人•日，很有可能还是100 人•日，甚至是**过100 人•日。
人月神话（The mythical man-month）：讲述了人力（man）和时间（month）并不呈现线性关系。指出投入大量人员并不能缩短软件的开发进度。一窝蜂式的作业方式无助于软件生产，而且**制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只**使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。若有N 个人必须在这群人之中进行沟通（无阶级关系），当N 增加，其沟通所消耗的M 将抵消其产生的效益，甚至出现负增长（最后几天所完成的进度，远不如刚开始几天所完成的进度，像是发现了许多错误）。
不过这种计算方式是在一个宏观层面上去看待项目，落实到实际操作中时，还**源源不断地出现各种问题。举例来说，有一次，产品有一个业务需求是由兄弟部门支持的，之前都定了合理的时间，并保证了质量。最后出现了大家都没想到的情况——这项业务涉及的一些功能无法通过App Store 的审核，不得不打回，重新修改然后上架。对于本团队需求来说，及时调整和修改还算比较敏捷，但对于外部业务来说，沟通的成本和修改的成本就大大提高了——业务需要考虑修改了之后是否**对产品产生影响，功能是否**因此减少，体验是否**有明显的降低。
对于测试人员来说，每一次的发布都是工作量最饱和的时候，因为大量的修改都需要验证通过之后才可以发布。何况，这仅仅是一次可以规避的意外，还有许多未知的事情在寻找机**发生——这就是风险所在。
对于新人来说，风险更容易出现。我并不否认经验对于工作和降低风险的重要作用，但往往有一些事情无法被预知。恰如混沌**中的“蝴蝶效应”，牵一发而动全身。初为产品经理时，我曾遭遇过两个与此相关的事件。
事件一：风险的出现起源于一份没有说清楚的需求文档。当时我交付了对应的需求文档，但由于缺乏经验，对于细节的把握少有提及，往往是把交互操作和页面跳转的逻辑重述了一遍，忽略了对于字段长度的限制、意外情况展示等方面的描述，导致开发人员对此理解有偏差。但当时我和开发人员并没有建立很紧密的关系，双方都按照各自的理解进行工作，没有及时沟通，甚至在需求评审的过程中也没有对细致的结果进行充分沟通。随着开发时间的逼近，我开始体验功能时才发现了许多小问题没有解决。本以为这些小问题可以很容易地处理，结果被告知整个实现方式并不能修改为我想要的效果，不得不推翻方案重新开发。
在这个事件中，沟通是最大的问题。但如果产品经理有经验，一开始就确认一些细节问题，并及时跟进体验，多与开发人员进行交流，可以避免很多问题。
事件二：无法被预知的风险才是最可怕的事情。当接近开发尾声的时候，发现老板要把方案进行调整。此时就**遇到一个棘手的问题：如果要按照方案调整，就不得不推倒重来；但重来的话，**影响到整个项目进度。于是不得不找到开发人员的负责人和项目经理重新商议此事。这种临门一脚的调整往往有可能带来许多烦恼。
所以，我们不得不把风险永远地列入产品经理和项目经理的关键词列表。关于风险的概念不需要我再多做解释，唯一可以承认的事实就是：无法预测。
正如时间的流逝，风险的存在并不是一个可控的问题，也不是一个管理问题，而是如何应对的问题。我们无法完全地杜绝风险，而应该迎接风险。正如LinkedIn的创始人霍夫曼在《至关重要的关系》一书中所提到的：风险常在，因此我们所有人都得去冒险。但是，在面对风险的时候，并不是所有人都能聪明地应对。许多人认为，最小化风险就能获得稳定的事业。但是，相当讽刺的是，在一个千变万化的世界里，这**是你做的最具风险的事情之一……
风险因人而定，而且是动态变化的。
所以，让我们迎接风险，学**与风险并存，及时发现风险，管理风险，这是应对不断变化的现实的最佳策略：趁势而为。
不过，就算我们承认需要主动地与风险打交道，还是面临这样的问题：
作者：mary
via：**大讲堂
