写点什么

效能改进之项目例会导入实践

  • 2020-03-18
  • 本文字数:2426 字

    阅读完需:约 8 分钟

效能改进之项目例会导入实践

众所周知,在项目管理的过程中,我们需要非常注重沟通,而每日例会作为沟通管理中的一项最佳实践,非常适配互联网项目短频快的特点。成功地在项目中建立例会制度,能带来以下好处:


1)让研发人员相互之间了解各自的任务完成情况,以便于上下游及时衔接,发现进度异常和集成的风险。


2)让技术难题和业务疑点及时暴露,并根据问题的普适程度,选择在会上或会后得到支持与解答。


3)让产品经理了解研发过程,一方面及时掌握动态,另一方面能对结果和风险抱有更深切的同理心,以便后续能更紧密地合作。


4)帮助团队建立秩序感和纪律性,提升组织的成熟度。



作为一名在 弱矩阵型组织 中拥有微权力的 PM ,要在一个尚没有形成惯例、且仅为完成当前项目而临时组建的团队中建立例会制度,笔者建议以如下方式迈出第一步:

一、事前摸底

可以先通过访谈对话的方式,收集项目组成员在 如何透明研发进度和风险 方面的认知情况,甚至可以了解一下其所属部门的工作风格,以便采取合适的应对措施。


如果有成员曾经参与过项目每日例会的相关实践,务必抓住这个机会,尽量说服 TA 作为你安插在项目组中的卧底,在必要的时候主动站出来配合你,这样的话,其他人也更容易行动起来。


可能也有成员曾在例会中经历过糟糕的体验,比如:时间冗长、议题蔓延、信息过载、与之无关等,这时,你一方面要庆幸提前发现了暗礁,在自己组织的例会中要尽量避开(当然,如果你有丰富的项目管理经验,阅会无数,那你能举出更多的失败案例,但无须事事防范,否则过犹不及,让自己处处掣肘),另一方面,也要更加谨慎地实施你的想法,避免对方受到二次伤害,进而对 PM 和改进工作丧失信心。

二、承诺约定

PM 需要具备一定的主动性,在项目启动之初(比如: kickoff meeting 上)提出例会的建议,可以介绍一下例会对项目及成员所带来的好处,与大家(包括 PO )约定每天在固定时间和地点同步一下各自的状态,挑选大家都合适的时间,并获得每个人的口头同意。


作为交换, PM 须针对大家关切的问题作出一些承诺,比如:确保会议的质量,时间不会超过 15 分钟,会后有文字材料输出用于追溯。


不仅是例会制度,绝大部分的改进工作都会要求参与者走出舒适区,做出一定的让步甚至承受阵痛,故所谓“投之以桃,报之以李”:你愿意配合我的工作,我也不会让你失望。针对之前调研所掌握的信息,给项目团队吃下定心丸。

三、不见不散

可以要求让每个人创建一个日程提醒。但无论设几个闹钟,刚开始几次例会,还是会有不少人迟到甚至忘记出席,需要经过反复提醒才会慢慢养成习惯。


守时是职业操守之一,但如果遇到成熟度较低的组织,则需要不断灌输和教育。这时候, PM 一方面需要及时补位,在会前就做好提醒工作,另一方面也可以于会后在项目日志中做好记录,在必要的时候反馈给当事人所属部门的负责人,一起帮助 TA 改进。身处于某些组织文化中的读者,可能会对这种直接了当的反馈方式抱有畏惧心理,但考虑到“如果团队尚未达到理想的成熟度,未来高阶的改进工作将难以开展”这一点,就不应该回避沿途的任何困难。


另外,例会地点尽量固定,以便于大家习惯的养成,否则每次换地方都要再通知,成本很高。


四、每日三问

首次例会一般需要花更多的时间,最主要的一点是 PM 需要向大家讲解和示范如何参与例会。当然,在 承诺约定 环节可以做一些铺垫,但光是口头解释缺乏身临其境的场景感,大家未必都能 get 得到。所以,也不必赘述,只要现场主动参与和切身感受一下,包教包会,屡试不爽。


为了争取最佳的投入产出比,我们有必要把例会的环节设置得尽可能的精简,但又不失效果。笔者建议会上所有人站成一圈,每个人(除 PM 和 PO 之外)轮流向团队回答三个问题:1)我昨天做了什么(即:工作进度);2)我今天打算做什么(即:工作计划);3)我遇到了什么困难(即:暴露风险)。


前两个问题,上下游与之依赖的组员会特别关注,比如:前端依赖于后端的接口实现,否则他自己的功能验证工作会迟迟完不成。而第三个问题, PM 和 PO 会比较关注,他们有义务为项目扫除障碍,比如: PM 需要协调项目团队以外的技术顾问来做支持, PO 需要解答产品功能细节的疑惑,不一而足。通过上述三个问题,信息在项目组内部变得完全透明,成员对工作更有目标感, PO 对成功交付更有信心,妈妈再也不用担心我的项目了!


如果组织得当,按每人三句话的速度,一次例会妥妥地被控制在 15 分钟以内。当然,由于例会的时长非常短,为了确保会议的效率和效果,仍然要求 PM 控制好会议的节奏,同时也需要项目组成员全身心投入。

五、反馈改进

每人分享完自己的三个问题且没有其他公共议题了的话(非公共议题应放在会后单独进行),项目团队的首次例会就进入尾声了。此时,大家的精神状态已经放松下来了,由于是第一次例会, PM 可以在宣布散会前询问一下大家的与会感受,以便后续做改进。


也许首次例会并不如你预想的那样完美,比如:有的成员不太善于表达、有的成员会忍不住和其他人开小会、有的成员羞于公开上报自己的风险,等等。但至少你已经迈出了第一步,项目组成员的心中已然被你播下一颗种子,后续免不了还要不停地浇水施肥,帮助他们积累 如何高效参与例会 的经验,在现有最小可用例会的基础上持续迭代。


小结

导入项目例会 比较适合作为对组织实施效能改进工作早期阶段的一次试探,以投石问路的方式了解组织对轻量级变革的接受情况。如果较难接受,则说明组织的成熟度不高, PM 要做好贴身辅导打持久战的心理准备,反之则能顺利推广并赋能到组织的各个角落。


在有赞建立项目管理体系之初,笔者曾倡议试行项目例会,有幸被广泛接纳,辅之以实物看板,简直如虎添翼。曾经有一段日子,某间狭小的会议室,在一个小时内轮番成为四五个项目的每日例会之场所,与会人员络绎不绝,一派繁忙而有序的景象。


作为 PM ,每次参与项目管理都是一次帮助组织进化的机会,而每个为新项目所临时组建的团队中,都可能出现你曾经合作过的同事的身影。让他们成为你效能改进工作过程中散在各处的星星之火,从此,你将不再是一个人在战斗。


2020-03-18 19:54646

评论

发布
暂无评论
发现更多内容

Nop平台的定位和发展规划

canonical

DDD 低代码 可逆计算 Nop平台

第二十二周作业

大肚皮狒狒

华为云GES助力九洲平台:探索确定性运维的新实践

华为云开发者联盟

开发 华为云 华为云GES 华为云开发者联盟 确定性运维

第七周作业

大肚皮狒狒

4K Star,强大的实时监控告警系统

GitHub指北

TIKV 分布式事务--Prewrite 接口详解

TiDB 社区干货传送门

TiDB 底层架构 TiKV 源码解读 TiKV 底层架构

“分布式透明化”在杭州银行核心系统上线之思考

PingCAP

数据库 TiDB 银行业

听 GPT 讲 client-go 源代码 (3)

fliter

听 GPT 讲 client-go 源代码 (4)

fliter

想设计一个高并发的消息中间件前,先熟悉一下这些知识点

华为云开发者联盟

开发 中间件 分布式架构 华为云 华为云开发者联盟

OpenAI 推出的文生视频 Sora,目前 AIGC 视频的天花板,会让多少公司望而生畏?

派大星

Open AI

fastposter v2.18.0 一分钟完成开发海报-云服务来袭

物有本末

海报编辑器 海报生成 海报小程序

听 GPT 讲 Deno 源代码 (13)

fliter

架构的技巧

agnostic

架构设计原则 架构设计实战

听 GPT 讲 client-go 源代码 (1)

fliter

通过 Prometheus 编写 TiDB 巡检脚本(脚本已开源,内附链接)

PingCAP

数据库 TiDB

一篇文章彻底搞懂 TiDB 集群各种容量计算方式

PingCAP

数据库 TiDB

架构误区系列19:Big API

agnostic

架构设计实战

第八周作业

大肚皮狒狒

4 月 9 日至 4 月 10 日,Hack.Summit() 2024 首聚香江

TechubNews

starknet财神开始发红包了

币离海

以太坊 空投 starknet

在中国做 DePIN?你需要明白风险与机遇

TechubNews

中国比特币矿工的新根据地:埃塞俄比亚

TechubNews

BTC

关于ERPNext的树形结构研究

麦兜

网安训练营 毕业总结

李某人

效能改进之项目例会导入实践_文化 & 方法_feijieppm_InfoQ精选文章