如何打破团队的舒适区

发表于2017-08-29
评论0 750浏览

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

打破舒适区,就意味着变化、意味挑战、甚至是失去,就跟大脑跟身体说:你,现在去跑步吧?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、新项目还是老项目,都传袭着这样的传统,说起来,还是有点儿成就感的。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引

游戏学院公众号二维码
腾讯游戏学院
微信公众号

提供更专业的游戏知识学习平台