这些天事情比较多，本想给写东西无奈时间太紧，没有成文，却又忘在了公司的电脑里面，在此就随意谈谈了。在周四开的会中提出的任务管理办法，我是非常支持的，实际上这些方法，在很多公司都在用（除技术外的管理都很容易去实施）当然了，对于软件行业来说，好的开发管理，还有很多的事情要做。
对于部门领导所关心的开发管理工作无非就是有那么几点：项目是否能够按进度完成，系统是否非常的稳定容易维护，大家工作别太辛苦，并对公司的工作充满激情，当然除了一些管理外，你会更多的还会考虑产品的发展，演变，新产品，新项目等诸多方面。
但实际上即使在大公司很多问题都是存在的而且还非常严重，但是也有些公司的做法值得借鉴，他们都有好的地方，也有不好的地方，我只是例句几个特点。
先说糟糕的吧，记得在我离开呆了三年多的第一家公司后找到了一家新公司（300多人的行业软件公司），这家的管理很有特点，就是疯狂的加班啊，而且以加班为支持，以加班为荣，以加班为判定一个人是否努力，经常一个通宵，我的脖子是真熬不住了，呵呵。很理想化的弄出了一个框架想做产品，实际上无法实现（因为他们更多的也是在做服务），反倒弄的大家在此基础上的开发筋疲力尽，实际上还是在做服务，他们很想做技术，但每个人都是拿来即用,java和.net 混合着来，弄的代码的确很难维护。后来我没有坚持住，在试用期没有过，就与那里的同事跑到新公司去了。
新的公司相对来说还好一些了，这里的特点就是成本意识很强（其他部门俺不知道哦，这个公司开发人员有1500人以上，博客园的"蛙蛙池塘"排名36，也是我们公司但不在一个部门），对中国大环境下的电信软件产业道路认识很深刻，就是做服务，不搞理想化，客户给我们钱，我们就干活，搞出来就行，成本越低越好，没有什么维护架构，不考虑你什么后期什么产品，每个人必须要赚多少钱，技术负责人和项目经理或者说是产品经理有些类似，不管你用何种技术人少做出来就行，掐两头，拿项目和验收，倒也涂个清闲，搞得大家月月外地出差在甲方现场（做服务嘛）。甲方要什么就做什么，没有需求，没有设计，没有考虑，只关心功能，刚开始每个人一个项目工作量不大，大家都还兴致勃勃，有的时候还很闲着（这个公司有一点很受员工欢迎就是OPEN，上班是没有严格打卡的要求的，你什么时候来都行），后来呢，由于服务方式的工作，常常是拉出来就干，而且非常着急，下周就来领导检查啦，必须这周做完，所有人都跟着加班啊，疯狂的搞了一个星期啊，无论怎么“对付”也好吧，反正是实现了，结果呢，到了哪一天，没有消息了，领导没来还是没有看？，做服务就是这个样子，也许在头半个月主动问甲方“有什么需求啊”，甲方还回答“没有”，但是只要一来了就是非常急，后来每个人的身上是项目众多，由于快速做的东西很乱，重构大家又觉着没有必要，因为这个东西也许就是领导看一次的东西（领导也不安排这个时间给你）能用就行。不过我到还没有遇到领导安排做.net 又是java 技术的那就崩溃了，如果技术人员要成长，完善一种技术系统的知识树是很漫长的。这样的公司部门人员少而且精，但是必须程序员的能力要稍微强一点，因此这里的领导就接受了以下这个循环（高工资=高能力员工=高质量服务=高回报=高工资）反过来就是低的。
最后一个就是我呆了3年多的第一个公司了，这个公司是一个机械公司，在2008年软件部门才单独的成立了一个公司，也就是这个公司的倒闭我离开了那里，这个公司是做混凝土行业的，这个行业的甲方都是些个体，而且软件这种东西本身对于他们的生产来说就是一个附属服务，导致这个行业的软件价位很低，做项目成本又很高，无法赚钱，很不好做，想赚钱就只能做成产品，真正的软件产品。
新公司成立了（也许是被忽悠的），老板租房子装修买设备投不少钱，最后证明了还是失败了。不过在开发管理方面的确有很多值得去借鉴的。
以前这个公司的领导很强不过他们都是机电专业的，软件管理都是门外汉。这时候就来了一个技术总监，这个技术总监大概有45岁左右的年龄，很强，不是因为他的技术强，而是软件管理流程很强，理的很顺，很协调，很轻松，什么东西都是先想好了再做，绝没有（也不允许）拍脑袋说需求的事情，他是我见过的第一个完全按照RUP的方式做开发管理的人，与实际开发结合的还不错，当然RUP有很多工作对于一般性的小公司是冗余的。
我们的目标是做产品，而且产品也不算小，对于我们开发人员加测试也不到8个人（工控系统程序员除外）来说，全部使用Asp.Net 开发，一共是13个子系统，加分析的时间算上周期是6个月，由于这个总监对这个行业不是很了解，分析也仔细，分析的时候程序员都在做技术培训，画图，做表，思考怎么做就过去了两个月，不过开发确实很迅速的，基于CSLA框架，做业务层，每个组3个人，分了两个组，每个组有一个业务开发，分工明确，遇到问题就临时安排一个人做调研，两个UI（因为ＵＩ一直是工作量最大最复杂的）就这样快速推进，两个月后我们已经开始做第１０个子系统了，代码很规范容易维护大家用的都是相同的技术，业务层的代码大部分都是代码生成的，UI的页面之前设计过，所以风格规定好了，剩下的页面根据业务层需求开发，页面很规范（实际上这很好，从使用的角度来看保持统一的风格，会更容易使用和上手），虽然很多，但规范式的开发方式让所有人都对什么时候可以完成充满信心，很团结，找个人稍作培训就可以开始，而且不怕员工离职，这个总监要求下班就要回家，每天每个人就只是做规定多的工作，但必须要高质量，这正好和我下一个公司相反。
最后这个公司在我们开发的第四个月的时候由于公司高层出了一些事情，没有自我盈利能力而倒闭。但这套开发和管理的每个细节给我的影响很深，但也有一些问题，就是UML流图文档非常的多工作量很大，后来我经过思考，结合XP，将这些多余的工作去掉，只保留说明问题的文档，保留了其开放框架，及迭代推进的经验，整理了一套自己认为合理的开发方式，但真正起作用的依然是开发技术，及开发流程管理方面的总结和优化。技术先进性才是解决一切开发难题根本，而不是理想化的管理。