浅析哪些软件开发项目不能做

开发 项目管理
软件开发项目,有很多其实是不能实现的。但为什么我们还要往这个坑里跳?本文将为大家分析一下哪些项目不能做。

  最近半年扑在一个项目上难以自拔,简直就是一个泥潭,无数同行来到这里、陷在这里,谁也不知道到底完成项目还需要多少人来填坑。项目管理混乱,高层领导离职,已无进度管理可言(自打来了项目组,就没见“里程碑”为何物)。干到现在,我所感觉到的仅仅剩下失望、苦闷与挫败感。写到这里有点发牢骚的味道,其实我想说的是项目的成败与管理有莫大的关系,作为一个管理学出身(我现在是开发),我也想通过我的经历说说我对项目管理的认识。

  首先,说说我们项目组自身的不足。

  1 没有“规范”。进入项目我没有拿到任何“规范”性文档,所以开发中数据表、变量、工作流等命名极其混乱。

  2 没有数据字典。开发对数据库的认识仅能通过查询来了解,对于一个企业级项目来说,表实在是太多了,我们不了解某些数据,现有的表是否保存。

  3 没有核心人物。对于一个使用独立框架开发的系统,没有一个对其十分了解的技术总监,所有人都是在按照之前的版本改造,尝试性地引入新功能,经常是一错错一片,需要不断地进行整体的返工,非常耗时。

  4 没有责任到人。项目一贯的拆东墙补西墙的做法,导致某个功能点被分配了N手,所有人都要看前人的代码并熟悉业务,但项目组有不给你足够的时间交接,这样的结果就是大量代码重复,BUG数量飙升,以及出问题没人认领,互相推诿,最后接手的人要为前人买单。

  5 缺乏沟通。在如此一个需求不明确的情况下,开发就应该坐在需求部门边上不断掌握需求,但是多数人没有,导致了我们都变更单都快追上《C#高级编程》了,而且内部人员沟通不足,缺乏协作。

  6 不做代码审查。项目组没有质管,破坏现有代码分层,插入不写验证的情况很多,谁来为他们的BUG买单?

  7 资源分配不合理,奖惩不均。甲方人员闲的打游戏,乙方人员加班到半夜。这其实也没啥,但是我要说的是为啥表扬的总是甲方,乙方加班就是应该的对吗。开发兼职运维,每天都要浪费大量时间来解答用户的各种问题,这也没啥,但为啥不让用户去找培训人员而来找我们,为啥解决问题消耗的人日不列入计划。

  其次,说说我们的合作厂商的问题。

  1 顾问能力不足。多数顾问不懂技术,其设计的系统完全违背大型分布式系统的开发原则。一个接口对应N个功能点,为了复用代码他们绞尽脑汁呀,可你可知道你提高了系统的耦合度,你对维护提高的多少成本。自己接口从不写验证,你为啥那么相信你的外围系统,你自己的库你都不看好门吗。完全不知道需求文档该怎么写,你是顾问,你要将用户的需求转换为需求文档,而不是指导用户如果写个EXCEL来应付差事,你的用户不知道开发人员需要什么,也不知道该如何表示自己的需求,再说哪有让用户写需求文档的。完全不能估算工作量,单方地认为改改字段就像改EXCEL文档那样简单,压外围进度压的好死。此外,顾问的业务水平也不高(经常遭投诉),定个需求要开几天会,等真正做的时候发现业务又走不通了,明显在设计时,没有根据实际业务对设计进行反复迭代。

  2 糟糕的文档。先不说文档的质量,首先数量就不全,经常是先开发后补文档。再说质量,完全是外行人写的东西,不过也可以理解,毕竟大部分文档是用户写的,我就想问,让用户出设计那还要你顾问干啥,难到就是发发邮件当监工。我觉得这已经不是能力问题了而是职业道德和责任心的问题。

  3 推卸责任。业务上本该自己系统实现的功能,因为不好做就下发给外围系统,你个几千万的系统做不了,你要个几百万的实现,这理由充分吗。每个系统都应该承担起自己的责任,占有自己的位置,不要因为客户不懂技术,就偷懒。虽然作为顾问,维护己方开发人员的利益是合理的,但也你不能够以牺牲系统的可用性为代价。

  4 换人不做交接。很难相信会发生这样的事情。不过我确实遇到了,换了人了,之前的设计全报废,然后做新的。

  5 环境混乱。完全不理解为啥开发需要搭建如此多个环境。用户不停地从1个环境上测完去另外一个。你同类环境1个就够了,为啥整一堆没有针对性的测试环境,最要命的是还不能保证发布的版本同步。而且环境数据脏了就整新的,那得啥时是个头。

  6 不接受意见。外部厂商顾问不爱接受外围系统给出的意见,比如接口复用问题。完全是把接口做成一个并集,来最大限度进行复用。

  7 频繁变更。变更过于频繁,这也是项目组遇到最大的问题。不管是否收到甲方的确认函,变更都会到来,我报废掉的代码比现在可用的高出数倍。你完全不知道你的任务啥时候完了,到开发完成,测试结束,用户确认并试点上线之后,本该认为是没事了,但是到来的不是BUG而是变更。看过《C#高级编程》都知道那书有多厚,如果把我们的办更文档都打印出来,页数也差不多了。

  说了这么多,很多都是自己的牢骚与不满,不过我真正想说的是软件工程的重要性。是什么造就了软件泥潭?原因的多方面的,但是好的项目管理能够帮助我们规避风险降低开发成本,并提高代码质量。比如,与用和其他参与者(包括合作厂商)密切沟通,对需求反复迭代,规范技术文档,好的版本控制,统一编码风格,进行代码走查,问题责任到人,采用合适的开发模型,正确评估工作量,制定合理的进度管理和激励机制,这些都有助于对一个项目的跟进。

  感谢读者能够耐心地读完我的这篇”牢骚“,作为一名普通的开发人员,我不想指责谁的过失,因为毕竟我没有坐到那个岗位上,没有资格指责别人的工作。我觉得,一个项目的成败,虽然不是某个人能左右的,但是只有各个岗位的人各司其职,全力配合才能够保证系统的顺利上线。我想对刚入行的程序员们说的是,请对你们的代码负责,用户不提的不代表你就不用做了,没测出BUG不代表就没BUG,请在提交前做好代码走查,并不要推卸你的责任,是人就会犯错,你要做的就是承认错误并及时解决;对顾问说的是请对你们的客户和你的设计负责,你要知道你出具的文档是我们开发系统的重要依据,我们是如此的信任着你,请不要让我们失望。

  最后送上我比较喜欢的一句话:软件开发如同在水面行走一样简单,只需需求已确认,水面已结冰。

原文链接:http://www.cnblogs.com/MeteorSeed/archive/2011/07/12/2104069.html

【编辑推荐】

  1. 新手软件项目经理该如何入门
  2. 项目经理的力量应该从哪里来?
  3. 当你从程序员变为项目经理
  4. 软件测试项目为什么会失败
  5. 项目管理之CVS与SVN日常使用总结

 

责任编辑:彭凡 来源: 博客园
相关推荐

2011-07-26 10:44:32

开发项目

2011-07-21 08:49:06

软件项目

2013-05-22 09:26:48

软件开发工作效率

2009-06-12 11:35:28

模式框架软件设计

2022-08-29 14:56:39

物联网软件开发设备

2011-11-29 09:29:35

项目经理

2022-11-06 15:42:16

软件开发KPI团队

2022-10-12 14:17:39

物联网软件开发

2016-12-14 14:26:23

软件开发云群体

2011-05-19 08:57:41

软件开发项目

2011-08-10 08:58:14

项目管理

2015-09-24 16:09:45

软件开发项目原因

2012-05-02 10:08:19

软件开发开发

2012-06-18 09:34:14

2020-06-24 11:21:47

软件开发面试

2017-03-17 08:15:17

敏捷软件开发软件开发

2024-11-07 12:14:36

2020-10-16 18:33:18

Rust语言前端开发

2011-07-08 08:37:05

软件开发

2011-10-19 13:45:36

ibmdw软件工程协作开发
点赞
收藏

51CTO技术栈公众号