重新定义项目管理 — 个人蜕变，组织转型

Posted 2021-05-02 青色进化领导力

     

       上篇谈到十几个团队并行开始敏捷方法的实践，尝试了三个月之后，项目经理们困惑了，一个巨大的“哲学”问题摆在面前：

我 是 谁？

        公司的组织架构中定义的正式岗位是—— 项目经理；可是在scrum 中，没有项目经理，参照第一个项目，项目经理做PO，但实际上很多事情是产品经理在做的；scrum master又是谁？好像项目经理的工作中也有部分像 scrum master .

         Scrum 中的PO 和 SM双领导力在实践中又是怎样运作的？俗语说：一山不容二虎，跟双领导力似乎又有些冲突。我的Scrum 教练告诉我，SM最好是全职的，而我们几乎都是兼职SM.......

        有很多困惑升起，在敏捷的探索实验中，“我”在成为谁？“我们”又在成为谁？

       我们尝试着通过回顾“我们从哪里来”中，找些蛛丝马迹，希望能够顺藤摸瓜，找到“我们要去往哪里”的方向。

过去项目经理是谁？

       PMI的项目管理知识体系中又是这样说的，在项目章程中定义项目的范围，预算，初步时间表，项目经理的权限。

      在我们的实践中，项目经理很多时候的主要工作是协调资源，追踪进度，保证在计划时间内完成项目，同时考虑质量成本等完成指标。总结一句话，项目经理是负责完成项目KPI 的人。我们问自己：这样的职责定义，我们满意吗？与我们内心的渴望一致吗？答案是不满意，不一致？这是为什么呢？

       一方面，产品需求是市场部输入的，决定是老板们做的，项目经理只是个执行者；另一方面，在市场的快速变化，组织日益庞大的复杂情景中，似乎每个人都在有意无意中期待项目经理是个超人，能够面面俱到，确保最后良好业务绩效的达成。

      

       改变势在必行，那么正好借着敏捷的东风，去实验，探索出一条新的道路来！

重新定义项目经理

      在2005，公司的项目管理流程中，是用 project leader整个称呼的，到了大约2009，修改为project manager,原因是为了项目经理赋予项目经理更多的权力，比如参与制定团队成员的目标设定，绩效考核.....

       当然，修改了头衔称呼，就能赋予更大的权力吗？就能让项目进展更加的顺利一些吗？不管怎样，当时我们就是这样认为的。

        

       在敏捷的实践中，基于当时的情景，我们部门对于项目经理及Scrum master 的角色进行了重新定义，如下图:

      由“project manager" 改为“ project leader", 我们想要更多的强调领导力，提升自己作为领导者的影响力，而非管理者的权力！一个团队就一个领导角色，“project leader" 需要综合三个角色的能力：

1. 项目经理 ：管控项目的能力，管事。

2. PO:“产品，项目的负责人”具有企业家精神的创业者，以愿景引领团队。

3. SM：教练团队，支持陪伴团队成长。

       

       印在部门名片上的这段话，是我们想要成为的领导者，我们希望自己的行为能够鼓舞他人梦想更多，学习更多，成为最好的自己！

     Scrum Master 是个颇有神秘感的角色，从前没有，基于前两个项目的实践，觉得TA很重要，对于个人的能力要求也特别高。这么多团队要开展敏捷，需要这么多的Scrum master，总不能凭空而降吧！

      办法总比问题多！我们想到把Scrum Master拆分成两个角色：Scrum moderator 和 Scrum coach, moderator, 主持人，对我们来说是非常熟悉的，公司内部多年来就有会议会议主持，工作坊引导的文化；Scrum coach，敏捷教练这是个新的角色，没有人知道具体是干嘛的，那就还是由我来第一个跳下河，带着大家一起摸着石头过河。

       在困惑中，我们找到了可以踏出去实验的一步，我们内部很兴奋；同时，也听到了一些质疑和争议：你怎么擅自就把项目经理职角色修改了呢？你做的这不是Scrum?书上不是这样讲的，培训中老师不是这样教的，其他公司没有这样做的......

       听到这些声音，我有些挣扎，对自己也产生了一些质疑：大家说的都对，我们这样的做法真的可行吗？同时，我也听到了自己内心的声音：按照现有的流程，Scrum 框架的标准定义，能够解决我们眼前所面临的问题吗？不能；既然没有更好的方案，那何不大胆的尝试！

      Scrum master角色的拆分，为很多人创造了成长的机会，scrum moderator 志愿者们加入进来，这为多团队的敏捷旅程，注入了一股新鲜的活力，我们大踏步向前行进了。

项目经理的成长之路

       在公司里，传统的做法是先定义出角色的能力要求模型，然后做能力评估，根据能力评估结果提供相应的培训，这个做法看起来是那么的完美；在实践中却是耗费大量的人力财力，可是效果甚微。

原因之一：很多情况制定能力要求模型的人并没有实际岗位的工作经验，能力要求偏理论化。

原因之二：能力评估的过程夹杂了很多其他原因，如薪资待遇，这使得能力评估不是以发展和成长为目的。

原因之三：培训是培养能力的一个途径，但并不是最有效的途径，实践才是！

       我们摒弃了过去的做法，基于罗伯特.迪尔兹老师的理解层次，写出敏捷心智层次模型，然后用这个模型自我评估，制定自我成长行动计划，年底的时候大家在一起，回顾，分享，学习，共同成长。

自我评估的小练习：

       建议你读到这里的时候，拿出纸和笔，来做做这个小练习，问自己一个问题：我的工作是什么？（我是如何理解我的工作的？）

1. 把老板交代的事做好。

2. 把设定的绩效考核出色完成。

3. 很好的满足客户提出的要求。

4. 为用户为公司创造价值。

5. 具有企业家精神的创业者。

      这是一个非常简单的自评工具，很多项目经理发现自己在2或3的层级，没看到这个自评工具之前，一直以为自己的工作做的挺棒的，自评之后，给自己制定了具体详细的成长行动计划。

心智层次模型带给我的成长：

      当建立这个模型时，我自己明确是在3——能力的层面；同时，我能感受到内心有股隐隐的力量，在拉着我逐渐走向价值观，身份的层面。那时候，我时不时的用这个自我评估来给自己的心智成长定个位。

      记得一年后，也就是2015年的9月，我去上海找CEO，在火车站，我给部门的伙伴们发信息：“此刻，我感觉我的状态到了5，敏捷组织转型就是我的创业项目，我准备好了！”

Scrum master的能力发展系统：

       如今，我 并不太喜欢规划“职业发展”路径这样的做法，因为我认为对每个人来说最重要的是：

我想要成为怎样一个人？

我有怎样的天赋优势？

这一生，我最想要创造的是什么？

        职业发展是生命旅程中的一部分而已，可是在我们成长的过程中，过去关注职业发展，而忽略了生命本身。关于职业发展这个部分后面的章节再详细展开。

       2014年的我，身陷在职业发展的困局，尚未突围而出，那么这个Scrum Master能力发展系统，以职业发展为主线就一点不足为奇了；同时，这也是当时的需要，这个发展系统为很多人带来了希望和活力，为他们打开一扇新的窗。

这个图是SM能力发展的生态圈：

Project team : 要尝试敏捷实践的团队

Scrum training : 为团队提供的scrum 培训，培训结束时招募SM志愿者。

Scrum moderator : scrum 主持，从主持站会开始，逐渐的再主持计划会等。

Scrum practice coaching: 每月的回顾，学习，分享，教练，共同成长。

Senior scrum moderator : 主持所有的活动，并且教练刚刚起步的scrum moderator.

Project leader : 对于想要在项目管理这个方向有所发展的员工，SM的经验会有帮助。

PM&SCRUM coach : 敏捷方法教练 ，积极的推广敏捷，支持团队开始敏捷。

关于Scrum master的各种实验

      有了人选，我们就开始了关于Scrum Master的各种尝试,没有统一的标准，每个团队各自参照前两个项目开始实践，经过了几个月后，把大家约在一个共同做个回顾，来做出下个阶段的调整。

       我们以工作坊的形式展开。（或许是因为我个人喜欢引导的缘故，引导能力是我们项目经理必备的素质，敏捷对我来说，某种程度上，可以称之为以工作坊形式展开项目管理。）下图是当时的讨论：

      这次的工作坊中，我们得出了这样的结论：

项目经理不能作自己项目的SM,

核心团队成员不建议作自己项目的SM,

鼓励交叉着相互作SM。

SM需要具备的品质：

耐心，关心他人，聆听，逻辑，观察，热情！

这也是第一次我们作为团队正式从能力向更深的层面去探索。

SM角色的边界条件：

项目经理作为自己团队的SM，这是不可能的，因为我们远远还不具备能够平衡好“事和人”这两者的能力。没有成长空间，让我们去改变自己习以为常的“push""monitoring and controling"的行为模式。

核心团队成员作为自己项目的SM,非常挑战，因为在项目的会议中，他常常扮演着两个角色，时间久了，会有点“分裂”的感觉，特别在团队的激荡期；对于相对成熟的团队，这个做法大家感觉挺自在的。

项目经理作为其他项目的SM,是个不错的尝试，因为没有项目结果的压力，能够更加中立的支持到团队的成长，同时，还可以在项目上相互学习。

      基于这个实验结果，基本上我们形成了团队之间互为SM的惯例。并且我们也很快实现了SM-项目经理自组织，SM社群的自组织雏型在形成。当时在我们的组织中，谁做哪个项目是被分配的，当SM的社群建立起来后，就逐渐实现了自主管理。

      每个项目经理暗暗的担心没人愿意做自己的SM，她会更加在工作中注重“人”的因素；SM暗暗的焦虑没有项目组愿意找TA，所以TA就会想办法自己学习努力提高自己的能力。而我做的工作就是我天赋的部分：培训，教练, 在后面章节我会讲到如何关注个人天赋，组建高效团队.

       

重新定义项目管理

       项目经理，PO,SM角色展开了新的探索的同时，对于项目会议也展开了一系列的尝试。

过去的项目会议？

      项目相关的会议，在我们的组织里可以归结为两类：

第一类项目团队会议：团队成员参与，每周一次，大约2h.大多内容是跟踪任务进度，以项目经理主持，大家看着大屏幕，团队逐个更新自己的工作。很多时候显得有些乏味无聊，开着会心不在焉，玩着手机的现象屡见不鲜。

第二类项目评审会：董事会，所有的职能经理，每个月一次，大约一天，每个项目经理汇报项目的进度，风险，提出需要批准的申请。

       每个人都谨慎甚微，项目经理们怕不能够得到及时的支持和决策，职能经理们担心自己部门什么没做好被投诉，老板们担心自己了解的信息不够，做出错误的决定。为了这个会议，项目经理提前一周就开始准备PPT，跟职能经理及分管老板讨论，从具体要解决的问题，到提议的方案，更甚是每个用词，所使用的模版等等....... 那种感觉就像是上学时的期中期末考试，而我们是每月一考。

重新定义项目会议

       很自然的，应用Scrum框架，改变了第一类项目团队的会议方式，团队会议变成了一个大家一起的工作坊形式的工作方式。

Scrum 中的会议：

        在Scrum实践中的四个会议：

计划会议：在每个迭代的开始，团队成员参与，有需要的时候邀请经理及专家参与，最初2天，逐渐过渡到半天——2～3个小时。

What I have done

What I will do 

Any impediments

      开始时，我们是掐着秒表的，为了保证15分钟结束，因为大家并不太习惯简短直接的表达。

      “Impediments"在很长一段时间都没有，一方面很多人并不太理解这个词究竟什么意思，不知道要说些什么；另外一方面，大家并不太习惯暴露小问题，都想自己尽力去解决，往往这就造成了后面的大问题。 后来，我们就明确，任何在当下感知到的风险，阻碍，问题，都可以在这里简短的抛出来，贴到板上去。

产品评审会：由于产品的性质，不可能像软件那样每个迭代都会有产品增量的输出，很多时候是，好几个迭代才会有。评审会，我们就主要来依照机会会议所定义的“接受标准”，PO和团队一起来共同验收这个迭代所完成的工作。

回顾会议：最常用的工具就是海星图，在过去的这个迭代中，什么让我开心，什么让我不开心；什么我们要多做，什么我们要少做；我有怎们的新的点子，下个迭代可以尝试。

      后来，基于一个团队的最佳实践，我们发展出了第二个工具，团队愿景的自我评估。

      每个团队会专门展开半天，一天，两天不等的工作坊来讨论：我们想要成为怎样一个团队？比如，上图展示，团队想要成为一个“disire, on time, communication, learning "的团队，对于每一个关键词对他们来说意味着什么，也会展开详细的讨论和澄清。

      接下来，在每次的回顾会议中，团队来以投票的方式来评估，比上个迭代那些进步了，那些退步了，上图图中，这次会议团队的自我评估是：目前我们是低效率的团队。没有人愿意在低效率的团队中工作，自我改善的行动计划就涌现了。

      另外，在2017年，在学习系统思考的过程中，7层冰山模型呈现，我开始用7层冰山模型来做回顾：

      具体细节在后期的文章中分享。

给评审会议减负：

      过去的项目评审会议模式始于2006年，当时组织中没有任何正式的项目沟通渠道，有问题时，再有针对性的解决；为了能够更好的支持到项目，就建立了一月一次的项目评审会；随着组织的壮大，人员的流动，领导风格的变化，慢慢的项目评审会就变成了在上文中，我所描述的那样，与会者都有些痛苦。

      回到项目评审会存在的意义：支持项目。

      如何做才是当时情景最为合适的呢？我们尝试着建立了Scrum 项目评审会，项目经理和职能经理参加，不用提前准备任何PPT，每个项目15分钟，就基于Scrum任务板展开，项目的进度，问题，风险等等都一幕了然。由于这个会议没有老板们的参加，就能够更加直接的深入实际问题，非常高效，相对来说，大家也轻松自在一些；有些时候，也会有一些激烈的争吵发生，相比老板们大家压着情绪，表现得很“专业“的相互推诿，这样直接的碰撞更有利于问题的解决。

      我们引入了Scrum评审会议后，正式的”评审会“变得高效了，时间大大缩短，大多时候2-3个小时，就结束了；并且以前各个部门相互推诿扯皮的现象也大大减少。毕竟，没有人真心的想要推诿，只是求自保，在老板面前争个好印象，在晋升之路上获得助力。

       随着项目会议的变化，减负，让组织中很多人切实的感受到了好处，越来越多的人开始对敏捷产生了兴趣，同时，也升起了一些担心和疑问。特别是当时流传的误解：敏捷，就是没有流程的项目管理。

       我在第一篇“敏捷在传统行业如何着陆”中就提到，12年就有总部发起，各区域参与，重新定义项目管理流程。

过去的项目管理流程？

       流程有两百多步骤，大概四十多是必须要做的，无论什么项目，什么具体情况；其他的如不适合具体项目的步骤，团队需提出申请，得到相关的批准后，才允许省去，有时候为了得到这个批准，团队需要额外做很多的“证明”，有些团队就选择做，但对项目并无实际意义，有些团队就选择不去申请批准，在回头项目审核的时候，就为不符合标准项。

       项目管理的文件的批准，纸质文件签字；很多都是需要老板们签证的，而老板们经常世界各地出差，打印，签字，扫描回传，会非常的不便。

重新定义项目管理流程：

       新的项目管理流程，也就是我在第一篇“敏捷如何在传统行业着陆”中所提到的Time To Market  agile;大概经历了一年多的时间，第一个版本的雏型就完成了，我们杭州敏捷团队，是全球最早开始大规模试用，边用边反馈边调整，正是的流程在2014年底，才向整个组织全球正式发布。

      

      新的流程整合筛减到一百个工作包，只有11个必做，比如需求文档，Quality Gate,项目阶段性的放行，失效模式分析.... 并且团队自己可以依据具体的项目需要，自定选择哪些步骤适合，不做的有存档就可以了。另外，把一部分的批准签字权交给了团队。

       配合着新的流程的，项目管理工具IT系统也进行了升级，项目的关键文档都可以存在系统中，文件的批准也都可以在系统中进行了。

       这些变化是令人幸喜的，同时，也引起了其他一些人的担心和焦虑。

敏捷了，质量怎么控制？

      敏捷，就是没有流程，这个误解，令分管质量的副总裁非常的焦虑。

      有一天，他来到Scrum room,我跟他讲了新的流程，5个Quality Gate仍然在的，在每个阶段结束的时候，团队会共同对照QG的清单一一检查，跟过去相比，质量控制从一个人变成了整个团队。另外，我们用“用户故事”的模版来计划,让我们更加有质量意识了。

As who 

We do what

So that why

      例如，作为研发团队，我们全寿命测试样机，是为了更好的验证设计方案，提供更加可靠的产品给用户。在过去，由于公司有非常详尽的流程，很多人只是在按照流程操作，而不追问为什么？

      副总裁听完我的分享，点点头：嗯，这样好，我们就是要这样做的，质量保证是关键。。。

敏捷了，合规怎么控制？

       在我们的组织中，充斥着两种声音：就是因为流程太多，才使得我们变得不敏捷了，太慢了；敏捷了，很多事情都不需要上面的批准，小到公司规范，大到各个国家的相关法律条款，怎么控制，还不得乱套了。

       敏捷团队开始后，很多人很担心，集团总部来审核怎么办，这是公司最高级别的审核，谁都不想被审核员查到任何的瑕疵，在我们的文化中，那简直就是巨大的污点，哪怕是漏掉一个小小的签字。

      结果怎样呢？16年初，我们迎来了审核，第一个敏捷项目被选中，全绿通过，很多细节得到了审核员的称赞。再一次验证了，在敏捷团队中，改变了过去靠流程来管控的状况，而是团队参考流程，针对实际的项目做出最合适的控制。

        

        项目会议的方式改变了，项目管理流程改变了，接下来谈谈项目团队成员之间协作关系。

过去的团队成员之间协作关系：

       当时，我们的组织是平衡矩阵的组织架构，每个项目组由市场，研发，质量，采购，生产，物流，财务等成员构成，在项目的事宜向项目经理汇报，实际的老板是自己部门的经理，部门经理有升职加薪的决定权。

      在这样的背景中，大家之间的连接就是项目中的职能角色以及项目的任务。

重新定义团队的协作关系

      由于我个人在13年开启了个人内在成长的旅程，开始参加一些个人成长，教练，静心等等的课程。我自己获益很多，14年也逐渐开始在我的部门和项目团队展开了一些工作坊。在这里，先分享针对项目团队展开的部分，其他的在后面个人职业发展的章节在详细展开。

      我们会为每个团队开展一天的工作坊：发现个人优势，发现团队优势。用一个例子来比喻：孔雀开屏，展现它美丽的羽毛，自然会露出丑陋的屁股；如果孔雀遮住它的屁股，它就无法开屏。我们每一个人都想要别人看见自己的，不想要别人看见自己的缺点，在不知不觉中我们花很多精力去隐藏自己的缺点，那自然也就无法全然的让自己的优点绽放出来；倘若是一群孔雀一起开屏，大家围成一个圈，那么就能够向外展示美丽，向内相互看见，彼此支持，共同成长。

上图中左边是个人的优势，右边是团队的优势。

       通过优势工作坊，团队中的每个人不仅更加了解了自己，同时也更加了解了整个团队。组织中通常大家只关注能力，经验，知识的部分，不太关注个人天赋优势的部分；并且相互的合作更多的职能：你是做研发的，我是做质量的等等。优势工作坊会让团队在“人”层面有更多的连接，从而有更深的相互协作！

自我探索的小练习：

       读到这里，邀请你做三个深呼吸，像过电影一样看看自己的过往，从中是否能够发现自己有怎样的优势，甚至与生俱来的天赋。

      或许，还有些困难，自己一时想不起，看不到，因为我们从小就被教育要“谦虚”，要关注在“我哪里还不好，更需要提高的。” 下面的几个做法你可以尝试：

借助测试工具，

2. 可以用免费的测试：

http://www.apesk.com/Advantage-detecting/index_hr_m.asp?hr_email=18670054561（PC打开）

你可以得到一份建议的报告：你的五大优势，以及34个优势项的全部得分。

跟他人聊聊：

逐个的约上几位了解你，在你生命的不同阶段陪伴你的人，比如，父母，老师，同事，朋友，问问他们，在你他们眼中，你具有怎样的优势，天赋。

通过这样的对话，可以帮助你了解自己，有一点善意的提醒：去探寻自己本来的样子，而不是他人期待的样子。

一天优势工作坊的流程：

      在这里，也把当时在团队展开的一天工作坊流程分享一下，当你想在团队展开的时候，或许会有帮助。

Check in: 让大家的状态进入到工作坊，通常会是身体的活动：跳舞，身体拉升动作。。。

你小时候有怎样的梦想？

给大家15～30分钟的时间，自己静静地思考，可以准备一些彩笔，蜡笔，涂涂画画。

接下来团队围成一个圈分享，随着场域流动，不去刻意控制时间。

注：现在有什么梦想，很多时候在组织中比较难以真实的打开，从小时候谈起会比较轻松一些。

你的职业表达了你的人生召唤吗？：

如果没有，那你对什么最有热情？

它为你实现了什么？

那么当下你的召唤是？

两两结对分享。

你现阶段有怎样的困难和挑战：

根据具体情况，决定是大组分享，还是分为两人，三人，四人小组分享。

个人优势，团队优势：

围大圈坐，用粗的记号笔，在A4纸上写下五个优势。

先从一个人开始分享：“我是如何理解我的优势的，在工作生活中是怎样呈现的？”

他分享完了之后，跟他人给出补充：“在工作中的某个具体事例中，我感受到你怎样的优势。”

听完所有同事的补充后，分享的人做一个简单的回应：“谢谢。。。。”

然后下一位，通常跟前面一位有共同优势的人就会自动接上。最好大家把纸放在地板上，所有人都可以看见。

       上面就是一天工作坊的简介。如果你想要更深入的学习相关内容，查看，过去很多的团队工作坊，沉淀，整合之后，慢慢生成的一个课程。

敏捷项目管理

        我们摸着石头过河，如今，我把过去的旅程细细的回顾总结，形成了我们自己的敏捷项目管理体系，由三个部分组成：

项目管理知识体系 

Scrum 迭代式的团队工作方式

关注个体天赋的成长

       

         我觉得这个框架可以在很多领域尝试。

          项目管理知识体系在我们具体场景中是研发项目管理流程，而Scrum迭代式的团队工作方式和关注个体天赋的成长，对于各行各业都适用。

         最近在跟一个朋友探讨，如果在她的场景中，用质量管理体系来替代项目管理知识体系，会发生些什么呢？我不知道，但我很想带着好奇跟她一起去探索！

系列连载

 1.

 2.

 3.

 4. 重新定义项目管理

  

我们探索更加完整的

工作生活方式，身体力行，

同时，帮助他人！

”