别拿软件不当工程

现实与理想总是有差距，当初我认为这么一个企业是完全有实力建立自己的工程体系和方法的，实际上还完全处于吹牛阶段(CMMI3)。

而事实上不仅仅要有实力还要有能力。每个项目都做的乱糟糟的！作坊式的生产工艺。也许部门也不想这样，因为上面的更大的领导也许根本不关心，只要能干活儿就行了！所有的人都在强调，很多客观因素是无法改变的。没人有试图改变什么，大家都在改变自己，无论是心态还是方法等等。领导的意思很明了，别哀求什么时间不够用，你们还年轻，很有冲劲，潜力很大，做好主力，当好MT，抗住！

软件开发，是个脑力活儿。有时候重复性工作也比较多，所以程序员也有IT民工的称号。并不是所有的代码都可以重用，coding的同时也留下了思维的痕迹，拷贝-粘贴之余，也要思考一番这个东西怎么做，做成啥？所以人在软件开发当中是非常之重要的因素。我讨厌别人把程序员当成纯粹的code maker来用。人不机器，机器也写不出代码(虽然可以替代一部分吧)。

工程是需要计划、组织、人员、管理等等要素的。

在软件开发当中，其实有一点很重要，就是能够比较准确合理的评估出工程所需要的时间。一个正常的项目，起码要根据工作量和团队的水平，给一个合理的估算。但一个问题是，怎么才能估算准啊？国外好像有人发明了几种数学模型，可以用。但我讨厌用数学。。。呃。不爱计算。如果估算的话，最好是让承担任务的程序员来估算，而且不要给他压力，这样应该能够得到一个比较合理的值。但前提是，要先大概分析下要开发的东西需要修改或者新增的东西，然后和以往的工作进行一下类比。最好的情况是，能够在项目进行中，如果发现了偏差可以进行修正。这个因为有些项目是难以修改DeadLine的，所以可以会有些不切实际。

在建筑领域，交付时间是由甲方来定的，软件也是一样，一般都是甲方定好的。相对于建筑，软件的不确定因素太多，且大多时候甲方都是急功近利，从而导致了很多不爽的事情。建筑方面，由于受限于资金流等因素，所以甲方有可能会把交付时间订的比较长，而施工单位也可以通过简单的增加人员的方式来提交工程速度。而做软件一般需求都比较紧迫，项目中也很难通过简单的增加程序员来提高开发速度。另外对于估算工期，建筑方面也很好估算，主体结果的施工，最快7天左右一层，这个要受限于混凝土的凝固速度。而做软件就没这么早的福气了，更多的团队都是期盼，计划能够偏差不大就ok了，实在不行，只能通过加班来处理。

据说印度的软件公司，很强大，工作量可以细化到比较小的粒度，这样可以相当准确的估算出时间。从而减少了加班的出现。

所以，估算工作量，指定交付时间，怎么也要在需求分析之后。否则，就是胡诌了。

关于加班，除了给自己打工的，恐怕没人愿意加班。没有补偿的加班更会打击团队的士气与信心。出现了加班也就意味着出现了偏差，所有人都想努力挽回，可如果偏差太大，再也无法挽回……

不写了，累了。

p.s.  nnd,每个项目都要靠无休止的加班来完成，哪个X订的计划。