关于开发计划

[soaringbird]

各位每月做计划的时候的精度是多少？有没有精确到天？就是把这一个月的每一天的任务都分解出来，而不是只是一个月的笼统计划描述。包括给自己定的计划和给组员定的计划。

[soaringbird]

我们也是这么做的，月计划下面有周计划、周计划下有日计划，当周的计划有的也精确到了小时，但是现在新来了一个总，要求做一个月的计划的时候就要精确到天，我是对这一点有异议，一个月这么长的时间，变数太大了。

[wanghui0380]

做计划前先要有计划保证才成

不然单纯的计划根本无法完成，所谓计划跟不上变化。所以首先要保证的是，如果计划有变动如何去协调，不能把计划死死的压在程序员头上

1如果计划做的很死，很招程序员恨
2。如果计划本身有毛病或者计划又变动，那么根本无法保证进度，这个计划做了也白做，无法执行
3。如果计划做的很死，而且没有一个核心设计师或强力项目经理，那么程序员只会快速完成自己东西，他们根本就不会考虑其他事情（因为计划往往跟绩效跟钱相关，他们才不会考虑项目能不能完工，既然你把计划死死的压在他们头上，那么只好优先保证速度，而不是质量。只要他自己的工作完成了，其他的问题都是你这个做计划的人，他们会说你交给的我的都完成了，如果项目失败不是我的原因，那是你这个做计划的人的毛病）

[flowerspring]

定时，定量。因地制宜。~

[wuyq11]

月周天都制定计划，并用相关图表显示执行进度
但每个进度留有余地
每项任务完成的先后顺序以及完成的标志性事件都实现编写

[以专业开发人员为伍]

其实单纯空洞地把计划精确到天是不可能的。人家做法，受首先不看绝对事件，而看每一个计划是否已经细化到不超过1天的工作了。如果没有，比如一些人连底层支撑环境都还不知道、连如何使用后台服务平台都不清楚、连所使用的开发工具中到底哪一个组件才适合开发产品、甚至连自己的产品的最基本的用户操作行为尚未说到位，等等，那么所谓精确到天的计划就是假的。相反，如果你把一个产品划分为20个任务，每一个基本上在4、5个小时可以确保完成（并且让行家开会你来答辩，评估你说的是真话），那么按天的计划易如反掌，根本不用可以计划只要随便前后摆一摆位置就能安排出来的。

我精确到天，是因为我基本上可以保证按时完成。这种计划过程就像拼图一样。如果强行将任务分解，就会感到勉为其难，那种所谓精确到天的计划就是骗人和害己的。

[以专业开发人员为伍]

每一个任务就好象拼图 还是 每一个任务都硬性分解？这是天壤之别的，是不同的项目管理风格。

[amandag]

[Quote=引用 9 楼 sp1234 的回复:]
我精确到天，是因为我基本上可以保证按时完成。这种计划过程就像拼图一样。如果强行将任务分解，就会感到勉为其难，那种所谓精确到天的计划就是骗人和害己的。
[/Quote]

精确到天（一般是下一周的计划）的前提是PM对组员了解，而且和组员沟通的结果。

不过再现实情况下，PM压任务或者组员明明2天能做的，说一周也是经常的事情。

[newnew003]

[Quote=引用 6 楼 wanghui0380 的回复:]
做计划前先要有计划保证才成

不然单纯的计划根本无法完成，所谓计划跟不上变化。所以首先要保证的是，如果计划有变动如何去协调，不能把计划死死的压在程序员头上

1如果计划做的很死，很招程序员恨
2。如果计划本身有毛病或者计划又变动，那么根本无法保证进度，这个计划做了也白做，无法执行
3。如果计划做的很死，而且没有一个核心设计师或强力项目经理，那么程序员只会快速完成自己东西，他们根本就不会……
[/Quote]

兄弟好有经验!

[以专业开发人员为伍]

[Quote=引用 11 楼 amandag 的回复:]
精确到天（一般是下一周的计划）的前提是PM对组员了解，而且和组员沟通的结果。

不过再现实情况下，PM压任务或者组员明明2天能做的，说一周也是经常的事情。
[/Quote]

如果招聘一个人，你就了解他，这是肯定不现实的。而且恰好相反，我想现在公司招聘的80%以上的人都是自己不能立刻理解、喜欢的类型的。

最近我们有3个小功能，我让两个人新人写了1个半月的文档（当然丝毫不是八股文，而是务实到甚至其它同事都认为“甚至一点设计完美都不追求”的地步）。其它行家1个月前就希望他们开始编码，可是在我看来，他们写东西达不到基本的程度，我宁可最终换人，也不需要现在就写代码。

[以专业开发人员为伍]

因此，“PM压任务或者组员明明2天能做的，说一周也是经常的事情”这其实是讽刺PM。而我其实也是重点针对“不同的项目管理风格”来讨论，我先不想评论程序员多么喜欢找理由之类的。因此所谓这个计划能不能做到，丝毫也不能只是寄希望与程序员自己，而要从PM的素质抓起的。

[以专业开发人员为伍]

[Quote=引用 12 楼 newnew003 的回复:]
兄弟好有经验!
[/Quote]

呵呵，给你提供了统计自己的PM的理由了吧？！

[soaringbird]

[Quote=引用 13 14 楼 sp1234 的回复:]


[/Quote]

有些时候也不是PM的问题，我今天发这个帖子是因为公司新的规定，要求给每个人的任务都要安排到天（一个月的），这只能强行将任务分解下去。当然谁（除了老板和做这个规定的人）都知道这是不现实的
其实我的想法和你的差不多，但是有的人就是希望看到每个人都在忙忙活活地干活，而不管他干得怎么样，结果怎么样，甚至看结果也只是看表面的结果。

[newnew003]

[Quote=引用 16 楼 soaringbird 的回复:]
有些时候也不是PM的问题，我今天发这个帖子是因为公司新的规定，要求给每个人的任务都要安排到天（一个月的），这只能强行将任务分解下去。当然谁（除了老板和做这个规定的人）都知道这是不现实的
其实我的想法和你的差不多，但是有的人就是希望看到每个人都在忙忙活活地干活，而不管他干得怎么样，结果怎么样，甚至看结果也只是看表面的结果。
[/Quote]


中国就是这样,很多都是门面过去就行了,哪怕你做的是垃圾,只要他看到你是勤勤恳恳的他就觉得有希望...

[newnew003]

[Quote=引用 13 楼 sp1234 的回复:]
引用 11 楼 amandag 的回复:
精确到天（一般是下一周的计划）的前提是PM对组员了解，而且和组员沟通的结果。

不过再现实情况下，PM压任务或者组员明明2天能做的，说一周也是经常的事情。


如果招聘一个人，你就了解他，这是肯定不现实的。而且恰好相反，我想现在公司招聘的80%以上的人都是自己不能立刻理解、喜欢的类型的。

最近我们有3个小功能，我让两个人新人写了1个半月的……
[/Quote]

sp123 我是不是在哪里见过你这头象?是不是在javaEye?

看了大哥的评论,小弟受教了,搞程序的还是要 有责任感 才行,这样才能做大项目,而不能混过去就算了,哪怕是当前项目急着招人而来了几个不合要求的人

[yixianggao]

建立 lz 参考敏捷软件开发的计划部分！

[coleblack]

计划要根据实际的需求，细分模块成为最小单位的任务，然后将任务按小时来计算，每周按照模块实现的先后顺序自动周计划，周计划按照天/人来计算，当然计划定的不要太死，每个功能要抛出点时间。

[soaringbird]

[Quote=引用 18 楼 newnew003 的回复:]

[/Quote]
的确如此

[zjx198934]

个人觉得计划如果是一个定出来的计划！此计划不用看绝对不是最准确的，团队一起根据确认好的需求制定的计划才是好的计划，想一次把整个项目计划都细分到天/人，觉得不太好也不够准确，应为唯一不变的是‘变’！先把整周的计划分为天，然后再项目开展的过程中足见把整月的计划分为天已经很好了！

[yaazz]

我是在既定期限内根据功能块划分的，当然是大模块套小模块。
将小模块计划精确到天，甚至小时
其中还要综合考虑预留未预见因素所用时间，计划也是根据检查结果不断变化的
具体的操作需要有对全局的把握，对整个项目以及组员的特点了然于胸，才能游刃有余的控制项目制定计划

[hongmaohouzi]

要划分任务单元，结合项目的关键路径来分，项目的总体工期不能延长，在这个关键路径上可以调配任务，将项目划分为几个大任务模块，再把大任务划分为小任务，再将小任务划分为功能包，每个功能包需要多长时间，根据你手下人的能力来定，每个功能包最长不要超过3个工作日(比较好监控)，有些任务很简单，可能就是1天，有些任务比较复杂，可能是5天，能细化的任务尽量细化，这样，项目经理才更好跟踪与监控，但计划不要太急，否则，你手里的弟兄会承受不住的。