如何将设计思维应用到精益初创公司的软件开发

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

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

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

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

在这个过程中，我们取得了一些进展，也经历了一些挫折，还遇到了一些其他事情。

如果您正在考虑采用设计思维，或者只是大体上考虑您的产品流程，不妨继续阅读本文，了解下我们的尝试。

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

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

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

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

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

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

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

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

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

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

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

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

共鸣：

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

设想：

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

定义：

产品团队每周审查类别版块，对需要进一步验证或需要进一步发现的内容加以标注。

在审查的基础上，我们会对每个项目分配以下一个优先级：

原型：

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

测试：

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

实施：

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

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

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

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

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

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

0 人点赞