记得一次培训会上，老师在讲团队战斗力的时候，举了个特种部队和土匪的例子，让我印象深刻。特种部队，纪律严明，指哪儿打哪儿，要什么给什么；土匪，纪律涣散，散兵游勇，要什么都得催。如果以特种部队的状态代表5分，以土匪的状态代表1分，我的团队能得几分？这个问题困扰了我一段时间，直到在一次回顾会上我向团队抛出了这个匿名调查，平均下来大概不到3分。

      我不得不承认，抛开平时组员之间的幽默风趣和说说笑笑，一旦回归工作本身，我的团队是不够活跃的。不够活跃体现在某些方面，例如：不热衷分享、不热衷代码检视、不热衷优雅的编码风格、不热衷提升编码技术、不热衷打造辅助工具、不热衷实施自动化测试、不热衷文化活动等。但是，为什么呢？我思索了许久，直到我读到了有个词叫做“富余时间”。前面提到的不够活跃的具体体现，没有一样是不需要时间投入的，那么反观团队的日常的确是没有多少“富余时间”，所以团队不够活跃也是自然而然的事情。

        那么团队为什么没有富余时间呢？团队的日常主要是靠项目来驱动的，那么是否项目太多或太难了呢？我回想了下，在很长一段时间内，每个组员身上都挂了多个项目，包括主办业务项目、辅办业务项目，主办技改项目等，并且经产出现需求完成度超期的情况。再深入分析，会发现这些项目彼此之间除了开发平台、技术架构、编程语言等相同外，每个项目的业务基本上是不重叠的，也就是说技术可以积累和共享，业务逻辑却是不能的，这无疑加大了组员切换项目的额外成本。

        如果说只是项目业务逻辑不能共用，其实也不会引发太严重的问题，毕竟只要需求明确开发起来也是可以高效率的。然而，现实当中的需求好像并不是那么如意的，有的需求很像“一句话需求”既没有背景也没有范围，更没有草图和业务规则，有的需求读完后一头雾水，会有无数的疑问需要解答，有的需求收到后要想联系上业务人员比登天还难。我想，组员大多数项目时间应该都花在了沟通成本上，等待需求澄清，等待主辅办讨论，凡此种种。

        那为什么会出现项目并行度高且需求质量差呢？我想，很大程度上是因为团队没有防御机制造成的。理想中的防御机制，我想应该是有个需求质量过滤环节，还有个需求填充队列。需求质量过滤环节为我们拦住了那些完全是浪费开发时间的沙子需求，这种需求将耗费大量人力物力才能变成板砖甚至钻石需求，而这并不应该是开发人员的主要职责。需求填充队列可以对需求进行分类，或者说组内服务范围进行分类，例如：加急需求、监管需求、流量需求、技改需求等，只是进行分类并不能控制项目并行度，还需要配合WIP来控制资源投入比例。

        前面，我们首先发现团队不够活跃，然后分析出富余时间缺乏，又了解到项目并行度高需求质量差，最后发现是团队没有做好服务分类和WIP控制，折腾了大半天，最后才找到主要原因，这就是典型的“后知后觉”吧。那为什么我们不能做到“先知先觉”呢？我想这就要引出理论学习的重要性了。以上这些问题，在我读了《精益产品开发》和《看板方法》后，有种茅舍顿开的畅快感，有种求得真经的满足感。 

      精益产品开发的主要目标，是顺畅和高质量地持续交付有用的价值，又以看板方法作为具体方法，包括：可视化价值流动、显示化流程规则、控制在制品数量、管理价值流动、建立反馈持续改进。可视化价值流动和显示化流程规则可以帮助我们建立看板墙并确保工作项卡片按照规则进行自我拉动；控制在制品数量，暂缓开始聚焦完成，从追求资源效率转为追求流动效率，从而加快价值流动；管理价值流动，通过就绪队列填充建立节奏控制质量，通过看板站会发现瓶颈识别阻碍问题并预警风险，通过发布规划建立发布节奏并分离部署与发布；建立反馈持续改进，通过基于量化数据的回顾会，定期对阻碍团队的问题瓶颈进行梳理并产生改进措施，使团队拥有持续提升的内驱力。

        我想，为了以后能少走弯路，埋头苦干的同时也要习惯抬头看路，对团队既可以在后面推，又可以在前面拉，要具备这些能力，我还需要做很多事情。

        对我而言，提升团队活跃度，打造良好的团队文化，增强自组织水平，将是我的最高追求和努力方向。我相信，团队文化就像空气一样，团队的所有活动，团队的所有成员，都会受到它的滋润，从而获得正能量，将无往不前，无坚不摧。