未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。

版权所有，侵权必究。

图书在版编目（CIP）数据

网易一千零一夜：互联网产品项目管理实战／网易杭研项目管理部著．—北京：电子工业出版社，2016.10

ISBN 978-7-121-29984-1

Ⅰ．①网…　Ⅱ．①网…　Ⅲ．①网络公司－企业管理－项目管理－经验－中国　Ⅳ．①F279.244.4

中国版本图书馆CIP数据核字（2016）第231942号

策划编辑：王莞朕

责任编辑：刘露明

印　　刷：

装　　订：

出版发行：电子工业出版社

北京市海淀区万寿路173信箱　邮编100036

开　　本：720×1000　1/16　印张：20.5　字数：335千字

版　　次：2016年10月第1版

印　　次：2016年10月第1次印刷

定　　价：46.00元

凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888，88258888。

质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。

本书咨询联系方式：（010）88254199，sjb@phei.com.cn。

序一

网易公司董事局主席兼首席执行官　丁磊

自从1997年成立以来，网易公司的成长伴随并见证着中国互联网发展的每个关键节点，从拨号上网和网站的1.0时代，直到当今移动设备的普及以及互联网和各个领域的深度结合。这样的深度结合，往往通过产品来实现，商业模式和用户体验都需要通过产品落地。这让互联网产品在更加异彩纷呈、百花齐放的同时，也给产品研发和管理的过程提出了更高的要求。

企业真正的使命，是能够通过探索和创新，真正给消费者带来价值。在一个对的方向上要专注，要有工匠精神，关注细节，做到极致。网易的互联网产品，在这19年的探索中，既快速应变市场，又坚持着自己“有态度”的工匠精神，不停地创新和打磨自己的产品。产品的背后，工匠精神并不是灵光乍现，而是凝聚着艰苦而科学的工作、多团队的协同以及不断地快速版本迭代。互联网产品的项目管理对此至关重要。

传统项目管理的精髓必须传承，而互联网产品的特殊性又要求管理本身加以变革和调整，在一定程度上管理已不再局限于“项目”，而上升到了“产品”级的全生命周期。这个领域并没有定式的打法，更需要真刀实枪的来自实践驱动的探索。如何让产品真的快？如何减少产品的浪费？如何将复杂的互联网产品环节打通？如何让产品矩阵互相配合发挥作用？如何真正实现产品内外的良好协作？我鼓励项目管理的同事们将这些实践的经验和教训分享出来，记录下网易互联网产品所走过的路，也希望对大家有所启发。

书中内容是网易互联网产品的真实写照，还有诸多不成熟、不完美之处，欢迎大家和我们共同交流探讨。

序二

网易教育事业部总经理　蒋忠波

项目管理对于软件研发过程管理和成功交付的意义不言而喻，经过多年的发展，这个领域已经积累形成了比较完善的理论框架和实践指导。尽管不是银弹，但在风险管理、按期交付、质量保证等各方面，项目管理都起到了不可或缺的作用。

互联网产品的项目管理和传统软件研发既有共通之处，又有非常不一样的地方。软件仍然是互联网产品的核心组件，所以，很多软件研发过程中行之有效的做法都有用武之地，特别是和敏捷相关的一系列实践。但是，互联网产品其实不是一个“项目”，从创意和调研到第一个版本快速上线，从持续迭代到功能渐趋稳定完善，从以产品研发为中心到重心转移至运营推广，有时可能还涉及迁移和下线，这是一个完整的生命周期，在不同阶段对于项目管理的期望其实有比较大的差异。进而，互联网产品非常强调用户体验，从产品演进模式的角度，一般采用小版本迭代加上用户验证、快速调整；从团队结构和协作的角度，也比传统软件更强调设计和运营。另外，实际上，互联网产品是一个范围相对模糊的统称，在互联网与各行各业结合越来越紧密的大环境下，产品形态也越来越丰富，这些都给项目管理带来了新的挑战。

网易杭研的教育产品部和项目管理部都是在2011年成立的，到今天已经携手走过5年了。教育产品逐渐发展壮大，从公开课到云课堂，到中国大学MOOC以及一些新的探索，我们正以自己的节奏推动整个行业的发展。在产品的发展历程中，每个版本规划，每次迭代上线，每轮运营推广，都离不开项目经理的支持和贡献。项目管理部也从支持基础技术组件的研发，扩展到支持网易大部分的互联网产品，包括音乐、阅读、教育、电商等，在业务拓展的同时，作为一个专业团队，项目经理们一直坚持实践经验的整理提升，并以简报和实战录的方式在整个网易公司内部分享。

这本书正是网易杭研项目管理团队在互联网产品研发、运营方面的实践总结，内容非常丰富，既有实用工具、方法的介绍，也有通用能力在特定环境下的经验分享，更涉及引导、平衡等相对比较复杂的话题。开卷有益，无论你是项目经理、产品经理还是研发工程师，相信都能在本书中找到救急的良方或能力提升的建议。

前　言

一千零一夜启动

文／曹智清

如果你爱他，送他去做项目经理吧，因为那听起来很美；如果你恨他，送他去做项目经理吧，因为那会让他痛不欲生。

看到很多工作两三年的朋友们，跃跃欲试地向项目经理转型；也看到逐渐有一些应届生，懵懂而积极地投身于这个行业。再加上“互联网”这一时髦热潮的概念，互联网产品项目管理这个行当变得越来越迷之炫彩，吸引着越来越多的目光。

身在其中，实际上又是怎样一幅场景呢？让我们从网易杭研项目管理的前世今生说起。

1．网易杭研项目管理的前世今生

网易杭州研究院（以下简称“杭研院”）是网易的研发中心，致力于为整个网易集团提供先进的技术解决方案、优异的技术支撑平台和坚实的基础技术支持，在大数据处理分析、云计算、多媒体等方面开展各种前沿技术及相关产品的探索，包括网易云系列产品（蜂巢、视频云、易盾、云捕、易测等）、云信、七鱼、网易有数、网易猛犸等。近年来也扮演孵化器的角色，孕育出各类面向个人及企业用户的互联网产品，包括网易云音乐、网易云课堂、LOFTER、网易云阅读、网易漫画、易信、网易青果等。

网易杭研院项目管理部（PMO）成立于2011年。和很多PMO一样，我们也是个“后来者”，在接受和融入上颇具挑战。我们选择了“服务”之路，虽然项目管理自带“管理”二字，但实际上是为各个产品提供专业的项目管理服务。项目经理们沉到项目最深处，和团队充分打成一片，哪里需要就出现在哪里，渐渐地这支高执行力、高情商的项目经理团队获得了大家的接纳和认同。

与一般的项目管理，互联网的项目经理们长期稳定地对应于同一产品线。我们将项目经理的荣辱与产品线的兴衰充分结合，于是，项目经理不仅仅关注版本的成功交付，更关心团队的长期健康成长。这样的定位，除了解决了项目经理融入感问题，更为项目经理的长期专业发展铺平了道路——项目经理＋团队教练。

与此同时，我们时刻将产品实践中的点滴感受沉淀总结，定期通过内刊和培训的方式进行理念传递，帮助大家解决日常项目执行中的困惑难点。

助人者之路必定越走越宽。目前，网易杭研项目管理团队已从最初的1人发展为20余人，服务覆盖了杭研院所有产品，各个产品团队对于项目管理的基本认知和理念也有了很大的提升。

2．互联网产品项目管理之我见

那么，这些年的互联网产品项目管理，我们到底是如何做的呢？无论是新手还是老人，谈及互联网产品项目管理，有几个痛点必然是共通的。

一是讲究快。互联网的交付速度是以周、天甚至小时来计算的，而大小需求又交错其中，因此，我们不仅需要以短迭代快速交付，更需要有快速应变的研发能力。

二是弱矩阵。大多数互联网企业的项目经理，都生活在弱矩阵结构下，背负责任但却手中无权，需要通过“软实力”构建自身的影响力，继而影响团队达成交付和改进。

三是阶段和角色多样。与传统IT项目管理相比较，互联网产品项目管理同样需要从研发项目管理切入，对项目的成功交付负责。无论是瀑布还是敏捷的方式，项目经理都需要关注范围、时间、质量这几个核心要素。但前后的延展同样需要，向上游的产品端延伸，向下游的运营、销售、客服延伸，最终形成完整的产品项目管理闭环，从而真正有效地取得产品成功和团队改进。不仅如此，不同阶段的互联网产品所需的项目管理方式也各不相同，孵化期、发展期、稳定期的特性各异，产品的生命阶段和团队成熟度阶段交织在一起，项目管理更需要随需应变。

因此，比较强硬的、统一的、完善的项目管理流程和度量，在互联网公司中几乎是不可能实现的（好，我应该去掉“几乎”这个词）。要不要学PMBOK？要，因为那是基本的项目管理框架；要不要学敏捷？要，因为那是非常符合互联网特色的研发方式和精神。但是，真正的高手，不在乎招式，无所谓门派。

多年来，虽然我们放弃了建立完整的项目管理流程，但我们对杭研院各产品现状进行了梳理，归纳了“最小流程集”和“最小数据集”，并长期加以执行和收集。我们无法回答我们属于传统还是敏捷，是否使用Scrum，但我们恪守保障交付的基本点，也用更灵活的方式适应了产品和团队的现状，真正做好产品的业务伙伴。也许，这才是我们得以立足和发展的根本原因。

3．从今夜起

从今夜起，我们将三年多的一个个故事展开，向大家娓娓道来。这本书不是教案手册，我们信奉这个世界没有银弹，但每个团队都可以从中找到适合自己当前阶段的良药。我们记录了自己寻找这剂良药的路途，有时甚至是挫折的经历。也许读者会觉得文风各异，但这些来自一线的干货，真实体现了网易互联网项目管理过程，也希望借此和同行们交流，不尽之处请大家帮助指正！

我们将这些内容分为四大部分：

•　第1章　我是项目经理 　介绍了项目经理们日常基础工作的一些做法和感受。我们既讨论了基础的估算、计划、站会、白板、报告、回顾、风险、沟通等该怎么做，也提出了新手在初任项目经理阶段所需要注意的问题及修炼之路。从本章中你会对项目经理的基本工作有个基本的认识，了解这些看似简单的工作怎样才能真正做好。

•　第2章　高度延伸 　在前一章节的基础上，对项目经理们的日常工作做了进一步深挖，从有效管理和提升的角度，思考了各个阶段项目经理们实操工作背后的深层原则和思路，针对一些复杂问题进行了更系统的整理。在这部分末尾，你会对项目管理工作及其价值有更深的认识，也可以对若干个典型问题有更完整的解题思路。

•　第3章　宽度扩展 　探讨了若干个项目管理和与业务结合的实战过程中的实际问题以及我们的实践方式。这章集结了数据分析、跨项目沟通、项目管理工具等实践，读完这一章你便能清楚地知道该如何掌握项目的方方面面，它们覆盖整个产品面的管理业务。有了这些工具与武器，你便能在项目中如鱼得水，做深做透。深入产品，帮产品赢！

•　第4章　深度修炼 　当项目经理经历了多年项目日常工作淬炼后，升华到另一个境界——自我修练与管理能力提升，此时该如何管理好一个团队？该如何持续提升自己的核心竞争力？当遇到困境时该如何突破自己、更上一层楼？本章借着小鱼儿的故事，把项目经理成长的历程，真实又逗趣地呈现在你面前。

读完后，你将立体地了解互联网产品项目经理从基本专业技能到业务应用再到个人修炼的完整路径，也会看到一线互联网产品研发的现状和自我演进之路。

那么，就让我们赶快开始吧！

目　录

序一

序二

前　言

第1章　我是项目经理

给项目经理新手的五个建议

项目管理境界之一二三

估算那些事儿

工作时间打扑克？——扑克估算之我见

走一步，看三步——怎么做好进度计划

我们是如何开每日站会的

我的站会感悟

白板的艺术

不简单的周会周报

让你的报告会说话——如何有效、有料地进行工作汇报

项目管理≠烦琐的会议

高效回顾，引导团队从优秀到卓越

项目管理从零开始

悬崖边的舞蹈——小议风险管理及在互联网项目中的应用

心的修炼——项目沟通的四个原则

第2章　高度延伸

项目启动阶段，项目经理何去何从

产品初创阶段，项目管理该做些什么

项目初创期，如何帮助项目走上正轨

欲速则不达——冻结制度小谈

当所有需求，涌向我的时候

我们如何赶上工期

大版本下，团队如何完成项目目标

没有什么是不可能的

项目经理需要的能力——掌控冲突

网易云计算的大规模团队沟通

产品中的风险管理

我们的敏捷路

敏捷教练与项目经理

云主机项目的持续改进之路

第3章　宽度扩展

数据收集埋点流程梳理

打破“原地转圈圈”的魔咒

输了你赢了世界又如何

初试跨部门项目

小议合作项目中主要风险及其应对措施

Bug Bash手把手教你做

我们的持续集成之路——提高项目交付能力的利剑

JIRA工具的云计算中的应用实践

上线精神——献给开发兼做运维的同行

苹果审核血泪史——说说加急那些事儿

电商客户端Apple Pay接入实践

软件外包采购类合作项目的建议

建设学习型组织——读书小组实践

第4章　深度修炼

项目经理的核心竞争力

没有权力，怎么做项目管理

走出“已知”的舒适区

项目经理的平衡之道

给新上任的领导者的五个忠告

主管的引导者角色

从混沌中找出根本原因

项目成功路上的绊脚石，你遇到了吗

超越“老和尚”期望的那三两件事儿——论个人工作方式

如何建立与团队的信任

小鱼儿学沟通——性格色彩

小鱼儿学沟通——引入变化

小鱼儿学沟通——透过现象看本质

小鱼儿学沟通——向上管理

小鱼儿学沟通——走出困境

作者介绍

致　谢

大咖荐语

沉淀组织使能因素，赢得持续竞争优势　清华大学国际项目管理研究院副院长　强茂山

提升能力，将不可能变为可能　Odd-e敏捷教练　吕毅

一本有态度的书　Odd-e唤醒者　滕振宇

附录A　项目管理增值服务介绍

第1章

我是项目经理

介绍了项目经理们日常基础工作的一些做法和感受。我们既讨论了基础的估算、计划、站会、白板、报告、回顾、风险、沟通等该怎么做，也提出了新手在初任项目经理阶段所需要注意的问题及修炼之路。从本章中你会对项目经理的基本工作有个基本的认识，了解这些看似简单的工作怎样才能真正做好。

给项目经理新手的五个建议

文／雷蓓蓓

初为项目经理，一开始很难抓到重点。我们资深的项目经理从实战经验中提炼出的几点实用建议希望能为你拨开迷雾。

我真正从事项目管理的时间并不算长，可掐指算算，经历的大大小小的项目也不少了。作为过来人，回想当时的自己，在摸索的过程中走过一些弯路，也幸运地得到过很多前辈的帮助和指点。以下浓缩的五条建议，有经验教训，也有心得体会，希望能给刚上路的项目经理（Project Manager，PM）新手们一些帮助。

建议一　多想想项目到底需要什么

“我们应该每天都开个站会沟通一下情况，另外这个工具也要换一个，××比这个好用多了。”

有的项目经理拿到一个项目，上来就开始左突右攻，恨不得把十八般武艺都套上，结果很可能惹来不必要的麻烦，且收效甚微。接手项目之前，与项目中的重要干系人加强沟通，理解前因后果，多想想项目到底需要什么，对于项目的成功推进至关重要。

每个项目都有它独特的需要，时间、成本、质量到底哪个因素更重要？各个角色目前的痛点在哪儿？哪些是最先需要解决的？哪些是隐藏的积弊？大家对项目管理的认知和接受度怎样？我要通过怎样的途径，全面推进，还是一步步改善？从哪个角度切入？这个蓝图是否清晰？是否与项目负责人沟通到位并达成一致？这些问题能够帮助你理清思路，从项目的真实需求出发，解决问题。

建议二　不要凡事恨不得事必躬亲

“跟某某说了几次，到现在还没做好呢！频频出问题，那个费劲，还不如我替他做来得爽快。”

替别人代办他们本该自己做的事情，对于团队长期而言反而效率是最低的。新手项目经理要进行观念转变，从自己去做这些事，到想办法让别人去做好它。实际上，比起自己直接去做，影响他人去驱动一件事情，要难得多。简单来讲，成功地施加影响有三个要素：获知（Awareness）、动力（Desire）、能力（Ability）。事实证明，停留在浅层次的信息传达，比如单方面的工作交代，并不足以让人产生动力从而促成有效的行动。获取理解及认同，激发动力是项目经理努力的关键。最后，还要确保他有相应的能力来做好这件事情，例如初期提供一定的辅助、必要的培训等，能推动事情真正付诸执行。

建议三　不要追在别人屁股后面做监工

“好，我不亲力亲为，活儿都分出去了，我监督大家把事情做好吧。我先跑去问A，这个做好没有，A反馈说这事你得找B和C，于是跑去问B和C，一天下来各处跑遍了事情还是没个说法，反倒讨了一身没趣。我该怎么办？”

其实，项目经理最该做的，是跟大家一起把事情从头到尾各个环节捋顺了，建立一套对应的流程规则，明确各个角色在过程中的职责，并获得大家的认同，让这个机制自行运转起来。记住应该是规则在约束大家的行为，而不应该是项目经理。当成熟的秩序在团队中形成之后，解放出来的项目经理，就可以更进一步，致力于目标激励、团队建设等更高层面的工作，变“赶”为“引”。

建议四　言必信，行必果

“刚进入一个项目，人微言轻，发给大家确认的邮件没人回，组织开会人叫不过来，多次提醒某人均被无视，提的建议没人在意，一个没有任何授权的项目经理菜鸟如何建立属于自己的领导力及影响力？”

无权力下的领导力（Leadership without Authority）是弱矩阵结构下的项目经理必修的一堂课。适当的时候，懂得巧借力，会帮助你争取支持与重视，但 要记住的是讨巧的东西必不会长久。要想建立属于自己的领导力，核心在于真正赢得团队对你的信任，建立自己的可信度，打造个人品牌。而信任的获取，靠的是一件件事情中一点一滴的积累，没有捷径可走。

首先，在专业上做足功课，要求别人做的事情，自己要做得更专业，起到表率作用；再者，言必信，行必果。学会为每次会议、每次发布、每个跟进事项做收尾，发出去的邮件、自己说过的话，哪怕没人记得，也要有始有终，自己给自己一个响应，给大家一个交代。

建议五　不一定要强势，但一定要内心足够强大

一个专业的项目经理会尽可能让自己客观、公正。但无论多么客观，你都会遇到形形色色的人，持有形形色色的世界观和人生观，一定会有一些麻烦，最终归结于“人”的问题。哪怕你已经尽全力尝试，依然无法改变某些人认同你的观点，有些思维方式根深蒂固，怎么办？

这个问题一度让我受挫，但经历了几次类似事件之后，我渐渐明白，我无法改变他人，我甚至不应该试图那么去做！真正应该和可以改变的只有我自己！于是，我学会了允许和接受这种差异的存在，并与之共处；我学会了求同存异，找出一致的地方并努力放大。一个好的项目经理，不一定强势，在一些事情上可以让步、可以妥协，但内心一定有自己的坚持。

项目管理境界之一二三

文／陈海春

项目管理工作入门易，但出色不易。成为优秀的项目经理是否有规律可循？本文从三重境界说明项目管理循序渐进之道：做项目，懂业务，懂人。做项目是让项目进行下去，懂业务是知其然知其所以然，懂人是能够在利益相关人满意的基础上交付项目。

上周五和一位刚刚开始做项目管理的新同事聊天，就如何开始项目管理生涯、如何做项目计划、如何引导项目站会、如何克服自我简单粗暴强势的管理风格等问题进行沟通和交流，不知不觉间一两个小时就过去了，聊到了不少建议和我的一些个人经验。面对面的沟通往往口慢而思维快，可能无法全面而系统地表达。趁着周末在家闲来无事，和着江南烟雨时节的安静，回顾自己过去近10年的项目管理经历，概括出项目管理的三重境界：做项目，懂业务，懂人。不同的人、不同的经历、不同的公司、不同的行业对项目管理的境界都会有不一样的理解和看法，这些仅仅是我个人粗浅的总结，欢迎大家拍砖、反馈、交流。

境界一　做项目

每个人的项目管理生涯都开始于交付一个一个小的项目，也许某一天上司安排了一个项目给你，并要求在某某日期前上线、实现一堆功能。用项目管理专业术语讲就是需要在满足项目铁三角（范围、时间、成本和质量）的情况下交付项目。

紧接着就开始紧锣密鼓地执行项目了，WBS、项目计划、站会等一般项目管理的工具、最佳实践都用上，基本上只要认为挨着边的都用，使出了浑身解数和十八般武艺，甚至出卖个人的“色相”和美食与项目组成员搞好关系，因为此时满脑子想的是我不能让领导失望，要全力以赴地准时交付项目。记得我自己在第一个项目交付过程中，还不知道什么是项目管理铁三角、不知道敏捷，只是根据以前的耳濡目染和对相关领域的了解，拉上几个人，分工、计划、绘制甘特图、跟踪进度、加班、项目交付、完事儿，一系列工作做下来发现也能保质保量地交付项目了。当时就想项目管理不怎么难嘛，只要跟着计划走，把既定的事情搞定就可以交付项目了。难道项目管理真的这么简单吗？

对于一个定义非常清楚、一次性的项目这么做应该没有什么问题，这也是项目管理的最起码的要求，概括而言，就是在项目管理的铁三角的相互制约下交付项目，如图1-1所示。这一境界的项目管理能够满足基本要求，但往往很多时候基本相同的项目团队成员在做完一个项目后还需要继续做后续的项目， 甚至还是相同的项目发起人，那么在这种情境下需要步入后续的境界二、境界三，而不仅仅是境界一的“一锤子买卖”了。

图1-1　项目管理境界一的铁三角

境界二　懂业务

在这层境界中，项目管理的介入时间点需要前移，参与项目立项前的讨论。理解业务，能够成为业务部门可以依赖的左膀右臂，而不仅仅是被动地接受项目安排，根据设定好的铁三角约束条件交付项目。你需要从业务的角度出发，去引导和参与规划、定义项目，提炼出项目，化被动为主动，清楚地知道为什么立项这个项目，它所带来的业务价值是什么，是通过衡量哪些不同方案和利弊后才做出这样的选择的，外部环境有什么样的制约。项目的最大风险是公司内部风险还是外部市场／政策风险。只有自我认同项目的价值，才能在后续项目执行、讨论过程中遇到问题时能够说服其他项目成员，也能够获得其他人对项目目标的认同。

虽然说互联网领域瞬息万变、唯快不破，但仍然可以引导业务部门做出一段时期内的规划图（roadmap）（如1个月到3个月的规划），促使业务部门、从业务发展的角度去思考未来一段时间该领域最重要的事情是什么、项目做成后将有什么样的收益。项目经理在这期间应该参与讨论，并发挥引导作用，引导建立该业务领域的重点事项规划图，然后根据具体情况设定不同优先级的项目，并进行相应的项目管理和交付。

图1-2是笔者组织参与的公司某部门的月度规划图讨论会的一个实例。在 这个会议中，业务部门主管、公司高层对仓储物流现状、未来的规划进行沟通和讨论而形成如图1-2所示的结论。

图1-2　某部门月度时间规划图

在这一层级的项目管理范畴中，需要在境界一的基础上加入对“业务部门的持续发展”的理解。项目经理能够想业务之所想，从业务角度出发去做项目，也能够权衡项目对业务部门的重要性，概括出如图1-3所示的项目管理约束条件集。

图1-3　项目管理境界二的铁三角

懂业务不仅是指对业务领域熟悉，还包括对实现其业务需求的产品方案的了解，知道使用哪些技术来实现，以及对技术实现过程中的难点和重点需要有 清晰的把握。例如，要想熟悉仓储物流业务，就需要去仓库参加定期盘点、打包、理货、上架、入库审核等一系列的操作，才能真正对业务有深刻的理解。话说京东创始人刘强东每年都要当一天的快递员，为客户亲自送货上门，为的就是了解系统、熟悉基层业务。

境界三　懂人

同一业务领域中前后不同项目参与的人员基本相同，但人员的诉求各不相同，如果能在项目的交付中结合个人的诉求，既能交付项目，同时也能满足项目成员的个人发展要求，将是大家乐于参与的项目。例如，测试同事希望通过参与API接口测试的相关自动化测试开发工作，来提升自己未来的市场竞争力，项目经理可以考虑在时间要求不是那么严格的项目中安排相关的自动化测试工作。

图1-4　项目管理境界三的铁三角

另外，需要带着同理心去交付项目，“士为知己者死”。例如，一起和项目团队共同加班，对产品方案一起沟通讨论。又如，在强制要求996工作制的部门中就不要再想方设法去压榨项目时间了，因为大家已经处于一种比较高压的状态中，此时应该想想如何为项目减压，建立“防火墙”机制，如通过项目优先级的调整、人力聚焦于重点项目来使非重点项目的节奏稍稍缓和一点，让人员轮番参加重点项目，将马拉松变成一站一站接力赛。

总结起来，项目经理要活儿好、让人满意、及时进行“上下左右”不同对 象的汇报沟通，从做项目到关注业务的发展、再到对人的关注。因此对这一境界的项目交付结果的衡量还需加上利益相关人的满意度，拥有一种平衡组织中不同人诉求的能力（见图1-4）。

《孙子兵法》中说：“水因地而制流，兵因敌而制胜。兵无常势，水无常形，能因敌变化而取胜者，谓之神。”项目管理也一样，从做项目、懂业务到懂人虽然是一个递进的过程，但对于不同的环境仍然需要灵活应变，在不同的组织环境中需要将重点放到不同的境界。

估算那些事儿

文／何燕华

估算，在外行人看起来是一件再小不过的事情了，但是笔者认为它在所有项目管理技术里面是比较核心的一部分，蕴含着很大的学问。什么样的情况下该选什么样的估算单位，用什么样的估算方式，以及各自的优劣势，本文都将详细介绍。

说在最开始

对于估算，团队常常会有这样的困惑：花了大把时间来估算，最后却发现与实际还是有不小的偏差，到底有没有必要做估算？怎样来做估算？

俗话说，行百里者半九十，意思是说一百里的路走了前面九十里其实只完成了一半，剩下的十里仍需要花很多的功夫。那么现实的生活和工作中，我们是不是也经常遇到这样的情况呢？回想一下，会不会有这样一种经历：打扫卫生，让房子从凌乱到整洁只需要20%的努力，要让房子从整洁到一尘不染却要花费80%的努力。那么我们就要审视一下，在精力有限的情况下，从整洁到一尘不染有没有必要？房子从凌乱到整洁是不是就已经足够了？我想没有洁癖的一般人，就如我，会觉得后面那个过程的性价比实在太低，完全没有必要。

回过头来看我们在项目中的估算是不是也可以类比，从无估算到有估算其实花的是比较有限的精力，但是从有估算到追求“准确”估算却是个漫长的过程，并且有数据显示，我们花一些时间得到的估算数据与花费大量时间而得到的结果不会差很多。《敏捷估计与规划》这本书中提到，估计的准确度和投入的工作量之间存在图1-5的关系。

图1-5　估算准确度和投入的工作量之间的关系

因此我们认为估算还是需要做的，有了估算，在团队协作中，各角色才知道自己大概要在什么时间安排什么工作。但是在估算的时候不必花费大量的精力强求精确，更何况我们也无法做到精准。估算只是估算，只要做到尽量合理、尽量贴近真实值即可。

估算单位的选择

有的团队往往会在估算开始时纠结于如何选择估算单位，因为合理的估算单位选择是影响估算成功的关键因素。那么究竟该如何选择呢？

1．理想人日

理想人日是指成员在不受干扰的情况下，全部时间都用于开发需求所需的天数。理想人日的劣势在于：小组成员对技术和项目的熟悉程度、个人的经验和能力不同，会导致基于理想人日的估算值有一定差异。例如，你问一个擅长C语言的成员某个需用Java开发的功能的理想人日，他也许会告诉你是5天。 但是你问一个擅长Java的成员同样的问题，他的回答也许就是1天。这样的差异会导致我们对任务规模认识的偏差，很难衡量项目的实际“大小”。而它的优势则在于：对于团队外部的人来说，理想人日更容易被理解，无须解释。对于团队而言，它使估算更容易开始。

2．理想人时

理想人时是对应理想人日而存在的，只不过它的粒度更小。在熟悉需求的情况下，用理想人时的估算会更准确些。想象一下，让你估算接下来1小时能完成多少工作任务和接下来一天能完成多少任务，哪个更接近真实情况？我想应该是前者吧。因为一天内能做多少工作，我们需要去除很多“杂事”（如喝水，上厕所，跟同事唠嗑，戳网页……）来估算纯干活的时间，这一点往往较难一些，总会存在一些偏差。但是如果要估算接下来1小时能做什么，应该就比较容易了。理想人时的估算优势就在于：在充分理解需求的情况下，能帮助团队做到更靠近真实值的估算。而缺点是：对于一些大的需求无法做到如此细的粒度。

3．故事点

故事点来自敏捷的概念，是对任务规模的估计，它是一种相对概念。例如，需求X为4个故事点，需求Y为8个故事点，则表示Y的规模是X的两倍，但并不表示开发Y比开发X要多一倍的时间，因为这还取决于由什么样技术熟练度的人员开发。故事点的优势在于：一方面，基于故事点的估算更纯粹，不会因为开发人员的变更、时间的推移而改变。换句话说，项目半途有成员离职，加入新的成员，此时我们不需要对每个任务都重新估计，只需要重新评估一下是否需要调整插入到当前迭代的故事点数。另一方面，由于人们往往更擅长于相对估算，所以故事点会让估算更迅速。想象一下，让你估算一杯水是另一杯水的几倍，是不是比让你估算两杯水各是多少毫升来得更容易呢？劣势在于：一方面，由于编程语言不同或者业务分块，大家很难找到一个共同熟悉的需求作为基准，那么用故事点作为估算单位的方式就很难开展了。另一方面，故事点相对于其他估算单位更难被理解，这也使估算难以开始。

估算的几种常用方式

1．自下而上的估算

由每个开发人员估算自己的任务时间，然后将所有的任务汇总，并考虑过任务间的依赖关系后，就排出了计划。该方式适用于具有以下特点的团队：成员间业务独立性强，相互之间的业务熟悉度不高且熟悉成本较大，较难进行共同估算；各成员的经验相对丰富，对自己的任务能进行较准的评估。在这样的团队应用该估算方式有以下优势：

•　估算效率较高，各自任务的估算可以并行进行。

•　准确度也会较高，因为大家对自己的任务和能力都比较熟悉。

2．专家判断

由一个或多个专家根据相应开发的情况给出任务的估算值，但前提是你能找到这样一个熟悉整个项目所有业务和整个项目团队成员的专家或专家组。笔者所在的团队一般会由开发领导者来充当这样的角色。它的好处显而易见：

•　通常不需要太多的时间。一个人估算就不存在太多的交流成本。

•　准确度有一定的保障。有证据说这种估算方法比其他分析性方法更准确。

3．扑克估算

该方法是以扑克牌的形式进行估算。估算开始前，每个估计者会分到一叠扑克牌，每张上有一个数值，如0, 1, 2, 3, 5, 8。然后由负责人对某个需要进行估算的需求或者任务进行讲解，讲解完之后，所有人可以向该负责人提问关于该条需求或任务的问题，直至足够了解，然后所有成员各自挑选一张扑克牌代表自己对该条目的估算。例如A给出8，而B只给了2，这样就需要A和B各自说明自己估算的理由。这样一轮下来，大家对该条目又加深了了解，然后进行第二轮估算，如果相差还是很大，则继续下一轮。大多数情况下至多经过两轮，大家的估算值已经非常接近了，就可以取平均值作为对该条目最终的估算。扑克估算的好处在于：

•　集合了所有团队成员的意见，比一个人估算少了很多主观成分。

•　在估算过程中，强化和深化了大家对需求和任务的理解，将任务考虑得更加细致，降低了不确定性给计划带来的冲击。

•　这种形式使相对严肃的计划和估算变得更加有趣，但是不得不承认，这需要比前两种方式更多的时间成本。

如果你们团队对于这种估算方式的接受度较高，能够找到一个故事作为基准，大家的编程语言一致，有能力评估同一个需求，就可以通过这种方式把需求的理解做到位。另外，这种方式也可以演化一下，当团队成员间对某个需求的工作量有较大分歧的时候，就可以让团队采用这种方式来达成一致。

实际应用中的估算实例

1．故事点＋扑克估算

Datastream

团队稳定合作近2年，尝试敏捷1年多，开发语言统一，长期服务于一个产品，成员间对相互的业务也都比较熟悉。

估算单位和估算方法：由于很容易找到大家熟悉的一个用户故事作为基准，团队选择基于故事点的扑克估算。团队在经过几次迭代之后，基本上确定了团队的开发速率（每个迭代能完成的故事点数）。在接下来的迭代中，团队通过扑克估算确定了每个用户故事的故事点，再根据用户故事的优先级一个个插入迭代开发计划中。扑克估算促使大家把对需求理解的不一致提前暴露出来，能在很大程度上减少交付成果和需求不一致的情况。

除了Datastream，网易云阅读、网易漫画、网易Gacha等产品开发过程中，当大家对需求工作量分歧较大的时候也采用这种方式。

2．理想人日＋专家判断

网易云硬盘

组成：9人团队

现状：团队组建不到3个月，开发语言不统一，成员比较年轻，对系统的熟悉程度也不高。

估算单位和估算方法：一方面，由于成员之间的业务熟悉度不高且开发语 言不统一，团队无法轻易找到一个合适的基准用户故事，所以团队的估算都是基于理想人天开展的。另一方面，由于开发人员数量较多且一部分成员经验比较欠缺，无法很好地进行团队估算，所以团队选择采用专家判断（开发领导者给出估算）为主的方式进行计划。

除了网易云硬盘，网易云安全以及其他一些成员经验有限的新团队也在一段时间内采用这种方式。

3．理想人时＋自下而上

网易用户中心产品

组成：20人团队

现状：团队组建约3个月，产品模块较多，不同模块有不同的负责人，成员对自己模块的业务逻辑比较清楚，但是对其他模块的业务了解甚少，且一人会同时服务于几个项目。

估算单位和估算方法：由于成员间业务熟悉度不高且开发语言不统一，团队无法找到合适的基准故事点，而且一个成员并行任务较多，成员自己都很难判断自己的安排是否合理，所以需要更精细化的估算单位，团队因而选择理想人时作为估算单位。另外，也由于模块较多，开发领导者不能熟知各业务逻辑，所以团队采用了自下而上的估算方式，由成员各自估算各自的任务，进而给出开发计划。

除了网易用户中心，还有网易云主机等产品也曾采用这种方式。

网易理财

组成：40＋人团队

现状：团队组建半年多，业务种类较多，大团队中分小团队负责不同的业务。

估算单位和估算方法：理想人日对于团队来讲更直白，团队中一个人主要会在一个项目开展工作，无须更精细的单位，所以团队选择的是理想人日作为估算单位。由于团队较大，业务的种类也比较多，团队无法找出一个人能够作为专家来判断，所以选择自下而上的估算方式。

该种类型的方式是网易大部分产品目前采用的方式，例如网易云音乐、网 易云课堂、考拉海购等。

通过以上几个例子，笔者想说明的是：各种估算单位和估算方式本身并没有好坏之分，只有合适不合适之说。每个团队都需要根据成员和项目的现状来进行选择。随着项目阶段的变化，以及人员的调整，估算的方式都要随之变化。以上所述也只是在一些项目的某个阶段、某种状态下的例子。如果生搬硬套只会弄巧成拙，得不偿失。

关于估算，我们需要注意的点

（1）估算仅仅是一个预测，当对外（或者对老板）承诺项目完成时间的时候，最好提供一个日期范围，让听者知道你的估算只是预测。

（2）不管用什么估算方法，将任务分成更细粒度总是有利于估算的。

（3）团队需要练习估算方式并且收集反馈。每次估算对应的开发结束后，大家需要回过头看看我们当初做的估算是否合理，如果不合理，那么就要分析原因，并且在下一次尝试中做调整。

（4）估算需要反复进行，当项目进行到一半时，发现估算过于乐观了，就需要对剩下的工作进行重新估算。

（5）当发现团队成员经常过于乐观或者过于悲观的时候，我们需要采取相应的措施。例如，有的团队经常比较乐观，那么我们在整体规划的时候就需要给出更多的预留。而当有的团队过于悲观的时候，我们的计划又要适当做得更激进一些。

工作时间打扑克？——扑克估算之我见

文／雷蓓蓓

估算在项目管理的知识技能中占据了很重要的一席。本文将从估算带来的价值以及扑克估算的诸多好处来向读者展开介绍。

不知道是不是因为勾起了大家的牌瘾，最近一阵扑克估算很是火了一把，在几个项目尝试后很快蔓延开来，很多项目团队都跃跃欲试。

尝试的过程中难免产生一些困惑，在这里做个澄清，把我实践下来所理解的扑克估算的方方面面跟大家一一道来。

在开始之前，首先需要澄清的是，在某种程度上，估算其实是在预测未来！预测未来是件非常难的事情，我们看看天气预报，就知道人类在这项工作上有多么的不靠谱了。

为什么要做估算

估算本身很困难，而花在估算活动本身上的时间，又并不能够对产品本身产生直接的价值，那么为什么我们要花时间做估算呢？为什么气象中心还是坚持不懈地发布自己的预报呢？

首先，用户需要一个预期，甚至承诺，这个功能什么时候都需要提供。

其次，管理层需要可预测性，某些决策需要基于估算而做出，即便这个估算还不那么准确，但总是聊胜于无。

最后，团队需要了解如何相互协作，在哪个时间点能够拿到所需要的接口或素材，据此相应地规划并安排自己的工作。

总之，估算可以帮助我们找到一个合理的计划，给用户、管理层以及团队自己一个稳定的预期。

为什么选择相对估算

传统的估算方法，通常是基于人天／小时的绝对估算。而敏捷中所推荐的扑克估算方法，则是基于故事点的相对估算。这种估算一开始容易让人找不着北，大家会习惯性地问：“那这个故事点到底代表什么？单位是什么？做完了相对估算是不是还要再转化为人天？与人天的对应关系又是什么？”

要想讲清楚这一系列的问题，我们需要先搞清楚为什么选择相对估算。相对估算有哪些好处呢？

首先，相对估算更符合人的本能认知。电脑区别于人脑的一大特点，就是电脑更擅长计算与处理绝对信息，而人脑则对相对印象更有感觉。我们可能永远搞不清楚手上的核桃和苹果的真实重量，但却能很直观地判断出苹果更重，重量嘛，大概相当于“6个核桃”。瞧，这就是人类的本能认知。

其次，正是因为相对估算更符合人的本能认知，因此掌握之后，它能让估算过程变得更快、更简单。因为我们不再需要纠结于这个任务到底需要5天还是4.5天，我们只需要为手头的工作定义一个参照物（1个核桃）作为基准，然后拿其他的工作与之相比较，工作量是更大还是更小、复杂度是更高还是更低，然后给出一个大约的倍数值就可以了。

相对估算需要转化为人天吗

在实施Scrum的项目团队中，最后得出的故事点的数值，不需要再转化成人天，这是由Scrum的特性所决定的。

在Scrum项目中，我们会以迭代（sprint）为周期来做增量交付，这直接改变了做计划的方式。传统项目中，我们需要根据基于人天的估算来确定各节点及最终发布的日期到底是几号，而在Scrum项目中，周期是事先约定好的。每个迭代的计划不需要确定日期，而只需要估算下一个迭代我们能完成多少工作。由于迭代固定周期性的特点，在几个迭代之后，我们就会得出一组相对数据（如35个故事点），来衡量团队的生产效率。根据这个生产效率，我们可以很容易地快速进行相对估算，不需要转化为具体人天就能得出结论。

当然，如果这是你的第一个迭代，没有经验数据，可以尝试转化为人天找找感觉，或直接根据团队的直觉来做出判断。

如果你是在传统项目中做扑克估算，那么我的建议是可以直接用人天来进行估算，虽然不如相对估算那么便利，但至少可以获得各种好处。

扑克估算有什么好处

1．团队一起做估算，估算更全面细致

在传统的项目管理中我们也会做估算，WBS分解后完成任务分配，然后 每个人估算自己的。如果每个人只对自己的那块比较熟悉的话，估算结果往往会有欠考虑，特别是相关性较强的模块，会出现较大误差，从而为项目后期埋下潜在风险。

在用扑克估算法时，一开始我们特意不进行任务分配。对于每个故事，都会由全员出牌，包括各个模块的开发及测试，每个人从自己角度出发想问题，互相补充。比如在扑克估算时，测试的成本会被自然地考虑进去，作为一个整体来衡量。对于测试成本高的故事，大家会一同来考虑进行哪个层级的测试更为合适，单元测试、API测试，还是UI测试？这样涵盖了各方成本估算的结果自然会更全面、更细致。

2．团队一起做估算，需求探索更深入

实践中我们会发现，真正到了让你给出预估的时候，就会有各种各样的问题冒出来。这个需求到底要不要做，是否要满足哪个条件，等等。扑克估算让这个需求探索的过程公开化，通过公开讨论，在早期进一步挖掘和明确需求，帮助我们将需求探索进行得更为深入。

3．团队一起做估算，有助于优化解决方案

大家一起亮牌，经常会有不一致的情况出现，比如一个人出5，另一个人出40，这个时候往往是团队成员间交流解决方案的好时机。问问你的团队，为什么相差这么远，这样的讨论能够帮助大家找出最优的解决方案，并在团队中迅速共享。

如何进行扑克估算

团队应该如何进行扑克估算？在火龙果软件的网站上，《敏捷扑克估算》这篇文章配合实例有非常形象的说明。（见图1-6，文章请见http://www.uml.org.cn/SoftWareProcess/201108264.asp）

图1-6　扑克估算

后记

在这篇文章成文三年多以后，我回顾自己亲身经历及旁观的大小项目，关于估算及扑克估算又有了新的认识。在实际实践过程中，很多项目都尝试过文中所述的这种扑克估算方法，由于其形式新颖活泼，引入时普遍广受欢迎，也确实带来了如上所述的种种好处。扑克估算让各个角色围绕时间预估，增进了彼此之间的沟通对话，将潜在的冲突公开化、台面化，让大家去充分碰撞，然后用一种近似游戏化的方式再去化解掉，这可以说是扑克估算最为精髓的地方。

但同时我们看到，在长期演化过程中，能坚持一直用扑克估算的项目少之又少，多半新鲜劲儿过去就走回老路，怎么简单怎么来。是不是扑克估算终究花哨大于实用呢？实际倒不尽然，说到底，所谓的扑克估算，只是一种估算的招式而已，所起到的作用并不只是为了得到估算结果，而是其带来的种种附加效应。

而至于这些招式，用在什么样的场合，发挥什么样的作用，则完全取决于修炼者自身的把握。用不好，会觉得不过就是花拳绣腿；而真正用得好的，则会慢慢将招式内化。我所见到的一个团队，在尝试扑克估算一段时间后，逐渐形成了估算会议上多方碰撞的传统，然后渐渐地他们发现自己不需要扑克了。因为一旦这种对话机制建立起来了，没有这个道具的参与，对话也能正常进行。 虽然最终看起来似乎并没有坚持做扑克估算，却已内化了其精髓。

以上就是目前我对于扑克估算这个话题的简单认识，希望对各位读者有所帮助。

走一步，看三步——怎么做好进度计划

文／雷蓓蓓

制订项目进度计划是项目经理的必备技能，那么如何做好这一步呢？本文从制订计划的时间点、调整计划的注意事项以及如何做好计划这几个维度来介绍，希望读者能学以致用。

没有战争是根据计划而胜利的，但是没有计划，战争也无法胜利。

——艾森豪威尔

请思考一下这句话的逻辑。

首先，我们承认战争的胜负受很多计划外因素的影响，计划不是万能的。其次，战争胜利离不开计划，计划是至关重要的。

正如同“钱不是万能的，但没有钱，却是万万不能的”。在项目管理中，进度计划也同样拥有举足轻重的作用。

别怕做计划

既然计划如此重要，可却有很多人从心底害怕或排斥做计划。

表面上看，人们会声称自己不喜欢受约束或被限制，自由随性才能激发更大的创造力。这些观点看似无可厚非，特别是创意性或探索性的工作。做计划限制了创作，这种观点站得住脚吗？

严格约束下的创作会将想象力的翅膀完全伸展，并迸发丰富想法；在彻底自由下创作可能使作品散作一盘沙。

——T·S·艾略特（T. S. Eliot）

自由与约束并不矛盾，很多例子表明，约束和限制反过来会帮助创作，比如唐诗、宋词的韵律等。

计划的本质，是团队对何时完成任务的承诺。从心理学层面来分析，排斥做计划的真正原因，在于人们不愿轻易做出承诺。人人都有一种言行一致的愿望，一旦做出承诺，来自内心和外部的压力会迫使我们按照承诺去做。但也正是由于这种下意识的一致性倾向，才让进度计划真正有效。

或许你会说：“我们并不是没有做计划，但计划的执行往往是有问题的，做了也没用啊。”

因为计划的执行有问题，就不去做计划，这种逻辑无异于因噎废食。

计划要趁早

做计划时经常会听到有人说，等策划案定了再说吧，现在也不知道具体做什么，计划做了也是白做。

的确，任何人都很难在早期估计一个项目所需要的时间。说实话，刚刚接触项目管理时，我也是这么想的，后来几次实践下来，渐渐领悟到“越有太多不确定，越应该给出计划”。在混乱不清的状况下，你根据仅有的少量信息给出了期望值，就好比挖了个坑，人们自然会来填满它。马上就会有人跳出来指出哪个时间点肯定不行，哪里不靠谱，渐渐地计划变得越来越充实，越来越准确。更有意思的是，经历了这个指手画脚的过程之后，你会发现人们开始下意识地按照计划做事，那个最初不靠谱的计划竟一步步变成了现实！

项目经理应该做头一个挖坑的人，引导团队拨开重重迷雾，将所有不确定一一落地。否则，模糊的概念永远停留在高层或某个人的脑袋里，不会对团队产生任何实质的影响。

做项目如同下棋，高明的棋手，走一步看三步。好的计划必须领先于项目实际，要有一定预见性。

调整计划要谨慎

计划绝不是固定不变的，相反，计划是调整的基础与依据。在整个项目周期中，为应对随时可能出现的变更，计划永远是个反复修正、渐进明细的过程。另外，在项目进程中，随着信息越来越详细，估算会越来越准确。因此，计划需要持续地改进与调整。

但计划的调整绝对需要谨慎，一个天天调整的计划会渐渐失去公信力。重要的是，要确保项目中每个人知道当前的计划是什么，调整计划需要怎样的决策过程，需要谁参与决策。在我们的项目中，与进度计划有关的任何变更，都会提交至项目经理，由对应功能小组成员（该功能模块涉及的策划、设计、开发、测试）及其他相关方共同讨论，明确各方影响，最终做出决策，并公告所有项目组成员。

计划诞生记

计划是“市场需求或高层期望”与“团队生产力”两者之间平衡的结果。

项目的每个过程都需要做计划，计划应该贯穿项目始终，持续细化调整。具体步骤如下所述。

1．项目立项前

这时的计划比较粗略，可将目标按照功能体系分割成几个重大里程碑，并给出里程碑完成的时间点预期。根据项目周期长短，时间可以估算到季度或月。此时的重点要给出立项的时间表，如图1-7所示，何时完成初期调研及评估，何时做好立项准备、启动项目。立项时间表使得项目各资源方有了明确的预期，以便提前做好资源调配。

图1-7　项目立项前时间表

2．项目立项后

各项人力资源逐步就位，根据对团队生产力的经验估计，结合启动过程中对里程碑的大致预期，进一步推导出需求确认、设计确认、功能完成等中间节点，如图1-8所示。

图1-8　项目立项后时间表

3．需求确认后

由设计、开发、测试一起做WBS，将工作细化分解。根据分解后各部分工作量的详细估算，项目各方人员共同讨论，对计划进行细化调整。此时需进一步明确以下时间点：设计确认、功能完成、零缺陷（Zero Bug）、发布前代码冻结（Code Freeze），以及里程碑完结日期，如图1-9所示。

至此，一个里程碑的计划已经基本成型，在接下来的执行过程中，需要不断监控计划的执行情况，识别并应对风险及各种变更，适当调整计划中各时间节点，并确保相关人员及时获知计划变更情况。

图1-9　需求确认后时间表

有时，我们需要对里程碑进一步划分，做更细粒度的计划，参见下面的“怎样做好计划”。

别忘了完成标准

简单来讲，完成标准就是该时间点需要完成的事项列表，或应该达到的某项指标（特定水平的Bug数量／性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。完成标准越早定义，计划按照期望完成的概率就越大。

以里程碑中最关键的几个时间节点为例，完成标准如下：

•　需求／设计确认。执行所需的需求稿／设计稿已经完成（有时，并不一定需要全部完成，可以完成可接受的比例或核心部分完成，具体标准需要准确定义），团队已准备好要编写产品代码。

•　功能完成。所有定义的功能都已经完成（已通过冒烟测试，但允许有质量差距或Bug存在），团队已经准备好将焦点转移到质量保证上，所有剩余问题都将作为Bug来跟踪。

•　里程碑完成。质量已达到适当水平（如不存在高优先级的Bug等），可以上线发布，或可以开始下个里程碑。

克服估算焦虑

做计划就离不开估算，很多人有估算焦虑征，这很正常。我们承认估算是 困难的，所有估算都是一种概率事件。越早做估算，准确度越低。但只有进行粗略估算才能拥有一个起点，以做更好的估算。

大多数人利用直觉的本能反应来进行估算，通常是小团队短周期的项目，这种估算可以起到很好的效果。除直觉之外，有些方法可以帮助我们更好地估算，比如昨日天气法（Yesterday’s Weather），通过分析团队的历史数据，得出生产率的估计。如果是一个新的团队，没有历史数据积累下来，可参考类似条件下的其他团队。

以零缺陷时间点的估算为例，我们就可以参考这个团队在之前的工作中，开发每天平均修多少个Bug，测试每天平均新发现多少个Bug，使用公式“当前有效Bug数＋测试新报速率×X天＝开发修复速率×X天”，通过简单的计算就可得出天数X的值。去除节假日，并根据项目人员的投入情况留出一定的缓冲，零缺陷时间点就算出来了。

估算是一项能力，通过反复练习，估算的准确率能够得到有效提高。

怎样做好计划

首先，好的计划一定是团队共同参与才能制订出来的。

在很多项目中，我们注意到计划往往是某个领导自己拍脑袋就确定了，其他人只有执行的份儿。这样的计划在执行过程中，会面临很大的风险与挑战。计划的本质是承诺，心理学告诉我们，要想让承诺更加有效，它必须得是当事人积极的、公开的、且经过一番努力后自由选择的。计划最终是要整个团队来共同执行的，那么制订计划就必须是项集体活动，参与所带来的责任感能带来持久有效的承诺。千万别低估这一点。虽然共同参与会带来一定的成本，但实践表明，让相关人员公开参与计划的制订过程，对于提高计划的接受度、保障计划的顺利实施有极大的促进作用。

其次，善于规划的人，会把里程碑分割成一个个小的阶段，分而治之。

例如，持续一两个月的功能开发期，一般会拆分成多次迭代来进行管理。那么计划要做到什么粒度呢？这里的原则是，方向越容易改变，变更越频繁，迭代的长度就要越短，反之亦然。每个迭代都需要制订单独的计划及完成标准。 优秀的项目管理，要把握项目的节奏，张弛有道。

最后，好的计划必须跟进。

最怕计划做了就不再看了，那不是计划，而是一张废纸。做了计划就必须跟进！

我们是如何开每日站会的

文／雷蓓蓓

站会对项目的跟进作用不言而喻。那如何开好每日站会？这里面有很多值得我们一起学习的地方。本文主要列出我们在实践中积累的比较实用的经验和方法，供读者参考。

每日站会（Daily Scrum）是大众所熟知的Scrum的代名词之一，作为Scrum中的标志性活动，因为执行不易历来饱受争议。很多有心尝试Scrum的项目试行一段时间后，往往在站会上最先打了退堂鼓，继而产生质疑。

质疑的原因有很多，首当其冲的是抱怨没劲，这种情况下的站会被当作例行公事的汇报会，听不到什么实际内容的讨论，枯燥无味；在另一些团队中，站会又显得冗长而低效，讨论漫无边际，“有这个开会的时间，我活儿早干完了”。

种种声音都在说明，开好每日站会，并不是件容易的事。那为什么Scrum坚持把每日站会作为它最重要的实践之一呢？站会的目的究竟是啥？

每日站会≠汇报会

每日站会绝不是汇报会，而是团队沟通交流的平台，用以分享信息、做出承诺及提出路障（遇到什么困难，需要哪些帮助），解决的是团队协同的问题。

Scrum推崇自组织的理念，提倡团队自我管理，而每日站会就是团队自主进行状态同步、风险管理及制定各项决策的非常重要的实践形式。团队通过站 会来了解整体状态，并对暴露出来的风险和问题做出集体决策。一个组织良好的站会，是出于团队的自组织需要，而不是领导者的监控需求。

为什么需要真实的白板

一开始实践Scrum时，我们选择了JIRA上电子化的敏捷广告牌，它可以根据不同团队的需要定制广告牌上的状态、分类、显示方式等，其功能着实很强大。但一段时间下来，我们发现团队间交互的效果不甚理想，站会上大家面对着电脑自顾自地说，有人看计算机处理自己的事，有人低头玩手机，轮到自己了就对着计算机巴拉巴拉一通。时间久了站会开得更像一个汇报会，形式大于内容，用两个字总结就是“没劲”。

意识到这个问题后，我们及时调整了策略，放弃了看似强大的电子化工具，转向了最原始的白板。说来也神奇，自从团队前面竖起了一面白板，你会发现很多事情自然而然地发生了。我们每天站在白板前，一边跟团队交流，一边在板上移动标记着自己颜色的便笺，碰到新问题，就立马重写一张，然后把自己的颜色标签贴上去。抛弃了冰冷的计算机，大家总算真正面对面了，互动和交流都变得生动和开放起来。

你知道吗？这种真实白板的好处在敏捷社区广受认同，有些专家甚至认为，白板的使用大到可以影响一个组织的文化。

为什么要站着讨论

站着讨论的好处：

（1）站着的时候思维会比较活跃。

（2）站着有点像在做演讲，这种能力平时就应该培养起来。

（3）站着大家容易做手势。

（4）站着防止打瞌睡。

（5）如图1-10所示，大家在空地中站着，彼此之间没有桌子什么的挡着，这样从心理学上会促使人们更加开放，更愿意吐露心声，更愿意讲真话。

图1-10　团队成员正在开每日站会

“三张牌”式站会法

伴随着白板的应用，每日站会上的沟通越来越活跃，大家的话题越来越发散，渐渐地我们的站会开始变得冗长而低效。我们渐渐意识到，把一个站会开好，需要一个主持人来把握会议的节奏。有人来控制节奏是不错，可在我们的团队里，为了强化大家的主人翁意识，每个人都是团队的主人，所以我们的主持人是大家轮换担任的。

那么如何让每个主持人都能把站会开好呢？我们需要一套有效的机制。经过长期的实践摸索，团队逐渐发展出来一套自创的“三张牌”式站会法。

站会开始时，主持人将红、黄、绿三张牌发放至所有与会人员。在整个站会的过程中，任何人都可随时举牌来行使自己的权力。

•　举“黄牌”，进行相关提问，向发言者了解协同及依赖的信息。

•　举“红牌”，用来打断谈话，避免过度的讨论和无结果的时间浪费，提高站会效率，如图1-11所示。

•　“绿牌”则代表着每个人的发言权，将此牌归还给主持人表示陈述完毕。

当所有的“绿牌”都已归到主持人手中，且无更多疑问时，则宣告站会结束。

正是靠着这样简单的游戏规则，一方面帮助主持人找到感觉来把握节奏，另一方面又把会议控制的权力和责任交给了与会的每个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同时又能保持“高效”。

图1-11　红牌与黄牌

确保持续改进

以上是我们在每日站会的实践过程中所积累到的一些策略和方法。想要持续把每日站会开好，在策略之外，你还需要让团队保持持续改进的动力，根据项目各阶段的情况做自适应的调整。

比如站会时间，很多敏捷书籍上都推荐把站会作为一天的开始。经过反复尝试和适应，团队决定把站会的时间放在午饭前的11:30开始，一方面大家可以有相对完整不被打扰的一整个上午的工作时间，另外，吃饭的动力会让大家加速起来，保障站会的高效，如果有某些争议性的话题还可以转到午饭时继续讨论。

我的站会感悟

文／靳霄

站会起作用有其内在的原理，了解这些深层次的内容便于你更好地使用这个工具。

在敏捷的Scrum框架里，有个活动叫站会。对于站会的好坏，项目经理们有 不同的意见。我在不同的项目中实施了站会后，对站会背后的原理有了一些感悟。

感悟1　一种仪式

我们的站会一般放在早上上班一到公司就举行，这个对团队来说有一种仪式感。

其实“仪式感”是一个很宽泛的词，并不只是“冠婚葬祭”这些大礼，还有许许多多的小礼。举个生活上的例子，不知道大家有没有在投飞镖的时候试过闭眼、深呼吸，再睁开眼，然后发现几米之外的靶子看得更清楚了？你的身体、你的眼睛并没有因此产生变化，是因为在这个小小的仪式中，自我暗示让自己的注意力更集中，感官对周围环境的变化更加敏锐，所以感觉自己看得更清了。仪式感，暗示你必须要认真地去对待这件事。

同样，早上的项目组站会，通过固定的时间，项目组人员站在一起同步项目的情况，会像一种仪式一样，给大家一种心理的暗示，暗示自己要更加专注、认真地对待自己手头的工作。让团队快速地进入工作状态，帮助团队调节情绪，从放松的家庭环境过渡到专注的工作环境。

感悟2　核心习惯

站会是帮助团队成长的一种核心习惯。

习惯是行为的自动驾驶系统，如果能让团队耳濡目染，久而久之形成好的习惯，可以加速完成任务。那什么叫核心习惯？当我们想建立团队的习惯时，我们需要建立一些核心习惯，这些核心习惯是可以启动团队良性循环、逐步驱动团队重塑好的行为模式的。什么意思呢？例如，2009年，美国一组研究人员发表了一个关于新的减肥方法的研究。他们召集了1 600位有肥胖问题的人，让他们每周至少一天记录一下自己吃的所有东西。慢慢地他们养成这个习惯后，意外的事情发生了，他们自己通过这些记录，发现了自己没有注意到的行为模式。有些人发现自己总在上午10点吃零食，那他们就在自己桌上放一个苹果和香蕉作为这个时间的小点心。有些人根据这些记录制定了新的健康餐，而不是冰箱里的垃圾食品。而这些都不是研究人员让他们做的，记录饮食的核心习惯创造了一个架构，让其他习惯得以形成。研究进行了6个月，做饮食记 录的人比其他人减掉的体重多一倍。

那为什么说站会是团队的核心习惯呢？在站会进行的过程中，我们会固定地同步任务的状态是否按计划进行、当前有什么风险和问题、确认需求变更。久而久之，站会这个框架，帮助团队提升了时间管理的习惯，提高了风险管理的意识，加强了需求变更管理的习惯，驱动着团队逐步完善。

感悟3　高效的会议模式

站会对于项目组来说是一种高效的会议模式。

冗长的会议一直是各个团队抵制和抱怨的。然而项目是一个多人进行的事情，必然需要多人在一起碰头确认内容，清晰有效的沟通绝对是成功的关键。IM通信工具、邮件在这方面都有不足，必须是项目同步会这种方式。相比于冗长的座谈会，15分钟的项目站会是一种高效的模式。

1991年，美国陆军中将威廉·帕戈尼斯主管海湾战争的军队后勤工作。帕戈尼斯负责将55万名士兵运送到半个地球以外的主战场，需要押运部队的全部装备。他的团队一共安排了1.22亿份餐点，输送了59亿升的燃料，寄送了3.2万吨邮件。这些项目，涉及那么多人员，帕戈尼斯到底是如何高效地进行项目同步的呢？帕戈尼斯会在每天早上8点准时召开会议，8点半散会。他的会议有两个关键点：第一，每个职能部门至少一名代表参会，以此保证组织中的信息交流通畅开放。第二，他要求每个人全程站立开会。

帕戈尼斯的这个会议就是站会的一种形式。这种会高效的原因，一个原因是，固定安排时间，减少召集会议所花费的时间，避免了和每个与会者确认时间并达成一致的时间花费，另外，早上是凑齐相应人员一起开会最容易的时段，特别是涉及并行任务比较多的关键角色，这些人在其他时段经常会有各种时间冲突。另一个原因是，由于是站着开会，一旦有人跑题或者长篇大论，与会上的其他人员就会出现明显的肢体动作，于是话题更容易重回重点。

以上这些是我在实施站会后，感受到的站会背后的原理。只有掌握了这些背后的原理，才能更好地让站会发挥效果，并让它作为一种工具可以独立于Scrum之外进行使用。

白板的艺术

文／何燕华

白板上除了任务状态、燃尽图，还可以添加项目目标、信心指数、上线倒计时等模块，帮助团队统一方向，聚焦核心工作，发现潜在问题，集中力量解决问题。

白板上的便笺纸也可以有不同的设计，通过颜色和形状变化来标识不同的任务类型，以获得更好的互动效果。

说到白板，大家可能都有所耳闻，很多时候白板是用来配合站会的。其实白板也可以有两种选择：电子白板和物理白板。我们当时对比了JIRA中的电子白板和普通的物理白板的效果，最终选择了物理白板。原因有以下几点：

（1）物理白板可任意定制。可以添加／删除栏，添加各种新的标识，写下迭代目标、发布标准，贴上燃尽图（后面将做具体介绍）、贴上进度计划等。这种改变在白板上实施，所有人都能在一分钟内迅速学会，这一点应该是其他电子广告牌所无法做到的。

（2）物理白板需要团队的协作。由于我们没有可触摸的电子屏，所以电子广告牌大家只是用投影仪投在墙上，往往由主持人在上面做一些操作，这样缺少互动。而物理白板允许每个人从墙上拿下便笺，挪动位置，甚至在上面写下一些文字。它使会议形式更加有趣生动，团队的互动也会更好。

首先说明一下，我们的项目是一个后端和运维扮演很重要角色的项目，这会影响我们在白板上各栏目的设置。那么我们是如何设计白板的呢？

白板概览

我们将白板分为5行4列，5行代表5种任务：运维上线相关任务（日常 更新、线上缺陷）、开发（普通开发任务，含前端、测试等）、测试（独立的测试任务，如测试用例完善、测试代码完善等）、前端（独立的前端任务，如页面优化）、分享（内部技术分享等）。4列分别为：还未开始的任务（Open），进行中的任务（In progress），开发完成待验证的任务（Resolved），验证完毕的任务（Closed），如图1-12所示。

图1-12　白板概览

纸条颜色的讲究

图1-12白板中的纸条花花绿绿，你可能会疑惑为什么用不同颜色的纸条呢？下面我就来解释一下。

上面提到的5种任务中：

（1）运维上线相关的任务会用红色方形纸条，尤其是线上Bug。因为线上相关的问题都是优先级最高、大家最关注的事情，所以用红色醒目地标识出来。图1-13就是一个线上Bug。

（2）一般的开发任务、独立的测试和前端任务、分享都以淡黄色方形纸条标记。其中开发任务如果需要相应的前端任务配合，则在该纸条上方贴上一长 方形蓝色纸条标记；如果有对应的测试任务，则在纸条下方贴上红色的长方形纸条。图1-14所示是一个既有前端又有测试工作的任务。

（3）有设计文档、API文档测试用例的任务，会分别用绿色笑脸、黄色笑脸、红色笑脸来标识。原因是团队正在做这方面的改进。设计文档和测试用例强调回顾（review），曾经因为这方面做得不到位，出现过一些线上问题。而API文档是开发提供给测试人员用于设计的用例，这个涉及成员间的沟通和互助，所以也重点标识。此处大家也不难发现白板的便捷之处，就如本文开头所讲的，在应对一些非常规的规则时它非常灵活方便。当大家对设计文档、API文档、测试用例的规则牢记于心的时候，我们就会去掉这些笑脸用于其他的跟进。图1-15是我们在白板上对笑脸的说明，图1-14是一个既有API文档更新又有方案设计工作的任务。

（4）新增任务、迭代计划外加入的任务会用蓝色纸条跟进。迭代总结时会对新增任务的工作量进行统计，用以指导后续的计划。图1-16就是一个新增任务。

图1-13　线上Bug

图1-14　具体任务

图1-15　对笑脸的说明

图1-16　新增任务

纸条内容的组成

纸条内容由以下几部分组成：

（1）任务概要：简要描述任务内容。

（2）估算工作量：以人天为单位。

（3）负责人：姓名拼音首字母。

（4）实际工作量：当任务完成后由相应开发人员回忆实际的工作量，数字外围画个圈，以区别于估算工作量。在做迭代总结的时候，实际工作量和估算工作量的偏差，可以说明我们的计划是否做得合理。

白板上就只放这些小纸条吗？只是用来跟进各任务的进度吗？在我们的实践中，根据项目所处的阶段，我们会有选择地增加一些内容，如燃尽图、倒计时和目标、信心指数、计划等。

燃尽图

燃尽图可以帮助我们直观地了解项目进度的风险。

燃尽图往往用来呈现实际情况与理想情况的偏差，可以提示我们风险的存在。比如燃尽图一直很平坦，下降的趋势不明显，这样团队就需要回过头看一下哪里出现了问题。是测试吗？如果是，开发能不能帮忙协助一下。是外部依赖吗？如果是，项目经理能不能出面协调。是技术难点吗？如果是，技术领导能不能出面寻求技术专家指导等。燃尽图就是以这种方式帮助团队发现问题的。不过从我们的实践来看，这里有一个陷阱，那就是，在迭代初期（前1/3，甚至前1/2），燃尽图会处于比较平坦的状态，但是不一定真的是风险很大，因为前期，团队正在做着一些准备工作，很少去关掉任务，等到这些工作全部到位后，后面关闭任务的速度会大大加快。针对这个问题，我们团队也正在探索更合适的方式来展现。图1-17是我们上个迭代的燃尽图。

图1-17　燃尽图

目标

在白板上放置目标能帮助团队往同一个方向努力。

在很多组织中，管理人员都以为项目成员清楚他们的目标。可事实却表明，在被问到目标是什么时，每个人都会有自己不同的答案。在过去很长一段时间里，我们的团队成员只是被分配到一个个任务，每个人只负责完成这些任务，却不知道这些任务孰轻孰重以及它们的来龙去脉。有的时候自己在完成某个任务时遇到困难，会花大把的时间去解决，而不是先看看这个任务是不是影响我们的目标达成，或者等负责人来拍板是不是要继续这个任务。团队更多的只是在完成任务，对产品的全局没有清晰的认识。现在我们会有一个中长期的目标计划和每个迭代的目标，让大家看到自己所做事情在全局中处于什么样的位置，看到团队未来的方向在哪里。当被某个任务阻塞的时候，大家可以根据目标来自己判断是不是影响该目标的达成，如果不，那么这个任务可以稍缓；如果是，那么就要赶紧提出风险，大家一起来想办法解决。而这样的目标，我们通常会放在白板上，让大家看得见摸得着，并且在迭代总结会的时候来回顾是 否完成了这个目标。例如上一个迭代的目标为：发布至联调环境。那么开发人员自己也会判断，我自己的几个任务哪个比较重要，即那些阻碍发布至联调环境的任务。虽然定目标的时候有时候会比较困难，但明确的目标有助于项目所有人员保持同步，明白对于下一个迭代而言什么最重要。

信心指数

白板上的信心指数显示了目前团队对于成功的交付所持有的信心，这一指数往往能帮助团队发现一些潜在的问题，及时地进行调整。

在确保了大家对目标的认知是一致的之后，就可以做一些检查。比如在站会的时候，每个人对完成目标的可能性来投票。每个人写下一个数字：5=绝对能，4=有可能，3=有点悬，2=不太可能，1=拉倒吧。只要投票结果中有2和1的话，可能就提示我们需要重新评估目标，并讨论需要做什么改变来提升信心。常用的方法有：消除障碍，帮助解决瓶颈问题，缩小范围，调整目标，更加努力地工作。信心值低的同志会得到来自项目团队其他同志的协助。团队中曾有这样的情况，其他成员给的是4，而有一位成员给的是2。我们会问这位成员是什么原因导致他信心值不够，他告诉我们，接下来他要做的工作不是他擅长的，现在还不知道怎么开展。于是技术领导就指派了另一位比较资深的成员来协助他完成这部分工作。试想，如果没有这个过程，有可能到最后这位成员才会说完不成这部分工作。

倒计时

在白板醒目的位置，以红色字体标识出来，是为了提醒我们离终点还有多少时间，必要的时候通过时间和剩余工作量的对比来发现问题。例如倒计时已经是10天了，而某个开发的剩余工作量是11人天，很明显这里应该是有一些问题了。这就使大家的视线聚焦于这一点，集中力量来解决这里的问题。

对于白板上放什么内容，团队可以根据自身的条件和项目所处的环境进行选择。我上面提到的这些点也不必全部放上去。例如，信心指数，我们往往会在项目临近发布时用来提示有可能存在的问题。如果项目中不存在文档回顾的 问题就不需要有用于标记设计文档，测试用例和API文档的笑脸。当然除了我说的这些，还可以加入更多的内容，如日历、每个人的剩余工作量、阻碍我们的问题列表，这些都是要根据团队和项目的需要进行调整的，我们团队正在考虑用一种标记来标识需要上线的任务。

关于白板我们必须明白

（1）对于物理白板，在迭代结束后，纸条就会都被揭下来，贴上新的纸条，这样就没有历史记录了。对于一些长期的项目，也许还需要回去查历史数据，就可能还需要在电子白板上留一份数据。我们团队当前的情况就是这样，物理白板用来沟通问题、同步进度，而电子白板用来留档。团队可以根据自己的情况来决定如何使用物理白板和电子白板。

（2）对于办公区域不在一个楼层甚至不在同一个地区的团队，物理白板可能就不合适了。

（3）白板虽然可以定制各种内容，但是建议不要一次增加太多规则，最好一次增加一种规则，等到这种规则成为大家的工作习惯后，再退出，让位给新的规则。

（4）不要增加太复杂的规则。太复杂的规则需要一些学习成本，而且实践也证明，太复杂的规则往往不容易被遵循。

（5）项目类型的不同也会影响对白板的设计，如本文没有提到策划、交互、视觉等角色的工作在白板上的体现，是因为本文描述的项目中这些角色都是与其他项目组共用的，我们会直接把他们当作项目的输入，没有监控前期的状态。当然如果你们的项目中这些角色参与度较高，也可以将他们的工作纳入白板中。

白板是一种强大的工具，如何使用白板不是一篇文章能够说清道明的，本文提到的只是它在笔者所在团队的应用，希望能给大家一些借鉴。所有团队都可以根据情况定制属于自己的白板。

不简单的周会周报

文／曹智清

周会周报是我们项目管理沟通中非常重要的两个环节。本文从周会的分类、开好周会的要点以及做好周报的细节点等方面进行剖析，给大家提供一些思路，希望读者通过做好这两个环节来一窥项目全貌。

周会周报，看似众所周知，但当PMO把这一话题列入讨论候选列表时，居然获得了大部分项目经理的积极投票，看起来这里头似乎有不简单的困惑。

周会

先来说说周会。通过调查，目前项目经理们所处的项目中，毫无例外地拥有各自的周会，但开法略有不同，主要分为三类：

（1）全体类：项目全体人员共同参与，这根据项目大小的不同又有差异。技术研发类项目，本身以研发人员为主体，周会以所有人员的状态和项目信息同步为主；也会有部分产品类项目，虽然角色和人数众多，但依然会有全体参与的周会。时间控制在半小时内，以产品和团队的动向同步为主。

（2）组长类：这也是目前占比最高的周会形式，更多地存在于产品类项目中。各组同步状态，同时了解产品最新情况以及讨论重要的产品事宜。

（3）三方类：主要是产品、运营、市场三方周会，也存在于产品类项目中。因为这三方是产品动向的主要来源，且日常沟通合作中需要协调配合的事项很多，所以也需要定期讨论决策。

当然，这里没有包括各个职能团队自己的周会，那些主要属于团队管理性质。

那如何来开好这看似简单的周会？

首先，要想清楚为什么开周会。要同步状态、汇总各团队信息吗？如果仅仅如此，每个团队罗列自己的事项，互发邮件是不是就行了？显然不够。我们需要通过周会来：

（1）面对面地感受项目当前的整体状态、重要问题、接下去的目标以及所需的调整。

（2）借此来对项目当前重要问题有一致的认识，进行小幅度的讨论，并形成下一步工作事项。

这里有一些开好周会的要点：

（1）控制规模和时间。人数为10～15人，时长不超过1.5小时。更大的规模和更长的时长，一方面是资源的极大浪费，另一方面会造成讨论无法有效展开。一个包括了20人的超过2小时的周会，效率非常低下。

（2）要不要轮流汇报？事无巨细的罗列，既乏味又无效。大部分项目整体情况可以通过项目经理事先的收集来直接做整体概述，对于部分方向性或者商务性小组，可以简单汇报主要工作和主要问题。一旦会议陷入轮流发言的局面，你会发现不发言的与会者很快就会掏出手机开刷。

（3）如何识别周会该讨论什么？先说哪些不该在周会讨论：急事不适合周会讨论，要第一时间当下拍板！非跨团队的问题不适合周会讨论！纯执行细节问题不适合周会讨论！大方向决策问题不适合周会讨论！……这样我们就更容易得出哪些适合周会讨论了。那些跨团队的、涉及整体计划性或者协同配合型的问题、或者中期改进型问题，适合放在周会上。项目经理一方面可以在收集整体状态的过程中识别此类问题，另一方面也需在周会过程中随机应变发起对“火花”型问题点的快速讨论。这样的讨论，不需要在周会时明确所有的细节，但大家要有共识，并有行动方向、落实人员。

（4）确定状态同步的维度。大部分情况下，不需要完全按照职能团队来同步，目的不是汇报贡献，而应该按照产品内子项目线的维度来跟进进展，挖掘问题。当然，整体研发情况是一个必有的维度。

（5）控制说话比例。如果一个周会从头到尾是项目经理或者主管在唱独角戏，那就应该反省一下周会的形式和内容了。合适的比例是1:1:1。第一个1指的是会议主持人，往往是项目经理或主管，向大家更新整体状态，并且主 持整个讨论；第二个1指的是部分需要汇报的与会者发言；第三个1更为重要，是所有与会者参与讨论发言。达到了这样的比例，容易让参会者从信息获取度、决策参与度和专注度上都保持较高的水平。

（6）固定时间地点。周会的时间地点需要尽可能固定，这样会让大家有预期性和节奏感，也能够提高到会率和准时率。为此，会议主持人需要付出不少努力，包括预定会议室、应对突发事件、完善会议规则和通知等。

（7）如果我们已经有每日站会了呢？这个问题更多地来自技术研发型项目（产品类项目通常有必须高频率同步的业务需求），研发日常已经每日同步了，那自然不需要再依靠周会来同步状态。这种情况下，视项目变动情况、团队管理的需求，变周会为主要针对项目概况和团队管理的会议，开会频率降低，时间上也可以作进一步压缩。如无此需求，也可以省略周会。

周报

很惊讶我居然写了那么多关于周会的事儿，原来真的不那么简单……那么，周报呢？

通过统计，发现并不是每个项目经理都在写周报，有两类原因：一是项目本身复杂到项目经理没有能力描绘清楚整个项目各处的完整情况；二是周报约等于周会纪要了，因此省略。

衡量周报有效性的判断标准就是，有多少人真的会打开周报来看？又有多少人会认真看周报里的信息？

当然，要警惕周报万能论。不能依靠周报来沟通具体的待办事项，谁干什么，还是要面对面沟通到位，周报上呈现的更多的是让团队“透明”地了解信息，而不带来任何意料之外的惊讶。

那么写好周报又有些什么细节呢？总结起来是“三要，三不要”。

1．三要

（1）周报要包括什么？要包括整体进展、整体风险、各子线状态、各子线风险。周报应该让大家清楚重要的进展、目标达成情况、风险状态以及应对措施。总之，看完周报，大家应该对项目现状有清晰的整体认知。

（2）要进行换位思考。要多从报告接收者的角度进行思考和准备相关材料，有条件的话提前沟通确认内容和形式。别假设看报告的人跟你有一样的理解背景和上下文在心中，要给出连贯的表达说明。

（3）要有提炼自数据的关键信息。需要提供相应的信息而不仅仅是数据，信息和结论来源于数据分析，通过数据分析出相应的有价值的信息是每位项目经理、其他管理人员的核心竞争力之一，数据可能是客观存在、无序而杂乱的，而信息是用来衡量现状和指引我们下一步行动的基础。产品数据一定是敏感数据，并不适合实时向所有人公开，因此，并不需要在周报里列清所有数据，要把控好周报的分发范围。

2．三不要

（1）篇幅不要过长，控制写周报的时间和复杂度，适当图形化。对于进展和问题，都只写要点，不要事无巨细都写。周报不是为了表现工作量，更不是为了刷存在感，只说重点就够了。没有人愿意花10分钟以上时间来读一份周报，因此我们应该提高信息表达效率，适当将信息图形化，提高周报的阅读效率。一份周报的准备时间应该控制在1～2小时。如果你的周会纪要本身和周报有不小的重合，那也确实可以考虑两者合二为一。

（2）不要有令人惊讶的内容。状态报告仅仅是工作的状态总结呈现，更多的沟通工作和问题处理应该在汇报之外处理。发现问题，要及时分析和解决，而不是等待报告项目状态的时间来临再寻求帮助。

（3）不要直接拷贝粘贴你下属的报告。想想我们存在的价值就知道这其中的含义了。

每每写完一些细节，我们都需要抬起头来思考一下这些细节背后的意义。我们并不是为了汇报而来讨论周会和周报，恰恰因为这两个环节是非常重要的沟通平台架设的一部分，它们既可以给团队提供基本的“透明信息”，又可以有效推动重要问题的思考和讨论，让大家避免一头扎在细节工作中，而忘了抽身审视自己，影响持续改进。

让你的报告会说话—— 如何有效、有料地进行工作汇报

文／陈海春

掌握良好的汇报工具和方法能够让你在职场中更胜一筹。好的报告不仅是好的色彩搭配和炫酷的字体组合，而是针对不同受众整理出恰当内容并运用适当的图表以简洁的方式传递信息。本文对不同报告（日报、周报、月报）的内容格式进行详细说明和举例，希望你不再把写报告当作工作中的累赘。

人们常说流程、邮件、会议是职场人士讨厌的三件事情，大家可以审视一下，看看有多少邮件、多少会议是与项目汇报、工作汇报（含个人工作汇报）有关的？特别是部门主管、项目经理们的邮箱是否不断地在经受这类邮件的狂轰滥炸。笔者通过对工作的观察和总结，发现有些方法和步骤能够把这些干巴巴的汇报、记流水账式的汇报变得更有意义，也能提供更加丰富的信息给听众，从另一方面讲也许可以减少一定的时间浪费。

写报告经常遇到的一些问题

也许我们在写个人工作汇报或者书写项目汇报时经常会遇到以下问题，笔者以前就亲历过这些问题，同时也发现身边的一些同事正在经历这些问题，但往往是“当局者迷”，如果没有其他人指引和提醒，我们自己很难发现这些问题应该是我们值得注意和改善的地方。这些问题是：

（1）这一周（或者这一段时间）做了什么呢？好像这周／这段时间没什么可写的？

（2）啊，就这点干巴巴的内容？

（3）项目状态到底该如何评价？风险可控吗？

工作汇报的目的

工作汇报是将个人工作状态、项目进展状态与其他相关人员进行沟通的一个正式渠道。我们为何在不同公司、不同小组都需要写状态汇报、做工作汇报呢？除了将目前的现状知会相关人员外是否还有其他功效呢？笔者认为一份好的状态汇报至少可以达到以下三个目的：

（1）将状态、问题、风险知会相关干系人，这是任何状态汇报都需要满足的最起码要求。至于什么样的信息需要让谁知道，需要大家在做状态汇报前与各相关人员达成一致，以避免辛辛苦苦写出来的东西不是其他人所需要的。建议可以通过类似小迭代、不断改进的过程来探知和摸索出适合相关人员的状态汇报，例如可以先按照自己的理解书写第一版状态汇报，然后在会议上或者邮件中询问大家是否还需要补充或调整相关内容，如果有的话就在下次的汇报中进行调整。

这其中也需要考虑以何种方式、频率发送状态汇报。一般来讲，一周一次的状态汇报就够了，但是对于处于紧急状况下的项目或者公司领导重点关注的项目就需要区别对待了。

（2）寻求帮助。工作中遇到问题并不可怕，最可怕的是在问题初期不去积极主动地寻求帮助，而到了“火烧眉毛”时，即使有上级领导介入也需要花费数倍的成本来解决，有时甚至一不小心把自己的职业前程给搭进去了。

这里只是说状态汇报是一个非常好的寻求大家帮助的机会，而并不是说所有的问题需要积聚到进行状态汇报时才披露出来进行处理。在工作中平时可以及时地就遇到的问题进行沟通，同时在状态汇报时再次正式提出来，也许这样会得到相关人员的更加关注和重视。

（3）自我审视。古人云：“吾日三省吾身。”作为现代人的我们平时大家都忙于推进各项工作或被各项工作任务推着前进，是否有时间停下来审视一下自己？状态汇报的书写过程就是我们的自我审视过程，也许无法做到“吾日三省”，那么也至少需要“一周一省”吧。在时间管理的相关培训中提到的相关点令我印象深刻：时间管理就是目标管理，在个人的时间瓶中是否先放入大石块，而后是小石子、沙子，最后是水？在这样的每周一次的自我审视过程中也 许我们不需要把全部内容都写入汇报中，但至少对我们自己而言是一次难得的自我交流的机会。

个人工作周报

个人工作周报应该是大家最常用的一种工作汇报手段，但有多少周报是应付式的周报呢？也许我们对表1-1所示的那种典型的流水账式的周报似曾相识，看这些周报的主管们即使没有这样的周报也能知道他们的工作状况。仔细看看这样的周报我们就可以发现，它们的共同点就是仅仅记录了过去做过什么。

表1-1　××的个人工作周报

××的个人工作周报

本周工作：
1．完成任务114#，新版上线统计方案

2．产品推荐性能优化，减少对推荐模板加载时间

3．参加项目总结会议

××的个人工作周报

本周工作：

和后台进行联调、修补漏洞

如果能借助一些简单的任务管理工具的话，这样的流水账很容易得到，这样的个人周报是没有什么附加值的。

表1-2是笔者推荐的一种个人工作周报内容与格式。

表1-2　个人周报内容与格式

内　容

说　明

本周工作完成程度

做了什么、完成结果如何

下周工作计划

需要做什么、时间点、完成的定义

工作中遇到的问题及建议

对部门、项目、小组中存在的问题进行的思考

个人感言、建议、分享

个人工作中的总结分享，让上司知道你在想什么

•　本周工作完成程度。 不仅需要描述做了什么，还要知道它的结果如何，例如是否已经上线、客户的投诉率是否已经下降等。

•　下周工作计划。 除了描述要做的事项外，还需要对主要的任务的预期结果进行说明，也就是我们在敏捷领域经常听到的Definition of Done，即 需要对“完成”有一致的理解。

•　工作中遇到的问题及建议。 发现部门、团队、项目中的一些问题及其对应的相关建议，例如持续集成的使用、代码评审的更好实践等。

•　个人感言。 团队管理、合作，个人发展等方面的感想可以写出来与上司、同事进行分享，不要把与上司的沟通仅局限于每个季度一次的考评沟通会议。

团队工作周报

身为团队领导，需要发出本工作团队的周报给上级领导、相关部门，与前述个人工作周报不同的是团队周报更应该聚焦在结果和计划上，而非个人微观层面的事件总结。计划的时间跨度根据团队规模大小不同可以从1个月到3个月不等，如表1-3所示。

表1-3　给上级领导的周报

内　容

说　明

上周已达成的结果（跟计划相比如果有差距，则列出如何改进）

量化的结果指标，如销售额、用户数等数据

未来一段时间的规划图

通过图形化的方式言简意赅地列出任务的时间点和期望达到的结果

达成如上规划图的风险／需要的协助

资源风险、合作方风险及建议的应对方案

项目状态报告

在日常项目或者执行中经常需要这样三类汇报：项目日报、项目周报和项目月报，一般周报是最常用的一种项目状态汇报形式。

1．项目日报

项目日报适用于项目中紧急情况下的某个问题／项目报告，如重点项目、线上问题、重大客户投诉问题等。在处理问题的过程中发日报是为了让更多项目干系人了解情况，寻求他们的帮助。

一个典型的项目日报格式如表1-4所示。

表1-4　项目日报

内　容

说　明

邮件标题

【重要紧急】××线上问题日报，2015-12-21

问题简单描述

时间、地点、发生了什么

处理进展

概况描述尝试的方法及结果

下一步工作计划

需要的帮助

计划解决日期

根据目前的进展预期的问题解决时间

2．项目周报

适用于常规项目状态报告，默认情况下选择周报的形式和频率，一般需要包含项目的主要度量指标等信息（进度状态、问题、风险、质量指标等）。

一个典型的项目周报如图1-18所示。

对于繁忙的领导们而言，看到项目天气就可以基本了解项目目前的总体状态，其中项目天气的各种天气情况定义如图1-19所示。

3．项目集周报

单个项目周报的格式和内容主要运用于对单个项目的汇报和沟通，如果是同一项目经理负责范围内的多个项目，为了方便报告接收者阅读和对比所有相关项目信息，建议以一个总体表格的形式进行汇报。表1-5是一个项目集周报的内容和形式的例子。

4．项目月报

适用于向高层领导、客户报告项目状态，高层次、概括性地介绍项目相关信息。一般而言，参与月度汇报、阅读月报的受众为公司、部门的领导，他们平时都非常忙碌，因此报告需要覆盖他们感兴趣的领域，重要的是会议前需要与相关的会议参与者对会议内容达成一致性。

项目概况

项目状况：

•总体进度

°目前P0级别bug都已经修改并在测试服务器上回归通过，12/15进行上线评估；

°……

项目细节

•　开发测试

°Done

°Ongoing，部署所有bug-fix到测试环境。

°Coming，12/6进行代码merge到主线版本，12/7—12/10进行回归测试。

•交互设计

目前开发进度安排如下：

图1-18　项目概况＋项目细节

图1-19　项目天气图标说明

表1-5　项目集周报（示例）

图1-20是一个典型的月度项目汇报包含的内容，其中左边的总体状态中包含费用预算消耗情况、项目质量、产品发布截止时间、项目移交进展情况、需求变更情况、风险状态、IT设备等主要内容。用绿色表示该项的目前状态正 常，黄色表示有些风险需要关注，红色表示需要重点关注和决定的事项。每一栏状态右边的感叹号图标是一个超链接，可链接到更详细的具体页面中。

图1-20　月度项目汇报（示例）

项目管理≠烦琐的会议

文／靳霄　陈海春　刘煦萍

项目管理的流程会给团队带来一些会议，这些会议的目的是解决问题、做出决策、建立起彼此之间的信任。把握好会议管理的技巧，会让整个团队更加高效。

当我们在开展项目管理的过程中，会遇到大大小小各种会议，一些是别人要求我们参加的，一些是我们组织的，对于项目负责人或项目的关键人员，有 时候一天会议的时间就能占到1/2的工作时间。对于开会，大家期望的标准是什么呢？一般来说是没有人愿意参加一个非常冗长的会议。

那为什么我们要花费这么多时间来开会呢？因为开会可以把大家聚到一起，无论是团队还是特别小组，无论是部门成员还是谈判者都围坐在桌子周围。会议意味着要解决问题、做出决策、建立起彼此之间的信任。

会议导致团队效率降低

对于项目会议时间的花费，我的一个同事海春，在给公司的一些负责人培训项目管理课程时，还被问到了这样一个问题。一个负责人发现自从旁边一个项目组引入项目管理后，同一层的会议室预订变得多了起来。他的疑问是一旦引入了项目管理之后，是不是会导致会议繁多，效率低下？

为了说明这个问题，我们专门整理了所在的其中一个部门的与项目相关的会议数据供大家参考和评说。

这个业务部门的项目周期一般来说从项目启动到项目上线大约持续1～3个月不等，很少有超过3个月的，项目主要会议见表1-6所示。

表1-6　项目主要会议

会议名称

会议时长

参与人员

会议目的和内容

启动会

≤30分钟

项目组全体同事

让大家认同项目背景，了解为什么要做这个项目及目标是什么

项目站会

≤15分钟

正在执行项目任务的同事

根据项目特征每天、每周一次，或者每周两次进行项目进度状态、问题同步

需求评审会

≤60分钟

项目组全体同事

从不同方面对需求点进行讨论和确认

视觉评审会

≤60分钟

项目组全体同事

从不同方面对视觉稿进行讨论和确认

上线评审会

≤60分钟

项目组全体同事

讨论是否已达到上线标准、推广运营是否准备就绪。上线时每周例行的维护任务可通过邮件审批而非面对面的评审会形式

项目回顾会

≤60分钟

项目组全体同事

庆祝项目上线，对项目过程进行总结和对需要提高的方面讨论改进措施

以一个平均每周两次站会、项目周期为2个月的项目为例，其会议花费时间为8.5小时，会议负荷度为2.65%，即使再加上会议前后的准备时间，基本上会议负荷度不会超过5%（会议负荷度＝所有会议时间÷理论工作时间，即8.5小时/（40工作日×8小时）=2.65%）。

试想一下，如果在某个项目中没有任何这些会议，那么我们项目的效率将会提升5%吗？答案应该是“不一定”，因为没有这些面对面的沟通会议，项目团队可能会是另一场景：项目POPO群会不断弹出消息，策划需求同事疲于回答各种问题，进度沟通均是简单的“OK”回复，如果同时有3个人在POPO中同时输入，则上下文理解就变得愈加困难了……POPO新消息的闪动也会打断大家的工作思路。相信大家都有过类似这样的经历：看到POPO的新消息提示后好奇地点开查看，发现和自己没有什么关系。笔者统计了一个20人规模的项目POPO群记录（这个项目每日站会同步项目状态），发现基本上每天的聊天记录在30条左右，大多为站会上的跟踪事项的结果通知。

在会议室里召开面对面会议的另一个显著的好处就是可以通过在白板上写和画，来表达清楚大家的想法和意见。

那既然这些会议的时间成本不高（<5%），也有这么多显而易见的好处，为何还是有很多同事一提起开会就唯恐躲闪不及呢？为何还有这么多以睡觉来抗议会议的大佬们呢？据笔者观察，在笔者所在的公司基本上没有以睡觉来抗议会议的，而是以低头玩手机来抗议会议。

问题的关键是：错误的会议安排会导致团队效率的降低和团队的抵触。我们要做的是尽最大努力来使会议开得更有成效、更有价值、更有收获，甚至让大家更有兴趣。

为什么要开会

在开会之前，首先你要想清楚你想在会上达到什么目标、解决什么问题。

然后，你要弄清楚需要得到哪些人的帮助。一旦你确定了“达到什么目标”、“解决什么问题”和“需要得到哪些人的帮助”之后，其余问题（什么时间、在哪里开会）就显得相对容易多了。

例如，团队有开周例会的习惯。有的团队在周一早晨开例会来明确这一周需要做的事情，而有的团队则选择在周五开例会来回顾全队这一周的工作进展情况和所出现的问题。有些团队则有每日的站会，10～15分钟，用来及时暴露问题和解决问题。

一般情况下，开会需要有充分的理由，比如当你：

（1）需要团队就某一个问题提出他们的想法和建议时。

（2）需要团队参与决策或解决问题时。

（3）需要团队来解决一个仅通过一对一的交流方式无法解决的问题时。

（4）需要和整个团队一起共享信息、分享成功或排忧解难时，或是想要每个团队成员都意识到这是一个特殊时刻时。

（5）需要来自不同团队的那些有着各不相同的观点的团队成员集思广益来解决一个问题时。

（6）需要明确由谁来对所出现的问题、所造成的麻烦或者所涉及的领域负责时。

（7）发现团队成员觉得非常有必要开会时。

但当下列情况出现时，就没有必要开会：

（1）要讨论的是私人问题，比较适合采用一对一的方式解决。

（2）你没有足够的时间去准备会议。

（3）其他的沟通方式能收到与会议相同的效果，或者比会议更好的效果，如通过E-mail、POPO群讨论，或者打电话的方式等。

（4）会议的议题不值得浪费所有与会者的时间。

（5）团队之间的关系一团糟，还不能通过会议达成一致、做出决策时。

应该邀请谁

那具体谁应该参加会议？应该邀请那些真正有必要出席会议的人，即那些能够帮助你实现会议目标并能为会议的议题提供各种观点的人，他们是：

（1）对于所要讨论的问题有关键决策权的人。

（2）对于所要讨论的问题有相关知识和信息的人。

（3）一心一意要解决问题的人和与所要解决的问题休戚相关并有重要作用的人。

（4）有必要知道你所要传达的信息并有利于他们进一步开展工作的人。

（5）需要执行决策的人。

如何制定会议议程表

因为你参与了会议筹备的全过程，所以你要运用你所获得的信息来制定议程表。优先要考虑的是会议的目的，其次是与会者。

议程表一般应该包含以下几个方面的内容：

（1）明确的会议目的。

（2）会议欲实现的目标或产生的结果。

（3）给哪个小组开会或者与会者都有谁。

（4）开会的日期、时间和地点。

（5）会议将持续多长时间。

（6）会议是由谁组织召开的。

（7）每个与会者在这个会议中分别承担什么任务。

（8）会议所要讨论的每个议题（每个议题都要具体制定负责人，而且要规定讨论的时间）。

（9）筹备阶段所需的背景资料。

对一些特殊的会议，你也可以根据具体情况来调整会议议程表内容。

好的会议议程表能够帮助与会者随时了解会议的相关情况，比如为什么开会，开什么会，有谁来参加，什么时候，在哪儿开会等。

如何主持会议？

在会议一开始就要进入主持状态，清晰地陈述会议的目的、会议所有讨论的问题，以及会议的步骤。

按时开会。即便有几个与会者还没到会，你也要按时开会，就像他们已经到会了一样。当他们到会场发现错过了一些重要内容，他们就知道下次不能再迟到了。不要等人齐了重新开始，否则就等于你在鼓励这种迟到行为。

严格按照议程表主持会议。一旦会议开始，就不要谈论与会议议程无关的话题了，尽量按照会议的议程表来主持会议。在讨论议程中，你要密切注意所讨论的议题和所用的时间，或者专门指定一个人负责把握时间。

如何按时结束会议

按时结束会议有助于保证会议的效率，同时也便于与会者安排接下来的工作，与会者也会比较高兴。你可以使用以下技巧来保证会议按时完成：

（1）让一个团队成员来做计时员。

（2）每隔一段时间提醒大家一下还剩下多少时间，还有几个议题没有讨论。

（3）如果时间不够了，就优先或者推迟讨论某些议题。

（4）如果需要延长会议时间，应先征得大家的同意，或者也可以另行安排一次会议来处理剩下那些没有解决的问题。

如何对会议收尾

会议的结尾用来说明会议已经达到的真正目的。

对会议进行总结。对会议总结时就意味着会议要结束了，总结的人可以是领导，也可以是与会者。无论是谁总结，都要重申：

（1）所讨论的关键问题。

（2）所做出的决策。

（3）下一步计划如何实施。

（4）每个任务分别由谁来负责执行。

这一环节可以帮助大家理清他们不太明白的地方，同时也是和大家就会议达成的结果再次进行确认。

把会议上涉及的重点内容记录下来。一定要让会议的记录员把所有重要的内容都记录下来，如关键的议题、所讨论的主要观点、所做出的决策、会后大家各自应该承担的责任，包括由谁来承担这些责任，他们需要用多长时间来完成他们各自的任务。

如何做好会后的跟进工作

会议开得成功与否关键在于会后跟进工作做得好与坏。而高质量的会后跟进工作恰恰是最容易被忽略的一个环节。所以说，若要会议取得真正意义上的成功，最重要的一件事就是积极做好会后跟进工作。因为毕竟问题的关键并不在于会议本身，而是经过会上讨论所要进一步采取的行动。

如何能够保证会后的跟进工作成功呢？关键是会议上形成的沟通和行动计划，应该包括三方面的因素，即什么事、谁、什么时候完成。

（1）会上做出了哪些具体决策，产生了什么结果，以及会后应该完成什么样的任务？

（2）由谁来负责执行这些任务？

（3）什么时候完成这些任务？让与会者对于承担的任务制订一个较为合理的工作计划。

最后将沟通和行动计划以会议纪要形式发给所有与会者和相关人员，让没有出席会议的人看了这份材料之后知道会上都发生了什么。

最后以小平同志的一句话作为结尾吧：“开会要开小会，开短会，不开无准备的会。会上讲短话，话不离题。”

附录　评审会样例

项目过程中评审会是个常用的会议形式，项目管理部同事刘煦萍总结了如何高效地举行这种会议的方式，如图1-21所示。

这样在评审过程就会形成一个检查表，如图1-22所示。

图1-21　评审会流程样例

图1-22　评审过程检查表

高效回顾，引导团队从优秀到卓越

文／曾璎珞

回顾会能够引导团队持续改进，是项目管理非常重要的一个环节。本文从回顾会的形式、如何高效地开回顾会以及回顾会后形成的行动事项如何落地这几个维度来讨论，希望能为读者日后如何开回顾会提供相关思路。

临近年底时，很多人都会写年度总结，回头看自己的过去，反思每件事，尽量把来年的事情安排妥当。但是世事难料，未来充满了各种不确定。当然，如果把目标定得更明确一些，由写年度总结改为写月度总结，也许回顾的效果就会更好一些。

定期回顾，对个人而言，非常重要；对团队而言，亦是如此。例如，戴明环PDCA里，每次行动后的“检查”环节；Scrum敏捷模式中，每个迭代末尾的回顾会，均是让团队及时回顾，发现过程中的浪费（特别是协作中的障碍），分析根源，落地实施，引导团队持续改进。

常见的回顾会形式

作为项目经理或团队负责人，需要引导团队及时回顾，定期反思和调整。

常见回顾会的组织形式有：

（1）与会人员用便笺纸（见图1-23）写下项目过程中做得好／不好的5个点，按照分类贴在白板上，确保大家的意见能够充分自由表达。

（2）在白板前逐条看大家的意见，共同发现问题，并有针对性地展开讨论。

（3）对大家总结出的好／不好的点，进行集体投票。

（4）由项目经理整理投票结果，好的方面总结成最佳实践予以推广，不好的方面加以讨论。

（5）得出流程改进方案。

图1-23　回顾会示例

然而，我们经常看到虎头蛇尾的回顾会，花费了大量时间逐一讨论每个人写下的“顶”和“踩”，但后期的改进方案却没有深入地挖掘。回顾会的典型过程是发现问题—分析问题—解决问题，核心在于根源分析以及决定改进措施。根源分析可以采用多问几个“为什么”的方式，而改进措施必须由团队自己给出，可能讨论过程中有冲突争执，但必须在会议上得出达成共识的团队决策以及具体措施。

一个版本开发结束了，回头看看来时路，总结一下优缺点，回顾会就是个很好的方式。但几个版本的回顾会下来，是不是发现，问题还是那些问题？项目的关键问题似乎一直没有被有效地改进。

回顾会，如何高效聚焦、形成结论

1．如何选择合适的主题

回顾会的主题一般针对完成的迭代过程，但有时我们也可以穿插主题性的回顾会，比如，我们一直在做团队持续集成和自动化测试方面的改进，那么可以选取这个主题做回顾。建议在各个迭代中，主题性回顾可以和“正常”回顾

会穿插进行。这样，既有主题性的回顾会，引导团队实施长期主线改进；也有“正常”回顾会，定期检查团队状态，及时发现潜伏的问题或风险。

2．回顾会该有多长

当回顾会超过2小时，人们就会变得很疲惫和缺乏耐心了。对于固定节奏为两周的迭代来说，我们推荐会议时间为1.5小时以内；对于更长周期的迭代，建议会议时间不超过2小时。另外，如果能买些水果零食，那么回顾会的气氛就会更活泼，不让人觉得那么冗长了。

3．怎样发现问题

需要限制发现问题的时间，不超过会议时间的1/3是合适的。既然要压缩发现问题的时间，那怎么做呢？可以提前做团队意见收集的工作，也可以通过画项目时间线的方式一起回顾项目历程，从而列出问题列表。我们不可能三头六臂同时改进多个问题，那么就从列表中选取1～2个重要问题，作为下一步分析和改进的目标。有时，某个迭代的问题暴露非常明显，比如迭代交付失败或者严重延期，那么不需要收集信息，直接展开分析就可以了。

4．如何调节会议的基调

一方面，会议基调是每位与会者心情的叠加，它直接影响会议最终的结果。因此，回顾会开始前，建议先私下里了解每位成员即将与会的感受，这些信息非常重要。当你将与会者的感受映射到“问题解决者”、“学习者”、“游客”、“囚徒”等不同角色上时，你会发现：

•　如果大多数人扮演的是“问题解决者”，说明大多数人是带着明确的问题参会的，并且希望借助回顾会改善现状，那么，恭喜你，接下来的回顾会效果不会太差。

•　如果“游客”或者“学习”居多——大家只是过来玩一玩，或者来见识一下回顾会怎么开，那么会议组织者需要反思，会前是否准备充分，是否已经把客观的数据和问题清晰地传递给了团队。

•　如果有“囚徒”在这里，那么“囚徒”成员需要被重点照顾。

另一方面，会议基调也是每位与会者会议理念的叠加。在初期的回顾会上， 大家常常认为，解决的问题越多越好，然而很多时候却只是“补丁式”地缓解了一下问题，并未去根治。如果要让团队真正碰触到问题的根源，深入细致地探讨出解决方案，则需要有充足的“时间”和“耐性”。这时候，需要会议的主持人向大家灌输正确的理念——“复杂的世界里，一个就够了”。面对众多问题，能够完美地解决一个，也就够了。要帮助大家聚焦。聚焦之后，团队讨论过程中更容易有实际的、正向的进展，这是对团队最好的激励。

回顾会的结果如何有效落地

回顾会落地措施有以下几点：

（1）团队长期共享一份持续改善的检查表。表中包含正在改进中的问题和事项，也包含后续待改善的问题。

（2）回顾会开始时，检查进展。在回顾会开始时用几分钟时间检验一下上个回顾会改进的效果。时间控制严格、改进措施明确的回顾会，是团队持续改进的加油站，它既是上一迭代的完满句号，又是新迭代希望的开始。

（3）回顾会结束时，为每个行动事项指定一位负责人，更新检查表。重要的行动事项，甚至可以直接当作一个项目来推进。某些行动计划，可能需要学习新的技能，此时，可以与技术经理一起，为成员提供相互学习的氛围和机会。任何改变都是困难的，一旦发现正向变化，别忘了及时反馈给团队，这是对团队最重要的鼓励。

附录　角色映射法使用实例

笔者曾经主持的某次回顾会上，有一位QA美眉表达了她的“囚徒”感受，她认为最近一次的线上Bug是她的失职，这次回顾会主要是来找她追责的，因此压力山大、紧张异常。借回顾会茶歇的机会，笔者与她单独进行了沟通——“问题的根源，80%以上来自团队和过程，而不是个人”、“质量，不仅是检测出来的，更是在过程中被开发出来的。”

在接下来的回顾会过程中，笔者更多地照顾“囚徒”美眉的感受，并且引导团队更多朝着组织和过程的方向来求解。

最后，针对这类线上Bug问题，团队找到的主要根源是“过程质量有待提高”，找到的解法及落实到具体事项是“开发代码回顾”、“提测环节，开发和QA共同把关”，从源头保障质量；同时“功能上线后，由QA负责人及时做线上校验”，在最后一个环节把好质量关。

项目管理从零开始

文／陈海春

互联网公司中很少有公司级别的强流程，几乎没有需要统一遵守的检查点和文档规范，“百花齐放、争奇斗艳”，一派繁荣，每个部门、每个产品都是一个小自由王国。在此基础上项目经理如何开展工作？如何引入恰当的、不被人反感的相关流程来做到从混沌到适度有序？从访谈了解问题入手、确定试点项目、评估产品部门的痛点是否被解决，再到定期的规划图制定、项目落地的保障——“三步评审法”等一系列方法手段的应用，将网易四个不同部门的项目管理水平提升到一个新的台阶。

项目管理简单吗？非常简单！因为只要你掌握了基本的思路和方法，就能一通百通，达到“一切皆项目”的境界。那么项目管理复杂吗？当然复杂！因为项目管理不仅要根据相应的方法论依葫芦画瓢，更重要和更具有挑战性的工作是在项目执行过程中人员间的协调、沟通、冲突处理、加强团队凝聚力等与人密切相关的部分，只有相互信任的团队才能到达项目顺利交付的彼岸。

本文记录了笔者近三年的时间里在四个不同业务部门从事项目管理工作的主要过程，介绍了如何将纵横交织、盘根错杂的业务部门各项目梳理到基本井然有序地交付，并提炼出一些在弱矩阵环境下项目管理的基本思路，供读者参考。

通过访谈了解问题

项目经理要做好随时被空降到不同部门、不同项目的准备，项目经理往往是业务部门领导心目中的那个可以信赖的人：组织者、协调者、促进者。也许是老板们一个紧急的合作项目希望项目经理管起来，也许是一个迟迟看不到进展的项目需要项目经理去拨乱扶正按期交付，也许是一个迫在眉睫的、极具挑战性的项目需要项目经理按时上线。项目经理被寄予厚望，信心满满地走马上任了。那么如何开始呢？

不论一个项目经理拥有多么丰富的理论知识、多么牛的实战经验，如果对项目背景、团队成员不了解的话，也是举步维艰的，更别说按时交付项目了。所以不论你接手的项目多么紧急、多么重要，作为项目经理的你需要开展一些一对一的或者一对多的访谈，带着同理心去聆听大家的反馈，并适时地引导大家朝正确的方向前进。

如何了解和知道当前业务部门对项目管理的期望？如何了解项目的当前状态？只有知己知彼方能百战不殆，虽然业界有很多方法来达到这个目的（如问卷调查、面谈、焦点小组、匿名反馈等），但都比不上一对一、面对面的访谈来得直接和真实。面谈的问题列表主要包含以下内容：

（1）部门的愿景是什么（或者项目的目标是是什么）？

（2）目前项目或部门中的主要风险／问题有哪些？

（3）目前的工作方式／流程是怎么样的？团队成员的分工是怎么样的？

（4）目前质量衡量指标有哪些？

（5）影响项目成功的关键因素是什么？如何界定项目的成功？

（6）对项目管理的期望是什么？

笔者在初入一个业务部门时通过与所有团队主管（8名）和部分同事（6名）进行一对一访谈后，得到的主要反馈有：

（1）项目立项较随意。

•　缺少市场调研分析，对该项目／功能所带来的改变／收益没有详细地研究。

•　无法说服相关参与者真正参与到项目中，下游开发测试团队感觉都是为上游的网站策划团队打工。

（2）需求变更频繁、更无流程，变更原因不清，变更后通知不及时。

•　需求讨论和分解不充分。

•　没有召集所有可能受影响的团队成员参与讨论（如经常忘记让测试、客服人员参加），或者需求讨论只在会议上进行，没有预留时间让大家提前了解需求。

•　需求文档和相关的交互、视觉文档没有基线化，大部分需求变更都是通过在文档系统上追加备注进行更新的，而下载的文档内容并不是最新的内容。

•　需求变更经常在IM通信群里进行讨论，需求文档却没有及时同步更新，并且有些相关人员没有及时通知到（如测试人员）。

•　无变更管理流程（什么样的需求变更需要谁在什么时候做决定）。

（3）各项目的计划不清楚，项目状态不透明。

•　无项目交付节点或者对里程碑的交付物定义不清楚。

•　相关项目参与人员很少有定期的面对面会议进行状态同步，大多数沟通是通过IM工具来完成的。

（4）产品策划人员没有得到充分授权进行项目的执行，或不知道如何进行进度监控和风险规避，部分策划人员没有动力去进行项目的计划、跟踪和了解交付过程，认为策划出的功能后续团队就能自动交付。

（5）相互推诿，对于延迟的项目／任务，基本上都认为问题出在其他团队身上［如技术人员认为UED（User Experience Design，用户体验设计）是瓶颈，UED认为策划是瓶颈等］。

（6）会议效率较低。

•　没有留出时间让会议参与人员进行准备。

•　很少有会后跟踪措施，没有做到问题的闭环跟踪。

（7）很少有人在乎计划的交付日期。

•　产品部门无中、长期的计划，以及如何达成这些目标计划不可视，建议通过季度部门会议从业务优先级上使大家达成一致。

•　无部门管理团队定期的面对面周会，周报大多流于形式，各组间的依赖、风险、问题没有进一步的跟踪和解决措施。

（8）临时性任务多，经常打断正在做的项目／任务。每个小组都认为问题出在其他相关小组上，不认为是由于本小组导致项目／任务延迟的，无相关历史数据供参考。

总体来说，大家对项目管理的期望是：

（1）项目计划清楚、可视、可控。

（2）给出一个项目启动评审的决策流程，能够帮助大家识别项目的价值和优先级。

（3）加强各部门在项目中的合作，使相互的协作更加流畅。

（4）项目需求更加清楚合理，考虑更全面。

（5）需求变更有据可依，有据可查。

（6）提高项目参与人员的主人翁意识和责任感。

（7）尽快做1～2个标杆性的项目，通过此项目向大家传播专业的项目管理方法。

在得出基本的问题列表以及结合大家对项目管理的期望，和业务部门主管一同讨论后就可以水到渠成地得出项目管理工作的基本思路。不积跬步无以致千里，改变和提升可以先从试点项目开始。

改变从试点项目开始

1．试点项目的选取

首先，试点项目要具有典型性和代表性，其中包括项目规模、人员构成、时间长度、结果跟踪。最好选平均规模的项目，不可太大或者为了制造出一个试点项目而圈定2～3人参加的小项目。人员构成应该保持全部流程参与方的团队，例如一个典型的互联网项目需要有产品经理、交互视觉设计师、开发工程师、测试工程师、运维人员、运营推广员等主要角色，在试点项目中最好能够包含这些全流程的角色。在互联网领域，通常的项目交付时间长度应该是1～2个月，不可选时间太短（1～2周）或太长（＞3个月）的项目，时间太短可能一些项目活动都被剪裁了，时间太长则试点输出的结果需要很久才能得到推广。试点项目的结果跟踪指的是被选定的项目需要在项目开始的时候定义清楚 如何衡量这个项目的成功与否（项目管理铁三角、线上数据表现、团队成员反馈、用户研究访谈等指标）。

其次，试点项目要得到业务部门领导的支持和授权，让领导们明确知道这是试点，在试点过程中可能由于新引入的一些方法、流程不一定适合团队，导致团队的效率下降。需要对试点项目希望达成的结果有统一的认识，如通过试点项目，是想找到比较适合目前团队的流程方法、度量指标，还是提高项目及时交付率，抑或通过项目交付打造优秀团队文化和自组织团队。

最后，试点项目团队成员需要知道自己身处“试点”之中，犹如在拨打自助电话客服时被提示“您的通话将会被录音”一样，使每个人有心理预期和准备，更积极有效地加入试点中来。

2．试点项目的执行、数据收集与分析

试点项目的目的要明确，需要针对性地收集数据。数据为下一步改进提高提供决策的基础，没有数据支持的决策基本上都是凭感觉和拍脑袋的，正所谓“无量化，不管理”。针对前面访谈所暴露出的主要问题，在试点项目中重点收集的数据有项目人力支出、项目规模变化、线上缺陷数量、及时交付率。

3．项目人力支出

网易可以说是一个不差钱的互联网公司，很多产品／项目不需要进行相关的预算审核和营收考核，大家可以在一种宽松的环境下发挥创造力，自由地打磨产品。但同时也带来一个问题，有些产品投入了上百人月但是用户规模、营收很不理想，导致团队成员怀疑其产品定位和质疑我们的价值、我们的ROI在哪儿。统计项目人力支出并不是想通过投入的人力来判断一个产品／项目的好坏，而是希望让部门总监知道不同项目的人力投入，以及项目所带来的收益是否值得，后续如果有类似的项目是否还会投入这些人力，抑或减少／加大人力投入，甚至需要考虑类似的项目是否可以直接从市场采购。

图1-24是一个对外合作项目的投入人力情况，数据来源是每周项目周会上每人记录在过去一周投入这个项目的时间百分比，历时4个来月，总共投入了24人月。项目上线后的第一个月带来的销售额是2万多元，新用户数也区区不足千人。

图1-24　对外合作项目投入人力的情况

在项目回顾会议上大家都认为这个项目的ROI很低，在项目启动时需要慎重评估，项目发起方商务团队需要对接项目的结果进行预估和上线后有相应的衡量考核体系。

4．项目规模变化

在不同部门的初期访谈过程中，研发团队反复提到的一个希望是能够控制需求变更，减少变更。为了能够衡量项目开发过程中的需求变化情况，在试点项目中从项目规模维度进行了量化和记录。由于大家以前都没有接触过敏捷中的故事点估算方法，在大家对敏捷还没有什么概念的时候，如果推行故事点估算的话将会遇到很多困难（故事点和人天间的换算、模块负责人估算的权威性等）。

图1-25　项目规模与进展对比

这里使用大家最容易理解的人天来进行估算，图1-25所示的项目在初始阶段时规模是112.5人天，中途增加了需求导致规模上升到145.5人天，同时 实际花费的人力也是145.5人天，最后得出规模变化率为29%，其计算公式是：（实际花费人天－项目初始估算人天）／项目初始估算人天。

得出项目规模变化率的目的并不是想控制需求变化、减少需求变化，而是通过3个试点项目的统计数据发现，在A部门中的项目规模变化率中位值是25%，通过回顾分析发现，这些变化的需求大部分来源于两个方面：一是由于产品策划考虑不充分，例如一些异常情况的处理；二是技术实现上的难度比估算时更大。因此在A部门的后续其他项目中基本上预留额外的20%项目规模作为缓冲时间。

5．线上Bug

在加入K部门后要求QA部门对线上Bug进行统计分析（见表1-7），并发出月度线上Bug总结邮件，P0级线上Bug指已影响到用户使用的情况，不论影响了多少用户（如支付环节中支付不成功问题）。P1级线上Bug指不影响用户使用的功能（如内部系统问题、活动页面图片／链接配置错误问题）。

表1-7　Bug统计分析

统计时间区间

P0 Bug数

P1 Bug数

线上Bug总数

2015.7.16—2015.8.15

4

21

25

2015.8.16—2015.9.15

3

7

10

2015.9.16—2015.10.21

3

7

10

深入分析这些数据后还发现一个有趣的现象，即约有1/3的线上Bug是由于修改前一个线上Bug导致的，或者由于测试场景不充分、仓促上线导致的。基本上每天都在上线（当然如果CI做得好、自动化测试足够的团队每天上线也许没有什么问题），合代码并进行手动回归测试基本上只有1天的时间。为了减少线上Bug的发生和做到有计划、有节奏地上线，特别制定了固定上线节奏（在K部门是每周二、周五两次）。

6．及时交付率

通过对部门中3个月里交付的所有项目完成时间和计划完成时间的比较得出项目及时交付率，从3月11日到6月4日在部门中共上线了16个项目， 平均项目时长31.8天（日历日），其中3个试点项目由本人担任项目经理，其他13个项目由开发负责人或者产品经理兼任项目经理。

16个项目中按计划日期上线的有8个（部门中的项目及时交付率为50%），这和访谈中大家谈到的项目延迟严重比较吻合。8个延迟项目中，延迟率从2%到60%不等，详情如图1-26所示（由于涉及公司具体的项目和人员，在图1-26中的项目名称已做模糊化处理，项目经理一列中具体的人名已移除）。

图1-26　各项目状态表

通过图1-26的数据可以看出，超出1个月的项目延迟风险比1个月内的项目延迟风险要大得多，其中延迟57%、60%的两个项目主要原因是中途方案调整较大。

建立基本的项目管理流程和度量体系

1．项目集路线图机制

公司的运营、部门的运作犹如行使中的高铁列车，一旦启动就很难停下来，部门中每位同事每天都很忙，最近两年互联网公司流行一个术语叫996（指工作时间从早上9:00到晚上9:00，每周6天），但是经过半年左右的996后，团队就会频繁地质问我们真的需要996吗？为什么每天都在救火？每个事情是真正值得做的事情吗？

由于业务部门的业务不断发展壮大，业务启动时单一仓库无法满足要求了，需要将货物挪仓，有时同一货物需要在不同仓库中发货，而开始时系统是 针对单一仓库设计的，有些功能无法实现。例如，某天的主管站会上，一位运营同事提出希望在不同的仓库间售卖同一商品时能够做到用户看到同一个页面，并且评论可以分享。产品经理答应会后给出解决方案来帮助运营同事减少评论复制、页面复制的人工工作量。但是，详细分析和了解目前系统架构和数据结构后发现，底层商品逻辑不支持，需要对相关系统进行重构，也无法承诺具体什么时候能够重构完成，而仓库间货物转移早在2个月前就已经开始了。是什么导致了如此重要的功能一直没有被提上产品开发日程呢？第二天项目经理和业务部门CTO就此事进行了讨论，得到的结论是平时大家都忙于应付紧急的事情，这些重要的事情往往被一而再、再而三地延后了。

这类情况在其他部门也经常见到，因此对应的一个解决方法是设立部门重点项目集管理，通过每两周一次的产品路线图会议来对项目集中的每个项目状态在核心主管团队中进行回顾，以评估当前的重点项目是否有风险／问题，以及是否有新的项目需要纳入重点项目集中。

图1-27是在K部门所使用的项目集甘特图，其中1～6（浅绿色背景的项目）为部门重点项目。

图1-27　项目集甘特图

为了保障重点项目能够有足够的人力投入，与CTO及各位主管达成的协定是：一旦重点项目立项，那么需要保障人力来交付项目，如果其他项目或事情需要挤占重点项目的人力并且影响重点项目交付的话，就需要部门CTO批准了。

2．三步评审法

在完成了三个试点项目后，摆在项目管理工作面前的问题是：如何找到适合业务部门的项目管理基本方法和流程？诚然，原封不动地应用Scrum流程时机未到，并且阻力较大（涉及组织结构的调整、新的角色职责、考评方式的改变），也无法照搬CMMI/IPD等繁重的流程体系。在和业务部门领导及团队主管同事讨论后，我们提炼出里程碑规划＋迭代的项目管理基本思路，从项目启动到项目上线，其间辅以3次主要评审活动，取名为“三步评审法”，这些评审活动的目的是使项目团队在“做正确的事”方面更有保障。

通过对业务部门的项目交付流程的整理，梳理出如图1-28所示的基本过程，其中产品创意讨论阶段和项目需求确认阶段由市场／需求小组与部门主管一起进行讨论，主要集中在市场前景分析、ROI预估等方面，不需要包含大部分项目组成员，因此这两个步骤没有纳入项目评审会议中。而最后面的项目总结阶段目前仅仅针对有营收指标的一些项目进行分析，并没有覆盖到所有的项目中，所有项目的评审会议中也没有包含这一步骤。因此，三步评审法包含的内容是图1-28中框内的内容，包括策划需求评审、交互／视觉评审和上线评审。

图1-28　项目交付流程

3．3个评审会议内容结构

表1-8是三种评审会议基本内容。

表1-8　三种评审会内容结构

表1-8中的3个评审会时长限制在1小时，是希望会议组织者、参与者能够在会议前准备好，在会议上重点讨论有分歧的问题，避免冗长而低效的会议。

4．形成每周固定上线节奏

结合前述访谈的反馈和试点项目的反馈，在业务部门中实施了每周二、周五两次固定上线节奏，上线窗口之外的上线均需要部门CTO批准，做项目计划时将上线时间匹配入对应的上线时间窗口。这样的安排所带来的最直接的一个好处是使研发部门（开发、测试团队）的计划性更强了，工作也更从容了。

通过两个月的观察和数据统计发现，紧急上线频率下降得有限。实行固定节奏上线的机制后的第一个月紧急上线了20次（22个工作日）、第二个月紧 急上线了18次（21个工作日），这其中主要原因是电商活动相关的一些修改和上线。通过和研发同事对这些数据进行分析，发现每次紧急上线的内容变少了，没有了以前那种搭便车的情况了，因而研发的压力并不是很大。

要做到业务人员眼中的“想发就发”的境界，下一步需要建立起比较完善的CI系统，其中最重要的是完善相关的自动化测试脚本，能够做到回归测试交由机器来完成，而测试人员要聚焦在新功能的完备性测试和相关的探索性测试上。

5．最小度量数据集＋闭环跟踪指标

通过在试点项目中形成的数据统计，与业务部门领导在项目的最小度量数据集及闭环跟踪指标上达成了共识，其中最小度量数据集主要包含的内容是：人力支出、及时交付率、规模变化率、线上漏洞。

（1）人力支出：在每次项目站会上收集项目成员投入本项目的人力占比，单位为人天，用于衡量项目的基本人力投入。由于计算机服务器资源在互联网公司一般都在云端，所以这一块的成本基本不用在项目中进行记录和衡量了。

（2）及时交付率：用于统计项目延迟／及时交付的情况，计算公式是：（项目实际上线日期－项目计划上线日期）／项目计划时长，日期对应的单位为工作日。

（3）项目规模变化率：可以使用人天或者故事点来衡量项目规模，规模变化率是指项目实际所花费的人天或故事点除以计划的人天或故事点，用于衡量产品方案的完备程度。获得较多数据后将可以用于项目缓冲时间的基准。

（4）线上Bug：用来衡量项目质量的一个主要指标，记录线上Bug数量和严重程度。线上Bug严重级别根据不同的业务可以进行划分，例如下面P0-P2级别划分是某部门的定义。

•　故障等级P0：重要性高的服务功能不可用或功能异常，且大面积影响用户使用。

•　故障等级P1：重要性高的服务功能不可用或功能异常，但影响的用户有限；或者，重要性中等的服务功能不可用或功能异常，且故障持续大面积影响用户体验。

•　故障等级P2：重要性中等的服务功能不可用或功能异常，轻微影响用户体验。

其中闭环跟踪指标主要是在上线的1～3个月内对线上表现情况进行跟踪分析，记录的数据主要是营收和新用户数两大类指标（PV、UV），以及复购率作为辅助指标。

6．全员培训

一个流程的确定和实施需要广而告之，让部门所有同事知其然、知其所以然，需要讲解为什么选取这样的流程、记录这些数据等内容。对部门全体同事进行培训，是开展后续全面项目管理必不可少的一个环节。全员培训的内容主要是以下四个方面。

（1）流程和项目最小数据集：三步评审法的内容、输入、输出以及需要参与的人员介绍。解释为什么要进行项目的最小数据集度量，每个历史数据将如何使用（这些基本的数据不能用以团队成员的季度考评，主要用来衡量一个部门的整体的项目健康度情况）。

（2）成员职责说明：除了团队成员的各自角色介绍外，其中项目经理和产品经理的职责需要重点介绍，这是一般人比较容易混淆的两个角色。项目经理的主要工作职责是组织和协调项目中各项活动，提高团队效率；项目计划跟踪执行，识别风险和解决团队所遇到的问题；服务于产品，使项目顺利交付。产品经理的主要工作职责是理解用户需求，定义产品形态，形成需求列表，决定功能优先级。

（3）不同项目类型的定义：为了简单起见，将项目分为重点项目、非重点项目两大类别。特别需要对重点项目的评选机制、变更流程进行重点说明，并且让大家清楚地知道当前有哪些项目是重点项目。

对项目管理的反馈

每个人都希望自己的工作能够得到他人的承认，作为项目经理也不例外。为了能够知道过去一段时间时业务部门的贡献和价值情况，基本上每半年会对业务部门全员进行匿名反馈，以下是其中一个部门在项目经理介入6个月后的 一些团队反馈，主要结果如下：

（1）100%受访者认为项目管理介入后项目管理及时交付率有了提升（数据显示，在项目经理介入的半年中项目及时交付率从20%上升至68%）。

（2）78%受访者对项目管理工作是满意或者非常满意的。

（3）75%受访者认为项目管理介入后项目的透明性、质量方面有提升。

（4）50%受访者认为三步评审法适合目前业务部门的现状，38%受访者认为比较占时间或没什么感觉，12%受访者认为没有必要。

虽然基本的项目管理流程对三步评审法接受程度不是太高，但它使项目经理深刻地认识到一个流程是需要不断优化和演进的，没有一个可以解决所有问题的“万能药”式的流程能够解决目前业务部门所有的问题。知道问题所在才是更进一步地工作的动力所在。

除了上述量化的反馈外，在工作中的项目管理对项目风险的管理、减少外界对团队的干扰、为项目保驾护航等方面带来的好处而赢得团队成员的称赞是无法用量化数字能体现的。

项目管理的下一步

项目管理在一个部门中得到初步的认可了，基本的项目管理流程也已建立了，及时交付率得到了一定的提升，后续项目管理在业务部门中该如何发展呢？

及时交付项目是对项目管理的基本要求，持续优化项目管理相关流程是项目管理的本职工作。三步评审法只是一个起点，后续要结合项目的实际情况使这些评审中的相关工作更好地落实，并且在效果和会议时间上取得更合理的平衡。

项目中硬性的东西（如流程规范、度量指标、工具使用等）相对而言是比较容易建立的，而团队中软性的东西（如团队文化、激情和士气、认同感等）是需要长时间的引入改变的。后续在保持和维护基本的硬性要求外，将在这些偏软性方面提供更多的项目管理增值服务，如打造相互信任的自组织文化、减少浪费、闭环反馈、教练机制。

1．打造相互信任的自组织文化

团队是否认同所设定的基本项目管理流程？团队是否还为产品的未来心存梦想？团队是否在为达成项目目标而自愿奉献？这些更深层次的问题需要的不仅是项目管理的流程方法来解决，还需要深入到业务部门和团队中去，聆听大家的心声，施加相关的正能量。要想在上下级中获得信任，一个前提条件是团队的产出能够是一个完整的交付物，而敏捷圈的特性团队（Feature Team）能够从基础上提供一个良好的组织架构。

特性团队指承担端到端交付任务的、长期的、跨职能成员合作的一种团队形式，例如一个典型的互联网项目的特性团队包括策划、交互视觉、开发、测试、运营成员。相比目前大多数组织所采用的功能团队（Function Team），特性团队的好处是可以承担完整的、端到端的交付任务，能为结果负责，而不是众多环节中的一个螺丝钉，无须在功能团队间进行任务传递，整个特性团队对项目的成败负责。

在项目集管理方式中，各项目团队成员在项目完成后就解散了，针对这种项目成员不固定、项目周期比较短的项目是否可以采用固定的特性团队来提高团队合作效率呢？在参加Scrum认证培训以及与业界同行聊起这个话题时，大家几乎都建议是把业务部门目前的功能团队组织架构改成类似图1-29中的特性团队。

图1-29　功能团队与特性团队组织对照

虽然特性团队的好处是可以将团队固定下来，不同的项目可以由任意一个功能团队完整地交付，每个团队对从头至尾负责项目的定义、开发、测试、上线和运营。但在应用特性团队之前需要和相关团队、上司达成共识：这些以前每个团队的负责人角色如何定义？每个同事的领域能力如何能够得以提高？如何让部门领导授权给团队？团队的能力成熟度是否足以为结果负责？

2．减少浪费

笔者曾经经历的一个真实而典型的项目是这样的：一个2013年的Win 8 Metro风格客户端项目花费的研发人力成本是24人月，但是2014整个上半年贡献的销售额不足1万元。当时项目是及时有效地交付了，但是它的价值/ROI如何呢？另外，这种情况对团队的长远发展是非常不利的，长此以往将没有人会认同业务愿景，士气低落，对业务的发展形成负效应。除了加强项目立项评审、多方共同参与决策外，应用精益创业中最简产品（MVP）概念来验证需求，将会使这样的“大”失败更少一些，为公司节省资源和费用。

3．闭环反馈

闭环反馈是为产品、市场、运营活动提供结果跟踪、意见反馈的跟踪手段。我们曾经在一个网易的垂直电商产品（个性化印品定制）中推广了这一方法：对所有的运营活动、推广合作、新产品上线制定出上线后一个月内的线上数据表现情况、客服反馈情况的闭环反馈和评价机制。在这个过程中客服的意见被更加重视，不能说目前对客服的意见大家不够重视，只能说客服反馈意见的时候大家都觉得有道理，但是后续没有相应的措施来保证客服意见被接受和修改到产品、活动中去。久而久之，客服就有点儿麻木了，不再想反馈意见了。我们在后续的过程改进中让客服参与到产品定义、需求讨论中来，使客服（客户意见的代表）的意见真正被重视和被落实。项目上线一个月后的数据分析会上邀请全体项目组同事进行线上数据分析（销售额、PV/UV、新用户数、复购率等指标），让大家能够切切实实地感受所交付的项目带来的价值是什么。如果没有达到目标需要业务负责人给出原因分析和后续改进措施。

4．教练机制

教练是一个集多种角色于一身的人，但他的主要职责是挑战和激发团队成员的潜力，做团队中那个看不见皇帝“新衣”的小孩，把团队中的问题真实地反映出来，然后促使大家意识到该问题的存在，并通过引导建立相关的团队文化、工具、流程。这些工作不是一朝一夕能够立竿见影的，需要比较长的时间才能看到团队的变化。

笔者一直认为在弱矩阵下的项目经理是一个成本中心而非利润来源，项目经理的价值是通过提高团队的效率、提高项目成功交付率而体现的。项目管理是为业务部门解决问题、提高效率的，而不是单纯地推广流程、文档。

只有成功的产品才有成功的项目，项目管理需要和业务紧密结合才能体现价值，项目管理需要为业务发展提供支持和保障，它没有职责边界限制，它取决于所在的环境需要什么样的项目管理服务。

悬崖边的舞蹈—— 小议风险管理及在互联网项目中的应用

文／曹智清

风险管理要求我们只能够相信那些真正靠谱的，逐一甄别所有的质疑和信心动摇点。致命风险超出了项目经理的责权范围，除了转交上级，我们还是可以在日常风险管理中加以监测，以便及时提示致命风险转化的可能性。风险需要被持续监测，风险的具体影响需要被明确体现。常见风险列表可以辅助风险排查。

当刘翔脚伤的新闻见诸报端但他依然站在了伦敦110米栏的起跑线上时，我们知道这时只能阿弥陀佛了。然后，正如蛋糕掉落时总是奶油的一面落地一样，人们看到了最不愿意见到的英雄凄然离场的一幕。

当一艘老爷船的船主满心祈祷目送旧船又一次远航，却接到旧船倾覆乘客丧生的噩耗时，他究竟应该感叹命运的不公还是神明的缺失呢？

生活中太多的悲剧都在演变成灾难前有所征兆，然而人们却习惯于应对变化，没有为可能的变化做准备。项目管理亦是如此，我们要学习如何从解决问题事件的泥沼中挣扎出来，学会去发现、直面和管理灾难征兆，这就是所谓的风险管理。

信仰的伦理学

对于风险的认知，有太多的定义，我们说，只相信你有权相信的事。比如，你可以一直坚持说项目将于下一个春节前交付，但是你是否真的考虑了各种因素？是否经受得起伦理和信仰的考验？是否真的有权这么坚持？管理的核心是“信仰的伦理学”——风险管理要求我们对于项目推进的每个信念都必须接受伦理的拷问，只能够相信那些真正靠谱的，而将所有的质疑和信心动摇点逐一甄别出来。

风险，并不是带着“坏人”的印记出现的，并不总是件坏事。没有真正意义上的风险，项目注定是失败的。因为，在全无风险的同时，它们也几乎全无收益。

大部分项目经理都会在项目中进行风险管理，但我们往往会看到，或者致命而深刻的风险未被发现，或者风险的初期识别和后期监控脱节，或者虽然控制了部分风险却全然不知对产品和项目的作用何在。

致命风险

你是否看到过一些项目，尚未完成上线就被全盘否定和取消？在这种情况下，“致命风险”转化为事实了。现实中，典型的致命风险包括但不限于：投资方撤资、大老板改主意了、竞争对手率先发布同类产品、行业市场状况急转直下等。致命风险超出了项目经理的责权范围，只有用“项目假定”才能管理它们。应该对这些风险负责的不是项目团队本身，而是让这个项目诞生的人。所以，识别它们，说明它们，向项目发起人转交它们。

虽然致命风险被作为项目假定转交给上级了，但部分致命风险还是可以在日常风险管理中加以监测，以便及时提示致命风险转化的可能性。

比如，互联网行业的很多领域先发者制胜，如果你的团队正在一片蓝海中探索，那么你一定要紧盯市场上潜在竞争者的动作和状态，有时仅仅提前一周发布就能帮助产品取得先发制人的优势。

又比如，在产品的基本定位上，产品负责人和高层重要干系人的意见不一。那么，你就需要去了解不同思路背后的原因，及时构建各种沟通讨论的桥梁，并根据各种日常项目信号来判断定位差异的变化情况和严重程度，适当时也可以从中施加影响力，促成各方的意见趋于一致。

转化监控

在日常的风险管理中，我们往往在识别和采取了一些措施之后，就自认为已经远离这些风险了。而事实上，对于大部分风险我们所采取的措施并非远离规避，而是缓解或者包容。对这些风险依然可能转化，需要长期监控。

比如，团队习惯于过于乐观地做时间估算，在识别出这一风险之后，我们有针对性地加强了时间估算，专门为设计、自测以及缓冲预留了时间。这很好，但这并不意味着估算改进之后该风险就被完全规避了，我们依然需要对时间估算的准确性以及里程碑的实现可能性做长期的监控，很可能在监测到估算偏离的情况下需要执行相应的措施来缓解该风险出现后的代价。就时间进度而言，我们就可以预设多重防护来进行风险管理，从提升日常效率到预留多道缓冲及检查点，从预备多重不同的功能裁剪或分批交付模式到及早暴露进度偏差，这些都是时间风险管理中的预备措施，在监控过程中可以根据不同的偏差情况选取不同的方法。

所以，在最初的风险识别和初步规避措施之后，我们依然需要去分析各项风险出现的可能性，并设定转化指标，做好长期监测。

风险的体现

我们有没有这样的体验：虽然我们识别出了以前被掩盖的风险，并且进行 了管理，但除了那一页风险管理文档之外，我们没有看到项目有任何不同，我们并不知道识别出来的这些风险究竟对项目来说意味着什么？

“精确”的估算，本身就是个矛盾体。但是，项目经理们，我们却一直挣扎在这精确里程碑目标日期的焦油坑中。通过WBS、关键路径等方法，我们可以得到一个目标日期的估算，这往往是一个最早交付时间的预判（见图1-30）。但是，一旦领导们看到了这个日期，容不得项目经理们展示下一页说明，领导的脑海里就已经深深烙下了这个目标日期的印记——加油！你行的！这就是你的目标！

真正的里程碑目标，应该是一张风险图，包括了最早交付日期、最可能交付日期以及最晚交付日期。最可能交付日期应该成为我们真正意义上的计划；而最早交付日期，可以作为团队的奋斗目标。目标只是用于激励员工拿出最高的工作效率；与此同时，在向顾客和管理层做出承诺时，你还需要一个与目标迥然不同的估算计划——真正的计划、最有可能的计划。

图1-30　风险图示例

比风险图更简单的，我们可以使用风险倍数来体现项目有关的风险（见表 1-9）。风险倍数包括常见的风险，例如人事变动、需求改变、工作上的障碍之类，这些风险倍数让你更准确地估计完成日期和需要多少故事点数（Story Points）。

表1-9　风险倍数

机会率

精确的开发过程所用的倍数

能完成的故事点数

内　容

10%

1

140(140÷1)

几乎不可能完成

50%

1.4

100(140÷1.4)

延伸目标——只有一半机会，有机会再去完成

90%

1.8

78(140÷1.8)

几乎可以成事的承诺

互联网项目中的常见风险

大家有没有这样的同感：出现项目偏离日程安排的情况，很少是因为工作耗费了比预期更长的时间，更常见的原因是，根本不在计划中的工作使项目泥足深陷？如果作为项目经理的你，深有同感，那么，我们就可以体会到，项目中的风险是可以互通的。昨天的问题就是今天的风险，你的问题很可能就是我的风险。事实上，我翻阅了公司文档库中留下的各个项目总结会记录，它们深深印证了这一点。

因此，我们总结并列出了互联网项目的常见风险列表（见表1-10～表1-12），你只需在项目初期逐一对照，就能够形成很有效的初始风险清单。当然，没有任何两个风险是完全一致的，这一列表的作用是辅助头脑风暴或者进行风险排查。真正最重要的风险，往往不是通过走查发现的，而是对日常项目状态把脉洞察，这样那些核心风险就会跃然纸上。

只相信我们有权相信的，质疑我们应该质疑的，说出我们的质疑，观察并应对我们的质疑，这就是风险管理。生于忧患死于安乐，并不是让我们成为那个终日忧心忡忡的人，而是让我们真正蜕变成那个看得更远、更深的人。

表1-10　常见业务风险

类别

风　险

需求

产品规划和定位不够清晰

需求

用户／主要干系人对于最后交付的产品不满意，要求重新设计和重做

需求

干系人对需求规划的审核／决策周期比预期的要长

需求

干系人坚持技术决策而导致进度计划延长

需求

干系人要求的支持工具和环境不兼容、性能差或功能不完善，导致生产率低

需求

干系人期望的开发速度是开发人员无法达到的

需求

需求变更频繁持续

需求

变更管理不够，不能及时跟踪记录

需求

添加额外的需求，产品规模比估计的要大

需求

需求不清晰，完成产品定义含混的部分比期望需要更多的时间

需求

复杂模块需要比预期更多的测试、设计和实现工作

需求

模块重构导致额外工作量

需求

分别设计开发的模块无法有效集成，需要重新设计或重做

需求

涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多

需求

开发额外不需要的功能（镀金）延长了计划进度

需求

严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作

需求

要求与其他系统或不受本组控制的系统相连，导致无法预料的设计、实现和测试工作

需求

要求在不同操作系统下运行将花费比预期更长的时间

需求

在不熟悉或未经检验的软件环境中运行产生未预料到的问题

需求

在不熟悉或未经检验的硬件环境中运行产生未预料到的问题

需求

开发一种对组织全新的模块将比预期花费更长时间

表1-11　常见技术风险

类别

风　险

技术

设计过于复杂，导致一些不必要的工作，影响实现效率

技术

设计质量低下，导致重复设计和实现

技术

设计质量低下，导致重复设计和实现

技术

对技术难点理解不够，调研评估不足

技术

使用不熟悉的技术和方法，导致额外的培训时间

技术

重犯前期实现时曾犯过的错误

技术

部分必要功能无法使用现有代码库实现，开发人员必须使用新的库或者自行开发

技术

代码审查未能提前发现代码问题

技术

开发自测不充分

技术

过高估计了增强型工具对计划进度的节省量

技术

代码管理不到位

技术

测试难度和复杂度未充分考虑

技术

部署过程不规范导致花费额外时间

依赖

产品依赖政府规章，而规章的改变将是不可预期的

依赖

产品依赖草拟中的技术标准，而最后的标准将是不可预期的

依赖

外部依赖产品没有按承诺交付

依赖

外部依赖产品不稳定，产品质量低下无法接收，必须花时间改进质量

依赖

非技术的第三方的工作比预期长

表1-12　常见后勤风险

心的修炼——项目沟通的四个原则

文／曹智清

沟通自始至终贯穿了项目从0到1的完整生命路线。本文介绍的沟通四原则，其实核心是内在的心态修炼。然而兵无常势，水无常形，不局限于形式，有强大而又积极的心态才是取胜之道。

在各种项目问题的解决、进度的推进背后，都凝结了大量的沟通协调。今天，我们就来聊聊项目沟通中的四个原则。

原则一　主动尽早

案例场景1

项目4月20日就要发布了，项目总监早就把这个信息通告给了几个重要客户，但这边，项目经理小A和团队在4月上旬就发现越来 越多计划外的任务不断地塞进了任务列表，比如测试服务器搭建等。大家从第一个任务加入的时候，就在暗自忍耐并企图自行通过加班方式进行消化。虽然大家都看到了任务列表越来越长，但没有人愿意去触碰4月20日能否发布这个问题，小A也是如此，更是祈祷团队能在计划内吃掉新增任务，而不必惊动总监。终于，到了4月19日，大家不得不面对第二天无法发布的现实了，项目经理硬着头皮告诉了项目总监这个不幸的消息。

案例场景2

项目5月20日的发布目标，预留了一周测试时间。项目经理小B对测试预留时间反复思考后，判断测试时间不足，有延期风险，第一时间向项目总监报告了这一风险。在第二天的站会上，小B向团队提出了这一风险，项目总监和团队一同讨论后，对整体计划进行了调整，测试提前一周开始。最终，项目5月20日按期发布。

小A希望把问题扛下来解决，而给总监报告好消息，结果项目无法发布；小B尽早向总监和团队沟通了可能的问题，结果项目成功交付。

怕什么来什么，躲什么来什么。爸妈从小教育我们：“要敢于面对问题。”直面是种勇气，也是种意识和态度。项目沟通中，第一条原则就是要敢于尽早暴露问题。只有把问题摆出来了，才可能调动大家的力量来尽早解决问题。

对重要干系人的沟通也是如此。虽然他们非常希望听到产品能顺利交付的好消息，但尽早了解可能存在的问题，一方面可以避免他们向客户传递潜在有误的信息，另一方面可以为团队争取到最及时有力的帮助来解决问题。而这，也一定好过发布前一天才得知一切落空吧！

有人总结说：“项目经理，就是要悲观面对项目，乐观面对团队。”话虽不尽然，但项目经理的确就是项目背后的那一双眼，要纵观全局，发现潜在问题；项目经理也是项目身后那一张嘴，不时提醒大家需要注意的问题或者需要做出的调整。一路报喜，只能粉饰太平；只有对问题的主动和及早沟通协调，才能真正收获最后的喜报！

原则二　抓住本质

案例场景3

测试主管在泡泡群里呼唤项目经理小C，“小C：有个小意见！”

“哦？”

“现在开发任务都记录到白板中，完成这个版本以后收走了那些任务便笺，我们报Bug的时候都不知道谁做哪个任务了。如果后面来了新人，每次发现Bug都过来问应该报给谁开发，这个代价有点大。”

接着小C拉着测试主管到会议室私聊。原来，新来的测试发现了回归Bug，每一个都得询问测试主管应该报给哪个开发，测试主管正愁着呢！原来测试团队一直都非常了解模块开发归属，哪怕遇到模糊地带，也会查询JIRA关键词来找到对应的任务和开发者。那为啥不直接报给开发负责人，让他来分配呢？开发负责人可以帮忙解决小部分问题，但如果是全部，那工作量就太大了。

小C似乎看到了测试主管的痛苦所在，“是啊，的确需要有个地方让测试很明确地了解模块的开发归属。”（将问题引向本质而不是具体解决方式）

“就是啊！否则我真不用干活了，整天都在帮新人指定Bug的归属！”测试主管很头疼。

看到了一致的问题，最终，小C和测试主管商量决定建一个维基页面，列明主要模块和对应的前后端开发，这样还解决了JIRA中原开发者离职变更这样的问题，可以根据团队情况保持维基页面更新。

测试主管以质疑白板作为沟通的开始，这是他所遇到的直接问题。如果小C作为白板方式发起人，以自卫的心态进行沟通的话，很容易将视点聚焦于白板本身的矛盾，从而将沟通变成攻守关系，可能很难有双赢结局。在上面的例子中，一方面小C及时避免了在泡泡群中公开讨论矛盾问题，另一方面把视点聚焦在测试主管的“需求”而不是“需要”上，这就把双方都放在了更高的、容易达成一致的目标上，而不是具体的解决方式上。这样，在相同的出发点前提下，沟通就容易顺利进行了，解决方案也就更水到渠成了。

生活工作中，有无数类似的场景，讨论由具体的某个“需要”开始。如果纠结于“需要”，沟通就容易陷于泥沼；而如果聚焦“需求”，那就容易达成求同存异。

产品经理和开发者争执于某一个临近发布时提出的需求变更，如果着眼于为什么那么晚才提变更或者进度太紧张，那么结果无论如何总会有人内心郁闷不堪。但如果先一起来看看为什么要做这个变更，对产品、对用户的作用如何，也许结果就变成我们如何去做的讨论了，而不是做和不做或者分清责任的问题了。

只有透过现象看本质，才能在沟通中真正求同存异。

原则三　共情引导

说到共情，最深刻的案例来源于育儿界。咱们一起看一个案例，是一位妈妈和女儿之间的对话，相信几乎所有的家长都会有这样的对话。

案例场景4

“妈妈，我明天不想上学了！”

“哦？”（敞开对话大门）

“上周的考试，我才得了30分。”

“是你说过的那个数学考试吗？没想到只得了30分哦。”

女儿立马放声大哭：“我已经非常努力了！可才考了30分！”

“很努力了才得30分，的确令人沮丧。”（共情，并且中立）

女儿梨花带雨：“我要原来的中文老师！”

“要是她在，你就不会考这么惨了。”（说出女儿的心声）

女儿使劲儿点头，认可老妈的诠释——说到她心窝窝里啦。

“你是因为看不懂题而没考好吗？”（女儿中文阅读不太好，应用题不一定能理解。）

这下子女儿的防卫又自动脱落了好大一层：“老师说话太快了！我根本听不懂！谁都听不懂他说什么！”

然后女儿又抱怨了一堆老师的不是，老妈表示理解。

女儿：“我不上学了行不行？等到下周一再去，行吗？”

老妈：“嗯，这件事于你来说是非常严肃沉重的，一直压在你心口，你一直在纠结，你想停止思考它，却发现自己做不到。”（终极洞察）

小女“是”了一声后沉默。老妈知道这一箭射中了靶心，曙光在望了。

女儿：“我是不是非上学不可呢？”

老妈：“当你特别不想做一件事，可又必须去做的时候，是挺困难的。”（没有直接给判断）

女儿：“我也不是特别不想去，明天有体育课和艺术课。”

老妈：“你最喜欢的两门课，如果不去就可惜了。”（说出感受）

女儿：“我不想错过体育和艺术课。”

老妈：“你感觉很矛盾。”（说出感受）

女儿再次陷入沉默。

沉默良久之后，女儿声音颤抖着，带着哭腔，说：“那好吧，我明天还是上学吧，因为我想上体育课和艺术课。如果中文老师还不好，我星期四和星期五就不去学校了。”

随后，她小哭了两声，表示她提出的这个解决方案是多么令她忍辱负重、委曲求全，她是多么可怜啊！

妈妈自始至终没有直接给女儿任何判断或者指令，取而代之的，是共情和引导。很多时候我们的立场是随着情绪而微妙变化的，所以沟通时的情绪基调很可能会导致沟通结果的迥异。理解和接纳对方的情绪，充分引导对方把问题和情绪表达出来，也就开启了沟通的大门。相反，如果开门见山就给出自己的判断和见解，不仅会把对方的倾诉欲望堵回去，更可能让双方站在情绪对立面上。

当然，仅仅共情，还是不够的。沟通，尤其是项目沟通，大都希望达成一定的目标，如果仅做了倾诉，是无法解决问题的。因此，以共情为基调，需要在陪伴的情绪中洞察问题根源和解决突破口，并适时加以引导。如上例中妈妈所说的“这件事于你来说是非常严肃沉重的，一直压在你心口，你一直在纠结， 你想停止思考它，却发现自己做不到”，把女儿的情绪从负面发泄引导到问题解决的思路上。最后，女儿自己能够找到解决问题的方法，妈妈所做的，只是陪伴和顺势引流而已。

原则四完整解决

和普通的个人沟通不同，项目沟通往往是为了解决项目问题。所以，往往不是一次性的沟通或者和单人沟通就能解决问题的。项目沟通需要在时间维度和沟通对象维度有计划地做拓展，来为解决问题服务。

案例场景5

随着产品的发布和不断取得进展，项目经理小D和测试主管小E都看到回归测试工作压力越来越大，产品的质量风险也一天天升高，持续集成和单元测试的强化要求迫切。如何来引导团队开始在这方面起步呢？

小D和开发团队负责人沟通，获得了加强持续集成的认可，但开发负责人觉得可能还不到时机开始推行，不过赞同下个版本从最基本的持续编译开始尝试；小E和质量保障部门沟通获得了基础工具和专业指导方面的支持。

在迈出了持续编译的第一步（大约1个月）之后，小D和产品总监沟通了持续集成和单元测试对于产品目前和未来的重要性，得到了总监的基本认可。同时也获知需要充分平衡产品交付节奏和额外的持续集成精力付出；小E给开发团队做了持续集成方面的基础分享式培训，让大家对为什么要做持续集成以及可以如何做形成了初步概念；小D和小E又多次和开发团队及其负责人进行了沟通，确认了逐步引入和保障单元测试的方式；随后，基本的持续集成框架和集成状态广告牌开始使用了，持续集成状态也被包括进了项目日常状态公告中……

完整解决，并不是具体的沟通技巧，而是如何完整地安排沟通以及使用不 同的沟通方式来解决问题。项目中，很少有仅凭一人之力就可以解决的问题，尤其是策略性、方向性的问题。需要我们有目标、有计划、有耐心，以积极的心态去面对整个沟通和推进过程。

要做到完整解决，首先要有强大的愿力和强大的内心。愿力，是根本驱动力，是对目标的期待强度。完整解决的过程往往漫长，坚定的决心可以陪伴我们坚持到底。强大的内心，是耐心，是韧性。过程中一定有挫折，一定有起伏，强大的内心可以给我们积极的心态和越挫越勇的精神。

其次，要有敏锐的洞察力和审时度势的能力。问题的解决方式有很多种，需要看清问题的根源和不同角色对问题的影响力及作用，也要看到不同时期不同人对于问题的态度和需求。为什么开发负责人一开始表示认同但无力推进尝试？产品阶段、团队规模、团队状态都是他考虑的因素。为什么会同意从持续编译开始？毕竟不需要团队本身的额外付出，但又可以为未来搭建基本框架。为什么要先给团队做分享？因为团队成员年轻、经验不足，甚至有人完全不了解持续集成是什么。

完整解决，已经不仅仅是沟通的问题了，而是项目过程中持续改进的典型实例。有愿景、有策略、有坚持、有反馈，成为真正的闭环，这样才能使项目和团队在改进中成长。

结束语

沟通的过程，技巧其次，关键在沟通的心态和心境。无论是主动尽早、抓住本质、共情引导、完整解决，真正起作用的都是沟通者的内在修炼和积极心态。

我们经常说换位思考。确实，沟通本是为了解决问题，关键就在于走出小我，从对方从全局来思考问题。当我们“忘我”时，就不会再害怕、再遮掩，也不会纠缠于表面利益是非，这时才可以和对方同探讨、共进退，进而完整圆满地解决项目问题。

沟通，可以修炼吗？不，因为它不仅仅是技巧。沟通，可以修炼吗？可以，因为它正是我们人生修炼的过程！

第2章

高度延伸

在前一章节的基础上，对项目经理们的日常工作做了进一步深挖，从有效管理和提升的角度，思考了各个阶段项目经理们实操工作背后的深层原则和思路，针对一些复杂问题进行了更系统的整理。在这部分末尾，你会对项目管理工作及其价值有更深的认识，也可以对若干个典型问题有更完整的解题思路。

项目启动阶段，项目经理何去何从

文／何燕华

这个项目看起来要团队没团队，要需求没需求，连一个产品经理都没有。简直就是个“三无”项目。顿时小P感到莫名的不安，到底该如何推进这个项目顺利进行？该从何下手？一连串的疑问随之向小P袭来：我应该去找谁要资源？要多少资源？谁有权力决定这个产品的需求？在没有被公开授权的情况下，该如何名正言顺地跟进这个项目？前期主要是需求过程，只有一两个人在干活，那项目该怎么跟进？最终小P是如何破解这一个个难题的呢？

案例场景

接触项目管理两年了，项目经理小P以前被分派的项目都是已经有明确的团队成员、明确的需求、明确的目标，他重点关注的是如何更好地去执行，保质保量地按时完成任务。所以对于需求的确定、团队的建立过程都没有什么概念，也没有太多的思考，当然也怕自己被要求去跟进那些什么都不确定的项目。但很不幸，正如墨菲定律告诉我们的那样，怕什么就来什么。突然有一天他的直属主管项目管理总监找到他说：“小P啊，产品总监老C有一个新的项目要做，半年内要完成上线，你去帮他跟进一下这个项目吧。”

接到这个任务，小P一头雾水，这样算是被授权了吗？这个项目看起来要团队没团队，要需求没需求，连一个产品经理都没有。简直就是个“三无”项目。顿时小P感到莫名的不安，一连串的疑问随之向小P袭来：“到底该如何推进这个项目顺利进行？”“我该从何下手？”“我应该去找谁要资源？”“要多少资源？”“谁有权力决定这个产品的需求？”“在没有被公开授权的情况下，该如何名正言顺地跟进这个项目？”“前期主要是确定需求过程，只有一两个人在干活， 那项目该怎么跟进？”最终小P是如何破解这一个个难题的呢？

团队组建

产品总监只是说了声要干活了，但是却没有给资源，小P的第一步就是去要资源。但是该要多少呢？小P不熟悉这类产品，没法给出预估。于是他找到了产品总监手下一个资深的开发人员，经过与这名开发人员沟通之后，基本上确定了交互、开发、测试等资源的数量。接下来就是要资源了。这个项目是产品总监亲自发起的，理所当然问产品总监要资源了。但是产品总监又不直接带交互、开发和测试人员，于是小P召集了产品总监、交互负责人、开发负责人、测试负责人一起碰头明确项目的目标和上线时间以及关于资源分配的问题。产品总监向大家介绍了一下他做这个项目的目的，并且表示项目要在6个月后交付上线，让各负责人提供资源上的支持，当场大家都承诺会提供资源，并且确定了产品经理，但是对于资源的到位时间都无法保证。不过总算是有对应的责任人了，为后续的工作开展奠定了基础。

解读： 其实在要资源之前，小P等了一个礼拜，因为他觉得产品总监既然要做事情，总得给资源吧。但是一个礼拜过去了，产品总监什么动静也没有。小P只好硬着头皮主动去向产品总监要资源。其实很多时候产品总监是不会主动来问你要不要帮助的，只有自己拿着需求和依据去找产品总监，产品总监才会给予支持。

自我授权

小P是从自己主管那儿接到项目的，虽然是经过产品总监默许的，但是并没有在公开场合宣布他成为这个项目的项目经理，其他人并不了解他的角色。在最前期跟进的过程中，每一次跟新的团队成员接触都要向其解释一下自己的角色。小P总觉得很别扭，因为没被公开授权，如果一直以一个不明不白的身份跟进项目，不仅给团队成员带来困惑，也不利于开展后续的项目管理工作。小P左思右想，觉得不能继续做“黑户”呀，产品总监不授权，那是不是得自己找机会跟大家说明自己是经过产品总监默许的、而且必须在产品总监也在场 的情况下。于是才有了小P自我授权的过程。那天，小P借着前期的一次已到位人员碰头会向大家做了自我介绍并说明了自己以后会跟进这个项目。他说完，产品总监也应和道：小P后续会帮忙跟进这个项目，大家要全力配合。大功告成，从此小P告别了“黑户”！

解读： 与要资源一样，产品总监真的不会管你缺什么，我们必须自己去争取项目需要的东西。

需求可视化

过去小P在跟进项目时，对于需求制定的过程跟进得比较少，因为需求一般是产品经理或者策划人员一两个人的工作，只是让他们给定一个预期时间，到了时间去跟进一下是否完成就行了。但是这样的后果是，到了时间点，需求制定人员总会说：还没做好，还在想。然后就会一拖再拖，最终将开发和测试的时间给压缩了，有的时候甚至会引起开发人员的不满。这一次，小P觉得是不是需要做点什么来帮助改善这种情况。于是定了每周一次的需求沟通会，各个角色都参与进来，不管需求进行到了什么程度，有多少内容就看多少，大家群策群力来做需求。

解读： 当一件事情被提上议程，它的进度往往会比较快。想象一下，你有两件事情同时在做，有一件事情需要每周给大家展示你的进度，而另一件只需要在截止日期前拿出成果就行，当你的时间不够用的情况下，你会先做哪一件？另外，每周团队一起来评审和讨论需求，会给需求人员带来更多思路，有利于他们更及时地调整需求，同时也会增加大家对需求的认同度。

固定沟通渠道

项目前期，主要是需求制定和一些准备工作，貌似没什么好沟通的。小P曾经也是这么以为的，直到需求文档第一部分发出来以后。当时的情形是，需求发出后，没有人回邮件提出自己的意见和疑问，小P以为这个需求会很顺利地走下去。但是有一天小P无意间和团队成员聊起需求，那个成员马上提出自 己的异议，巴拉巴拉说了一通。这个时候小P才意识到，其实需要给团队一个机会来聊这些东西。于是小P立马召集了一次会议，想不到不只这一位成员有异议，其他成员也有不少疑问和建议。随后团队就固定了每周一次的周会习惯。

解读： 有的时候你不去问，别人是不会主动来告诉你他的想法的。例如，小P需要的需求问题，其实需求制定是由需求人员负责的，在团队成立初期，其他人可能不会主动表达自己的意见，一方面，是怕得罪需求人员，另一方面，不是自己的东西，也懒得去提意见，做得不好也不是自己的责任。周会其实就是给了他们一个沟通的平台，每周给团队成员一个机会来相互沟通。也许这也是那些周会、月会、双月会等看似形式化的东西存在的意义。

项目的启动阶段，由于需求和计划都还没定，有的时候甚至连团队成员都没定，自然它的不确定性要比其他阶段大很多。一些项目经理可能对这个过程跟进得比较少，但是并不表示这个阶段不需要项目管理，正所谓好的开始是成功的一半。以上几点小P的经验之谈希望能给大家带来更多的启发。

产品初创阶段，项目管理该做些什么

文／何燕华

产品在初创阶段往往具有这几个特点：需求变更多；产品亟待市场验证，所以迭代节奏非常快；各方面资源都受到限制，尤其是人力方面的资源。虽然项目管理技能具有通用性，但是面对这些特点，仍需要做一些个性化的处理。本文将为大家展开探讨几个比较适合产品初创阶段的项目管理方式。

产品在初创阶段，项目管理在其中应该扮演什么角色，该起到什么作用？采用什么项目管理技术？要回答这些问题，我们先来看看产品初创阶段常有的几个特点。

（1）开发过程中的需求往往变动较多。互联网产品本身的需求变更较其他 行业产品会更多，初创的产品更是如此。因为新产品的需求都是在摸索中不断调整和优化的，没有哪个产品经理能拿捏得非常准确。

（2）较多需求亟待市场验证。一个新的产品，虽然或多或少业界也有类似产品可供参考，但是想要做得好必定要有几个独特的亮点功能，这类需求谁都说不准市场对它的反映会如何，就需要尽快通过市场去验证。

（3）缺人缺人缺人，时间紧时间紧时间紧。关于这一点多说无益，你们懂的。

在这样的产品背景下，项目管理必然需要根据这些特点做相应的调整来达到一个平衡，以最低的成本产出最大的价值。为此，除了常规的项目管理工作，我们在工作特别注重了以下几点。

尽量缩短迭代，尽快交付成果

不管是老板，还是策划者，其实在初期对自己的需求也不是特别有底，更多的是参考竞品然后加上自己的创意。所以我们要做的就是尽快把策划的东西做出来，面向用户去验证自己的想法。我们的做法是：1.0版本上线前，我们每两周一个版本做出一些可见的东西，并且提交给偏用户的内部角色，如运营部，来体验产品的功能，并且提出反馈。阶段性地再邀请公司内的非本产品的人员来体验和反馈。反馈的部分后面一节会重点提到。1.0版本上线后的一段时间内（约2个月），我们以每周一个版本定期上线的模式进行发布，虽然这样的方式会增加一部分组内成员每个版本的评审工作、上线等成本，但是我们更看重我们的功能能更快见到用户，所以前期还是愿意花这部分成本的。等到产品基本成型，需求变更没有那么多的时候，再将版本的周期拉长。

建立通畅的反馈渠道

很多人都说互联网产品要快，但是如果没有建立合适的反馈机制，盲目地快，那只会死得更快。我们不仅要快，更重要的是要反馈快速，所以反馈是我们非常重视的环节。这里说的反馈有两个层面：第一个层面是内部用户反馈；第二个层面是外部用户反馈。

1．内部用户反馈

内部用户又分为两类：一类是团队内部的运营人员，因为我们的运营人员本身是一群产品的目标用户，他们也是最接近用户的人；另一类是公司人员。前期研发过程中，每两周的版本结束，我们都会以集中会议的形式收集团队的运营同事的反馈和意见（其实我们尝试过用文档的形式，不过最后发现还是集中会议的形式更加高效）。我们会在一个大版本结束后，邀请公司内部的目标用户过来参加试用，帮助我们发现Bug，反馈建议。有的时候还会邀请一些专家，如QA或者设计师，从他们专业的角度帮助我们做一些改进。

2．外部用户反馈

外部用户反馈也可分为两类：一类是上线前的可用性测试，另一类是上线后运营整理的每周用户反馈报告。

（1）可用性测试。可用性测试是由专业的用研同事帮忙进行的，他们会邀请一些产品的目标用户，做一次深度的试用和访谈，主要侧重在用户体验和需求设计上的反馈。他们会记录用户的反馈以及梳理出修改的建议给策划。策划会视反馈的轻重缓急决定是否在上线前修改。

（2）每周用户反馈报告。运营同事会每周整理用户反馈，并且发出报告。策划同事会负责接收这部分反馈，并且回复如何应对这些反馈。这样的形式会让用户的反馈以较快的速度触达策划，从而影响接下来的需求设计。

工具轻量化

1．任务管理工具轻量化，有道云协作＋JIRA

产品研发初期，团队还没有那么大，同时速度又比较快，所以在任务管理工具的使用上会考虑尽量轻量化，来减少不必要的浪费。我们的选择是：

（1）我们推荐将需求细化，所以每个需求都有对应的任务。考虑到每个任务都建JIRA的成本不低，所以想了个简化的方案，用有道云协作的表格做任务管理。每一行是一个功能点（功能点足够小，一般开发工作量在3天以下），每一列是不同角色的任务，对应的格子中写上该角色针对该任务的工作量（主要针对开发和测试，视觉或者交互会列截止日期）。如果一个角色有多人，则 在对应的格子里标注对应的人。格子的颜色表示任务的状态：红色表示未开始，黄色表示进行中，绿色表示已完成（见图2-1）。

图2-1　任务管理表

（2）Bug考虑到后期需要统计分析，所以接入JIRA。为了方便大家查看，定义了Bug的仪表盘（dashboard），会罗列出目前版本所有未修复的Bug，这些Bug按人分的情况以及按优先级分的情况。在版本后期集中攻克Bug的阶段，会罗列当天需要修复的Bug。

2．文档轻量化

首先，初创阶段本身的需求和设计的调整会更频繁，花了大量精力写了文档后，后续产生变更又要重新更新文档，这会花费大家不少精力；其次，有了文档，不同的人对同一份文档的理解可能又会不一样，为了确保大家的理解一致，还是少不了当面沟通的成本；再次，初创阶段，团队是新成立的，其实大家非常需要面对面沟通的机会，来增强相互的了解，形成默契，为后续的合作奠定基础。所以我们的需求文档和设计文档都省略了，需求会以交互文档的形式，通过集中会议传递给开发团队，一些规则说明就直接标注在交互文档中。需求阶段策划会与相关人员确认可行性，最终所有开发人员确认的是交互文档。设计文档也会省略，只会定义接口文档，用于不同角色之间的协作。具体的设计更多的是以面对面沟通的形式完成，一些流程实在需要文案来记录，则会用简单的形式记录在维基上。

全员招聘

产品初期，经历过的人都知道，真实的状态就是人少、活多、时间紧，所以招聘是其中非常重要的一项任务。“国家兴亡，匹夫有责。”同理，招聘主要是主管的事情，但是招不到人，现有团队的同事就会更辛苦。所以一定程度上，我们团队全员参与招聘，大家有资源的就拉过去的同事、同学内推，没资源的就帮忙筛简历面试，团队3个月时间就从几个人迅速增加到30多人。

以上这些是我们团队在从无到有、从小到大的过程中尝试的一些方式，我们从中获益良多，但我们知道这些方式并不完美，也一定不适合所有的团队，只希望能给大家带来一丝灵感，从而定制出属于你们的最佳实践。

项目初创期，如何帮助项目走上正轨

文／张孙恩

当新创一个项目时，什么流程都没有，项目经理该如何让团队高效、有序地运作起来呢？本文介绍如何帮项目从0到1建立起规范流程，分享在猛犸与有数两个项目中；如何一步一步导入流程，从文档架构、常见流程、执行与监督、搭配工具到经验转移等步骤。我们的建议是流程从轻做起，而且项目经理可以与QA合作推动流程；流程要常保动态、经常更新。

初创项目的问题

当我们身处一个新创项目、新创公司时，一开始只有一个小团队，大家的协作靠着默契或口头上的沟通与交流就行了，没有什么规矩、流程。一开始看似没有什么问题，但是随着团队逐渐扩张、产品开发越来越复杂、业务逐渐增加等情况的出现，伴随而来的问题也越来越多。我的很多项目都是从新创阶段带起的，就遇过或听过以下状况：设计文档没写，测试不知道如何测；上线各模块负责人随意上线，导致线上不稳定；策划天天改变需求，最后开发测试一 团乱；到了约定的提测时间，质量却不好，增加测试工作量；某个需求到联调当天才发现有模块不知道也要做……遇到这些问题时，项目经理该如何帮助大家走向正轨，营造有序的工作氛围呢？这时候就需要适当建立一些流程，来提升大家的协作效率。

什么是流程

制度流程可以看作人与人之间合作的游戏规则，由于身处在团队合作中，需要跟大家一起协作来完成项目。因为每个人的工作习惯不一样，有时候会产生摩擦或者问题，所以我们就需要约定一个共同遵守的流程，并结合之前的经验教训归纳起来，避免下次再犯错，这就是制度流程。传统行业也会把制度称作标准作业程序，因为公司规模大，希望所有人能像机器一样一步一步照规范执行，减少自我判断、减少错误机会，达到最大限度地控制。而互联网公司其实都是很新、很年轻的公司，比较强调个性化与创造性，如果太多条条框框，可能就会错过市场先机，所以对流程的约束与掌控就比较少。

流程就是沟通

如果人少、合作有默契，是不需要很多流程的。大家沟通、合作出问题了，需要有流程来规范。我们需要有一个规则，明确责任归属，但是还需要有取舍，如果流程太多又会过于死板。流程是为了提升效率，终究是为人服务的，而不是人被流程制度所掌控！所以一味照着流程来做，很可能会流于形式，那流程存在的意义就会大打折扣。

当项目处于草创期或团队小的时候，靠着大家彼此默契或约束，不用制度也能运转得很好，效率也很好。但是随着项目不断成熟、团队变大，就得靠更多的制度来规范流程，减少沟通成本，提升整体效率。需要多少制度和流程，这个度自己要仔细拿捏衡量，过犹不及都不妥。

项目初创期该如何建立流程？

我经历的几个大项目都是从零开始的，如网易猛犸、网易有数等。流程是 从轻做起的，一开始其实不适合把一整套很重的流程搬过来套用。通常是有遇到相对应的问题、有新的业务、新的团队出现，才考虑建立流程。举例来说，如果产品只在开发周期，把用户管理、运营推广的制度流程建立起来，用处不大，因为可能连运营这个岗位的人都没有，这些流程也只是摆着好看。通常是遇到问题真正痛过，大家才会了解为什么需要建立这个流程，此时推行相关制度才会比较顺利。

制度管理从文档管理起步

一个好的制度，需要让团队很容易找到且条理清晰。所以在建立项目的文档库时，就应该跟着流程来建立结构，方便大家查找。最早的时候制度少，每个文件夹按照流程建立，制度就放在各文件夹第一页。

随着制度和流程越来越多，维基页面也越来越繁杂，我们感觉需要有个统一的地方放制度流程，所以我们就独立出来一个文件夹，把所有文档按照顺序排列，让新人一上岗先学习，也方便大家更快找到。图2-2是我的两个项目的文档库结构。

制度从轻做起

一开始我们只是进行了简单划分，如各流程文档谁负责，该输出什么，最关键的需求、设计、计划文档该如何签核（见图2-3）。

一般来说互联网项目会随着项目成长经历这些环节：需求、交互、设计、计划、开发、提测、上线、hotfix、解决线上事故、日常运维、运营等，每个环节可能都是独立的岗位，人与人协作就会出现问题，这时候就需要流程。图2-4是我根据整个项目流程画出的总体主流程图。

图2-2　网易猛犸与网易有数两个项目文档库目录

图2-3　项目流程规范简单版

图2-4　总体主流程图

常见的流程主要有：

•　需求管理

•　变更管理

•　提测流程

•　测试流程

•　上线流程

•　hotfix及线上除Bug流程

大家注意到了吗？通常这些都是比较容易混乱的环节，需要有相对应的流程加以规范。例如，变更在开发过程中很常见，当开发人员发现一个问题就会与产品经理讨论，然后调整一下设计，但结果交互、前端、QA、PM都不知道，而且变更增加了工作量且导致进度延误。当踩过坑，大家都觉得很混乱时，就可以抛出一个流程的建议，让大家一起讨论。以下是变更流程的范本：

（1）产品策划或开发针对需求与设计有变更，发起人要先与产品策划讨论，确认是否变更，并确认方案（有个初步交互稿或交互设计）。

（2）召集总负责人（可选）、策划、项目经理、交互、视觉（可选）、相关模块负责人、QA召开需求讨论会（看变更大小，采用会议、站会聚集讨论等形式）。

（3）各方确认是否同意变更，策划建立JIRA追踪。

•　变更多或重大，影响工期，还需要邮件群给开发组邮件群。

•　变更小，JIRA跟踪即可。

（4）JIRA依流程走，即待交互稿、视觉方案确认后（可选），交给前端或相关开发人员。

流程执行与监督

流程定出来很简单，但是该如何执行？建议有以下几个步骤：

（1）取得共识。应该要和项目负责人甚至上层总监、各负责人等确认这个流程是大家都同意、愿意遵守的。有时候流程是跨部门的，那就需要相关干系人一起参与讨论。如业务部门（云音乐）向服务部门（大数据组之搜索与算法） 团队提需求，这时候需求管理的流程，就需要双方一起确认。

（2）发布通知。建立好维基文档页面，并且发通知邮件给整个团队。

（3）详细解说。可以在周会上，完整地把思路向团队说明宣导，并确保大家都没有意见或疑问。

（4）执行与监督。平常需要以身作则，确保每个环节都有照着流程进行。当发现有工作没有照着流程来做，应该先了解原因，然后让大家修正依照流程执行。最后可以发出邮件、POPO来提醒大家，顺便再把流程的链接放上去。

流程需要搭配工具

流程前面说过就是一种沟通机制，所以应该搭配各种沟通渠道，如会议、邮件、JIRA、POPO等。当然最正式的就是大家一起召开会议，一起确认流程的环节或文档。比较轻量级的是发出邮件，避免每次一大堆人花很多时间开会，但坏处就是可能有些人不会注意邮件。当然借助项目管理系统，JIRA可以起到很好的追踪与邮件通知的效果，而且大家可以很清楚地找出记录，任务的流转也可以结合JIRA里面流程的变动，这是更清楚、不遗漏的方法。即时通信系统（如POPO）当然可以即时广播给大家，但信息一多可能被漏掉，管理历史记录也比较不方便。选择好适当的工具，能让流程自己转起来！

项目经验移转

猛犸大数据平台是我的第一个项目，项目团队都已经合作很久了，彼此比较熟悉。而网易有数团队，有很多新加入网易的同事，是一个很新的团队，所以很多流程我都会先在“猛犸”做尝试，当在“猛犸”用起来比较成熟了，就可以移植到“有数”项目，再做微调。这样一次一个项目地推动，好处是比较稳定，当有坑可以先在“猛犸”踩过，然后推行到“有数”上就比较顺利了。

另外给些小建议，大家其实也可以在维基上扒信息，看到成熟的项目有不错的流程制度可以借鉴，我当年也参考了教育产品、URS的资深项目经理所建立的成熟流程，省下了自己跌跌撞撞的过程。要注意，很多项目是因为业务的独特性，才形成自己的流程，不可以一味照搬，而是需要裁剪以使其适合自己 的项目。

总结与心得

（1）流程应该从轻做起，新建项目要建立流程。一开始大家不希望受太多流程的约束，因为会很麻烦，也会限制一部分弹性与创意。从整体面上看，当然流程越多越规范，但在新创团队中，流程一下子太多会让大家吃不消，引起反弹，造成反作用，得不偿失，所以不能心急，一定要循序渐进。

（2）项目管理在推动流程上，可以跟QA紧密合作。因为QA其实也很重视过程质量，而且许多流程其实都需要QA参与。举例来说，上线流程、hotfix流程、提测流程等，很多都需要开发与测试环节之间相互约定与协调，所以一起推动能有助于产品质量提升。

（3）最后，流程是动态的。不是制定完了就永远不用调整了，它也需要敏捷迭代，如果发现流程不适用或者有更好的解决方法，就应该调整，这样才能保持灵活性。如果流程一直不调整，大家渐渐觉得流程已经过时，就会逐渐不遵守流程了。流程不断优化，能提升大家工作效率，让协作更顺畅。

欲速则不达——冻结制度小谈

文／吕广川

受渠道发布流程（苹果应用商店一般至少需3～5个工作日审核，安卓渠道一般1～2个工作日审核）和移动端设备中更新策略（系统自动更新、用户手动更新等）的影响，一旦客户端版本出现重大缺陷问题，仅仅靠更新客户端版本往往无法立即解决问题，很容易影响用户使用，并可能给公司造成一些不必要的损失。我们是如何解决这个问题的呢？且与笔者一起深入了解。

欲速则不达，一味追求速度，性急求快反而不能达到目的。在实际的项目运作过程中，经常会有要快速响应变化，要快速做出产品决策，要快速完成开发，要快速完成测试等要求。一味追求快，往往容易忽略事物本身的发展规律，甚至因为过快导致各环节质量下降，后期疲于奔命等。笔者主张追求淡定从容、忙而不乱、张弛有度、高效可持续的工作状态。单次迭代内适当克制，小步快跑，让长期目标得到更快响应、更快见效等。冻结制度是迭代内可用的一个不错的小工具。

在互联网产品中，无论是网站前端还是网站服务器抑或移动端版本，都或多或少会遇到一些变来变去令人抓狂、需要克制的时候。移动端项目的交付产物以客户端版本为主，配合WAP页面、H5页面及后台服务器等相关支持。受渠道发布流程（苹果应用商店一般至少需3～5个工作日审核，安卓渠道一般1～2个工作日审核）和移动端设备中更新策略（系统自动更新、用户手动更新等）的影响，一旦客户端版本出现重大缺陷问题，仅仅靠更新客户端版本往往是无法立即解决问题的，很容易影响用户使用，并可能给公司造成一些不必要的损失。在互联网产品中，相对于网站前端等，移动端项目更需要关注质量。下面笔者将从移动端入手谈一下冻结制度。

移动端项目的冻结

以某电商移动端项目A为例，预估迭代周期为一个月左右。有个购物车模块相关的需求涉及客户端、WAP页、后台、主站等多方面及各种接口定义联调，同时可能还涉及支付模块的配合。倘若该需求产品方迟迟没有确定方案，改来改去一直等到迭代中期才给出需求方案进行初步评审，那么留给开发测试的时间将只有不到两周。技术团队还要协调各方接口联调，协调类似支付模块等其他第三方。单就这一个需求点的延误就可能产生较高风险。万一此时推广计划已敲定了，例如已和苹果约定申请推荐位等，提交审核时间必须某日进行，情况就更复杂了，很有可能出现开发到最后一天才完成代码稳定。距离提交审核只有几个小时，测试同事才拿到与用户要使用的完全一致的客户端版本，很难保证所有隐患都能排查出来。就算此时排查出问题，恐怕也没有时间去纠正 了，要么硬着头皮提交，要么错过约定好的推荐申请。

下面具体聊聊如何尝试需求冻结和代码冻结两个措施来预防这种局面的出现。

需求冻结

在快速迭代的项目中，单次迭代的需求可分解为细粒度。为了更快速完成交付，在一个迭代期内需求不可能无休无止地改来改去。需要适当冻结以满足快速交付的要求，为下次迭代中快速响应新变化留有余地。有一点需关注，需求冻结指的是影响迭代交付等的需求冻结，并不是拒绝变化，具体需要团队自身去评判。例如无节制、无节操的需求蔓延和需求变更则需禁止，再例如，迭代进行中因外界突发情况特别是法律法规等政策因素导致需求变更，则团队可自身评估，尽量去拥抱这个变化，同时降低风险。

仍以某电商某移动端项目A为例，只有不到一个月的研发周期，团队承接了看似不可能完成的大量需求。项目启动第一周，完成需求评审并进入需求冻结。迭代中后期也没有频繁大块需求改动困扰，有零星的改动也都在可控范围之内。团队在迭代前期第一周就已开始技术方案评估，产品、开发和测试同事协调碰头，确认配合进度安排，包括诸如购物车功能等所有模块，团队成员也都已清楚自己的工作安排及时间节点。无论是接口联调还是与支付模块依赖，都可以在接下来的工作中定期确认进展，游刃有余地展开工作。

代码冻结

冻结代码，代码另起分支准备发版之用，但并不是完全停止代码更新。允许谨慎可控的缺陷修复等。需特别强调的一点是，代码冻结期，原则上禁止新增任何需求或者任何调整功能点的开发任务。

仍以某电商某移动端项目A为例，团队在迭代结束前三天完成所有代码稳定工作，并另起分支，冻结代码，给出将要提交审核的客户端版本。在这三天时间里，测试同事继续各种测试，同时邀请公司内同事安装试用，对之前缺陷大扫除暴露的问题进行验证。线上服务器也按要求部署上线，客户端完全满足 最真实用户体验要求。倘若此时真的发现问题，评估结果为必须加以修复，则此时还是有时间去争取的。但须注意一旦代码冻结，所有修改必须经过慎重评审确认后再提交。最终，该版本在紧张刺激中顺利完成，也成功通过了苹果审核和各安卓渠道审核。

代码冻结并不是时间越长越好，而要顾及整体的迭代进度，尽量在一个月的迭代周期内以合理的时间、成本去执行代码冻结。具体冻结期长短取决于团队自身情况。对于从未做过代码冻结的移动端团队，建议月度迭代末期至少能争取临近发版前三天冻结代码。

制度补充

项目排期中，需求冻结时间点和代码冻结时间段建议列入时间轴中，直观体现，如图2-5所示。

为保障冻结能有效执行，需做好以下准备工作。

（1）需求。需求冻结的前提是需求的质量足够高，建议将需求评审拆分。小评审，尽可能点对点沟通，为避免过于分散影响研发效率，可以考虑集中每周二、周五两个晚上进行小评审。大评审和最终需求确认会，意义在于将全局信息传递到全体项目组成员。确认会后进入需求冻结。

（2）代码。代码冻结只是保障版本质量最后的几道屏障之一，不能把所有的质量都寄希望于代码冻结阶段去解决。建议重视平时的提测质量及开发自测等。代码质量重在平时习惯养成，等到最后需要代码冻结时再重视就晚了。

（3）规则。冻结后异常情况处理的规则需提前明确并广而告知相关项目组如超过需求冻结点、有需求的变更或插单等，技术团队不得私下接单，要走申请流程并告知相关人员等，同时需明确，如果破坏规则导致相应的后果该如何承担等。

图2-5　排期计划时间图

题外话

为什么看似简单的事情，还要制定一个制度？道理很简单，因为口头约定只局限于当事人之间知悉，持续性较差。另外遇到特殊情况时，口头约定效力低，往往还得再费一番口舌去解释等，甚至有时口头约定会流于形式没人在意。而形成一个简单的制度约束，比较直接的一个好处就是可以降低沟通和认知的成本。有相关的材料介绍，有约束并广而告之，久而久之就会形成一些规范和默契，从而达到单次迭代内适当克制，长期目标得到更快响应、更快见效等效果。

结束语

所有的制度终归还是为项目服务的，当项目情况发生一些改变，制度已不能满足需求时，制度本身也可以改进迭代。总之，在不断磨合中前进，在不断沟通中成长，该冻结就冻结，该拥抱变化就拥抱变化，最终目标是项目成功交付并走向产品成功。

当所有需求，涌向我的时候

文／曹智清

我们该“拥抱”变化，而不是拒绝变化；我们对于变更的基础需求是要记录它，以便角色间同步；我们愿意克服困难去接纳那些很有价值的变更；对于影响巨大的变更，我们需要谨慎讨论和评估。

也许，我们已经习惯了需求排山倒海而来的日子。每个团队都有自己的方式去消化延绵不绝的需求。高大上地说，这是需求管理、变更管理；接地气地说，就是让我们了解一下怎样判断需求做与不做，以及哪个先做。

来自一线的实况和感悟

给项目经理们提了两个问题：你的项目是如何接受新需求的？你的项目是如何应对需求变更的？十几位一线互联网项目经理逐一回答之后，我们得到了如下信息：

（1）几乎所有的项目在需求管理上都不是强流程，而是用适合各自的办法来形成研发排期。

（2）需求管理的承载形式主要有两种：JIRA中的Backlog或Redmine中的任务列表，维基中手动维护的需求列表。不少团队的列表内容和维护方式，都经过了多个迭代的优化调整。

（3）产品主导的项目中，需求管理的负责人往往是策划团队（产品经理团队），这种情况下需求管理往往较为和谐。主策通常会设立策划内部的评审讨论机制，来给出经过整理的需求列表。

（4）运营力量较强的项目中，需求的决策往往需要由产品总监、主策、主运营以及项目经理所组成的核心团队来共同讨论确定，这种情况下往往多了些纠结争论，有时需要经过多次协商才能得到结果。好处自然是可以更好地平衡运营需求。

（5）对于变更，一部分项目采用了分类处理的方式：对于大部分中小粒度的变更，进JIRA记录并发大群通知，直接执行；对于重要变更，建立控制委员会（包括总监、主策等）进行评估把握。其他部分项目，采用了简单的负责人审批方式来应对变更；更有少数项目，几乎对变更不加控制，交由一线团队自我决策。

（6）对于来自高层的需求或者变更，往往拥有较高的优先级。

存在即合理，不过我们依然通过讨论得到了一些建议：

（1）流程可以不强，但不可以模棱两可或者朝令夕改。所以，无论是需求还是变更管理，都建议项目经理做一些抽象提炼，形成适合团队的方法，并做记录和传达。

（2）这里更关键的是人，而非流程本身。需求和变更的决策，谁或者谁们来负责？一旦这个问题落实清楚了，这些人本身也会制定和改进决策流程。

（3）能够让人有效运转起来，不仅要职责到位，更需要一些基本原则和理念的统一。比如，对于需求，“产品当前的重心是什么？”这就是判断需求优先级的重要来源。再比如，对于变更，有的团队认可“用户体验第一”原则，有的团队综合考虑“需求方、变更代价、上线风险”等因素。

（4）需求管理是产品流水线的源泉，也是研发项目最大浪费的根源。项目经理往往容易直接跳入了“排期”的宿命，而忽略了对于需求的反复斟酌。

（5）变更管理不是一成不变的方式和准则，它要随着产品生命周期以及重点诉求的变化而变化。所以项目经理要经常审视变更带给产品和团队的影响，适时加以引导，激发团队持续改进。

变更管理由形入神

先来讲一个真实的变更管理演变的故事。

早在2012年，网易云课堂的第一个内测alpha版的回顾会上，大家投票亟待解决的问题就是频繁的需求变更。于是诸如所有变更都要进JIRA、确立冻结制度等改进措施应运而生，甚至讨论了类似按钮颜色变化的变更也需要进JIRA这种极端的问题。

一个版本之后，Beta版回顾会上，我们重新审视了这个问题。大家热烈讨论了如何看待变更的问题：在产品初期，形态未稳，需求变化剧烈，我们是否应该更主动积极地拥抱变更，而不是去拒绝变更或者为变更设置过高的障碍？而底限的标准则是对变更加以记录和组内同步。

经过了三年多的不断调整适应，我们已经不会再过多纠结于变更流程本身，而会去探究变更的价值和必要性。对于显然对效果有利而又变化不大的变更，开发测试的同事有着相当高的配合度，即便已在预发，也积极配合来调整文案或布局效果；而对于重大变更，又会及时组织讨论，确定影响程度以及解决方案。

由此，我在思考，什么是变更管理的本质？什么又是项目管理的本质？

有人觉得，项目经理就是来建一套流程规范的；也有人觉得，项目经理来了就可以把所有单个职能外的工作都丢给他……确实，我们经常从一头扎入项 目开始做起，也会天然地与“流程规范”挂起钩来，但是真正之于团队有益的并不是一套运作框架，而是激发团队内在的思考力，培养和统一这个团队对于基本问题的看法以及应对思路。比如，我们该拥抱变化，而不是拒绝变化；我们对于变更的基础需求是要记录它，以便角色间同步；我们愿意克服困难去接纳那些很有价值的变更；对于影响巨大的变更，我们需要谨慎讨论和评估……

这就是做事的习惯和处事的原则。一切流程规范，都是在这些基础上应运而生的。也只有如此，流程规范才不因僵化而惹人厌。

回到需求和变更管理上来，变化是永恒的，找到不变应万变的方法是我们所努力的方向和本质。

我们如何赶上工期

文／何燕华

项目经理常常会遇到这样的困境：项目交付时间被定死了，但是基于现有的资源完成项目几乎是不可能的。遇到这样的情形，我们难道就束手就擒了吗？幸好，我们有神秘百宝箱来拯救我们。本文就让我们来看看项目经理的神秘百宝箱中都有哪些宝贝，它们是如何拯救项目于水深火热之中的。

接触互联网项目管理以来，团队经常遇到这样的困境：老板已经把项目的交付时间确定得死死的，完全没有商量的余地。但是项目团队经过初步估算后发现，就当前的范围、资源、质量要求而言，完全没有可能按期交付。相信这样的情形也同样困扰着其他一些项目经理。我们是如何应对这种情况的呢？我们该做些什么？加班、加人？也许这些都是方法，却都是非常规的，在笔者所在的团队较少将这些方式作为项目计划的一部分，原因如下。

（1）加班。一方面，在弱矩阵项目结构的组织中，项目经理没有绝对的权力要求团队成员进行加班，即使项目经理将加班视为解决时间紧张的方案也未 必能够实施；另一方面，团队成员的工作是一个持续的过程，一个项目结束后就会马上有另一个项目的任务，成员在加班的状态下会消耗比平常更多的能量。这与人在跑步的时候一样，突然加速快跑冲刺肯定消耗大量体力，但是能量总是守恒的，一般在加班过后，团队的士气和效率都会处于较低的状态，而且这个状态会持续较长一段时间，势必影响其在下一个项目中的表现。

（2）加人。一方面，在项目需求已经出了初稿的时候再去招人是比较困难的事情，人员的到岗速度并没有那么快。就算不需要重新招人而是从其他团队调人，也并非易事，因为该人员必须在技术上很适合该项目，而且有时间过来协助。另一方面，新成员的加入，会增加不少沟通成本，理论上讲，一个原来有n 人的项目，每增加一位新员工就会增加n 条沟通渠道，这势必会增加一些沟通成本。我们平常也经常说1个人两天完成的工作量往往大于两个人一天完成的工作量。所以这种方式也不作为我们处理时间紧张问题的常规方式。

那么我们是如何解决这个问题的呢？在笔者所在的团队通常会考虑下面一些选择。

1．需求调整

一般项目都有关键约束因素和浮动约束因素。关键因素是决定项目是否成功的因素；浮动因素是指可以调整的重要影响因素。在时间作为关键约束因素的项目中，范围就成了可浮动的一部分。我们会重新回顾需求文档，根据需求的优先级，重新划定本里程碑的范围，将一些锦上添花的功能先拿掉，剩下主体功能。在互联网的项目中，产品经理或者策划在定需求的时候可能只是按照他们的期望定了范围，他们总是希望在最近的里程碑将所有需求开发完，往往有一些需求并没有那么迫切，对用户来讲可能也无关紧要，不需要非得在本里程碑完成，完全可以将这些低优先级的需求放到下一个里程碑完成，或者本里程碑可以完成这些需求的简单实现，在下个里程碑进行完善。

2．小迭代开发

在顺序开发的项目中，若时间不够充裕的话，往往测试的时间就会被压缩，最后导致测试不充分，产品的质量不过关，测试期Bug“绵延不断”，交付后仍可能出现严重的Bug。为了避免这种现象的产生，时间比较长（3个月及以 上）的项目，我们会采取分批提交的方式，将需求分2～3次提交，让QA同事提早介入。在第一批功能开发完成时QA同事就可以开始测试，开发人员此时就能开发接下来的功能。这样就能减少QA同事在开发阶段等待的时间以及开发在QA同事测试过程中的等待时间，提高了团队的效率，缩短了整个里程碑发布需要的时间。如果有可能的话我们甚至可以按功能提交，每完成一个功能QA同事就开始测试。不过该方式下，很多时候开发可能身兼多重任务，修复第一批功能Bug的时候同时开发第二个功能，此时就需要项目经理细粒度地跟进情况，及时发现问题，将开发任务和修复Bug的优先级定义明确。

2．关键路径法

关键路径即该项目中所需时间最长的一条路径。项目之初，理出关键路径，将关键路径外的功能交由一些相对不稳定或者时间不固定资源（实习生、外部人员）去协助完成。这些功能就算不能按时完成，整个项目的提交也不会受到太大影响。这样，更多的资源就能被分配到关键路径上，集中力量解决问题。

3．Bug管理

项目之初，若是时间不充裕，在定交付标准的时候可以适当降低Bug修复的标准。一些修复代价较大且影响较小的Bug可以暂时不修。等到项目进入测试阶段，根据当前的情况，我们会重新评估之前的标准，看是否需要重新调整。关于Bug的优先级重要性，QA同事在报告Bug的时候会有一个初步的判断，经过团队分类后会最终确定下来。那些被“剩下来”的Bug，可以在里程碑结束之后修复，但是这都不会影响到关键功能的使用。

以上方法，均需根据项目组的实际情况剪裁使用，“让你的团队赶上工期”。没有最完美，只有最适合。

大版本下，团队如何完成项目目标

文／曾璎珞

团队成员对项目目标理解不一致，有劲，却没往一处使；周期太长，制订项目计划和日程安排，很难一步到位；最终交付的产品，总是达不到预期。带着这些头疼的问题，与笔者一起探寻解决方案吧。

在长周期、大版本项目中，我们常常被下面这三个难题困扰：

（1）团队成员对项目目标理解不一致，有劲，却没往一处使。

（2）周期太长，制订项目计划和日程安排，很难一步到位。

（3）最终交付的产品，总是达不到预期。

在过去的两年中，我们团队经历了三个移动端大版本开发，过程中不断改进，最终做到按期交付。对于上述三个问题，我们逐渐总结出一些适合自己的解法。

成员对目标理解不一致，有劲，却没往一处使

为了让团队成员更好地理解项目目标，有两点我们一定会争取做到：

（1）团队形成，越早越好。一方面，可以让成员提前接触到产品需求，提出有价值的意见建议；另一方面，成员之间也需要经历一段时间的磨合才能达到默契。

（2）项目目标，尽早明确。举两个例子：

•　如果当前的产品，需要非常注重交互视觉体验，那么，相信团队在研发和质量保证过程中，也会更关注用户体验，并且也相对容易地去接纳这些体验上的需求变更。

•　如果当前版本的目标，是为了满足当前用户的互动需求，用户希望尽可能快地使用这款产品，那么，团队需要更加关注进度，计划中考虑更多的并行工作，甚至赶工。

周期太长，制订日程计划，很难一步到位

1．对于计划是什么，计划用来做什么，我们的团队达成了自己的共识

需要特别注意一点：计划≠承诺。项目初期，对时间的粗略估算，准确度在-50%～+50%；待需求案确认后，估算的准确度可以提高到－25%～25%；待交互稿、视觉风格确定，并经过团队评审和技术调研、任务WBS和任务估算，项目计划的准确度可以提高到-10%～+10%。

因此，团队和产品负责人需要共同意识到，项目计划完成时间点不是单一的时间点，它不可避免地存在浮动区间；项目初期的计划，并不一定准确，却也可以帮助我们提前看到风险，并适时调整项目“时间”、“范围”和“成本”这铁三角。

2．对于计划怎么做，我们也有了自己的答案

（1）项目初期，经常碰面，小步推进。团队在确定产品需求、交互、视觉风格的同时，还穿插了技术预研、底层接口整理、可行性分析、开发环境搭建、项目配置系统设置等工作。这个阶段的工作总是在变化，很难明确地估算，可以尝试用时间盒来约束和推进。例如：团队三五天或者两三天就会同步进度并梳理短期日程的安排。当然，初期状态越混沌，就需要团队越频繁地进行沟通，甚至可以使用每日站会的方式来跟进。

（2）项目日程，渐进明晰。项目日程创建这部分工作，很难一步到位，而且，这样很容易出错。项目初期，项目经理召集主要成员，根据项目目标和历史经验就可以大致推测出项目的主要里程碑。一般情况下，最近一个月的日程安排，可以具体到某一天的粒度；但是，超过一个月的日程，就只能按周或者双周来计算了。

（3）安排项目日程，不求完整，但求实用。渐进明晰地创建项目日程，先细化最近一个月的日程安排；每当一个里程碑完成后，再进一步落实接下来的日程。以此类推，直到获得的信息足够进行完整的日程安排（见表2-1）。

表2-1　项目日程示例

日　期

里程碑

2012年10月×日

项目启动

2012年10月×日

需求评审

2012年11月×日

交互评审

2012年12月中旬

视觉风格评审

2012年12月中下旬

确定研发阶段的迭代周期和次数

……

多迭代交付和评审

2013年3月中旬

邀请特征用户试用早期版本

2013年4月中下旬

提交市场

2013年5月底以前

面向用户

•　适时给出计划。何时才能给出一份相对准确的项目计划呢？一般收集到以下三份资料后，再做任务估算和日程安排，会比较靠谱：

—确认的需求案。

—基本确认的交互稿。—确认的视觉风格案。最后，提供一份我们日程安排的示例，供参考（见图2-6）。

图2-6　日程安排示例

最终交付的产品，总是达不到预期，怎么办？

我们现在的做法是：

•　短周期、多迭代，预留出更多的机会来检查项目中间状态。

•　重视每个迭代的计划和评审，让团队来主导设定具体目标，也让团队来共同审核目标的完成情况。

•　我们并非每次都能做到完美交付，过程中必然遇到各种问题，因此，我们通过回顾会来检视过程缺陷，帮助团队持续改进。

针对以上三点，确定项目目标、制订项目计划，执行直至交付最终产品，其中每一步的解法，都与我们每一位成员息息相关，而我们所沉淀的原则和方法，也是为了帮助每一位成员真正融入产品和项目中，让大家更直观地看清楚产品目标以及项目每阶段的关键所在。当成员看清楚了大版本项目的全貌，项目的推进过程，其实并不那么复杂。

没有什么是不可能的

文／曹智清

项目的时间、范围、质量总是彼此牵制，此消彼长。但现实中，往往给定了范围，同时也敲定了时间底限，当然，质量也是不能出问题的。在此种情况下之下，除了加班，我们能做些什么来达成目标？项目经理该如何维护项目的可持续发展？

“没有什么不可能。”这是一句多么激情四射的广告语，它体现了互联网和移动互联网产业瞬息万变的现状。唯快不破，尤其在这个充斥着各种竞争以及山寨的领域，大家都懂的。这也是为什么我们的身边，总会有许多“不可能的使命”（mission impossible）（上级下达的死命令，确定的最后期限、给定的功能范围，看似不可能实现，得拼了！）。

“不可能的使命”带来的影响

让我们先来看一下“不可能的使命”这把双刃剑。

1．关于产品

大多“不可能的使命”最终会在团队全体一心、夜以继日之后达成，产品由此可以抢占市场的先机。在互联网和移动互联网产业，有时哪怕只是一天的先机也是天和地的差别，对于企业的兴衰存亡至关重要。

回首所达成的目标，我们发现，原来咱们团队有着如此强大的张力，如此看似不可能的任务我们一样能够完成，原来我们是如此的坚不可摧！但是，也应该理性地看到，这是拼搏的成果，是团队牺牲了短期个人生活和休息所换来的。这的确是一种团队的力量，但这并不是可持续的常态。团队和个人效率的提高是一个循序渐进的过程，和经验积累与过程改进有关。短期的、表面的效率高涨，关联的是时间的投入，而不是真实的效率提高。如果长期以此来衡量团队的正常产出，相当于拔苗助长，或者只是美好的假象。

2．关于团队

短期（比如一周内）的加班，对团队的凝聚力和归属感有着很奇妙的增强作用。如果你想让一个团队真正凝聚，组织更多的团队活动未必是一个好办法，因为大家未必有同样的爱好。真正的凝聚，来自让团队一起工作，在工作中讨论、协作、冲突、缓和，一起欢笑、一起奋斗，哪怕是一起抱怨。

但如果加班超过一定时间，或者时间压力过大，那么这种奇妙的增强作用就会迅速被负能量所替代。

每个人都是有血有肉有个性有情绪的，我们日常在工作中，虽然也有个性的彰显，但往往有所控制和收敛。也许我们会在家人面前发脾气，但是极少对着工作同事如此。而在长期加班的过程中，我们除了睡觉之外绝大部分时间是和同事一起度过的，从概率上来说难免会控制不住地发泄情绪。除此之外，长期的工作压力也容易导致情绪低落。

开发员A平时是个整天乐呵呵的小伙子，在大压力版本中，某天突然对着测试员就一个缺陷问题大吼大叫，大家都懵了。后来得知，A当天一直情绪莫名不佳，午饭也没吃。第二天，该缺陷被修复得很好，A和测试员之间的关系 依旧还不错。于是，大家懂了，这只是一时负面情绪的爆发。但这样的爆发对于团队关系和合作都是有伤害的。

除了团队关系之外，另一个难题是绩效。每一个成员在长期加班的同时，一定有一部分支持信念来源于对高绩效的渴望，也就是每个人都期待着B＋或者A的考评结果，毕竟付出了那么多牺牲。但是，影响绩效考评的因素往往是多样的，既是个人的功劳和苦劳的综合，也会考虑产品和团队本身的业绩。也就是说，如果“不可能的使命”不能直接带来产品业绩的一路高歌，那这个周期的考核就将面临各种矛盾和考验。

3．关于变化

互联网的精神本身就是拥抱变化，许多互联网团队都向着拥抱变化的方向进行着转变。许多“不可能的使命”本身就是为了顺应变化，抢占变化先机。有趣的是，我们发现在整体任务快速响应市场变化的同时，在任务内部响应细节变化的弹性反而可能减弱。如何面对变化，是一种心态，而真正应对变化，也需要环境和过程的支撑。当整个估算本就是冲着120%甚至150%以上的负荷去的，那团队又何来空间包容甚至拥抱变化呢？

有一个真实的例子。开发团队刚在上个版本开始建立拥抱变化的心态和氛围，甚至主动提出拥抱变化的理念，但下个版本遇到了“不可能的使命”，开发员很想依然拥抱变化，但本就120%的任务量压力下，一个临时变动导致的0.5人日工作量，也会让开发员本已脆弱的弹性雪上加霜，自然会出现抵触情绪。即便通过高压手段执行了这些变化，伤害的是员工刚刚建立起来的拥抱变化的心态。

4．关于技术

“不可能的使命”更多的是以产品为导向所产生的紧急任务，在此大环境下，技术债难以避免地会产生和堆积。无论是解决方案的可扩展性和兼容性，还是开发过程中的单元自测、代码审查或者重构，甚至部分注释（当然，也跟工程师个人编码习惯和风格有关）都可能成为时间的牺牲品。

5．关于节奏

有松有弛，于是在大压力版本的里程碑结束之后，整个团队往往需要明显的恢复期，尤其是团队关系和个体身体状况方面。长期的产品研发，团队都期望有较为固定的节奏，哪怕节奏频率很快，也会好过拍脑袋不固定的节奏。因此，一次里程碑之后，团队会期待后续的理顺以及节奏感，而不能够轻易接受又一次的“不可能的使命”不期而遇。

“不可能的使命”的应对方案

看到了挺多“不可能的使命”的负面影响，但我们依然不能否认在这个极度敏捷的行业中快速响应、抢占先机的重要性。因此，我们希望在看到负面影响的同时，更多地来探讨如何面对、如何最小化这些负面影响。

1．“不可能的使命”敏捷变革，让快速响应“不可能的使命”成为常态

正是因为看到了很多“不可能的使命”带来的伤害，我们认为这招在必要时刻得用，但不可多用，不能成为常态。应该为团队找到可持续发展的模式。同样是快速响应变化、抢占先机，我们可以采取短迭代高效率的方式敏捷应对。具体来说，就是对产品版本周期进行节奏梳理，形成2～4周为固定周期的发布频率，必要时甚至可以采取短于2周的发布频率，快速上线变更，用小步快跑的方式持续改进产品或者增量式开发新版本。版本开发过程中，逐步有针对性地尝试敏捷实践，用以解决产品功能规划以及开发过程中的沟通、协调、跟进等问题。

有时我们也会发现，固定节奏快了未必等于有效的产品交付快了，往往有三种可能的原因：

（1）产品需求不靠谱。一个需求可能到开发或测试时被发现不完整或有自相矛盾之处，在研发过程里再补充需求细节，甚至在测试阶段被打回重做，这些往往是研发效率低下的罪魁祸首。

（2）研发效率不靠谱。有时是因为士气低落，更多的时候是因为基于遗留系统开发，牵一发动全身，不靠谱的前期架构已经为微小的改动留下了众多的坑，前行缓慢。

（3）过程流动不靠谱。有时存在环节或能力上的瓶颈，有时是因为所有人都被工作塞得太满，就像高峰时的高架桥，每寸土地都被利用，然而有效的流动却很慢。这时，就需要根据这些不同的原因加以响应和调整了。当主要的、妨碍快速流动的问题被解决时，固定周期的快速发布才能发挥巨大的优势。

2．明确传达并统一对项目目标的理解和价值认同

在大压力版本开发之前，采用启动会或者其他方式，明确传达并统一对项目目标的理解和价值认同。让大家知道，我们为什么这么做，我们真的必须这么做。只有理解了、认同了，才会心甘情愿去奋斗、去拼搏，而不仅仅是“老大让我这么干”。同时，借此机会也可以明确开发过程中的一些规则和底限。

3．加强各版本内的变更管理，减少不必要的失误导致的变更

拥抱变化的目的是为了快速响应市场变化或者潮流，甚至先期引导用户习惯，但并不是为不成熟的需求方案埋单。快速迭代和交付的方式，可以让团队在版本层级上充分灵活，因此，我们建议尽可能对版本内的变更进行控制和管理，尤其是那些不成熟的需求方案所导致的变更。在版本内，尤其是版本后期，对变更进行限制或者约束流程是必要的。如果真有商业因素导致的变化，那我们不如立即启动新的版本快速交付。

4．使用多层级站会

每日站会利用每天不到15分钟的时间进行团队间的快速沟通，包括状态和问题。只要团队间是需要协作的，并且有一定的版本压力，那站会的形式必然益处多多。一些团队为什么不能坚持站会？一是可能站会的时间不能够有效控制在15分钟以内，15分钟和30分钟是本质的差别；二是站会内容有可能发散，会议目的游离；三是团队根本没有版本压力，无须密切协作；四是召集人没有建立良好的规律习惯，随心所欲地开站会。对于超过10人的团队，团队需要拆分，并建立多层级的站会制度，即自下而上地进行站会。

5．加强状态展示及更新

无论是敏捷或者传统的项目管理方式，良好的项目状态展示都是项目控制的重要组成部分。对于大压力版本，状态更新更需要加大频率，以更准确、及 时地呈现状态、提示问题并寻求解决方案。状态展示并不是机械地汇报JIRA状态或者记录站会信息，向整个团队报告进展情况仅是状态展示的一个部分，更重要的部分在于及时发现问题和风险并制定解决方案和落实。从形式上来说，无论是电子的还是实物的（如白板）均可，实物往往能起到更好的共享和实时提示作用。

6．明确定义质量标准

对于测试的准入和准出需要制定明确的质量标准，如冒烟测试100%通过方可提测，全部关键的和主要的缺陷被修复后且测试用例通过率达到95%以上方可通过测试等。质量标准需要在项目启动会之前就确定并在启动会上宣布。冒烟用例需要尽早（联调前）提供给开发，便于有针对性地进行检验。实践中，我们发现测试的准入标准往往比准出标准更为关键，可以从基点上保证基本的质量。

7．记录技术债，并排入版本计划

在非常时期，一定的技术债难以避免，我们至少必须及时记录这些技术债，比如某处设计在扩展性上做了一定的妥协等。在后续的版本中，要确保技术债被同样进行优先级排序并列入版本计划。也就是说，我们并不赞同连续的大压力版本导致技术债无法被及时偿还，长期积累势必影响系统的长远发展。无论是单独设立技术优化版本，还是在每个常规版本中保证一定比例的还债任务，都是可以参考的方式。

8．领导身先士卒

当团队在拼命赶工时，领导身先士卒至关重要。或许你不直接写代码，但哪怕只是个吉祥物，你的存在对团队而言也是一种信念和榜样。更何况大部分领导远不只是吉祥物呢！

9．情绪及人际问题早预防、早发现、早协调

同样是加班的苦，有时稍作些调整就能化为众乐乐的和谐气氛。比如，准备些犒劳大家的食品饮料，从提神的红牛、咖啡到补充体力的巧克力饼干，从甜心小食到健康水果，略微变换点花样，大家在加班时就会多少对于食物有些 小期待，也顺便可以用这样的茶歇时间让大家站起来走走聊聊，提升团队氛围。当然，不时地搓一顿也可以为加班增加一些亮色。对于确有特殊原因的同事，也可接受在家加班等灵活的方式，当然，首推还是团队在一起协作高效地工作了。

上一段落中提到的领导身先士卒，在情绪和人际问题方面也相当重要。只有充分贴近团队执行过程中的点滴，才能真切感受到情绪的波动变化。一旦出现问题苗头，就需要第一时间协调，以确保整体的积极向上。

项目经理需要的能力——掌控冲突

文／靳霄

项目进行当中可能出现各种“撕逼”的情况，这种冲突的场景并不是坏事，关键是要对其进行管理，让其产生对团队有意义的产出。

通常，在项目管理的过程中，所涉及的项目有部门内部的，也有跨部门的，其间，当人与人之间，或部门与部门之间项目合作冲突时，项目经理需要担当救火队员和解决危机的角色。有些时候，项目经理也会被卷入冲突中。发生冲突是不可避免的，如果团队中只有虚假的“一团和气”，并不能很好地解决团队遇到的问题。但是，冲突是需要被管理的，任由其发展就变成争吵和恶意的人身攻击。项目经理需要控制好冲突，让其产生对团队有意义的产出，同时要 控制冲突不要超过某种界限。

冲突在团队不同阶段的表现

项目团队在其生命周期中会经历以5个阶段：

（1）形成阶段。在本阶段，团队成员相互认识，并了解项目情况以及他们在项目中的正式角色与职责。团队成员倾向于相互独立，不怎么开诚布公。

（2）震荡阶段。在本阶段，团队开始从事项目工作，制定技术决策和讨论项目管理方法。如果团队成员对不同观点和意见不能采取合作和开放的态度，团队环境可能恶化，产生破坏性。

（3）规范阶段。在本阶段，团队成员开始协同工作，并按团队的需要来调整各自的工作习惯和行为，团队成员开始相互信任。

（4）成熟阶段。进入这一阶段，团队就像一个组织有序的单位那样工作。团队成员之间相互依靠，平稳高效地解决问题。

（5）解散阶段。在解散阶段，团队完成所有工作，团队成员离开项目。

在不同的阶段，冲突的强度是不同的，如图2-7所示。

图2-7　项目生命周期中不同阶段的冲突强度

从图2-7上我们可以看到，冲突的强度在各个阶段是不一样的。

（1）一个成功的团队，在团队的初期不是为了追求“一团和气”而逃避冲突，而是通过发掘冲突，来解决团队遇到的问题，这样反而是随着团队的成熟，慢慢地冲突的强度降低下来了。

（2）对于一个不是十分成功的团队，在团队形成的初期几个阶段，会有意避免冲突，导致实际存在的问题得不到解决。而到了后期，冲突集中大爆发。

（3）即使一个成功的团队，在团队成熟之后，冲突也是不会消失的。好的团队应该包容和掌握冲突，通过冲突产生一些有创意和高效的解决方案。

为什么对于两种类型的团队，会出现截然相反的冲突强度变换的曲线？这就需要我们解释一下两种不同类型的冲突。

冲突的类型

对于项目中我们遇到的冲突，基本可以分为两种类型：启发式（积极）冲突和破坏式（消极）冲突。

1．不同类型冲突的特点

（1）启发式冲突的特点：

•　愿意倾听和理解别人的观点。

•　彼此信任和尊重。

•　追求双赢的解决方案。

（2）破坏式冲突的特点：

•　逃避或是拒绝。

•　以自我为中心。

•　感情用事的解决方案。

2．破坏式冲突案例

小鱼儿：是一个感性和靠直觉办事的人，非常喜欢团队进行的头脑风暴，总爱提出新的观点。

老K：擅长分析和细节处理，并不擅长产生新的点子。

在一次团队会议中，小鱼儿提出了几个新的想法给团队。由于老K细节导向的思维习惯，在大家没有充分讨论的情况下，老K就挑出了他观点里的几个瑕疵。虽然没有明说，但是老K觉得小鱼儿的想法不靠谱，这些想法之前都没有进行充分考虑就不负责任地提出了。

自己的想法每被老K挑剔一下，小鱼儿就变得激动一些。最后，在小鱼儿讲完他最后一个新想法后，小鱼儿冲着老K，红着脸生气地说：“好吧，你现在说说这样想法问题在哪里！”老K觉得在团队面前受到了攻击，本能地进行反击。如此来来回回，导致冲突爆发，最后会议不愉快地结束了。

类似的场景会在项目的会议上发生，有时冲突可能没有公开爆发，有时候可能比这种情况更严重，导致团队气氛紧张，协作出现问题。仅仅逃避是解决不了问题的，最终会导致形成一个具有破坏性的冲突团队氛围。

我们看一下破坏式冲突的症状有哪些：

•　认为其他人的需求没有道理。

•　情感因素快速占据上风。

•　终止沟通。

•　事情、人都受到了负面影响。

正确地认识冲突

要想解决冲突，首先我们要正确看待冲突。冲突对于团队来说是一个力量和机会。可以帮助我们提高团队的健康程度、学习的潜力和对于变化更大的接受程度。

面对问题积极解决，能够帮助我们找到更多的可能性。如果逃避冲突，那些存在的问题会反复出现，一直得不到解决。这些得不到解决的问题，如果在团队形成的后期集中爆发，可能会摧毁团队。

如果团队一直处在一个比较舒适和满足的环境中，就很难保持创新的能力，需要用冲突把团队赶出这种满足和舒适的环境，让他们保持创新力。同时我们要注意掌握冲突的界线（见图2-8），避免把启发式冲突演变成为破坏式冲突。

图2-8　冲突的界线

1．对破坏式冲突的例子的分析

我们重新看一下前面破坏式冲突的例子，有没有好的方法把它转变成启发式的冲突呢？我们分析一下小鱼儿和老K两个人的特点。其中一个擅长产生新想法和展望未来；一个善于分析细节和步骤，更立足于当下；一个认为对方墨守成规，一个认为对方不负责任，想法天马行空。实际上，这两种想法对团队都是有益的。只是一开始我们需要的是新的想法，后面需要认真的分析去把想法变成现实。团队成员如果能够理解个性的差异，就能够接受人与人之间行为的不同，而不是互相指责，并且能够更好地利用这些不同为团队做出贡献。

2．解决方案

（1）如果小鱼儿在开会前，能够私下先找一下老K，听听老K的意见，看看自己的想法有没有重大的问题，这样就可以在团队会议上呈现给团队更完善的想法。

（2）老K在发现小鱼儿的方案有问题时，不要直接否定，而可以通过一步步提问的方式，让小鱼儿自己发现自己方案中的问题，这样更有利于小鱼儿虚心接受。

用对话解决冲突

看了前面的例子，那在实际对待冲突时，有哪些技巧可以帮助我们呢？

通常我们希望用对话化解冲突，但在冲突的场景中，这种对话比较难以把握，其原因是它具有两个特点：

•　双方抱有不同的观点。

•　有激烈的情绪。

由于这样的特点，导致对话存在很大的失败风险。如果没有一个好的策略进行引导，很有可能一波未平一波又起，在化解冲突的对话中造成更大的争吵。那有哪些策略可以帮到我们呢？

1．注意对话的安全信号

案例场景

小王负责产品的运营，为配合世界杯活动，需要开发实现一个功能并及时上线。开发员觉得时间太紧，这个策划案无法保质保量完成。在进度计划会上，小王也很着急，对开发员说：“世界杯又不会改期，广告都投出去了，你们开发不要不积极投入啊。你们部门负责人也在，你们几个开发员要给我这个承诺的。”几个开发员都低着头刷手机，开发小组长看大家都不说话，满脸无奈地说：“你这么说，谁还能说什么，那就定在世界杯前一天上线喽！”

最后的结果是，功能的确按照那个时间上线了，但是上线的前一周一直在解决线上问题。

策划小王在进度确认会上虽然让开发员给出了承诺，但在进度计划会上应让开发员把风险提前暴露出来，并给出对于风险的解决方案。否则就会导致在功能上线时，前一周的时间都在还这些“债”。小王在沟通的过程中，太强调产品开发周期这件事，以至于对其他情况都视而不见，如其他人的感受和表现方式、他们的语气语调等细微的方面。

在激烈讨论的对话过程中，当问题变得比较棘手时，你既要关注讨论的主题，又要观察对话的氛围、参加者的反应。如果你能弄清对方为什么生气、为什么保留自己的观点或沉默以对，那你就更容易解决冲突。与此相反，越晚意识到你已经偏离了主题，就越难回到正轨，所要付出的代价也就会越大。

对话只有在安全的气氛中，参与者才能畅所欲言，如果失去对话的安全感，人们便会举步不前，隐瞒内心真实的想法。所以在对话进行中你首先要关注的是对方安全感是否出现了危机。危机出现的特征表现通常是沉默或者语言暴力，沉默的意思是拒绝观点的交流，在实际场景可能表现为逃避对话和掩饰实 际的想法；语言暴力主要表现是通过强迫、恐吓或污言秽语的方式强迫别人接受其观点。

在解决冲突的沟通中，你的大脑要随时保证“并行处理的双核”模式，既要关注你谈话的目标，又要观察谈话的氛围，这个氛围是由你的行为和对方的表现所形成的。

2．循循善诱表达观点

案例场景

一个团队的项目经理小P在项目的开发过程中发现，开发员小陈多次没有按时完成开发任务。小P就找小陈谈了一次话，说：“你工作怎么不太认真啊，你的任务总是无法按时完成。再这样下去，我就反映给你的直接领导了！”小陈一听就不高兴了，反驳说：“你怎么知道我工作不认真啊，进度没有按期进行，我还觉得是你项目经理失职呢！”

这个案例中，小P一出口就错了。在大多数情况下我们沟通时都会用一些平常的方式，如“Hi，这件事我觉得应该这么做”。但是如果在一个冲突场景中，对话会充满风险，有时双方情绪也会比较激动，如果不注意，就很有可能犯小P的错误。以下是我们的建议。

首先，开场列出事实。如果对话是以主观判断起始的，很容易不客观而导致更大的争议，而以事实为谈话的起点可以让你安全出发。例如案例里，小P可以这么说：“我看最近一个开发任务的完成比你原来承诺的时间晚了2天”，这样说就毫无争议了，而如果换成案例里的开场“你工作怎么不认真啊”，这里面就包含了个人的判断，看起来像人身攻击，容易激化矛盾。

其次，说出你的推理逻辑。谈话中还是要说出你的观点的。你可以从事实出发，告诉对方你的分析思路，是如何得出你的个人观点的，这样便于让对方理解你的观点。例如：“这个开发任务的完成比你原来承诺的时间晚了2天。上次周会同步时你说进度没有问题，同时我看到期间你还报名参加了公司组织的第一批旅游，那我的理解就是你认为这个任务完成时间应该很充分的，而现 在你延迟了2天才完成，会让我感觉你对这个工作不是很负责。”

最后，征求对方的意见。在冲突中对话，目的不应该是证明你自己的正确，而是让大家能够自由地交流观点，做出最佳决策。这就需要你在陈述完自己的观点后，收集对方的想法。事实陈述和逻辑推理的目的就是便于你更好地收集对方的意见，让对方针对你的推理逻辑提出他的观点。

通过这样三个步骤，能够帮助你更加客观地表述你的观点。

3．打破僵局

在冲突解决中，如果对方拒绝沟通，你要想办法了解对方退出对话的动机，这样才能打破僵局，继续解决问题。鼓励对方说出动机，有几个方法可以参考使用：

（1）最简单、最直接的方式就是询问的方式，让他们直接表达。例如：

“针对这件事，我想听听你的想法。”

“我的想法并不一定正确，我想了解一下你的想法。”

（2）如果询问无法让对方开口，可以通过“描述你看到的对方的感受”，给对方创造一种安全感，从而让对方愿意表达。例如：

“你真的没有想法吗？从你说话的方式看，我感觉你有些不高兴。”

“你认为这个方案怎么样？感觉你欲言又止。”

这样做会让对方感觉你并不排斥他现在的情绪，会让对方更愿意说出想说的话。

通过前两个方法，可以帮助你了解对方部分的想法，你可以通过“主动描述”的方法，表达出对方的特定的感受，从而为对方创造一个更愿意表达的氛围。例如：

“这样，你看我理解得是否正确。你感觉我定的这个季度目标太难以完成，这让你感觉我的想法太不切合实际了，是这样吗？”

这样做对方会觉得你在主动理解他们的感受，会让他们顺着你的话说出他们内心的想法。

高段位方法——谈判技巧

前面介绍了对话的方式，如果想更有策略地解决冲突，就需要使用高段位的方法——谈判技巧。

1．人的因素决定一切

案例场景

小P新到一个公司任项目经理，到了新部门之后，发现没有特别正式的流程。由于他之前所在的公司项目管理方式用的是Scrum，小P很想把这套流程应用到新的部门。小P找部门负责人建议把项目管理的方式改成Scrum，说Scrum是业界推崇的项目管理方式，使用固定的迭代周期，使用每日站会等。项目负责人说，这个不急吧，就委婉地把小P回绝了。

案例中，小P“想在部门实施Scrum”的谈判为什么没有达到目的？想必每个负责人，都不会轻易对部门的整个管理流程进行改变。小P在谈判前准备了一大堆的想法，“我”想这样，“我”想那样……然而实际上，在这个谈判过程中，你有没有考虑过部门负责人是怎么想的？

在谈判过程中，你自己应该是无足轻重的，最重要的人是对方，对方现在的感受是什么？他们对当前形势的看法如何？谈判之前，部门负责人的想法是什么？

在促进谈判双方达成协议的关键要素中，“人”在其中所起到的作用超过50%。人的因素决定一切，包括双方是否相互信任，是否愿意倾听彼此的要求。

大家还记得我们读书时学的《触龙说赵太后》的故事吗？战国时期，秦攻下赵国三个城池，赵向齐要求出兵相救，齐就要求赵太后最疼爱的小儿子长安君做人质方愿出兵。大臣轮番向太后苦谏，都被太后唾出门外。最后触龙劝说太后为长安君的今后长远利益着想，让长安君去当人质，是为国效力，即使太后去世了，长安君也能靠自己的功绩在赵国立足，这样才成功达到“谈判”目的，解决了赵国的燃眉之急。

其他大臣与太后的谈判，都是从“国家利益”出发，没有考虑到“人”的因素，没有考虑作为“母亲”的赵太后的想法：送长安君出去，相当于让我儿 子去送死啊。触龙谈判成功的原因就在于她充分考虑了赵太后的顾虑，引导赵太后看到这么做对她本人和她儿子长安君的利益好处。

同样，回到前面工作场景中小P的例子，当你和部门负责人谈判来推行某个流程时，你首先要考虑他脑海里认为团队当前存在哪些问题，你的方案如何解决他的问题。

2．争论对错毫无意义

案例场景

一个运营员想在产品里加入一个功能来支持运营活动，找策划谈这件事，策划觉得这个功能和产品的整体设计思路不一致，就拒绝加入这个功能。想到之前几个方案都被策划拒绝了，这个运营员就有点火大了，加之之前有些小矛盾，两个人就把之前的事情也翻出来，吵了起来，最后不欢而散。

在这案例里，运营员和策划的谈判为什么失败了呢？在谈判中，很关键的一点是谈判前你要明确这次谈判你要达成的目标是什么，目标是你要努力实现的东西。

谈判一开始就要对目标做到心里有数，同时，在谈判过程中要不断提醒自己。在上面这个案例里，运营员这次谈判的目的是什么？是为了证明自己比策划的能力高？是为了之前策划拒绝自己的事情来惩罚他？如果不是这个，就没有必要把之前的事情翻出来，去争论这些事情的对错。在谈判中，为昨天发生的事情而争斗永远不会让你取得任何进展。这并不是说我们不要为昨天的事情负责，而是在谈判中我们必须找到推动前进的方法，我们要努力让双方分清主次。在这次谈判中，运营员要明确自己的目的就是“让策划在这个版本中加入一个功能”，不有助于这个目的的话题在整个谈判过程中不要加入进去。

同时在谈判过程中要控制自己的情绪，因为你想要的并不是引发战争。如果对方怒气冲冲，你要提醒自己，加入他们的阵营根本于事无补。你要提醒自己“他们正在企图将我的注意力从我的目标上转移开”。

在NBA比赛中，每到最关键的时刻，老谋深算的教练经常会使用这个技巧。他会派一个球员上场，一对一防守对方当场得分最顺的球星，通过使用一 些故意激怒对方的防守方式，致使有些球星当场暴怒起来，带着情绪去打球，完全忘了之前教练布置的战术，影响了整个团队的发挥，让比赛双方的形势发生了转折。

目标是你去谈判想要获得的东西，只有在谈判开始时明确目标，过程当中不偏离目标，才有可能在谈判结束时达成目标！

3．步子太大会“扯到蛋”

案例场景

测试小张所在的部门开发和测试人员的汇报关系都在项目负责人老K手里。小张在原来公司一直做开发，进这家公司时因为当时没有开发的职位，所以选择了测试。工作半年之后，部门由于业务发展，又有很多开发职位开放出来。小张想和项目负责人申请转成开发。一起做测试的好友小李听了小张的想法后说：“这个你就别想了，我之前也去问过老K了，他说一般我们是不会让测试转成开发的，在招聘时，这两个职位要求的技能是不一样的。”听到这种情况后，小张就改变了和老K的谈判策略。

第一次，小张对老K说：“我看我们很多测试用例自动化测试程度不高，我能不能申请点时间设计一个自动化测试框架，这样可以加快测试周期，加快版本的上线时间？”老K觉得可以缩短测试时间对产品来说很有益，当然就批准了。

一个月后，小张独自完成的测试框架上线了，测试可以利用晚上和周末的时间自动运行，项目的进度和稳定性都大大得到了提高。小张的编程能力和积极主动的态度得到了老K的极大认可。

第二次，在当季度的考评谈话时，小张对老K说：“在这个项目测试上，我已做了快一年了，对系统功能都比较了解。我个人对开发兴趣更大，想申请转做开发。在对系统功能比较了解的基础上做开发，全局的思维会很有帮助，你看是否可以。”

最后，在接下来的一个季度，小张成功转成了开发。

在这个案例里，为什么老K同意小张的谈判请求，而拒绝了小李。我们看一下小张的谈判思路。首先他不是一开始就提转到开发的要求。他分析了老K拒绝小李的原因，知道开发和测试招聘时要求的技术背景是不一样的。那意味者你如果想去做开发，就要证明你符合开发要求的技术背景。

所以第一步，小张就通过开发自动化的测试框架去解决老K关心的缩短产品发布周期的问题，既证明了自己的开发能力，又让老K知道自己是可以超额完成本职工作的。在这个步骤完成并得到老K认可之后，第二步才向老K提出请求。

熟练的谈判人员在准备自己的谈判时，首先会考虑把自己的谈判目标进行拆分，分成多个步骤，每一步都要停靠一下并进行确认。大部分经验不足的人往往要求对方一次迈出一大步，这和当前的状态差别太大，容易遭到对方的拒绝。

项目经理的态度

总的来说，作为项目经理，对冲突应该抱着积极的态度，鼓励团队通过启发式的冲突发现团队存在的问题，并积极解决；就事论事地去争论，找出对组织最佳的结论，而不是为了维持“一团和气”或“这是权威说的，就应该毫无疑问地去执行”。当遇到破坏式的冲突发生时，要能够利用一些技巧和方法，去除情感因素，冷静下来找一下双方本源的共同目标是什么，从而找出解决问题的方法，让双方在共同目标下，达到项目经理追求的“双赢”。

网易云计算的大规模团队沟通

文／钟欣

想象一下这样的情景，团队成员经常抱怨忙不过来，而当问起原因，大多会有这样的回答：“人员不足。”管理人员也没有经过论证，就把这个问题抛给 了上层，作为团队交付没有达到预期的最好借口。人员紧急补充，交付逐渐增加，但仍旧没有达到预期，因为人员补充了1/3，但交付也许只增加了1/4。人员随之进一步增加，但情况持续下滑。随着人员的增加，交付并没有增加相匹配的量，直到有一天，即使增加了人员，交付也没有什么明显的变化，甚至还减少了。导致这个问题的原因是系统性的，但是有一个很直接的原因就是因为沟通的成本增加比生产力的增加要快。

当谈到项目管理，管理者讨论和研究的话题更多的是围绕范围、时间、成本、质量这四个主要的领域展开，相对的，挺少会看到一些文章深入讨论沟通管理这个领域。沟通在团队规模较小的时候，问题总是不会太过重要，换句话说，沟通成本还是相对能够控制的。但是当团队规模不断变大，甚至团队的组成比较复杂的时候，团队之间沟通的成本就会逐渐增加，也会成为我们项目管理人员不得不面对和要改进的重要问题。

加入网易后，我就一直担任网易云计算的项目管理工作。云计算大大小小有不同的模块组十余个（见图2-9），总人数逾130人，而且这些模块组还来自多个不同的部门，虽是一个项目组却不得不进行部门间的合作。论人数这可能未必是网易最大的项目，论技术复杂度和各模块之间的协作，绝对是网易屈指可数的项目之一。

图2-9　网易云计算架构

技术的复杂度加上组织架构上的特殊性，决定了云计算这个项目所面临的 沟通成本不会低，大部分的隐性风险可能都会源于沟通问题。

进入云计算项目初期，我经常会碰到各种沟通问题，先让大家看几个案例。

案例场景1

有一天，某PaaS层服务的领导A急匆匆地跑了过来（虽然都坐在一块区域，但人数多，往往最远的团队可能相距50米，中间隔了2～3个会议室）。

A：“昨天我们线上服务某功能失效了，听说你们底层昨晚升级，原本工作的接口现在不工作了。我们整整查了一宿，怎么改了接口也不通知一下，你们得负责！”

底层领导听了不乐意了，立马翻出一封系统发的上线通知邮件，说：“看，邮件上写得清清楚楚，参数和以前不一样了，请上层做好适配，这责任还得你们自己背！”

“每天这种邮件那么多，怎么可能一一看过来。”PaaS某模块领导又不服气地说。

“那通知已经发了，况且我哪知道你们谁用了，会不会出问题。”底层领导也不甘示弱。

争吵持续5分钟，10分钟，30分钟……1小时，始终没有结论。

案例场景2

A为了完成任务依赖某一模块的工作，于是向B提出需求任务，他们一合计没什么问题，B也就接受了，同意一周后完成。为了不至于等待，A继续其他任务的工作。

一周后，A向B询问任务的进展，B回答：“为了完成这个任务还需C的工作，需求任务也提给C了，他正在开发中。”

“那啥时候能给？”A有点急。

“C一完成我马上就能给你。”B说。

时间过了一周，A又去问B进展。B回答：“C好像碰到点技术难题，一直没完成，具体什么原因你去问问C吧。我这儿正忙着其他 工作。”

A无奈找到了C，C告诉他：“的确碰到点技术问题，需要重新修改原本的设计。”

两人一商量敲定了方案，约定就这么做，一周后完成。A心想这回总好了，心满意足地回去了。但一周过去了还是没动静，A去问C进展，C说：“约定的方案当时没叫上B，现在对接到B那边又出了问题。”

A：“……”

最终什么时候解决的也不得而知。A由于心力交瘁，再也不想管这档子事儿了。

案例场景3

这是一个大块的功能设计，涉及多个模块的工作，设计由核心模块出，其他团队配合。在设计评审会上，各方都参与了会议，虽然有不少争论和讨论，但最后确定了设计方案，大家也表示没有问题，会按设计完成。到了交付时间点，却发现不能正常运行。一查，原来当时出方案的时候，核心团队并未了解其他团队目前的设计和工作模式，其他团队也并未完全搞懂整个设计的真实需求，大家都只是在各自理解的基础之上达成了表面的共识。当真的联调的时候发现，以现在的状况无法达到最终的需求目标。

互相推责抱怨的声音，又开始此起彼伏，不绝于耳。

以上场景，读者想必也会深有感触，可能也因为这些问题曾痛得深切。仔细总结一下就会发现，沟通的问题有以下几种类型：

•　信息不交换。

•　信息传递不正确。

•　信息传递损耗。

•　信息传递中断。

•　信息传递链路太长。

•　立场对立。

•　沟通人员太多，沟通成本高，耗时长。

沟通模式

为了解决在大规模团队下沟通低效的问题，我也一直在思考不同的解决办法，但首先我们还得先明确云计算适合哪种类型的沟通模式。

通常情况下，大规模团队的沟通模式会有以下几种模式。

1．树状

传统的职能型沟通模式，自上而下或者自下而上，任何平行团队之间的沟通都必须走到共同的上层领导来进行对接和协商处理。这种模式的沟通效果最好，但是沟通链路最长（见图2-10）。

图2-10　树状沟通模式

2．拓扑

这个模式就像网络的拓扑结构，每个小团队对外都有一个固定的中心负责人，而中心负责人都是平行团队对外沟通的接口人（见图2-11）。

3．动态拓扑

这个模式是拓扑模式进阶版，同样是小团队，但是对外沟通的接口人不是固定于同一个人，而由任务驱动，谁的任务需要对外沟通，就需要担负起对外沟通的责任（见图2-12）。

图2-11　拓扑沟通模式

图2-12　动态拓扑沟通模式

4．网状

这是一个比较自由的模式，沟通也不局限于小团队单元，在大团队中的任何一个人都可以担负沟通的责任，只要任务需要，就可以随时组织相关人员进行沟通，并传递给需要信息的人。这种模式和树状模式正好相反，沟通效果最差，但是沟通链路最短（见图2-13）。

图2-13　网状沟通模式

以上四种模式，各有优缺点（见图2-14），选择哪种模式还得参考项目复杂度、组织结构、人员素质等综合因素，而唯一不变的评判标准就是衡量和平衡各方因素，使得团队在项目中的沟通成本达到最低。

图2-14　沟通模式优劣对比

在云计算中，各个模块组众多，各自独立运作，又相互依赖。每个模块组都有一个固定的负责人，担负起这个模块的管理工作。从组织架构讲，各个模块组又来自不同的部门，可以说没有统一的直接行政领导负责云计算这个项目。根据这些实际情况，可以确定云计算最适合的沟通模式应该是拓扑结构模式。模块和模块之间的沟通职责都落在了模块负责人的身上，但凡有对外的依赖需求统一都由负责人对接和与外部沟通，外部进来的需求也都由负责人进行统一管理和调度。

这样的模式在云计算中的好处是很明显的。由于人员多、模块多、信息量大，通过固定的负责人，可以对信息进行分层、分类和过滤，让人员能够捕捉到重要的信息并且有效地传递给正确的人员，提高开发人员的工作效率，责任到人。但同样也会有一些缺陷，就是对于负责人的要求会比较高。再者由于需要花更多的精力在小团队管理和沟通上，就无法投入更多的时间在开发上，但这也是为了能让团队高效工作的必要代价。其次，沟通的链路相对较长，比点对点的沟通要多出两个环节。例如，团队A的成员要跟团队B的成员提交需求，还得通过团队A的负责人传达到团队B的负责人，再传达到团队B的成员。在初期，当然可以把相关人员拉到一起沟通清楚，但是在进度跟踪阶段，就经常可能会在链路上多出两个环节。根据沟通成本最低的评判标准，这种沟 通模式是最适合云计算的。

流程制度

1．定义流程

流程的定义和执行，主要是为了能够保证输出结果稳定，每个环节的权责明确，自动按照预定的工作路线进行流转。在沟通层面上的解释是为了明确分割好每个环节的工作内容和职责，减少或避免持续和其他人员沟通的工作，因为输出的内容和约定的工作都是固定的，只需要按照约定的流程做好要做的事情并转交到下一个环节就可以了。

云计算是个庞大的平台型系统，如无一定的流程进行约束和分工，那些重复性的工作就会有巨大的沟通成本甚至出现各种问题。

项目管理上我们有一个总体的流程（见图2-15），以半年为一个完整的里程碑周期，里程碑周期中又以月为周期迭代，这样滚动式开发，推动流程前进。

图2-15　滚动前进的开发流程

除了这个总体流程，我们还有其他各种小的流程来加以补充，针对各种不同的重要事件进行流程规范：

•　上线流程（示例见图2-16）。

•　环境部署流程（示例见图2-17）。

•　故障恢复流程（示例见图2-18）。

图2-16　上线更新流程

图2-17　私有云环境部署流程

图2-18　故障恢复流程

2．定期会议和报告

记得网易杭研项目管理办公室（PMO）曾针对会议和报告成本过高的现状，有过一次讨论：在大团队下是否还有必要开周会和提交周报？如果要开，如何才能开好周会和如何利用好周报？讨论最终都没有一个很明确的定论，但是有那么几点是可以肯定的。

（1）在团队还未达到理想的沟通状态之前，为了能够同步信息、传达精神、互相学习和借鉴，甚至于解决全局性问题，周会还是有必要的。

（2）周会不是讨论过多细节性问题的地方，需要在会议前做好充分的准备，同时控制好周会节奏，提高周会的效率。

（3）周报还是有必要的，但周报不能只是单纯的记录，需要精炼易懂，突出重点，起到效果。

云计算根据当前团队的状况，制定了一系列定期会议和报告制度，在跨组织的背景下，这是有效同步整体信息、传达精神与规划的途径之一。

围绕云计算的整体的项目管理流程，每个节点都有相应的会议：

•　里程碑计划会（各模块组，半年一次）。

•　里程碑评审会（各模块组和相关评审人，半年一次）。

•　迭代计划会（各模块组，一月一次）。

•　迭代发布会（云计算模块负责人，一月一次）。

•　迭代总结会（各模块组，一月一次）。

•　周会（云计算模块负责人，一周一次）。

伴随着这些会议，也同样会有报告输出。

•　里程碑报告（模块负责人，半年一次）。

•　周报（模块负责人提交各自模块的周报，项目经理汇总总结，一周一次）。

•　月报（项目经理，一月一次）。

这些是云计算整体会议和报告制度，每个模块组的内部也会根据不同的情况和要求，对模块组成员要求召开和提交定期的日站会、周会、日报、周报等不同形式的会议和报告。

3．工具

任何流程制度都是人为的约束，团队大了约束起来就会更加困难，而管理者的目的并不是为了约束并展示权威，而是希望大家每日工作都能够切实地按照所定的流程制度执行到位，真正让工作顺畅起来，效率提升起来。另外，流程和制度本身就是为了要让重复性的工作输出更加稳定。但是人不是机器，天生对于重复性的劳动逐渐会失去兴趣且容易犯错。那么有效的工具对于我们来说就是提高重复工作的效率，减少重复工做出错，甚至在出错之后能够得到提醒和纠正的必不可少的手段之一。

网易云计算中就使用了不少工具，在大规模团队中，帮助大家减少了沟通的成本。

（1）JIRA这是一个任务管理和Bug跟踪的工具，但任何一个管理工具的使用需要带上项目本身的管理理念于其中，才能充分发挥工具本身的价值。云计算从里程碑任务开始，到迭代计划任务，到每个人的日常任务，层层分解，全部都会记录在JIRA系统中，且都有明确的交付定义和责任人。除了任务本身，还有Bug的跟踪、改进意见的记录，甚至风险的跟踪都会完全通过JIRA进行管理，这也是对团队工作进行量化的一个前提，数据积累的重要过程。

（2）Confluence。这是一个可在线编辑的维基文档管理系统，所有人都可以上去进行查看和编辑，我们大部分的文档，包括设计、部署、报告等，都会放到这个系统中统一进行管理，文档的集中化可以帮助团队所有成员知道去哪里查看自己所需要的资料，不需要跑到专门的组进行沟通。同样，文档的编写和维护也会成为团队在开发过程中重要的工作之一。

（3）POPO、易信和邮件。通信工具自然是必不可少的，但不同响应级别的通信工具都需要具备，这样在有需要的时候能联系到正确的人。但无论怎么搭配和混合使用，邮件始终还是最为官方且正式的通信方式，其重要性无法被替代。通常发送邮件会配合使用POPO、易信，或者口头和电话传达。

（4）持续集成和其他自动化工具。持续集成和自动化工具，同样可以减少和避免因为沟通不畅而导致问题出现，在问题有苗头的时候就发现并解决掉，减少沟通成本。如果说，流程减少了人与人合作过程中的不必要沟通，那么自动化工具可以减少人与人合作的流程，彻底解决在合作过程中因为信息不一致而导致的错误发生。持续集成和自动化工具对于减少重复性工作、提前发现问题、帮助沟通协作等都能起到很重要的作用。因其本身就是很大的一块内容，这里不做展开。

价值原则

如果你把人员的职业素养都看得很高，如果你愿意忽略人和机器的不同，那么也许我所要讲的就可以到此为止了。但事实上，人能做的工作还有很多是机器不能代替的，与此同时，我们又不能不考虑人性的因素。坦率地说，这也是我们最难把握的一部分，所以仅靠以上的内容无法解决我们所有的问题，举 几个例子。

（1）创造性和艺术性工作的合作。

（2）不断有新的环境变化引入，导致我们的流程来不及变化。

（3）因为立场和职责不同，导致互相无法妥协。

（4）团队成员中各自的目的和想法不同，导致所做的事情大相径庭。

（5）对于职责流程定义范围外的空白，无人填补。

这些当然不是问题的全部，却都无法或者说很难通过流程制度的方法来改善沟通效率，有的时候恰恰相反，流程制度反而还助长了这些问题的产生。对这些根源来自人性的问题，我们需要使用符合人性的方法来解决，那就是倡导统一的价值原则，或者说团队文化。

网易云计算中，也有类似的问题充斥在各个环节。例如：开发与开发之间的对立；开发与测试之间的对立；模块组与模块组之间的对立；模块组与运维之间的对立。这些都是由于在强调流程和责任的系统下，大家对于分工和所要承担的责任特别清晰，清晰得要跟你算得清清楚楚，只做职责范围内的事情。而当有一天出了问题，大家都会争执和各持立场，互相推诿。这都源于一个很简单的逻辑：出了问题必定要有人担责，只要证明不是我的问题，那就是别人的责任，跟我无关。

于是在流程之外，我们还倡导统一的价值原则，营造合作的团队文化氛围。

（1）梳理和制定团队合作的沟通原则（参照敏捷原则）。

（2）灌输和树立云计算团队统一的价值观和目标。

（3）秉持公开透明的原则。

（4）构建合作和主动沟通的团队文化和工作氛围。

（5）更多的鼓励，适当的追责。

沟通模式、流程制度、价值原则都是相辅相成的。流程制度和价值原则就好像团队沟通方法的两端，互相排斥又互相促进，管理者根据自己的经验和项目状况，进行不断的平衡。根据使用两种方法的偏重，决定了团队沟通的模式会是树状、拓扑、动态拓扑还是网状。还是那句话，最终评判的标准始终是衡量沟通成本是否达到最低。

网易云计算团队正是基于这样的评判标准，逐渐改变和形成了这样的沟通 模式特色——流程制度与价值原则相结合。我并不能说网易云计算现在的沟通成本已经降到最低了，但网易云计算团队以相对较小的人数规模，做到了业界好几倍团队规模所产出的成果，足见团队在沟通上所节省下来的成本效果有多大。

现在我所总结和记录下的经验，是希望给那些同样被大团队沟通问题所困扰的管理者们一些可借鉴的经验，同时也是希望身在IT和互联网行业的朋友们，能够深切地认识到在项目管理的世界里，除了范围、时间、成本、质量之外，沟通管理对我们团队影响会有多大。建议尽量能够通过其他方法提高团队的产出，扩大团队规模并不是唯一的选择。在大团队的管理中，尤其不能忽略沟通问题给团队带来的成本。只有正确地管理好沟通，才能为团队释放出更大的生产力。

产品中的风险管理

文／靳霄

产品的决策中风险的管理方案和产品交付中的管理策略有所不同。对于风险应有一种更积极的态度，以便找到更好的产品方向。但是采取激进策略时还要遵循一些规律。

在项目的管理过程中，我们进行风险管理的方式之前已有文章进行专门讨论。而在产品的决策过程中，风险管理的方式却不尽相同。同时，在我们的实际项目工作中，我们也听到一些声音：“产品的版本需求决策如果比较保守，反复修改犹犹豫豫出来的方案，并不一定比一开始的方案好多少，反而拖累了版本上线的时间。”

失败也是一种选择

IBM的创始人Thomas J. Watson曾说过一句名言：“如果你想更快地成功， 就要多犯错。”现代版钢铁侠Elon Musk也说过一句类似的话：“失败也是一种选择。”

然而人的大脑里，有个称作“蜥蜴脑”的部分，存在于你的脊椎顶端。它保存了人类从远古时代进化而来的生存记忆和技能，它所考虑的全部事情就是远离危险和填饱肚子。如果“蜥蜴脑”天生的保守思维主导了产品决策，让我们在产品的决策过程中害怕失败，那就只能生产出平庸无趣、沉闷乏味的产品。恐惧失败的产品风险管理思路帮助不了我们。

案例场景

通常只有采购部门或人力资源部门的办事人员会关心座椅的规格和质地，采购人员不断在安全而又简单的座椅清单中搜寻。座椅的产品经理则很认真地听取采购人员的意见，以最安全保险的方式设计产品。这样就造就了一个无趣、平淡、无奇的市场。

1994年当Herman Mille在市场上推出一款售价750美元的Aeron座椅时，同行都认为它简直疯了。这是一种看起来和之前市场上完全不一样的产品。普通的座椅产品经理认为这会是个巨大的错误，这把椅子的价格可以买市场上一堆别的牌子的椅子。然而产品上市后，因为这把椅子的设计非常独特，每个看过它的人都想坐一坐，每个坐过的人都想和别人分享。Aeron的产品经理在设计时知道这么昂贵的价格一般代理商不会轻易采购，但是他们还是希望尝试能够打动另一批人群。最终，Herman Mille成功地运作了这个产品，让坐在Aeron座椅上的人向外界传递一个信息：你的身份和地位更高人一等，而购买了这种椅子的公司也等于向外界传递了一条关于该公司的类似信息。Aeron面世不久，SiteSpecific公司的创始人在拿到他创业融资的第一张支票后，就立即不假思索地买了一打以上这种椅子，为此他还上了《华尔街日报》的重要版面。这种椅子从1994年推出后，已销售了几百万把，还被美国现代艺术博物馆所收藏。

超越有限的理性

为什么我们需要在产品的风险管理过程中大胆尝试，甚至“主动犯错”呢？原因就是假如我们是完全理性的，我们就不需要为了学习而去犯错，或参与一些随意的行为。然而我们还不够理性，所以才需要勇于尝试，介入一些随机误差，以便取得成功。我们之所以不愿冒险，原因是：

（1）我们过度自信。我们很多人并不了解自己知识的界限。研究表明，专业的知识并不总能保护我们，有的时候它还会阻碍我们的学习能力。这就是所谓的知识的诅咒。没有经验的决策者可能会犯很多错误，但也从中学到了很多。而经验丰富的决策者有可能变得只擅长他们习惯了的方式，以至于水平再也无法显著提高。如果你处于一个瓶颈阶段，你就需要勇于尝试，甚至可能需要故意犯错，从而走出自己的舒适区。

（2）我们怕承担风险。我们职业的自尊心决定了我们的行为。我们因取得良好的业绩而获得奖励，也因失败而受到处罚，因此，我们会花费大量的时间和精力试图不去犯错。尽管情况并不是很糟糕，但是损失在心理上比受益显得更为突出。

（3）我们倾向于找支持我们的论据。当我们做出选择后，我们总希望自己是正确的，而不是错误的。我们倾向于找那些支持我们信念的论据，而不会问一些反向的问题。

适合的场景

在使用这种风险管理的策略时，我们要对度有个把控，在如下类似的场景下实施这种策略的效果会更好：

（1）付出的错误成本不高，但会有巨大收获。当一个决策的失败风险成本很低，然而一旦其成功受益会很高时，理所当然要进行大胆尝试。

（2）需要进行反复决策的问题。例如信用卡产品到底针对哪类人群获得的回报更高，这是一个反复要做的决策，所以要大胆尝试，甚至主动犯错，然后根据获得的数据找到相应的人群。

（3）市场环境不断变化。如果你产品所处的环境是不断变化的，之前的方 式不再有效，你就需要用这种方式去加速学习的过程。

（4）对一个问题的经验是有限的。如果你对一个问题不熟悉，你解决它时就更应该抱着一个开明的态度，而不是保守和固执己见。

我们的敏捷路

文／曾璎珞

在注重目标和人时，我们的过程应该是透明而灵活的，具体体现在两方面：项目过程中，信息的流动更加简明、客观和高效；通过持续的回顾、改进，团队逐步打造和磨炼出最适用的最小集流程和规范。

日本剑道，有守破离三层境界：守——学习方法，按照套路出招；破——用现在时髦的话讲就是创新；离——看透本质，大道至简，无招胜有招。

我们的敏捷，一路走来，也有类似的体会。

敏捷启程

2012年，笔者初进入团队时，常常听到大家抱怨：研发的计划总是赶不上变化，计划正在逐渐丧失公信力……究其根源，我们会发现以下问题：

（1）版本大，周期长，项目推进过程极易遭遇“帕金森综合征”（前期乐观，后期赶工）。

（2）开发、测试、项目验收，三个环节串行，问题和风险常直到末尾才暴露。

（3）项目过程中变更较多，有来自需求的变更，也有来自研发过程的变更。

当时，刚好了解到业界推崇的Scrum敏捷模式，它具备了小迭代、快速交付、快速反馈、及时调整等特征，正是应对上述这些问题的一剂猛药。于是，团队决定试水敏捷，经过一轮Scrum基础培训，即刻选定一个App大改版项目做试点，由此正式开启了我们的敏捷路。

三个月苦“守”

Scrum框架下，为期3个月的大版本项目，原先是瀑布式串行开发模式，现在设定为每两周一个迭代，通过6个迭代来完成。每个迭代过程，完整应用Scrum的4个仪式：计划、站会、评审、回顾（见图2-19）。

图2-19　迭代计划安排

当我们应用整个完整Scrum模式走完全程，大家可以明显体会到Scrum模式带来的变化：

（1）设定短迭代，将大目标切分为团队触手可及的小目标。

（2）通过计划会，让团队共享迭代目标，确定范围、质量标准。

（3）通过每日站会，同步开发和测试进度，暴露障碍并及时处理。

（4）通过评审，邀请策划和设计即时体验，更早地挖掘出需求变更。

（5）通过回顾，即时发现和处理迭代过程中潜藏的沟通协作问题或障碍，让团队能够更及时地适应产品和团队的需要。

虽然，敏捷这剂药一到，团队计划拖延的病征立马解除了；但是，药量配得过猛，也给团队带来了一些额外的负担，例如：

（1）测试成本上去了，原本一轮回归测试，现在每个迭代重复一次，6个迭代就有6次回归测试。

（2）大家为了冲刺进度，忽略了质量，并且欠下了一堆技术债务，后来不得不通过若干次迭代对代码进行重构，才重新找回代码的可读性、可复用和可扩展性。

经过3个月的敏捷实践，大家掌握了Scrum的形，同时也形成了自己的判 断：“旧制度，不一定全错；新模式，也不一定尽美。”

一年突“破”

敏捷试水之后，带着我们自己的判断，一年下来，在经历了9个Android版本、10个iPhone版本、1个iPad版本的项目实践，以及持续的过程回顾和改进，团队开始逐渐找到更适合自己的解法。

1．迭代周期一定要固定吗？

固定的迭代周期，有利于团队形成有序的节奏和平稳的产出；然而，相比固定迭代周期，我们更看重需求在迭代内的完整实现。一个迭代收尾时，如果需求没有完整实现，那么，测试工作也没法有效展开，而策划和设计更没有理由提早试用和验收功能。

2．开发阶段和测试阶段完全并行吗？

Scrum模式下，成员没有明确的角色区分，大家围绕同一个迭代目标进行冲刺，因此，也就没有开发阶段和测试阶段的划分。这种方式对团队和工程实践的要求很高，如果没有机器的持续集成、自动校验作铺垫，仅仅通过人工来保障质量，开发和测试完全并行的方式反而会加重手工测试的负担。

因此，我们依然会区分开发阶段和测试阶段，同时也允许两个阶段30%～50%的并行；同时，还通过开发自测、代码评审、持续集成等方式提高过程质量。

3．需要每日站会吗？

Scrum规定了团队每日定时开站会。具体实践中，我们有两个小组已经习惯于每日站会，无论事多事少，都会选择清早碰个头，来迅速开启一天的工作。有一个小组，选择了研发阶段每周二、周四开站会，测试阶段和上线前每日开站会。

接下来的敏捷之路：脱“离”形式，看本质

回顾我们的敏捷之路，从模仿Scrum的形开始起步，追赶上了计划、按预期交付了产品，同时，理想化模式的应用也带出了一批新的问题。好在敏捷持 续改进的环节，提供了停下来去思考的契机，让大家有机会及时地总结回顾、发现问题和适应调整。

这其中，不管是最初遵循Scrum仪式也好，还是持续改进中寻找到自适应解法也好，各种“形”似的背后，都有着惊人的“神”似——始终关注人，让过程更透明，同时也让过程更灵活地适应目标。

接下来的敏捷之路怎么走？相比之下，我们会更看重敏捷背后的关键——目标、人和过程。

（1）目标导向。围绕产品目标，提前看问题、障碍和效率，并且及时地、相适应地调整项目过程，以更好地支持目标的达成。

（2）始终关注人。尊重每位成员在项目中的参与、体验和收获，呵护团队的特质，并且通过分享和培训更好地同步认知，让人主动去定义和完善过程，而不是简单地由过程来推动人。

敏捷教练与项目经理

文／雷蓓蓓

种种看似矛盾的建议，恰恰说明了成为一名合格的敏捷教练有多难。就连在ScrumGathering大会上，敏捷专家Lyssa Adkins和Michael Spayd震撼全场的精彩演讲，也没有直接告知个中秘诀，而用了一系列真实情境的对话模拟，让大家自己“领略”和“体会”教练的魅力所在。

在被奉为“项目管理圣经”的《项目管理知识体系指南》中，对项目经理在各阶段的职责有着清晰的界定，如项目经理要制定规则，安排进度，监控执 行中的各项风险并实时汇报状态，等等。

然而在敏捷的世界里，虽然对于Scrum Master的职责也有界定，然而一名合格的敏捷教练（Coach）的标准就没那么清晰了，更多了几分“只可意会，不可言传”的味道。

“对团队提供适度的支持，既不能太多，也不能太少。”

“要发挥自己的作用，但不能过于强硬。”

“提供指导，但不是管理。”

种种看似矛盾的建议，恰恰说明了成为一名合格的敏捷教练有多难。就连在ScrumGathering大会上，敏捷专家Lyssa Adkins和Michael Spayd震撼全场的精彩演讲，也没有直接告知个中秘诀，而是用了一系列真实情境的对话模拟，来让大家自己“领略”和“体会”教练的魅力所在。

尽管有着种种的不同之处，敏捷教练与项目经理也有相同的一面，两者的目标都是为了帮助提高工作效率，达成项目最终目标。从这个意义上讲，也可谓是“殊途同归”了。

下面介绍敏捷教练的五步修炼法。

第一步　唤醒内心的能量

我们说敏捷教练的使命是帮助团队完成某种转变。受惯性的影响，任何转变，从工作方式到日常一个不起眼的小习惯，都不可能一蹴而就，过程是曲折甚至反复的。团队很可能在刚开始时跃跃欲试、意气风发，一旦遇到困难或阻力，就会陷入停滞不前，甚至为自己找到很多借口，重新退回到老路上去。Scrum大会上曾经讲到过zig zag（一波三折），描述的就是这个转化过程中的曲折反复。

那么如何才能促成最终的成功转变呢？如果结合物理学的解释就不难理解，我们知道当离子从一个稳态跳跃到另一个稳态，最关键的是能量（Energy）。因此，能否找到这种能量对于转变本身来讲至关重要。所幸的是，事实上这种能量每个人本来就有。

作为敏捷教练，你所做的关键不是给予，不是说教，不是传授，而是唤起 这种发自内心的能量，帮助团队找到内心对改变的渴望和动力。一个真正成功有效的转变、“破茧成蝶”的过程，一定是由团队自发主导的，绝非外力所能。只有发自内心要改变才能最终成功。

要做到这一点，你首先要让自身充满能量，才能去影响和带动周围的人，让他们自己去发现现状中存在的问题，获得内在改变的热情和动力。一个自认为各方面已运行良好的团队，是无法产生持续改进的。

建议： 作为敏捷教练，你必须让人们自己意识到为什么他们需要改变，为什么现在就要改变，帮助人们不断在这一转变的过程中学习并积累经验和信心。

第二步　心中无锤，不为工具所累

心中有锤，为其奴役，可以说是新手最容易犯的错误。

如果你手里有一把锤子，所有东西看上去都像钉子。由于在学习的过程中付出了很多时间，从而导致情绪上产生了明显的偏好倾向，当然内心就急迫希望能够用上，这时很容易忘掉其适用的前提，看哪个都是钉子想上来敲打一番。

在遇到问题的时候不是具体问题具体分析，而是不管三七二十一先上黄金大锤再说，开始往往颇有成就感，却将自己真正原本要解决的问题抛在脑后了。

建议： 始终不要忘记提醒自己“问题是什么”，切忌为了敏捷而敏捷。

说到底，敏捷教练的修炼与是不是敏捷无关，而是要去影响和改变他人！

第三步　耐心倾听，用问题代替答案

一个优秀的敏捷教练，会懂得听比说要重得多，也困难得多。

认真倾听，不光意味着要听到他都说了些什么，更意味着要听懂隐藏在话语背后的层层信息，留意到表情、动作、眼神甚至气氛。只有把自己放在对方的位置上，你才能够真正理解他的需求与担忧，从而做出正确的判断，据此调整自己的方向及优先级。

当被教练者主动寻求帮助时，不要尝试直接给出答案或解决方案。优秀的敏捷教练会通过正确的问题层层解析、步步推进，营造共同探讨的氛围，引导 和触发人们自主思考。被教练者通过这个自主寻找和思考的过程，让人们在得到最佳解决方案的同时，收获了解决问题的思路和途径。同时，来自被教练者自身的想法在执行中更容易获得认同，从而得到更好的贯彻。

建议： 多听，少说。

在敏捷中，回顾会就是一个锻炼倾听、鼓励团队自主寻找答案的最佳实践。通过收集匿名的便笺，我们把主动权和话语权还给了团队中的每个人。敏捷教练要做的就是营造一个开怀畅谈的氛围，让每个人都可以公开发表意见，并确保其充分表达，然后只需要适当引导，“嗯。从大家的投票结果来看，这的确是个严重的问题，我们该怎么解决呢？”，把问题巧妙地抛回团队。

第四步　用信任代替担心

记得有人说过，项目经理就是要有那么点“杞人忧天”的特质。我们总有这样那样的担心，担心团队不知道正确的方向，担心团队可能会失败或做得不够好。的确，这种风险意识很多情况下帮助我们扼杀了摇篮中的风险，起到未雨绸缪的作用。

但同时，我也看到过很多新手项目经理，包括曾经的自己，由于一些不必要的担心而让团队和自己都陷入困扰。自己心急火燎，一万个不放心，冲上去一顿指挥，别人未必领情，有些个性强的人甚至会产生抵触心理。同时，过多的担心和干预也会让团队丧失原本可以获得的自我协调的能力，使团队无法看清可能产生的后果，不知道自己将遇到什么样的问题，也不知道自己有多大的潜力。

就像父母对待渐渐长大成人的子女一样，伴随着团队慢慢成熟起来，我们的信任应该越来越多，遇到问题适当缓一缓，给团队自己发现和解决问题留下足够的空间。出点小问题不要紧，用宽容和鼓励的目光，看着他们用自己的方法和选择达成目标，转而去做那个“站在路边鼓掌”的人。说到底，什么时候该担心，什么时候要放手，这有个“度”的问题，取决于团队的成熟度及教练对具体情况的判断。

事非经过不知难，有些道理必须亲身体验以后才能明白。要相信团队能够 做出正确的选择，虽然没有了你的指导他们的选择可能会不同。要相信他们能够并且会很快从死胡同里退出来走上正路，所以尽可以让他们经历一些挫折。要相信即使他们失败了，他们也能吸取经验，再次做得更好。

建议： 不要一味地试图指导和干涉团队，在情况允许的范围内，想办法打造安全的环境，允许一定程度的犯错和自我学习，帮助他们找到属于自己的道路。

第五步　放下自我，保持好奇

著名的管理大师，《从优秀到卓越》的作者吉姆·柯林斯曾经描述过这样一个黄金法则：

“不是要把自己变得有趣，而是要对别人感兴趣！”

如果你想要一场有趣的午餐谈话，保持好奇心；如果你想要写出有趣的东西，保持好奇心；如果你想要遇见有趣的人，对你遇见的人保持好奇心。他们的生活、他们的历史、他们的故事？他们从哪儿来？要往哪里去？他们知道些什么？

我们总是试图把自己变成焦点，却忘了在关于“改变”这场大戏中，主角并不是你，而是你的团队。最优秀的敏捷教练会尊重团队所在的组织文化和工作环境。只有将注意力从自我身上移开，才能关注到你周围的人，关注到真正需要你关注的事情。

刚开始推广敏捷时，我迫不及待地等待每个机会，希望能够用上自己学到的敏捷知识，充分展示自己对敏捷的理解和观点。渐渐地，我意识到，这除了让我自我小满足一下之外，不会给团队带来多大好处。

把注意力集中在他人身上，去探寻“他们在意的、他们需要的、他们适合的”，而不是“自己擅长的、自己喜欢的、自己想做的”。用他人喜欢或接受的方式来沟通，而非坚持自己喜欢的方式一成不变。

建议： 试着问你自己一些问题，比如，“这里都在干什么？”“他们的目标是什么？”“他们会觉得什么比较有用？”然后更仔细地观察。用心看清楚周围的情况，了解团队的处境，但不能在其中加入带有个人感情色彩的判断和假设。当你看清楚团队的情况以后，你就可以开始考虑该做些什么了。当你对他 们表现出兴趣，想要更多了解和联系他们时，人们通常会变得更加开放。

看看你是哪个型

一个优秀的敏捷教练，在不同类型的团队，或不同的团队发展阶段，会结合具体情况，表现出迥异的风格特点。

有人把这些风格归为7个大类（见图2-20）：海鸥型、意见型、管理员型、集线器型、蝴蝶型、专家型。这里我根据有限的经验，尝试将这些类型的适用条件及可能的缺点一一加以梳理。如果长期过于鲜明地集中于一种型，就有必要思考一下，改变的时候到了吗？

图2-20　敏捷教练的类型

参考阅读：http://tech.it168.com/a2008/1211/260/000000260040.shtml

后记

这篇文章写的过程，本身也是一次修炼，里面潜藏着很多内心的思考，夹杂着我目前做到的、没做到的，正在实践的或想要达到的。

写到最后，我突然发现其实上面所总结的敏捷教练的修炼之路，不正是一个优秀的管理者的修炼之路吗？

成长，我们一起在路上！

致和我一起修炼的各位项目经理筒子们。

云主机项目的持续改进之路

文／雷蓓蓓

在打造团队的过程中，我们不可避免地会遇到这样那样“人”的问题。这种问题的表象有很多，你会遇到“不合作”、“消极怠工无进展”，甚至当面的“言语冲突”等各种情况。可以说，能否解决各种“人”的问题，是能否打造高效协作团队的关键所在。

刚开始启动云计算项目的时候，我们在云主机领域可以说是一穷二白，一个专家都没有。一年半的时间里，云主机项目从无到有，搭班子拉队伍，现在七七八八加起来，竟成了一个近20人的大团队。组织结构如下：

•　开发：计算组4人，网络组4人。

•　测试：3人（其中2人新加入）。

•　平台运维：2人，应用运维：3人（3人兼职）。

•　前端：1人；中间层：1人；交互：1人（3人兼职）。

这个快速扩张的过程，也注定将伴随着这样那样的问题。在开源社区基础上发展出来的云主机，天然地吸纳了很多好的工程实践（如持续集成、灵活的GIT分支管理策略等），这使得它在很大程度上具备快速发布的能力。但值得注意的是，由于云主机在云计算整体中属于底层核心模块，这一属性决定了在这个项目中，质量及稳定性的重要性要远高于功能交付的速度。因此虽然具备“快”的资本，但是我们面临的挑战却更多落在“快中求稳”。

本文从三个典型问题出发，从问题表现、原因分析、解决方案这三个方面进行剖析，希望将我们在持续改进中的点滴经验梳理出来并分享给大家。

第一回　合树立质量信心

1．问题表现

首当其冲的问题还是质量。在云计算六大模块同步开发的情况下，上层模块经常对云主机抱怨连连，提供联调时有时甚至在关键流程上都有问题，“不好好测试就放出来”、“就拿我们当小白鼠啊”这样的声音不绝于耳。这些让大家对云主机质量的信心无从建起。从数据上看，有史以来云主机线上的Bug占总Bug量的17%，如此多的漏网之鱼，作为底层核心模块，给上层其他模块、运维都带来不少麻烦。随着越来越多的线上应用陆续接入云平台，这个问题不解决，眼看着内部矛盾就要升级为外部矛盾，越发不容忽视。

2．原因分析

（1）队伍增长得很快。在相当长的时间内，测试人员的配比都非常低，8个开发对应0.5个测试，测试基本上只是给开发打工，只能保证最最基本的功能，其他更深度的测试根本无法涉猎。

（2）缺乏从用户的视角来检验产品。上层模块的应用场景、运维的应用场景与测试的视角相差较大，测试效果很难保障。

（3）线上Bug分析中，我们发现约有1/5的Bug其实来自社区，之前基本都是出了问题后才去社区找，然后把这个补丁合进来，应对太被动。

3．解决方案

（1）脚步放慢。在基本功能已经成型的情况下，进一步控制新功能开发在迭代中的占比与优先级。当然，这个也是基于我们的用户调研结论。用户对云主机的期望更多的是稳定，至于新需求普遍表示暂时没有，因此对我们来说盲目增加复杂功能其实并不明智，保持产品简单可靠才是王道。后续的产品规划中，除了一些为简化运维所做的改进外，至少云主机核心功能不再会做大的变动，而云网络和轻量级云主机基本都是另立炉灶。

（2）回顾总结。将线上Bug分析作为周会一项固定内容，集体讨论出整体层面上的改进措施，并跟进实施到位。

（3）查漏补缺。对已有测试用例进行全面梳理，与相关的开发、测试、运维一起集体回顾和完善，花大力气补充测试代码（增加异常、并发、稳定性测试等）。考虑到这是项长期工作，要确保将其分解到各个迭代中分批实施。

（4）走到前面。紧密跟进社区Bug，分析重现并评估影响，定期总结梳理，组织讨论应对措施，主动引入必要的补丁。

（5）以终为始。新功能需求确定后，测试用例同步设计并评审通过，然后将冒烟测试标准开放，让开发人员带着明确的“什么是完成”来进行开发。

第二回　合与用户建立联结

1．问题表现

虽然在我们的身边充斥着各种各样的群，运维群、租户群、用户群……但有意思的是，与用户之间沟通的有效性却并没有跟着改善。用户的意见通常是怎么到达我们的视野呢？有时它拐了几个弯从项目经理的饭桌上传到我们耳朵里；有时在某个内部论坛上，无意中听到环境不稳定的抱怨；有时在某个群中大家闲聊时，听到申请流程太折腾的吐槽。

2．原因分析

之前我们也召集过用户沟通会，人很多的场合下，大家你一言我一句，如果不是很迫切的共性问题，往往得不到深入挖掘和探讨；再加上可能由于总负责人在场的关系，使得用户在自由表达上多少有所顾虑，某些潜在问题可能一直被掩盖着。

实际上，我们缺少的并不是渠道，而是真正近距离贴近用户，打开倾听之门，让用户可以放心地畅所欲言，并相信他所说的最终能得到重视和反馈。

3．解决措施

（1）一对一探访。在征求了专业用研人员的意见后，我们决定采用一对一访谈形式来开展用户调研。事实证明这样的方式很有效，我们收集到了很多有 价值的反馈，并对用户的疑问面对面进行了更深入的探讨，“用户眼中的产品”带给我们很多不一样的视角。

（2）规范运维。作为直接且现阶段是唯一面向用户的窗口，运维质量很大程度上决定了外界对于云主机的认知，可以说是云主机对外的门面。在用户反馈的指引下，我们对运维人员的职责进行了梳理，明确了三种不同的运维分工：应用运维主外，平台运维主内，SA提供基础服务，各司其职，同时根据产品指定对外的统一接口人，以简化用户的沟通复杂度。

（3）用户引导在目前的情况下，我们发现产品用户基本上只能通过与运维人员的接触来了解产品，除此之外根本没有一个直接途径对云计算平台建立起整体认知。了解到这些后，我们将官网、面向用户的FAQ、只读账号等提上日程，并考虑对部分产品做更大程度的开放。

（4）信息同步。影响到产品方的事故，由总负责人发布正式邮件告知详情，一方面，通过正式渠道给用户一个明确的交代，对用户表现出足够的尊重；另一方面，事故的主要责任人需要起草这封邮件发给总负责人，这在无形中也构成了一种压力，促使大家对线上问题更加慎重。同时我们定期向用户邮件同步平台更新情况，让用户同步了解我们的最新情况，对平台更放心。

第三回　合打造高效协作团队

1．问题表现

虽然团队内部的整体氛围很好，不过可能受红色性格偏多的影响，总体稍显“散漫”。比如，在团队看来，迭代完不成的工作没什么大不了的，延几天发布也关系不大，特别是涉及前端或其他模块的任务更是如此。另外，从负责人层面来讲，对于开发之外的其他角色，比如QA、运维（后来演变为平台运维、应用运维）、前端、中间层、设计等，多少感觉有些鞭长莫及。几乎每次线上出问题都说要增强测试，但很难真正落到实处，缺乏项目层面有效的整体把控和推进。

2．解决措施

（1）重视完成。在每个迭代开始时，进一步明确、细化完成标准，涉及多 端的要彻底全部做好且从头到尾测好才算完成；迭代中实时关注发布倒计时，并对剩余工作超载的个人进行实时风险提醒，帮助其调整应对；在每个月的迭代总结中加入固定环节，全组公开讨论迭代计划完成率、未完成工作及原因，并群邮公布结果。从迭代前、中、后各项环节出发，来增强大家对完成的重视。

（2）站会与白板。云主机项目本身是参照云计算整体要求的，每个月一个迭代，计划会＋产品需求池＋回顾会＋总结会，可以说已经引入了一个敏捷的最小集。在此基础上，我们引入了站会与白板，给不同角色提供了一个更有效率的同步沟通平台，每个人都可以实时了解项目全盘的动态信息。在最近一次的总结会上，有超过半数的成员对站会给团队带来的改变深表认同，而我们也通过站会，将上述的很多改进措施真正落到了实地。

（3）绑定共同目标：一个团队必须要有一个为之奋斗的共同目标，才可以称得上团队。考虑到云主机项目所处的时期，我们花了很多时间来制定大规模推广目标，并与团队里的每个人一起讨论这个目标，通过目标让大家凝结在一起。

心得体会

在打造团队的过程中，我们不可避免地会遇到这样那样“人”的问题。这种问题的表象有很多，你会遇到“不合作”、“消极怠工无进展”，甚至当面的“言语冲突”等各种情况。可以说，能否解决各种“人”的问题，是能否打造高效协作团队的关键所在。

在这个过程中，最最重要的还是靠深入的洞察去分析问题，判断出问题的实质到底是什么，以此为基调来指导该如何应对。比如我们发现运维时常嚷嚷“这个我做不了，谁会做谁做！”，听这话也许你会认为这是态度问题，确实这个态度不能说好，但结合该成员一直以来的表现，我们最终判断实际这是一个能力问题。对于能力问题，我们的基调应该是“帮助”，帮助他提升“将自身工作提升到流程化层面”这个能力。

另外，在打造团队的过程中，一个绕不开的问题就是如何对负责人施加有效影响，让其在这个改变过程中起到助力的作用。如果负责人的理念与你的不一致甚至相违背，那么再好的想法，在实施过程中也一定会遇到阻力。这个时 候，你就必须多动动脑筋，想办法在一些公开动作之前，在你们二人之间先达成共识，这一点非常重要。在云主机项目中，我们对负责人的影响主要有以下两个方面：

（1）强化整体视野／责任。开发出身的负责人，受其行政职责所限，很容易形成的一个惯性思维就是“我只管开发，质量、运维是他们的事”。想要改变这一点，就需要你时常站在产品的角度跟他对话，让他意识到质量、运维做不好，开发做得再好也没用，引导其关注产品整体。

（2）培养用户视角。做开发惯了，离用户越来越远，反正还有运维呢，开发时才不会考虑那么多。通过用户调研的机会，我与负责人一起主动接触用户，近距离听到了许多来自用户的真实声音，这让他对用户的“苦”感同身受，回来以后有很多改进，立马就推进去做了。

以上就是我们在云主机项目持续改进之路中，遇到的问题以及所做的思考与尝试。持续改进是一条永无止境的道路，我们永远在路上！

第3章

宽度扩展

探讨了若干个项目管理与业务结合的实战过程中的实际问题以及我们的实践方式。这章集结了数据分析、跨项目沟通、项目管理工具等实践，读完这一章你便能清楚地知道该如何掌握项目的方方面面，它们覆盖整个产品面的管理业务。有了这些工具与武器，你便能在项目中如鱼得水，做深做透。深入产品，帮产品赢！

数据收集埋点流程梳理

文／刘煦萍

数据对产品的重要性毋庸置疑，可要想让数据收集这个系统化的过程顺畅透明起来还是不容小觑哦。下面就一起来看看小L遇到的问题以及她是如何解决的。

数据对产品的重要性毋庸置疑，每个产品都会有自己的核心数据指标，而这些数据指标是怎么收集和呈现出来的呢？接下来笔者讲述当时经历的一个2C的通信社交应用项目中的情况，希望能对你有借鉴意义。

首先，要确认产品明确的核心业务指标，然后根据核心指标定义各功能的核心数据考核指标。虽然此话题不是本文的重点，但却是前提。如果产品没有核心数据指标，数据的收集梳理工作也就不重要了。相信每个产品都有，而产品类型不同、产品所处的阶段不同，所定义的核心指标也会相应发生变化，业务在不同发展阶段以及产品战略调整时需要其与之相适应。你可以简单地问自己几个问题：

（1）我们的产品是否有明确的核心业务指标？

（2）这些指标是否符合目前产品的阶段和现状，或者说是否从未发生过变化？

（3）这些明确的核心指标是否分拆到各功能考核指标中？

因为产品在做的功能需要符合产品目前定义的核心指标，也就是产品目前的定位。所以在产品规划接下来的功能时，需要定义出如何考核接下来要做的这个功能，并进行验证是否符合产品的方向。

有了核心考核指标，接下来就是如何落实。一般2C的应用，数据来源于用户行为，需要通过记录用户的操作行为，来形成数据进行分析。而同样的数据不同的人分析的结果和给出的方案会差别很大，这也是数据分析人员真正见 功底的地方，笔者就不在这里班门弄斧了，推荐一本书《精益数据分析》给大家。笔者在这里想讲的是，定义了要考核的数据指标后，如何让它落地。一方面，考核的数据指标是由很多、很细、很分散的各种数据形成的；另一方面，从功能开发、数据收集埋点、测试验证到上线，之后还要经过线上用户一段时间的使用后才能进行分析和验证，整个过程和周期较长，如果要提取的数据定义错误、埋点错误，或者统计错误，都会影响我们及时地验证、反馈和下一步的计划，所以此项工作需要重视起来并严格执行。先看看当时我们团队遇到的一些问题吧：

（1）有时候会出现未提数据收集埋点需求的情况，待上线后要查看相关数据时才想起，此时也只能顿足捶胸等下个版本再补了。

（2）数据提了，但可能有遗漏不完善，或模型不对。毕竟同样的数据不同的人组合得出的结论会差别很大。另外，由于不同的人可能会在同一功能不同版本上交叉负责，有些交互上的变化需要埋点数据同样做更新，但会由于信息的不透明和未及时沟通而导致以下问题：有些埋点已经失效，看到的数据其实含义已经发生变化，前一个人的漏斗分析已经失效等。

（3）埋点数据无测试和验收环节，需求负责人（需求负责人，可能是策划、交互或其他人，这里统称需求负责人）等版本上线后去查看相关数据，此时如果发现有问题，而且是客户端埋点的问题，已经发的这个版本就没有办法补救了，只能等下个版本。

问题1、2的根本原因就是对数据收集埋点的重视程度不够。由于不是每个需求变化都有数据收集埋点工作，所以这个非必选项在意识不够的情况下容易被忽略。可是需求负责人怎么会不重视数据反馈的实际效果呢？又经过一番摸底后才知道，原来很多人没有直接的数据权限，那么前面的疑问就自然消失了，要解决的问题就变成了：1）提高大家对数据的重视程度；2）提供大家可见的数据。找到了问题，方案就不会太远了。

再看看问题2，除了刚才上述说的原因外，还需要一个专家指导或者评审机制，来尽可能确保需求的正确性。另外，还需要解决埋点数据透明性的问题。整个系统的埋点数据收集如果是公开透明的，那么每个需求负责人就可以方便地查看他本次所改动的部分之前是怎样的情况。然后有变化随时更新，大家一 起来维护这张表。

问题3需要与测试和开发们沟通是否有好的办法。经过一番沟通，好的是我们可以在发布前验证埋点数据的有、无和对应属性的正确性，不好的是目前暂时无法验证数据的精准度，即用户在客户端触发了事件我们可以验证事件是否有以及是否对，但还不能精准确认用户操作的次数和后台显示是否匹配，小数据可以验证，大数据就难落实了。这个我们可以逐轮迭代进行完善。

有了解法，很快我们决定召开一次数据收集埋点培训／动员会。目的也很清晰：1）提高大家对数据收集埋点的重视程度；2）解决大家看相关数据的问题；3）建立数据收集埋点的整个流程（见图3-1）。所以大会也就分为三部分：1）“安利”，目的在于提高大家对数据收集埋点的重视程度。2）介绍埋点业务知识和数据考察核心指标等，用于让大家了解常规考察的核心指标是什么，这也是文章开头讲的部分。3）介绍数据收集埋点工作流程，在整个版本过程中有哪些环节以及如何开展。前面两点就不多介绍了，第三点做个介绍供大家参考。

图3-1　埋点流程

数据收集埋点工作在整个版本过程中分为三个阶段：计划、执行和验收阶段。

1．计划阶段

通过定义的指标，计划并确认要收集的数据（见图3-2）。

需求负责人确定需求的同时需要提数据需求，根据要收集的数据，确定需要通过何种方式收集，可能是服务器日志，可能是客户端埋点。根据数据埋点标准模板提交给指定同事及数据组同事进行审核，用于确认数据收集埋点的合理性及格式，比如有些事件可以合并，将多个事件转变为一个事件多个属性等。指定同事确认没有问题后提交开发进行确认和埋点。

图3-2　计划表

2．执行阶段

各端开发根据已确认的埋点需求文档进行埋点。

3．验收阶段

本阶段分为三步：

1）在测试阶段，开发提供调试做埋点，需求负责人可以通过触发事件、界面显示所被触发的事件进行简单的验证。

2）上线前，指定同事通过平台查看数据收集埋点的情况，做二次确认。

3）上线后，需求负责人观察线上数据是否有异常。

有了明确的流程和规范后，接下来就是严格执行啦！而在跟进的过程中可以不断地优化和完善整个过程。当然最重要的关键点还在于意识，如果大家意识到它的重要性，即便不知道如何做，也不会成为绊脚石。

打破“原地转圈圈”的魔咒

文／曾璎珞

也许大家都感受到在产品和团队中总是被“原地转圈圈”的魔咒所“诅咒”，但是当我们设定好目标，有效地度量目标，并且及时从中获得反馈，就能够敏 锐地感知到产品脉搏的每次跳动，就能始终呵护团队火热的心，保持住它的温度，一齐坚定地走下去。本文将从研发和产品两个角度，教你如何去打破“原地转圈圈”的魔咒。

魔咒魔咒

公司一年一度的体检季又来了！

你是否也有所期待，期待自己体质变好、变强壮，不断地催促自己要锻炼、要有好的生活作息规律？然而体检结果下来了，却看不到任何正向的变化。

这只是很小很小的一个点。我们每个人都有许多期待，都在憧憬各种美好。然而，梦想成真的时刻似乎总是那么遥不可期，因为时间这把杀猪刀，会让我们一步一步放松警惕，一步一步把我们拉扯回原点。

个人小小的改变，都容易陷入这“原地转圈圈”的魔咒里，更何况产品和团队呢。

偶遇高人指点

因缘巧合，觅得一位高人指点，他讲述了这样一个故事。

我的孩子啊，小时候特别喜欢喝可乐，一天能喝好几罐，简直当水来喝。好说歹说太多次了，没有任何改观。

既然劝说解决不了问题，那只能换个法子了。

于是，拉他到身边，这是最后一次提到可乐的事儿，“孩子啊，喝可乐了，会让你变得极其虚弱，作为父亲，我很担忧啊。不过，从今往后，我不会再制止你喝可乐了。毕竟你已经长大了，你自己来决定吧。”

我这一番话，让孩子绷紧的心完全松弛下来，接下来几天，冰箱里的可乐消耗得异常迅速。

双周的周六，是家庭园艺日。孩子负责搬运肥料袋。我能够察觉孩子神情上的异样。我不语。接下来一周，冰箱里的可乐还有剩余。

过了两周，又是家庭园艺日，孩子继续搬运肥料袋。看到他紧张而沮丧的表情，额头上还渗出了汗珠。我默默不语。接下来，冰箱里的可乐，竟然纹丝不动。

孩子的妈妈很诧异，问孩子，他却平静地答道：“那玩意，早就不喝了。”

听了这个故事，激起了我强烈的好奇心，忍不住问为什么。

高人神秘地一笑，继续道出了接下来的故事。

我当时表达出“喝可乐会让身体虚弱”的担忧，其实已经在他心中种下了一颗种子。

接下来，趁孩子睡着了，我每次都会在肥料包里增加一点点分量。他第二天去提肥料包，会感到自己的力气变“小”了，身体“虚弱”了，渐渐地，对可乐有了恐惧，不再喝了。

后来，孩子长大了，也知道了我玩的这个小把戏，但是，他仍然不愿意碰可乐，因为“喝可乐会让身体虚弱”的阴影，早已扎根在他童年的记忆里。

孩子为什么会拒绝喝可乐，是因为父亲让他“真实地”体验到了喝可乐的后果，而且后果很“严重”。

行为，产生结果；结果，调整认知；认知，决定行为。某种行为之下，

（1）如果我们持续获得的结果反馈是负面的，那么，我们很容易放弃该行为。

（2）如果我们持续获得的结果反馈是正向的，那么，我们就会拼力强化该行为。

（3）如果没有结果反馈，那么，我们的行为模式就不会有任何变化。

趋利避害是人的天性，而反馈触发我们做出调整。当我们埋头做事，较少获得反馈时，就很容易原地转圈圈。过程做得对不对、好不好，不清楚；距离理想和目标有多远，很模糊。所以，要打破魔咒，就需要持续地寻求反馈。

获得破解之术

那么，如何寻求反馈，打破魔咒呢？

步骤有三：1）确定目的和预期目标；2）有效度量；3）持续跟踪。

其中，有两类因子，需要重点度量：

（1）渐变因子，用以表达目标的完成度。

（2）随机因子，用以映射具体过程。

需要渐变因子，很容易理解，但是我们为何还要关注过程中的随机因子呢？

目标很重要，然而，过程更重要。有了目标之后，关键在于过程的落实。

度量渐变因子，映射宏观进展。而度量随机因子，却是引导团队关注当下每项具体事务的实时效果。随机因子，看似随机，却和我们的一思一念、点滴付出息息相关。在我们付出之后，马上获得了反馈，而每次的反馈都因我们付出略有不同，这是不是很让人着迷？试想一下，如果打地鼠的游戏里，每次地鼠都是从同一个洞里冒出来，你还有没有兴趣挥舞着棒槌去敲打它呢？工作也是如此。当我们感到乏味时，或许仅仅是因为我们忘记了及时去获得反馈。

获得破解之术后，我们开始在研发过程和产品环节进行改变，尝试打破原地转圈圈的魔咒。

研发过程中的尝试

1．研发过程的困境

研发阶段，前松后紧，开发任务常常临近提测时，才匆匆收尾。这常常导致提测质量不佳，或者提测时间延后，风险积攒在测试阶段爆发，最终导致项目延期发布，或者带着显性的Bug上线。

2．新项目中的尝试：进行目标、度量和跟踪

项目启动会上，与团队明确定下两个项目的里程碑：1）A日期以前，完成开发；2）B日期以前，完成上线前确认，剩余Bug不得超过10个，且不允许存在严重的Bug。

项目过程中，开发阶段，通过燃尽图，持续跟踪开发当前剩余的工作量（见图3-3）；测试阶段，持续跟踪每日新增Bug，以及当前剩余Bug的总数和严重 Bug的数目（见图3-4）。

细心的读者会发现，这里主要涉及两项渐变因子：开发当前剩余的工作量和剩余Bug的总数；同时，还涉及一项随机因子：新增Bug数目。

图3-3　研发阶段研发工作量的燃尽图

图3-4　Bug的修复趋势

3．结果与启示

在研发过程中，当我们设定明确的目标、给予一定的度量，并且应用趋势图持续跟踪每日的状态，我们发现了两个有意思的现象：

（1）团队的拖延症消失了。研发阶段前面50%的时间里，消化了70%以上的工作量。

（2）提测时间提前了。团队为了控制剩余Bug的数量，一致采取了分批提 测的方式，令Bug得以在更早的时间被挖掘出来，也更早地被解决。测试后期，每日Bug数量始终控制在10个以内。

最终，项目按预期目标完成交付。

我们在新项目上的尝试，给了我们启示：明确项目目标，并且持续跟踪，每个人都能够很清楚我们将要去哪里，我们现在在哪里，我们要往哪处使力，此时，团队的状态已经发生变化，每个人不再是被驱赶着前进，而是整群人被目标牵引着、相互依伴着向前赶路。

我们在产品过程中的尝试

1．产品过程的困境

与研发阶段相比，产品过程中的困境，涉及的维度更多，也更加复杂。

对于产品接下来的方向，团队里有不同的声音，有人坚持在小众的基础上进一步创新，有人坚持平台化、工具化、大众化。过去的半年时间里，我们在每个方向上都有尝试，而每个方向上也都有着各自不同的障碍。目标发散、时间和人力的局限……导致我们每个方向的投入都未让自己满意。

2．小心翼翼地尝试

第一个问题，首当其冲，“我们的目标是什么？”

经过很长一段时间的讨论，团队开始意识到无论走哪条路，我们当前最缺的，是用户的规模。只有当用户数拓展到一定的规模，曾经的A，B和C项目才有可能发挥出更大效力。于是，大家将目标收敛在产品用户总数和用户活跃度两个关键指标上：在保持用户活动度A的基础上，在9月底拓展用户总数到B；为了达到这一点，我们的每日用户新增数必须翻倍。

在确定目标的基础上，团队进一步规划：

（1）列出所有相关的工作，涉及曝光、用户激励、落地转化、注册门槛及用户挽留等各方面。

（2）针对每项工作，按转化逻辑，计算出可能带来的注册用户数预期。

（3）按预期，对工作进行排序，指定具体责任人负责推进。

这里涉及三个渐变因子：用户注册量、每日新增用户数和日登录用户数， 通过数据日报呈现；同时，还涉及一系列的随机因子：每项具体工作的效果，由对应工作的责任人负责跟进。

3．结果与启示

如图3-5所示，团队7月中旬完成规划；8月初，部分工作开始呈现效果；9月初，用户新增速度是以前的两倍；9月中旬，用户注册量提前达标，而日登录用户数也在9月底的最后一天达到目标。借由话题营销和研发功能快速响应，从竞争对手处争取到一大波用户，带来活跃度的新一轮提升。

图3-5　产品关键指标

团队两个半月的努力冲刺，收获了阶段性的成果，这让大环境下的我们有机会获得更多资源，让产品走得更远。来听听身处其中的策划和运营同伴的心声：

“对，我们就需要这样的目标，并且是跳一跳可以达到的目标。”

“产品和运营工作规划，难以像项目规划那样一步到位，因为有太多的不确定性，也有太多的偶然性。虽然，我们有一个长长的任务栏表，但是，我们通常只能规划几周或一个月的工作范围，也是优先级最高的事务。”

“有些新的事务，我们一开始无法预估它的价值，会选择快速去尝试，快速看结果。如果值得做，就再来一轮优化；如果不值得，立马终止。”

“每项事务，都必须要有完整的目标。如果目标不完整，那么我们对成功的概念是很模糊的。如果失败了，也无法获得完整的经验教训。”

“当每项工作都定义了目标，我能够更加清楚，应该往哪处使力，方案讨论时，我能够更有力地引导大家快速找到有效的方案，避免在细枝末节上纠结太久。那句话怎么说来着？哦，对！‘将军赶路不赶兔。’”

“嗯，我开始看到自己的工作能够带来具体多少价值！”

写在最后

产品，或许，因一个创意而产生，但是，它却需要至少5 000个创意去发展和成长。路途漫漫，充满艰辛，容易彷徨，容易迷惘。只有当我们设定好目标，有效地度量目标，并且及时从中获得反馈，才能够敏锐地感知产品脉搏的每次跳动，才能始终呵护团队火热的心，保持住它的温度，一齐坚定地走下去。而此时，团队的心理能量位开始跃迁，“原地转圈圈”的魔咒也正在解除。

输了你赢了世界又如何

文／曹智清

我失去你，赢了一切却依然如此冷清。输了你，赢了世界又如何！面对互联网的瞬息万变，在产品发展中，我们往往一心盯着业务，盯着KPI，然而对于一个产品来说，用情怀呵护，营造一个温暖的团队后盾同样很重要。

记忆里小说中的桥段：某潜力股青年，为了挣得让女友幸福生活的家产，在外打拼多年，成功归来却发现物是人非。输了你，赢了世界又如何，多么痛的感慨！

身边不少新闻段子：某公司年轻高管，坐拥千万元乃至上亿元家产，终因劳累过度，意外猝死。输了自己，赢了世界又如何，多么痛的领悟！

其实，我们做产品、做项目的过程也不乏这样的经历。

互联网世界，瞬息万变，每个玩家都在玩命地快快快！每块业务都在飞速发展！当你在风口上的时候，即使你比猪还胖，你也必须要飞起来！

这时候，所有的眼睛都盯着业务，盯着KPI，盯着发展；所有的需求都只能应对最重要的业务功能或者运营活动，影响稍小点的用户Bug只能靠边站；各个版本只来得及实现需求中最最重要且紧急的，并且还不断砍掉些看起来不那么重要的小点；运营也是忙得飞，用着虐心的后台也得把长长的内容给录入进去，还要上接用户下接供应商拢起无数条线头……加班，根本停不下来！

有没有感觉我们在拼世界的同时，似乎忽视了什么？

忽然有一天，线上开始连续出事故，一看原来都是以前欠下的债！然后团队规模是之前的两三倍，但产能总上不去，比以前多出不了多少活，而且大家对成天的加班怨声载道。再然后，一个一个员工开始离职，核心功能开始无人能懂……

和谈恋爱一样，痛过苦（哭）过，后来，我们才学会如何去爱。原来我们的产品在拼世界的时候，永远需要另一股力量，打造团队更坚实的基础，营造团队更温暖的港湾。这是产品老大们都要敬畏的生存现状，是团队都要注意的发展平衡，更是每个项目经理要固守的项目根本。

现在从三个角度说说如何关注和打造这样的基础。

人

指标：新老员工比例不应超过1:1，其中新员工包括正职／借调＋实习生

原因： 无人指导和关怀的新人就是添乱，除了搞乱那本已有点乱的代码外，更容易造成老员工烦躁，新人本身的诸多怨气最终导致不稳定。另外，当新人从人数和文化气场上强过老员工时，原有的文化会被颠覆，种种不和谐“应运而生”。

应对： 不要在短期内招过多新人，招一批带一批，成熟一批后再招一批；每个团队都要建立自己的新人入门指南，每个新人要有正规的方式介绍给团队；从了解公司到权限申请到各种规范，都要有培训；每个新人都要确定一个 导师，导师帮助新人制订上手计划，每周至少一次深入沟通，建议新人每周简单写一下心得，作为个人积累和问题反馈。让新人成为导师所负责领域的助理，也是种不错的梯队培养方式。

事

指标1：研发规范执行到位的程度

原因： 别以为上线申请或者更新交互稿少群发了一次不是什么大不了的事儿，也许正是因为一次少发，导致一个线上事故。千里之堤溃于蚁穴。研发规范执行得松散并非一日的倒退，长此以往会造成团队散漫，同时又给产品埋下无数的雷。

应对： 言必行，行必果。项目经理必须对日常研发规范的执行起到强力维护作用，并根据实际情况不断优化。某些做法如已不再适合团队，就要正式将其退役，而非不了了之。从站会的频率和时长、周会周报的频率和内容、策划交互稿的评审和群发，到提测和冒烟的执行、上线审批及效果追踪，虽然繁复但需坚持。产品线上无小事，意识都是点滴培养积累的。

指标2：研发效率／产能，不是团队负荷度，而是产能吞吐量

不要在意每个人的负荷是不是满的，而要关注相同时间内完成了多少需求量，或者需求的平均响应时间。

原因： 所有人都被工作塞满的做法是不科学的。每个人都可以装作被塞满了，这种非常被动不信任的方式副作用很多。产品真正需要的不是一堆加班的人，而是一堆好用的功能。所以，关注这些功能多久能被完成是更合适的。

应对： 先记录，就能发现团队的问题。然后从流程优化、团队培养、技术架构这些层面引发更多的思考和改良，自然开始有“还技术债”的需求进入视野。另外，关注产能还可以帮我们更快地消化需求队列。

指标3：版本中是否出现过技术优化需求

原因： 没有不欠债的技术团队，但如果版本计划里已长期无法排下技术优化需求，那也就意味着技术问题长期堆积，架构风险日益增高，迟早有一天以 重大线上问题的方式集体爆发出来。

应对： 在提升产能指标的过程中，重要且紧急需求的响应加快，逐步会有空间来做重要的架构优化；另外，架构优化中重要问题要提升优先级排上来，整体的架构优化要排计划，并且获得产品老大的支持。

结果

指标：线上事故频率及严重度、修复速度

如果说产能代表了速度，那么线上事故则代表了质量。两者并举才能做到又快又好。

原因： 废话，不多说。

应对： 做好了1和2，线上事故整体会下降。当然，也需要针对性地做些提高，比如上线流程、线上事故应对预案等。对所有的线上事故都要做记录，分析根源，以及提出改进措施。当事故频率显著升高时，其实已经提示有重大的研发过程问题了。

当人和事指标出现偏差时，往往是问题的早期，要尽快采取措施进行纠正；而当结果指标报警时，团队的健康程度已经发生了问题并导致了产品不良结果，需要花更大力气来拨乱反正了。

对事的问题要防微杜渐，对人的问题要心存敬畏，带着团队去打拼世界，才是长久之计！

初试跨部门项目

文／靳霄

跨团队的项目形成的是一个虚拟团队，人事上的汇报关系不存在了，人员之间关系的复杂性增大了，管理这种类型的项目就更需要抓住其关键点。

故事背景

在一个名叫“天狼”的互联网公司，有一个新兴的项目“打击职业差评师”。之前没有界定过这是属于哪个部门的业务，D1部门和D2部门都认为这项业务对公司比较重要，在相互不知情的状况下，都准备着手开始做。人员汇报关系如下（见图3-6）

（1）部门D1、D2和PMO是同级别的部门。

（2）L1是部门D1的负责人，该部门先进行“打击职业差评师”项目的开发，对业务比较了解。

（3）L2是部门D2的负责人，该部门也准备开发“打击职业差评师”项目，平时专注于算法研究。

（4）P1是产品方负责人，和L1、L2是同一级别的，这个项目是为P1的产品服务的。

（5）H1是公司总监，是L1、L2和P1的领导。

（6）小P是PMO的初级项目经理。

图3-6　项目人员汇报关系

L1和他的团队先完成了一个简单版本，产品方P1比较有兴趣。L2的团队对于“打击职业差评师”项目还在设计阶段，在找P1时发现L1也同时在做这个项目。究竟该谁来做这个问题最终摆在了H1面前。由于各有优势，几天后，L1、L2和小P收到一份H1的邮件：

（1）“打击职业差评师”由D1和D2两个部门合作开发。

（2）D1部门负责和产品部门联系制定需求，除算法之外的开发工作都由D1部门负责开发。

（3）D2参与需求的讨论和制定，核心算法实现由D2部门完成。

（4）由PMO负责这个项目，小P是这个项目的项目经理。

作为项目经理的小P，会在这个跨部门的项目中遇到哪些典型的问题呢？

如何进行授权

小P得知要负责这个项目后开始考虑如何保证这个项目成功交付。这两个项目组的主要人员都是小P之前没有接触过的，公司里的项目经理是个横向的管理者，弱矩阵结构，加上之前负责的项目都是一个部门内部的。对于这个项目，小P有些顾虑：这个项目的管理方式需要和之前的那些项目的管理方式有哪些不同？小P觉得以前介入项目，只要部门负责人召集团队成员，介绍一下小P是项目经理，他接下来就可以名正言顺地开展工作了。但是现在这两个临时组在一起的项目组，L1和L2都没有召集会议宣布他的角色和合作方式。

小P找到PMO里带他的老K咨询。老K问了情况之后，给小P分析：一个部门内的项目，项目经理的角色授权来自部门负责人，所以只要部门的负责人召集大家介绍一下你，就是一个公开正式的授权。而这个跨部门的项目你的授权实际上来自公司总监H1，L1和L2现在之间还心存一些芥蒂，都不想太主动出面做这件事情，总监级别比较高，具体项目的细节不太会参与，更不会主动替你安排这件事。所以公开场合正式授权这件事必须你自己来。小P惊讶地看着老K说：“自己给自己授权？怎么操作啊？”老K说：“你去看一下我们的项目经理工具箱——流程模板库，里面不是有个‘项目启动会’的模板吗？就用它。”

小P看了启动会的模板，发现召开项目启动会是为了给团队明确以下几点：

（1）项目的范围。

（2）项目的进度计划。

（3）人员结构。

（4）项目基本的合作方式。

小P看了之后，如获至宝。心想我把这个会召开了，实际上就是向项目组正式宣布了这个授权，H1不出面也没有问题。同时启动会的模板也给出了项目启动前要准备的内容重点。

接下来小P就开始和L1、L2就启动会里应该包含的各项内容进行沟通和确认。

如何跟进和调整计划

小P觉得以前的项目，项目计划的制订只要自己和负责人达成一致就可以了，现在有L1和L2两个负责人，需要和这两个人都达成一致。而这个项目在L1和L2心目当中的优先级也是不一样的。小P了解到，L1和L2手里都同时有多个项目，L1的想法是既然H1提出需求都是由我主导来定的，基本上这个项目算是我来负责了，这个项目在我自己几个项目当中不是优先级最高的，在现在人员比较紧张的情况下，其他高优先级的项目有需要我还是要把一部分开发人员从这个项目上抽走的，所以希望这个项目不要赶得那么紧，项目的效果才是最重要的。而L2的想法却不一样，本来他们想独立做这个项目的，现在他们只负责算法，实际上变成了为L1团队工作，L2就想把这个版本赶快做完，他们的人就可以退出了，后续就交给L1去维护和更新。

在这样的情况下小P该如何把握项目计划的制订呢？小P又来请教老K，老K听了情况之后分析说：“项目计划本身就是个‘渐进明细’的过程，同时根据L1和L2对项目的不同态度，必然会对这个项目的时间计划增加一些变化和调整的因素，对于这样一个跨部门合作的项目，最重要的是做好时间调整评估、决策、通知和记录机制，保证相关干系人能及时获得时间变更信息，评估影响，确保变更公开透明，这样保证以后如果有异议的话，有据可查。”

根据老K的提醒，小P制定了每周对项目计划进行评估和讨论的机制，周会上通过确认当前任务的完成情况、所存在的问题和风险，对当前计划的可行性进行评估，最后由L1和L2对于决策进行确认。之后，小P把变化的情况记录在一个包含项目各个关键节点时间（需求完成的时间、概要设计完成的时间、L1团队开发完成的时间、L2团队算法完成的时间、提测时间、测试完成时间、上线时间等）的Excel表上，最后以邮件形式通知所有会受到影响的相关人员，并将文件保存在服务器上。

如何解决冲突

L1和L2由于前期都想做这个项目，在竞争时相互之间产生了一些心结，最后由于总监H1的安排才一起合作这个项目，所以在合作的一开始并不是那么顺畅。L1由于要负责这个项目满足产品方的需求，所以对做出来的实际效果要求比较高，而将项目的时间进度放在第二位。L2是个技术派，前面也说过，对于这个项目，他的想法是做完后快速抽身，所以时间是他最关心的。一个追求软件的效果，另一个追求快速交付，导致在合作中，经常出现L1对软件的效果不满意时，想调整时间进度，让L2团队优化算法。在一次周会上，当L1再次因为这个事情提出调整上线时间时，L2就有点激动了，说这个时间是前面和你确定过的，不能为了效果无限制延长时间。当时两个人就在会议上僵了下来，没有讨论出结论。

会后L1找到小P说：“小P，软件的效果不好，达不到客户的要求，算法这边是一定要改的。L2不愿意合作，你说说看，他这算什么态度啊！你是项目经理，协调的工作可是你职责之内的事啊。我看不行的话，L2不积极合作的情况你要反映到H1那里，H1发话的话L2应该没话说了吧。”

小P想了想，正好之前参与了一门管理学课程的培训，有一个分析和解决管理者和下属之间矛盾的方式可以在这时候使用。

小P问L1：“你先消消气，我们分析一下。你觉得L2在这件事上不合作，是心态问题，还是能力问题？”

L1：“L2的技术肯定是没问题的，他带的算法组技术是很强的。主要是心态问题，因为一开始竞争这个项目的缘故，他认为总监对他不认可，所以现在做这个项目不是很投入。”

小P：“那看来解决了他的心态问题，这个问题就会化解了？”

L1：“那肯定的，对L2我还是比较了解的，他只要想干的事，加班加点都做得出来。”

小P又问L1：“你在这件事情上要的结果是什么？是让H1指责L2不合作，出口气吗？”

L1想了想说：“那倒不是，我要的还是希望L2对这个项目比较投入，项 目成功才是我最关心的。其实对L2的技术能力，我还是佩服的，想以后继续合作下去。”

小P说：“如果是这样，我帮你出个主意。听说这周你要和L2一起去向H1汇报项目进展，你在汇报时，大力恭维一下L2技术能力，说说这个项目主要是靠他们团队的算法实力才能得以成功，我想这样可以化解他的心理问题。你说呢？”

L1想了想，笑着对小P说：“看不出来嘛，你鬼点子挺多。”

过了一周，又到周会时间了，L2主动提出要优化一下算法。

小P的反思

跨部门的项目与普通项目的不同点主要在于整个团队完全是由于项目的原因形成的一个虚拟团队，人事上汇报关系的约束力不存在了，人员关系、部门利益的复杂性增加了项目管理的难度，因此更要依靠管理的技能来保证项目的成功交付。如何让多个团队接受你的项目管理方式？如何让整个项目的计划和决策机制公开透明？如何在计划执行中两个团队之间出现问题时去及时化解？这是小P认为相较于一个部门内部的项目会有的三个难点。希望小P成长过程中的小故事会对大家有所启发。

小议合作项目中主要风险及其应对措施

文／陈海春

不同公司间的合作项目由于公司间的文化、地域、流程等因素的不同，导致这类项目中的风险管理也有所不同。本文介绍了合作项目中常见的四类风险及其应对措施，包括跨地域沟通、上线标准不一致、资源投入不对等、商务谈判和研发并行。

项目管理中的风险管理是极其重要的一个环节。广义来讲未来的不确定性就是风险，识别风险可以从项目不同的阶段（需求、视觉交互、开发测试、上线过程、线上运营等）、不同的领域（运营、客服、策划、技术等）通过头脑风暴的形式而收集到初始风险列表，进而通过概率影响矩阵分析法，选出那些出现概率较高和影响较大的风险，与之制定相应的风险应对措施和并定期监控。

当然不同类型的合作项目需要注意的风险类型和应对措施也是千差万别的。本文根据笔者近期实际参与的两个合作项目，提炼和总结出三个主要风险及建议的应对措施和大家分享，希望能对你有所帮助。

合作项目指的是和其他公司合作共同完成项目。主要的合作模式为共同开发、资源互换：利用网易线上资源和技术能力置换合作方的相关线上、线下资源。双方不是外包与服务关系，没有哪一方是客户，双方都为最终产品的使用者（真正的客户）服务，期望通过产品上线后的导流模式、分成模式来达到双赢。

笔者通过对过去一年多几个跨公司合作项目的交付，总结出类似项目主要的风险有四类：跨地域沟通、上线标准不一致、投入资源不对等、商务谈判和研发并行导致的风险，以及在项目中的应对措施。

跨地域沟通风险及其应对

合作类型的项目中第一个风险就是如何进行顺畅的沟通。笔者所参与的合作项目的合作方都分布在不同的城市（北京、深圳、东莞等），与杭州相距较远，无法做到双方团队长期在一起面对面工作，因此在项目中如何降低此风险对项目的影响成为较高优先级的事情。

在项目启动阶段，一旦双方业务合作协议达成后，安排业务、产品、技术核心团队成员在一起办公一段时间，也许会稍许增加项目成本，但带来的好处显而易见。各位成员能够面对面地进行需求讨论、系统接口确认、交流感情，为后续的合作打下良好的基础。需求讨论确认后还需要双方负责人签核，确定需求范围，界定双方合作的边界、各自责任人及进度要求、风险与应对。

双方团队开始通过建立IM群的方式来加强沟通合作与交流，但是使用了IM群聊功能一段时间后发现有三个主要问题：

（1）对文字描述的短句信息的理解有时不一致，刷屏太快，比较难以总览全部信息内容。

（2）对于策划稿／交互稿之类的文档通过文字很难描述和讨论清楚。

（3）有时连续几天IM群没有人发言，项目内容状态无法及时有效地更新。

在和对方的项目负责人沟通这些问题后，除了使用IM群进行日常细粒度任务沟通外，还制定了固定时间的联合周会制度（双方的接口团队成员参加此会议），利用会议电话和共享桌面软件召开周会。在周会上双方就各自的进展进行阐述和沟通，需求问题、视觉问题、交互细节直接在会议上描述。会议中还包含对上次会议的决议进行跟踪和状态确认。

会议后由项目负责人发出会议纪要，对周会上结论的内容和会后行动进行通报和跟踪。典型的会议纪要邮件记录如表3-1所示。

表3-1　典型的会议纪要邮件记录

会议过程记录及会议结论

列出双方在会议上达成的共识或进展情况

会后跟进事项及责任人

清楚描述事项内容、完成标准、计划完成时间及责任人

下次会议时间

在项目临近上线的前两周时间由于Bug较多，将周会变成了更加紧密的每日会议，对每日新增的Bug的严重程度和优先级进行共同决策，明确各Bug的责任人负责后续修复和验证。

上线标准不一致导致项目延迟的风险及应对

上线活动通常是互联网项目一个版本或一个里程碑的结束点，同时也是相关运营活动的开始点。倘若合作双方上线标准不一致，将会直接导致项目的延迟或发布内容受到影响。不同公司的文化和流程对上线的标准有不同的理解，因此很容易导致项目不能按时发布的情况。

正如墨菲定理所言：有可能出错的事情，往往就会出错。我公司某业务部 门在2013年10月与D公司合作的项目中就由于双方对上线标准要求不一致而导致项目延迟两周后上线。

该合作项目在我方的项目流程中有条不紊地向前推进，我方各团队确认通过了上线评审后发出上线通知邮件并准备于第二天进行上线。但是就在邮件发出30分钟后收到合作方的电话，要求暂停上线，因为对方公司的内部各部门（研发、市场推广、信息安全、法务、客服、运维）间还没有完全验收通过，其相关的客服、运维支持工作没有准备就绪。后续两周中对D公司每个团队反馈的Bug、建议进行沟通和评定，待对方所有相关团队确认后项目才顺利上线。

总结起来，就后续项目如何应对此类风险的方法有：

（1）在项目初期和对方明确讨论并形成双方确认的上线标准，以及相关的测试、体验活动时长。双方在项目中期明确定义运营活动的准备就绪时间点。

（2）选择双方都能接受的上线时间点。由于对方是外资企业，周末难以协调到人员进行加班，所以上线时间尽量避开周五，以减少如果周末发生线上事故可能无法及时召集双方成员处理的风险。

项目资源不足的风险及其应对

同一合作项目在不同的公司里有着不同的优先级和期望，如果大家没有对项目目标达成良好的一致，则很可能会导致人力资源投入不足，或者中途出现由于人力资源不足而暂停或取消项目的情况发生。例如在部门与某国内手机制造公司进行手机App预装合作项目中就发生了类似的情况。双方在项目初期投入了不少精力进行商务沟通、策划讨论和交互稿评审，在项目即将进入编码阶段时，由于这家手机制造公司团队开发人力紧张，其团队为了保证该机型上的其他系统软件能够顺利发布而没有人力进行本App合作开发，导致项目无限期暂停，我方前期的产品开发投入付诸东流。

此类商业风险可能无法完全避免，但可尝试从以下两方面入手减少此类风险对己方的影响：

（1）首先需要了解该合作项目在对方业务中的重要程度和优先级，分析出哪一方是项目的驱动者（Driver）。如果对方是项目的驱动者，那么可以采取跟 随战术，即跟随对方的节拍，可以比较保守地投入人力资源；如果己方是项目的驱动者，则需要采取更加主动的方式来推动对方进行人力资源的投入。

（2）然后了解该项目在己方的重要性。例如有些项目可能是来自高层指定的人情项目，但对本部门营收并无多少影响，它方便后续公司间其他产品的资源互换；而有些合作项目可能是业务部门新的业务方向、流量或推广的入口，关系到业务上后续的拓展和发展。要针对不同背景的项目进行合理和有序的项目人力投入，项目经理本人也能确定不同项目的轻重缓急，有针对性地落地执行。

和产品研发商务谈判并行可能导致的风险及其应对

往往有时为了加快产品上线速度，在双方合同尚未签署完毕前就开始进行技术对接和开发了，但随着商务谈判的深入，特别是一些排他性条款在合同中被双方的法务同事不认可，项目就被一票否决了；或者市场环境的变化导致合作停止，而前面的技术产品对接人力就付诸东流了。

针对这类风险也许无法根本避免，因为市场的变化速度有时往往快于系统对接速度。为了使研发资源投入能够得到及时止损，可以在启动产品系统对接时要求业务人员确定最晚合同签署日期，而一旦超出此日期，如果合同尚未签署的话，就需要评估是否终止人力投入了。

以上四个风险是笔者在目前已交付的合作项目中总结出来的，供大家参考。另外在合作项目的进度计划上也应该额外多留出5%～10%的缓冲时间，用于应对双方的各种不确定性。

Bug Bash手把手教你做

文／张孙恩

产品质量不好怎么办？QA人力不足怎么办？上线时间太赶怎么办？教你一个好法宝：Bug Bash！本文解说什么是Bug Bash，分析推行Bug Bash的优 点：让团队集体发现需求、厘清发布前还没准备好的事情、游戏化激励团队。并且以猛犸大数据平台与网易有数项目中的实践例子，一步一步教你如何在自己的项目中推展Bug Bash这种活动。文末也反思了Bug Bash的一些限制。

Bug Bash是什么

Bug Bash，顾名思义就是“小强”大扫除，让大家在产品版本发布前，一起集中精力来找Bug，是软件工程、互联网产品开发过程中，产品验证很重要的一个活动。通常可以由项目经理或QA主导发起。

1．什么时候做

建议在上线前，QA第二轮测试结束通过后，确保线上没有重大Bug影响试用、服务，处于稳定的状态，这时可以进行Bug Bash。

但这里有个两难：确实等到前面描述的状态完成后，进行Bug Bash比较正规，团队不会因为重大Bug而阻碍各环节的试用，而且比较接近上线后用户的使用状态；但坏处是通常开发时间是很紧凑的，当第二轮测试结束后，离上线也没几天了，如果Bug Bash提出很多需求类的Bug、新需求、大改动，其实已经来不及在本版本实现，就会放入需求池或之后版本实现。Bug Bash提出的很多问题或需求会越积越多，修复之路漫漫。

当然解决方式可以在提测后，就邀请产品策划、交互、视觉针对产品做个验收，确认产品是否符合设计，以及是否有需求Bug、新需求、新改进建议，这样可以减少Bug Bash时需求类Bug的数量，及早让团队应对。

2．与QA做的测试区别是什么

有读者会问：那是不是我们可以只做Bug Bash，不需要QA了？其实QA有更专业、更全面、更完整的测试计划与策略，Bug Bash可以补充QA的工作，发现一些QA可能没发现的问题。或者当QA人力不足时，众人一起找Bug的效率也较高。

另外，Bug Bash参与者多，更能发现兼容性或用户登录、权限差异等问题，可以事先就约定好哪些人分别使用哪些不同的浏览器、手机、作业系统来找问题。而且一样米养百样人，大家对于产品操作的理解，也会相差十万八千里。 多人同时协作来使用系统，操作的复杂度就会呈指数级增长，可能会发现在测试环节不容易找出的复杂Bug。QA的测试用例只能针对功能点，但许多新功能点交叉，加上老的功能点，复杂度也会增加，这就需要众人齐力发现复杂性Bug，使得产品质量更有保障。

有QA同事做测试，不做Bug Bash也是可以的；但是只做Bug Bash，没有QA则会有很大问题。

为什么要做Bug Bash

1．团队集体试用，发现需求

可能有人觉得Bug Bash提需求会不会走偏？其实提新需求也是很重要的，因为在Bug Bash中，我们的角色就不只是研发人员，也是以用户的角度来看产品。如果内部团队自己都觉得有很多需要添加的需求，那产品经理或策划也该好好考虑调整产品的设计了。网易教育产品的项目经理曾做过问卷调查，团队原本对于在Bug Bash提建议有疑虑，问卷统计结果显示，大部分人还是支持在Bug Bash提需求与找Bug的。

此外，在Bug Bash前，开发都只专注在自己工作的部分，可能都没有完整地真正试用过整个产品，要让团队自己主动去试用比较难。当测试第一、二轮结束后，Bug Bash是一个强制的活动，促使大家真正把自己做的产品用一遍。很多之前在设计、交互稿看到的功能都只是纸上谈兵，真正用起来，才会发现问题或需求，这时也可以看看交互与文案是否容易被大家理解。所以我负责的两个项目——猛犸大数据平台与网易有数，经常是新需求以及需求类的Bug多过开发产生的Bug数。

2．厘清发布前还有什么没做好

用户手册、环境、账号等，由于大家要开始使用，会促使团队思考上线还缺什么。由于开发与测试的同事对于产品操作、环境都很熟，但在进行Bug Bash时，视觉、交互、策划、项目经理可能都是第一次看到成品，这时应该思考用户手册是否看得懂、数据库资料有没有准备好等问题，让产品上线前的准备工作更完善。

3．游戏化激励团队

如果只是宣导“大家要注意质量哦”、“QA要尽量找出Bug哦”，或者要求大家恪尽职守，可能团队成员执行的动力就比较弱。但Bug Bash，其实就是一种工作游戏化，通过大家聚集在一起参与，然后加一些比赛的元素，会让大家有冲劲想要努力找出Bug，互相比着谁找的Bug数最多。有一点要注意，主持人项目经理或QA不能只在旁边观看或加油，也应该积极参与，一马当先多找一些Bug，来提升大家的参与度。当然最后可以利用统计工具，计算一下大家的排名与Bug数，给予奖励。

团队平时自己可能会做团建，有些团队不一定常搞活动。这种类似游戏化的活动，能促进团队间彼此沟通、良性竞争，对于团队建设也是很有帮助的。如果项目经理要进行Bug Bash，可以弄得热闹一点，变成一种团建活动。

如何做Bug Bash

（1）说明规则。准备一份PPT（见图3-7），可以在周会上向团队宣导说明什么是Bug Bash、宗旨与目的、时间与地点、准备工作确认、游戏规则等。这份PPT也可方便大家随时查阅。

图3-7　Bug Bash活动方案PPT

（2）问题记录的区域。如果用JIRA，先确认大家都有JIRA的权限、并建立一个叫BugBash的模块（也可以是标签，只要方便筛选、统计）。不用JIRA 也可以用云协作、Google doc、维基工具来代替，甚至每人发一张纸一支笔也一样可行，只要方便大家记录、结束时好统计即可。

（3）活动前，提醒大家做好准备工作，包括用户手册、环境是否都准备好、权限都开了没有、测试是否确保重大Bug修复并验证完毕。如果有经费，还可以准备一些点心、水果、奖品，有助于提高大家参与的兴致。

（4）会议场地。项目组如果人少且都有笔记本电脑，可以借一间大会议室，方便随时讨论、合作、排除问题，让大家能更集中投入活动，气氛也会更热烈。但是如果没有办法借到大会议室或者大家都是台式电脑不方便移动也没关系，只要座位距离不远、使用即时通信软件沟通，也一样可以把Bug Bash做得有声有色。

（5）统计工作。Bug Bash结束后，项目经理要统计全部问题数、有效Bug数、需求数（见图3-8），并检查是否有重复提交的问题，若有重复可以按照提交时间的先后顺序，决定这题算谁的，或各得一半的分数。然后再把Bug与需求区分开来。另外，有些团队根据提Bug的价值与重要程度，给予不同奖励。当然如果经费允许，可根据不同表现，给予一些相应的奖励，促进大家积极参与。

图3-8　Bug Bash活动结果

（6）最后，也是最重要的，做完Bug Bash，团队要开个会，大家一起整理所有提出的问题的优先级，判断到产品上线前，哪些Bug是要修好的、哪些是可以留到未来修的。因为Bug Bash到产品上线时间可能已经很接近了，除非 是很严重的Bug，或者工作量小、效果大的（性价比高），可以考虑处理，其余都不应该处理，这样才能保障代码的稳定性，以及准时交付。当然这个版本不修的Bug、不能实现的需求，可以标示重要性大小，放到需求池，在未来版本去实现。

Bug Bash的问题与反思

1．每次迭代都做，大家最后会失去新鲜感

我在几个项目内推动Bug Bash，第一次大家非常有新鲜感，参与度高。但是每个月迭代下来，大家逐渐对于这种活动失去了激情。项目经理这时候就要好好反思一下，该如何改善与调整。我自己的经验有两个：

（1）不一定每个迭代都搞，可以在大版本或者累积好几个小迭代后认认真真做一次大的Bug Bash，发发奖品，这样可以保持大家的新鲜感。

（2）真的觉得有必要的时候，才做Bug Bash。团队如果平时主动走查、用户反馈也很积极，倒也不必特别做Bug Bash，不用为了做而做。真的发现有价值、有需求，再推动，效果反而更好。如网易有数项目，就是QA同事与开发负责人感觉测试时间紧张，需要调动大家一起来Bug Bash，这样大家自己提出来积极性会更高，我也认真准备了小礼物，大家玩得也很高兴。

2．Bug Bash有限制吗？

有人会问Bug Bash是不是什么功能都要测？其实它也是有限制的。例如支付功能、与实际时间相关的功能（教育产品的学期），还有权限类功能，会比较难在一两个小时内让众人一起来做测试，要真的充值，还是要弄虚拟货币、调整权限等，比较麻烦，反而会阻碍其他功能的试用。建议这类功能的测试，尽量让专业QA来做。当然如果项目组事先准备工作做得好，Bug Bash能覆盖这类功能是最棒。

总结与建议

Bug Bash不是一定要进行的活动，如果有时间进行，对于团队、产品等各 方面都有好处。其实不是只能让内部团队参与Bug Bash，二次元Gacha这个项目曾经邀请用户参与，效果也是很不错的。让我们一起提高产品质量，打击小强！

我们的持续集成之路—— 提高项目交付能力的利剑

文／刘煦萍

持续集成在一个团队中从无到有需要一个驱动力。为什么我们要引入持续集成？人云亦云的想法会让你在实施的时候举步维艰，初始时的坚定决心也变得非常脆弱和不堪一击。本文根据笔者所在团队的实施过程阐述为什么要引入持续集成？持续集成实际上到底是什么？它能干嘛？包含哪些内容？团队实际引入的实施过程以及感受。

对于初次接触持续集成的朋友，要先了解一下它的概念。持续集成（Continue Integration，CI）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

笔者对以上概念的理解有两点：

（1）过程的关键词：高频率、自动化。

（2）结果关键语句：能尽早地发现问题，从而避免问题拖到后期而导致巨额成本。

为什么要引入持续集成

要谈引入持续集成的初衷，就不得不先介绍笔者所在的团队。由于业务扩 展的原因，团队在3个月内由原来的4人增长为13人，之前每月迭代中一个人负责多个模块，一个功能一个功能地串行开发，后来变成多人对同一模块并行开发。快速交付的要求，使得团队需要及时提交，快速响应，解决冲突等。在实施的过程中，持续集成或许能有助于我们解决以下这些问题（当然持续集成能帮到团队的可能远不止如此）：

（1）快速交付的要求使得开发周期更短、节奏更快，如何做到快而不乱呢？

（2）多人对同一模块并行开发时不可避免地遇到一些冲突，怎么解决或者减少冲突？

持续集成实际上到底是什么，包含哪些内容

它能解决我们团队当前遇到的问题吗？来看看它都包含些什么？它常常包含：代码提交后自动构建，构建成功后自动运行已集成上去的单元测试用例，接下来进行静态代码走查、接口测试、回归用例集等（见图3-9）。

图3-9　持续集成

每个项目根据自己实际的情况做部署；有些产品类项目还包含UI测试、圈复杂度等环节。

因为整个过程是自动化的，而且时间一般也不会很长，我们的CI跑一轮的时间在20分钟左右，所以一旦搭建成功，团队能很快知道每轮提交后的结果，从而保证每次提交的质量，让问题尽早暴露，尽快进行分析和解决，而不是到最后大家一起提测时再发现一堆“剪不断理还乱”的问题去紧急救火，问题严重的甚至可能会导致项目延期。这样看起来持续集成有助于解决之前团队遇到的一些问题，帮助项目健康、快速地运转。

说到这里我们对持续集成大概有一些了解了，也明确了它能有助于解决我们团队之前列出的问题，那我们就赶紧“动”起来吧！

1．团队实际引入实施过程

别着急，动手之前我们先考虑一下对于我们团队最有可能导致CI失败的原因是什么？找到它，并先想一步，从而防患于未然。

对于我们团队来说最有可能导致CI失败的原因是：当开发任务的压力与持续集成的实施有冲突时（因为目前团队处于高负荷时期），如果处理得不当，你就会发现理想很丰满现实很骨感。如何找到其中的平衡点，而且是我们需要下定决心去坚持的，这是决定持续集成能否有效的关键。这个平衡点很大程度上就是我们接下来要讲到的“军规”。过于严苛的要求必然会使持续集成之路更加艰难，但规则过于松散就体现不出它强大的“功力”，做了之后大家会说“哎，持续集成也就那样，好像也没什么效果嘛！之前还花那么多努力……”

那我们团队又是如何实施的呢？

2．先做计划，出样板

持续集成从无到有，需要有一个大致的计划，明确先做什么后做什么，什么时间点做到什么。由于项目模块众多，我们打算从一个被调用较多的模块开始做CI，初步做出样板后再扩展，这个样板包含构建、单元测试（UT）、静态代码走查、自动更新部署测试环境、接口测试跑回归。

如图3-10所示，一行（Pipeline）代表一次触发，从第二列到第四列分别表示：构建、UT&静态代码走查、更新部署测试环境、接口测试跑回归。我们用绿色表示成功，黄色表示部分失败，红色表示失败则会被叫停。

图3-10　持续集成样板

3．制定“军规”

样板大致形成后，我们怀着满心的喜悦尝试着让它跑起来！当我们看到静态代码走查的结果是上千个“主要”（major）、上百个“关键”（critical）问题时，满心的欢喜顿时化为彻底的绝望。啊！谁来拯救我啊！针对这种情况，项目组需要根据目前实际情况来确定标准，制定出适合项目组实况的军规：一是静态代码走查规则的再筛选；二是需要确定一些规则。

（1）静态代码走查跑出的结果（见图3-11），block数，critical数，major数分别应控制在多少？要合理，不能太影响目前功能开发的进度，但基数也不能过大。

（2）是否已经责任到人，每个模块都有明确的责任人？这关系着执行效果。如果没有细化任务和明确责任人，就有可能发生我们经常看到的现象：说了等于没说，分了任务给大家就等于没分。

（3）UT覆盖率的指标是多少？

（4）目前我们采用什么方式触发？触发的频度？

这些规则的制定和后继的实施决定了持续集成的效果和所发挥的作用。因为团队才是持续集成真正的主角，持续集成能否真正跑好、用好、发挥作用，关键还是要看团队能否坚持编写与维护高质量单元测试用例，能否第一时间修复发现的问题。

图3-11　静态代码走查结果示例

4．实施

根据以上所述，我们召开会议讨论出暂时目前看似合理的规则：block issue控制在0，critical issue控制在0，major控制在1 000以内；UT覆盖率必须在75%以上；提交自动触发＋定时触发，只要有人提交就会触发＋每天10:00自动触发（自动触发的目的是验证环境正常）。这样每天可能有多次触发，但要确认的是每天最后一次触发的结果是达标的！

在实施的过程中你会发现，前期持续集成过程中所花的工作量还是很大的，一定程度上会“影响”项目的进度，不说各种工具搭建上所花的工作量，光静态代码走查规则筛选也花了不少精力，而且随着开发的进展、代码的增加／变化，对于减少／控制问题数的指标也是要花费不少时间和精力的。但一旦构建好之后，持续集成不仅能解决我们团队以前遇到的问题，而且很大程度上提高了我们的工作效率和质量。因为就如之前所讲，很多问题如并行开发所产生的冲突能尽早发现和解决。每日或按需提交使得错误能尽早被发现，同时也增强了开发者对代码质量的信心，更重要的是后期严重问题的减少很大程度上确保了项目的按期保质交付！

当然在执行的过程中，我们会根据实际情况来讨论持续集成过程中的一些环节是否要做相应的调整，从而不断改进，找到适合自己项目组的运行方式。

感想

就目前实施的情况和各负责人的反馈来看，持续集成对项目组的运转还是 很有帮助的，特别是在频繁集成的过程中能尽早地发现问题。当然有些并不是真正的问题，但却是值得的，因为它减轻了到后期才发现问题所付出的更大代价。我们的深切体会是：单元测试用例的质量高低和设计技巧学问很深，很大程度上影响着项目的质量；静态代码走查规则设置的水平，对项目团队工作效率是很有影响的。

这里需要提到的一点是，不同类型的项目和团队所处的情况很大程度上影响着CI。对于互联网产品来说，很有可能你的项目处于初期，开发总人数很少，项目也是偏界面类的，而且还变更频繁，跟维护的成本比起来可能性价比不高，此时可能你要考虑一下引入CI要达到的粒度或者说侧重点，比如先做后端接口类的，这样一步步制订计划，逐步有效地推进。

最后想说的是，引入和实施持续集成顺应了目前快速交付的节奏。自动化、高频率地进行使得问题尽早暴露和解决，从而有效减少了后期整体修复时间，避免了项目延期，有助于提高项目的交付能力。

更重要的是在实施过程中让团队建立一种意识，一种持续提高和改进的意识！例如，实施的时候开发认为“主要问题控制在1 000以内”这个指标其实可以做得更好；团队发现其实可以在运行完CI后引入代码审查环节，为质量再加分；实施过程中发现现有的代码管理方式不够好，从而会采取一些措施加以调整。往往这些改进点都是团队自己提出的，由此后续实施的过程也会更加顺畅！

这里再附上一些可能会用到的工具供您参考：

（1）Jenkins，之前叫作Hudson，是基于Java开发的一种持续集成工具http://jenkins-ci.org/。

（2）Sonar，一个开源平台，有强大的数据分析与展示功能。Sonar比较容易和Jenkins通过插件做结合，http://www.sonarsource.org/。

（3）项目构建管理工具Maven。Maven基于项目对象模型（POM），可以通过一小段描述信息来管理项目的构建，是报告和文档的软件项目管理工具。http://baike.baidu.com/view/336103.htm。

（4）单元测试XUnit家族以及IBM的Rational Purify，Quantify，Pure Cover age等。

（5）静态代码分析工具，开源的有项PMD、CheckStyle、FindBugs、Splint；商业的有Klocwork、Coverity、Pc-lint等。

（6）圈复杂度。所谓圈复杂度是一种代码复杂度的衡量标准，用来衡量一个模块判定结构的复杂程度，数量上表现为独立现行路径条数。即合理的预防错误所需测试的最少路径条数。圈复杂度大说明程序代码可能质量低且难以测试和维护。根据经验，程序的可能错误和高圈复杂度有着很大关系。http://baike.baidu.com/view/3553594.htm。

JIRA工具的云计算中的应用实践

文／钟欣

好的项目管理工具能带来极大的帮助。本文讲述笔者在网易杭研云计算团队中如何深度应用JIRA工具，用实践告诉读者：根据自己的项目特点，选择自己的合适工具，制定好合适的流程，保证数据完整性、规范化和时效性，并发挥一些创造力，定能为项目管理工作带来极大的帮助。

JIRA在我加入之前就已经是云计算唯一官方项目管理系统工具，之后的一年多JIRA的地位也丝毫没有动摇，而且云计算还是网易杭研最深度的JIRA用户，没有之一，甚至会把JIRA和代码管理工具集成起来实现提交代码自动关闭JIRA任务。但总感觉云计算在JIRA的使用上哪里不对，因为明明在JIRA中存有那么多的数据，却偏偏用不起来。仔细观察后才发现大家对JIRA的使用的确存在很多问题，使得这些数据毫无统一规范，缺乏完整性和时效性。

（1）只把JIRA当作任务和Bug跟踪记录的工具，并且实现了简单的开发验证流程，但这样的用法掐头去尾，只截取了整个研发周期中的中间一段，并没有包括需求管理、版本上线发布的完整流程。

（2）信息记录不完整、不及时。例如，不会对应计划将任务一开始就录入； 估算、到期日、优先级等都没有（正确）填写；任务工作过程中不会及时更新状态。

（3）各个模块团队间的使用标准不统一，使用的方法、规范都不一样。

改变的契机来自杭研决定把JIRA升级成JIRA6，我们决定抓住这次机会在升级的同时梳理和规范JIRA6在云计算的使用标准。经过三周的精心准备和梳理，我们又有针对性地进行了定制，要求尽量简单，贴近以前使用习惯，还要能实现我们项目管理对于JIRA使用的要求。由于准备充分，整个推进的过程相当平顺，云计算团队很快就上手适应，几个迭代下来，整体效果也是非常明显的，不仅覆盖了项目管理的完整过程，还统一了所有模块团队对JIRA6的使用规范。于经过统计分析，还挖掘出不少有价值的数据来帮助我们有效进行过程改进。

接下来将详细介绍云计算使用JIRA帮助改进项目管理工作的实践。本文不会详细介绍JIRA6的功能本身，只是介绍云计算下如何定制自己的JIRA项目，这也要求读者需要对JIRA系统有一定的了解。

JIRA6整体流程管理

图3-12　JIRA6整体流程

这是云计算产品的主要流程和主要流程输出物（见图3-12），大致包括以下内容：

（1）产品里程碑、运营活动策划的管理。

（2）需求池的管理。

（3）版本计划。

（4）双周版本上线。

针对产品导向的管理，我们定义了价值分解的模式来逐层分解，分别是Epic，Feature，Story，Task。

•　Epic代表最高层级的价值，比如里程碑目标、产品形态的定义（产品里程碑），运营活动。

•　Feature代表由Epic的目标分解而来的产品功能。

•　Story是基于Feature分解的更小粒度的功能，可以避免大块的功能开发测试的工作量太大而导致上线版本的风险增加，增加交付的平滑度。

•　Task是最小层级的分解，它基于交互、视觉、前端、后台、测试等进行分工。

云计算产品版本同迭代的节奏保持一致，但从概念上是有所区分的。JIRA6对于版本这个字段，使用范围只能局限于JIRA项目本身，并不能跨项目，但我们的产品却是跨了多个模块组（一个模块组一个项目），因此，我们只能自定义一个字段“产品版本”，来标记Feature，Story，Task放在哪个版本上线。制定版本计划要提前下个版本1～2周的时间，由项目经理统筹安排哪些功能排入，并排出详细的优先级，而这一切都是在JIRA6上进行的，并且把该版本保存为过滤器，最后把链接公布给所有产品团队的成员（见图3-13）。

图3-13　产品版本计划管理

工作流

计划有了，接着就是任务的执行和监控了，对应JIRA就是问题的流转和状态的变更。

对于工作流，可以复杂也可以简单。例如，可以一个任务交给A，A完成后交给B，B完成后交给C，C完成后结束，类似工单的方式；也可以一个任务拆分成三个子任务，分别交给A、B、C，三个子任务都完成后任务才结束。如果强调依赖性，可以采用工单的模式；如果强调任务明确性，可以采用子任务的方式。而云计算采用的是子任务的方式，主要原因是为了任务明确，并且便于工作量的统计。

所以，云计算工作流基本上只采用最基本的默认工作流，非常简单（见图3-14）。

图3-14　云计算默认工作流

风险管理

项目管理中，风险管理是很重要的一块。风险的来源可以是多种多样的，而常规的风险就是来自我们项目内部本身，或者就是平常的任务和Bug中。在云计算这种模块众多、技术要求高的项目中，对于常规风险的管理尤为重要。只要平时的任务完成的进度无法把控，或者某些Bug一时很难有效解决，都会升级成为项目中的风险。

针对这种情况，我们巧用了JIRA6里的标签功能。任何人只要认为某任务或者Bug可能会无法控制和有效解决，可能会成为项目的风险，都可以打上“风险”的标签，以表明这已经是一个内部风险。当然风险不仅局限于任务或者Bug，Epic、Feature、Story、Task都可以通过打标签的方式升级成为风险。

打上“风险”标签的工作，意味着需要更高级别的人关注，或者需要更多资源支持。项目经理就可以通过一个过滤器，同时加入项目的仪表盘（Dashboard）中。项目经理会持续关注这个过滤器下的所有问题，定时分析和解决，一些比较难处理的风险还会在周会中重点讨论。

风险的识别是解决了，而最重要的还要有人跟进、有人处理，采用这种方式的最大优势就是能够分配到人，保证每个风险都有人对其负责。风险仪表盘如图3-15所示。

图3-15　风险仪表盘

敏捷插件

这不是云计算管理中的一个场景，但却是一个能够帮助我们更好管理任务和进度的工具，其最主要的功能是管理迭代需求、电子广告牌和燃尽图。

云计算虽然模块众多，但都有统一的迭代节奏，所以不需要各个模块项目都去创建自己的Sprint，我们有一个所有模块项目之外的JIRA项目，只有项目经理有权限，负责创建、开始和关闭云计算统一的Sprint。每个模块组都能看到，并且在整理迭代需求、制作迭代计划的时候选择当前统一的Sprint作为这个迭代的标记。

因此我们会产生两个层次的敏捷面板，一个是整个云计算层面敏捷面板，另一个是每个模块项目自己的敏捷面板。敏捷面板的作用是能够生成迭代任务的燃尽图（见图3-16）、电子看板（见图3-17）和报表（见图3-18）。这样我们就能够看到基于两个层次的电子广告牌、燃尽图和报表，从而更有效地监控进度和风险，更精准地确定和解决问题。

图3-16　云计算整体燃尽图

图3-17　模块组电子看板

图3-18　模块组版本之报表

数据挖掘

至此，我们实现了JIRA对于整个项目甚至产品的全覆盖，项目组全员每天都会在JIRA上产生和更新大量数据，这些数据具有完整性、标准化、时效性。那么，如何从这些数据中挖掘出有价值的信息，进一步帮助项目或产品进行过程改进呢？

1．完成率

总体完成率＝迭代总完成工作量／迭代总工作量

计划完成率＝完成计划工作量／计划工作量

蔓延率＝新增工作量／迭代总工作量

当我们第一次开始统计完成率的时候结果是非常令人惊讶的，云计算总体完成率只有32.72%。在有JIRA数据统计之前，各模块组都是通过周报估算自己的完成率，当此数据出来之后，发现差距太大，各模块负责人都不太相信这个数据的真实性。当说明了算法后，很多人就指出这可能是因为新增需求太多所导致的。的确，我们的需求蔓延率达到了141.03%。但其实原因并非只是需求增加，因为我们统计了计划完成率，只有31.25%。真正的原因其实源自“完成”这两个字上。以前各负责人在估算的时候会把投入某个没完成的任务（也就是没有经过验证人验证通过的任务）的时间也算进去，这样看上去完成率会达到80%～90%，事实上真正交付的工作却远远低于这个数值。这是个很大的风险，往往会让管理者很轻易地认为交付了80%～90%的功能，但其实一大半都还停留在未完成阶段。

2．Bug生产率

Bug生产率＝迭代新增Bug工作量／迭代总完成工作量

这是一个我们自己创造的名词和算法，只是想单纯呈现单位工作量会产出多少Bug工作量，从而展现我们到底产生了多少效率上的浪费。云计算的Bug生产率统计出来之后确实也是挺令人吃惊的，这个值为73.45小时／百工作小时。换句话说，我们工作100小时的任务，就要产生73.45小时的Bug。假如我们要交付工作，我们还得至少花73.45%的时间，这还只是假设测试工作量 没有增加，修改Bug的时候不产生新的Bug，忽略来回沟通的成本，去掉审查代码的时间，等等。相信当我们把这些时间全部加上，浪费简直无法估量和接受。事实上，在这个交付速度越来越快的时代，质量的保证本身就能保证交付的速度，缩短交付的周期，也会在很大程度上影响其他重要因素，如测试开发比、人员利用率、成本、风险，甚至用户体验等。

既然要改进，总要有一个目标。达到多少才是合理的呢？毕竟我们不能完全杜绝Bug。让我们换种思路，首先，Bug一定是一种浪费且不具有任何价值，Bug一定越少越好，而Bug生产率也一定越小越好。Bug生产率是一个根据云计算特点定义的数据，没有业界参考，但我们可以以此为基准，不断地减小这个值，来减少浪费。改进一定是永无终点的。

有价值的数据挖掘还远不止这些，云计算也在JIRA的宝库中不断挖掘，已经统计出来的数据也不会一成不变，会随着时间推移和环境的变化、问题改变和重点的转移，不断创新、进化，目的是为了能对不断提升云计算的生产力起到有效的指导作用！

对团队带来的影响与改变

当我们利用JIRA工具做到了这些，云计算团队因此有了什么改变呢？

1．流程更加规范和统一

项目管理工具不能只是任务Bug跟踪的工具，而应该覆盖项目管理的完整生命周期，通过工具有效地规范和约束流程的执行，使得执行流程的效果得以真正体现。

2．提高了沟通协作的效率

当所有工作都统一到JIRA上，团队会开始更加关注JIRA，因为他们能看到自己的所有任务和任务的描述，依赖的任务进展、需要找谁，被依赖的任务是什么、需要什么，甚至当团队无法控制的时候，任何人、任何时候都能提出风险并让管理人员及时采取措施。而这些都是在大规模团队沟通中的主要内容，虽然并没有解决所有问题，但已经能帮助团队提高相当程度的效率。

3．提升了全局的把控能力

把控全局需要的是信息，不光要全面，而且还要实时。这样才能让老板们运筹帷幄，决胜千里。团队对于JIRA工具的深度使用，正是让这些数据源源不断地汇集起来，通过可视化的图表展现出来，使得把握项目方向变得更加容易。

4．促进持续进行过程改进

自我改进是困难的，特别是当团队达到相对稳定的阶段，往往需要通过深度挖掘的数据帮我们不断发现问题，更精准地定位问题，并采取有效的措施改进我们的生产力。而项目管理工具的使用，正是采集过程数据的过程。也只有这样才能采集到“活”的数据，有效地指导我们不断进行自我改进。

这些都是云计算在项目管理工具上使用的一些实践和体会，也仅限于JIRA这个工具的使用，并不一定完全适用所有的项目。大家也可以根据自己的项目特点，选择自己合适的工具，制定好合适的流程。只要保证数据完整性、规范化和时效性，并发挥一些创造力，定能为项目管理工作带来极大的帮助。

上线精神—— 献给开发兼做运维的同行

文／刘煦萍

为什么说此文是献给那些开发兼做运维的同行？因为开发和运维看问题侧重点不同，开发会比较注重写代码、查问题、找根源，而且开发一般比较自信：只要你能想得到，我就能用键盘给你敲出来！我能的！我开发的东西肯定赞！……而上线时需要切换角色——运维，会站在客户的角度看问题，尽可能减少对客户的不利影响，质疑每一步、每一个操作是否都是正确的，并且后续是没有问题的！有任何蛛丝马迹都不会放过！如有问题立即停止和上报！因为他会意识到，自己做的每一步都是在线上操作，就好比医生在手术台上给病人动刀子，一有闪失，后果不堪设想。

所以让开发做运维，一定要让他们培养和建立起一种意识——上线精神！而且这种“软性”的东西，不是一两下功夫就能植入大脑的。

笔者领悟到更多的是：态度很重要，即对此事的重视、谨慎、细心的程度，或者说“上线精神”！我们不能保证每次上线都不出问题，但是我们要保证的是出了问题能用正确的方式和思维快速地处理问题！

近期在团队中发现一些有意思的现象。先介绍一下背景：此项目属于底层存储类，项目上线的频率基本一月至少两次，近期由于前专职运维人员离职，一时招不到合适人员，决定尝试开发接手运维工作。下面是上线过程中出现的三组现象（见图3-19）：

（1）A： 上线前的流程是开发完成，然后自测、单测达标→功能QA测试通过→性能QA测试通过→上线步骤评审通过→演练通过→领导审批→上线。

结果： 上线过程出现问题，由于处理不够迅速，整个恢复过程花费了近2小时，上线失败，领导对整个处理过程不太满意（因为期望是15分钟内完成回滚操作）。

（2）B： 与A过程基本一致。

不同点：

在上线时多了一位经验丰富的运维人员（此人也是这个团队新上任的负责人）。

结果： 上线过程中出现问题，但处理迅速且第一时间反馈给领导。虽然最终上线结果仍是未成功，但领导对处理的结果还算满意。

（3）C： 与A过程基本一致。

不同点： 在上线评审时邀请了一位“位高权重”的领导一起参与；在上线时多了一位经验丰富的运维人员（此人也是这个团队新上任的负责人）。

结果： 上线顺利成功！

图3-19　上线过程中出现的三组现象

难道领导的力量这么伟大？还是说偶然？或是说前面上线运气不好、上线的复杂度高？

不过具体问题是要具体分析，领导人在其中的作用虽然毋庸置疑，但他们是真正的原因吗？笔者领悟到态度更重要，对此事的重视、谨慎、细心的程度，或者说是“上线精神”！

为什么这么说？

领导不是神，如果程序有潜在的坑，现场他们也未必能解决，即使能解决也不会直接当场修复上线。那么让我们简单分析一下成功的可能原因：

（1）位高权重的领导来了，等于告诉大家：哎呀，领导都这么关注，此事看来很重要！上线步骤、测试、演练等各个环节大家都非常小心谨慎，尽可能不漏过任何潜在问题，及时发现、定位并解决它们！

（2）有经验的运维人员在场，突发情况能处理得很好，这里不是指Bug问题，而是指处理线上突发事件的顺序、流程。

我们不能保证每次上线都不出问题，但是我们要保证出了问题能用正确的方式和思维快速地处理问题！

为什么说此文是献给那些开发做运维的同行，因为开发和运维看问题侧重点不同，开发会比较注重写代码、查问题、找根源。而且开发一般比较自信： 只要你能想得到，我就能用键盘给你敲出来！我能的！我开发的东西肯定赞！……而上线时需要切换角色——运维，运维会站在客户的角度看问题，尽可能减少对客户的不利影响，会质疑每一步、每一个操作是否都是正确的，并且后续是没有问题的！有任何蛛丝马迹都不会放过！如有问题立马停止和上报！因为他会意识到，自己做的每一步都是在线上操作，就好比医生在手术台上给病人动刀子，一有闪失，后果不堪设想。

所以让开发做运维，一定要让他们培养和建立起一种意识——上线精神！而且这种“软性”的东西，不是一两下功夫就能植入大脑的。

那这里所说的精神到底是什么呢？我的理解为：

（1）原则的事情不能触碰！也就是前面讲的一些流程，还包括一些上线原则：

•　流量最低时间点上线原则。此时用户量最小意味着受影响的用户范围也就越小！越是风险系数较高的上线越要选择最低谷的时间点来操作，而这往往也是半夜的时候。我们项目的最低点是半夜两点，为尽量减少影响范围，我们通常会选择用自己辛勤的付出来降低风险。

•　一次上线不允许软硬件一起升，并且不允许太多模块一起升。一次上线的内容越多风险就会越大，出问题时的定位、回滚也会越复杂。

•　上线过程中出现问题及时上报！一方面，领导需要第一时间知道。如果领导在不知情的情况下，接到上级或者合作方的投诉电话，会比较难处理。另一方面，有问题及时上报，出了问题让领导来决策更合适！我们这里不是推卸责任，而是让更合适的人来做决定！

•　节假日前不要做上线操作！一方面，马上要放假了，大家的心已经飞走了，质量难保障；另一方面，放假前后也是各产品搞活动的好时期，更要确保稳定！此外，万一放假期间出了问题，值班人员有限，定位问题和解决速度都会大打折扣。

（2）万事皆谨慎。线上操作无小事，要打有准备的仗！有数据统计表明，通常60%的问题是事后发现的，也就是说我们有60%的提升空间（见图3-20），而这些问题的成本会因所处的阶段不同（设计阶段、开发阶段、测试阶段、上线）成指数级增长，图3-21是我曾经所在的一个软件项目的问题成本分布情况。

图3-20　提前发现问题和事后发现问题的百分比

图3-21　软件项目问题成本分布情况

所以开发过程中的各个环节我们都需要认真把关，特别是上线前的这道关。

•　上线的每个操作都要确认批准后才能执行，这里是指会引起改动的操作，那些不会引起改动的命令等就排除在外了。

•　审批流程也需要明确出来，具体的流程这里就不详说了，需要确认的是这个审批流程一定要清晰明确，而且责任到人！如果形同虚设，那么就很难起到效果，也就无法保证上线质量！

•　所有上线操作，请提前一天准备好就绪工作，不要有临时抱佛脚的心态！准备好需要的脚本，测试通过，演练通过，回滚方案／脚本也准备好并经过验证。

•　准备好应急预案。因为在上线过程中难免会遇到突发情况，如果不幸遇到，可能会大脑缺氧、冒冷汗、紧张，正常思考的能力或许都暂时失去 了，此时让你临时想解决方案，一个字——难！但如果提前准备好，信手拈来，在关键时刻露一手，那才是展示咱能力的时刻！到时候不要偷着笑噢～

（3）还想提一小点：重视上线前的演练！

往往很多人对演练不重视，这当然也跟现实情况有关，因为演练环境毕竟不是线上环境，有时候没那么真实！而且它不是必选项（因为有些情况没法在演练环境中操作），有人甚至可能怀有这种心态：前面单测、功能、性能测试都验证没有问题，上线步骤大家都评审过了，都这么步步到位了，不会有啥问题的，然后就草草了事，没有很慎重地把演练当成上线前的实战！

而事实是，在碰到的为数不多的上线问题中，就有因演练不够仔细而将问题留到上线时才发现的情况，特别是有的问题只有查看一段时间的日志才能发现，所以即使演练顺利，也应该提高重视度，把演练当作真正的上线，认真检查每一步！

当然项目类型不同，前面所说的也会千差万别，如底层技术类项目跟网站产品类项目对上线的要求会差别很大，因此具体每个项目还是要结合自己的实际情况进行定制化。对我们而言，上线的态度应该是明确的！俗话说台上一分钟台下十年功！上线精神要从头到尾地贯彻，才能确保这一分钟的成功。也只有这一分钟的成功，前面的努力才没有白费！而这一分钟不光需要前面那么多环节步步到位，还要各路人马大冬天凌晨两点从温暖被窝爬起来的勇气啊！

苹果审核血泪史——说说加急那些事儿

文／刘煦萍

说起苹果审核，大家似乎都有种说不出的痛，以及坐等考试结果的感觉：过了万幸，不过继续补考……更可恶的是标准审核官说了算，同一个答案，别人可以，你未必行。但互联网产品要的就是快，特别是那些配合了相应市场活 动的版本，着实让人苦恼。为了能赶上活动时间大家会选择走加急。笔者亲身经历了两次悲催的加急审核过程，拿出来跟大家分享，希望能有借鉴作用！

第一次走加急是我们在产品里做了一个活动功能，这个活动是专为上个版本的大功能做的延续动作，所以时间上要求不能隔太久，否则活动效果大打折扣。为此我们特别申请走加急，理由也与上面描述的一致：做活动。不久我们就收到了被拒的消息，被拒的原因有很多，可以总结下来的结论就是：不要写活动！为什么？原因如下：

（1）涉及活动的版本，审核官们会考虑很多，检查得比以往更慎重。比如是什么类型的活动？是否涉及金钱？是否会有欺诈行为？如何验证奖品发放等。

（2）检验活动本身流程也会遭到种种质疑，当然这跟活动本身的复杂程度也很有关系。

（3）心理上审核官也不喜欢这类项目，这一点纯属笔者个人感觉。

我们是怎么做的呢？

首先，把这个活动从功能上屏蔽了，因为当时考虑到可能是临时性活动，所以活动设计时就做成了开关式的，事实证明此举非常有先见之明。

然后，把理由改了，随便编了一个原因，因为我们从一次跟审核官的对话中得知：一旦建立加急通道，直到加急成功才算这次加急通道完成。什么意思呢？就比如这次加急第一次失败了，下次提交还是自动走加急通道，如果再失败那下次还是走加急通道，直到版本加急成功。

没想到的是，我们很不幸，又被拒了。这次原因是Today Extension问题，这个我们就很不服了，因为我们知道当时至少有两款还比较出名的产品都有Today Extension！于是我们立即申诉，申诉惨败！原因也是……总结下来结论就是：听审核官的话——改！其实，

（1）我们了解到目前有五个地方的审核团队同时进行审核，不同的人审核的严谨度和标准可能会略微有差别。

（2）“其他产品是别人的产品，你的产品是你的，我现在讨论的是你的，你不要去管别人的，其他产品审核官们会慢慢处理。”（够强势吧？没辙，所以 照做就是了。）

于是我们就乖乖地改了，然后继续提交，这回出乎意料的快，第二天一早就通过了！当然这里也要换位思考，其实这也难为苹果审核团队了，那么多产品能出一份人尽可行的标准就不错了，更何况全球各地不同团队每天都在审核各种千奇百怪的App，能做到现在这样的水准也就只有这样标准化的大公司才能做到。

下面就说说第二次走加急的事儿吧。第二次是为了春节活动，时间点是死的，市场砸下去的钱也是收不回来的。为了尽早让版本上线，便于春节前有一定用户已经升级上来，我们决定走加急通道。很不幸我们又被拒了，也是因为这些悲剧才能有这篇经验总结，也算是收获颇多吧。

被拒的原因是：

（1）春节期间太多App走加急。大家都走加急那就等于没走加急，慢慢等要排队。

（2）沟通中得知：之前网上说每个App一年有两次加急的说法是误导。审核官说加急原则上是一年一次，而且不是按自然年算，是按照上次加急到这次加急的时间算。我们上次加急到现在还不到一年，所以理论上是不能走加急的。

哦，上帝啊！救救我吧！春节在即，现在被退回走正常的审核很有可能来不及了，这可怎么办？怎么办？！

只有一招了：找崩溃、严重Bug！因为原则上本次加急要距离上次加急一年的时间，但是严重崩溃等问题是不算在内的，所以有些App一年之内不光走了两次加急，三次四次都有可能。这个时候发现产品有个严重的问题也是件好事情。

我们没有找到主流程上非常严重的问题，但我们找了一个非主流程上相对严重的Bug，然后写了一封非常诚恳的信提交对方（见图3-22）。

或许是真的打动了审核官，或许是Bug起了作用，最终第二天我们通过了审核！让我们的活动得以顺利进行。

通过这两次加急的种种被拒，让我们收获了以下几点：

（1）理由不要写活动，最好版本更新说明中也不要提活动！

（2）审核官让你改，你就改！同时在审核的有五个地方的审核团队，每次 都是不同的人，不确定性很强！

（3）功能设计时可以考虑是否要做成可配置的，这个具体情况要具体分析了。

（4）加急一年一次，时间从上次加急日期算起，而非按自然年算法。加急通道一旦建立，直到加急成功为止，才算用了一次加急。

图3-22　诚恳的请求信范例

（5）严重问题，比如崩溃、严重Bug、安全问题等是不受上一条所说的限制的，但也要慎用。

（6）态度诚恳是有可能加分的！

（7）最后一条也是最重要的一条，在有大型活动且有时间要求的版本时，尽可能做好项目计划，充分预留审核时间，哪怕是审核通过后先放在那里，当然时间也是成本，所以这个方法只针对有强制时间要求的、有相应市场配合的大型活动版本。

以上两次加急的亲身经验希望能对你有用，也希望更多的小伙伴能总结经验进行分享，让大家少走弯路。

电商客户端Apple Pay接入实践

文／吕广川

笔者团队历经一个月时间从无到有，通过苹果应用审核，成为中国大陆第一家成功对接Apple Pay的跨境电商。本文将介绍Apple Pay及开发注意事项，具体解电商客户端接入实践。

Apple Pay是什么

在笔者曾参与的与苹果方面关于Apple Pay接入事项会议中，苹果方介绍，Apple Pay本质并不是一个支付端，不碰用户信息，不碰资金。主要涉及以下内容：

（1）NFC与iPhone无线技术。

（2）指纹识别。

（3）加密硬件支持。

（4）内置苹果的钱包应用等。

Apple Pay付款流程（引自苹果官网），见图3-23。

Apple Pay开发注意事项

苹果官方：Apple Pay入门https://developer.apple.com/apple-pay/get-started/cn/

在苹果官方的介绍文章中已经包含《Apple Pay编程指南》、《APP内购买项目编程指南》、《Apple Pay识别标志指南》、《iOS人机界面准则》及常见问题解答等内容。请务必仔细阅读了解。

如采用银联SDK方案的话，银联会提供相关文档（见图3-24）。请务必仔细阅读了解。

图3-23　Apple Pay付款流程（引自苹果官网）

图3-24　Apple Pay银联SDK方案相关文档

电商客户端接入实践

笔者负责的电商移动端Apple Pay项目对接，可谓一波三折。最终成功发版，得亏团队成员们锲而不舍，精诚合作。

领受任务： 尽一切可能尽早完成电商移动端Apple Pay接入工作，争取赶上苹果首波推荐。

任务背景： 2015年12月下旬接受任务前，项目成员对Apple Pay一无所知。其他同类争赶苹果推荐的应用已对接，少则一个季度，多则半年有余，部分已经进入苹果实验室测试环节。

应对策略： 搭班子，定战略，带队伍（借用柳传志管理三要素）。

实践简介： 笔者领命后，首先尽可能收集有关Apple Pay的信息，了解大致情况。然后分析邀请相关人员（共涉及客户端开发、后台开发、支付工具、银联、产品策划、测试等角色），确定重要干系人，发出整理后的材料，召集启动会议。

首次碰头会即定下大致的产品方案（先期敲定API对接方式后，没出几天根据实际情况调整为使用银联SDK方案），明确分工，约定沟通机制（保持至少每周一次定期会议，其他按需安排会议）等。根据实际情况及时更新《进展简讯》，邮件抄送相关干系人。项目排期经多次会议沟通后分阶段确定，先确认内部分批次联调及基本主流程打通的完成时间点，然后在项目中期确认最终发版时间。

项目时间： 苹果于2016年2月18日正式发布Apple Pay。笔者团队从1月初正式开工，历经一个半月（除去春节放假，实际工作日约一个月），最终于2016年2月19日提交应用给苹果审核，2月20日审核通过，成为第一家成功对接Apple Pay的跨境电商。

解决过的问题摘录

（1）确认对接方案流程。2015年12月25日第一次碰头，12月30日决定暂用API方式接入，支付工具方选网易宝，元旦假期后2016年1月4日上午提出需确认的方案，下午组织会议，确认方案需更改并制定初步的技术排期等工作：支付工具方继续选网易宝，改API方案为银联SDK方案。第三方集成SDK方案，也是目前苹果官网中推荐的接入方式。

（2）涉及收款业务时，需向银联申请开通支持Apple Pay的商户号。

（3）同支付工具方、银联多方合作，外部依赖明显，团队决定制定分阶段联调目标，并约定沟通机制减小依赖风险。在与团队外沟通时，建议问题发起 方需要确认及时得到了答复。一般问题邮件确认，紧急问题电话确认，如都已尽力了但当天下班前半个小时还有未得到答复确认的问题，则向上反馈求助。

（4）银联SDK返回商户名有问题。排查确认，是我方未能及时替换更新银联SDK版本，未能正确对接升级后接口。后期要求银联第一时间提供最新或正式的SDK版本及说明文档。

（5）部分商品获取Apple Pay支付方式失败。问题：排查确认，部分商品涉及不同商户号，支付工具方未绑定开通对应的商户号，导致该类商品无法使用Apple Pay支付。绑定后即正常。

（6）因故无法去苹果实验室参与测试，改用提交测试视频方式。但这个过程比预估的耗费了更多人力。有些未能按照苹果要求，需重新录制，有些是根据苹果针对视频提出的修改意见修改后重新录制的。沟通方式以电话沟通、邮件沟通为主。

（7）涉及跨境业务时，需特别考虑实名认证信息等。因Apple Pay本身不需要用户实名认证，所以既要兼顾跨境业务需要，又不能打破良好的用户交互体验。我们没有对应参照可依据，决定采取多种应对手段。①为增加Apple Pay快捷支付亮点特性，推出Apple Pay专场秒杀活动，选取不需要实名认证的非跨境业务商品。②为避免未实名认证用户使用Apple Pay购买跨境商品时中途不得不暂停去补实名认证的尴尬，平衡利弊后团队制定了针对该人群临时屏蔽Apple Pay支付入口的方案，如张三未实名认证过，那么他在购买需实名认证信息的跨境等商品时，就不会看到Apple Pay的支付入口。

（8）关于隐私政策引起的问题。在2016年2月19日提交版本后，苹果以我们提供的内容不符合“客户隐私保护政策”为由拒绝了。虽然之前该内容，已经用了很久了未更新过，审核一直都没遇到问题，但还是当即决定修改内容，更为直接地展示公司保护隐私政策的地址链接，重新提交审核。这一步不需要重新打包提交，只需提交应用审核界面更新链接即可。最终于2016年2月20日周六晚审核通过。

和苹果方打交道的三条建议

（1）一定要熟读苹果的规范及要求，否则返工在所难免。小到几个像素的图标细节，大到界面规范原则。另外如需提供测试视频，也务必按照苹果的要求录制与提供，如要求什么机型以上的设备录制等。

（2）请预留时间和精力处理与苹果方的沟通事宜。苹果方面对于产品设计的细节要求十分苛刻，无论是界面展示还是交互流程，会事无巨细地提出很多修改建议。苹果方甚至会特别在意沟通中“Apple Pay”这几个字母是如何书写的，是否大小写区分并且空格隔开。有一些是按照规范要求必须修改的，有一些则只是诚恳的建议。怎么取舍平衡需要团队根据自身情况去定夺。

（3）如需争取苹果推荐位，保留合理心理预期。苹果一般不会明确承诺是否推荐、推荐的形式及预估推荐效果等。为获取推荐舍得投入多少，需要团队自身去评判。一般在Apple Pay这种同类参与者众多的情况下，基本上众多参与者都是有同等推荐待遇的，除非有特别迎合苹果实际需要的超级亮点应用，而这种情况极为少见。

结束语

在对接Apple Pay项目过程中也有诸如投入产出比是否值得等质疑声以及其他诸多坎坷，笔者在此就不一一赘述了。单从项目研发角度评判，它是成功的，至于其他整体评判则值得进一步深思和反省。

软件外包采购类合作项目的建议

文／刘煦萍

或许你所在的项目（现在或未来）也遇到时间紧迫、人手不够，需要将其进行外包的情况，那么在这种软件外包（采购类）合作项目中应该注意什么呢？以下是笔者在经历实际项目后，站在研发部门的角度，总结了过程中大家需要 注意的事项，供大家参考。

整个过程可以分成三个大的阶段：签合同前、签约后的研发过程以及上线后，每个阶段都有需要注意的事项，希望尽可能帮助大家避免事后扯皮的情况出现。

这是小鹰来到Y部门的第二天，正在享受早餐时看到群里发消息说101项目线上有问题……汗！一来就碰到线上事故。到办公室后小鹰了解到，101项目是由A部门发起的，希望Y部门能尽早完成。但由于当时人手不够，于是A部门找了一家外包公司一起完成，最后双方联调上线。目前实际情况是线上问题较多，而且比较低级，潜在问题不知还有多少。

了解了项目的大致情况后，小鹰先去找A部门的联系人萧萧，希望与外包公司进行电话沟通，了解目前的项目情况。在与外包公司的电话会议上，小鹰提出了希望看到对方功能测试、性能测试计划和报告结果，从而基于此做相应的查漏补缺。然而对方却告知很难提供。一再要求之后，对方说他们准备一下，而态度似乎在说：“之前没听说要，现在都已上线了，你才来问我要。”这种事先没协商好，出问题后来走查的情况的确会让双方都很尴尬。内部讨论后，大家怀着对产品负责的态度，最终决定调整资源，把功能再扫一遍，同时站在双方共同目标的立场上，让外包公司进行性能测试，并提前准备好上线后的相关应急预案，从而尽量保证接下来线上的稳定性。其实我们可以让项目进展得更顺利，而不是此时线上问题一箩筐，大家加班加点地救火，互相埋怨。那么在这种软件外包（采购类）合作项目中应该注意什么呢？以下是小鹰在经历实际项目后，站在研发部门（比如上文中的Y部门）的角度，总结出的注意点，供大家参考。

整个过程可以分成三个大的阶段：签合同前、签约后的研发过程以及上线后，每个阶段的注意点如图3-25所示。

图3-25　软件外包合作项目里程碑

签合同前

1．合作方式

首先要明确是全部外包还是半包，如果是全部外包，大多只需检验实际情况是否符合预期标准即可；如果是半包（这里所说的半包是指自己也有部分软件开发工作量，并与对方有技术衔接），那么中间需要关注和沟通的细节会较多，本文以半包为例进行说明。

2．合同类型

因为很多合作是通过公司中间部门找到外包公司进行的，所以合同也大多由中间部门直接负责，研发部门参与很少，而实际上直接对接的研发部门需要了解，此次合作的合同类型是哪类？总价类、成本补偿类还是工料合同类？合同类型会影响我们在项目进展中的一些决定，所以合同类型也是研发部门需要了解的重点。

3．方案可行性沟通

在选标时建议成立一个临时评标委员会，由技术、产品、市场等共同组成，以确保方案的可行性。

（1）技术层面。由负责技术的同事把控，如果对方给的方案看起来天花乱坠，但实际上在本系统内根本无法实现或成本很高，那就把它扼杀在摇篮里，或者建议对方做一些调整等。

（2）活动／方案。与目前在做的方案进行平衡性考虑，可以由产品／策划／市 场同事给出意见，如这个方案与我们产品的方向违背或不符，那就要尽早排除。

（3）时间和成本方面。此次项目的发起者或者整体的负责人应该对此有一定的要求。

4．验收标准

在签合同前要“丑话说前头”，避免正式开始合作后出现撕破脸的尴尬。需要明确验收标准，确认对方能否满足：

（1）技术层面。主要由技术负责人把控，验收时需要提供功能测试范围及报告、性能和稳定性测试报告、线上扩容方案、监控报警配置、安全性（漏洞）等。

（2）活动效果。市场和产品的同事会对此提出要求，如曝光、拉新等指标。

（3）应急处理能力。如果出现重大事故，对响应时间、影响范围以及事后的紧急围堵、补救措施等要做一定的说明和量化，对造成负面影响较严重的则需要确定合同处理方案。

研发过程

常规研发过程这里不展开，主要讲一下在外包采购类项目中这个阶段团队沟通合作需要注意的事项，包括：

（1）跨公司的团队组建。需要明确双方团队成员和角色，以便接下来开展工作，让双方团队在需要时找到对的人。如果能做一定的团建预热活动则更佳。

（2）沟通管理（分层、频率、工具）。双方的产品同事成为一个虚拟团队进行一定频率的沟通；双方研发技术团队成为一个虚拟团队在需要时能够及时地沟通；双方的主要负责人会进行定期的项目进度同步。一般会建立两种沟通方式：正式的和非正式（即时）的。正式的有邮件及文档形式，进度计划、接口文档等重要过程输出以正式的形式为佳；非正式的即时沟通方式，如电话、易信、QQ群等可以进行临时性的讨论。另外项目周期长的话可能需要一些协同工具用于问题跟踪，此时可能需要借用第三方工具，但需要注意隐私和安全性。

（3）交付方式和频率。根据项目实际的大小会协商以何种频率进行交付，比如为期三个月的合作项目，会希望第一个月有可交付的成果，后面两个月每隔两周进行一次交付（此处数据仅供参考）。前期更多的是沟通，到中后期则需要尽快、尽早地进行验证。这样做的原因：一是为了更早地确认研发理解的是不是需求方想要的，二是确保双方的进度和质量。

（4）变更流程。中间难免有这样那样的变更，双方需要尽早明确变更流程，最主要的是决策机制和决策后的沟通要到位。跨公司的重要点沟通更需要尽早确认。

（5）线上问题处理流程约定。上线前需要双方协商好线上问题处理机制，谁作为运维人员进行第一时间的排查处理，约定好什么级别的问题在什么时间期限内需要处理以及过程如何透明化等。

上线后

如果与对方的合同是开发完成交付即可，那么交付给产品方进行验收就行了；如果是活动类型且对方直到活动结束后终止合同，则上线后要共同保证活动期间线上的稳定；如果对验收标准、线上问题处理流程双方有明确约定，那么活动期间有问题就要按照约定进行，相信即便有问题也能通过有效的沟通加以解决。

最后则是对整个项目整体效果的评估和总结：从开始到活动结束，以及结束后对整体过程和实际的效果要做评估和总结。评估要比较正式，拿实际数据说话；总结则可以略微轻松活跃，让大家敞开心扉来回顾和发表自己的看法，可以大致依据上面整个合作过程的三个主要大的阶段进行回顾，欠缺的方面可以以后完善，好的方面自然要给予肯定。如果对方是长期的合作伙伴，总结会建议一同参与，这样的模式合作过一两次后，相信双方的信任度和默契程度都会上升很多，为下一次起航做更好的准备！

建设学习型组织——读书小组实践

文／汤君嬉

很多公司组织给员工营造良好的学习环境，鼓励大家持续学习，提升自我。但学习往往浅尝辄止，效果不甚理想。另外学习的内容，与组织的目标没有太大关联，在工作上无法直接体现其价值。本文分享了网易PMO组织读书小组的实践经验，从项目管理的维度剖析每个环节（成立读书小组、选书、读书、分享以及总结等）中要注意的点与推荐方法。

亨利·福特说：“任何人只要停止学习就是老了，无论他是20岁还是80岁。持续学习可以保持年轻，而生命中最重要的事情就是保持年轻的心境。”当今社会，知识技术日新月异，推陈出新的周期不断缩短，知识的折旧率也越来越快，几天不学习，就感觉落伍了。企业组织也是如此，要保持年轻活力、提高创新能力，需要持续学习，不断补充新的知识能量。很多组织在这方面的投入也是不遗余力的，如组建图书馆、搭建完善的培训体系以及构建分享平台等。网易在提升员工能力上，更是不遗余力，有图书、培训、沙龙、实践者社区等。而杭研的PMO为了进一步鼓励和推动项目经理们持续学习和营造更好的学习气氛，自去年开始了读书小组的实践。

项目背景

不管是公司层面还是部门层面，都给大家提供了良好的环境，鼓励大家根据兴趣学习，提升自我。但学习浅尝辄止，效果不甚理想。另外学习的内容，与组织的目标没有太大关联，在工作上无法直接体现其价值。

项目目标

读“好书”，“读好”书！

项目运行机制

1年8本书；1季度1迭代；1迭代2本书。

项目启动

在一次PMO季度规划会议上，读书小组项目启动，对项目的整体目标以及项目的总体运行机制进行了分享与讨论，达成了一致意见，同时指定了下个季度读书小组的负责人。大家对一起读书这件事情相当期待，但同时提出了一些不容忽视的疑虑和风险：

（1）每个人的知识、经验、背景各不相同，什么样的书适合大家一起读？

（2）每个项目经理在项目中分身乏术，能把书坚持读完读透吗？

（3）读完后，这些知识怎么呈现、分享？

项目执行

1．准备工作

（1）书海择书。在前一个迭代末或迭代之初需要选择2本书，这并非易事。另外加上每个项目经理本身的经验背景各不相同，选择合适的书相当耗时耗力。能帮助快速缩小搜书范围的经验有三条：

•　权威书单。行业大牛们的书或行业得奖的书。如德鲁克被称为管理学之父，他所著的管理经典书籍可以考虑纳入书单中。

•　实现组织目标所需的知识。根据组织下一阶段的目标，对照团队的知识与能力水平，选择相应的书。如项目要做持续改进，《精益关键度量》这本书就进入了我们的视野。

•　其他人推荐的书。领域专家推荐的书，或朋友推荐的书，或自己阅读过的书，都可以进入选择范围。

（2）确定书单。通过上一步骤，再加上季度负责人的再次评估过滤，书单就可以供团队讨论选择了。通过调查问卷匿名投票方式，让大家选择想读的书，最后根据投票数来确定季度要读的两本书。在这个过程中，需要特别注意的是，供大家投票的书，需要简要地说明（书的大概内容、适合人群等），方便团队做出选择。所以最好负责人先试读再做初步的评价，或网上搜索对该书的正反评价，在最大程度上确保所要读的书是“好书”，该步骤决定了能否实现第一个项目目标——读“好书”。

（3）确定小组组长。因为大家工作太忙，没有时间看完两本书。在我们现在的实践中，分成两个小组（6～8个人一组），每个小组选择一个组长，组织后续的读书活动。读完以后每组就这本书总结分享给另一个组，以达到读书小组之间的知识分享，进而实现一个季度读两本书的目标。

2．读书迭代计划

第二个项目目标是“读好”书，就是把书读完、读透、读出深度来。迭代计划的合理性成了能否实现该项目目标的关键因素。组长组织成员一起探讨可行的具体读书计划，不仅要关注进度（读完），还需要注重质量（读透）。为了读透，还可能会延伸到别的书或资料，所以范围管理也是需要探讨的。有几种组织方式可以尝试：

（1）成员各自回家把书看完，最后定个时间组内进行共同分享讨论。这样做的好处是，成员的读书进度可以根据实际情况，自己控制。不确定因素是，要是大家都太忙了，没时间读，临近约定日期，匆匆看一遍，分享讨论的质量自然不会很高，要实现“读好”这个目标，变数有点大。

（2）先整体后局部。先约定2～4周，成员各自把整本书看完。后续每1～2周拆章节分享讨论。

（3）吃大象法，一口一口来。按周来读指定章节，每周固定时间点分享讨论，最后进行整本书的回顾总结。

至于要用哪种组织方式，需要根据团队自身情况进行裁剪，只有适合的才是最好的。目前我们更多的是采用第三种方式，而且实践表明，即使按周来交付读书成果，由于工作太忙，有些成员还是无法读完指定的1～2章。所以采用 了结对阅读的方式，在周分享之前，每对约时间讨论读书的内容，以提高周分享的质量。对于没有完成阅读或无法参加分享讨论的同事，也设定了一些惩罚措施，如做俯卧撑，给大家发红包等（见图3-26）。

图3-26　读书小组介绍

3．读书

读书不是对所有人都是一种享受，更何况有些书本身就比较乏味。有小伙伴说“我昨晚很上进，想在睡觉前看会儿书，结果没看几页就睡着了。”怎样读出别样的乐趣来？怎样激发各自的读书动力？这没有一个万能的解法，需要根据所读的书，一起读书小伙伴的特点决定。我们尝试的做法有：

（1）在书中寻找答案。这是比较功利性的读法，为了解决问题、寻找新思路、新方法而读。在读之前就列出现实中碰到的一个个待解决的问题，然后在字里行间仔细探寻可能的回答，享受寻找谜底的乐趣。

（2）互动法。一个人负责讲，一个人负责听，听的人难免会走神，甚至昏昏欲睡。要是讲师与听众有许多互动的话，这个过程就会有趣得多。要是讲师与听众进行PK的话，是不是更引人入胜呢？只是一味接受书中的观点，会让我们少了独立思考的能力。与书对话，与书辩论。如果作者说向左，不妨问问为什么不是向右，尝试看看向右会有什么结果。无论结果如何，当你作为一个主动阅读者（见图3-27），这本书的观点会深深刻在你的记忆里。

图3-27　成员反馈

（3）奖品诱惑。读书期间来点小惊喜，不仅给读书带来乐趣，还能起到激励、正向竞争的作用（见图3-28）。

图3-28　小奖品大诚意

（4）打卡签到。朋友圈里有运动量排名，大家玩得不亦乐乎。不少原本懒得动的人，开始加入运动的行列。建个群（见图3-29），看书的时候拍个照、打个卡，不失为相互激励的好方法。在群里提提自己的疑问，谈谈自己的想法，读书的气氛日益融洽。

图3-29　打卡签到

4．组内分享

组内分享是一次思想的碰撞。读同一本、同一段字，每个人的理解千差万别，各有各的角度。每个人都可以说说书中哪些观点比较认同，哪些观点不敢苟同，哪些方法比较实用，哪些手段只适合特定案例等。这个过程中需要注意以下几点：

（1）环境的选择。选择相对放松安静的地方来做分享。可选择咖啡吧，也可选择公司某个安静的角落，享受新鲜的空气（见图3-30）。

（2）营造开放、平等的氛围。鼓励每个人都发表自己的想法，同时也要注意不要评判别人的想法，尤其当同一小组的人在层级或经验上差别较大时。

（3）总结回顾。分享讨论后，留下的可能是一系列疑问，也可能是一些感悟。不管是什么，最后对内容做一个梳理总结，整理后发给小组成员，不仅方便大家再次回顾消化，也为以后全书回顾总结留下可追溯的内容。

图3-30　组内分享

5．跨组分享

经过一个季度的读书、组内分享以及有针对性的尝试和实践，大家对共同读的这本书有了较深的理解，也有了不同的收获感悟。上学的时候，老师经常教导说：“先把书读厚，再把书读薄。”组内分享过程是扩展、发散的过程。跨组分享就是总结收敛的阶段，需要做到把几百页的书浓缩成几页，让没有读过这本书的小伙伴们在短时间内获得书的精髓。在分享的形式上，既可自由发挥、可常规性分享（准备PPT，讲述内容，Q&A），也可圆桌讨论，当然还可以采取辩论的方式。需要注意以下几点：

（1）尽早分享。组内读完总结完毕后，尽快尽早安排分享。时间久了，激情退了，遗漏的内容多了，分享的效果就会打折扣。

（2）准备充分。分享什么内容、结合什么案例、怎样引导讨论等，都需要做好准备，这样才能带来更好的效果。

（3）留点讨论时间。这不仅可以在互动环节增加参与感，更是难得的一次集体思想碰撞。没有读过这本书的小伙伴，思维不受限，更发散，能提出意想不到的角度和观点，引发更多的思考。

6．回顾总结

勤于反思才能和谐进步。为了让读书小组发挥更大的能量，取得更好的成果，在季度末（迭代结束）时，组织一次回顾总结会。回头看看读书活动过程中踩过的坑、绊过的石头，回忆一下读书过程中的收获、讨论碰撞出的火花。在Scrum里，回顾总结的架构是：哪些是做得比较好的，哪些是需要改进的，对改进方面应该采取哪些行动。我们可以重用这个架构，也可以裁剪成符合团 队特点的，比如说增加“我们想尝试些什么新内容”等。回顾是为了更好地改进，回顾的结果可以作为下个迭代的改进的输入。

体会

读书小组实践具有轻量灵活（成员只需一本书以及一点空闲时间）以及投入成本低（一本书一般就几十元）的特点，但要真正运行起来并达到目的，需要在每个环节做好规划设计并根据实际情况进行修正调整。

（1）选书。好的开始是成功的一半。选择对的书，非常关键。我们在实践的过程中，出现过宁愿受惩罚也不愿意再读，甚至提出“退学”的情况。很多时候不是小伙伴不求上进，而是所选择的书对他不合适。因此选书的时候需要考虑：

•　小伙伴的兴趣倾向。

•　试读并给出内容简介以及荐读理由。

•　有自由选择的空间。给小伙伴留一定的选择权利，而非限定一本书。

（2）读书。在繁重的工作压力下，读完一本书可能需要1～2个月。随着时间的推移，读书的热情也渐渐消退。实践过程中发现，传统的读书会可能会加快读书热情的消退。当时我们一个小组采用的是在会议室里由小组成员对着读书笔记讲书里的内容，结果大家百无聊赖，昏昏欲睡。读书的具体形式可根据实际情况来定，有以下几项建议：

•　有规律性。规律性能帮助团队形成读书习惯。

•　与实践相结合。在分享或讨论过程中，多借用工作中发生的事，更能引发共鸣和兴趣。

•　有趣味性。有人说，读书是痛苦的。先不论这话是否正确，但肯定是某些人的真实感受。若能在读书过程中设置一些娱乐小游戏，趣味互动，在吸取知识的同时增添更多的欢乐，将会有越来越多的小伙伴加入读书队伍。

•　分享总结。总结是对整本书的进一步理解深化，分享是众人的一次思想碰撞。分享总结需要在读完书后，尽快组织。

最后的最后，好好学习，天天向上！

第4章

深度修炼

当项目经理经历了多年项目日常工作淬炼后，升华到另一个境界——自我修练与管理能力提升，此时该如何管理好一个团队？该如何持续提升自己的核心竞争力？当遇到困境时该如何突破自己、更上一层楼？本章借着小鱼儿的故事，把项目经理成长的历程，真实又逗趣地呈现在你面前。

项目经理的核心竞争力

文／雷蓓蓓

我们该如何修炼内功、构建自己的核心竞争力呢？这几项能力尤为关键：执行力、专业力、软性影响力、创造力与想象力、自我调适力。

杭研院项目管理部《实战录Ⅲ》的序言中有这么一句话：“项目管理并不仅是一种硬技能，还是一项软实力；更重要的不是招式，而是内功！”我深以为然。我始终认为，知识和技能并不能构成项目经理的核心竞争力，核心竞争力永远不在招式本身，而是要学会在不同的情境下，在合适的时机点，灵活地运用、协调、整合不同知识和技能，这就需要深知每种招式有什么好处和弊端，招式背后的意图和价值是什么，该什么时候用，将每一招应用到什么程度。

那么，我们该如何修炼内功、构建自己的核心竞争力呢？结合自身的项目管理体会，我认为有以下几项能力尤为重要。

执行力

项目管理部出来的人，虽然个性差异很大，但却有一个共同的特质，俗称“靠谱”。他们都以目标为导向，有超强的执行力，这一点可以说是项目经理们的立身之本。

一个“靠谱”的人，言必信，行必果。手上任何一件事情，都有头有尾，有始有终，懂得闭环。

一个“靠谱”的人，为人处世总让人心安，懂得如何获取信任，更懂得如何不辜负这份沉甸甸的信任。

一个“靠谱”的项目经理背后，体现出的是对项目、对团队深切的责任心。正人先正己，项目经理要教导别人如何正确地做事，那自己首先要成为这样的 标杆，一言一行都严格自我约束。

专业力

项目经理的专业力，在于能够在不同的项目情境下，提供专业化的项目运作方式指导。简单来说，就是从混沌变有序，帮助项目团队找到最合适的方式。

有时，这需要对一个复杂系统重新审视和梳理。有经验的项目经理，“闻”得出一个团队的“味道”，并快速定位到问题点，问题的解决也见功力。直接头痛医头、脚痛医脚，往往治标不治本。项目团队是一个复杂的系统，增加一点点小的变量，就会引发一系列连锁反应，这些反应在团队这个大的网状系统中，相互作用、彼此强化，形成聚沙成塔、集腋成裘的效应。

就像一个南美的蝴蝶扇动翅膀，能够影响纽约的一场暴风雨。关键是在什么时间、在哪个地方、怎样扇动那对翅膀。专业力到最后，往往会体现在这种对系统敏锐的感知判断上，基于此，恰到好处地“经营”。这种经营不是一朝一夕的功夫，也没有一招治百病的捷径，需要沉下心来，肯花时间，下大功夫，持续不断地朝着正确的方向，一点点地发挥作用。

软性影响力

项目经理要有软性影响力，这种软性影响力，体现在即便没有一毛钱权力，却依然可以四两拨千斤，对项目和团队中的人和事带来或大或小的影响。

区别于权力，影响力是一种柔软的力量，想要发挥这种柔软的力量，先要把自己的心变得柔软。“当你只注意一个人的行为，你没有看见他；当你关注一个人行为后面的意图，你开始看他；当你关心一个人意图后面的需要和感受，你看见他了。”

这种软性影响力以“同理心”为基础。正如NLP中所强调的，先跟后带。影响力想要发挥作用，一定要以同频为前提，真诚地打开自己，与对方同步，理解对方的处境和心态，只有在这时，真正的对话才会发生，否则，那只能算自说自话了。在真正的对话中，并不存在说服与被说服，只有真诚朴素的想了 解和倾听对方的愿望。共同的需要会转化为彼此的默契和共振，转化一点点地发生。

这种软性影响力在项目中，会发展成一种之于群体的感染力。在这种精心营造的氛围中，并不存在感染与被感染，只有对团队真诚朴素的关怀和共情。共同的期许会自然地转化为前进的信心与勇气，帮助大家正视并解决自己的问题，换个角度看世界！

创造力与想象力

也许你会认为，对项目经理来讲，既然最重要的是执行力，那还要想象力和创造力来做什么？事实上，不光是项目管理，对于其他所有类型的工作，是否能在做事的过程中，激发自己的创造力和热情，从做事本身的过程中找到内在的愉悦，恰恰是优秀与卓越最大的分水岭。

创造力与想象力就像点石成金的魔杖，能让一块普通的料子，焕发出新的光彩，令人惊喜；能把一个平凡的世界，变得生动而有趣。这种源源不断的创造力与想象力，会让你始终有层出不穷的创意想去付诸实践，让你看到始终有那么多有趣的事情在召唤你去做，驱使你在迈向专业的这条路上，不断地自我翻新，持续地学习和成长。离开了这种原始而本真的力量和追求，任你在哪条路上，恐怕都很难走得更远。

自我调适力

自从当上项目经理，你就该知道，自己要走的这条路注定是坎坷曲折的。倒不是说处境上一定会经历多少困难，而是内心要经历磨炼，甚至煎熬，就如同把心放在火上翻来覆去地烤，直到自心可以如如不动，才有希望凤凰涅槃。还记得我做项目经理的第一年，心理状态一直是非常纠结的，每天会为各种各样的事情烦心，别人的任何一点负面情绪都让我半天想不开，自己在那里着急上火却只能眼睁睁地看着，想使力又不知道怎样才能使上力。也许在深层次上，这是源于一种对自己无力的愤怒吧。

随着经历的累积，人开始慢慢变得成熟，也越来越淡然了。成熟和淡然，源于在内心深处，和你遇到的困难和解，和你周围的环境和解，和你自己的脆弱和解。要做到心态上的不断成熟，就要学会自我调适，学会在每个人身上照镜子，学会自我反省。

最后的话

在做项目管理的几年时间里，我经常会听到一种声音，说项目经理没有权力，就是个打杂的包工头，老实说，一开始我也有过这样的困惑。但是几年之后，当我回头去看的时候，我会发现，没有权力是件多么好的馈赠！正是因为没有权力，却要承担很大的责任，这使得我们项目管理部的项目经理们，个个发展出了一身技艺，拥有了不可替代的核心竞争力！

这些年，我一直戴着项目经理的帽子，这顶帽子让我得以拥有较其他角色更为广阔的视野，让我做了很多自己根本都想不到会去做的事情。有时，我像个政委，专门做思想工作；有时我又像个人力资源经理，操心员工的稳定性和长期发展；有时，我是个咨询顾问，给业务方出谋划策、充当智囊；有时，我又成了个教练，帮助我的Scrum专员们胜任自己的工作；有时，我还是个心理医生、拉拉队长、知心姐姐……项目需要什么，我就是什么。这多多跨界的历练机会，是其他角色很难获得的，也是我核心竞争力的来源。

说到最后，项目经理的核心竞争力到底是什么呢？我想，或许就体现在“体、机、用”的这个“机”字上。体是本体，用是效用。体和用，对应于项目管理的知识技能及用途，是可描述、可传授的知识经验。最难掌握的便是这个“机”，它不光指“时机”，同时还意味着“环境”和“条件”。在一个项目中总结出的最佳实践，套在另一个环境中未必适用。由于机不可重复，对机的把握是一种非常稀缺的能力，它难以精确描述、难以传授，也因此变得不可替代。如何把这种核心竞争力变得可复制、可传承，让更多的人能够从中受益，未来，我们还有很长的路要走。

没有权力，怎么做项目管理

文／钟欣

项目经理的权力有哪些？软权力，这个比强制权力好用得多，项目经理其实也并不是那么被动，关键在于你如何发现、如何运用你手上的那些软权力。你承担起了多大的责任，你自然就会有多大的力量。

初进职场，项目经理就成为我职业生涯的一个目标。那时只有个单纯的想法：项目经理的权力很大，做项目经理很轻松。后来做了项目经理，才发现项目经理才是弱势群体，经常被高层、客户和基层夹在中间上下，左右为难，即使你有行政权力，发现也无法起到多大的作用，有时候反倒会使情况更糟。再后来，经历过一次又一次的惨痛教训，我开始学会使用软权力，发现这个比强制权力好用得多，开始理解项目经理其实也并不是那么被动，关键在于你如何发现、如何运用你手上的那些软权力！

人脉

无论在强矩阵、弱矩阵还是平衡矩阵的项目中，无论项目经理的行政权力如何变化，作为项目经理的责任都是不变的：纵观全局，保证项目在计划的时间、成本、质量下完成既定的任务或产品。也正因为要承担这样的责任，项目经理在整个项目的组织架构中，势必成为整个团队的中心、团队和团队之间的协调人、上级和团队的桥梁、外部关系人和团队沟通渠道。

项目经理身处在这样的位置上，本身就已经拥有了巨大的权力。就好像战争中的那些关口险隘，每每都是兵家必争之地，成为左右战局最为重要的地理位置。而项目经理在项目中的组织结构的位置意味着什么呢？人脉！项目经理一定是这个项目中人脉最广的人，这也是为什么项目经理很重要的工作就是管 理干系人。管理干系人不仅是责任，更加是权力！

项目经理要学会厘清各干系人的权力职责、利益关系，并且平衡和维持好关系。项目经理把手中的人脉利用好，就会成为任何人都无法替代的权力；善加使用这些权力，对项目会产生正向的影响，最终帮助我们共同达成目标。

案例场景

项目团队中往往都会有一些德高望重、因为种种原因并不承担管理工作的人员，但由于他们专业知识的不可替代性，或者因为资历颇深，因而拥有相当高的威望。当碰到有些事情无法推进又或者缺少资源和信息的情况下，不妨和这些德高望重的人好好聊聊，也许他们在团队中的作用比他们的上级更大，对于事情的推进能起到意想不到的作用。

信息

项目经理的位置在组织结构中相当于关口险隘。关口险隘通常是通商的必经之路，而项目经理则是项目内外信息传递的关键人物。换句话说，项目经理就像信息的交换中心，所有的信息都会流向项目经理，并通过项目经理的过滤、处理再转发给相关的人员。

如果项目经理只认为这是一项繁重的工作，那相当于守着一个巨大的宝库却不自知，还当它是累赘。我们都已经大踏步地迈入了大数据时代，谁掌握着数据，谁就拥有强大力量和权力，应用在我们项目管理中也是一样的。项目经理利用“人脉”的信息渠道、本身的职责之便，一定会成为拥有最大信息量、最了解项目的人，大到全局，小到每项工作，甚至项目的初衷、未来发展的方向。当我们问，谁最适合为项目做出决策、把握方向？那回答一定是“项目经理”。因此，信息的管理权何尝不是项目经理的强大权力之一呢？

作为项目经理，第一要务一定是保证对信息的正确过滤和正确转发，让团队和相关人都能够获得足够的信息开展工作；除此之外，还要学会积累和吸收所有流经的信息，不能只是简单地转发，更要分析和深度挖掘，帮助团队找出问题原因，做出决策，把握方向。

案例场景

在项目中，两个有关联的任务、模块、甚至项目并行的情形时有发生，计划总不是完美的，需求经常变更，依赖任务、模块和项目延期，人员变动，等等。当某一情况发生变化，整个计划就有可能调整，而最清楚全局原来计划、变动情况和目前进展的人就是项目经理。所以只有项目经理才有足够的能力和信息，对现有计划做出调整，甚至调整资源分配，使得项目能够尽量按照要求完成。

话语权

“说话”是人人都有的一项平等权力，但是让人听你“说话”，可不是人人都有的一项义务。项目经理处在项目中心的位置，并且又掌握着最大量的信息，决定了项目经理必须承担起组织和主持会议、给团队传达信息的重要职责。责任总是和权力相伴的，项目经理就是一个在项目团队中拥有让成员听你“说话”的权力的人，这种权力也称为“话语权”。

在我们的生活中，各类媒体就是典型的拥有“话语权”的组织，它们拥有大量的信息，有权力决定传递什么信息、不传递什么信息、传递给哪些受众，甚至还可以增加一些有倾向性的评论，通过这些手段控制舆论，达到影响群体的目的。但任何权力都是把双刃剑，它能带给项目团队积极的帮助和不可思议的成功，也可能会因此导致团队的分裂，甚至项目的失败。

让人听你“说话”如果是你的一种权力的话，那让人听进去你说的话就是你的一种能力。作为项目经理，不仅要积累管理项目的基本知识和水平，还要有会“说话”的能力、在公开场合演讲的能力、沟通的能力。同时，我们还要时刻清醒地认识到使用这种权力给团队和项目所带来的影响，因为我们最终的目的始终是要让项目成功，而不是满足自己。

案例场景

项目团队是很需要被认可的，特别是被客户认可，这样才会让团队工作得更起劲。某项目经理经常会在周会中安排出5～10分钟的时 间，专门传达客户对于项目使用的感受，有好的也有不好的，而项目经理的表达技巧经常能让团队感受到客户对于项目团队的认可，也就乐于接受客户所提出来的一些反馈。整个团队的工作氛围越来越好，大家的主人翁意识越来越高，项目推进和产品质量也越来越好。

汇报

谁会认为汇报也是一种权力呢？这明明只是一项责任、一项日常工作而已。但如果我们再仔细推敲一下，我们就会发现，不是所有人都有权力向上级汇报的，汇报关系意味着你是最接近那个有更大权力的人的那个人。有时候，“狐假虎威”也能对人产生影响，简单点说这也是一种权力。

用“狐假虎威”，似乎有点贬义，如果用拳法来比喻，那强权好比刚猛的空手道，而汇报权力就好比太极拳，能四两拨千斤，以柔克刚。在团队中，我们要经常平衡和协调成员之间的关系，促进成员积极性的同时也要保持对工作的责任心。使用强权往往可能会下手过重，矫枉过正甚至适得其反。而借力打力，反而能在这些复杂关系中，找到合适的平衡点，既达到了效果又能避免冲突。

项目经理经常会被误解为包工头、监工，而好的项目经理需要具备相当高的综合素质和能力，除了管理专业知识、专业知识、技术能力和沟通能力外，还要有强大的平衡和协调能力。汇报不是打小报告，而要善于利用汇报关系，通过正向或负面程度不同的汇报信息，来调整不同成员之间的关系，这也是项目经理需要学会的技能之一。

案例场景

项目团队中，总有一些工作不积极、工作绩效也不是那么理想的同事。项目经理如果因为没有对他的考核权，就向他的上级汇报他的工作状况，以期望他的上级约束和管理他。应该怎么汇报，汇报哪些内容，达到什么目的，这些都是项目经理可以使用的权力。有些时候，认可往往比批评更容易让人接受和改变。当向他的上级认可和表扬他的贡献的同时再描述其不足，也许会起到更好的作用，当然这个汇报也需要让他看到和听到。

“With great power comes great responsibility.”这句出自电影《蜘蛛侠》，很有道理，意思是当你有了强大的力量，不要忘记你所应该肩负的责任。显然，初级管理者或者平凡者并不拥有强大的力量，那又如何担负起这么大的责任呢？而现实很多事情往往都是相辅相成的，当你承担起了多大的责任，你自然就会有多大的力量，只是很多人都被传统的“权力”的概念给蒙蔽了，忽略了那些因为你承担的责任而得到的力量，忽略了通过自己的才智灵活运用它。这似乎是个“鸡生蛋，蛋生鸡”的关系，唯一的破解之道就是先动手做起来，自己有多大能耐就干多大的事，干好了多大的事就自然会给你带来多大的力量。靠想是一定想不通也一定破解得了的。所以，我相信，“责任越大，力量一定也越大”。

走出“已知”的舒适区

文／曹智清

走出“已知”的舒适区，才能在“未知”的区域里认识新的自我，见识到更大的世界。带着忐忑和自信，进入到未知的区域里，快速学习、勤于思考和有力地执行让我们在“未知”的领域里感知和成长。

当教育给予人们的是流程和模板时，人们用它们来创造一个确定的可预知的世界；当教育给予人们思维方法时，人们就可以期待一个未知的充满创新的世界了。

小P的烦恼

案例场景

小P最近很头疼，他自己手头项目做得好好的，却突然被领导要求去参与一个新项目的投标。新项目是小P从未涉足的复杂领域，项 目客户方也是个很难对付的主儿，还必须得和另一家公司合作联合投标。领导既没有给小P明确的团队支持，也没说清楚如何看待这个新项目的价值。

一切的推进都很困难，但是小P只得硬着头皮上，心中满是负能量，直到有一天小P在反复推敲新项目的定位思考中，顿悟出一个道理：之前种种怨言，都来自一个词“未知”。小P一直都习惯于领导给定明确的任务，也能够完整地把这些任务搞得妥妥的，但是，真正的开拓并不在于这些可预知的世界，而恰恰在那些令人痛苦的未知上。

为啥说立项过程难于执行过程？为啥说策划角色总是被寄予厚望而又被诟病颇多？都是因为这些角色所需要的不是流程模板，而是知识和思维，加之敢于开拓的魄力。

走出“已知”的舒适区，积极地面对“未知”的环境和问题。当心态有了切换，你就不会再去寻找所谓的经验工具，而是真正激活自己的右脑，去思考、去分析、去面对、去拥抱“未知”了。

走出“已知”的舒适圈

项目经理的价值何在？除了从计划到上线的整个流程跟进，项目经理是否还有自己的独到价值？

项目经理小P最近至少花了50%的精力盯着一份研发资源协调表，当然不是瞎盯，而是逐行地比对目前的实际进展状态，思考时间是否足够，人力是否协调得开，需求的细节是否有待确认，各研发人员是否对需求有了认可和一致的理解，上线时间是否符合产品用户群的使用习惯，发布后运营时间上是否匹配了可借力的大规模推广……每一行都涉及至少2～3个风险点，小P需要找到对应人员做协调沟通，确保信息对称透明，能及时纠正刚刚发生的偏差。

这就是项目经理的风险管理，从理论上看似乎就是一张表，但实际上包含了对当前以及未来一段时期内的项目演变分析，更包括了因预见到问题而做出的积极响应。

除了有效的风险识别和应对外，小P发现：最近交互A对上游所给的方案非常不满、策划B和运营C之间就同一个案子的设计和配套推广分歧很大、商务E对于自己所提的产品需求迟迟得不到响应而意见多多、开发F和G最近工作总是打不起精神来、开发负责人H反映目前整个团队对产品方向不清楚……这些源源不断的信息片段，构成了项目的潜在问题集，小P需要从中去判断重要性，去分辨这些是事实问题还是信任问题。于是他又花费了大把的精力去了解和协调问题，从中提取出共性问题，从团队整体的角度做工作。

总结

从日常流程的跟进和团队沟通中，项目经理需要真切地感受团队中发生了什么，大家经历着什么，感受着什么，从中洞察问题，提取关键点，并找到正确的人促成这些问题的解决。无论是进度、质量、范围，还是团队、产品、文化，都需要项目经理用心把脉。

这样的风险管理、问题协调、团队感知，都不是用既定的流程模板可以框定的，它需要项目经理用缜密而开放的胸怀，通过深邃的洞察分析去强有力地执行。

基本的项目管理流程和进度跟进是项目经理的基础，而项目经理真正的价值在于那些超越了流程模板的思维方式和行事方法。

教育最终给予人们的，并不是知识本身，而是“学习力”，包括了“思考力”和“执行力”，这才是人们真正的核心竞争力！

项目经理的平衡之道

文／雷蓓蓓

项目经理常常处在一个平衡点上，需要巧妙地调整来保持各方的平衡，这种平衡是动态的，不同的环境、不同的时期，项目经理需要采取完全不同的行 动。如何有效运用平衡的力量，这需要直觉、判断以及经验，这也是项目管理被视为艺术的原因。如果运用得当，平衡之道本身就是一种力量，可以让你在各个角色、各种力量之间游刃有余。

我们所处的这个宇宙，每个星球都有着自己的轨道，它们各自运行、互相牵扯，却又奇妙地保持着动态的平衡。“一沙一世界”，一个项目中的各种干系力量也构成了一个小宇宙。好的项目经理会让自己处于一个“恰到好处”的平衡点上，知道在什么样的情境下，应该朝哪个方向用力，从而“四两拨千斤”，影响整个力量布局。本文结合自己的经验体会，从以下四个方面，谈谈我对平衡之道的理解。

平衡亲与疏

项目经理进入一个团队后，会发现团队很自然地分成了两个阵营，有人特别欢迎你，期望你的到来能够为他们带来某种支持，而另一些人的态度却要冷得多。这时，你很容易与你的支持者们相互亲近，对他们的痛点深度共情，在各种场合为他们发声。久而久之，你与他们打成了一片，甚至不自觉地带着他们的视角去看问题。而在别人眼里，你俨然成了这一方的“形象代言人”。

初来乍到一个陌生环境，项目经理想要站住脚，这种做法本无可厚非，可如果长期下去只是代表一种声音，无异于画地为牢，作茧自缚。作为项目经理，你得到的是一部分人的高度支持，但失去的却是一个珍贵的第三方视角。可以想象，要让另一方阵营敞开心扉去接受你、信任你、继而配合你的工作，无疑将变得曲折和漫长。

平衡强与弱

案例场景

X项目，测试的同事煞是苦逼，最后关头测试时间总被挤压，每次出问题测试还首当其冲地被公开责难，生活在一片水深火热之中。项目经理介入后，在很多公开场合创造机会让测试发声，争取大家对 质量的更多重视。伴随着一系列措施的推进，大家对测试的声音越来越重视了。可好景不长，事情似乎变得有些走味了，发声的机会俨然变成了测试发起炮轰的阵地，大家怨声四起。

项目经理天生的“使命感”——要为“穷苦大众”伸张正义，使得他很容易与项目中的弱势群体打成一片。这其实是一种有意识的平衡，但值得注意的是，强势弱势往往是动态变化的，因此这种平衡也一定要动态地变化。为弱势群体撑腰撑久了，弱势也有可能在某种场合下转变为强势。对弱势者的“过度”保护，实质上会造成对其他所有人的不公。

平衡内与外

面对外界对团队的非议，项目经理是站在团队立场一致对外、努力维护，还是站在外界用户或其他相关方的角度，义正词严地要求团队改进？

如果你是梦鸽，面对外界对孩子的指控，是鸣冤叫屈、百般维护，还是厉声呵斥、责其改进？

带团队与育儿一个道理，走得太近、关系太密，你会跟团队产生情感关联。别人说团队哪点哪点不好，条件反射般地你就会站出来维护，那些话就像句句都是在说你一样。与团队的共情，无疑会加深团队对你的信任与依赖，但另一方面，也会遮住你的双眼，让你对他们真正该提高的地方视而不见。

在这种情况下，更为合适的做法，或许是在“设身处地”对团队表达足够的理解和同情之后，以开放的心态去体会外界所反馈的痛点，最终引导团队认识到自己的问题，促成其自愿自发地改进。

平衡抑与扬

通常人们会认为，批评要谨慎，表扬则多多益善。但实际上，表扬或鼓励也会成为矛盾的导火索，如过度鼓励苦劳容易让功劳者失望，过度强调功劳容易让苦劳者心凉，等等。

在弱矩阵结构下，项目经理虽无实权，但因其职务关系，会给其带来很多话语权。如项目经理主持的面向项目组高层负责人的周会，公开对外的周报等， 这些公开的舆论阵地，很容易使项目经理处于舆论的中心，所以说话做事更要平衡好尺度。

这样说是不是我们就干脆不要表扬了？如果这样想那就又极端了，更为合适的做法是，在你进行表扬时需要经过深思熟虑，知道你这样做会在团队中强化哪种行为，抑制或打击到哪些人、哪些想法，想清楚了再做。如果无法预估后果，建议你尽量避免直接发起表扬，如果一定要表扬，借他人之口或许更为中立。

结束语

不同的环境、不同的时期，项目经理需要采取完全不同的行动，这些看似矛盾的做法有时会让你陷入悖论和困境之中。如何有效运用平衡的力量，这需要直觉、判断以及经验，这也是项目管理被视为艺术的原因。如果运用得当，平衡之道本身就是一种力量，可以让你在各个角色、各种力量之间游刃有余。

但是，想做到“恰到好处”的平衡非常困难，有时在特定时期你天然需要一定的倾向性才能办好事，但更重要的是你必须对此保持警醒，后退一步重新思考一下，自己这么做出于什么考虑，会有什么样的影响，以及什么时候需要重新调整你的平衡策略，做出更合适的决策。

给新上任的领导者的五个忠告

文／雷蓓蓓

刚刚成为领导者，角色发生了转变，从对自己负责变成要领着其他人一起向前走，从关注事情变成要同时关注人的状态，从提升自我变成要培养团队，从自我激励要包容和激励团队，这中间有许多需要学习的地方。

从最初懵懵懂懂开始带人，到如今虽然仍无甚建树，但因为耳濡目染，没少跟在一些老大身边偷学，在努力做事的同时，也在悉心观察他们的一言一行、为人处世，那些不言之教，总算让我开始有了些许体会。

加之身边有不少因为自身专业表现出色、由明星员工转而开始带人的案例，看上去是好事，可岂知这个转换就像吃饭右手换左手，尚未摸到门道的新上任的领导者们，并不总能一帆风顺。这里结合自己的经验体会，给出一些建议。

关注人的状态，不只是事的进展

从做业务走向做管理，首先意味着思维模式的巨大转变。有很多业务明星刚开始带人的时候，往往还意识不到一点，此时最容易犯的错误，就是只关注事而忽略人。分配任务下去，然后期待一个好的结果，过程中一旦出错，忍不住跳进去马上指出，接着下一次又出问题，不明白为什么已经说得很清楚了，事情还是没有按照预期开展。怎么办？

其实，事情一再出错，往往预示着一个信号，提示你应该做出些调整。这时，不妨暂时放下这件事情本身，用心感受一下他最近的状态，放下预设的判断，坦诚地和他聊聊，他做得开不开心？有没有遇到什么困难？到底是能力上还有差距、需要进一步指导，还是环境还不太适应，没有得到足够的支持？当前的工作是否符合他原本对自己的规划和设想？……所有这些问题，都会影响他的状态，先找好原因，然后仔细去思考，你做什么样的调整，可以对他有所帮助？

人不是机器，做一个合格的领导者，应该锻炼自己的这种同理心，敏感地发现潜在的状态偏离，在事情出错之前做好预防和调整，而不是事后补救。说到底，管理者经营的是什么？是人心！铁打的营盘流水的兵，人心是这天下最易变的东西。好的管理者，就像转盘子的杂技演员，盘子一直在变，杂技演员每时每刻都需要不断地平衡，才能把每个人不同阶段的诉求，与整个组织的整体目标始终保持在同一频率上。

培养人才是你的天职，你责无旁贷

“领导力就是把一个人的精神境界、责任心提到前所未有的高度，然后才能把一个人的潜力、持续的创新动力开发出来，让他做出他自己以前想都不敢想的那种成就。”

每次看到德鲁克的这段话，我总是会心潮澎湃，受到莫大的鼓舞，激动之余，深感责任之重大，差距之无穷。

案例场景

孩子给你倒橙汁，一不小心打破了杯子，弄湿了你正在工作的电脑，你会做何反应？

第一种，顿时火气上袭，“怎么这么不小心！”被长期这样对待的孩子，胆小怕错，遇事缩手缩脚，而你也别指望以后再能喝到橙汁。

第二种，尽管很生气，但发现孩子很害怕，停下来安慰孩子，“妈妈知道你是好心，杯子破了、电脑坏了没有关系，下次要小心”，然后自己去收拾残局。这类孩子长大后，安全感很足，但是自己一旦闯了祸，就别怪他们只会撂下一句“我爸是李刚”。

第三种，安慰了孩子的心情之后，看着一片狼藉，问孩子“现在该怎么办呢？”，然后，与孩子一起打扫收拾，把东西归位。这类孩子会有更强的主人翁精神，积极乐观，同时又勇于承担。

大部分父母以为自己是在教育孩子，其实我们往往不是在发泄情绪，就是在应激反应。大部分管理者亦是如此，有谁又真正明白，就是在这么一件无比简单的小事上，你的这么一次没有过脑子的反应，在决定着他会变成一个怎样的人。

管理者的责任，就体现在这一点一滴的小事上。一个真正成熟的管理者，会把每一次互动当作一次宝贵的机会，在处理好当下的事情的同时，又能让其有所领悟、有所提升，最大限度地得到激励。

学会看人之大，选择激发善意

你的团队里有没有问题员工？如果你的第一反应是有，那么那些出现在你脑海中的人，恐怕你已经给他们贴上了标签，你和他的沟通也已经出问题了。有时我们常会陷入一个怪圈：一段时间注意到了某人的缺点，然后越看越觉得碍眼，总想把他拧过来，不改变他，就浑身不舒服。陷入这个怪圈的领导者，往往忍不住想尽各种办法去纠正错误，大多数时候，你会遇到各种形式的抵触或反抗，而这些应激性的抵触、反抗、自我开脱、不合作，也封上了进一步成长和改进的大门。

“领导者天天都要面对既可爱又不完美的人，面对人性中的善、恶、潜能、长处和弱点。任何有经验的领导者都会明白这一点。领导的本质，其实就是激发和释放每个人的善意。”

经历了越来越多的人和事、对自己越来越了解之后，越发觉得人无完人，一个人有多少优点，就一定会有多少缺点。每个人心中都有个希特勒，即使那些头戴光环的榜样们也不能幸免。之所以显得完美，只是因为被距离掩盖而已。认清了这一点之后，看待他人的缺点和自己的缺点，都会变得更加宽容。因为，我知道所有人都一样，只要给以适当的环境，那么终究可以瑕不掩瑜，潜能得到最大化的发挥。

那么如何面对他人内心中的恶呢？我的经验是，你首先要学会的是处理自己内心中的恶，如不要轻易对人下结论、贴标签，要先从善意的角度出发，去理解他人的行为动机。这样做的领导者，会在他的周围聚集一股善意，即使他一开始确实有不好的动机，那又如何，要往好里带，越是正面视之就会越来越好。这样的领导者所在的组织，环境中的“仁率”会越来越高。在这样的组织中，人们会互相正向影响，从而不自觉地促使他人改变行为，让善意不断发酵扩散。这种影响可以让每个人直面自己的问题，心甘情愿地做出改变。

看人之大，是一个领导者必须学会的功课；激发善意，是了然真相之后的一种智慧的选择。你永远无法真正去改变一个人，但你可以做到改变环境。这个环境是什么？大到一个组织的制度机制、文化氛围，小到你的一句话，一个眼神，一次回应，这个环境就是“你”本身。

因人而异，却又以不变应万变

“水因地而制流，兵因敌而制胜。兵无常势，水无常形，能因敌变化而取胜者，谓之神。”管理永远因人而异，没有标准答案，要充分尊重个体差异性。严厉要求，还是谆谆教导，只是方法不同。偶尔激将，偶尔鼓励，只在情势所需。成熟期的小困惑、青春期的小叛逆，皆需要你因地制宜，见招拆招。或许管理的魅力就在于此，千人千面，你永远不知道下一个会碰到什么样的问题，需要什么样的解法，以及你之前的经验是否适用。

这也给我们提出了无穷的可能性。虽有差异化，但在差异化的背后，领导不变的内核，只在“情理法”三字之间。因循不同的情境，动之以情，晓之以理，必要时也“绳之以法”，才能让领导行为真正发挥效用。

最重要的还是做好自己

曾仕强在《中国式管理》一书中，开篇就谈到，管理是修己安人的历程，起点是修己，终点则是安人。要在管人之前，必须先把自己管好。作为领导者，就是要以身作则。

有人会说，这一点最容易，我是业务明星，我就是榜样。岂知这里的“以身作则”，不只是指才，更是指德。你是否胸怀广阔、志存高远，是否身先士卒、甘为人梯，是否以责人之心责己，以恕己之心恕人，人们心中自有明镜。管理风格可以因人而异，但永远不可替代的就是“敬”。这种发自内心的“敬”，是一切管理或领导行为的基础。离开了“敬”，人们只不过是屈从于职权而听命，终将无以为继。

这并不意味着你需要成为完美的圣人或道德楷模，你可以有弱点，但要真实；你可以犯错，但要敢于认错；你可以不完美，但要保持修炼。曾经与友人聊天，聊到他最敬重的一个老大，其中一个细节让他一直记到现在。那时他的一个同事离职了，这个老大当着大家的面，无比诚恳地对所有人说；“他的离开是我的失误，是我没有做好。”顿时全场汗颜！老大把离职同事一路送到电梯口，满是歉意地看着他离开，那么长长的走廊，他就这么一直陪着，众人震撼得无以言表，心中除了尊敬还是尊敬……我想也许这就是“其身正，不令而 行”的含义吧！

最后的话

领导上的修炼永无止境，自知刚刚摸得一些门道，越了解越敬畏。谨以此篇小文，向我的领导者们，以及合作接触过的各位老大们致敬，感谢你们的不言之教，让我一路走来每每可以有所领悟。

“学而时习之，不亦说乎！”从今以后，谨言慎行，每次行动之前，问自己三次，我这样做，有建设性吗？我这样做，有建设性吗？我这样做，有建设性吗？与各位共勉！

主管的引导者角色

文／靳霄

有人说领导的一个角色像助产士，是在帮助另一个生命的诞生，你的方式应该让那位母亲认为自己得到了帮助并且感到自在。这就要求主管在没有必要的时候不应该插手团队工作，要引导正在发生的事情，而不是主导你认为应该发生的事。

作为主管，要担当三个角色：领导者、管理者和引导者。前两个角色主管都比较有意识地去履行，引导者角色却被很多人忽视了。

那么引导者是做什么的？为什么需要主管的引导者角色呢？

所谓引导者是指，无论面对什么问题，总是内心询问自己：该怎么做，才能协助团队进行积极而具有创造性的讨论？而非只是自己去找出问题的答案。需要引导者角色的原因在于，其一，如果团队不参与找出问题解决方案的过程并将决策视为己任，或对决策不认同，执行时会只是应付了事，更可能产生误解；其二，组织成功的关键因素，不仅在于产品、服务、技术，还在于组织是 否有能力激发并运用其成员和相关者的智慧。

作为引导者需要具备哪些技能呢？

技能一：设计流程

例如，当主管想要组织一场讨论会，这个讨论会的流程就很重要。因为即便讨论的内容相同，若是搞错先后顺序，可能就得不出有效的结论。也就是说，要引导一场精彩且成功的讨论会，事先就要深入思考流程，并且细心规划。大家可以回想一下自己的经历，有些讨论会往往卓有成效，而有些却毫无结果。

对于设计流程，首先必须明确这个流程要达到的目标是什么。目标包含两个内容——“目的”和“成果”。

目的，就是要达成的意图。比如，提高员工的工作积极性，或者改进项目流程。

但是，光有目的有些抽象，会议后会产生“今天讨论得的确很热烈，但是有什么决定吗”的疑问。

为了解决这个问题，在设计流程时，要预先想好要得到的“成果”。例如讨论会的“成果”就是相应的若干结论，如跟进事项的清单等。

有了目标后就要开始设计流程的细节。一个要注意的原则是，即使你觉得会浪费时间，也要留出足够的时间给大家进行“发散”的过程。如果跳过“发散”直接进入“收敛”阶段，就无法收集成员有创意的想法，也有可能导致成员的不满情绪。

技能二：控制现场

在引导的过程中可能会发生很多不同的状况。有时候设计好的流程，可能会因为现场出现意外情况而无法顺利进行。

例如，参加的人员比预期的还要沉默，或者过程中出现了强烈的抵触情绪。如在项目总结会上，本来的目的是讨论项目过程中的不足和改进的方案，但是有时会出现意外状况——不同角色开始进行激烈的争吵。引导者需要妥善处理这些场面，并控制现场的流程。

这个过程对引导者的情商要求比较高，首先需要能够很好地控制自己的情绪，只有先控制好自己的情绪，才能维持好成员之间或成员和引导者之间的关系。

技能三：启发想法

在引导的过程中，如果从很多成员那里都得不到回应，引导就很难开展下去。例如在技术评审会中，如果现场的技术人员只关心自己模块或比较内向，那就很难收集到意见。

因此在过程中如何启发大家的想法和观点，如何以他人的观点为基础，进一步激发、碰撞和延伸，以产生更多灵感就极为重要。为了达到这个目的，引导者可以使用有效的提问方式，或者一些工具来辅助大家更好地表达意见。

我们以“曼陀罗九宫格”为例说明一下工具的使用。这个工具的目的是“以复眼思考方式激发创意”。

（1）使用场合。在遇到大型主题或同时思考数个子议题时，曼陀罗九宫格可以引导出创造性的内容。在不偏离主题的情况下，同时思考4～8个子议题，这样参加者不仅可以鸟瞰整体状况，有时也可以发现原先没有想到的关联性。

（2）工具使用方法。

•　在白纸的正中央大大写上讨论主题。

•　以四分法或九分法分配子议题，必要时将子议题名称写在分割的栏目中。

•　以正中央的主题或栏中的关键字为引导，写出联想到的想法或意见。各自的关系用颜色表现或以箭头连接，这样更能够引发新的想法。

（3）使用案例。

使用曼陀罗九宫格的一个经典案例就是现在比较流行的“精益画布”，如图4-1所示。

技能四：达成共识，改变行动

讨论出的结果必须是全员共同达成的结论，这样在执行时才会推进得更好。为了达成共识，就要在一开始对做决定的方式达成一致。达成共识固然重 要，但是最终还需要相应的“改变行动”进行跟进，所以引导活动要以行动计划收尾。

图4-1　精益画布（示例）

总结

综上所述，作为主管，要不断练习自己作为引导者这一角色的技能，调动起团队共同的创造力。

从混沌中找出根本原因

文／何燕华

多项目并行是导致团队归属感差、计划难以制订、任务切换的额外成本高等诸多问题的根本原因之一。团队拆分、减少成员的项目并行、固定迭代长度、审视项目的优先级、强化计划过程等措施可以有效降低多任务并行给团队带来的困扰。

这是一个已经在线上运行多年的产品，因业务调整，业务线增多，同时有五六个项目并行，人员数量并不算多，大概20人，当时的情况是一个开发人员可能需要同时参与三四个项目，每天还有不少日常线上支持工作。团队成员为了完成计划经常加班，但还是赶不上进度，项目计划总是不停地调整。团队负责人焦头烂额，因为对外界的承诺已经给出，却迟迟拿不出成果。同时团队成员也感觉无力，明明已经很努力了还是赶不上计划，有些成员的情绪产生了一些波动。

当时团队出现了几个比较严重的问题，下面我们来分别看一下这几个问题以及产生这些问题的原因。

问题一：计划不准确，进度难把控

现象： 有些同时参与多个项目的团队成员经常会跟项目经理说：我在A项目的提测点要延后，因为B项目那边我要多加一个任务，那个要更早做，不然B项目的QA同事会处于干等我的状态。也有的情况是，团队成员告诉项目经理：我在A项目当时的估算太乐观了，任务做下去才知道远没有这么简单，所以我B项目的任务要相应延后了。由于对人员的依赖性，项目之间会出现两两依赖的情况。所以项目的计划经常需要调整，后续的进度也很难预测。

原因： 所有项目的计划不是同一时间做的，一个成员在做A项目计划安排的时候，他后续需要投入的B项目的计划还未开始做，所以在做A项目的计划时很大程度上是拍脑袋。在计划阶段缺乏深入的探讨和思考，对任务理解不到位，就会出现估算乐观的情况。

问题二：项目成员缺乏对产品的主人翁意识

现象： 项目的策划案、交互稿、视觉稿，大家没有积极审核，他们觉得：这又不是我的任务，我本来就很忙了，这样不是把我往死路上逼嘛。策划和视觉稿确认了再来找我们就行了，你们负责需求，我们负责实现。这样的结果往往是，有一些方案在开发实现上明明有困难，却在最后开始写代码的时候才发 现，策划案修改导致一些返工。另外，开发和QA之间的界限划分也会特别明显，是开发的事情QA不管，当然，QA的事情开发也懒得帮忙。

原因： 如果一个成员同时参与三个项目，那么平均一下，他可能在每个项目的投入只有30%，说明他在整个项目中可能只是做了一小部分，很难要求他把产品整体的设计思路都去理解一遍。另外，精力有限必定先做开发任务，怎么可能让他从产品整体角度思考问题、为产品的未来做打算？能够把任务做完就不错了。

问题三：加班情况严重，团队出现疲态和怨言

现象： 团队所有成员，包括开发、测试，甚至策划、运营，都开始加班，有的成员经常熬夜到凌晨。

原因： 工作量大是一方面，很重要的一方面在于多任务并行造成的切换成本。想象一下，从一个任务切换到另一个任务，然后再切换到另一个，这个过程中的开销是非常巨大的。Mike Cohn所著的《Scrum敏捷软件开发》一书中提到，假设一个开发人员在一个月的产出为1，如果他同时参与两个项目，那么他在这两个项目的产出和就为0.8；如果同时参与三个项目，那么产出和就降为0.6。如果项目更多的话，这个值就会更低。另外，软件开发过程需要团队各角色间不断沟通。有研究表明团队成员每11分钟会被打断一次，如果一个人同时参与三个项目，那么他的沟通渠道就会乘以三，可想而知他被打断的频率是多少了。有的项目成员也会反馈：我白天的时间只能应付邮件、即时聊天，以及各种沟通，只有到了晚上才有时间码代码。为了不让进度偏离得太离谱，很多成员就选择加班来赶上进度。但是加班是需要慎用的一种赶上进度的方式，短期采用或许能加快进度，如果团队长期处于加班状态，不但当前版本的进度加快不了，还会影响后续很长一段时间的团队生产率。有研究表明，从团队连续加班第四周开始，生产率就开始下降。

应对措施

分析下来，我们不难发现，导致团队种种问题的原因中，有一条是非常根 本的，那就是多项目并行。它不仅会导致多任务切换的额外成本高，还导致团队在任何一个项目上都没有归属感，也会增加计划之间的牵扯，使计划很难制订，并引起一些连锁反应。

所以我们围绕这个问题采取了一系列的应对措施。

（1）进行团队划分。将大家分为三个团队。其中两个项目团队主要承接项目需求，另一个是支持团队，主要承接每日来自线上和用户反馈的开发任务。当然在团队划分的时候尽量新老结合，让经验丰富的成员带领新成员尽快熟悉业务。这样项目团队和支持团队可以分开工作，最大限度地减少日常支持工作对于项目造成的影响。

（2）减少成员的项目并行。每个成员尽量只服务于一个项目，如果有些开发成员实在无法只服务于一个项目，他会有一个投入超过60%的主要项目，有了这个60%，至少他会对这个项目有更多的归属感，总好过对所有项目都没归属感，他在这个项目中的参与度也会更高。

（3）进行固定长度的迭代方式。两个项目团队每两周更新一次计划，两个团队在同一天做项目计划，一个在上午，一个在下午。这样方便有项目并行工作的同事统筹他的精力分配。

（4）审视项目的优先级。把项目分出优先级，一个团队可能会负责两个项目，但是这两个项目有优先级区分。例如团队一负责A项目和B项目，A项目优先级更高，那么团队最先开始一个A项目的两周计划，接下来两周做B项目的计划。当然如果A项目结束后，发现A项目接下来的需求优先级比B项目高，则会继续开始一个两周的A项目计划。

（5）强化计划过程。每个两周计划前会有一个迭代计划会，需求会在这个会上被理解清楚，因为每个需求都会被要求做WBS和估算，如果需求理解不清楚或不去理解需求是没法做WBS和估算的。这个过程促使开发和测试人员更早地去与策划讨论需求细节，在迭代过程中变更就会更少。

这些措施实施一段时间之后，项目经理渐渐观察到一些小的变化：

（1）某些开发同事开始不时地找策划同事讨论需求中未完善的细节。

（2）某个测试工作量很大的迭代，开发和其他角色的同事主动要求承担部分测试的工作。

（3）某个项目的一个迭代中，测试环境被其他项目占用，需要用一个新部署的测试环境，但是这个环境之前都有一些问题，一直没能用起来，这次测试和开发人员齐心协力，在半天时间内搞定了之前很长一段时间都没搞定的问题，顺利用上了新环境。

（4）大家加班的情况得到了缓解，曾经有对立关系的测试和开发人员的关系更融洽了。

……

其实在这个案例中，虽然看起来问题有好几个，但是最终分析下来，会发现有一个最根本的原因，这个原因导致了一连串的问题，把这个问题解决了，其他问题就会迎刃而解。所以有的时候我们需要跳出框框，从更高的角度去思考和归纳问题，这比埋头解决一个又一个问题更重要。

项目成功路上的绊脚石，你遇到了吗

文／何燕华

有很多人都会问：我怎么做，项目才能成功？对于这个问题，笔者认为很难回答，因为每个项目所处的环境、人员等各方面因素都不一样，同样的事情在不同的团队里开展，效果可能是截然相反的。但是有一些影响项目成功的“绊脚石”，却有可能大家都会遇到。

“我怎么做，项目才能成功？”笔者目前还不能很好地回答这个问题，只是对于那些影响项目成功的“绊脚石”，有所感悟。而且这些“绊脚石”正在以各种形式不断地出现在不同的项目中，影响着项目的顺利交付。在笔者曾经所在的一些团队中也遇到过这样的“绊脚石”，给项目的成功制造了不少的麻烦。我们是怎么被绊倒的？如果再给我们一次机会，我们会怎么做呢？

目标和计划“跳一跳”完全够不着

案例场景

在有的团队里，领导会把项目目标和上线时间一手包办了，并且这个上线时间和需求的范围是不允许调整的，团队成员只能照此去倒排计划。对于实际情况来说这个目标定得过高，团队成员也心知肚明，但由于是领导定的目标，而且态度坚决，所以没有人愿意站出来挑明这个问题。

结果： 在这样的项目中，由于计划是根据截止日期倒推的，而不是根据实际需要的开发工作量来估计的，所以经常出现的情况是：团队经过加班仍然完不成计划，需要一再调整计划。到了一定程度后发现实在没法完成，在上线日期无法改变的情况下，不得不调整范围。后续的情况就是这样的循环，计划往后推→调整范围→计划往后推→调整范围。到最后需求被砍得面目全非，完全不是领导期望的样子。

解读： 目标和计划不合理的情况，对团队的影响其实非常巨大。首先，目标和计划由领导一人包办加上定得又不合理，使得团队成员不仅没有参与感，也没有积极性，觉得这本身就是不合理的，再努力都不可能完成，还不如不努力，就算失败了也不关我的事。这个时候就算硬性要求加班，效果也不会那么理想。其次，在执行过程中，不断地调整目标和计划，会让目标和计划丧失应有的严肃性，团队会觉得，反正是可以调整的，不必太在意现在是怎么定的，到时候能做多少就做多少，连努力的动力都没有了。

如果上天再给我们一次机会，我们将会：

（1）最佳的状态是团队能在一开始就参与目标的制定，例如可以请团队各角色制定自己对应的目标，给领导一个参考，最终由领导统筹整个项目的目标。

（2）如果领导非要包办，那么项目经理可以做的就是创造一些机会和场合，让制定这个目标的原因和意义能够同步到整个团队，例如在周会、月会等场合请领导亲自向大家介绍这个目标，以及这个目标对于整个团队和产品发展的意义。

（3）项目经理还可以将团队当前的一些客观情况反馈给领导，供领导在制 定目标时参考。例如目前团队成员的资历构成（资深、高级、实习人员等的比率）、团队的加班情况（考勤数据），以及团队成员的某些情绪状态等。

（4）当然，在目标制定的过程中，项目经理也可以充当一个客观的第三者，给团队或者领导一些建议。当看到目标超出团队能力范围太多的时候，可以适当发出声音，对这个目标施加一定的影响。因为如果是团队提出这个目标太高、完不成，领导未必能听得进去，他会觉得你们连试都没试过就说完不成。但是如果是一个第三者的意见，也许会更客观和有说服力一些。

除了码代码，其他都不重要

案例场景

开发人员在进度紧急的情况下，总会有这样的认识：码代码才是正事，其他都是扯淡。经常出现这种情况：进度太赶了，所以策划和交互稿可以先出框架，先开发那些定好的部分；详细设计可以先不做，直接进入代码开发；单元测试和代码评审都可以不做，有时间再说；不要站会，一周一次的周会都嫌多，更别说总结会。

结果： 实际上，往往会出现这样的情况：需求和交互稿在不断完善的过程中不断修改之前的内容，导致大量开发工作返工；详细设计没做，接口、协议等都没定义清晰，结果某组件开发完之后与其他组件联调时完全不能通，发现大家对设计的理解不一致，于是返工重做；没有进行代码评审，有些资历较浅的成员的代码没经过评审就合入了，最后发现可维护性很差，导致很多返工；沟通会都省略了，大家都自顾自地开发，导致问题的发现比较滞后，问题的解决也比较缓慢。

解读： 很多时候，开发人员觉得只有写代码才是正经事，那些会啊文档啊，都是你们管理人员希望我们做的，对我们来说是浪费时间。所以团队成员会天然地抵触这些东西。只要项目经理一提，团队就说：不要，不要。实际情况是以上所述的情况基本都会发生，号称前期“节省”的那些时间，后期要用更多的时间来弥补，根本没有达到“快”的目的。

如果上天再给我们一次机会，我们将会：

（1）策划和交互稿最好在开发开始前完成，就算有一部分未完成，那也必须是相对独立的，不会影响原有的设计。

（2）详细设计最好有，就算边做边写，也好过完全没有。

（3）一周一次的周会对于团队来讲真的不够，建议一周至少两次沟通；对于三个月的项目来说至少每月一次总结会，以便及时地收集团队成员的想法并调整策略、目标和流程规范。

（4）重视代码评审。对于有新成员的团队，需要有资深人员帮忙评审新成员的代码，无法做到前评审，至少可以在测试阶段做后评审。

不断有需求加入

案例场景

开发过程中，来自高层的各种需求源源不断，需求来了就得接着。关键是加了需求之后，其他的需求却没法相应删除，于是需求越来越多。

结果： 需求越来越多，团队的生产力有限，到了持续加班后还是无法完成的地步，最终迫于无奈还是有许多需求被砍掉。由于最初目的是想把所有需求都完成，看起来所有的需求优先级都很高，没有真正进行优先级排序，导致最后完成的不是最高优先级的需求。

解读： 当大家觉得这些需求都要被完成的时候，就不会再去纠结到底是1的优先级高还是2的优先级高，反正都是要被完成的。于是有可能1先开发，也有可能2先开发。最后，到了不得不砍需求的时候，发现优先级低的已经被优先开发了，而优先级高的却还没有做完。

如果上天再给我们一次机会，我们将会：

（1）每个团队能消化“额外”需求的能力是有限的，且不说开发进度已经非常紧张的情况下。就算按照正常的估算进行计划的项目，也有一定的消化“额外”需求的比率。这个比率可以通过几个迭代的数据统计出来。

（2）超出这个比率之后，再有需求加入必须考虑它的优先级在哪里，如果从优先级上它能排进来，那么就应该把优先级低的需求清理出去。

（3）必须排定所有需求的优先级。在考虑优先级时，可以借鉴“如果明天是世界末日，你最想做的是什么？”的思路。通过想象“如果这两个功能只能完成一个，我会选择什么”来区分需求之间的优先级。

团队感染了一种情绪，你发现了吗

案例场景

有没有遇到过类似这样的情形？策划说：这个需求调整到这个时间行吗，小A？同事A：行吧，先这么排吧，能做多少就做多少。然后产品经理转头问B：小B，这周之前把这几个需求完成，如何？同事B：行啊！同事A：小B啊，这么多需求，这周完成？我看不大可能啊。小B：是啊，能做多少做多少呗！

结果： 事实就是如以上两位所说的，最终需求还是因无法完成而一再被调整。团队大部分需求都开始延期，计划制订后一改再改。

解读： 当团队里有一两个同事出现这种“无所谓”的态度时，其他同事会无形中被影响。渐渐地大家都会觉得就应该是“能做多少做多少”，不再主动承诺什么。这种情绪在团队里开始传播时，需要及时被控制。

如果上天再给我们一次机会，我们将会：

（1）当有类似情绪的苗头出现时，项目经理就该找相应的人沟通，必要的时候邀请产品负责人一起来沟通他的疑虑。判断这种疑虑是否有必要，如果没有必要，那就要与他沟通好，防止他的这种情绪影响他人。

（2）如果这种情绪是合理的担忧，那么就该坦诚布公地讨论这个问题，解决他的疑虑，让大家都不再有这样的疑虑。

后记

以上这些“如果上天再给我们一次机会，我们将会……”，看起来都是“马后炮”，事实上还真的可能只是“马后炮”。在有的新团队里，当他们没有经历过上述痛楚的时候，是无法深刻理解这些建议的意义的。那些经历过这些问题 的团队，他们会懂得笔者都说了些什么。当然也有一些团队思想比较“开放”，容易接受这些理念，在项目开始时就能对这些问题采取相应的措施！本文就献给那些已经经历过，或者正在经历这些痛楚的，以及那些正在寻求建议的团队们吧！

超越“老和尚”期望的那三两件事儿——论个人工作方式

文／刘煦萍

工作中的我们每天都在处理这样那样的事情，也都希望自己做的事情让出题人满意，而且为了高效我们往往会根据出题人的指示直接去做。这样能否完成目标或者说达到出题人的预期效果呢？今天笔者想跟大家聊聊个人工作方式，说说那些或许大家都知道但忽视的问题。

从前有个老和尚，有一天他在海边走时听到海对面的寺庙里发出的钟声是他从未听到过的：圆润、浑厚而且深沉、悠远。他决定去海对面寺庙取经，于是对庙里的小和尚们说：“你们去山下帮我买一艘小船，我这里有5两银子，5天后我要用船。”小和尚们商量之后决定明天一早分头行动。

第二天傍晚大家回来后发现情况不妙，因为最近树林里有怪兽出入，村民们都不敢去砍树，导致没有船可以买，即便有，价格也是高得离谱。大家陷入沉思中，突然有个小和尚说：老和尚4天后就要船，现在我们自己做恐怕是来不及了，又买不到，那我们可不可以先租海边的那些船？小和尚们纷纷表示认同，第二天一大早大家分头行动去租船，傍晚回来发现情况仍不乐观，连租船的价格都贵得离谱，5两银子租不到船。于是大家又陷入深思。

亲爱的小伙伴们，如果你和你的团队就是这群小和尚的话，此时你会想到什么办法呢？

沉默中突然有个小和尚说，那租不到整条船，是不是可以和别人一起租呢？老和尚到底买船要做什么呀？“对啊！老和尚买船是要做什么啊？”大家纷纷议论道，“走，去问问老和尚”。老和尚告诉他们说，“我就是想到对岸的寺庙去而已。”“那您和别人租船过去可不可以？”一个小和尚问道。“可以啊！”老和尚笑着回答。“那您坐普通的渔船过去可以吗？那个要便宜一半呢？”小和尚又问道。老和尚说“可以啊！”“想要到对面去，其实可以坐马车过去，西山脚下有桥而且很便宜呢。”“其实还可以……”这时又有一个小和尚问道：“您去那里要做什么？”老和尚说：“我就是想知道对岸寺庙的钟声是怎么发出来的。”另一个小和尚说：“其实可以让信鸽代劳不是吗？”

听到这儿，也许你会说，哎呦，绕了一大圈子早说明白不就早解决了嘛！是啊！这种旁观者看来如此容易的事情却经常蒙蔽我们的双眼，是老和尚不愿意说吗？从后面的对话中可知不是那样的。为了圆满完成任务，任务的接受者需要主动获取更多信息。完成项目也是同理，需要我们了解背景上下文，是否有时间、地域、环境、人员、费用等各方的限制条件？有怎样的限制？最侧重的限制因素是什么？做这件事情的目的是什么？我们需要做到怎样的程度？等等，尽可能获取我们需要的信息，否则我们可能往往纠结在对方要我们做的事情上，或者解决他所说的那个问题，而把背后真正要解决的问题忽略了。所以在接到一个任务的时候要带着一些方法，多问几个“为什么”，多挖几层深层原因，获取更多有用信息，这样对以后开展工作是十分有益的。

在我们的工作和生活中，每天都会做“老和尚”交给我们的活，如给老婆大人出去买双拖鞋，帮朋友订个酒店，给上司预订个吃饭的地方，完成领导交代的工作等，看似一件小事，想把它做好了也不容易哦！其实我们可以通过下面的四个步骤尝试把事情做好、做出色。

抓根本问题或者说抓住问题背后要解决的是什么

有时候不好直接去问对方：“你要这个准备做什么？”那我们可以做一些“委婉”的引导式沟通，如就目前对方要求的事情给他一些选择项或者提出能获取更多信息的问题，在本文开篇的例子中，当老和尚第一次对小和尚说要买船的时候，就可以问：对船的大小有要求吗？1个人还是20个人一起坐？旅行有多远？如果过夜的话要有能遮盖的篷吗？这样的问题选项抛出来之后，会离当前要解决的问题背后的目的越来越近。

常常出现的场景是，当事人以为要实现A只能通过采用B的方式才可以，所以在交代任务时也只是让其去完成B，但有时候B不太好实现或者其实可能不是比较好的解法。平时的工作生活中我们要注意这样的“陷阱”。当然通常我们只要完成“老和尚”交代的事情也就算把事情做完了，但如果在这个过程中我们能避免做无用功或者说有更优解，并以合适的方式沟通和执行，或许老和尚对你的满意度会有意想不到的“涨幅”。

注意限制因素，特别是关键限制因素

在传达任务的过程中，有时候传达者只是简单讲了他要你做的事情，比如故事中的老和尚说：“你们去山下帮我买一艘小船，我这里有5两银子，5天后我要用船。”这里讲到的限制因素：买一艘小船，5两银子，5天后。但你要问得更多、更具体：小船的定义是什么？没有共同的参照物就会发生大象说小，蚂蚁说大的情况，你可以问小船大概坐几人？与我们之前去××那个船一样大吗？或者更具体点，直接问尺寸。而且，需要了解清楚哪一个是最重要制约的因素，钱？时间？还是船本身？以及一些侧重因素，比如，最后有个小和尚说其实可以用信鸽的方式。但如果老和尚希望实地考察，那么可能性价比最高的方案就不是最优解了，所以在接到任务的过程中要注意这些限制因素，并在过程中细化和明确它们的性质和等级。那些不满足则不满意的因素，往往是最重要的，我们要特别关注。同样，那些满足则很满意的加分因素，我们也要稍加留意。

过程中注意同步沟通

你也希望你交代给别人的事情，别人总是能稳妥地办好、办顺畅，并且合你心意。那么你自己该怎么做也就很明了了。需要提示的是：把事情做好，一方面要在理解了正确的意图后选择了好的方式完成任务，另一方面你要把你认为好的方式做法，获得对方的认同、认可，避免那种你做完之后他告诉你，他不同意你的做法的情况出现。如果是时间持续较长的任务，一直无任何消息，换作你也会有一点不安，那么你就要选择合适的沟通方式进行同步，让你和他都放心。

任务完成后告诉他任务状态，同时记得挖掘点可能对以后有价值的内容

我们会熟悉这样的场景：“老大，你让我买的船我买好了，具体价格尺寸颜色等详细情况你可以看这个文档。”老大笑眯眯地对你说，“嗯，小伙子做得不错！走，喝酒去！”其实这是一个很好的机会，一个很好挖掘老大态度和满意度的机会，因为喝酒庆祝的时候氛围比较轻松，平时不好说的话在这时也会比较容易出口一些，那就顺便再带一些老大的反馈和期望回去，或许还可以挖掘出更加适合你们之间的合作模式和工作方式，这样，下次做事时或许就会做得更得心应手和出色，也让对方更满意！

其实任务发布者和执行者的目标是一样的，都希望顺利地完成任务，把事情做好。可是在任务信息传递过程中，往往会带有当事人的想法和主观色彩（或许他也不想这样的），所以在这个过程中，我们需要多思考，获取更多有用信息，在做事的过程中注意沟通和及早发现问题，最终实现双赢。让我们一起努力吧！

如何建立与团队的信任

文／何燕华

项目经理作为外来人员，与团队的关系可能没有那么浑然天成，尤其在刚进入团队的时候。但是与团队之间的信任关系在项目经理推进各项工作的过程中起着至关重要的作用。那么如何才能与团队建立起信任？本文将为大家娓娓道来。

提到项目经理，你会想到些什么？他们就是老板找来监督团队干活的人？他们只关心进度而不管团队成员的死活？他们千方百计地想着压榨“劳动人民”？我想持有这种想法的人不在少数，笔者也曾在自己的团队听到过类似“项目经理是监工”的声音。长此以往，不仅项目无法顺利推进，而且团队成员和项目经理的个人发展也受到很大的影响。那么项目经理怎样做才能扭转团队这样的认知？如何与团队之间建立长期健康的信任关系呢？

采取一切行动之前，作为项目经理，必须先想清楚自己的目标究竟是什么。难道真如团队所认为的，为了监督团队干活？为了压榨团队成员？为了赶进度？有的时候，不是团队把你划入不同的阵营，而是项目经理本身就没把自己与团队看作一个整体。其实，项目经理的目标只有一个，那就是保证项目的成功交付。从这一点来说，你的目标与团队是完全一致的。所以大家的一切工作都是朝着这个目标而开展的。

有了这个共同的出发点，接下来的一切才有意义。下面是一些笔者在这方面的一些建议。

不要为了检查进度而检查进度

案例场景

小A跟踪项目时，“尽职”地盯着任务的进度，一再询问相关的 开发人员，这个任务怎样了，那个任务完成没。结果团队对他应付了事，小A也不能完整了解该任务的状态。弱矩阵的项目里面，项目经理不对成员进行考核，成员对他的问询也觉得无关痛痒。

而小B则不同，他会在项目开始时，郑重地宣布项目目标并且由团队确认这个目标，如果团队不认同这个目标，就对目标进行修正。在执行过程中不断以这个目标来检查工作。同样是检查一个任务的进度，小B会从这个任务是否阻碍我们的目标角度出发，让成员从源头上认识到自己这个任务的重要性，从而能自主地努力完成。结果，团队成员根据项目的目标，就能判断自己任务的重要性，分清楚轻重缓急，按照优先级来完成任务。有的时候一个开发人员进行的是这个目标之外的事情，其他开发人员也会来提醒他先去完成阻碍目标达成的工作。

解析： 每个人都不喜欢被别人监督着，开发人员更是如此。一个不写代码的人隔三差五就来问问问，简直要被烦死了。但是有了一个被认同的项目目标后，一方面，在你询问进度的时候，团队不会觉得是在监督他们工作，而是在帮助他们发现达成目标过程中的风险，另一方面，团队其他成员也会一起来检查任务的进度，因为这对目标的达成有重要影响。这样项目经理就达到了既省力又有效的目的。

帮助团队成员解决问题

案例场景

小A在跟进任务进度时，要是开发人员反馈说还未完成，小A的跟进就到此为止了。结果，很多开发人员都不愿意跟他主动反馈问题，小A主动问询的时候也是爱搭不理的，问一句答一句。

而小B在团队成员反馈还未完成后，会再问一句：是因为什么原因耽搁了？有没有需要我协助的地方？有一次，一个非常关键的环境部署任务，团队成员反馈说未完成，原因是运维人员没空部署。了解情况后，小B找到运维人员，跟他协商是否能调整任务的优先级，但 还是被告知没有调整空间。从小B的判断来看，这个部署工作比其他运维人员手头的工作优先级更高，于是小B找来运维和开发的领导，一起商量能不能调整优先级，优先完成这个部署任务。最终小B如愿，这个部署任务被当即执行了。经过这一件事，那位开发人员在后面的工作中，一有风险就愿意跟小B诉苦，小B也能在第一时间发现风险并积极协助解决。

解析： 项目经理在技术方面确实没有开发人员精通，没法给开发人员提出很有价值的意见和建议，所以很多开发人员觉得没有必要向项目经理说得太多，反正他也不懂。但是项目经理在资源调配、风险意识、干系人管理等方面还是有其天然的优势，可以在这些方面帮团队解决问题。这样渐渐地团队和项目经理就建立起了协作关系，也就渐渐地建立起信任。

与团队一起工作

案例场景

小A在工作中将自己的职责和团队的职责划分得很清楚，团队的事情绝不会揽过来做。特别是当有一些临时任务进来的时候，经常就指派给某个开发人员了，而不管这个开发人员忙不忙。对于自己的工作，如制订计划，会自己全权负责，要求团队执行就行了。结果计划常常被迫调整。

而小B，一方面必要时会参与到团队的工作中，如帮助用研人员开展用户调研，帮运营人员进行数据录入，帮团队搭建产品主页等；另一方面，他也会让团队参与到他自己的工作中，如请团队一起来制定风险列表、时间计划。结果在帮助团队干活的过程中，小B多了许多了解产品的机会，而自己的工作，通过团队的协助也开展得更加顺利。

解析： 曾经听到过一种说法是：团队成员间增进感情的方式并不是一起出去活动或者旅行，而是一起工作，一起工作是增进感情和建立信任的最好方式。小B帮助团队做事，让团队感觉他是在用心地帮助他们而不是冷眼旁观。让团 队帮他做事，使团队更有参与感，在执行计划和规避风险的时候更有主人翁意识和积极性。

多向团队学习

案例场景

小A专注于自己项目管理领域的学习，但是很少参与团队的需求与技术方案讨论，使得自己永远都是该领域的外行。结果在周会上，他除了问进度还是问进度，完全参与不到其他问题的讨论中。

而小B，遇到团队成员围成一群在讨论些什么的时候，就会“厚着脸皮”凑上去，看看是在讨论什么样的问题。有的时候从自己的角度提出一些建议和意见，有的时候作为外行人问一些问题，以加深对产品技术上的了解。很多时候，在这种场合他还能发现一些项目潜在的风险。

解析： 项目经理不仅对自己的领域要有深入的认识，而且对产品和技术领域也要有一定的了解。这样至少在任何场合你都能听懂开发人员们聊的是什么，有的时候还能搭上话。如果一直如小A那样，就很少能与团队聊起来。更不用说建立信任了。

共同工作不仅是建立信任的最佳方式，而且我们还可以对团队成员的生活加深了解和关注。作为建立团队信任的辅助方式，下面是一些小的建议：

（1）增进与团队成员在生活上的交流沟通，有的成员恋爱了，有的成员结婚了，有的成员有宝宝了。如果项目经理是过来人，可以跟他们聊聊你的一些经验，给出一些自己的建议。如果项目经理还未经历过这些，那么就可以向他们取取经，学习学习。

（2）关心团队所关心的问题。例如最近团队都在讨论锻炼身体的计划，那么你也可以分享一下自己在这方面的打算，或者之前有过的经验。

（3）参与团队的活动。如同团队一起吃饭，在饭桌上谈天说地，更深入地了解每个人，周末同团队出游等。

与团队之间建立信任关系是项目经理开展工作的基础，但是这个过程也是艰难而漫长的，以上这些只是我们的一些体会，期待大家来一起探索。

小鱼儿学沟通——性格色彩

文／雷蓓蓓

红、黄、蓝、绿每种性格颜色各有千秋，我们需要在洞悉背后的深层动机、充分了解对方的基础之上才能跨越性格上的鸿沟，进行有效的沟通。本文以新任项目经理小鱼儿为例，阐述了项目管理过程中不同性格色彩的人之间的沟通问题。

故事发生在某公司代号为“神雕”的项目组。

小鱼儿：新项目经理

郭靖：小鱼儿的直线经理和师傅

老K：“神雕”项目的产品经理

萧峰：大部门总监，老K的直接上级

虽说在同类项目中已有两年多的工作经验，但这还是小鱼儿第一次真正做项目经理，心里难免忐忑。在这之前，他的经理郭靖特意与他一起梳理了整个项目的脉络，实际上这个项目对于新项目经理来说并不简单，特别是在人事上很有难度。在部门总监萧峰的积极倡导下，其下的所有项目都相继引入了规范的项目管理，可“神雕”项目对此却似乎颇有疑虑，进度缓慢……

小鱼儿按照经理的建议，私底下两次想找产品经理老K聊聊项目的事情，都被他委婉推掉了。虽说老K面子上礼貌周全，但小鱼儿却总能感受到一种拒人以千里之外的寒气。

初次交锋

这天，小鱼儿接到通知说“神雕”项目的新版本启动会开始了。他紧赶慢赶，还是迟到了几分钟，会议室的座位早已坐满，无奈只好隔壁拉了把椅子过来，回来时会议室已经被围得水泄不通了，空气闷得人发慌。

此时老K已经在讲了，小鱼儿挑了个角落的空地坐了下来，心不在焉地听着。这是小鱼儿第一次参加这个项目的集体会议，他想一定要找个机会发言，好给大家留个印象，借机在项目组推广一下自己备加推崇的敏捷实践。

正想到这儿，有开发人员打断了老K，针对他提出的一个方案的可行性，补充了一些自己的看法，小鱼儿觉得很有道理，正想开口附和一句，老K他漫不经心地“嗯”了一声，继续自顾自讲了下去，似乎在他眼里，这根本就不是个问题！小鱼儿注意到那个开发人员眼中一丝不满和失望掠过，随即又习以为常似的，眼神暗淡下来。

老K的演讲终于进入了尾声，接着部门总监萧峰简单讲了自己对项目规范化运作的期望，向大家介绍了小鱼儿之后就借故离开了。小鱼儿兴奋地接过话头，把刚从书上看来的Scrum一股脑儿地讲了起来，从Scrum是什么，到怎么运作，各个角色应怎么配合。

正讲到兴头上，老K却显得不耐烦起来，说：“Scrum我们之前用过，问题很多。项目赶得这么紧，你确定我们要这么干吗？我可不要所有人一起做什么试验。”小鱼儿显然没有想到老K这么直白地质疑，但由于缺乏经验，一下子憋得脸通红。

好不容易等到会议结束，小鱼儿上前拦住了老K，一脸真诚地表示想找他谈谈，老K见绕不过，只好跟小鱼儿来到了休息区。小鱼儿讲我们用Scrum及配套工具也是为了符合萧峰的规范化要求，其他项目已经都用起来了，并暗示萧峰一直对“神雕”项目里的很多做法不满意。老K一开始仍配合地听着，听到这句话脸上的表情极不自然地动了动，“这些我怎么从来没听他说过！”小鱼儿忙不迭地解释，不过心里也自知，这下又捅了个马蜂窝，双方不欢而散。

豁然开朗

经理郭靖路过时，小鱼儿正一脸愁容地摆弄着手中的笔，盯着面前的显示器发呆。“一起吃饭吧。”小鱼儿听到经理的声音，这才回过神来，“好啊，也正好有很多疑问要请教呢”。

饭桌上，小鱼儿急不可耐地讲完了整个经过，眼巴巴地问道：“我到底该怎么做呢？”经理耐心地听着，喝了口汤，并没有直接给出小鱼儿想要的答案，转而问道：“你觉得老K是个什么颜色的人？”

“嗯？”小鱼儿很意外，虽然组里一起学习过性格色彩，遇到事情自己倒还真没往这上面想过，他考虑了片刻，不确定地回答：“黄……黄色吧。”“嗯，对。”经理肯定地点点头，继续诱导说，“那黄色的人都有些什么特点呢？”“这个嘛”，小鱼儿努力地回想着，“黄色的人是成就驱动派，他们目标导向，喜欢主导，讨厌被强迫……”

讲到这里，他突然意识到了什么，不好意思地笑了笑说：“老K好像一直都对规范管理不怎么感冒，他肯定觉得我们拿萧峰的意志在强迫他了。”“呵呵，要想要黄色的人配合你的工作，一定得他自己认为这对他的目标真的有帮助。”

见小鱼儿若有所思的样子，经理继续问道，“老K现在最迫切的目标是什么？”“嗯，我想应该是以最快的速度保障项目顺利上线。我仔细看过项目方案，按照目前的人力状况，想要完成这个时间目标，风险和阻碍还有很多，需要开发、测试、配置等各方面提前考虑，完美配合，而这些目前看来似乎还没有被考虑到……”

小鱼儿的眼睛忽然亮了起来，说：“啊哈，这些都是我能够应用手头的知识和技能帮到他的，我知道该怎么做了！”看着小鱼儿脸上云开雾散的样子，经理忍不住笑了，说：“这是个建立信任的过程，急不得，多站在他的角度考虑问题，我相信你能做好的！”

经理低头吃了口面，“另外，萧峰那边，我抽空会去找他私下聊聊，看起来似乎这里还存在一些沟通问题。”“那太好了！”小鱼儿禁不住感叹，看来自己距离一个成熟的项目经理还有很长的路要走，不过一想到接下来的挑战，立马又热情高涨了。

至此，小鱼儿的故事告一段落。

亲爱的读者朋友，懵懂冒失的小鱼儿，循循善诱的经理郭靖，对规范管理推崇备至的部门总监萧峰，他们的性格是什么颜色呢？

性格色彩小课堂

其实，红、黄、蓝、绿每种颜色都各有千秋，以接纳的眼光来看，我们将看到性格上呈红色的自由快乐，蓝色的完美谨慎，黄色的果断坚定，绿色的和谐宽容；倘若用对抗的眼光凝视，你看到的却是红色的杂乱无章，蓝色的死板固执，黄色的霸道蛮横，绿色的软弱拖拉。可现实中，并非所有人都能跨越性格鸿沟做到彼此理解，那么我们在与各种性格的人沟通时，需要注意些什么呢？

首先，不要只盯着别人做了什么，而要关注背后的“为什么”。只有洞悉背后的深层动机，才能找准着力点。

你用眼睛看到的永远只是“对于一个提议，A不配合，B不冷不热，C和D吵起来了，E在旁边静静看着，不置可否”，可为什么他们会有截然不同的表现呢？这就是所谓的“动机”。笼统来说，红色追求快乐，绿色追求和谐，黄色追求成就，蓝色追求完美。具体到实例中，情况则会更加复杂，做出正确的判断需要的不是“眼睛”，而是用“心”去感知和体会，当时的情境气氛、对方的表情神态、身体动作都会成为你获悉动机的线索。

其次，好的沟通建立在充分了解对方的基础之上。选择用对方接受的方式，而非自己喜欢的、擅长的、习惯的方式来进行沟通。倘若面对的是严谨而又挑剔的蓝色，那么在沟通前的功课就尤为重要，翔实的资料、严密的逻辑、条理清晰的问答，这些都不是直接抛出一个简单的结论就可以了事的。可假如对方换成个红色的，恐怕他早就迫不及待地想问你到底想要说什么了。

最后，真正有效的沟通，必须基于人与人之间的信任。建立信任只能靠一点一滴的积累和磨合，毫无捷径可言。只有对方接纳和认可了你这个人，才能更好地接受你所说的话。

沟通的学问，多少有点“只可意会，不可言传”的味道，值得我们每个人在工作和生活中，不断学习和琢磨。

小鱼儿学沟通——引入变化

文／雷蓓蓓

项目管理过程中需要面对不同的困境，本文从新任项目经理小鱼儿的故事出发，阐述了如何在项目管理过程中引入变化，克服当前困境。充分利用好天时、地利、人和这三个要素，更好地达成变化。

新的困境

话说小鱼儿最近接了一个新的项目，代号“天龙”。“天龙”的负责人萧峰，小鱼儿之前还是打过几番交道的，人倒还好接触，但也谈不上深交。不过经历了上次的事，小鱼儿也学会谨慎了，决心先观察观察再说，毕竟这个项目在他来之前已经运行了一年多，有它自己的运行方式。他们每个月一次迭代，每周开一次集体大会同步各自进展，团队聚起来黑压压坐满一个大会议室，对着一张大表格各自讲讲最近的进展和问题。开会时气氛很是欢乐，大家都显得无拘无束，时不时还会有人插科打诨几句，相互开个玩笑。再看萧峰也一脸和善，随意得让人如沐春风，小鱼儿霎时觉得，这回才真是来对了地方。

可这样的日子没过多久，小鱼儿便开始觉得不对劲了。眼看着距离迭代发布的日期只剩两天了，表格上显示还有几项任务并没有做，周会上说这两天就应该弄好的，小鱼儿只好硬着头皮去问双儿。双儿眨着一双无辜的眼睛支支吾吾地说：“我的接口上周已经给小宝了，其他的我就不知道了。”于是，小鱼儿索性拉上双儿到小宝那儿，小宝听明两人的来意，说：“我前几天调试了一下这个有问题，我不是都写在任务里了嘛，调用一个接口十来分钟，这性能也太差了吧。”双儿显然没有注意这个留言，怯怯地望着小鱼儿。小鱼儿心想现在 不是互相埋怨的时候，只得说：“那现在怎么处理？还有两天迭代结束，我们还赶得上吗？”事情发展到后来，萧峰也加入进来了，最后大家敲定先用加缓存的方案来处理，可这么下来再加上测试，两天肯定搞不定，这个迭代做完恐怕是无望了。可奇怪的是，包括萧峰在内，大家都没有提赶不上怎么办，似乎这根本就不是个问题。

这件事以后，为了确保迭代万无一失，小鱼儿只好更加仔细地一个一个去问、去提醒。每次回想起别人的眼神，总感觉自己脑门上写着两个大字——监工，这让小鱼儿很是苦恼，他并不喜欢这种感受，似乎整个迭代的目标都只压在他一个人的肩头，这让他越来越疲于应对，也隐约觉得团队似乎存在着一些问题。可是，这个困境到底又该怎么解脱呢？

统一战线

一个念头瞬间击中了他，“对了，每日站会！”小鱼儿一个鲤鱼打挺从床上蹦了下来，连忙打开电脑，却再一次陷入了沉思，以现在的形势来看，向团队提出要每天开会？小鱼儿在想象着每个人的反应，“开玩笑？不是好好的嘛，为什么？”是啊，为什么，现在缺的就是这个为什么，总不能对大家说为了方便跟进问题吧，那样大家会买账才怪！带着这个想法，小鱼儿这回也着实沉得住气，心想这次我得讲究“策略”。

每周一次的周会时间，萧峰和小鱼儿的问题总是特别多，似乎只有这一个机会可以光明正大地去问每个人的进展，于是十几号人一轮下来，不知不觉两小时过去了。预订的会议室到期了，眼看着被撵出了会议室，可是大家的状态还没有同步完，只得作罢。

会后，小鱼儿叫住了萧峰，经过两周的近距离接触，他对萧峰的行事做派也算有了进一步的了解。小鱼儿开门见山，直接跟他谈起了对目前状况的担忧：“现在我们每周开一次大会，总感觉信息滞后得很，如X接口，我们早发现问题，也不至于现在又大费周章，这个迭代又有一堆任务要推迟了。”萧峰往前坐了坐，不由得点头表示认同。实际上他也意识到了这个问题，只是在会上当着那么多人的面，一直没好说什么。

小鱼儿猜到几分萧峰的心思，进一步说道：“只是开发的问题那倒还好办，一旦涉及其他角色、其他模块的支持，事儿就难办了。我们喊了很久要加强测试、加强运维，可也只是喊喊，喊完之后就没了下文。现在我们产品基本功能已经成型，质量和运维才是重中之重啊。”“是啊。”小鱼儿的话一下子戳中了萧峰的痛点，顿了片刻，他接着说道“可你也都看到了，实在是有些鞭长莫及呀。”只见他眉头紧锁，话语间很是无奈。

小鱼儿心想就等你这句话呢，于是把之前构想的各角色一起开每日站会的想法一股脑儿倒了出来，双方顿时一拍即合，萧峰觉得这的确是个好办法。考虑到人数众多，他们又一起商议了许久觉得还是有必要分两组来开站会。最后离开时，萧峰又叫住小鱼儿说：“我们一开始要不还是两天一次，两个组错开进行吧。”小鱼儿知道萧峰在顾虑什么，连忙回说：“刚开始慎重些也是需要的。”

与萧峰统一思想之后，小鱼儿信心大增。于是，他立刻找来了几个测试人员，想聊聊测试这边怎么分组好。几个人坐定后，当着萧峰的面，小鱼儿几句话便讲明了来意：“现在大家都坐得很近，但是团队中的沟通似乎并不是那么有效，我跟萧峰商量着，考虑引入站会。”一句话还没说完，测试员巴泰插了进来：“我觉得现在的沟通挺顺畅的啊，有什么问题。”小鱼儿显然没想到巴泰横插这么一脚，一时卡了壳不知道说什么好了。

萧峰见状忙帮着打圆场：“有事就喊两嗓子，沟通起来快是快，可更多时候一件事情喊过往往就没下文了。”小鱼儿感激地望了一眼萧峰，转了个弯接着说：“是啊，就比方说，开发改个Bug没改好，测试还等着去测，结果问了一次说在修，结果几天过去没见动静了，说不定开发已经转做其他的了。这个情况我想测试肯定碰到过，但我猜巴泰你也不好意思一次一次去问吧。”其他两个测试点头应和，也说确实有这个麻烦，再看巴泰脸色也缓和了下来，小鱼儿继续说：“可我们如果每天开站会，花15分钟时间互相同步一下进展，问题不就解决了？测试不需要去催开发，每天站会时他们自己会讲进展。如果测试需要开发提前做某件事情，以便安排足够的测试时间，那也容易多了。”看着巴泰的反应，小鱼儿知道测试总算搞定了，于是长吐了口气，心里嘀咕“还好我脑子转得快。”

因势利导

这天又到了一周一次的全体大会时间，小鱼儿早早跟萧峰打过招呼，说在周会上请他讲一下站会的事儿。小鱼儿按照往常同步完状态，时间已经过去了近两小时，屋里闷热得很，气氛早已有些焦躁，有人凑在一块窃窃私语，有人低头玩手机，有人双手托腮百无聊赖地坐等结束。小鱼儿顿生感叹：“现在我们每次周会时间好长噢！大家已经在加快速度讲了，这么多人一轮下来两小时就没了。”大家早已经开得有些生厌，经小鱼儿这么一挑，乱哄哄地纷纷吐起了槽，说有这时间多写两行代码也是好的，更有人还自告奋勇得直接给起了建议。

小鱼儿给萧峰递了个眼色，示意他来说两句。于是，萧峰开了腔，将早就讨论好的分组开站会的想法讲给了团队，小鱼儿补充道：“我们现在15个人，开一次周会要花费所有人2小时×15=30小时，可如果按照刚才萧峰的提议，每个人每周开两次站会，也就花30分钟，我们能给每个人节省1.5小时时间！”大家显然心有所动，有人笑着问道：“那以后周会是不是也不要开了？”萧峰看了眼小鱼儿，说：“这个嘛，如果一周没有特别需要集体讨论的事项，我看就不开了吧！”小鱼儿点头同意，说：“以后每周五前，我会收集一下大家的议题，如有整体目标、用户反馈、Bug分析等涉及所有人的事情可以开，没有的话就默认不开啦！”

看大家一脸高兴劲，小鱼儿知道已经大功告成，顿时心里颇为得意，顺口说道：“我看你们周围墙上那么多白板，我们开站会时也可以用起来了，一边说一边看”。大家显然还没这需求，大多一脸疑惑，有人问道：“写些什么呢？JIRA上都有，更新JIRA就好了。”小鱼儿见状，本来准备的种种好处，话到嘴边只得生生给咽了回去，心里也知道自己又心急了。

如何更好地引入变化

从小鱼儿的经历出发，在引入变化的过程中，有哪些要素能够帮助我们更好地达成呢？

简单来说，你需要“天时、地利、人和”。

首先，要选择合适的时机。孔老夫子有句话：“学而时习之，不亦说乎。”我最为认同的一种解释的版本是讲，学习并在合适的时机投入实践，那才是真正的乐趣所在。纵然你学有十八般武艺压身，要想投入实践去引入变化，时机才最重要。早了，大家还没意识到问题；晚了，他们又找到了可以将就的办法，逐渐形成了惯性，并视为理所当然。时机或早或晚，都会让引入变化的阻力成倍地被放大。什么时候才合适，需要你在观察中耐心等待与发现。

其次，要因地制宜。要结合团队的实际情况，为团队定制方法。“天龙”项目中，小鱼儿并没有照搬理论或所谓的“最佳实践”，而是与萧峰讨论后决定分组开站会，每两天轮一次。实践中顺应每个团队的特点，用最适应的方式来做，才能获得好的效果。

最后，要因人而异。对不同人要切合不同的痛点去沟通，对方才会买账。在大范围公布并引入变化之前，要确保与关键角色都进行过小范围甚至一对一的沟通，最后的效果往往会更好。当然，这一切必须建立在信任的基础上。这个信任不仅是对项目经理个人能力的信任，更重要的是，你是否能够站在对方角度设身处地地思考，让团队相信你是在真心为他们着想，你是在真正为他们解决问题，这样团队才会愿意打开大门，接受你所带来的变化。

后记

话说，“天龙”项目组的站会风风火火地开了有个把月了，大家感觉还不错，只是每次会上说完的事，下次来的时候通常就想不起来了。这事发生过几次之后，小鱼儿拉来了一块白板放在会议室里，对大家说以后我们把需要跟进的事儿写在这上面不就好啦。看着萧峰在白板上认真地写跟进事项，擦了写，写了擦，小鱼儿知道又有新一轮的变化在酝酿了！

小鱼儿学沟通——透过现象看本质

文／雷蓓蓓

很多情况下，我们在沟通时，面对的往往是乱象丛生的各种复杂现象。只有通过敏锐观察、冷静地思考、审慎地行动、小心地试探，才能透过纷繁复杂的表象直达问题本质，看见解决问题的线索。

小鱼儿：成长中的项目经理

袁承志：“碧血”项目负责人

欧阳：项目总监，“碧血”和“倚天”等项目的总负责人

小鱼儿已经受住了各种考验，沟通功力与日俱增。可这一次，在“碧血”项目组，情况似乎并不那么乐观。

新的使命

在项目总监欧阳的直接授意下，其下所辖的“碧血”项目要为另一个“倚天”项目提供日志检索与查询的系统解决方案。这件事情欧阳非常看重，希望小鱼儿能够整合项目组的力量尽快执行。

小鱼儿很是卖力，与“碧血”项目的负责人袁承志一起讨论之后，袁承志很快给予了响应，两周时间，他们根据欧阳提供的简单需求做了个demo出来。

这天到了demo演示会现场，在袁承志结束他的演示之后，欧阳极为认真地提了一大堆意见，还需要加什么功能，应该放在哪儿，怎么呈现，如此种种。但令小鱼儿感到不解的是，作为直接用户的“倚天”项目的各个使用方，叫了几次才中途过来一趟，而且看上去他们似乎并没有什么想法，从头到尾基本上没有说什么话，一副你们随意，怎么都行的样子。

小鱼儿虽心中生疑，却并没有多想。会议很快结束，根据欧阳的意见有不 少内容都需要重新调整。小鱼儿与团队商议后，特意排开了仍在进行中的其他任务，大家加快进度，不到一个月，各项工作便完工了。

阻力重重

此时的小鱼儿松了口气，但令他万万没想到的是，直到这时，各种各样的麻烦才刚刚开始。因为最终系统要部署在对方的服务器上，各项配置、初始化等工作需要“倚天”项目组的配合，在袁承志找到对方的各个直接使用方沟通后续事项时，总是被对方以各种各样的理由拒绝，要不是说现在忙没时间搞这些，就是稍微尝试两步就有各种抱怨，有的说这东西太慢，点半天反应不过来；有的说这东西太难用，找了半天都找不到自己想要的日志。

三番五次下来，袁承志心中甚是窝火，“明明是他们日志量太大了，每天几十G，这么个数量级要查起来能不慢吗？”小鱼儿心中也觉得很纳闷，但还是安慰袁承志说，“与其在这里纠结，倒不如去找欧阳沟通一下，他应该可以出面要求他们再精简精简。”小鱼儿看袁承志点了点头，继续说道：“不过这难用的问题，我觉得这样，我去联系几个意见比较大的用户，找时间一起碰个头，大家把具体问题汇总一下，现在的反馈太笼统。你觉得呢？”袁承志虽然心中仍有怨气，但也表示赞同，之后两人便分头行动。

愈演愈烈

反馈沟通会上，小鱼儿叫来了平时意见最大的几个用户。在袁承志简短的产品演示过后，小鱼儿示意大家有使用中的问题，今天尽管提。一时间没有人开口。短时间的沉默之后，小鱼儿只好指了一个人请他发表一下意见。

第一个人开口之后，其他人断断续续补了几句，但始终感觉仍在表面打转。在那些“问题”背后，小鱼儿和袁承志越来越清楚地意识到一个事实，那就是几乎没有一个人真正好好使用过这个产品。这个结论让袁承志很是气恼，有种自己的辛苦努力被亵渎之感，本来还一直放低姿态找问题，此时的状况却令他再也无法继续淡定。他红着脸叫道：“早些时候让你们看demo，一个字不提，现在这个那个的不愿意用，早干什么去了？”话语间俨然已经完全失态。小鱼 儿虽极力挽回，但终究敌不过已然降到冰点的气氛，会议草草结束。

真相大白

这次反馈沟通会过后许久，小鱼儿始终被一种深深的无力感包围着。按说自己为了推进这个事情，也做了不少努力，花了不少心思，可不管怎么做，就是有各种阻力推不动。

究竟这是为什么呢？小鱼儿越想越觉得过不去，心中那股不服输的劲顿时上来了，心想不管怎样，我都一定得搞明白！

说干就干，要弄清楚这其中的真正原因，小鱼儿打算私下里找“倚天”项目的人沟通一下。沟通的内容小鱼儿也颇费了些心思，准备使用三个环环相扣的问题挖掘出其中的真相：①你认为现有系统有没有发挥作用？②如果没有，你认为是什么原因导致的？③在目前的基础上，做到哪些可能的改进，你会选择去用？

这三个问题的调研结果，让小鱼儿终于有些释然了。受访的六位同事，全都表示很少或从来没有使用过该系统，认为现有系统并没有发挥作用。其中的原因大家说了很多，核心思想就是说使用这套系统来查询日志，远不如直接登录到机器上查看日志来得方便、快速、好用。第三个问题的结论，更是让人大跌眼镜，有同事说得非常直白：“如果要让我选择，估计要做到比现在直接登录服务器查，还要更快、更方便，我才有可能用。这个难度非常高，基本不太可能做到，但如果做不到，估计真没有人会用。”

这些大实话，让小鱼儿开始回过头来，重新审视整个过程。那些小鱼儿一次次放过的各种怪现象，像电影一样在脑海中不断闪过：从demo演示会上用户的“无所谓”，到推进过程中的各种“没时间”和“不配合”，再到反馈会前后的各种“抱怨”，其实都在提示着这中间出了问题：用户并没有迫切的需求和足够的动力来使用这个系统。这让这整个过程变得更像“推”动而不是由需求“拉”动。在这种情境下，用户在心中总是会不自觉地拿现有的解决方案作对比，于是产生各种抱怨便也不足为奇了。

直到这时，小鱼儿才算真正找到了隐藏在种种表象背后问题的本质。这份 调研报告让欧阳以及袁承志陷入了深深的思考，他们迅速做出了调整。

至此，小鱼儿的使命也告一段落。

抓住本质

很多情况下，我们在沟通时，面对的往往是乱象丛生的各种复杂现象。想象你正在拉开一堆缠绕的线头，并不是越卖力，就越能扯得开一堆乱麻。在错误的方向上，越是卖力地推进，只会让你离目标越来越远。只有透过纷繁复杂的表象，准确直达问题本质，才能做到事半功倍。透过现象看本质，你需要：

（1）敏锐地观察。注意线头交错之间那些隐秘的“蛛丝马迹”——各种与常规情理不符的“怪”现象，这才是你解开问题的关键。千万不要轻易放过！

（2）冷静地思考。注意不要被繁枝末节所惑，而要着眼于问题的“根本”，也就是那些错综复杂的现象背后真正的“关节”所在。

（3）审慎地行动。小心地试探，拨开那些无关的线头，得到最本质的真相。

透过纷繁复杂的表象直达问题本质，并以此为根据去指导行动，只有这样才能够更有效地解决问题。但是，要想做到这一点并非易事。

在我们被云雾遮蔽双眼时，我们需要的是回归原点。越是错综复杂的问题，就越要回到原点，根据单纯的原理进行判断。如果我们把整个事件倒退，回到那个最初需求的起源点，就不难发现整件事情在一开始就埋下的各种隐患。

只要回归原点去考虑，就能看见解决问题的线索。我想也许这就是拨开云雾见南山、洞悉事物本质并解决问题的最佳方法吧。

小鱼儿学沟通——向上管理

文／雷蓓蓓

向上管理是职场中的一堂必修课，有效地、正确地向上管理，不仅需要勇气，更需要智慧。本文以成长中的项目经理小鱼儿的故事为例，讲述了如何在 项目管理中更好地进行向上管理。

一转眼，小鱼儿在“碧血”项目已待了有大半年的时间了，与袁承志两人配合得还算默契，越来越多的事情开始交给小鱼儿来把控。不过，相处久了，小鱼儿倒是发现袁承志有个癖好，就是出了问题或遇到风险总喜欢藏着掖着。

小鱼儿：成长中的项目经理一枚

袁承志：“碧血”项目的负责人

欧阳：大部门总监，“碧血”和“倚天”等项目的总负责人

郭靖：小鱼儿的直线经理和师傅

各种纠结

这不，距离这个大版本的发布只有一周时间了，团队逐渐进入了焦灼状态。测试过程中不断发现新的Bug，尽管团队已经在尽全力修复了，可是按照现在的进度，很多潜在影响很高的Bug可能无法在上线前完成修复，按照原计划上线的话风险会非常高。站会上，小鱼儿让团队各自给出发布信心指数的评分，总体来看大家对这次发布非常不乐观，信心持续走低。小鱼儿与袁承志沟通了具体情况，提醒他最好向欧阳提前报备一下，可能的话我们也好尽早修改发布计划。袁承志听到这却并没有应声，转而找旁边的开发人员讨论起某个问题来了，小鱼儿虽然心里急得很，也只好作罢。

实际上，小鱼儿的担忧并非空穴来风。“碧血”项目是为公司战略项目提供底层支持的，大部门总监欧阳对于“碧血”项目的关注度非常高，在多个场合曾表示过“碧血”是今年整个大部门第一优先级的项目，其中产品的稳定性更是重中之重。最近几次线上出问题，整个团队没少挨骂。小鱼儿心里明白当前这个信息应该是欧阳所关心的，要不要及时通知欧阳这个风险呢？

虽然平时开会也和欧阳多次打过照面，但一想到他那严厉的神情，小鱼儿心里不禁打起了退堂鼓。于是在欧阳的办公室门前绕了两圈以后，小鱼儿突然想到：“要是袁承志知道了，会不会觉得我是在打小报告，多此一举呢？怎么办？怎么办？”在经历了一番内心的纠结之后，小鱼儿转念一想：“也许并没 有像大家想的那样，上线应该还是会顺利的吧……”想到这里，各种顾虑战胜了对于风险的担忧，小鱼儿最终还是什么都没说。

遭遇质疑

“碧血”项目的新版本，虽说顶着重重压力，最终还是如期上线了。小鱼儿却并没有因此而轻松起来，这样仓促上线背后的代价，是在很多事情上都打了折扣，且不说遗留Bug的潜在风险，由于时间紧张，线上的监控报警都没做到位，一旦出现问题，不能及时发现，也没有充分考虑过应急预案。

正当他们开始着手事后弥补之际，线上还是出事了，他们所依赖的外部第三方服务出错，导致相当比例的线上用户请求失败。由于没有相应的监控，在错误发生后的一个半小时，大晚上接到用户方QA的紧急电话，大家才知道出了事。

第二天，欧阳的邮件劈头盖脸就来了，“之前一再强调监控，甚至在会上还特意问过，已经预见到问题却没有做应对，我认为这是非常严重的人为事故！”在接下来的事故总结会后，欧阳更是毫不客气地把袁承志和小鱼儿大骂了一通。

找到症结

经理郭靖找过来的时候，小鱼儿的内心正经历着一场斗争，无比沮丧和憋屈的同时也有非常多的困惑。郭靖显然注意到了小鱼儿的情绪，在耐心地听小鱼儿讲完事情的来龙去脉之后，他很快找到了其中的要害，试探地问道：“在跟欧阳的沟通上，是不是有什么困难？”小鱼儿愣了一下，这个问题似乎被自己刻意回避了：“嗯……常规的沟通倒是没什么问题。不过，在我看来，他是袁承志的上级，如果找他去讲一些问题，总感觉像越级汇报似的。”

郭靖想了想，并没有直接回应，而是继续问道：“你还记得项目干系人矩阵吗？”见小鱼儿点头，他便继续道：“干系人矩阵中，你觉得欧阳应该在哪一类？”小鱼儿想了想回答说：“应该是权力高且利益相关度也高的那一类吧。”“没错，这类干系人属于应该重点管理的类型，那你觉得目前对他的管理足够 吗？”见小鱼儿低头没有再说话，郭靖补充道：“其实作为项目经理，本身就是为了把处于不同职能部门、各个不同层次的利益相关方的力量和资源整合在一起，共同去完成项目目标而存在的。这中间关键的一步，就是要管理好各方干系人的期望。欧阳对这个项目最大的期望和关注点是什么？”小鱼儿不假思索地回答：“稳定！线上不要频繁出问题。”看小鱼儿一副很确定的样子，郭靖笑了：“没错，看来你很清楚嘛。那下次遇到这样会影响稳定的风险，知道该怎么做了吗？”

“嗯，我想这个信息他肯定会关注的，可是……”小鱼儿小声说道：“我还是感觉，绕过袁承志直接去找欧阳反映问题似乎不太好。”郭靖答道：“我们先明确了此类问题必须让欧阳知晓并有所反应，而后的处理方式还是可以多样的嘛，如果可能的话你可以说服袁承志一起去找欧阳，或者以邮件形式发一封项目风险警告，客观描述现在的风险并标注紧急和重要程度，提醒欧阳特别关注，等等。这里的关键是你必须想办法让这些关键信息及时有效地流动到关心它们的人那里去，帮助他们更好地做出决策，而不是在你这里止步。”小鱼儿若有所思地点头，心里已然有了方向。

主动出击

话说“碧血”项目，作为公司战略级产品的底层支持平台，容不得一点闪失，连续加班那是常有的事，半夜两点爬起来升级也是家常便饭。可就是在这样的高强度压力环境下，由于线上问题不断，团队经常受到各种质疑，从上到下都背负着沉重的精神压力。这种恶劣的生存环境，竟然让大家结成了“难兄难弟”般的牢固友谊，团队内部非常团结，私底下大家经常一起聚会，当然，少不了也一起“吐槽”。

这个周末又一次通宵加班上线，大家一直忙到凌晨4点多钟，结果更新后出现了个突发情况，为了不影响到用户使用，按照流程果断回退了，第二天定位解决问题后又重新来过。就这样在连续两个通宵加班之后，项目终于得以成功上线，而此时的大家都有点控制不住了。在无限苦逼的境况中，似乎吐槽成了最有效的排解压力的方式，“出了问题挨骂，没出问题是应该的”，小群里大 家有一句没一句地相互调侃着。

以往看到这样的情况，小鱼儿也特别觉得同病相怜，自己不是也一样，拼死拼活却得不到认可，可除了私下吐吐苦水又能做什么呢？小鱼儿突然想到了欧阳，他应该知道团队中这样的声音，因为长期下去必然会严重影响士气，从而进入恶性循环，线上质量更加难以保障，这一定不是欧阳想要看到的！而只有他才是解决这个困境的最合适的人！

于是，在一次会议散会之后，小鱼儿上前叫住了欧阳。几句话说明来意之后，小鱼儿把事先准备的参考数据摆在欧阳面前，说道：“有人曾经做过统计，连续加班三周，人的各种状态，包括身体、心理、情绪都会下降至最低，这样的情况不加以提振的话，恐怕只会更加容易犯错。而这个项目容不得半点闪失。现在这样的连续加班和通宵的情况，已经持续不止三周了，这次的上线，虽然中间经历了挫折，但大家仍然遵照流程执行并最终获得了成功。所以我们是不是应该简单庆祝一下，帮大家从心理上减减压，有一个新的开始？”听小鱼儿一口气说完了事先准备好的“台词”，欧阳先是略有些吃惊，但很快认可了这样的判断，“确实，我们得想办法鼓励一下大家，而且一定要及时！”欧阳肯定的回答让小鱼儿受到了莫大的鼓舞，“嗯！我看现在就是一个很好的时机。我们正打算下午开总结会。我去准备些零食饮料，可以的话请您到场，对大家讲两句话吧！”

如愿以偿

总结会上，欧阳显然事先准备过，从这个项目对于大部门的重要性，到非常感谢大家一直以来的辛苦付出，再到绩效及奖励措施上的承诺。看得出他还并不习惯于在公开场合说这么多鼓励的话，尽管气氛稍有些诡异，但看着团队成员们脸上难以置信又受宠若惊的神情，小鱼儿心中一阵欢喜，那些憋屈和苦逼，在这一刻，似乎全都一扫而光。

“我相信这次的成功只是一个开始，希望‘碧血’项目以此为始，步入一个正向循环，越做越好！”欧阳的这些话，小鱼儿一直到现在依然清楚记得。虽然不晓得欧阳在彼时彼刻是否真的相信，但在接下来的时光中，这些话的的 确确变成了现实。

如何更好地向上管理

1．向上沟通，胆量为先

由于层级相差较远，无形中会带来心理压力，这很正常，但往往会成为阻碍项目经理向上沟通的最大障碍。作为项目经理，这些高层级的干系人往往对项目成败进退起到决定性的作用，如果对这些干系人的期望不加以识别并有效管理，往往会成为项目遭遇困难的诱因所在。跨出自己的心理舒适区，主动沟通是第一步。

2．明确核心关注点，做好充分准备

我们知道，越往上层走，接收到的信息种类和数量越会呈指数级上升，他们的时间和精力也会越分散，这种信息的不对等使得我们很难去获知全貌，但至少对于你的项目，干系人更在意什么，是需要非常明确地获知的。

注意观察上层领导平时都在哪些事情上面出现或发出声音，会因为什么问题回邮件，开会的时候哪些问题说得最多，等等。在一个个看似离散、不相干的问题背后，你有没有真正思考过，到底什么才是领导的核心关注点。只有抓住了真正的核心关注点，并理解其背后的真正意图，才能在后续的沟通中，更加有针对性地有效管理期望。

高层干系人往往时间宝贵，在沟通之前，做好充分的准备，是必不可少的。首先，对事情的轻重缓急，要有良好的判断。将要反映的问题，是否与其核心关注点相匹配，这是能否引起其关注并进一步行动的关键所在。其次，不只说问题，要有数据或事实支撑，便于干系人做出决策。最后，不只反映问题，要列举可能的解决方案，并给出你的建议和依据。

3．做好沟通纽带，巧借力

高层干系人通过层层汇报得到的一线团队的信息其实相当有限，但这并不意味着，他们不关心这些信息。好的项目经理可以成为高层干系人与团队之间紧密联系的纽带。从高层干系人的核心关注点出发，将团队最一手的相关动态信息及时传递给他，拉近他与团队的距离。

这样，在团队遇到困难需要高层支持的时候，让其了解到这件事的重要性并向其借力，你就会得到积极的响应和帮助。而来自高层干系人的鼓励及资源的支持，都将使得团队取得更加正面积极的进展。

4．注意沟通方式和频率

千人千面，沟通的方式和频率也需要因人而异。方式上，有些喜欢你用邮件介绍工作进展，有些则喜欢简短的口头汇报。时间上，有些喜欢事无巨细参与，有些则不喜欢总是被打扰。重要的是，选择一个对方合适的时间和频率，并与当事人沟通确认这种方式。弄清楚个人偏好，然后对症下药，才是王道。另外，平时多找些机会闲聊，多一起吃饭等，都是增进感情、增强互信不错的方法。

当然，所有这些规划中的沟通方式，都需要为真正紧急且重要的事情留出绿色通道。当这样的事情发生时，直接打电话或走过去敲门，确保第一时间沟通，才是最合适的做法。

5．过程永远不是目的

在向高层干系人提问题的同时，要给他一个明确的理由，为什么要他关注这个问题。这就需要跳出项目经理的视角，站在对方的角度去思考问题。

“团队有人就是不做估算”“任务总是不及时更新”“某人老是迟到”等，如果只是这样反映过程中的情况，说这里不好那里不好，而没有和干系人关注的目标联系起来，没有告诉他为什么要关注这些问题的话，意见本身并不见得会得到重视。

没有结果的过程是无效的，没有过程的结果是垃圾。相对而言，业务方的高层更在意的是结果，而项目经理更关注“怎么做更好”。关注过程的项目经理，更像在扮演“政委”的角色，要明白自己与业务方在关注点上的差异。平衡好这些差异能够互相补益，平衡不好只想着过程，则容易造成分歧。如果方向不能统一，长期下去，双方势必会越走越远，从而最终损害项目的利益。

反之，作为业务方，在关注结果的同时，也要意识到过程的重要性。因为从长远可持续发展角度来看，没有一个良好的过程，任何一次成功都不具备可复制性，即使今天赢了，明天也是要输的！

6．不要一味跟随，要有自己的见解

项目经理可能在经验阅历等方面，与业务方的高层领导会有差距，但即使这样，不要一味跟随他，要努力成为他的“镜子”。高层领导也是人，是人就有弱点，也会犯错误，再加上信息不对等，可能会做出错误的决策。面对这种情况，优秀的项目经理并不会一味跟随，但是怎么处理就需要智慧了，一方面要敢于大胆说出来，同时又要讲究方法，用对方受用的方式来讲。

其实，不光是项目经理，向上管理更是职场中的一堂必修课，需要勇气，更需要智慧！

小鱼儿学沟通——走出困境

文／雷蓓蓓

当我们面对困境的时候，是选择向别人抱怨、郁郁寡欢，还是选择自我反思、冲出内心的牢笼？其实，困境永远源自内心，只有改变了自己，才能去改变周围的环境。

经历了几番历练的小鱼儿，到了一个完全陌生的环境——公司里大名鼎鼎的“笑傲江湖”（简称“笑傲”）项目组。这不，刚进来没几天，小鱼儿便开始觉得不太对劲，到底是什么情况呢？

小鱼儿：成长中的项目经理

郭靖：小鱼儿的直线经理和师傅

任我行：“笑傲”项目的核心开发人员

方证：任我行的直线经理，“笑傲”项目的开发负责人

风清扬：大部门总监，“笑傲江湖”项目组的总负责人

新的征程

部门老大风清扬，为人沉稳谦和，虽说之前有过几面之缘，但并无太多交集。在小鱼儿首次拜访中，风清扬只是简单说了几点期望和想法，“站会、白板、度量……”尽管指示非常明确，但小鱼儿听下来却始终如雾里看花，似乎隔着一层什么，本想继续深挖几个“为什么”，无奈相互了解甚少且时机未到，只得匆匆收关。

“笑傲”项目是风清扬选择的第一个试点，在风清扬那里没有解开心中的疑问，小鱼儿只好去找负责人方证。方证跟小鱼儿聊了很多，不过小鱼儿隐隐觉得方证的话，听来带着些许无奈。一番了解之后，发现原来这“笑傲”项目在这个项目组里，优先级是最低的，也正因为此，各种资源经常跟不上，项目周期经常被拖得特别长，等待已成为常态，久而久之大家也都习惯了。不知不觉聊了半个多小时，方证见小鱼儿仍旧摆出一副不依不饶要继续探究的劲头，兀自叹了口气，眼神越过小鱼儿，怔怔地看着远方，一字一句地吐出“坦白跟你讲，我觉得你也改变不了什么”。

在之后的日子里，这句话就像幽灵一样，不时地回荡在小鱼儿的脑袋里。“改变不了什么……改变不了什么……”，时而让他失落绝望，时而又让他斗志昂扬！小鱼儿就是在这样的情境下，踏上了全新的项目旅程。

艰难开局

这天是开发内部的周会，小鱼儿被叫过去旁听，一进门就被那扑面而来的“霸气”给震住了。这是他第一次看到会议上的任我行，只见他以极快的语速问着每个人的开发进度，并飞快地做出指示：“×××，这个你去跟进一下。”“×××，做的时候一定要注意性能，不要到最后得不偿失”！被点名的人低声应和着，一路没有多余的话。

会议很快结束了，全程下来似乎只有任我行一人在说，其他人都低着头，间或随意翻翻手机，每当他停下来的时候，气氛会显得异常安静。结尾的时候，任我行的目光停在小鱼儿身上，似乎在等待什么。于是小鱼儿连忙抓住机会，向大家做了自我介绍，并且简单说明了自己的来意及管理层对于试点的期望。 话还没说完，就听任我行开腔了：“站会我们之前在××项目开过的，没什么用！”虽然之前早已见惯了各种质疑，但如此直接且丝毫不容置疑的口吻，让刚刚开场的小鱼儿颇有点下不来台。

这次的经历过后，小鱼儿开始转向做“地下工作”。在筹备试点启动会前，几位核心人物都被他找遍了，找他们讨论试点需要做哪些改变，然后一一回应每个人心中的疑问和困惑。原来这“笑傲”项目，动辄三四个月的发布周期，在大家看来却稀松平常，因为优先级低，发布日期很少有人关注，一遇到什么情况就延期，之前并无人在意。

小鱼儿知道，周期这么长，且中间没有任何验证，各种问题和风险无疑都会在后期被放大，站会、白板虽然可以加快信息流动，但很多根本问题却被掩盖掉，无法在过程中暴露出来并得到解决，风险只会随着时间日积月累，愈发不可控。可想要说服大家同意缩短周期，又谈何容易！各种阻力都来了，就拿方证的话来说，“你要清楚老大让你做的是什么……”虽然话没有继续说下去，小鱼儿却立刻明白了这言下之意，“这根本不是你该要关心的范畴嘛”。面对这些阻力，小鱼儿几乎使出了浑身解数，产品、设计、开发、测试一个接一个地游说，才勉强让大家同意了在下个版本的计划中加入一个中间提测的点。

“呼……”，全部办妥之后，小鱼儿长出一口气，想到经理郭靖跟自己开玩笑的话“你这是一朝打回解放前啊！”禁不住一丝苦笑。由于提前做了充足的准备工作，试点启动会上，小鱼儿没有遇到什么麻烦，一片风平浪静，站会、白板等得以顺利推行。可令小鱼儿不安的是，那气氛仍然安静地让人不大舒服，即使小鱼儿卖力地想和大家有些互动，仍然仿佛一潭死水，激不起半点波澜。

冲突爆发

随着项目往前推进，提测的日子总算到了，积累了两三个月的开发成果，一下子呈现在了大家面前，提测、走查，大伙儿各种忙碌。让小鱼儿没想到的是，一场冲突也正在酝酿，一触即发！

设计走查之后，一个长长的清单连夜出炉了，上面密密麻麻写满了各种问题。第二天，走查沟通会还没说上几句，任我行发飙了：“写就好好写嘛，不 要打那么多叹号好不好！知道这多影响程序员的情绪吗！害得我一晚上都没睡好觉！”设计MM顿感冤屈：“走查时发现这么多问题，我好受伤！我交互稿里分明都是有的……”

“这个当时说过的，你是不是没搞清楚这个机制啊！”“……那算我错乱了行不，谁也不可能保证一开始就是对的吧，开发有Bug，设计也会有后期发现不合理的地方。这个很正常吧！”“不正常……”

整个会议就在各方漫长的推推嚷嚷中艰难地进行着，小鱼儿在一旁看得心急如焚。“这样一来，我们不是又要延期了？！”“延期呗，还能怎么办？”方证的话无奈中又有些习以为常，众人沉默，脸上分明写着“不关我的事”！后来，“笑傲”足足推迟了一周才得以最后发布，但似乎并没有人关心这些。

走出困境

在试点项目陷入困境的同时，小鱼儿的内心也在经历着前所未有的波澜。小鱼儿时常觉得自己像那个骑着一匹瘦马、妄想挑战大风车的堂·吉诃德，而他拼命想要战胜的，却是飘在空中、落在人们心底的那些细细碎碎的声音：“我觉得你也改变不了什么”“延期呗，还能怎么办？”……那些声音背后深深的无力和绝望，连同那些异样安静的氛围，像是从四周细小的缝隙里涌过来的冰冷潮水，一点点淹没了他，小鱼儿开始越发喘不过气来。

虽然几番尝试去澄清、确认，但那些漠然的神情和话语，始终刺痛着他。“或许他们根本就不想要改变！”小鱼儿失落极了，已感受不到一丝一毫被需要，举目四周是那样的孤立无援。就这样在坐了两三个月的冷板凳之后，小鱼儿觉得自己正在接近那个极限，而周围似乎一切仍然照旧，于是，他，崩溃了！

在那些低落的日子里，郭靖给了小鱼儿很多安慰和鼓励，向郭靖的诉说让他的情绪得以宣泄，但那些让他困扰的缘由，仍然像乌云一般笼罩着，迟迟无法散去。

有一天夜里，小鱼儿被吵醒之后就再也睡不着了，他打开朋友圈，注意到一篇文章，文章讲的是“胡萝卜、鸡蛋和咖啡豆”的故事。曾经有一个女儿遇到了人生中的挫折，他的爸爸给她看胡萝卜、鸡蛋、咖啡豆遇到沸水后的变化： 胡萝卜本来是硬的，变软了；鸡蛋里面本来是软的，变硬了；而咖啡豆呢？它溶于水，然后彻底改变了水质！

那一瞬间，小鱼儿“噌”地一声，从床上蹦了起来，心中只有一个强烈的念头：“我要做咖啡豆！我要做咖啡豆！”那一瞬间，小鱼儿清晰地认识到，自己已经在被这个环境所改变，这个充满压抑和无力的环境，正在让自己也变得无比沮丧，似乎做什么都无法使它改变分毫。可当真就这样任由环境改变自己吗？他打开灯，开始奋笔疾书，小心翼翼地记录下此刻的想法和心情，像怕它们会溜走似的，一番折腾之后，才满意地睡去了。

重新振作

那天之后，虽然外面的世界仍然一切照旧，可小鱼儿却坚定地相信“一切都会好起来的！”小鱼儿暗自打定主意，不管遇到什么样的回应，要始终保持自己的正能量！哪怕没有一个人在意这些，哪怕面对“老大有问过你进度吗？没有吧。”这样怀疑的声音，小鱼儿依然坦然从容，带着那份简单的自信，尽自己最大的努力，去准备好自己可以做的一切，每次站会、每项跟进、白板上的每个便笺、燃尽图上的每个点……就这样陀螺一般忙碌着。

世界果真就是这么奇妙，当小鱼儿的心境变化之后，每一点一滴的努力，真的如他想象的那样，在一点一滴地改变着周围的环境，然后聚沙成塔，汇流成河！

在版本结束后精心设计的回顾会上，一个换位思考的游戏让大家抛开了日常惯有的角色思维定式，并由此开始深入讨论研发过程中的角色间协作模式，效果显然超出了小鱼儿的预期。体验了一回策划的研发人员，突然发觉自己也会有那么多的“想当然、自以为”；尝试做了一回研发的策划和设计人员，则体会到了拿到需求时的那种“茫然、困惑”。通过一个简单的游戏，大家设身处地地理解了对方，明白出现理解的偏差是正常的，而要做的，就是如何更好地协作来改善这种情况。

正是这个讨论，让团队终于自己得出了那个让小鱼儿一直心心念念想要的结论，不是对上游变本加厉地提出要求，不是拒绝变更或筑起高墙，不是出现问题后互相之间指责和惩罚！而是应该缩短发布周期，更快地迭代—验证—反 馈，过程中增强中间版本的实时沟通和反复调整，从而避免版本后期的各种不可控……

回顾会上的热烈讨论，那一双双眼睛里闪耀和流转着的光芒，直到现在小鱼儿回想起来都备感欣慰，因为他知道，自己终于做到了！

如何走出困境

困境永远源于内心！

正如《楚门的世界》中“上帝”一般的制片人克里斯托弗，在面对公众对他的质疑时极为平静地断言：“如果他下定决心要出去，没有人可以拦得住他！”真正的牢笼始终都只在每个人的内心！这也是为什么，当人们看到楚门克服心中的种种恐惧，挣脱了那个伴随了他一生的谎言时，会如此欢喜雀跃，就仿佛从困境中挣脱的是他们自己！

相比外界你所面临的种种困境，更为可怕的是内心的绝望和恐惧。当你把眼光放在环境的各种局限和不如意上，你会不断受挫，在困境中来回打转。而当你把眼光放在自己身上时，才会真正明白，走出困境的钥匙，从来都在自己手中。

改变自己，真的能够改变世界！也只有改变自己，才可能改变世界！

当你下定决心要走出困境的时候，没有任何人能够拦得住你。

作者介绍

曹智清， 网易杭研项目管理部总监。曾经感受过IBM的专业严谨，领略过ASK搜索的起起伏伏，体会过创业中的酸甜苦辣。目前致力于在线教育行业的探索，同时关注项目管理在互联网产品全生命周期的应用，专注于敏捷精神的渗透和实践。

雷蓓蓓， 网易项目管理专家，CSM、PMP，ScrumGathering大会、Agile China、Top100 summit、AgileTour大会讲师。在网易九年多时间，先后负责过云存储、轻博客、云计算、云阅读、漫画等产品的项目管理工作，对跨部门沟通与合作、建设高效研发团队、组织敏捷转型等有丰富的实践经验。个人项目管理专业博客：http://leibei1128.lofter.com/

何燕华， 网易资深项目经理，PMP，CSM。先后在网易私有云、网易用户中心、网易GACHA、网易LOFTER等项目担任项目管理工作，积累了丰富的项目管理实践经验，并始终致力于项目的成功交付和团队的健康发展。

刘煦萍/Abble， 曾先后在摩托罗拉、诺基亚西门子任职。现为网易资深项目经理，先后服务于网易云存储、客户端安全、易信、云信、七鱼等产品，专注于流程优化、版本交付和团队成长。爱好旅游、乒乓和美食。

靳霄， 网易云音乐项目经理，致力于推动团队基于价值的交付、效率的提升和团队的成长。之前曾先后就职于摩托罗拉、诺基亚西门子。

陈海春， 网易考拉资深项目经理，PMP、CSM。先后负责过网易印像派、易信支付、网易理财、考拉海购四个部门的项目管理，根据各部门的现状因地制宜地引入相对应的项目管理方法，并提升业务发展。有十年项目管理经验，曾供职于华为、STC。工作之外参加多次马拉松活动。

曾璎珞， 网易杭研资深项目经理，ScrumMaster、PMP。先后经历LOFTER、iStyle、网易考拉、网易用户账号等产品的项目管理工作。关注互联网产品完整价值链的改善，以及团队的激活。

吕广川， CSM、PMP，TiD大会讲师。曾任职科大讯飞，现为网易资深项目经理。先后服务于网易秀品、印像派、严选、网易考拉海购、网易漫画、网易云阅读等产品。保持退伍军人靠谱忠诚的本色，关注团队及产品健康、可持续发展。

钟欣， 网易杭研项目管理部资深项目经理，CSM、CSD、CSPO、PMP。曾任职于博克软件和印孚瑟斯，深谙软件开发的理论和实践。在构建敏捷团队和敏捷转型等领域积累了不少实践经验，成功帮助印孚瑟斯多个项目进行敏捷转型。2014年加入网易，担任云计算的项目管理，帮助云计算百人以上的团队成功完成了产品化转型，起到了显著的效果。

张孙恩， 网易杭研项目经理，CSM、PMP。土生土长的台湾人，台湾大学MBA毕业。曾服务于美商默沙东药厂、顶新集团。在网易担任猛犸大数据平台、网易有数敏捷数据分析平台、AR增强现实的项目经理，并担任过Color Touch、搜索算法等项目之项目管理顾问。关注大数据项目集的敏捷实践，与企业级产品的战略规划、项目管理。

汤君嬉， CSM、CSD、PMP。曾先后在私企、国企以及外企任职。目前在网易担任杭研项目经理，服务于视频云产品团队及易测产品团队，致力于团队的健康成长和流程的持续优化。

致　谢

总编：曹智清、张孙恩、甘辰希

主编：曹靓、武静、李慧、周巧芬

编辑：易扬、王游、吴琛、葛露萍、赵璐、屈鹏飞、詹莉莉

摄影：吴榕、吴琛

在此感谢所有为此书付出的网易同人。

大咖荐语

沉淀组织使能因素，赢得持续竞争优势

清华大学国际项目管理研究院副院长强茂山

在“光环国际—2015中国项目管理论坛”上认识曹智清女士，她在带领项目管理团队、积淀组织过程资产上做出了显著成果。记得那次会议上我的报告题目是“构建组织使能因素，探索智能管理实践”，也是倡导沉淀资产。我们的管理思路不谋而合。

那么，什么是“组织使能因素”呢？组织使能因素（organizational enablers，业界也称组织驱动因素）是项目健康并高效运行的沃土，它推动组织有效集成资源并高效地实现其目标。PMI® 的PMBOK® 指出：组织级项目管理将项目、项目集和项目组合作为实现组织战略计划的手段，在组织使能因素（组织文化、组织结构、组织技术等）的驱动下提升组织的商业价值。即项目、项目集和项目组合是实现组织战略的“实体”单元，而组织使能因素是从这些实体单元到战略的整个体系顺利运行的“软体”动力。

为什么要关注“组织使能因素”的沉淀呢？一方面，从理论视角看，在现代集成、共赢的管理大背景下，越来越多的企业采用项目式管理，将项目作为 承载组织战略的基本单元，而项目的实施又离不开组织这片沃土。PMI® 的OPM3® 指出，组织级项目管理强调以项目管理、项目集管理和项目组合管理作为战略执行的框架，以组织使能因素驱动管理实践，从而以可以预见的方式达成组织战略，赢得持续的竞争优势，实现商业增值。其中，组织使能因素作为重要的支持因素，在近年来的组织级项目管理实践和研究中得到越来越多的关注。另一方面，从实践视角看，大中华文化背景下的管理实践普遍更专注“短期赚钱”，不重视“长期能力”培养。我常用作解释的一个比喻是“乌龟”的四爪，项目乃至一个项目型组织就像一只乌龟，它的两只前爪用于获得项目，其中一只获得内部项目，另一只获得外部项目；两只后爪用于结束项目，其中一只将完成的产品移交给客户运营，另一只将做项目过程中的软资产（使能因素）积淀下来。正是基于这种使能因素的持续沉淀，企业才能像乌龟一样，百年存活并持续发展。但可惜我们大部分公司都仅忙于、乐于赚钱，而不沉淀（软）资产。

《网易一千零一夜》是一本沉淀（使能因素）资产的书。你从这本书中学到的将不仅仅是他们的体会、经验，更重要的是一种新思想、一种精神。体现在：第一，他们认识到了积淀过程资产是项目乃至组织生存、发展的基础；第二，他们在持续行动，四年沉积了《千里之行，始于足下》《春风化雨，润物无声》《拥抱变化，茁壮成长》和《滴水石穿，厚积薄发》；第三，他们在分享，从面向组织内部的《项目管理实战录》到面向业界的《网易一千零一夜》；第四，他们在成长，从项目经理基本功，到高度提升、宽度拓展、深度修炼。当你整篇阅读后，也可能会感到“我的过去十年经历就是这么摸爬滚打过来的”，但是，借鉴本书的经验，“裁弯取直”，你可能只用两年的时间就达到“深度修炼”的境界，这就是沉淀组织过程资产的目的和意义，也正是这本书的价值所在。

《网易一千零一夜》，建议你边读、边悟、边练。

提升能力，将不可能变为可能

Odd-e敏捷教练　吕毅

与很多网易PMO团队的人都认识，开始是他们中的有些人参加了我的ScrumMaster认证课程，随后在杭州敏捷社区活动中多有接触。他们每年的总结成文从第一期开始就看了，很高兴他们能坚持把这些思考经验写出来，我会把这看成他们团队的一份简历，记录了他们个人和团队的成长。

从Scrum的角度来说，项目经理的角色有点尴尬，因为在Scrum定义的三个角色中并没有项目经理，但许多公司里最初接触敏捷的人很多都来自PMO团队。传统的产品开发模式里业务和研发之间形成合同，由项目经理负责交付合同。这一点和敏捷中倡导的打破合同游戏，由业务全程和研发协作以最大化价值交付有着根本上的不同。很多项目经理希望能在项目中引入敏捷的思路和实践，同时又不得不面临诸多组织上的限制。这是我觉得需要应用可能的艺术（the art of the possible）的时候了，这也是我推荐大家读这本书的一个重要原因。网易PMO团队的这些总结分享关注如何在传统的组织设计下渐进地、因地制宜地引入变化和改进，关注如何为产品交付和团队直接快速地带去好处，关注如何提升人的思维和能力。现在的这些尝试虽然很少直接去改变组织结构，但是人的转变又何尝不是对组织未来可能的演进所能做的最好准备？今天看着不可能的事明天就变得可能了。

几年前结合敏捷和Scrum中的角色与网易的朋友探讨过项目经理的未来发展方向。我的观点是传统的以协调执行为导向的项目经理在未来的产品开发组织中能提供的价值会逐渐减少。随着业务和研发组织更多地直接交流协作，研发组织的跨职能结构简化了研发内部的协调对齐，相对于项目经理作为业务负责人的代理人和执行者，项目经理更有价值的工作会往业务和教练两个方向发展。推荐该书的另一个重要原因是网易的项目经理并不只聚焦于项目的执行 （当然也有相关的思考和实践），更重要的是在往业务型和教练型项目经理探索和演进。

陈海春在《项目管理境界之一二三》中提到境界二是懂业务，境界三是懂人。雷蓓蓓在《敏捷教练和项目经理》中的阐述显然已经不只是项目执行的境界了。曹智清在《当所有需求，涌向我的时候……》中关注做事的习惯和处事的原则，让我想起“个人和交互高于流程和工具”的敏捷价值观。雷蓓蓓在《项目经理的平衡之道》的总结是对温伯格“成为有效领导者”原则的绝佳诠释。靳霄在《主管的引导者角色》中强调的不再只是解决问题，而考虑了人的参与和激发。雷蓓蓓的《小鱼儿学沟通》系列中所展现的影响力已经不局限于授权。还有更多文章中的思考和实践都值得你去细细品味。

网易的项目经理们都还在继续成长，这里记录的思路和实践也会被不断更新，不变的是持续的思考和改进。我期待他们的探索和尝试能够激发你的思考和行动！

一本有态度的书

Odd-e唤醒者　滕振宇

不可多得的互联网项目管理实战指导手册

与网易杭研项目管理部的小伙伴们一直有不少联系，一方面他们之中有不少人参加过我的公开课，甚至不止一次；另一方面也在一些国内的会议以及社区活动、微信群中与他们有过不少碰撞。没看这本书之前，感觉这群小伙伴相当有活力，求知欲望强，而且学得特别快，尤其一点，在其他客户或者学生那里很少见到的现象是杭研项目管理部的学习转化能力特别强，迅速把课上的理念转换为日常的工作甚至产品的理念。我一直有一个遗憾，没有机会了解这伙人实际项目中的情况。感谢曹智清提前给了我这本书稿，让我满足了好奇心。 看完后，我开始对这群小伙伴刮目相看了，为什么呢？

这是一本实际的书

项目管理的书往往落入抽象的陷阱，让读者读完了觉得都对，但是不知道怎样转化，这些书更多的是在讲知识。而这本书十分与众不同，作者们是网易各个产品项目组的项目经理，这本书其实就是网易项目管理案例分析文集。作为亲历者，能够对项目管理的方方面面中具体的做法加以总结分享，背后意味着很多实践中的尝试、比较、反思，这对于其他团队、其他项目经理会有更强的借鉴意义。

这是一本专注于互联网项目管理实战的书

绝少有机会全面了解中国互联网公司中项目管理的玩法、他们遇到的通用问题以及解决方案。这本书把互联网项目管理经常遇到的那些坑，以及网易项目团队的解法无私地分享给了大家。网易团队的解法对于其他互联网公司也会有不少借鉴意义。尽管文章并没有十分直接的逻辑关系，但是很棒的是，所有的文章被由浅入深地分成了4个Sprint，随着Sprint的发展，话题也不断深化、拓展。

这本书是群体智慧的结晶

这本书体现了网易项目管理部小伙伴们的团队意识和群体智慧，这本身就是卓越团队的一个很重要特征。每个小伙伴都在自己关注的领域，通过自己擅长的方式分享或实践各种各样的想法，并且不断比较、尝试、反思，然后这些点子和经验被汇聚成一个整体。做好的产品，首先需要好的团队，有了这样好的团队，除了网易那些有态度的产品，又产生了这本有态度的书。

这是一本关于学习型组织、学习型个人成长的书

无论是敏捷还是互联网思维，一个核心能力就是组织和个人的学习能力，这本书就是一群爱学习、会学习的小伙伴的经验结晶。让我欣喜的是书中还分享了这伙人怎样学习，怎样举办读书小组，如何不断挑战、突破自己的舒适区。

想要全面快速地了解互联网项目管理，赶紧找个地方，冲一杯咖啡，开始吧！

附录A　项目管理增值服务介绍

网易杭州研究院项目管理部除了服务网易集团，对外也提供如下许多公众服务：

1．公众号推广合作

2．敏捷项目管理培训、讲座（敏捷、项目管理、时间管理等）

3．项目管理辅导与咨询服务

4．网易杭研产品合作机会

如果有兴趣，欢迎与我们联系和咨询：

邮箱：pm-bd@hz.netease.com

我们不定期传递项目管理实战故事、模板工具、业界资讯、培训动态等信息。

微信号：NetEasePM

Table of Contents

书名页

版权页

序一

序二

前　言

目　录

第1章　我是项目经理

给项目经理新手的五个建议

项目管理境界之一二三

估算那些事儿

工作时间打扑克？——扑克估算之我见

走一步，看三步——怎么做好进度计划

我们是如何开每日站会的

我的站会感悟

白板的艺术

不简单的周会周报

让你的报告会说话——如何有效、有料地进行工作汇报

项目管理≠烦琐的会议

高效回顾，引导团队从优秀到卓越

项目管理从零开始

悬崖边的舞蹈——小议风险管理及在互联网项目中的应用

心的修炼——项目沟通的四个原则

第2章　高度延伸

项目启动阶段，项目经理何去何从

产品初创阶段，项目管理该做些什么

项目初创期，如何帮助项目走上正轨

欲速则不达——冻结制度小谈

当所有需求，涌向我的时候

我们如何赶上工期

大版本下，团队如何完成项目目标

没有什么是不可能的

项目经理需要的能力——掌控冲突

网易云计算的大规模团队沟通

产品中的风险管理

我们的敏捷路

敏捷教练与项目经理

云主机项目的持续改进之路

第3章　宽度扩展

数据收集埋点流程梳理

打破“原地转圈圈”的魔咒

输了你赢了世界又如何

初试跨部门项目

小议合作项目中主要风险及其应对措施

Bug Bash手把手教你做

我们的持续集成之路——提高项目交付能力的利剑

JIRA工具的云计算中的应用实践

上线精神——献给开发兼做运维的同行

苹果审核血泪史——说说加急那些事儿

电商客户端Apple Pay接入实践

软件外包采购类合作项目的建议

建设学习型组织——读书小组实践

第4章　深度修炼

项目经理的核心竞争力

没有权力，怎么做项目管理

走出“已知”的舒适区

项目经理的平衡之道

给新上任的领导者的五个忠告

主管的引导者角色

从混沌中找出根本原因

项目成功路上的绊脚石，你遇到了吗

超越“老和尚”期望的那三两件事儿——论个人工作方式

如何建立与团队的信任

小鱼儿学沟通——性格色彩

小鱼儿学沟通——引入变化

小鱼儿学沟通——透过现象看本质

小鱼儿学沟通——向上管理

小鱼儿学沟通——走出困境

作者介绍

致　谢

大咖荐语

沉淀组织使能因素，赢得持续竞争优势　清华大学国际项目管理研究院副院长　强茂山

提升能力，将不可能变为可能　 Odd-e敏捷教练　吕毅

一本有态度的书　Odd-e唤醒者　滕振宇

附录A　项目管理增值服务介绍