信心往下传，困难往上抛。为将者，懂得如何把信心传递到如何帮助团队缓解压力，如何帮助团队建立信心，达成目标。

团队的士气对于团队的战斗力，团队的工作成果起决定性的影响。一个成熟的领导者，懂得如何把信心传递到团队，把困难同步到老板。

在目标不清晰，方向不明确，困难和投诉一个接一个，需求又反复变化，未来充满不确定性，身边满是抱怨的环境中，团队的压力会倍增，身心疲惫，战斗力渐失。

如何传递信心。传递信心不能仅靠口头的打气，要建立在对团队和业务的理解之上，建立在行动的效果之上。

成熟的领导者，懂得把目标传递到团队，并清晰地传递。会让团队清楚现在在哪里，未来在哪里，让团队了解如何从现在的X走到未来的Y。从而使得团队有目标感，有方向感。

成熟的领导者，能解决的困难能够想各种办法来解决，从不抱怨，解决不了的问题能够往上抛（仍然不会跟团队抱怨），一个方面从上面寻求帮助（往往老板能从更高的层面，或者不同的角度提供帮助），另外一个方面管理老板的期望，让老板知道可能的困难，不至于出现问题时措手不及。

具体到我们的工作中。 跟团队同步整个的目标，分解各个阶段的目标，做出分迭代的目标（各个时间段的重点工作），让大家清楚我们如何一步步往前走。 同时也考虑充分迭代出现工作未能按时完成的情况，如何规避对整体进度的影响，不至于一步延误，步步延误（一定不能假设所有的事情都会按计划完成，因为必定会有事情跟预期的不一致，提前做好应对方案，把握好风险即可；一旦假设所有事情会按计划进行，出现延误时，很容易一步延误步步延误，团队逐渐失去方向和节奏）。

目标上我们也清晰地定义了各个主要角色的目标。 当团队中出现抱怨的声音时，管理者有责任采取措施减少抱怨的产生，减少抱怨对于团队的影响。

迭代的安排上，第一轮迭代的时间短，工作也相对少，但包含了最基本的流程。这样做的目的有3个，一个方面是为了建立整个团队的信心（很快基本流程跑通，每个迭代都有用户可以感知到的进展），另一方面帮助团队快速进入状态，第三是让团队后面可以基于这个基本的架子，能够并行地增加各种细节功能。每个迭代都有用户可以感知到的进展，就是每个迭代都要有交付，而且交付的是用户能看到的功能或者特性，这就是持续交付（能做到持续交付是对软件研发团队最有挑战的事情，成熟的团队能够做到持续的交付）。

4月25的时候，系统上线的前两天问问进展怎么样，产品经理拿出打印的三张A4的任务列表，说这些事情没有一个完成（验收完成）的。这种时候，团队哪里来的信心，早已被一堆事情，以及没有进展的状态所压垮，结果我们不得不最后一天之内做了4轮迭代把系统。迭代就是要把目标拆解，稳定持续地交付，持续验收，让工作有进展，团队有信心。

测试方面，第一轮迭代，我们建立好自动化测试的机制并且可视化。质量的可视化，一个方面提升团队对于质量和技术的信心，另外一个方面，也是减少质量成本，提高开发效率，加快迭代速度。（而业务指标的可视化，既提升我们的信心，也提升客户的信心，不仅是对业务的信心，也是对团队研发能力的信心，同时也作为一个监控工具）。

产品（业务目标）上，按重要性对大的模块，各模块中小的功能排优先级，新增的变化的也排好优先级，不是最重要的优先级排低。项目过程中，按照优先级从高到低进行开发交付，一次只做一件事情，能够让团队成员的工作富有条理，信心饱满。而不会被同时并行的一堆事情压垮。同时，让业务同事，客户看到我们的优先级划分，以及重点工作的快速进展，整个内部外部团队的信心都会大增。

推荐几本书： 《Joel说软件》， 《重来：更为简单有效的商业思维》， Carol Dweck的《mindset》