回忆刚加入腾讯电商的时候，一切都让初上手的笔者心里很忐忑，这里木有传统项目的大计划，木有非常清晰的传统标准需求规格说明书，各种木有，大家都是短打上阵，迅速奔跑。同时项目小而密集，一周两次发布，需求如雨而来，与已往所做过的动辄一两年，再短也得三个月以上的项目相比，实在有点灵巧得超出预期，一度颠覆了笔者对项目这一概念的认知。所幸遇到了不错的导师，还有很给力的兄弟们。在半年的摸索和试探里，兄弟们被笔者几经折腾，依然一如既往的支持，感谢导师和团队的兄弟们。如今半年过去，各种苦涩的纠结，甜美的回味，写下来与各位分享，恳请各位高手拍砖指点。

　　行文之前，先做个概要的铺垫，按时间顺序，将要展开的内容要点如下：

多看多问，小步演进;明确方向，聚焦重点;

梳理流程，培养习惯;鼓励沟通，增进效率;

明晰责任，接口清晰;适度计划，有序敏捷;

理念宣导，水到渠成;开放合作，共同成长。

这些内容都是从初加入团队至今的体会，也是一路走过来历程，自然不只是以上的泛泛概要，且看一一展开。

多看多问，小步演进

每一个有理想的青年，在被委以重任的时候，都希望自己立马能运筹帷幄，气死诸葛赛过子房，三把火一烧，令旗所至莫不如臂使指。事实上理想很丰满，现实很骨感，三把火下来，要么是烧得一锅焦黑，要么是烧得一锅夹生。

　　多亏导师一再叮嘱，要求多看多问，因此笔者就静悄悄的把自己的火把给灭了，静下心来好好观察。这时候问了自己三个问题：

1、 电商整体的开发模式是什么样的;

2、 团队目前面对的问题是什么;

3、 项目经理在这个团队的位置在哪里;

要把这三个问题回答完是一篇很长的文章，在此不多说什么，这里表达的意思在于，当PM们初到一个新团队时，是以一个中医望闻问切的方式来介入，还是以目前流行的暴力强拆的方式来介入。特别是传统IT项目经理出身的同学，必须正视互联网在项目管理方面的特殊性，需要柔性融入，小步推进，在保持团队产出的情况下，进一步提升团队效率。

　　笔者在初入团队的时候，自然是用的望闻问切：

– 望，望团队气氛，所处环境，工作方式;

– 闻，有人可能会问，团队有可以被闻到的东西吧，告诉你有的，那就是团队成员身上散发出来的情绪的味道，人家一般不说也不写在脸，但用心是可以闻到的;

– 问，上面提的三个是问自己的，除此外还要问团队，比如问团队自身觉得哪里感觉不舒服，哪里感觉很麻烦，总归以探知当前痛点为目标;

– 切，表象看过，就得深入的来了解，切就是扎实的去切入一些实际工作，从实践中来验证，来发现各种好的要保留的亮点，以及各种要调整的痛点。

　　下面笔者来分享下初期笔者们搞的水果会的故事，这也是个关于望闻问切的故事。

小技巧分享之水果会：刚到组内的时候，初看一轮，很不习惯，发现居然没有例会，是为望。继续深入发现新来的同学，不仅是笔者本人，在初期都散发着惆怅的味道，因为距离感消除起来有点难，是为闻。一轮访谈下来，同志们普遍反应例会还是需要开的，只是没人有空来组织，是为问。初入的头两周，没有例行的固定时间来集中进行各种交流与反馈，让日常的各项工作很难整体集中统筹起来，此为切。把脉完毕，开始对症下药，团队例会必须开，团队建设也必须开搞，但是，是分开做?还是合起来做?笔者的答案是合起来，既是团队例会，又是常规团队建设。怎么做呢?首先与开发Leader沟通，争取了些经费，在每期例会上买上一些水果，例会名为水果会，先谈正事，后吃水果敞开交流，例会的气氛活跃了很多，而且正事团建两相宜。

项目管理是件很灵活的事，望闻问切能让笔者们一开始就是以团队的需求来作为切入点,进而打开符合团队长期利益的持续改进之门。同时各种以人为本的小技巧或许能收到奇效，大家尽可以挥洒创意，做到更好。

明确方向，聚焦重点

　　在开始这部分的时候，先提几个很实际的问题在前面：

– 团队天天很忙，但各方仍然说没支持到，怎么办?

– 需求从很多方向来，可做可不做，怎么办?

– 各种零散咨询，支持要求满天飞，怎么办?

这些问题现实中在老团队里很普遍，作为一个运作了很多年的团队，我们团队其实挺苦逼，除了电商主平台外，其它各项业务都有支持，你来我往好不热闹，但是团队成员只有那么多，颇有疲于奔命的架势。

在经过第一轮的望闻问切后，可以发现以团队目前的人力情况，只能对现有的主平台进行全力支持，否则确实是力有不逮。因此团队内部已经高度一致的希望把支持的业务进行聚焦，重回到主平台的支持和基础技术框架本身的持续改进上来，只是一直没有想好来怎么进行切割聚焦。

这对团队而言是一件迫在眉睫的事情，得不到好的处理，就会把团队拖到一个个泥塘里，在这个泥塘里，各个上游无法得到充分满足，自己苦于奔命，下游测试与运维也一样深陷其中。这个时候，需要帮助团队一起来进行团队方向的确定，然后找各级老板沟通，重新定位团队的位置与目标，进行适当的业务切割。

　　有人问，你说聚焦就聚焦啊，太水了，木得干货，那咱就上干货，团队在打算聚焦时，进行了以下考虑：

1、目前支撑的业务中，是否都与公司及部门战略相合?

2、公司及部门战略显示不适宜由笔者们支撑的业务，是否可以整体逐步移交出去?

3、公司及部门战略显示应由笔者们支撑的业务，是否可以把高度定制化部分移交出去?

4、这些移交是否会对公司及部门的长期利益造成损害?

前三点，是团队在进行业务筛选时的一些要点，而最后一点是团队决定是否移交的终极原则。如果违背第4条，奉劝大家就不要提移交了，这必须是团队份内的事。因为有产品经理们和技术Leader的长期积累，聚焦方案出来得比较快，同时非常幸运的是，团队的聚焦尝试得到了各位领导的大力支持，最终某些业务被全移交，某些业务定制化部分被移交，很顺畅的实现了再次聚焦。

如果一个团队已经处于疲于奔命状态，那么一定需要审视下自己的业务，关注下团队是否还是聚焦在自己的主业务上，精力是有限的，毕竟团队里的兄弟都不是叶问。

　　梳理流程，培养习惯

　　团队初步融入了，业务也聚焦了，问题仍然有，比如：

– 需求仍然飞舞，开发排期依然困惑无比，怎么办?

– 开发兄弟做了很多工作，但外界仍然一再的问，你们到底在做什么，怎么办?

– 产品经理每每要想知道进度就只能找到对应开发兄弟时常催问，怎么办?

– 测试天天反馈说，这转测的也太随机了，忽而来一个，忽而又来一个，没有个计划也没个通知，怎么办?

– 运维说你们的发布太乱了，太随意了，怎么办?

– 其他各兄弟部门说，想要跟你们合作，需求到底要肿么提，提了你们会不会做，怎么办?

其实这一堆的问题，都是涉及到流程的问题，具体而言，就是需求找谁提，需求达到什么标准可以排期，测试什么时候介入，信息在哪里公布等等。

　　工欲善其事，必先利其器，工具是非常重要的，有的人用微软的Project，有人用Excel，也有人只用白板。电商一直用的是公司自研的研发管理平台，老实说这个平台工具并不算是较完美的工具，但是结合现实灵活运用好，也能给团队带来较大的帮助。因此结合研发管理平台，解决以上的问题团队用了以下的办法：

1、 所有需求都必须提到研发管理平台，需求都必须经过产品组的产品经理接入，解决需求来源的问题;

2、 所有需求都必须产品经理与对应开发评审过后才能流转到需求就绪，产品组必须在组内对需求评级，这样有效解决了排期难的问题，排期目标变得明确;

3、 排期权收归项目经理与开发Leader手上，把控入口，让开发及后续执行流程得到保障，也有效避免了所谓的黑活;

4、 排期与评审时，开发、测试、产品三方共同参与，解决了测试直到转测才知情的问题，也有效促进了各环节的积极沟通与协作;

5、 向外界约定，所有进度与需求信息从研发管理平台获取，借助研发管理平台实现信息透明。

事实上所出的措施并不多，但产生的效果是很显著的，目前团队的常规排期会，每周只需不到半小时的时间，测试与开发协作也顺畅了很多，需求流程清晰，各方也不会再困惑于怎么提交需求。由于所有的信息都在研发管理平台上流转了起来，信息高度的被集中，同时具备了可信度，且随时可探查。任何人想知道团队在做什么都变得很简单，打开团队的研发管理平台，都在那里，最大限度的利用工具做到信息的公开透明。

流程并不需要很复杂，流程在这里的作用是让事情有章可循，让工作顺畅有序，好的流程不带来麻烦，只带来有序、效率和透明的工作信息。不是因为规范而需要流程，是因为效率，秩序和沟通而需要流程。

小技巧分享：应用研发管理平台在实践中最痛苦的莫过于，让每一条信息的状态与实际情况进行同步。刚开始的时候，大多数人都是不习惯去系统里同步状态的，笔者团队也有这样的苦恼。为了改善这种情况，启用了个无伤大雅的惩罚措施，每周例会审查时，如果有人没有及时更新，那么就必须捐十块钱到团队的水果基金。开发leader和团队成员一视同仁，在此感谢兄弟们，在笔者屡次找兄弟们要水果基金时，兄弟的积极配合，欣慰的是，现在收基金越来越难了，因为这代表着同步状态已经成了一种习惯，再次感谢兄弟们的配合。

象征性小捐献也好，类似小红花小蔫花也罢，真实目标是在流程执行过程中促进习惯的养成，最终产生新的习惯来主动驱动流程，使之融入团队的血液之中。互联网人都是主动，积极，有独立思想的人，催工的鞭子并不适宜挥舞在这里。在这里好的团队是不用催的，好的团队是兄弟们都会主动的习惯性把所有好的，或不好的消息传递过来，然后大家伙一起去解决，或一起去欢呼。

　　鼓励沟通，增进效率

　　笔者也是个老程序员，仍然清晰的记得以下几个比较鲜明的场景：

– Boss问，为什么做成这样子，答曰产品让干的，Boss批曰，猪脑啊让干啥干啥;

– 做了个牛逼的产品正等表扬，这天Boss发了嘉奖邮件，木有自己名字，悲愤不已，心头升起小小的幽怨，不满积攒中;

– 又见兄弟慨叹怀才不遇，Boss有眼无珠，悄悄然裸辞远去，心生悲凉。

稍年长后回顾，真的是Boss无眼么，真的是产品不靠谱么，非也非也，只是自己放弃了表达的权力，被动，被动，一再被动，从而真的就把自己藏到墙角里去，于司于已，两不落好。

每个闷骚的程序员心里都住着一个哲学家，笔者最愿用装满饺子的茶壶来比喻开发的兄弟们。他们都很有才，但是他们都很沉默。无论多么不合理的需求，他们都习惯性的轻微抵抗后，就开始埋头专心的想着去怎么实现。无论做出的产品多么牛逼，在庆祝邮件里即便没有列上他们的名字，他们也只会默默的在心里感慨下苦逼而已。很多人说，这跟效率有关系吗?笔者要说，大有关系，非常有关系!

笔者至今工作也不算太长，以经验论，相比较而言一个乐于表达自己心情，时常保持心情愉悦的开发兄弟，是最有战斗力的开发兄弟，也是最不可能默默的跳槽让你郁闷到哭的开发兄弟;一个乐于分享的开发兄弟，是能最快成长，也最能帮助提高整个团队战斗力的开发兄弟;一个能在需求涌来时，敢于且擅于表达正确意见的开发兄弟，就像一尊门神，是个能保证团队的产出永远是高质量的开发兄弟。

　　团队半年里在这方面的做法是：

– 开设双周分享，每期让开发兄弟们上去分享自己的心得与体会;

– 在需求评审时，要求至少要问到为什么、有没有其它更好方案等;

– 鼓励兄弟们互相间的沟通，鼓励兄弟们从RTX里走出来，面对面的交流;

– 鼓励兄弟们就自己的工作、团队的各方面提出优化建议;

– 例会上，虽然研发管理平台已经有足够的信息，仍然要求兄弟们进行自由表达。

每个开发兄弟都是一座富矿，PM们要让兄弟们不只是会茶壶口微微冒热气，PM们还要让兄弟们勇于把茶壶盖打开，亮出自己一肚子的热腾腾细细煮好的饺子，之后就静待神奇的收获吧。以笔者团队的双周分享为例，每一期的内容和分享时的妙语连珠都时常让人赞叹不已。现在，团队的目标是，下半年，争取让部分开发兄弟走上整个电商的大讲堂。

沟通是个很系统的工程，我们没有办法可以一下子提高所有人的沟通能力，但是我们可以去鼓励沟通行为的本身，从而提高沟通的意愿与能力。

　　明晰责任，接口清晰

责任是一件很有趣事情，一旦分摊到很多人身上，大家就会习惯性的将其从自己身上寄托到其他人身上，这与高尚与否无关，就像笔者老家常说的，一龙治水粮满仓，二龙治水河底干。

　　在笔者的团队，起初相关矛盾会出现在两个地方：

– 需求状态不透明，不能快速哪些需求可以进行排期，哪些需求其实已经发布完;

– 外部向团队提需求时，可能是找TL，可能是找几个产品经理中的某一个，也有可能直接是找开发兄弟或项目经理;

这其实导致了一些混乱，第一点解决比较简单的，需求都可以进行充分拆解，落实到人，一来责任清晰了，二来工作量评估也可以更为准确。再辅以前述的水果会基金捐献制度，需求状态的流转更及时可信。目前流程定下来后，经过一段时间以来的实施，大家已经形成了每天去查看状态并流转的好习惯，水果基金的捐款收取难度是越来越高了。

　　第二点就会比较麻烦些，需要团队内外双向的互动来推动，最后定了几条基本的准则：

– 所有需求，都必须由产品组进行对接评估，通过后再与开发侧、测试侧共同评审;

– 开发人员，开发Leader和项目经理在接到外部需求时，需引入相应产品经理介入跟进;

– 产品组按目前业务方向，对人员进行分工，明确相关责任与接口方向，在各方来提需求时，可以方便的找到对应的产品接口人。

曾经需求来时，开发组就像草船借箭中的草人，每每被劈头盖脸的需求直接轰击，膝盖都不知道中了多少箭。几板斧下来，首先是进行产品组，开发组的责任划分，然后进一步定位好产品接口人，一下子天空清净，蝗虫箭雨再也没有了，需求开始像涓涓流水从产品组缓缓而来。在此感谢产品组兄弟们在前线的辛苦工作与支持。

在兄弟们被各种外来的嘈杂折腾得烦不胜烦的时候，我们应去倾听各种报怨，鼓励说出真实的心声，从而想办法通过厘清责任，重新界定各自的权力与义务，来让事情重新顺畅清爽起来。

　　适度计划，有序敏捷

　　初到团队的时候，每每有人问笔者：

– 可不可以快些，更快一些，咱们不是要敏捷么?

– 为什么要去做计划，难道咱们不要更快的响应么?

– 团队没有时间可浪费，难道咱们不能拍完脑袋就立即实现，看看效果么?

等等诸如此类，似乎快就是敏捷，敏捷就是快;似乎因为会变化就完全不需要规划;似乎一切就是极快的响应，极快的去试，而不需要方向性的指导与评估。那么团队有没有可能做到，既不失于规划，又不失于快速?

先回到笔者团队的现实，初入团队内的时候，团队内的计划性是比较弱的，强调的是按周排期快速响应各种业务需求。在接手时候，排期已经成了较大的问题，让所有人头痛不已，同时较远期的规划也变得艰难，在日复一日的埋头苦干中，没有空去看方向。因此决定还是进行适度的计划，来让团队在可预期的一段时间内，对即将开始的工作有个大致的预期，同时仍然开启周常规迭代，来对零散紧急的需求进行响应。整个计划链与常规紧急响应调整后现状如下：

上图中，计划外需求有几个分支，如紧急且复杂的需求，将按照优先级依据一进一出的原则进入当月的月度计划，在项目型迭代中进行开发;不紧急且复杂的需求，则放入下月月度计划。

在这种长短迭代结合的协作之下，笔者团队可以较有效的使产品保有一定的规划性，同时又能对日常紧急需求进行及时响应。有适度计划带来的秩序和节奏，又不失敏捷的交付与响应。

很难说这种方式是敏捷还是传统的RUP，这更像是参考两者后量体裁衣的实践，没有包治百病的最优方法论，是为没有银弹。笔者在此抛个砖，希望所有团队都能给自己裁出一身合体的好衣裳。

　　理念宣导，水到渠成

　　“我手执钢鞭将你打!……”阿Q兄当年有个梦想就是拿着钢鞭当领导。咱能学他么?好歹也是受过高等教育的，再说了，咱就一普通PM,手上也还真就没有钢鞭!是不是没了钢鞭事情就没法推了呢，美帝和我党用历史经验告诉大家，宣传工作才是一个组织的传家宝。回到地面，当大家在一个团队内推行一些措施时，真的感觉不是容易的事情，以下几个问题是通常会被挑战到的：

– 团队运转得好好的，为什么要按这些措施做?

– 这样做会有什么好处与弊端?

– 软性抗拒，应付性的处理下，等不催了就悄悄的停掉。

当然，还会有其它的一些问题，暂列几个典型的做个样例，在推行的过程中，发起人推得辛苦，执行的伙计们也接受得辛苦。个人经验，在一项措施要被推行前，事先的宣导是很重要的，即要在推行前，在团队内进行一系列的导向性宣传，且必须真的以团队长远利益为出发点。

宣导的目的是在事前清理掉可能的误会区，这会有效的防止在执行中误会频生，引出各种牵强的解释，甚至引发冲突;同时团队也有机会在事前做好充分的思想准备，消解可能遇到的阻力，引发愿意尝试的动力。如果确实是一项好的措施，也确实对团队有益，那么在事先充分的宣导后，必然可以水到渠成，事半功倍。

　　分享下笔者团队推行双周分享的事吧，团队曾经是有过双周分享的，但由于忙等种种原因，没有持续下来。现如今重新开张，如何来调动大家的积极性呢?我们专注于去发掘分享对大家的益处，一定要是实实在在的好处，这些好处大致如下;

– 双周分享可以给到大家舞台，让大家尝试去展示自己所长;

– 双周分享可以让大家吸收其他人的经验成果，开阔眼界;

– 分享前的准备，可以有效的总结自己的经验，促进自己成长;

– 分享能力是个人综合能力很重要的一环，并且有助于在司内长期发展。

等等诸如此类，实实在在绝无虚假的益处。宣导的一定是可信的，真实不虚的，为团队成员着想的，这样团队成员才会愿意相信，愿意投入精力来做这件事情。目前团队的双周分享是很不错，每期同志们都会积极准备，而且讲起来也是各具风采。

　　开放合作，共同成长

这个话题比较大，开放合作是大势所趋，就像QQ网购在前些天接入了支付宝，腾讯也在去年开始了倡导整个大平台的开放。双赢的组织和个人，会得到更多正向的支撑与反馈，从而让团队能在更健康的氛围中持续壮大。

这个部分说不上什么经验之谈，更多的是一份寄语，腾讯电商，乃至整个腾讯，大方面需要各个Group的合作，小方面要各产品组、开发组、测试组、运维组、运营组之间的精诚合作，大家才能一起水涨船高。落实到个人，对开发而言需要去尝试理解产品经理们KPI的压力，对产品经理而言要尝试去体谅开发和测试这些后端兄弟的琐碎与不易，团队之间互相理解，互相扶持，大家一起和电商共同成长。

在笔者团队，团队也会有一些尝试，比如开发团队的大讲堂，并不局限于开发技术分享的本身，总是会邀请产品经理、运营、测试来分享他们的工作与体会，从而促进各方的理解与合作。

笔者前述的部分业务高度订制部分移交各业务部门自己处理，在这件事上，其实也是从合作的角度出发，各自做自己最擅长的事，笔者团队提供底层技术平台，业务方按自己的意愿更快速的响应定制，各展所长，在合作中双赢。

同时，团队也在致力于运营平台的建设，最大限度的将相关的运营合作能力开放出来，让运营可以对程序的结果进行个例的自主优化，该平台的上线，很多运营的同学给予了极其热烈的欢迎，这是团队与运营的合作双赢。

还有团队的鼓励沟通，明确职责与接口，这些都是为了让个人和团队更为开放，能够更地好去分工合作，形成集体的战斗力。

开放与合作，团队会一直进行下去，团队的未来，一定是更开放的，也是更懂合作的。

　　最后的结语

零散的写了很多，从传统到互联网项目，乍一接触会感觉反差比较大，但骨子里，大家都是希望团队稳定、效率高，执行有序、质量高，信息透明、互信高。私心里深深以为，这之间距离确实有，但并不会比想象中的更远。有很多东西都是相通的，比如都应该是以人为本，以计划为工具，以流程建立团队风俗，以绩效为目标。执行层面粒度与倾向性或有不同，大的脉络仍然是一脉相承。

最后列些个人感受到差异，给大家参考下。计划是重要的，但并不是唯一重要的，比如团队必须随时响应更高优先级的突发需求;项目不一定是要规划得大而全整体交付的，大的项目其实是可以拆小来做的，比如保持快速小步的迭代，持续交付;流程不一定是要卡得死死的，其实可以抓大放小，保持团队的自主性，比如在团队成熟后，可以尝试把部分排期权下放;优先级并不是一成不变的，其实每过一段时间优先级可能就转换了，因此需要时常进行更新调整;再比如团队是必须珍惜爱护好的，因为互联网是由无数小型项目串起来的大事业，你将与你的团队在N多的小项目里一起同行到永远。

项目管理，其实没有成法可照搬照抄，不同的团队，不同大环境，都会有自己不同的实践选择，操作上无优劣之分，只有是否最适合自己团队的考量。在此抛砖一块，期望得到更多的回应，互相交流促进。