系统集成论坛

标题: 漫谈系统集成软件行业项目管理 [打印本页]

作者: unisonweb001 时间: 2011-8-25 09:28
标题: 漫谈系统集成软件行业项目管理
先就从项目管理开始。
项目管理是从上世纪六十年代开始，直到进入二十一世纪逐渐成熟、发展的人类对自身组织管理的高级发展形式。其深远背景是随着人类大规模生产力的空前提高，人类对物质、精神的需求不再停留在满足的高度，而是进一步提高到个性化、独特化的高度；随之而产生的是我们面对的自然和人类自身的工作课题也进一步复杂化和深度化，这些如果用传统的常规管理模式，用二十世纪三四十年代发展起来的机器大工业管理理念和方式已经是力不从心。关于项目管理的权威定义可以参考PMBOK.。
就企业而言，全球化的竞争加剧和产品周期的缩短，使得企业靠一种或一类产品滋润几年甚至几十年的时代一去不复返，如果不及时推出领先同行的产品占领市场，距离淘汰的日子也就不远。对于所有领先于行业的企业而言，如何研发新一代产品，如何进行市场营销策划，开拓新的市场份额，这些工作的重要性已经远远超过产品的生产和包装。而就前者的管理而言，就是项目管理的范畴，而后者则是传统的常规管理模式。
就行业而言，新型行业面临的风险和未知领域较多，侧重于项目管理，传统行业由于有了成熟的生产规范、工艺，侧重于常规管理，但这并不意味着传统行业与项目管理无关，事实上传统行业只有勇于创新，用于冒险，才能获得新的生机。任何企业都要靠市场营销和产品创新这两条腿来走路，短了任何一条都会成为瘸子，而这两条腿都适合项目管理的路子。
事实上项目经理在海外是相当重要的岗位，其资历和能力都有严格的要求。如果你的名片上跟个PM的标签，一般都能获得别人的敬重，这跟国内PM是基层的班排长角色的定位很不一样。
软件行业是只有二三十年发展历史的新型行业，几乎就是伴随着项目管理技术的发展而逐步成熟的。软件行业的项目管理几乎集中了项目管理的所有难点和风险，软件企业的管理几乎就是项目管理的天下，虽然在海外，随着软件开发技术和管理的成熟化、工程化，出现了一些工程化、规范化的组织、标准，如ISO、CMM、PMPOK等，但远远不能与传统行业的标准规范如机械行业、建筑行业相提并论，一张建筑图可以让任何一个国家的建筑师都能看得懂，可一份软件文档别说是跨国，就是两公司之间都没有共同的标准规范。
软件行业要成为传统行业，还有相当长的路子要走。换句话说，软件行业的薪水，至少还有相当时间要高于其他传统行业，国内有一些人说要培养软件蓝领，眼光不错，看得很远，关键是只有几十年发展年龄的软件行业是否能够达到像建筑行业那样的成熟和规范，找几个蓝领甚至是农民就能盖出一栋大楼来？在蓝领的后面，软件行业还需要很多东西来配套，而这些东西不是一天半月能建立起来的。
很多人知道印度的软件企业很规范，有的企业甚至人数过万，管理上没有一套是不可想象的，但细究一下，大家在市场上用过印度商标的软件吗？没有，其实很多大家熟悉的软件的底层模块可能就是印度人开发的，但我们不知道，真正掌握软件核心技术的不是印度人，而是美国人和日本人，他们把模块的编码工作让印度人去干，而策划、设计和其他一些核心工作都是关起门来自己干的。难道我们也得像印度一样重点培养软件蓝领，在软件这样的高技术领域也像传统行业一样成为发达国家的末端加工基地吗？
软件行业的项目管理，可以粗分为包括软件开发在内的系统集成项目，纯硬件的系统集成项目和系统软件开发开发项目。由于对后两类涉足不多，下边只说第一类。
系统集成软件项目在所有软件开发项目中是比较复杂的，与其他软件项目相比，集中表现在以下几点：
1、必须集软件与硬件技术于大成，要求项目组不但要精通软件，而且要掌握硬件技术，这与纯的系统软件开发项目和纯硬件集成项目的要求是不同的。将软硬件技术进行完美结合，给客户提供性价比最高的系统，是系统集成项目孜孜以求的目标；
2、必须集业务与计算机技术于大成，系统集成项目有明确的客户和目标性，必须是对某种行业某种业务或几种业务的支持，如金融、电信、税务等等，系统具有明确的业务要求，这与系统软件作为一种通用工具来开发是截然不同的。这就要求项目组除了精通计算机技术，还必须精通相关领域的业务知识，项目组对相关领域业务知识的掌握水平和前瞻性，很大程度上决定了系统的质量和生命周期；
3、客户的多方性和复杂性，系统集成项目与社会、人群息息相关，一个系统集成项目的成功带来的不仅是经济效益，更多的是社会效益。当一个成功的系统集成项目开始服务于社会，方便于人群时，开发人员应该因此而感到自豪和欣慰。另一方面，正是因为系统集成项目的贴近社会，客户的关系处理就显得复杂得多，这里不仅有甲方，合作方，包括双方的合作方和系统软件提供商，，还有顾客和社会等等；
4、管理的复杂性，正是如上说述，项目管理的复杂性就可以理解了。
最后谈问题，从目前国内的系统集成业的发展状况来看，系统集成商的发展很容易走入以下误区（以下问题侧重从技术的角度来思考，并不针对某家具体的公司，请勿对号入座）：
1、重市场，轻实施：这个就不必谈了。
2、重项目效益，轻管理、技术积累：作为项目经理，他的首要目标是确保项目的准时完成，成本控制在底线以内，同时让客户和公司双方满意。如果做到这些，这个项目经理就是合格甚至优秀的了。但从企业的角度而言，如果仅满足在这个层次，问题就大了，因为公司的生存不像一个项目就几个月或一年的时间，有些企业是有成为百年老店的决心的。我们发现一些公司拥有大量的成功项目案例，但其管理水平、技术能力并没有得到显著的提高，甚至会因人员的流失而下降，说明大量的成功项目并没有给企业带来管理和技术的积累，离开了一些技术骨干，企业就是一个空壳。这是项目经理的错吗？大家思考一下。
3、重第三方提供的技术，轻自身的系统集成技术：系统集成的真谛在于在满足客户目前和将来一段时间的需求的前提下，提供给客户最佳性价比的系统。集成商容易犯的错误是替系统软件商和硬件商打工做广告，一味强调第三方提供的硬件、系统软件技术是如何先进，而没有强调自身的在某一行业的系统集成技术如何，没有自身的品牌培养意识和技术积累意识。从长远而言，对于一个系统集成企业而言，没有明确自身的优势所在和命脉所系是危险的。集成商要始终清醒意识到，无论是硬件还是系统软件，这些核心技术都不是自己的，别的集成商都能轻而易举的获得，只有对相关行业的业务的深刻理解和前瞻，和积累起来的系统集成经验、技术才是系统集成商的核心竞争力。
4、重技术，轻业务：这个与上点相关，如果把技术与业务同时放在天平上，对于系统集成商来说，倾斜的永远应该是业务这一边。客户需要一个系统，首先而且是主要的目的是看这个系统能满足和支持什么样的业务，今后的拓展能力如何，而不是这个系统是靠什么技术去实现的。一个理智的用户绝对是要求系统在满足业务及其今后一定阶段拓展的前提下，实现的代价越小越好，技术越简单越好。这是很多集成商忽略了的地方。客户对技术往往是迷信和迷茫的，引导客户、培养客户对于一个欲成为百年企业的集成商来说应该是必不可少的。
系统集成商要培养自己技术人员不仅要精通技术，更重要的是精通业务，特别是系统集成后的业务。对于系统集成技术人员言，对业务掌握的要求要异于一般的业务人员，一是考虑到系统处理方式下如何优化业务的处理模式，二是必须掌握业务发展的前瞻性，确保系统在短时间内不落伍，随着社会的发展，系统集成开销对于任何一个客户来说，已经成为越来越大的支出，我们要理解客户对系统的期望和感情。昆明农信一位客户说过一句话，你们开发只是几个月，可我们要用几年啊。
就个人感觉，我觉得业务的门坎要高于技术，如金融、保险，没有十几年甚至几十年的经验是不敢称之为专家的，特别是对业务历史、发展的深刻理解，没有时间的浸淫是找不出感觉的。而相对而言，一些计算机技术，特别是一些新技术，如新的语言和中间件技术，一个毕业生通过一个项目甚至自学就可以基本掌握，很难说这些技术的门槛很高。
在国内，除了一些硬件条件限制的技术（如MAINFRAME）外，其他的只要能在PC上实习，盗版光盘又能买得到的技术，都不可能让你长久维持高薪的，这些东西新毕业生往往掌握得比老人快得多。有句笑话，在中国，任何先进的IT技术的门槛就是5元――一张盗版碟的价钱，好像最近都不要5元了。
那老人的价值在那里？如何使自己持续增值，至少是不贬值，应该是我们经常思考的问题。
5、重技术，轻设计：技术人员在深刻理解了客户的业务需求后，采用适当的架构和设计，根据架构和设计选用适当的技术去实现这个系统。但在具体的实施过程中，我们往往把这个顺序颠倒了，对于技术出身的人员来说，容易犯的错误是迷信技术，忽略对业务的深刻理解和在此基础上的业务设计和系统架构、设计，总是用技术的角度去看待、评价系统，作出来系统往往是技术先进、设计蹩脚、业务落后或不适用，这种例子实在是太多了。
6、重开发，轻测试：这个就不罗索了。
7、重测试，轻开发：这个其实和上一点犯的是同一毛病，由于这几年对测试的重视言语深得人心，有些集成商就幻想仅靠测试去确保系统质量，很多编码人员也不愿去做内部测试，把问题留给测试人员去发现，这就走向另一个极端了。大家要清楚测试的地位，测试工作只是对系统质量的确认和最后的把关，而不能将所有的系统问题遗留到测试阶段去解决，很多问题在前期解决的代价要远远小于测试阶段发现、解决的代价，俗话说得好，一人疏忽百人忙，这个亏我们不能再吃了。事实上一个系统的质量不是靠测试来决定的，而是在开发阶段结束时就已经定型了。测试只是最后的把关和验收，测试工作很重要，但千万不能迷信。
8、重程序，轻文档：这个也不罗索。
9、重个人能力，轻整体协作：这一问题在大型的项目中表现得尤为突出，过去我们的系统集成项目基本上都是四五个人搞定，在沟通和协作上即使没有规范的流程和文档控制都不会有太大的障碍，每个人的效率都可以达到很高，从而整体也同样达到高效。但在十人以上甚至几十人的项目管理过程中，原有模式就会给项目带来了空前的混乱，虽然每个人的效率并没有降低，但由于沟通不畅和误解产生的重复劳动、额外劳动大大增加，整体效率显著降低，这是我们急需解决的重点问题，因为我们不可能永远做手工作坊式的小项目，公司要成长，个人要进步，这一点也需要我们大家思考。

欢迎光临系统集成论坛 (http://bbs.xtjc.com/)