前几天跟组员们讨论11月的绩效目标的时候，发现有些组员存在一个问题：缺乏计划性，
总是觉得反正事情都是要做的，按部就班一点一点完成，做到哪里算哪里就好了。
有下面两个例子：
1）问曰：“11月准备做什么？”
答曰：“自测，改BUG”
再问曰：“改到什么时候？”
又答曰：“不知道，改完为止咯。总会有新BUG让我改的。”
2）问曰：“11曰准备做什么？”
答曰：“跟客户讨论需求，然后实现。然后给他看，然后根据意见做修改。”
问曰：“能够在11月定个大概的工作计划么？”
答曰：“不能，我怎么知道客户会让我做什么，又怎么能提前知道这项任务的工作量呢？”
＝＝＝＝＝＝＝＝＝＝＝＝＝
如果在开发之前制定好了测试用例测试框架，甚至写好了验收用例，哪里有改不完的BUG?
改到这个软件能验收能回款为止，就是停止修改BUG的时候！
我们又不是客户的工具，怎么能他说什么就做什么？怎么能被客户牵着鼻子走路？怎么能
沦落为客户的软件代工？
再说，我需要的工作计划跟开发计划完全是两码事，这年头，除了编码，一个软件的形成过
程还包括“需求调研、需求分析、编写测试案例”等等的。
我希望组员们能够认识到自己在做什么，目标是什么，头脑清醒地进行工作计划和工作安排，
例如第二个组员的工作方法可以是这个样子：
A 过几天跟客户开会讨论需求的时候说明：我们响应新需求的周期是一个月，也就是说，有
什么需求，你可以提，但是如果不是什么特殊情况，一般会在下个月的计划中安排开发，因
为这个月的开发计划已经安排好了。
B 讨论完需求之后，做好会议纪要，整理他们的想法并估算实施的工作量，发邮件给客户要求
确认。待确认完了之后才正式开工。如果客户到时候不认帐，或者提不同的想法，将邮件记录
拿出来作为证据。
===========================================================
eXcel (一颗色儿)·2006-11-09