产品失败的十大根本原因，任何一条都足以摧毁一个团队！

翻译：@Yibo设计

我看到在绝大部分公司用的都是相同的基本工作方法，我不禁想提醒这和那些好公司的实际工作方法相去甚远。

我不得不提醒你这讨论出的结论可能会非常令人沮丧，甚至你觉得有点太打击人，如果是这样，我觉得你可以停在这里不必往下看了。

让我们从绝大多数公司仍在用之创造产品的过程开始，我会试着不发表评论，我们仅是描述这个过程：

任何事情都始于想法。在大部分公司，想法来源于执行董事，或者关键的利益相关者，或者企业主，或者大客户（或潜在客户），但是任何情况下业务的不同部分都有一大堆事情需要去做。

现在大部分公司想要在路线图中确定这些想法的优先顺序，他们这样做基于两个理由。首先，他们想要我们优先专注于最有价值的事情，其次，他们想预测事情何时能准备好。

为了做到这一点，通常会有某种形式的季度或者年度计划会议，会上领导就这些想法思考并协商出一个产品路线图。但是为了确定优先顺序，他们首先需要为每个项目提供某种形式的商业案例。

一些公司会形成正式的商业案例，一些则是非正式的，但不管是哪一种，归根到底，关于每个想法都需要了解两点：

1. 它将赚多少钱？
2. 它将花费多少时间或金钱？

然后用这些信息来提出下一个季度有时也可能是一年后的产品路线图。

在这一点上，产品和技术部门有他们自己的工作节奏，通常是按照项目的优先顺序，从最高优先级依次往下走。

一旦一个想法被确定为最高优先级，产品经理需要做的第一件事就是和项目利益干系人讨论，将想法具体充实化，并提出一系列的“需求”。这有可能是用户故事，也有可能是某种形式的功能细则，但目的都是为了和设计师以及工程师沟通需要创建的是什么。

一旦需求被收集起来，用户体验设计团队（假设公司有这样一个团队），就需要提供交互设计，视觉设计，以及物理设备情况下的工业设计。

最后将需求以及设计细则交给工程师，这时敏捷开发最终登场。

无论如何，工程师通常会将项目划分成一系列的迭代——在敏捷开发模型中这称之为“sprints”。想法构建出来可能需要1- 3 次敏捷迭代。

很希望QA测试是这些敏捷迭代过程中的一部分，如果不是，QA团队应该用其他的测试跟进，确保新产品和宣传的一致，同时不会引进其他问题（称之为“回归”）。

一旦我们在QA团队那拿到了绿灯，新想法可以最终部署给真实客户了。

在我第一次见面的绝大多数公司，无论大小，重要的是他们的工作方式，并保持这样的方式工作了很多年。但也同样是这些公司，他们不断抱怨着缺乏创新，从想法到落地需要非常长的时间。

你也许已经意识到，当我提及敏捷开发的同时，几乎今天的每个人都宣称是敏捷开发，而我刚刚描述其实更多的是瀑布过程。公平说来，对于工程师，如果他们能够给更广阔的瀑布环境，他们能做的其实和敏捷开发一样多。

OK，既然大部分团队都是敏捷开发，但为什么那是如此多问题的必要理由呢？

我现在想做的就是将这些点连接起来，向你展示为什么这种普通的工作方式要实际为大部分失败的产品努力负责。

（编辑：ASP站长网）