软件项目管理实践之日计划

每个团队或每个公司的衡量标准都不一样。
最好是结合实际的情况。
工作量和效率的度量就不需要说了吧。

质量是比较难以衡量的，在我的项目组是提倡可交付成果。根据返工的情况来进行量化。
当然也可以根据缺陷率等量化，通过缺陷率最麻烦的是只有到QC或测试阶段后才能够确定质量。
对于不同的任务可能会有不同的质量度量标准。
比如设计文档类的，一般我会要求由设计者当众讲评来取代评委评审。
当众讲评的效果要比评委评审要好。
可以根据需要修改点的多少和修改的级别来衡量任务的质量。
传统的做法是以文档的页数等来进行度量。
但是个人的经验是，召开评审会议，由设计者当众向项目组讲解，任何人都可以提出疑问。
这样的效果明显要优于由专家单独进行评审然后给出评审意见的方式。

你们目前是什么方式？效果如何？亮点在哪里？能否一起探讨？

那按照和月底考核的制度， 修改点多级别大就得分低，就可能被扣钱？
那如果当事人说，他的设计模块难度大，修改点自然比较多，别人设计模块难度低，修改点自然比较少。
那这个制度又怎么执行呢？

至于工作量和效率的度量标准问题。
你们能以什么来测算呢？代码行数，User Story的个数，Task的个数，功能点数？
方便的话，望能解答的一下。

我们是传统的开发方式，因此想着寻找一个好点的开发方式。
我觉得在项目的一个迭代开始的时候，项目经理应该召集相关人员把这次迭代的所有用户故事写好，并且对每个用户故事进行工作量评估。因此在开发过程中，项目经理只需要根据每天的完成情况，对用户故事进行调整，然后分配。这样的话，项目经理的工作量还是小一点。

首先，项目不可能没有计划，这个不用说了。但是日计划和计划还是有区别的。
日计划并不简单的像你说的只是项目计划的计划，个人感觉他是在理想状况下对项目计划的极限细化。
管理成本过高首先是对于项目经理的管理成本。
以一个10人的项目为例吧。
从早间例会开始吧，分配当日任务，那么这个任务是什么时候由管理者确定的？那么我回溯到前一天。
前天下班前提前20分钟进行检查例会，那么只有当你检查完工作情况时，才能给出下一步的计划。
假设提前对工作做了计划，下午例会检查时发现任务因为各种情况没有完成，需要调整。
好，再假设你提前对工作做出的计划已经包含了各种各样的异常状况出现的应对办法了，那么这样一份计划的时间是多少？作为管理者你需要投入多少时间在一个每日计划上。
好，继续向下假设你可以很快的做出一份十分详尽的计划，这个计划包含了各种各样异常状况的解决办法，很详尽，那么这样一个管理者每月的工资会是多少，吧这样一个管理者放在一个项目中的成本又是多少？这样一个项目又能赚多少？这个是被习惯性忽略的一个问题。很多完美的项目不能按完美轨迹运行就是这个原因。
好，在继续，既然这个管理者成本很好，那么我们让多管理几个项目吧，那样平均成本不就低了，当一个管理者同时带几个项目的时候，他能像带一个项目那样那么了解需求那么容易的给每个项目做日计划吗？恐怕很难。
以上所以的假设还都是在项目计划可以确定的情况下的，但是事实呢，很多项目你接受的时候你就会发现，项目的需求根本确定不下来，项目的计划根本是随时在变的，这个是客观存在的。那么日计划的复杂程度会成几何级上升。

的确，日计划是一个很好的提高效率的方案，但是很多时候，我们需要考虑这个计划执行的环境，毕竟只有最适合的方案，没有最好的方案。这个在pmp中有两个元素是一只被提到的，企业环境因素和企业的资产。
所以对于日计划，个人的态度是，在特定条件下的项目，实施日计划是可以极大提高项目效率的。不过对于成本考虑比较重的项目，例如外包项目来说，还是感觉细化的功能点任务计划比较好点。

只能是以任务为计划项，定时跟踪任务执行情况。
比如一个3天的开发模块，安排下去后，你不可能要求张三今天完成33%，明天完成33%，后天完成34%。
可以在任务下派时候，通过合理分析计算，得到一个正常的用时参考。
也许开头用时长，后面用时短。
所以，每天去考核完成进度，个人以为有些矫枉过正了。

另外，这些都是要投入相当的管理成本的。
单单是项目经理肯定不成，需要一干人等配合检查，来确定任务的进展是否正常。

我在项目中的规模的估算是以人天为单位的。

如果只是根据故事分配工作，粒度太粗了。在成熟度比较高的团队可以这样做。
最好还是把故事再分解为任务。这样便于控制项目和追踪进度

谢谢你参与讨论。
你说的这些是一些项目经理经常挂在嘴上的托词。
我经常叫一些项目经理做一些日常管理：（如及时变更计划，使计划反映项目最真实的情况），他们经常挂在嘴上的就是：“没有时间，我还要写代码，开会。”
反过来想想，如果一个项目经理把时间花在写代码(不是说项目经理不可以写代码，我也经常写，并且写得不比其它人少)，开会等，而无暇顾及了解项目的真实情况，不去及时调整计划。这真是一个让人哭笑不得的事情。那么我们还要一个项目经理干什么？我们的项目还需要管理？当项目失败了，他们总会找一些理由：“需求变更，人员水平，时间紧急等”。如果你是一个成功的项目经理，这些问题在产生的初期就要被你及时发现并处理了。要不然，你这个项目经理就没有价值，没有起到作用。
这有些本末倒置了。什么是管理成本？即然公司指定了项目经理这个角色，给了你这个位置，公司就已经承受了这个成本。公司是要你把项目做成功，而不是失败了之后找理由,你的工资并不会因为你多做一些管理工作或少做一些管理工作随之增加或减少？会吗？你所谓的管理成本是你自己想不想做事的成本，与公司无关。
可见，项目经理首先需要明白自己该做什么？而且还要明白自己最该做什么？
如果一个项目经理没有把需求范围，时间，成本，质量这几个方面控制好，写再多的代码又有何用？个人能力再强又有何用，只能说明他更适合去写程序，做技术，而不是管理。

好了，至于说管理多个项目。如果你连一个项目都管理不好，都不能做到利益最大化。老板又怎么相信你可以带多个项目,老板不会是傻瓜。如果真是这样让管理一个项目都管理不好的人去管理多个项目，那岂不会眉毛和胡子一把抓？最主要是当你身处一个环境和位置时，要能在瞬间知道自己该做什么？最该做的是什么？
日计划就是让你最真实的了解项目的情况，及时发现风险和对项目进行调整。
永远要记住：“计划的调整本身就是计划的一部份”
而不是，在项目启动时做了一个计划，到结束时也是这个计划。
很多项目在运作一段时间后，计划就已经没有用了，项目处理无计划运作中。

关于管理多个项目，首先你要能够管理好一个项目，才有说服力去管理多个项目。
笔者同时管理多个项目，而且日计划执行得非常好，项目的效果也非常好。
当你在管理多个项目时，你需要去做每一个细节？那是不需要的。
关键是要把整个方法传授给你的团队，指导他们怎么去实施。
同时需要控制关键点,比如范围
会不定期的参与不同项目组的晨会
每天查看他们的日计划执行情况等，识别项目的风险。并不需要你什么都去做。你能力再强，也不可能什么都去做。
关于需求变更与日计划。越是变更越频繁的项目，日计划起到的作用就越大。
因为调整的频率高了，也就是应变及时了。不是吗？

日计划强调的是可交付成果.
并不会是33%,33%,33%这个很难以量化的目标。

三天开发一个模块。这正是传统的项目管理的任务分配方式。
你是项目经理，你让一个人用三天去开发一个模块，你心里有没有底，这个结果是什么？
1、三天后能不能够完成？
2、三天后完成的质量是怎么样？（代码写完而已，没法调试？调试通过，但是问题较多？调试通过，但是业务理解错误）
这些你都是无法控制的。


如果你是程序员，项目经理让你三天后完成一个模块，你会怎么做？
1。第三天开始动工，什么时候完期还真难说
2.第一天就开始动工，一天完成工作，第三天提交
还有多种情况。

这样的任务分配，对于是否能够按期，保质完成，这就要看程序员的素质了。
还有，风险没有办法控制和识别。

如果再进行细分：
模块XX，预估时间3人天(假设分析和设计已经完成)
  dao，service编写，并完成单元测试  1人天
   action,jsp编写 1人天
   集成测试，能够联调成功 1人天
我这里只是举例说明，具体的分解方法可以根据项目组的开发习惯而定。
发果进行了这样的分解，就可以进行更好的控制。
当第一天下班前，dao和service代码没有编写完，就要找原因。
如果只是代码写完了，但并没有单元测试通过，就说明这个任务没有完成。需要加班。

日计划就是每天每个人做的任务都是要可以交付的。