|
十个月的时间,辗转六七个项目,虽以普通开发人员的视角管中窥豹,但项目中的问题弊病依然可见一斑.从几个方面写写自己的见闻和浅析吧 1. 人天问题软件开发项目最大的成本就是人.人天预估的高了不容易中标,人天预估的低了又难以保证质量,其中的权衡拿捏不是我一个小技术能涉及的.但是真正落地实际情况并不理想,在许多项目的承包上,项目预估的人天与实际所需严重不符,甚至有项目刚开始做需求分析的时候,工期已经过去了一半多.所以即使已经疯狂压榨开发人员(个别项目整月整月的加班到12点),很多项目还是不得不延期,仓促赶工的项目质量不行与延期之后带来的成本提升都在降低甲方的满意度,同时也降低了乙方的利润 2. 业务能力不足多数项目中缺少能从整体角度辅助客户完成业务功能设计的出色业务顾问.很多项目中,甲方业务需求自己想方案完成方案设计,乙方业务能起到的作用小. 3. 盲目推行新模式赶鸭子上架推行DDD,领域驱动设计的确要求与业务加强沟通,双方共同设计出领域模型.但是在双方对领域驱动设计都缺乏了解的情况下强行推进DDD很容易弄巧成拙. 一方面业务人员容易落入原本瀑布式开发的窠臼中(视各种需求分析文档\开发文档为项目进度的里程碑)(这也有甲方的领导很难转变思维的原因:有时候业务角色接受了新型的软件开发方法,而他们的领导却不能紧跟这种变化) 另一方面,DDD要求技术人员也要转变思维,系统的设计,尤其domain层的实现,与原本的mvc模式完全不同.而且,领域模型驱动代码的实现要求保证领域模型的设计是正确的.否则我们无法确定领域模型可以解决领域中的核心问题 这就导致,甲方因为缺乏项目产出(特别是在项目前期,DDD因为重产品而轻文档,缺少能向甲方说明的项目进度的标的)会开始怀疑乙方的进度,而双方对领域的不擅长导致迟迟不能推演出正确领域模型设计又继续加重这种不信任,然后因为时间有限,仓促赶出一个领域模型并进行开发,以至于模型无法符合实际业务需要反而增加了开发难度...而项目的延期又会导致甲方进一步怀疑乙方能力... 总而言之,我认为在实施DDD的过程中,我们缺乏一个领域专家的角色带领我们向DDD过渡.
4. 技术与业务之间的隔阂在项目中,业务在完成了项目前期业务模型设计之后的主要角色就变成了监工和功能测试人员. 许多业务顾问除了催进度之外就只会甩锅,说什么什么问题是开发的问题,是他们写的bug.而技术人员同样会把锅甩给其他:比如设计的时候没写清楚,比如这个代码不是我写的而是之前的人写的等等. 互相甩锅导致乙方内部都无法通力合作,大把的时间用来互相扯皮推脱任而不是解决问题. 5. 规范与标准化的缺失
6.人员变动大项目成员表来源复杂,组织结构复杂,项目成员来自公司内不同的事业部,直接汇报的领导各自不同.而且,因为压力福利种种原因,项目内持续有人离职,所以项目组不得不从公司的其他部门调人同时从外面招人,而新招聘的员工质量无法保证,从企业内其他部门调来的员工又因为跨部门,带来了管理上的麻烦
尝试的改变与局限
|
|
|
