本文系译文：关于将设计思维与敏捷开发相结合的尝试 —— 成功与失败剖析"

• 作者：BrianNeisler
• 译者：Aceyclee

我们所说的设计思维，是指由 IDEO 公司的 Tim Brown 提出，并且正在改变全世界组织的设计思维，简称 DT。（译者注：IDDO，当代最具影响力的设计公司之一）

该理念承诺带来更高的生产效率和创新，促进与用户建立更好的联系。

听起来很不错，对吧？所以我们亲自尝试了一下。

在这个过程中，我们取得了一些进展，也经历了一些挫折，还遇到了一些其他事情。
如果您正在考虑采用设计思维，或者只是大体上考虑您的产品流程，不妨继续阅读本文，了解下我们的尝试。

设计思维在科技公司中是什么样的？

简而言之，设计思维流程针对的并非如何执行，而是如何在一开始决定应该构建什么内容。

它以一个紧密的用户驱动型反馈环路为中心。理论上，这个闭环可使您在开始写产品代码前尽可能迅速地验证新的功能想法：

image

对于我们这样的科技公司，设计思维意味着：

1. 共鸣：产品团队理解用户的反馈。
2. 定义：产品团队将反馈纳入问题池中。
3. 设想：产品团队和工程团队集思广益，共同提出关于如何解决问题的想法。
4. 原型：产品和研发团队采纳最佳想法并共同构建出一个或多个原型。我们不会保留这些代码，它们仅用于验证。
5. 测试：将解决办法提供给用户，看看是否解决了用户的问题。
6. 实施：如果解决了问题，由研发团队构建相应的实际产品。

其结果是新功能首先在小范围的产品中提供，然后由用户验证，最后才进行实际的开发工作。

这个过程中还有一个关键点：公司的所有部门之间会一直沟通。销售部门不会在几次交谈后就告诉工程部门应该构建什么产品，产品部门也不会告诉销售部门直接卖我们想做的产品。

每个部门都会和用户沟通，然后共同提出产品战略。

过程：我们如何将设计思维和敏捷开发结合？

敏捷的好处在于您可以将项目细化，以便确定更合理的优先级。设计思维可同时在微观和宏观层面上支持实现敏捷。

微观层面上，设计思维可用于验证各项功能。它符合敏捷框架，可帮助我们在迭代计划时始终专注于优先级最高的项目。

宏观层面上，设计思维使一切工作回归于公司的愿景，提醒我们不断重新评估当前工作，以长期为我们的用户提供更好的服务。

设计思维似乎天生适合我们公司。

具体细节：我们完整的内部过程

现在介绍我们在 Serverless 公司内部是如何开展设计思维这六个步骤的。

共鸣：
我们在 Confluence (Atlassian) 上设置了一个产品类别板，公司的任何人员均可提交用户问题。这些问题来源于任何真正可以发现实际用户问题的地方，包括直接的用户访谈、文章、论坛话题、漏洞报告和个人经历等。

设想：
任何人员还可以提交如何解决已确定用户问题的想法。我们的提交指南明确规定了所有解决方案均应从用户的角度进行阐述。有什么作用？要执行什么操作？期望产生什么结果？

定义：
产品团队每周审查类别版块，对需要进一步验证或需要进一步发现的内容加以标注。
在审查的基础上，我们会对每个项目分配以下一个优先级：

• 产品待办事项列表（高优先级）
• Icebox（低优先级）
• 否决（直接拒绝）

原型：
产品团队查看待办事项列表，并共同拟定我们接下来要关注的原型。工程团队接收原型，并将它们纳入敏捷规划管道。

测试：
如果一切符合要求，并且该想法可以很好地解决实际的用户问题，我们会将其转换成提案，纳入到中期路线图中。

实施：
这些提案阐述了我们接下来 3-6 个月之内要在生产环境中实际构建的最佳构想产品。此外，我们还会进一步围绕每个提案定义 KPI，以便可以不断地衡量所取得的成功。

目前有什么作用？

设计思维目前的确给我们带来了不少积极影响：相比于我们想一次性执行的大项目，我们的工作更专注于组成整体的细小部分；通过论坛、Slack 或者访谈，我们能与用户不断沟通，有助于我们保持坦诚相待；我们充分利用设计思维来确保一组经过验证的功能得到实施。

尽管一些旧习惯仍然在无形之中影响着我们，到这我们目前的执行还不是很完美，但我们比较乐观，也取得了一些进展。

不过，我们也发现了一些不足之处，至少对我们的团队来说确实如此：

1. 我们的公司规模并不大，而且设计思维虽然强调紧凑的迭代循环，但坦白而言，其本身是高度结构化且非常耗时的。其结构化程度过高，致使其不太适合我们这样的小型初创公司。设计思维起源于咨询领域，有时候这一点会体现得很明显。
2. 查看完提交的所有想法需要较长的时间。这意味着，提交想法的人没有觉得他们在积极地贡献，而是这个过程中存在很多的繁琐程序。此外，任何优秀的产品团队最后往往会拒绝收到的 90% 的想法，而得知提供的想法十之八九会被否决对提出想法的人来说是一件沮丧的事情。
3. 我们的团队大部分都是远程办公，分散在 18 个时区。由于时区协调性，并不是所有人都可同时参与会议，因此很难保持紧凑的结构化反馈环路。

此外，您可能时不时会看到 设计思维会抹杀创意 这样的观点，导致您不由地怀疑所作的努力。这时，您需要自行决定是否放弃。😉

替代方案？

如此看来，设计思维并非十全十美。但老实说，我们也很难想象出其他替代办法。

我们可以基本上舍弃流程，而是每月将所有人集中到办公室，让他们发表各自的看法。或者我们可以走另一个方向：始终让一个开发组长决定所有开发人员应该做什么，但如果这样做，对产品流程提供想法和意见的人将少之又少。

我们或许可以采取 Google 的方法，让团队中每个成员各自分配出 10% 的时间来做用户调查和调整新的想法（事实上，这主意听起来还不错）。

这又归结到一个经典问题 —— 任何体系都存在缺点。但至少，我们已经有一个可用的体系。

总结

我们可能会继续采用设计思维，也会在此基础上做些试验和调整。

您对此有什么看法？您觉得怎样改善设计思维会让其更加适合初创公司？我们很期待了解别人是如何运用设计思维的！

传送门：

• GitHub: github.com/serverless
• 官网：serverless.com