11 章节9: 充分放权
雷欧雷欧 保存 显示目录
现在我们完成了下注，该进入下一个循环周期了，我们应该如何启动呢？
分配项目而不是任务
我们不会在一开始给任何人指派任务。没有人会扮演将项目切割并指派的「包工头」或者「架构师」这样的角色。
提前将项目划分为任务就像将文稿塞入碎纸机，每个人获得的都是不连贯的部分。我们希望项目能够在整个过程中都保持「完整」，这样我们就不会丧失大局观。
我们相信开发组可以自行掌控整个项目，并在我们安利划定的范围内工作。小组成员将自行设定他们的任务以及工作方式。小组的成员将获得完全的自主权，并且通过自己的判断来尽可能的实现安利规划。
小组成员们都喜欢自由地用他们所喜欢的方式去实现构思，有才华的人都不喜欢被当作「码农」或者「自动售票机」。
当小组成员得以全权负责项目后，成果也变得更加卓著。没有人能在项目一开始就预测到应该怎么做才能让项目的各个部分完美地融合。纸上谈兵是没有意义的，只有实际参与开发的设计师和程序员才是调整项目和发现缺失的最佳人选。
当开发小组被分配到独立的任务时，每个成员都可以专注于自己分配到的任务，而不用去分心考虑任务间的组合。预先的计划会使得你对现实视而不见。
记住：我们并非给了开发小组完全的自由去从头打造一个解决方案。我们已经完成了对项目的塑造，也已经设立好了界限。现在我们应当相信他们会用真正的设计决策和成果来填充项目纲要。
我们努力将项目定义在合适的抽象层级上，减少多余的细节，终于得到了收获。小组成员能够利用他们对于细节的了解与才华打造出比我们预期更加优秀的成果。
完成意味着部署
在循环周期的结尾，开发组将会部署他们的成果。在一个循环周期中负责多个小分支项目的开发组会在周期结束前将这些项目都部署下去。
这个限制会使得我们认真对待我们的下注内容并且会重视断路器机制。项目必须在我们的预算时间内完成，否则，预计投入和预算就变得毫无意义。
这也意味着测试和质检都必须在周期内完成。这也促使了开发组需要明确项目的核心内容、尽快地完成，并且和质检人员进行协调（稍后会详细介绍）。
对于大部分项目，我们对于帮助文档、市场宣传更新、以及向客户推送通知的时间没有严格的要求，也不期望在周期内完成这些事项。从风险的角度来看，这些都是窄尾的（他们的耗时从未达到我们预期的五倍）并且大多由其他团队来处理。我们会时常留意这些更新，并在循环周期结束后的冷却期发布新功能的通知。
启动
我们会在 Basecamp 中新建一个项目，并将开发组的成员加入到项目中，以此来启动一个新的项目。我们首先要做的是将塑造好的产品概念原型推送至信息板上。我们还会将原始的安利或者精简版的安利也推送上去。
在 Basecamp 项目中的第一件事就是贴上塑造后的原型概念
由于我们是远程办公，我们会使用 Basecamp 中的聊天室来进行启动对话。
安排一次开发组通话来梳理一遍塑造工作
通话是这让开发小组核实任何没有在纸面上写清楚的重要问题的好机会。在对项目有了一个大致的了解后，他们就可以正式启动了。
找准方向
在开始的几天中似乎并不像是「开工了」的样子，没有人在检查任务完成情况，也没有成果被部署，没有任何可交付的工作去检视。在此期间，成员间甚至没有什么沟通，小组陷入了一种奇怪的沉默。
为什么会这样呢？因为所有人都正埋头钻研现有系统的工作方式以及探寻最好的切入点，所有人都在忙于摸清环境并找到方向。
开发小组指出切入点
管理者一定要重视这个步骤，成员们不可能立刻一头扎入代码中开始开发新功能。他们必须熟悉现有的代码、从安利内容的整体去考量，在暂时的死胡同中发掘新的起点。过早地对他们进行干涉对项目是无益的。小组需要花费时间去摸索最佳方案，探索是不可或缺的。过于强求进度只会将这个流程转为地下进行。不妨允许他们直接说「我还在摸索该如何开始」，这样他们就不必掩饰或者隐藏这些合理的工作。
通常情况下，如果三天后都没有打破这种沉默，那么就是时候介入其中了解一下是否出现了问题。
预想中的任务 VS 探索出的任务
由于小组被指派的是项目而不是任务，他们需要自己去划分任务。很快我们就会意识到，我们在项目开始时认为我们要做的任务，和我们在实际开展后逐步探索出的需要完成的任务，两者之间有着很大的不同。
小组成员会很自然的从一些预想的任务着手——这些任务在他们分析问题时判定是必须要做的。当他们真正着手进行这些任务后，他们会发现许多我们未曾预见的事情，这些意料之外的细节构成了项目真正的主题，有时也会成为最大挑战。
成员们只有在实际工作中才能探索任务。比如，设计师在桌面端的界面上增加了一个新按钮，但是随后发现在移动端中并没有合适的位置可以放置着个按钮，于是他们记录下了一个任务：想办法在移动端加上这个按钮，或者在设计的第一步就考虑清楚视觉层次。但是随后设计师意识到在修改了布局的地方还需要追加更多解释性的文本说明。于是又诞生了两个新的任务：调整布局来容纳解释性文本，以及撰写解释性文本。
我们通常会在毫不相关的地方诞生一个任务。假设一名程序员正在转移数据库，她在查看模型并理解交互时，发现一个用于项目不同部分的算法需要进行更新，她就需要将这个记录为一个任务以便于稍后进行更新。
只有在真正的实际开发中才能搞清楚到底什么事是需要做的。这并不意味着小组从一开始就什么都做，他们应该选取一些有意义的内容来优先开发，比如项目的核心内容，这些内容不仅重要而且足够的精简，可以在几天内就使用有效的操作界面和代码进行搭建。
在接下来的章节中，我们将探讨一下开发组该如何选取目标并且共同协作得到一个调试得当的成果。