提供创新是每个科技公司议程的重中之重。 但是他们常常不敢做，因为他们被永无止境的研发风险所阻碍，导致失败或缺乏切实的成果。 但是创新是否必然是不可计划的并且难以实现？ 在Hadean，我们反复采用了Tetromino规划的方法，该方法证明了相反的情况：我们授权六名非常有才华的工程师组成的团队，在不到一年的时间内提供了突破性操作系统的第一版迭代，三项概念验证击败了已建立的库的分布式计算库，以及在原型阶段已经在市场上无与伦比的游戏框架。 从技术和商业的角度来看，这是在高度不确定的情况下交付的卓越创新，并且都经过了深思熟虑的过程。
事实证明，敏捷和其他方法在支持需求和用户需求的不确定性方面非常出色。 但是敏捷在进行实质性创新时显示出其局限性。 我们的方法充分利用了团队的技术直觉：通过执行非常规的计划，软件工程师将被引导将其直觉转变为可以交付的切实成果，即使在最初“鲜为人知”的情况下。 Tetromino规划还可以估算和创建实际的计划，该计划看起来像Tetris（因此得名！），并且会不断更新以集成在开发过程中出现的新“已知”信息。
让我们看看这种创新的方法是如何工作的。
Tetromino规划背后的原则
此方法基于三个基本原则：最大化开发人员的影响力，拥抱开发人员的流程以及从头开始。
让我们从最大化开发人员的影响开始 。 作为第一近似，众所周知的项目约束的经验模型告诉我们，给定所需的项目质量，我们必须处理三个约束：资源，时间和范围。 您只能“强加”三个中的两个，第三个是这样做的结果。
考虑到这些限制，我们希望开放给开发人员决定的限制，以便他们能够产生最大的影响？ 我们可以选择资源，在软件开发中，资源主要是人。 但是在这方面存在很大的局限性，尤其是在早期公司中：人才紧缺，永远雇用合适的人才会花很多时间，而且通常董事会对预算有限制。 另外，开发人员是否想参与这一方面？ 听到这个消息我会感到惊讶！
第二种选择是时间，它是开发人员通常以估计的形式影响的一个方面。 给定需要实施的某些功能，实施需要多长时间？ 通常这是给开发人员提供机会进行评估的机会。 而已。 当然，计划扑克和类似技术已被证明行之有效，但是，尤其是在进行实质性创新时，这是最具影响力的方面吗？ 我相信不是。 我认为，在确定工作范围方面有很大发言权是开发人员最有影响力的地方。 稍后，我们将展示如何启用此功能。
第二个方面是拥抱开发人员的自然流动 。 如果您试图与软件工程师讨论高水平的创新目标，例如交付全新SDK的alpha版本，则可能很难进行有效的对话。 未知数太多，您在桌子上有太多选择，并且试图以较小的结果分解高级目标似乎非常复杂。 但是，如果您要问一个更简单的问题，例如“不做什么愚蠢的事情？” 或“您肯定需要实施什么？” —突然，您得到了大量的即时答案。 因此，我们决定与自然开发人员的流程相适应，而不是与使双方都感到沮丧的高层讨论作斗争，我们决定改编计划的工作：首先是细节！ 稍后我们将看到这在实践中如何翻译。
我们决定重要的最后一个要素是确保我们已经很好地定义了期望的结果 ，并且从一开始就做到了。 这种操作方式的灵感来自亚马逊广泛使用的“ 从客户那里退货 ”方法：他们的产品经理首先写了一个宣布成品的新闻稿。 本新闻稿针对最终客户，其中包含有关客户问题，当前解决方案失败的原因以及新产品为何能够解决此问题的信息。 我们发现，软件工程师将自己的工作写成新闻稿的想法非常有力，因为它可以使我们试图解决的实际问题更加清晰和一致。 但这也将激发人们围绕我们的解决方案的外观进行讨论，因为在新闻稿中我们应该介绍我们的解决方案。 从客户的角度来看，这也将是一次机会，可以看到并突出我们提供的价值。
向后工作的组合，不要太担心细节优先的方法以及使团队有能力影响范围对我们的成功至关重要。 让我们看看这些在实践中是如何翻译的。
规划
有两个主要阶段：规划和实际工作（我们称之为“流程”）。
规划阶段似乎不合时宜。 我们不是敏捷地从整个计划中移开了吗？ 创建路线图并花时间讨论将来可以做什么，然后意识到两周的事情发生了变化，这是否浪费时间？ 也许。 但是，我们发现，规划的锻炼是其中值是，不一定坚持它。 我们将计划作为一种有效的工具 ，使我们能够从高水平的目标转变为我们有信心可以交付的一系列切实可行的交付成果。 实际上，我们已经交付了整整一年的时间。
计划阶段的输入是两个明确的元素：高层目标和时间表。 高层目标可以是“发布SDK的Alpha版本”或“创建用于大数据集实时分析的库的证明概念”。 它们听起来可能含糊不清，而且是故意的。 即使它们很模糊，每个人也都很好理解它们，尤其是公司的非技术部门。 还记得我们上面所说的关于工程师的影响吗？ 没有精确指定结果的事实为这种影响留出了空间。 当您不得不面对不确定性带来的挫败感时，请记住这一方面！
第二个方面，时间框也很关键。 它可以由外部截止日期（例如您正在参加的会议）强加，也可以由自己强加，例如季度OKR。 我们发现整个季度是最适合我们的时间表。
定义了高层目标之后，规划将按四个独立步骤的顺序进行开发：
- 结果定义
- 构想和概算
- “俄罗斯方块”计划
- 利益相关者回放
结果定义
在流程开始时详细定义结果实际上是加入Hadean的新工程师面临的挑战和潜在挫折感，尤其是因为这很耗时（并且主要发生在会议中）。 但是，这一重要阶段的目的是以精简的方式将范围的浪费降至最低。 将结果定义为一个小组练习，可以使每个人都有发言权，并使团队根据我们解释目标的方式进行调整。
我们从高层次的目标开始，每个人都有机会提出“这实际上意味着什么”。 该小组在产品人员的指导下，汇聚成一个符合高级目标的成果的共同定义。 对于产品人员来说，适度结果定义是基本的，因为这是业务角度更加重要的地方。 考虑我们之前的示例，“发布SDK的Alpha版本”，它将阐明Alpha版本的预期“安装”体验。 丰富的调试经验以及交付机制。 等等。
在这个阶段，您不应太过严格，我们处于流程的分散阶段。 此步骤的目的是弄清楚旅程的结束是什么样子，而不是决定（尚未）将实施或将不实施哪个方面。 在此阶段，结果不应包含实现的详细信息。 这就是下一步的目的。
构想和概算
意念步骤是当大家邀请到有什么建议将实施以实现通过上一步中定义的结果的事。 功能/要做的工作应以简单的要点表示，足以进行讨论，但又不能太详细以至于无法为实施做好准备。 人们可以在自己的时间里异步地做出贡献，因此您应该邀请他们“疯狂”，因为在这个阶段不应该施加任何限制，欢迎大家考虑每一个想法。 这是我们工程师最喜欢的一步，也是我们拥抱自然流程的意图的体现：细节至上！
在可以实施的事项清单完成之后，我们请工程师对一个人实施的时间进行估算。 我们决定将选项限制为仅4天：半天，一天，两天，一周。 如果需要花费超过一周的时间，则应进一步细分。 请记住，这种估算并不是我们要求他们作出的承诺，而是一种估算相关工作量的方法。
在此阶段结束时，您将清楚地了解我们为实现您的结果而在餐桌上有哪些选择。 您现在可以开始确定值得关注的内容。
“俄罗斯方块”计划
此时，您将获得一份无组织的“洗衣”清单， 可以做的事情，以及有关每件衣服可能需要花费多长时间的想法。 这是过程的融合阶段，其目的是确定应该执行和不应该执行的工作，发现关键的依赖项并将工作分组为一致的工作块。
为了指导我们确定应该执行哪些事情，我们使用优先级排序中使用的技术MoSCoW方法 。 这是一种非常简单但有效的将需求分为四类的方法：（必须）（必须），应该拥有，可以拥有和不会（这次）。 可以通过您更熟悉的任何机制来发现依赖关系，只是要小心不要以复杂的甘特图结束-太详细了，无法满足您的需求。 最后，仅通过利用大脑将事物组合在一起的能力，就可以完成相干工作的分组-非常复杂，不是吗？
现在有趣的部分，玩俄罗斯方块并创建实际计划！
您的食材是：
- 一组可变长度的工作块（取决于实际范围）
- 可以为他们工作的人
- 每周一张桌子，您可以在其中布置四聚体（即由一个或多个人完成的一件工作）
您的游戏包括找到合适的人员/工作量/时间组合，您将竭尽所能来实现自己的目标。
通过反复试验，您将迭代如下所示的内容：
现在，最后一点是定义每个工作块的结果。 怎么样？ 对构想阶段中产生的事物的详细列表进行逆向工程。 基本上，您在这里要做的是问一个问题：“实施所说的话，我们得到的实际结果是什么？”。 从高层的结果开始，然后直接跳到细节，然后回到中间的结果，这似乎是一个荒谬的过程。 稍后我们将看到这种中间结果在实际工作阶段将如何发挥作用，但是由于该过程的设计方式，我们已经可以观察到该计划具有一些有趣的属性：
- 这是实践中高层目标的翻译；
- 它捕获了您短期内要交付的内容的整体视图，而不仅仅是通常分配给个人的两周任务；
- 从最小的意义上讲，它仅包含成功所必需的最重要的事物。
- 它包含了整个团队的所有智慧，资历和知识；
- 您很有信心可以实现。
这些特性是进行实质性创新时的与众不同之处，并且我们已经证明，即使在技术和商业角度都存在极端不确定性的情况下，它们也始终支持我们取得令人难以置信的进步。 最终，如果您要实现的目标至少在纸上可行，那么现实中更有可能实现！
利益相关者回放
一旦我们就tetromino计划达成共识，就该向利益相关者介绍我们的结果了。 应该与所有其他部门进行讨论，以便他们可以了解可能发生的情况。 他们还可以输入您可能已经忘记的主要内容或完全偏离轨道的内容。 意识到某些事情与预期相去甚远可能令人失望，但是您应该感到很高兴，因为很早就发现了这些事情，并且您有足够的时间进行调整（并且几乎没有实现任何事情！）。
现在，应该更加清楚地了解到tetromino计划如何使您从一个高水平的目标转变为一系列可以实现（并且确实可以实现）的结果。 在开始描述实际工作如何完成之前，重要的是要强调指出，我们在此描述的整个计划过程应该在几天之内完成。 我们通常将其散布在三天的时间里，每个计划阶段都要开会90分钟，再加上几个小时的异步工作。 这也应该使我们确信，我们所做的不是像瀑布那样繁重的前期详细计划，而是轻量级的小组练习。
现在让我们看看实际的工作原理。
实际工作，又称“溪流”
当“ temino”开始工作时，即，当“工作块”之一进入交付时，您将拥有一个拥有结果并有专用时间表实现结果的团队。
该团队的任务是交付最有影响力的成果，朝着成果确定的方向发展 。
这可能会将我们的方法与更严格的“完成定义”区分开来。 通过完成的定义，您的目标是使团队围绕遵守用户故事（或类似故事）和“适合产品和组织目的的质量”进行调整。 完成的定义表示您接受失败和延迟，将其视为必须满足特定用户需求的成本。
我们认为我们的结果更像是“成功的定义” 。 它必须使我们的开发人员有能力将自己的工作视为实现成功的机会，而不是简单地遵守某些规范。 这意味着我们不规定如何取得成功 。 我们想利用我们的开发人员是专家这一事实，我们相信他们。 领导层有责任尽可能明确取得成功。 开发人员有机会找到最明智的方法来实现它。
但是，在实践中，我们的开发过程每天看起来如何？ 实际上，它与看板没有太大的不同。 而且可能更轻巧。 之所以可行，是因为开发人员可以自由决定最好的方法来实现结果，只要他们对此负责。
我们采用了非常轻量级的方法，从一开始便改进了结果，每天进行一次站起来并每周演示一次。
结果细化
在编写一行代码之前，我们举行一次简短的会议，在会议上我们做一些简单的事情。 首先，我们重申商定的结果，重要的是要刷新我们的记忆。 其次，我们完善结果本身，添加细节并澄清可能仍不清楚的方面。 第三，我们为要完成的工作起草任务。 最后，编码可以开始了！
每日站立
我们的日常站立时间稍有变化。 我们要求每个人不要告诉我们他们前一天所做的活动，而是要明确说明他们所取得的进展 。 “昨天我参加了很多会议”，但沟通不多。 就表达能力而言，在描述软件开发时，它可与“昨天我整天在键盘上打字”相提并论。 感兴趣的是在该会议期间决定或同意的事项。 如果您很难通过这种方式参加站立比赛，那么解决该问题的一种方式就是回答“您今天知道什么，而昨天却不知道？”的问题。 这应该使让进展变得更加容易。
每周演示
在星期一早上，我们将举行一个全人一小时的会议，要求每个人快速演示前一周的进度。 它可以显示有关他们实现的功能的视频，或实时部署或任何使您能够展示工作效果的视频 ，而不是讨论您所做的活动。 这在原理上与我们日常站立的方式相似，并且始终如一地证明这是开发团队保持同步并为取得的进展感到自豪的绝佳机会。 有几个星期几乎没有什么可显示的。 在这种情况下，我们仍然会要求我们逐步介绍正在创建或修改的代码，并可能借此机会解释某些决定。 但这不应该是默认设置，它应该是一个备份，以防其他任何情况。
如您所见，没有什么特别的，但这是可能的，因为要确保每个人都清楚地了解我们作为一家公司所做的工作，因此需要付出巨大的努力和关注。 并且因为我们让工程师对成功负责，然后我们信任他们！
重新规划
在这一点上，您可能会有一种幻想，即，一旦您在开始时就计划好并开始开发，该计划在整个交付期间就不会改变。 与计划相关的通常含义是您实际执行该计划。
如前所述，我们认为计划是一种工具，可以帮助我们而不是我们承诺提供的东西。 因此，我们经常重新计划，并在必要时重新计划所有内容。
重新规划可能由于多种原因而触发：
- 新的“知名度”出现了。 这是最常见的情况，非常欢迎！ 这就是表格的清晰之处。
- 新的“未知数”出现了。 发生这种情况的原因是，由于进行了原型制作或测试，我们实际上意识到我们所知道的比预期的要少。
- 无法实现目标。 这也可能发生，众所周知的是，随着您的估算能力的提高，您总是会遇到错误的情况！ 那绝对很好。
- 目标改变。 市场可以改变，公司的战术方向可以改变，团队可以改变。 任何事情都可以改变。 目标可能会相应更改。
当这些事情中的一项或多项发生时，将触发重新计划。 我们不必从头开始进行整个过程，也不必与每个人一起进行。 这实际上取决于计划工作的受影响部分。 重要的是与受您讨论的更改影响的所有人员进行重新计划，并在完成后向所有人播放重新计划的结果。
不要以最小化计划变更为目标，这不是练习的目的。 您实际上是在尝试将新信息吸收到您的计划中，如果这意味着您必须完全更改它，那绝对没问题。
我们会跟踪计划的变化方式，并希望在这段时期结束时回顾一下。 令人着迷的是，通常实际的交付计划看起来与开始时看起来完全不同，但是实现了高层目标，这对于交付创新至关重要！
它如何演变
指导这种方法的迭代一直很有趣，看到才华横溢的工程师做出色的工作，并在解决复杂技术问题方面取得了实质性进展，这是非常荣幸的。
我们知道，在客户要求更加严格的情况下，这种方法在可扩展性和有效性方面存在局限性。 我们的工程团队现在有12名开发人员，我们相信这是可以采用这种方法进行全面协调的最大团队规模。
我们还处于特权地位，可以在自己设定的领域取得重大进展，这要归功于我们对产品的浓厚兴趣和吸引力。 因此，我们现在更加清楚了客户期望的细节。 由于我们将近三年的历程，我们对所处理技术的所有领域也了解更多。
由于这些原因，我们很快将把软件开发过程发展为类似于六周敏捷团队的事实，事实证明，该团队可以在我们进入公司的阶段以及提供的产品中使用。
但是，只要我们在仍需探索基础创新的领域上工作，我们就会继续使用tetromino规划。 例如，我们一定会继续以这种方式与在我们操作系统的某些区域HadeanOS上工作的团队合作 。
让我知道您对我们的方法有何看法，并请分享您如何在自己的计划中解决不确定性问题。
-
该帖子最初发布在Hadean博客上
732
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
