如何打破团队的舒适区

人大概都是有惰性的，习惯于以自己习惯的方式处理事情，习惯于自己已经拥有的便利、捷径、特权、掌控等，变化听起来就足够让人恐慌，就好比开发听到需求变更的心情，画面请各位自行脑补。

打破舒适区，就意味着变化、意味挑战、甚至是失去，就跟大脑跟身体说：你，现在去跑步吧？What？你要我拖着120多斤的肉去运动！

一个人的事情，有的时候需要的只是勇气、毅力、和决心，是自己跟自己的较量。

但，很不幸，你是个项目经理，你面对的是一个团队，一群人，你说服自己去运动去减肥都这么困难，更别提要让一群人去改变。对于一个没有任何实权的“经理”来说，这是一件多么尴尬的事情。其实，我自己也是个挺害羞的人，嗯，真的，虽然看起来不像。我经常则问自己，你一个害羞的人，干嘛天天干着这么多需要厚脸皮儿的事儿呢。这么说，我好像天天都在打破自己的舒适区一样，哈哈哈。。。

好吧，内心戏演完了，回来说点儿正事儿，跟大家分享一个我初当PM干的一件大事儿 —— 需求管理，嗯？你确定是在说大事儿？没错，需求虽小，但事关重大。PM每天在干嘛呢？开发、测试、产品、设计每天又都在干嘛呢？不过俩字儿：需求！是的，开发忙着做需求、测试忙着测需求、产品忙着写需求、设计忙着画需求，PM更是忙着“各种”需求。

曾经，我们的需求是这样的：

1.      有嘴，没需求

2.      有交互，没有需求

3.      一个几十页的word文档囊括了一个版本的所有需求的描述，图文，目录。。

4.      开发拆分需求

5.      开发对任务负责

6.      技术需求没有需求

7.      啥时候都在提需求，需求一箩筐，哪些做哪些不做，啥时候做

...

在没有PM之前，产品同时还兼职PM，既当裁判又当球员。

所以，当时，作为新晋PM的我，在产品眼中，我大概是个谋权篡位的家伙。

Phase 1 融入

接纳现有的方式、融入大家的环境，参加各种会议、活动、一起吃饭、加班。。。说白了就是刷存在感，我跟大家一样，也是团队中的一员，不是外人。中国人重关系，自己人说话好办事儿，即使不好，也只能自己人说，外人更是说不得。比如这个：

Phase 2 时机

即使是自家人，也不见的啥话都能随便说。谁都不喜欢被教训、被约束、被唠叨。而且呢，有的话，不见的啥时候说都有效果。比如，小时候吧，爸妈总爱唠叨说要谦虚谨慎，认认真真的。我都很不耐烦的说，知道了知道了。直到有一次，期末考试结束后，我老爸问我：考的咋样？我胸有成竹的说：还不错。结果，几天后，去领通知书，数学和语文，一个58分，一个56分，没一个及格的。而且重点是，自己真的信心满满，觉得自己都会呀，好么？从那儿以后，我自然而然学会了这两件事情：一是谦虚，凡事给自己留个后路，别太浮夸，当然，后来我有点儿过了，导致我这个人太低调，你懂。二是，认真。比如说，答完卷子几乎从来不会提前交卷，有时间再回头看下有没有弄错的；下车总看下有没有拉东西；出门有没有关好窗、带好钥匙、锁好门...虽然，现在有时候还是会有些粗心，但是下意识的，还是会喜欢check一次，以至于我老公认为我不信任他。

所以呢，你如果想要团队做出一些改变的时候，最好的时机应该是让团队成员也察觉到，我们有必要做一些改变。比如版本总结会的时候，总有测试站出来说，需求实现跟开始不一样、开发提测晚；开发则说，产品需求多、需求变更多；产品则说，开发没按照他说的来。。。比如13年底做4.0版本的时候，年度大版本呀，愣是没有需求，求大家的心理面积。

于是，痛定思痛，再经历过种种磨难后，终于痛定思痛，开始收集各种糟心的案例，准备彻头彻尾的把这局面给改掉

Phase 3 同盟

嗯，民主，这是个民主的涩会呀。提个倡议也至少得大多数人同意才行呀。

最关键的干系人应该是开发leader、测试leader、产品leader呀。因为是具体的执行者，所以，开发和测试其实是最容易争取的对象，基本不需要我说太多，纷纷表示支持支持支持！接下来，略微难啃的骨头就剩下产品了。其实，也算容易，不过是请产品leader吃了个饭，聊了个天，通通气。面谈愉快的进行着，大意是说：自己是社招来的，可能做事方式上也不算规范，如果觉得不合理的地方，可以拿一些案例出来，跟大家分享下。

phase 4 水到渠成

接下来的事，自然是水到渠成。拿着搜集到的案例，还有精心准备的PPT。开始bla bla的讲现状、讲问题、讲展望。顺便提提精心准备的PPT。对于这样一个长期几乎没有规范约束的团队而言，大家对规范和流程应该是抵触的，因为不够便利，就跟我们过马路爱闯红灯一样，就跟地上本没有路，走的人多了也便成了路的路一样。突然要让大家多等等，多走几步路一样，多少会有点儿不舒服。于是乎，ppt的第一页，是这样的：

大家看出来没：我传达的意思是，我跟大家一样，我也不喜欢流程和约束，把自己和大家的距离拉近，我跟大家有同样的心情和体会。

But，由此引发的问题来了，最终导致的是沟通成本大、版本周期长、工作不高效、团队情绪低落。

最终的解决方案，其实非常简单，无非就这么几条：

1.      接单干活：所有的需求都上tapd，没有单的事儿不干，以防扯皮（虽然官僚了点儿）

2.      需求拆分：别一个版本几十个需求都放一个tapd需求单里再让其他去拆分了，谁知道哪天这个超级大需求改了，拆分后的需求谁来维护呢，更别提后面的测试发布流程该如何好好的进行呢

3.      PM负责设定需求分类：这个需求是做或者不做，这个版本做还是下个版本做，一目了然

4.      技术需求不开小灶：跟产品需求一视同仁，都要有tapd单。之前的文章也说过，其实技术需求才是那个不定时炸弹，而且，技术需求往往伤筋动骨的，没有需求单，测试知道这个模块有改动，往往等到系统测试的时候才发现，导致测试在版本后期压力大，版本延期。最初有那么一段时间，开发和测试甚至是对立的，吵架的事情一点儿也不新鲜。

5.      时间点公告：何时开始收集下一个版本的需求，何时开始评审，提前周知给所有干系人，大家提前准备好需求，尽量避免版本过程中不断的提需求、评审需求的现象。嗯，团队的节奏感很重要。

现在听起来是多么简单自然的事情，但在那个蛮荒的年代，要让部门这么多开发、测试、产品团队改变原有的习惯，真的是费了心思。时间一晃，三年过去了，现在部门所有的项目，不管是前端还是后台、终端还是PC、新项目还是老项目，都传袭着这样的传统，说起来，还是有点儿成就感的。