产品设计体会（3013）项目的“敏捷沟通”实践

我一直觉得敏捷 是理想与现实妥协的结果，是一种很好的实践，理论网上随便一搜就有很多，这次就说说我身边的团队，真实的实践，通过“沟通”的角度来讲，不妨起个名字叫做“敏捷沟通 ”。

我们的每个项目，项目经理都会建立一个临时的IM 群（旺旺）、 一个临时的邮件列表 ，把项目干系人全部加入。邮件列表通常是通过第一封项目相关的邮件，把大家的email 整理齐，在邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”。IM 用于实时沟通，比如发了项目邮件要大家赶紧收、文档有重要更新、测试环境构建了暂时没法访问等等，都可以群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的wiki 地址，以及一些测试环境的host 绑定等等公共信息。

经典的每日站立晨会 我们团队是坚持的，对于典型周期为2 ～4 周到项目，控制粒度到“天”还是很必要的，项目状态看板 视情况而定，经常搞，举例如下。

第一张图，是用白板做的项目看板，这类项目典型长度是两个星期，看板可以和项目日报、晨会整合应用，板上横轴为进度百分比，纵轴为项目成员。每个项目成员负责的功能点，用一张张便签表示，在项目开始的时候这些便签都贴在0% 的 下方，随着项目的进行，这些便签就逐渐被拿到右边的方格里。每天晨会的时候，大家都围在白板前，集中调整便签的位置。便签的红黄绿不同颜色可以加以利用， 比如代表不同类型的任务，白板最右边留出一块可以写其他必要的信息，非常随意。用了这种看板，对于如此短周期的项目，邮件日报通常可以省略。这个看板的最 大好处是随时可视，项目成员、老板路过都会看两眼，而每个人要自己贴条，也是一种督促和帮助，试想大家都按进度在走，你老是滞后，自己也有压力，另一方 面，如果真遇到困难，大家也能及时发现并提供帮助。这里也蕴含着自我管理的思想，让每个项目成员都对项目进度负起责来。

第二张图，是“魔方计划”（项目代号）的项目墙，和白板比起来，这个项目相对长期，2 个月左右，毕竟这样一个KT 板也要200 多 块钱，上面主要有整个项目的时间轴、各个团队的重要里程碑、产品设计过程的一些可视化文档等等。究其目的，也是让所有项目干系人随时可以了解到项目的各方 面信息，在每个项目里，类似的看板应该包含哪些内容，大家可以边实践边改进。最终能做到根据项目特点的不同，在启动的时候自然使出最合适的项目管理方法， 从而画出最适合的看板，就是最高境界了，而这种最高境界的习得，我现在的感觉是没法学，没法文档化，只能靠悟，比较郁闷。

顺便提一点，我们喜欢尽量给一些项目起个有意义的代号，说实话这样还真能增加临时团队的凝聚力，比如“还魂丹”（激活不活跃用户的项目）、“魔方计划”（将多个产品的零散模块整合成一个新产品）、“画皮”（产品界面改版）、“画心”（产品交互改版，PM 光 光 同学 在这个项目Kick Off 的时候，一直放着张靓颖的《画心》做背景音乐，感觉真的很不错），而一些特别的项目，还会把团队临时集中在一个会议室做，叫 封闭开发 。

最后小结一下，从沟通扩大至整个敏捷方法，任何团队的探索，都在试图给出一个介于“无过程”和“过度过程”之间的折衷方案，使这个轻重适中的过程给团队带来最大的收益 。

 

iamsujie猜你还喜欢：

• 产品设计体会（7009）敏捷估计与规划 (0)
• 产品设计体会（3004）项目外包不适合“敏捷” (0)
• 产品设计体会（7008）再理解敏捷 (0)