项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 博客 圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
价值源于交流与分享
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:失败的IT项目比比皆是,进度延迟,预算超支,客户需求多变,成员加班抱怨...IT项目(软件开发.,信息系统实施等)寻求新生

本版版主

camer
登录:2013/7/2
次数:867
注册:2003/3/3
发帖:2745
dorothy
登录:2016/12/15
次数:804
注册:2004/9/6
发帖:993
steveli2008
登录:2009/5/26
次数:464
注册:2003/5/12
发帖:1026
zhf_karen
登录:2015/6/2
次数:346
注册:2005/6/13
发帖:469

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

社区热点

华师大CTO学院:科创生态建设与创.
宏发电声江玫瑰谈PgMP:“下好一盘.
PgMP:交付能力与创造未来的项目管.
开放讲座|《项目组合管理与PfMP认证
开放讲座|项目组合管理与PfMP认证
开放讲座|PgMP:项目管理思维与方法
开放讲座|《项目组合管理与PfMP认证
网络讲座|《项目组合管理与个人职业
开放讲座|《项目组合管理与PfMP认证
网络直播|产品经理的四大核心技能提

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

HG信用盘0出租
圈主:de123
行业:综合应用

集团企业生态体.
圈主:ETPPM
行业:综合应用

生态系统体系下.
圈主:ETPPM
行业:综合应用

西安IT项目管理
圈主:muzud
行业:IT软件

房地产项目管理
圈主:13935823
行业:房地产

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net


版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
软件项目中错综复杂的问题 [发表于 2014/8/20]
状态 开放帖 浏览量 535   

该帖子同步发自:(fayjie的博客  访问该博客)

  在《C++头文件风波》中提到我所在的team使用C++开发时遇到遇到的一些管理上的问题。对于软件开发项目来说,评价项目是否成功的因素恐怕最关键的就是

  ·是否能按期完成

  ·是否能够保证质量

  按期完成的事情就不要提了,到目前为止我还没有看到过能够按期交付的项目。原因很多也很复杂,大概有人读过《人月神话 》的焦油坑那节就知道怎么回事,连精英汇聚的IBM 360系统开发都能出这么多的问题,就不要指望我们这些平庸之辈组成的团队还能能够创造什么奇迹。这个观点也许有点消极,但是事实的确是这样的。虽然很多人在想办法解决软件开发中的各种各样的问题,但结果却仍然不那么理想。

  软件质量不能得到保证也是问题。软件质量衡量的标准有很多,你可以从不同的侧面说出来一个优秀的软件项目所能创造的价值,比如,健壮性,弹性,可移植性等等。问题是,很少有人或者团队在项目开发的时候能保证取得他们想要的所有质量特性。“先把事情作出来,然后在把它作好”,也许这也是个说辞。但现实情况是,如果没有良好的迭代流程,几乎在每一次版本变更或者移植的时候都会将上个版本完全抛弃。这就是我们遇到的问题。此外,第一个版本似乎永远是要被扔掉的——这句话也是《人月神话》来的。扔掉某个软件版本并不是很可怕的事情——比如用脚本语言开发的用来引发讨论和idea的原型,可怕的是,有的项目展开了都有一段历史了,版本变更的时候源代码还在剧烈震荡。你找不到清晰的版本线,你拿捏不了这玩意儿为啥要这么做。我遇到的一个比较极端的例子是一款浏览器的开发,main函数所在的那个文件有6000多行!!!而且这玩意儿是用C++写的,虽然按照《Code complete》的说法,C++代码比较verbose(如果c语言是1,那么C++的代码量是2.5左右),但也不至于到这种地步。很显然,这个浏览器在最开始的时候就没有经过良好的设计。有人把GUI的处理,HTTP通讯,业务逻辑等等混杂一气写到了同一个文件当中。于是造成的结果是,在开发下一个版本的时候,总是有大量的代码要被重写,6000行的源文件,几乎是全部被抛弃。日本人有保守谨慎的做事风格,因为他们认为上一个版本是能够使用的,所以,下一个版本应该仿照上一个版本来写。于是继续制造一堆根部不可读平且继续会被在下一个版本中抛弃的代码。就是再也样。代码重用如果有问题,恐怕想做到敏捷开发也是不可能。比如,新版本变更中仅仅影响到了图形界面——这是最常见的情况,例如从Graphic Toolkit从gtk换到Enlightenment,或者再从Enlightenment换到miniGUI上,如果在第一个版本中就搭建了一个良好的结构的话——Bridge Patten 是一个解决方法——以后的版本之需要按照简单的体替换规则做些改动就可以了。这是一种理想状况。我想说的是为什么在现实中无人关心这件事情。

  每次新项目开始,总会有很多部门的不同人员加入进来,关键是每次新项目的项目经理都在换!这个项目的项目经理不需要对下一个版本负责,他关注的只是现在,当下。他需要的是只要能把自己的task完成,至于以后怎么办,“那不是我的事情”。

  优秀的软件开发人员实在太少,即使能够找到,也会因为论资排辈的“科层”制度被埋没。我一直认为在研发上构造职权的层次结构是非常SB的行为。但是,往往会发生屁股指挥大脑的行为 。最狠毒的老板恐怕是下面这种人。 项目管理者联盟文章

  [This] reminds me of a true “Dilbert moment” a few years ago, when my training.mypm.net

  (obviously non-technical) boss commented that he never understood why it took months to develop software. “After all”, he said, “it’s just typing.”

  ——来自Coding Horror 。

  被公司放出去的项目经常难于管理。曾有Moto的VP大声疾呼,一定要把发放到亚洲地区的设计和软件开发工程收回才能拯救Moto的手机部门——虽然他们已经这么做了,但是很显然最终还是臣服于Google的Android平台。以我接触的项目为例,公司采用外派人员来参加项目开发,这样作的好处是不需要养那么多人而在长期来看是降低了人力成本,但弊端却是数不胜数!因为契约的关系,外派人员通常是按照计时或者计件收取费用的,所以,他们在项目之中呆的时间越长或者生产的代码量越大,他们获得的薪水就会比较高。很显然,这个利益获得方式与项目的进展不在同一条道路上。项目延期,代码重写对这些开发人员来说是“利好消息”。如果原动力都不一致,怎么能保证一个团队齐心协力的工作?

  人员替换和流逝过于快速。而恰恰因为传统的公司风格——以“管理人”为管理的核心,而不是把“管理知识”作为管理核心来看待——导致了人力资源流失直接造成产品研发能力的流失。代码,文档等内容管理被放在一个很不起眼的地位上,这些事情被认为只是辅助工具,而不是管理核心和作业对象,一遇到问题你得到的答案不是“参照XXX文档/标准”,而是“去问一下XXX大侠”。其结果是,人走了,软件版本会跟着出现断层。我一直认为对一家软件开发团队而言,最重要的财富就是良好的文档和优秀的代码,如果舍本逐末的只把着眼点放在最后产出上,那将又是一个只要葫芦不要藤的故事。

  设计理念和方法在团队中不能取得一致。大学的时候学过一门课程叫《系统分析与设计 》,我至今觉得这门课是我大学学习的最重要的课程之一。比较丢人的事情是,第一次考试我竟然把它挂掉了,挂课原因不明,呵呵。这本书中提供了(至少)两套系统分析和设计的方法——虽然不够完善,这个先按下不谈——随便按部就班的坚持一套作下来都会对你要完成的事情有比较清晰正确的认识。但问题是,这样的方法论在一个团队之间不是所有人都了解和认同的。往往设计方法的讨论结果是虽然作软件架构的人声明这个应该那样那样,虽然开发人员也只能按照那个方法去做了,但却不能完全理解他的理念,造成很多偏差和错误。所以我有时候想,是不是与大学同班同学开一家公司会比较强大,哈哈哈。《系统分析与设计》这本书虽然阐述了一套普遍的方法论,但遗留问题是,它只能作出对现事世界的直接描述,而这种直接描述只能适应现在的情况,而不适用于变化不定的未来。分析模型和设计模型之间存在一定的距离,而这个真空地带只能依靠工程师的经验后者新的方法论来填补,到目前为止我觉得比较有指导意义的一本书是《设计模式 》,具体的算法实现以及更加深入一点的实现部分最好的教本恐怕是Knuth大侠的《The art of computer programming 》,当然这个又是方法论的话题,扯远了。

  上面所说的这些原因,恐怕只是冰山一角。但以管窥豹可见一斑,那就是很多问题并不是单纯的技术问题,往往这些问题是人员,技术,管理,商业契约甚至是公司文化的综合问题。头疼医头,脚疼医脚是于事无补的,却往往把问题掩盖让情况变得更加扑朔迷离。要搞清楚这些事恐怕还只能踏踏实实的继续观察思考和实践。


>>> 由论坛统一发布的广告:
楼主 帅哥约,不在线,有人找我吗?fayjie


职务 无
军衔 主帅
来自 四川省
发帖 1197篇
注册 2009/12/18
PM币 40960
经验 17390点

  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号