开发者俱乐部

标题: 产品失败的十大根本原因，任何一条都足以摧毁一个团队！ [打印本页]

作者: wangshengrui23 时间: 2017-3-7 16:47
标题: 产品失败的十大根本原因，任何一条都足以摧毁一个团队！

　　
　　我看到在绝大部分公司用的都是相同的基本工作方法，我不禁想提醒这和那些好公司的实际工作方法相去甚远。
　　我不得不提醒你这讨论出的结论可能会非常令人沮丧，甚至你觉得有点太打击人，如果是这样，我觉得你可以停在这里不必往下看了。
　　让我们从绝大多数公司仍在用之创造产品的过程开始，我会试着不发表评论，我们仅是描述这个过程：
　　任何事情都始于想法。在大部分公司，想法来源于执行董事，或者关键的利益相关者，或者企业主，或者大客户（或潜在客户），但是任何情况下业务的不同部分都有一大堆事情需要去做。
　　现在大部分公司想要在路线图中确定这些想法的优先顺序，他们这样做基于两个理由。首先，他们想要我们优先专注于最有价值的事情，其次，他们想预测事情何时能准备好。
　　为了做到这一点，通常会有某种形式的季度或者年度计划会议，会上领导就这些想法思考并协商出一个产品路线图。但是为了确定优先顺序，他们首先需要为每个项目提供某种形式的商业案例。
　　一些公司会形成正式的商业案例，一些则是非正式的，但不管是哪一种，归根到底，关于每个想法都需要了解两点：
　　它将赚多少钱？它将花费多少时间或金钱？
　　然后用这些信息来提出下一个季度有时也可能是一年后的产品路线图。
　　在这一点上，产品和技术部门有他们自己的工作节奏，通常是按照项目的优先顺序，从最高优先级依次往下走。
　　一旦一个想法被确定为最高优先级，产品经理需要做的第一件事就是和项目利益干系人讨论，将想法具体充实化，并提出一系列的“需求”。这有可能是用户故事，也有可能是某种形式的功能细则，但目的都是为了和设计师以及工程师沟通需要创建的是什么。
　　一旦需求被收集起来，用户体验设计团队（假设公司有这样一个团队），就需要提供交互设计，视觉设计，以及物理设备情况下的工业设计。
　　最后将需求以及设计细则交给工程师，这时敏捷开发最终登场。
　　无论如何，工程师通常会将项目划分成一系列的迭代——在敏捷开发模型中这称之为“sprints”。想法构建出来可能需要1- 3 次敏捷迭代。
　　很希望QA测试是这些敏捷迭代过程中的一部分，如果不是，QA团队应该用其他的测试跟进，确保新产品和宣传的一致，同时不会引进其他问题（称之为“回归”）。
　　一旦我们在QA团队那拿到了绿灯，新想法可以最终部署给真实客户了。
　　在我第一次见面的绝大多数公司，无论大小，重要的是他们的工作方式，并保持这样的方式工作了很多年。但也同样是这些公司，他们不断抱怨着缺乏创新，从想法到落地需要非常长的时间。
　　你也许已经意识到，当我提及敏捷开发的同时，几乎今天的每个人都宣称是敏捷开发，而我刚刚描述其实更多的是瀑布过程。公平说来，对于工程师，如果他们能够给更广阔的瀑布环境，他们能做的其实和敏捷开发一样多。

　　OK，既然大部分团队都是敏捷开发，但为什么那是如此多问题的必要理由呢？
　　我现在想做的就是将这些点连接起来，向你展示为什么这种普通的工作方式要实际为大部分失败的产品努力负责。

　　最严重的 10 条问题
　　关于这个问题我可以畅谈一整天，但我即将分享的是我认为这种工作方式中，最严重的 10 条问题。更清楚一点，我所讲的这十条都是非常严重的问题，其中任何一条都足以摧毁一个团队，但大部分公司占了这十条中的大多数，甚至，全中。
　　1.让我们从最上面那条开始——想法的来源。这种模式导致了销售驱动特价，以及利益干系人驱动产品。想法的来源有很多，但是这不是我们产品想法的最佳来源。这种方式的另一个结果是团队缺乏自主权——在这种模式中，他们只是在那儿执行，就像一个雇佣兵。
　　2.接下来我们谈一谈这种商务案例中的致命缺点。我实际是支持做商务案例的，至少对于想法需要一个更大的投资。但与此同时，大部分公司在这阶段做商务案例，为了想出一个确定了优先顺序的产品路线图，确实是可笑的。为什么？还记得每个商务案例中两项关键的投入是什么吗？你会赚多少钱？它又会花费多少？冰冷的现实是，在这一阶段，两者我们都不会有答案，我们不可能知道。
　　我们不可能知道我们会赚多少钱，因为这很大程度上取决于我们的解决方法会变得有多好。如果团队表现杰出，这可能会取得巨大的成功，的确有可能会改变公司的进程。另一方面，许多的产品想法会落得一场空。这并不是夸大其词。确实是什么都没有。任何情况下，产品中最重要的一课是明白——什么是我们不可能知道的，在这个阶段我们不可能知道的是，我们能赚多少。
　　同样地，我们也不可能知道构建出这个想法需要花费多少。在不知道实际解决方法的情况下，工程师是很难去预测的。在这个阶段，大部分有经验的工程师甚至会拒绝去给出一个估算，但有些工程师迫于压力，只好作出老式“T恤size”式的妥协——仅仅让我们知道这预算是“小的、中等的、大的还是特大的”。
　　但公司高层确实想得出确定了优先顺序的产品路线图，为了得到它，他们需要某种系统来评估想法，所以人们就玩起了商务案例的游戏。
　　3.一个更大的问题来了。公司对他们的产品路线图感到十分兴奋。我见过数不清的路线图，绝大多数确实按照特征确定了优先顺序。市场需要这些特征来搞商务活动，销售需要这些特征来招徕新客户。一些人则想要一个PayPal集合。你懂的。
　　但是这里有一个问题，也许是其中最大的问题，我把这称之为“不愿面对的两个产品真相”。
　　第一个真相是，我们的想法至少有一半是不能被实现。一个想法不能被实现有许多理由。最普遍的是，客户不会如我们一样对想法感到兴奋。所以他们不会选择去使用它。有时他们想去使用它，但是他们试过之后发现它是如此的复杂，麻烦远大于它的价值，所以导致了同样的结果——用户不会选择去使用它。有时问题是客户很喜欢它，但要实现的东西远超出我们的想象，我们并没有足够的时间和金钱来实际实现。
　　所以我向你保证，你的路线图中至少有一半不会如你所愿实现。同时，真正好的产品团队认为，至少有四分之三的想法的表现都会不尽人意。
　　如果这还不够糟，第二个不愿面对的真相是，尽管这个想法被证明有潜力，它通常需要经过几次迭代之后才能实现它的想法传递真实商业价值。我们称之为 “时间就是金钱”。
　　我所学习到的关于产品最重要的一点是，无论你有多聪明，都逃不过这些真相。我曾有幸和许多杰出的产品团队工作。真正的差别在于你如何处理这些真相。
　　4.接下来我们要谈论的是这种模式下的产品角色。事实上，我们根本不用把这个角色称之为产品。它实际上只是一种项目管理的形式。在这种模式下，它更多的是收集需求并为工程师们记录下来。在这一点上，我们可以说，它离现代产品管理差了 180 度。
　　5.关于设计的角色也是同样的故事。设计发挥真正的价值已经太迟了，他们所做的大部分工作，我们称之为“给猪涂唇膏”。破坏已经造成，现在我们只是尽力去给这堆乱七八糟的东西画上一件外衣而已。UX设计师知道这并不好，但他们还是尽可能地让它看起来好一点，看起来一致。
　　6.在这种模式错过的最大机会也许是工程师完成得太晚。我们说如果你只是用你的工程师码代码，你只是得到了他们一半的价值。产品里有个小秘密是，工程师其实创新最好的单一来源，但他们甚至都没有被邀请参加这个过程的party。
　　7.不仅是工程师带进这种方式太迟了，敏捷开发的原则以及核心利益进入得更迟。团队也许只发挥了敏捷方式真正价值以及潜在价值的20%。你真正看到的是敏捷用于交付，但是剩下的组织以及环境根本不敏捷。
　　8.这整个过程是非常以项目为中心的。公司通常会为项目提供资金，人员并通过组织推动这些项目，最终启动项目。不幸的是，项目只是产出（output），而产品则是全部的结果(outcome)。这个过程预见性的导致了孤立的项目。是，某个东西最终会发布，但它没有达到它的目标，所以真正的那个要点是什么？在任何情况下，这都是一个严重的问题，它并没有达到我们需要构建的产品预期。
　　9.老的瀑布流进程一直以来，并且还会持续的一个最大缺点是，全部的风险都在最后。这意味着用给客户验证的时间太晚了。
　　你也许听过精益生产法，这是大部分人的选择。关键原则在于减少浪费，而最大的浪费形式之一是设计、建筑、测试以及配置功能或者我们并不需要的产品。讽刺的是许多团队认为他们正在使用精益法，但是他们进程的跟进就如我刚刚所描述的。他们实际正尝试的是我们现在所知道的最昂贵、最慢的方法之一。
　　10.最后，我们忙于这个过程的同时也是在浪费时间和金钱，结果最大的损失在于机会成本。组织原本能（could）拥有，现在却成了应该（should）拥有。时间和金钱一去不复返。
　　对于我来说，大量的公司花费大量的时间和金钱却收效甚微，这并不奇怪。我警告过你，这可能是非常令人沮丧的。
　　好消息是我保证最好的团队从来没有发生过如我刚刚描述的事情。
　　关于最好团队是如何工作的，我从不同的方面写过许多文章。产品探索是指我们如何用成功的方法解决我们正在面临的问题。探索是一种产品、用户体验设计以及工程开发之间积极的、不间断的合作。持续的探索与持续的交付并行。路线图（output）上的特征被解决业务问题（outcome）所代替。目标是产品／市场契合。
　　如果你的公司还在用这种老的早就被淘汰了的过程，我希望你能发光，开始向未来过渡。并希望你在做之前发现，你已经被比你更快更具有效率的初创团队或者竞争对手所打破。

欢迎光临开发者俱乐部 (http://xodn.com/)