禅道管理实践总结 第1篇

禅道在项目管理部分有一个更新工时的功能。分解任务估算工时后，每个领任务的人都可以在禅道上把自己每天花销的工时和预估剩余的工时录入进去，以便于产品经理（指已经负担起项目过程管理的，后面提到的产品经理都是如此）发现延期风险。

实际运行时发现，指望每个领任务的人去准确更新每天的工时是一种奢望。禅道的这个设计思路是很好的，精细化管理嘛，把每个人每天的工作量化，但是软件开发不同于送外卖，量化本来就是难题，那么期望一个团队中好几个能力参差不齐的人能够更新准确的数据就更不可能了。

禅道管理实践总结 第2篇

最开始我们团队设置了一个产品经理和一个项目经理，产品经理只负责把控需求，划分版本，输入计划。项目经理负责分解任务，估算以及过程监控。运行一段时间后，产品经理和项目经理都很沮丧。

为什么沮丧呢，这和我们团队的项目特点有关，我们团队的项目来源很杂而且很多，且并不局限一个领域，举个例子，团队可能同时进行着电商和政务信息化等多个项目，产品经理疲于转换不同领域但浅尝则止，需求理解不到位。项目经理每天只有一件事就是开会，分解任务估算工时，一个项目弄完弄另外一个。

禅道管理实践总结 第3篇

我的团队最开始使用禅道的时候，根据敏捷教练教的方法，每一步都严格按照教练的要求，一步步往下走。后来思考后发现，其实每个团队都是独特的，一定要找到适合自己的“最佳实践”。

需求录入，形成需求池，按照版本计划取出需求分解任务，团队成员领任务，完成任务，需求一个个搞定，叮！项目结束啦！完美的流程。

但是实际运行中发现，这个流程中需要一个平衡。中国人讲究做什么事情都有个度，不能为了分解而分解，分解花的时间已经可以让项目延期了那就失去了分解的意义。

禅道管理实践总结 第4篇

此阶段主要是开发人员的技术沟通，测试人员的测试计划和测试用例沟通，所以产品经理和UI设计师在这个阶段的时间里实际上已经是在做第一个迭代周期的工作了，产品经理在禅道中录入细化需求，UI设计师开始设计页面。

技术经理组织开发人员，进行项目的技术选型讲解和沟通，总体设计师对项目的总体设计进行讲解，数据库设计师对数据库设计进行讲解。讲解沟通无异议后，技术经理对每一个大的需求功能块指定开发负责人，负责人主要负责功能的模块设计、任务分解、功能开发和提交测试的跟踪，具体的开发工作可以是负责人，也可以是其他人，根据具体的工作量调配。

测试经理制定测试方案，并和相关的测试人员沟通，分配测试人员具体负责哪些功能模块的测试工作。

运维人员根据技术人员提的要求和功能需求，对服务端部署进行设计，并把发现的问题反馈给技术经理和产品经理。

完成开发、测试的人员分工后，整个项目就进入的具体的迭代开发周期。

禅道管理实践总结 第5篇

在产品立项前，产品经理做充分的用户需求调研，和市场营销的同事交流沟通，得到初始的用户需求。根据原始用户需求，产品经理规划产品需求功能，绘制原始原型图并整理需求文档（需求点较粗）。

产品经理进行市场可行性分析，同时提交需求文档和原型图给技术经理，技术经理对产品进行技术可行性分析。技术经理进行技术可行性分析时，可能会涉及到线上服务器部署相关的参数，这时需要运维人员协助进行部署可行性的分析。

最后，产品立项阶段产出需求文档、需求原型图、市场可行性分析报告、技术可行性分析报告，这些文档由相关领导评审后，进入下一个阶段。

禅道管理实践总结 第6篇

今天就说这三个实践吧天有点凉，手抖……

最后想说一点体会，软件项目管理真的是一门学问，虽然可以让师傅带着走一段，但是最重要的还是要自己体会，不停复盘不停尝试，找到适合自己的最佳实践。而且我发现“没有银弹”真是一句大实话，国人做事总认为自己把事情交代了，然后就能到点收获成果，这该多神奇啊，这其实是不负责任。现实往往是没有捷径，没有神奇的事情发生，只有脚踏实地的干。

声明：我可没有收禅道的广告费，要是禅道的人看到了这篇文章，麻烦给我个红包，谢谢。

我是个会开飞机的产品狗和程序猿。公众号：flypmang （不会开飞机的程序猿不是好产品狗）欢迎来看我～