用户名*
邮箱*
密码*
确认密码*
验证码* 点击图片更换验证码
找回密码
忘记密码了？输入你的注册邮箱，并点击重置，稍后，你将会收到一封密码重置邮件。
踏心以学实
1.分期。
每期PM设计三周，研发三周，测试一周。
这样可以三周上一次线，如果你有两个Team，可以做到一周半上一次线，如果你有一个Team，可以做到一周上一次线。
2.目标。
确定每一次需要假设和验证的目标。所有的产品在未经使用之前，一切的结果都只能是假设。
必须要明确自己倒底想要验证什么，快速的去看，真实的结果跟自己的预测是否一致。
所以跟这个结果都不符合的，全部抛掉。
3.流程。
提前制订好必备的流程体系。
提前教导团队遵守流程。
没有流程就是扯淡。
4.睡觉。
或者是做白日梦。
1.远见，产品的目光是1年，其实好的产品可以看到3年后的产品是什么样子；
2.视野，产品的目光是整个市场，整个市场对产品的影响是产品不得不思考的；
3.资源，产品要清楚有多少资源，尤其是可控的资源；
4.节奏，产品只要给开发讲3个月内要做的事情就好了，这样开发才能专注在开发上，产品则是控制节奏的人。
至于你自己的节奏感，呵呵，想想你的目标是什么吧，大象放进冰箱中到底需要几步？每步花费的成本多少？带来的收益多少？想明白就好了。
多谢邀请。
但是因为前几天生病了，所以一直没有回答。
这个问题如果要回答，需要先解决掉目前国内软件行业的几个错误观点：
1，项目管理至上论
很多人认为当了项目经理就可以不写代码，所以，很多本来对代码没有兴趣的却为了赚钱或者其他原因进入软件行业的人就热衷于将自己变成项目经理。
结果，这些人当了项目经理，却没有实际足够的代码经验，就出现了大量的瞎指挥和乱指挥，项目组内一地鸡毛，事情讨论不清楚，任务执行无结果。
还有些人拿着自己考出来的证书就认为自己应该当项目经理，然后照本念经，或者言必称某经典如何如何，某经典中某牛人团队就是如何如何操作的。
这都是错误的行为和认识。
2，项目管理无用论
然后就有了一批人认为，我们自组织就可以了，不需要项目经理。
然后项目中想做什么做什么缺少规划，缺少管理，缺少控制，缺少推进，开起会来人人都是牛人，看看项目却不知道进展几何。
————————————————————————————————
真实的项目管理中，项目经理是整个项目中最累的人。
于是，某位实际上没做什么事情也很清闲的项目经理就据此说，看到了吧，其实我最累！——我想对他说，其实你最雷！
大家都知道的默认规则，项目失败，首先的责任人就是项目经理，但是很多人并不知道，为什么一定是项目经理，这是因为很多人不知道项目经理到底是做什么的，负责，负责什么，只有负责两个字是没用的。我曾经给一家公司做内训的时候写过一个项目经理的工作任务内容，涉及到每天，每周的工作内容，而实际上，那个内容也是不够完善的，但是有这个为基础，就可以好很多，至少可以清晰一些。
每日工作任务：
p组织站立会议（计划，执行）
p进行成员任务的分析/调整（执行）
p组织必要的评审和讨论（执行）
p进行每日工作情况确认（计划，执行）
p异常任务处理和临时安排（计划，执行，风险）
p了解每个成员的任务执行情况，随时把握进度和可能遇到的问题（计划，执行，风险）
p给自己安排的研发任务（执行）
p每天检查配置库情况，确认执行与计划的匹配度（验证）
p其他事务（诸如招聘以及其他与项目任务无关的事情）
每周工作任务：
p周五拿到每周记录汇总后进行周报撰写，周一提交；
p制定/调整项目当前/下一个迭代计划，并跟进执行；
p分析遇到的项目风险，并针对风险的状态进行处理；
p项目紧急风险和特殊情况的及时汇报和沟通处理；
另外，项目启动，关键节点，项目结项，验收测试试运行等不同的阶段点也都有不同的任务内容。
注意：以上任务列表是需要根据你的具体管理方法结合起来修改的，建议最好不要直接照搬。
每周的任务中就是为上一周做总结，然后为下一周制定共同目标，控制节奏。
而每周的计划是在迭代计划中的，这需要在具体的迭代中制定共同目标，大家会在一个较大的视角范围来考虑项目的进度和自己的任务组合形态。
而每天的任务是检查控制较小的进度偏差，以便于发现后尽快调整，并对人员和任务进行重新组合，以期避免更大的问题，而很多项目经理往往会忽视这一点，结果造成更大的问题，也使得每周的计划无法到位，更大的迭代计划也无法获得有效执行。
今天先写这么多，后面有时间再来补充。
想要形成节奏感，首先要让工作更聚焦。工作明确了，大家劲儿往一处使，就会很容把目标实现，而且沟通上也会减少很多阻力。
伟大领毛主席曾说过：面对强大的敌人时，我们要集中火力，各个击破。
当然，光有主张是不够的，还要有实现方法。
就以我个人的经历来说吧：
我记得自己第一次负责项目时，踌躇满志，每天认真整理需求，把任务列表塞得满满当当，为了按时完成产品上线的目标，要求团队加班加点赶进度，梦想着有朝一日成为CEO，迎娶白富美，走上人生巅峰。
但这种方式非但没有加快进度，反而让团队做起事来变得更拖沓了。
后来一位比较有管理经验的前辈对我说了这么一句话：实现不了的目标，等于没目标。
我想想，确实是这样的。定那么大个目标，每天都不知道做到哪算完，一想后面还有那么多……去他大爷的，老子还不如逛京东淘宝！
所以说，团队效率低下的主要原因在于没有明确的目标感，导致大家最终失去了工作热情。于是我就想，如果把冗长的任务列表变成一个个可完成的小目标，会不会能让大家更有干劲儿呢？
随后，我开始将项目拆分成许多个小目标，每个目标都单独安排计划，目标中的任务也不多，大概2周就能完成的量，然后一次只做一个目标，完成了再做下一个。通过这种方式，增强大家的目标感，让工作更聚焦。（如下图）
将项目划分为几个阶段目标，一次集中完成一个目标
尝试了这种新的管理方法后，一个月下来，能明显感觉到团队效率有所提升，大家更有干劲了，需要加班的情况也越来越少。
但随之又产生了新的问题：
由于制定计划时每个任务的工时都是预估的，加上有紧急bug需要修改的情况，或是用户反馈需要尽快解决这种突发性事件，很难保证目标可以按原计划完成。
为了让目标能够按时完成，我每天早上到公司，都会先开20分钟左右的站会，总结一下前一天的工作，同时制定当天的工作计划。
一方面，明确每个人当天的工作内容，让大家的工作目标保持一致；另一方面，根据目标的进展情况及时调整计划内容，确保计划的可完成性。尤其是在前期，大家对预估工作量都不太熟练的情况下，更需要及时调整目标。
如果无论如何目标中的任务都没有做完，我也会结束掉这个目标，将未完成的任务移至下个目标中。
前面也提到了，开早会时很重要的一部分内容就是明确每个人的当天工作内容。当然，明确不能只是嘴上说，管理是需要落到笔头上的，一定要有记录。
但问题是，在本身已经有了一层目标计划的前提下，如何在计划中再做一层计划？而且，管理层级过深的话 ，查看起来也不方便。
这着实困扰我很久，后来用了列表+看板切换的方式来做，才将这个问题解决。
先在列表中将目标计划制定好之后，再按流程将看板分为待处理、进行中、已完成三个任务栏。目标下所有任务先分配到“待处理”中，早会时，我会将大家当天要做的任务统一拖入“进行中”。
这样做有两个好处：列表模式更方便添加任务，制定目标计划；而对于执行的人来说，看板模式让他们只需关注“进行中”的任务就好，不会被目标中的其他任务所干扰。
选择当天要完成的任务，拖入“进行中”
但这个方法有一个局限。
对于列表和看板两种模式都支持的工具，适应性会很好；若只有看板，加上目标管理也可以用，但制定计划时体验性稍差；如果只有列表模式，由于本身层级太深，不建议用此法。
另外一个比较难解决的问题，就是bug管理。
之所以说它难，是因为产生bug这件事本身是不可控的。就像打地鼠游戏一样，你不知道它们会在什么时候蹦出来，也不知道一下会蹦出多少来，你还不能不理，否则它跟你玩game over。
因此，开发人员经常得放下手头工作去处理这些活蹦乱跳的“地鼠”，这非常影响进度。
要解决这个问题，我就得避免将bug与任务放在一起，否则每天都有新bug进入当前目标，我就永远也别想完成它了。
我一般会将bug与计划分不同的项目管理。测试先将bug记录在单独的项目中，标记一下bug的紧急程度，回头由我来决定哪些bug可以进入到当前目标中优先处理。
在制定目标时，我也会预留出1到2天的时间，专门处理突发事件和bug，具体时间要看实际的bug产出量和紧急程度而定。
将需要修改的bug添加到目标计划中
有时候会出现这种情况，直到产品上线，项目中还会有上百条bug没有解决。
其实这是很正常的情况，我不会妄想将bug都处理完，因为bug是永远处理不完的，只要保证它们不会影响功能和稳定性，那么这个产品本身就是健康的。
这也是bug单独管理的另外一个原因，避免被这些“场外因素”打扰。
最后我们来说一说，为什么目标一定要完成这个问题。
其实写到这里，大家已经能够发现，上面写的这些内容，都是为了达成一个目的：完成目标。大家可能会问，为什么不惜调整计划也一定要保证目标完成呢？
其实原因很简单：只有团队目标按时完成了，大家才能把目标当做切实的标准去看待。
虽然一开始，由于目标任务量设定不够合理，或是bug产出过多，可能会导致一些任务无法完成。但只要坚持下去，你就会发现，目标制定会越来越合理，遗留的任务越来越少，完成的目标越来越多。
它会由一种仪式变成一个标准，大家在完成任务时会不断产生成就感，让大家专注于眼前的目标，并将这种高效的工作状态一直保持下去。
如此，节奏感就自然而然建立起来了。
昵称*
E-Mail*
回复内容*
回复 ( 4 )
1.分期。
每期PM设计三周，研发三周，测试一周。
这样可以三周上一次线，如果你有两个Team，可以做到一周半上一次线，如果你有一个Team，可以做到一周上一次线。
2.目标。
确定每一次需要假设和验证的目标。所有的产品在未经使用之前，一切的结果都只能是假设。
必须要明确自己倒底想要验证什么，快速的去看，真实的结果跟自己的预测是否一致。
所以跟这个结果都不符合的，全部抛掉。
3.流程。
提前制订好必备的流程体系。
提前教导团队遵守流程。
没有流程就是扯淡。
4.睡觉。
或者是做白日梦。
1.远见，产品的目光是1年，其实好的产品可以看到3年后的产品是什么样子；
2.视野，产品的目光是整个市场，整个市场对产品的影响是产品不得不思考的；
3.资源，产品要清楚有多少资源，尤其是可控的资源；
4.节奏，产品只要给开发讲3个月内要做的事情就好了，这样开发才能专注在开发上，产品则是控制节奏的人。
至于你自己的节奏感，呵呵，想想你的目标是什么吧，大象放进冰箱中到底需要几步？每步花费的成本多少？带来的收益多少？想明白就好了。
多谢邀请。
但是因为前几天生病了，所以一直没有回答。
这个问题如果要回答，需要先解决掉目前国内软件行业的几个错误观点：
1，项目管理至上论
很多人认为当了项目经理就可以不写代码，所以，很多本来对代码没有兴趣的却为了赚钱或者其他原因进入软件行业的人就热衷于将自己变成项目经理。
结果，这些人当了项目经理，却没有实际足够的代码经验，就出现了大量的瞎指挥和乱指挥，项目组内一地鸡毛，事情讨论不清楚，任务执行无结果。
还有些人拿着自己考出来的证书就认为自己应该当项目经理，然后照本念经，或者言必称某经典如何如何，某经典中某牛人团队就是如何如何操作的。
这都是错误的行为和认识。
2，项目管理无用论
然后就有了一批人认为，我们自组织就可以了，不需要项目经理。
然后项目中想做什么做什么缺少规划，缺少管理，缺少控制，缺少推进，开起会来人人都是牛人，看看项目却不知道进展几何。
————————————————————————————————
真实的项目管理中，项目经理是整个项目中最累的人。
于是，某位实际上没做什么事情也很清闲的项目经理就据此说，看到了吧，其实我最累！——我想对他说，其实你最雷！
大家都知道的默认规则，项目失败，首先的责任人就是项目经理，但是很多人并不知道，为什么一定是项目经理，这是因为很多人不知道项目经理到底是做什么的，负责，负责什么，只有负责两个字是没用的。我曾经给一家公司做内训的时候写过一个项目经理的工作任务内容，涉及到每天，每周的工作内容，而实际上，那个内容也是不够完善的，但是有这个为基础，就可以好很多，至少可以清晰一些。
每日工作任务：
p组织站立会议（计划，执行）
p进行成员任务的分析/调整（执行）
p组织必要的评审和讨论（执行）
p进行每日工作情况确认（计划，执行）
p异常任务处理和临时安排（计划，执行，风险）
p了解每个成员的任务执行情况，随时把握进度和可能遇到的问题（计划，执行，风险）
p给自己安排的研发任务（执行）
p每天检查配置库情况，确认执行与计划的匹配度（验证）
p其他事务（诸如招聘以及其他与项目任务无关的事情）
每周工作任务：
p周五拿到每周记录汇总后进行周报撰写，周一提交；
p制定/调整项目当前/下一个迭代计划，并跟进执行；
p分析遇到的项目风险，并针对风险的状态进行处理；
p项目紧急风险和特殊情况的及时汇报和沟通处理；
另外，项目启动，关键节点，项目结项，验收测试试运行等不同的阶段点也都有不同的任务内容。
注意：以上任务列表是需要根据你的具体管理方法结合起来修改的，建议最好不要直接照搬。
每周的任务中就是为上一周做总结，然后为下一周制定共同目标，控制节奏。
而每周的计划是在迭代计划中的，这需要在具体的迭代中制定共同目标，大家会在一个较大的视角范围来考虑项目的进度和自己的任务组合形态。
而每天的任务是检查控制较小的进度偏差，以便于发现后尽快调整，并对人员和任务进行重新组合，以期避免更大的问题，而很多项目经理往往会忽视这一点，结果造成更大的问题，也使得每周的计划无法到位，更大的迭代计划也无法获得有效执行。
今天先写这么多，后面有时间再来补充。
想要形成节奏感，首先要让工作更聚焦。工作明确了，大家劲儿往一处使，就会很容把目标实现，而且沟通上也会减少很多阻力。
伟大领毛主席曾说过：面对强大的敌人时，我们要集中火力，各个击破。
当然，光有主张是不够的，还要有实现方法。
就以我个人的经历来说吧：
我记得自己第一次负责项目时，踌躇满志，每天认真整理需求，把任务列表塞得满满当当，为了按时完成产品上线的目标，要求团队加班加点赶进度，梦想着有朝一日成为CEO，迎娶白富美，走上人生巅峰。
但这种方式非但没有加快进度，反而让团队做起事来变得更拖沓了。
后来一位比较有管理经验的前辈对我说了这么一句话：实现不了的目标，等于没目标。
我想想，确实是这样的。定那么大个目标，每天都不知道做到哪算完，一想后面还有那么多……去他大爷的，老子还不如逛京东淘宝！
所以说，团队效率低下的主要原因在于没有明确的目标感，导致大家最终失去了工作热情。于是我就想，如果把冗长的任务列表变成一个个可完成的小目标，会不会能让大家更有干劲儿呢？
随后，我开始将项目拆分成许多个小目标，每个目标都单独安排计划，目标中的任务也不多，大概2周就能完成的量，然后一次只做一个目标，完成了再做下一个。通过这种方式，增强大家的目标感，让工作更聚焦。（如下图）
尝试了这种新的管理方法后，一个月下来，能明显感觉到团队效率有所提升，大家更有干劲了，需要加班的情况也越来越少。
但随之又产生了新的问题：
由于制定计划时每个任务的工时都是预估的，加上有紧急bug需要修改的情况，或是用户反馈需要尽快解决这种突发性事件，很难保证目标可以按原计划完成。
为了让目标能够按时完成，我每天早上到公司，都会先开20分钟左右的站会，总结一下前一天的工作，同时制定当天的工作计划。
一方面，明确每个人当天的工作内容，让大家的工作目标保持一致；另一方面，根据目标的进展情况及时调整计划内容，确保计划的可完成性。尤其是在前期，大家对预估工作量都不太熟练的情况下，更需要及时调整目标。
如果无论如何目标中的任务都没有做完，我也会结束掉这个目标，将未完成的任务移至下个目标中。
前面也提到了，开早会时很重要的一部分内容就是明确每个人的当天工作内容。当然，明确不能只是嘴上说，管理是需要落到笔头上的，一定要有记录。
但问题是，在本身已经有了一层目标计划的前提下，如何在计划中再做一层计划？而且，管理层级过深的话 ，查看起来也不方便。
这着实困扰我很久，后来用了列表+看板切换的方式来做，才将这个问题解决。
先在列表中将目标计划制定好之后，再按流程将看板分为待处理、进行中、已完成三个任务栏。目标下所有任务先分配到“待处理”中，早会时，我会将大家当天要做的任务统一拖入“进行中”。
这样做有两个好处：列表模式更方便添加任务，制定目标计划；而对于执行的人来说，看板模式让他们只需关注“进行中”的任务就好，不会被目标中的其他任务所干扰。
但这个方法有一个局限。
对于列表和看板两种模式都支持的工具，适应性会很好；若只有看板，加上目标管理也可以用，但制定计划时体验性稍差；如果只有列表模式，由于本身层级太深，不建议用此法。
另外一个比较难解决的问题，就是bug管理。
之所以说它难，是因为产生bug这件事本身是不可控的。就像打地鼠游戏一样，你不知道它们会在什么时候蹦出来，也不知道一下会蹦出多少来，你还不能不理，否则它跟你玩game over。
因此，开发人员经常得放下手头工作去处理这些活蹦乱跳的“地鼠”，这非常影响进度。
要解决这个问题，我就得避免将bug与任务放在一起，否则每天都有新bug进入当前目标，我就永远也别想完成它了。
我一般会将bug与计划分不同的项目管理。测试先将bug记录在单独的项目中，标记一下bug的紧急程度，回头由我来决定哪些bug可以进入到当前目标中优先处理。
在制定目标时，我也会预留出1到2天的时间，专门处理突发事件和bug，具体时间要看实际的bug产出量和紧急程度而定。
有时候会出现这种情况，直到产品上线，项目中还会有上百条bug没有解决。
其实这是很正常的情况，我不会妄想将bug都处理完，因为bug是永远处理不完的，只要保证它们不会影响功能和稳定性，那么这个产品本身就是健康的。
这也是bug单独管理的另外一个原因，避免被这些“场外因素”打扰。
最后我们来说一说，为什么目标一定要完成这个问题。
其实写到这里，大家已经能够发现，上面写的这些内容，都是为了达成一个目的：完成目标。大家可能会问，为什么不惜调整计划也一定要保证目标完成呢？
其实原因很简单：只有团队目标按时完成了，大家才能把目标当做切实的标准去看待。
虽然一开始，由于目标任务量设定不够合理，或是bug产出过多，可能会导致一些任务无法完成。但只要坚持下去，你就会发现，目标制定会越来越合理，遗留的任务越来越少，完成的目标越来越多。
它会由一种仪式变成一个标准，大家在完成任务时会不断产生成就感，让大家专注于眼前的目标，并将这种高效的工作状态一直保持下去。
如此，节奏感就自然而然建立起来了。