敏捷里的一句话+继续收集“一句话推荐”【人人都是产品经理:9065】

无论我们最终发现什么,我们必须理解并完全相信:每个人在其当时所处情况下,在其能力范围中,做了最大的努力。

只要每个人都这样想,团队必然充满力量,:)

PS:我要继续收集大家的一句话推荐,请回在这里~~~

  • 一方面,我努力争取到《人人都是产品经理》正文前几页专属的区域,大家的一句话推荐,只要内容靠谱的,都会和你的名字一起写进书里!
  • 另一方面,我也说实话啦,我实在请不到人来写一篇很长的序,也许我email的几位都太高级了(李开复、马云、李彦宏、马化腾……),正如这篇的第一句所说……能集齐他们的email,我已经很满足了,呵呵……

产品设计体会(3014)敏捷实践的一些过程项

上次说到了我们在项目中“敏捷沟通”的实践,顺着再补充几点项目过程中的敏捷实践。

任务认领,我们没有完全实施,现在是利用开发经理对工程师能力的了解安排任务。任务认领的假设是:每个人都是足够聪明和职业的,应该被安排在最合适的工作上,所以最了解自己能力的就是自己,于是应该每个人制定自己的工作计划,其他人帮着定都是不优的。相对而言,任务认领更适合工程师文化的特种部队式团队,比如Google

需求评审,有的团队在需求评审会的时候,让开发工程师来讲述他要开发的那部分功能的PRD(含UC),PD来提问。对比更经典的PD讲述,开发提问的方式,这样做有两个好处:一是逼着开发认真看PRD;二是可以省去设计评审,相对PD讲述PRD的传统方式而言,开发讲述的方式下,不做设计评审的风险降低。

结对编程,我们还没魄力尝试,相信国内也很少有团队敢尝试。一位开发经理对我说其本质是两个人互相监督,没法偷懒以提高效率,更重要的是,这种效率的提高还伴随着代码质量、可读性的提高,从而完全可以抵消表面的“做事的人少一半”带来的损失。

测试驱动,我们有很强很严谨的测试,会利用TC编写、TC评审、甚至测试执行的过程来补充和细化需求,比如一些限制条件、异常流程等等,往往都是测试的同学提出来的。

冒烟测试,编码完成后,测试的同学会马上做冒烟测试,目的是确认产品基本功能正常,可以进行后续的正式测试,冒烟完成后立即进行产品演示会,叫上项目干系人来查看产品是否符合期望,符合“尽早交付”的概念。

关于加班,我一直让开发经理、测试经理评估资源的时候留一点余量,甚至我在排项目计划的时候会再留一点,但每次看上去仍然还是在加班,也许是大家不习惯一下班就走,反而喜欢上班时不时看会新闻,晚上时不时做点工作的方式吧,不管给多少时间,任务总是在最后一刻完成,呵呵。

你在的团队有什么好的实践么,不妨也说出来给大家看看。

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

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

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

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

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

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

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

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