前言
前文《团队品宣失败个案》中，被某高人批评无实质改善手段，不实用，需改善。高人就是高人，一击即中我心的惑。在总结上文后，其实自己也纠结了很久是不是太偏价值观可，是否需要增加点手段措施呢？真的一夜无眠思索此问。而最终因害怕过多地给出“标准答案”会扼杀团队的人完整性，作罢。
“你不能相信团队每个人都能有积极性，能发挥出他们的完整性，一些人仅可能是没有思考的‘工具’，只有少部分人才会和你一起竭尽全力”，高人又祭出了D神名言录。作为一个有经验的人，直接告诉他们怎样做，是一个管理者的责任。 而的确，经过今天的团队回顾也确反映了此情况，最感谢的人：无、当前问题：无。。。缺乏思考，并不是团队每一个人都能培养的。
过度关注于敏捷的价值观，让我觉得有时候这可能也是一种束缚，毕竟本来就不可能让所有人都一样，有些人注定就是喜欢舒适的，也应该尊重他们的这种选择（你只可以做的是不选择他们）。
那么，我就补一篇改善措施吧，顺将自己的思考同作记录。
正文
前文再续，书接上回。先抛出往文的主要问题总结：
（1） 需求各方理解不一致，没有人协调关联方，导致各方单点作战，衔接场景测试遗漏；
（2）设计方案过于简单，缺少沟通协作校准的介质。
“职责是清晰的，边界是模糊的”，ACT培训中最打入我内心的句（同为储总的名言），问题1中的答案。 无视剧本，打破固有思维。虽然为配角，但是如主角不给力，我们也应主动地去帮忙承担一下“主角”的戏份，但求好事，莫问尊卑。同如今天回顾时的抬杆游戏，如仅关注自己是不可能完成目标的，该站出来就得站出来，观测整体，引导全场。当然，也如另一同学总结，如主角给力，安静做好配角，同为佳作。
而整个版本过程中，产品和合作团队成员均没参与早会，这应该是另一点后续需要重视改进的地方。如需求非常重要（无所谓需求就算了），务必在开始前要求产品、业务和合作方一并早会，强制性参与，提早建立纪律契约。
而问题2，一个老生常谈的问题，此次再犯，实属低级。虽早在前期我已是再三强调开发同学要先出详设流程图评审，通过后才可开发。
“没有时间开发了，流程图等我开发完后补吧。”一句在程序员间古老却熟悉的魔咒，唤起了我过分乐观的信任，默许了。自此伏笔了后续的各种失败。
磨刀不误砍柴工，如这次能让双方牢记住此道理，也未尝不是一件好事吧（为庆祝自己又长记性，奖励元旦前徒步12楼上班）。坚守团队纪律底线，是每一个管理者的天职。
有些事情，就是需要我们刻意地去锻炼的，越困难的事情，越重复100遍，那么久容易了——跨职能协作校对；如铁一般执行团队纪律。
互勉之。
