产品开发常见的五个陷阱与解决方案

通过为 Apple、Bose、Roche、IBM 等公司提供数十年的咨询服务，我们 TCGen Inc. 已经看到了我们在产品开发中所占的份额。我们倾向于在不同组织和不同行业看到许多相同的问题。它们中的大多数都很简单，都是可以避免的，但它们的影响却很大。  

以下是我们见过的五个最常见的产品开发陷阱，以及如何避免它们。

1.缺乏清晰的产品开发策略。 

清晰且易于理解的产品策略是必须的。产品战略在您作为公司的“真北”与您在产品计划中开发的内容之间提供了一条视线。然而，在太多的公司中，我们发现团队仍在研究与公司战略没有尽可能紧密相关的想法。开发团队和职能部门（营销、工程、财务等）都必须了解公司战略以及他们的工作如何适应其优先事项。

太多公司将战略隐藏在抽屉里。高管们将其视为最高机密，而这应该为包括个人贡献者在内的所有人所知。当产品开发策略与日常工作脱节时，团队成员常常会疑惑“我的工作是否相关？”

一个解决方案是有一个明确传达和简单的战略计划。该计划应在整个组织内传达，并且所有人都可以访问。它应该包括：

• 愿景：关于您希望您的公司在三到五年内达到的目标的广泛陈述。

• 战略文件：您打算在两到三年内实现该愿景的步骤。
• 产品和技术路线图、优先事项和预算，与实现该战略的具体计划相关联。

各个项目应该能够看到它们与战略和愿景的联系。获得正确的全局是在市场上产生共鸣的连贯战略和连贯品牌的关键。

2. 产品定义不佳。

糟糕的产品定义是我们看到的最常见的陷阱之一。在太多情况下，我们发现开发团队不知道要构建什么。产品负责人不清楚产品需求，而且需求通常没有充分植根于客户反馈。入站营销和开发团队之间的沟通并不总是清晰有效，通常是两种语言不同。

一种解决方案是明确识别客户群。确保你从他们那里得到直接的定性反馈。将这些客户研究活动整合到开发团队中。理想情况下，让团队成员参与，而不仅仅是专门的营销人员。 

接下来，优先考虑定性反馈。将这些定性数据转化为定量表达的需求。例如，如果客户在查看音频电子产品时报告“嗡嗡声太多”，则量化“太多”的程度。有一个信噪比得到优化的点，工程师不需要超过它。为允许的感知“嗡嗡声”数量创建一个阈值，并将其作为您产品定义的一部分。  

最后，由团队中的产品负责人明确每个产品的“需要”是什么。在我们的音频产品示例中，假设工程师试图将噪音水平降低到人类听觉感知以下。这不是“需要”。

任何产品都会有许多客户要求——只有少数几个会在竞争优势方面产生影响。有一个功能和要求的优先列表，并尽早并经常参考它。 

3. 项目监督无法增加价值并减缓决策制定。

当您的公司准备承诺进行重大投资或面临重大发布时，对您团队的进展进行审查是不可避免的。但很多时候，审查会变成高级管理层的干预，但收效甚微。许多评论过长、过于详细且价值不大。处于正确轨道上的团队被迫为其继续存在提供冗长的理由，以满足管理层对控制的渴望。 

有时会发生相反的情况。高级团队不会过多干预，而是会分心并忽视需要指导、需要更多资源来实现目标或面临只有高级经理才能解决的其他问题的团队。（这通常发生在营销或销售副总裁出差或不在办公室时。）这会减慢决策速度，造成代价高昂的延误。

为了避免这个陷阱，有几个但逻辑上合理的检查点。在一开始就为项目和产品建立一些关键参数。我们称这些参数为项目的边界条件。边界条件定义了团队希望在功能、产品和项目成本、质量、时间或其他成功因素方面达到的关键指标。如果团队在工作时认为它达到了这些关键指标的目标，那么管理团队就应该放过它们。

如果团队预见到它会违反一个或多个边界条件，则需要快速升级流程让高级团队知道，以便他们可以帮助使项目重回正轨。在我们的升级过程中，越过边界条件的团队必须 a) 立即通知高级团队 b) 提出解决方案。如果高级团队同意该解决方案，则它会通过电子邮件或 Slack 通知团队，而无需对问题出在哪里进行冗长的分析。重要的是让团队在几小时或几天内回到正轨，而不是几周。 

如果管理团队不同意团队的解决方案，则召开会议讨论如何解决边界突破，或改变有问题的边界条件。我们将这次会议称为越界 (OOB) 审查（参见下面的流程图）。一旦开发团队和高级管理人员达成一致，新的边界条件就建立起来，团队在此基础上继续进行。

4.项目资源不足导致功能瓶颈。

我们看到太多资源不足的产品。项目经理有太多的项目要做，而团队却缺乏关键技能。产品负责人也很紧张，他们与开发团队之间的沟通往往不够优化，导致产品定义不佳。 

此外，请确保您在团队中拥有足够的专业技能。每个产品负责人、Scrum Master、项目经理或项目经理最多只有两个项目。当这些经理的办公桌上有两个以上的项目时，效率和质量就会下降。根据我们的经验，瓶颈经常出现在这些角色身上。在与外部合作伙伴共同开发的地方，我们也会发现法律方面的瓶颈。 

这个陷阱的最终解决方案很简单：不要贪多嚼不烂。值得做的事情就值得做正确的事情，你需要足够多的熟练玩家才能正确地进行开发。在将项目经理逼入困境的同时，偷偷摸摸地过日子是再常见不过的事情了。它会导致倦怠、人员流失，并从长远来看对公司造成伤害。 

5. 职责不明确。

谁做了什么？这是一个基本问题。然而，您会惊讶于有多少组织没有回答这个问题。很多时候，团队不清楚谁负责哪个可交付成果。 

项目经理应该负责与产品开发相关的方式和时间，而产品经理负责原因和内容。但除了这些宽泛的定义之外，许多团队没有明确定义的工作流和可交付成果，每个人的名字都写在旁边。或者不止一个人有自己负责的想法，导致重复工作和混乱。 

即使团队本身明确了角色和职责，我们也看到过这些角色没有传达给职能部门或合作伙伴的情况。

解决方案是在项目开始时定义角色和职责。记录它们。通过将更广泛的任务分成更小的、一口大小的活动，使任务比您预期的更细化。为每一项可交付成果指定一名且仅有一名直接负责人。我们使用了RACI 图（下图）的修改版本，有助于保持一切正常。它还有助于制定沟通地图，阐明谁代表团队发言，谁与合作伙伴和高管交谈等。

避免陷阱

看到同样的错误一遍又一遍地重复是令人沮丧的，尤其是当它们是可以避免的时候。无需繁重的事后分析、冗长的变更管理计划或昂贵的 IT 购买，就可以避免上述许多陷阱。它们是人类的基础，也是我们变幻莫测的沟通方式——或者无法沟通的基础。