由于沟通不畅等自身原因,我从一个大公司换到一个不知名的小公司.在这儿负责一个新项目的架构设计.这个公司由于市场定位准确,用户界面美观,易用,能方便快速的查看网络的信息,解决管理的复杂性,等优势,在市场上占有一席之地.

我的优点是对需求分析和架构设计的方法和系统建模流程比较了解,缺点是对这个领域的业务规则其实并不是很熟悉,而这个系统的架构设计其实已经由现在的项目经理做过一次,但是领导们总是感觉少了些什么,软件需求也是,其实项目经理已经做过一次,但是领导们还是感觉和他们的想法不一致.其实这里就已经埋下了伏笔,他们到底觉得什么可以是项目可以接受的提交点呢,好象没人能说清楚.

这个公司的特点是老员工都是编程高手,但是由于原来规模很小,属于20个人左右开始做大的,关于架构设计和需求等理论知识相对较弱,新来的领导们都是大公司里的技术骨干,属于追求技术完美类型.

这个公司原来也的确有些比如把数据写死到程序等大公司的DesignRule比较反对,造成维护困难等不是错误的需要提高的技术改进点.所以大家都报着美好的愿望开始,希望能在这个项目里解决问题.

但是一进入项目,发现自己理解的架构设计和他们完全不是一回事.我理解的是可行性分析加上UML的4加1视图, 可行性里面其实是希望业务需求达到80%的清晰.这个项目由于规划不当,其实是需求和架构

同时进行的,在评审需求时大家越想越多,想到了怎么做等等问题,唯一不去想这些需求到底要多少人力,哪些技术实现.

以至3个月后老板说这个需求还是属于业务需求,要重写一份软件需求.

在做这个架构设计时,业务视图由于需求太大,迟迟不定无法完成,逻辑和组件视图基本到是定了,大家对表达方式都很不习惯,后来发现这是由于大家对UML的视图元素不够理解,又讲了几次,这个似乎和他们的想法还是不一致,他们比较习惯于行业的用语和C#的技术,而我比较熟悉JAVA的技术和uml元素.于是大家又花了很多时间讨论.基本达到了一致,勉强通过.

到了实现视图和部署视图就更麻烦了,里面涉及到了技术选型,我推荐的J2EE(JBOSS)技术大家还是不了解,反而觉得原来的C#简单.本来这也不成问题,但是领导又要求支持集群技术,最后这个技术风险也成了最终的问题,以致没有人能实现得了.

想来从简单到复杂,从复杂到简单的分析方式还是很重要的.一个目标再好如果实现不了,就要坚决砍掉或推迟,不要把概念化阶段的文档当成项目的最终目标,否则,在前景不明的项目中,失败的风险高达1/3-1/2.

这个项目另外一个问题就是领导团队分工不明确,每个人都要发表自己的意见,只知道说什么不好,却拿不出一个模板,导致大家对架构设计和需求里到底要包含哪些内容,什么样子就可以验收,文档的结束标准不清楚,review时老板都不参加,然后项目经理单独组织一次又一次的评审会后,又增加一些新内容,比如云计算,比如集群,最后真正变成了空想.其实这些东西虽然好但是并不是我们根本和马上要做的内容,这样反复了4次后,文档增加和修改到60页,却发现和他们的想法还是差距很大,那么他们想要什么呢,还是不清楚.

于是又组织概要设计,又是4个几十页的文档,大家都按照自己的喜好去设计了,好象也没看出什么问题,却还是不知该怎么做.
这样过了4个月,感觉拖下去不是办法.另外换了一个人做项目管理和架构设计,又写了一些文档.
于是开始组织开发,一个回合下来,做出一个可以运行的产品,领导说你们没有解决根本的问题嘛.修改一次还是不能达到领导的目标,最后下面的人一大半都离开了,余下的人也去做其它项目了.这个项目基本就废弃了.

这次听了IBM的开发会议,还是很有感触的.
架构是一个逐步求精的过程,我们要不断修正,包括需求,最好从了解核心需要解决的问题和用户使用的场景开始,尽量小型化和把风险列出,Just Enough,一开始不要追求技术的完美,等大家都清楚了我们要的是什么后,再逐步求精.架构是需要原型验证的,以求证技术上可行和让大家从一个简单的架构开始学习和能力提高.

这个项目经理是个老员工,是一个技术专家型的员工,却比较缺乏项目管理的能力,对项目的范围管理,沟通管理,时间管理,成本管理,风险管理知识了解不够,决策层也普遍属于技术型,不够了解项目管理的要素,产品的市场需求,决策知识和如何划分重点.

还有一个问题,就是领导到底应不应当是技术专家?很多大公司里面技术专家和领导职位是分而规划的,而小公司往往期望其合二为一,当然这样有决策效率高,成本低的好处.但是其实所有的人都不是完人,都有自身的局限.领导过分干预技术决策的话,会导致员工失去方向,无法发挥主观能动性,而领导也由于纠结于细节,失去了项目的整体如时间进度业务价值等把握能力,不容易正确决策.这个问题我一直没考虑好.

而总结我个人,其实也有很多问题,和老员工包括领导的沟通不够积极,没有站在他们的立场上考虑问题,应当多做些技术交流和讲座,包括一起做些开发测试工作,了解他们的想法和需要,帮助他们在Java技术上提高就好了.自身对领域知识也了解不够,应当沉下去,多做写基础工作,谦虚学习就好了.

设计架构时,应当同时做写原型程序实现和对架构不断修正,也许就会离目标近些.项目的沟通也有些问题,其实应当多组织上下层,技术和业务的交流,大家报着一个积极向上,解决问题的心态就好了.总之,

回想起来,这个项目的圈,饼叉都有些问题,特别是饼,业务和技术目标都太大,不切合实际,可行性不正确是这个项目的根本问题.
再次,其实如果真的是没有java专家的话,不如当时把业务需求,软件需求,架构需求说清楚,目标划小些,用他们原来熟悉的C#实现了关键的需求,另外找个Java团队熟悉了JBOSS技术后,再重做一遍,可能成本稍微高些,但是成功的几率会大很多,毕竟,业务和技术都是全新的项目风险真的是太大了.这是一个实施策略的问题,

而且我在尊重员工,重视员工行为规范的宽松的外企里面呆习惯了,对民营企业拼命加班,严格惩罚员工,禁止员工上网等的军营式管理行为非常难受,其实仔细想起来很多时候磨练也是一种锻炼,对于人的成长长远看也是有益的.关键是要调整自己的心态.
其实不是环境改变人,就是人适应环境,所以在换工作前千万要了解这些情况,会少走些弯路.

我们很多时候不得不在犯错中成长,在痛苦中成熟.
满招损,谦受益.
高调做事,低调做人.
不要当众批评人和群发邮件.
即使领导不对,也要服从,
小公司里一切都要听老板的,要让老板满意就足够了.但是年轻人的话还是到大公司里锻炼,能培养正确的做事方式,然后再自己创业好些,否则基础知识还是不够扎实.

还有你付出了多少就期望多少,很多民营公司里成本是第一位的,所以要考虑好,你拿多少钱必定对你的期望有多高,是否能达到和适应,大公司里愿意培养人,而大多数在生死存亡线上挣扎的小公司里很难做到这一点.所以要改变自己的期望.

这是我在这次失败中总结出的几点教训.
希望明天能更好.