1 工作量估算
对于工作量估算很多项目经理(老板)喜欢用数学公式来计算，可能数学公式更加的客观和科学，ok,，看看市面流行的计算方法吧，最常见的是基于代码行的数学模型，那么这里存在不少问题，工作量估算主要是为了在项目进行中进行有效的项目监控，那么软件开发尚未结束，谁知道最后的代码行有多大?代码经常会被修改，那么修改的代码算不算?如果算，那么代码修改越多难道能说明工作量越大?代码效率的区别也是很大的，假如一个10行代码可以实现的东西被写成50行，难道能客观的Cye.com.cn反映工作量?还有2种比较高级点的方法是基于功能点和COCOMO的方法，那么我想问的是它们的公式中的系数该怎么定?那么不少咨询师忽悠我说，根据自己的实际情况来定呗，那么我想问的是，算命是迷信，电脑意味着科学，那么用电脑算命算不算迷信?所以我是主张这里还是要靠人的经验来估算，大家可以在项目周会上对工作量进行充分的估算，在估算时要同时考虑到项目执行的难度，根据经验给出合理的评估。
2 任务分配
大多数的做法是将整个项目划分成一个个可以独立执行的原子任务，这些任务要划分优先级和难度，至少心理有个数，并且每项任务要制定负责人。那么问题就出在这个任务分配上了，软件开发是一项智力创造的活动，如果按CMMI假设的那样，在分配任务时忽略人的因素是万万不可取的，我就有血的教训，不久之前做一个ruby的项目，然后开始在公司内部随便抓了几个有点ruby基础的人，也没太顾忌别人的想法。做着做着，觉得他们有点心在曹营心在汉，平时还是抱着本 thinking in java看，做ruby也是在敷衍了事，结果是代码质量不行，需要大规模的修改。当然按理说员工应该服从公司的安排，做一样就要做好一样，但员工也有员工的规划，你去叫他做他压根就不喜欢的事只能说明管理有问题。
另外还有一个普遍性的问题是能者多劳，有个朋友刚进公司动手能力很强，也非常的积极，每次做项目都分给他最难最累的任务，做着做着也就厌倦了，这时老板会忽悠你说，你能力强，要挑起公司的大梁，以后公司壮大了给你个什么职位，我觉得这就是在扯淡，这就是我经常见到的忽悠式的管理，很多管理手段完全靠人情，很多人都是在这种环境中被忽悠长大，到最后怎么样?被忽悠了几年还不是另谋高就了，所以指望人情化管理的公司很难长大。我觉得该讲原则的地方就要讲原则，在任务分配上给能力强的分配少而精的任务，而且要考虑到员工自己的想法，有些人想做java架构师，你叫他做oracle dba就不合适，有些对ui设计感兴趣，你叫他做系统分析员也不合适，有些人就喜欢搞技术，你硬要叫他做管理也是不合适。
|
