软件服务项目中的商务管理问题

对于一个从事面向行业信息化建设的软件服务公司来讲，无论它的经营的思想、炒作的概念是什么，本质上，它的核心业务实际就是一个个软件服务项目的实施工作，公司的利润最终是依靠一个个软件服务项目的成功实施交付来实现的，而它的生存与发展也可以说是完完全全寄托在它的项目实施交付能力上。

然而，几乎所有的人可能都知道，在现在的市场环境下，10个应用软件的开发项目，能够有２－３个按时、按质、按量地进行交付上线，同时赢得客户的较好满意度，就已经算是谢天谢地了。事实上，在应用软件服务领域中，软件开发项目的成功率一直是困扰业内人士的一个难题，看着今天行业服务的市场状况，有时真的让人怀疑，我们到底会不会做软件，到底会不会做项目？

一段时间里，我和一些同行朋友，感叹自己的从业经历，辛苦、压力已经成为我们工作生活的主旋律：以我们现在的工作努力程度，和自己的职业能力，无论做哪个行业，恐怕也要比做软件项目更有前途得多，“男怕入错行”，现在我所认识的一些同行朋友，几乎都有类似的感慨。

不过，问题既然存在，存在也就是合理的，既然入错了行，那也就只能想想办法去解决问题。怎样有效地执行软件开发合同，完成项目交付工作，也正是我们这些入错行的苦行者们所必须面对、迎接的挑战。

前一段时间，我们设计了一个项目实施的基本模型，对项目实施的一些问题进行了一些分析，希望能够对同行的项目实施工作能够有一些帮助。

这个模型是一个层次架构，我喜欢用分层的方法来剖析一个问题。从方法上，我们可以把这个项目执行这件事情分为四个层次来讨论：即商务管理层、项目管理层次、工程方法层、系统实现层。一个项目的执行，必然会涉及到这个模型的每个层次。

每个层次要解决的问题不一样：在商务管理层，我们要解决的是项目实施的投资回报的问题，核心的内容包括项目的决策、收入、成本、合同条款、执行跟踪和回款等等内容；而过程管理层要考虑的则是项目实施过程的控制和管理，包括的内容有项目的计划、预算、执行、里程碑的实现、工作范围管理等等方面的内容，本质上是属于项目管理的范畴；工程方法层要讨论的是对于软件实现的基本方法，包括业务工程方法、需求分析方法、设计方法和开发方法等等，同时包括这些方法的表达规范，如果一个公司在方法上进行统一，那么内部管理的成本应该会大幅度地下降；在系统实现层，则是我们具体实现软件系统采用的工作模式，我们现在已经在实践的方法是基于业务中间件来完成应用系统的开发工作，这种工作模式是实现软件复用、软件工厂的基本保障措施之一。

上面每个层次的都有很多内容，这里出于篇幅的原因，我主要是讨论一下商务管理层的内容，这是整个应用服务项目的基础，是项目实施的出发原点。

我从几个方面来讨论这些内容。
一、项目的商务决策问题
在商务管理层，我们要讨论的问题是，公司在准备做项目时，到底把什么做为项目的目标。对于老板或者投资商来讲，这个问题几乎可以是脱口而出地给出答案：做项目，当然是要赚钱的，要盈利的。
但是，对于具体项目执行的团队来讲，包括公司内部与项目执行相关的职能部门、相关的市场销售部门、相关的项目实施部门，对这个问题似乎并没有深刻地理解。
在市场上，我们经常看到的是，一个招标项目，大大小小的公司，向黄蜂一样，向目标做敢死队式的攻击：不惜血本地降低报价，向客户做出无限制的承诺；在公司内部，招标项目还没有开始，销售就在一轮一轮地调用公司的内部的技术人员，为客户做免费培训、免费咨询，同时销售排着队，争先恐后地请客、吃饭、桑拿、OK等等。这时还没有招标，客户就得到了一个深刻的印象，就是这些IT公司真的不求赚钱，但求奉献，归结起来，就是一个字：贱。
过度竞争是现在市场的基本背景，这个背景导致了甲方意识的过度膨胀。几乎这个行业的所有有点经历的人，恐怕都会有同样的一种感慨，就是中国的客户实际是给IT公司自己惯坏的。事实上是，就目前现状来讲，在国内行业应用服务的市场上普遍存在的情形是，客户极度地忽视、或者轻视公司的商业利益，甲方权利的滥用已经成为中国软件发展的一个最大的障碍之一。
所以，对于软件服务公司来讲，现在几乎都面临一个亟待解决的问题，就是重新建立自己的商业尊严：要培养自己的勇气！说到勇气，要真正做起来的话，还真的有些难度。
首先，要有放弃的勇气。有句笑话，说对于软件项目，不做是等死，做了是找死。呵呵，就我的底线来讲，宁可等死，也决不会去找死，等死，至少还可以选择一个自己的死法，还有一点点选择的自由是属于自己的：自由就是选择，萨特的名言。一个软件项目，如果自己的评估结论是风险大于收益，那么，肯定一点，公司要有放弃的勇气，我们可以不做这个项目，看谁牛！其次，要有说“不”的勇气。几年前，书摊上到处都是说“不”的声音――中国要说不，还有很多很多的说不；现在轮到我们这些一向腿软的IT公司要学会说“不”了。事实上，无论是合同条款，还是项目计划，或者客户的需求变更等等，当我们面临这些问题时，传统的做法几乎只有一个答案，就是“yes”。而现在，对于公司来讲，要有充分的勇气说“NO”。说不的勇气源泉是什么？还是要回到上面那个“放弃”原则：大不了，我们放弃而已！
其实，另一方面，从甲方的角度来讲，如果乙方因为竞争的原因而降低自己的商业底线，那么在项目执行过程中，商业利益的驱动，最终还是会以牺牲项目的质量来实现公司的基本商业目的，做公司不赚钱是不现实的。
我们每个人可能都有装修房子的经历，在和装修公司打交道的过程中，我自己最关注的是装修公司能不能赚钱。记得当时，我反复对装修公司讲：你们一定要赚钱，不然我真的不放心给你们做。我相信这也是大多数人在装修过程中说过的话。你不让别人赚钱，那么谁还能给你用心去做，最终住房子的还是你自己。其实软件行业也一样，软件公司如果不能赚钱盈利的话，牺牲的也只能是甲方的项目质量，最终受损的还是甲方的利益。当然，乙方一般也脱不了干系，最后的结果不是双赢，而是双输而已。
二、建立服务型企业的运营体系
这里要讨论的是，对于软件服务公司，要尽快地实现自己公司经营管理体系的转型，建立适合自己特点的业务经营和管理模型，适应软件服务这种业务的运营和发展。这点说起来简单，做起来实际难度更大。从2000年起，一些原来做系统集成，或者做分销的大型IT企业，也尝试过向服务型业务的转型，但是现在看起来，失败的案例远远多于成功的案例。
这里有一个例子，在几年前，我在另一家公司工作服务时，管理着一个研发中心。本来，我对项目的商务问题也基本没有什么兴趣，但是每次年终核算，到公司去给团队申请奖金时，公司似乎总是理直气壮找到理由指责我，认为我的团队是亏损的。当时很郁闷，也是被逼无赖，所以对商务、核算也开始关心起来。记得当时，我接到一个新项目的合同，是一个银行中间业务平台的项目，平生第一次仔细地看了一下条款，结果把我吓了一跳，在应用软件开发合同中，竟然冒出了开箱验收、设备安装、设备保修等等词语，再仔细一看，原来我们的应用软件开发合同竟然是用设备采购合同修改过来的，接着把其它的条款阅读了一遍，简直难以入目，乙方几乎承担了所有合同责任，所有的内容和我们现在常常说的那些霸王合同几乎没有什么区别。而后来我到公司一打听，才知道，公司内部竟然没有一个标准的应用开发合同的模板，所有的合同都是从设备采购合同改过来的。从那个时间开始，这个公司开始做自己的标准软件合同了！
软件项目执行的基础是商务合同，我们项目计划是在商务合同基础上制定的，商务合同出了问题，实际上，项目还没有做，项目的风险就已经巨大无比了。
当然，我知道很多做销售的朋友很会有着自己的看法：其一，市场环境就是这样，甲方的要求是无法改变的，而且我们不做，还有若干家公司在外面等着呢；其次，项目总会有风险的，合同的条款往往是客户的上级单位统一规定的，当然不能修改，而销售自己是可以控制客户的，可以在项目执行过程中进行控制和变动等等。我想，做销售的朋友的理论的核心可能就是这些。就现实情况来讲，我认为十分正确，他们说的没有错。但是，就公司来讲，这个项目的风险其实全部押在了销售、项目经理这些个人的行为之上，从这点来讲，公司的风险一点都没有化解，甚至更大，因为谁能保证在项目的过程中，销售也好，项目组也好，不会出现人员的离职变动？
事实上，这里我要表达的并不是说这种项目应该有什么样的结论，关键是要强调，对于公司，应该有一种管理机制来化解这种项目中潜在的风险，应该采取相应的行动来落实这种机制；对于客户，应该有一种机制进行说服、改变，引导客户进入到正常的商务环境中；对于销售，应该有一种机制来管理和跟踪他的解释和承诺；对于可能出现的风险，应该进行事先的预测和准备。所有这些内容正是一个软件服务公司基本的业务运营管理体系要完成的内容，这是保障软件服务项目正常执行的公司基础平台。
三、软件开发合同的几个问题
上面已经说到了合同问题，这里，我们做进一步的说明。
在合同方面，一个基础问题就是需求管理。几乎没有哪个项目能够在项目合同签订的时候就能够精确地预测需求的内容和范围，也没有哪个项目，能够在合同阶段准确地估算出项目的工作量，对于任何一个开发商来讲，这本身就是一个很大的难题。
化解这些风险，主要是在合同里，对双方能够精确估算的部分进行确认，把能够稳定的需求先定义清楚，把能够预测的计划先制订好，对于变动部分，应该在合同中加以说明，条款可以按照几种类型来做，一种是，双方对于不确定的部分，按照实际工作量进行确认合同款，或者先预估一个合同款，最后按照实际的工作量进行确认；其次，也可以先估算整个项目的合同款，然后在项目进展到一定阶段，对整个项目的需求基本明确，再进行合同款的变更；或者，根据项目的合同款，折算成为一个封顶的人月数，这样，所有的需求，应该控制在整个人月数范围之内等等。方法很多，这里不一一列举。
对于合同，第二个问题是里程碑计划与收款计划。这个问题相比起其它问题，要小一些，主要是付款条件的问题。从乙方来讲，当然希望收付款高一些，而甲方恨不得到合同维护期满以后再付款。事实上，通常情况下，维护期一般留10%的开发款，这些钱是很少能够收回来的，主要的原因就是软件合同中，往往把维护期放的时间很长，一般是一年，有些客户要求三年，很难讲三年后，甲方和乙方会是什么样一个状况。合同的里程碑和收款是项目计划的基础，而公司内部的项目考核制度又是基于项目计划，一环扣一环，因此，如果这些条款出现问题，那么项目计划的失效也就可以预见了。

还有一个问题是合同条款，这些是隐藏在合同内部的一个个炸弹，要想把这些东西弄得相对公平一点，可真是要有点专业水准。条款包括一般性条款，这些与其它类型的合同基本一致，没有什么太多说的内容，公司普通的律师顾问就可以基本搞定了；但是，那些与具体的需求、项目执行情况相关联的条款，那可就是一个个专业问题了。事实上，现在在软件服务行业里，能够谙熟软件服务合同的人才是非常匮乏的。
四、软件服务公司的基本组织保障
对于软件服务公司，一个核心组织保障就是项目管理部的建设。项目管理部本质上是一个项目商务咨询和服务部门，即它是一个职能部门，同时也是一个咨询和服务机构，是服务型公司内部运作的中枢。遗憾的是，就我现在了解的情况，多数公司把项目管理部做成了一个项目秘书处，一个周报或者其它项目信息的收发部门，或者，把项目管理部做成了一个行政职能部门，只知道编造一大堆表格，发给业务部门填写，而弱化了其咨询、服务的职责。
在服务型公司里，另一个重要的群体就是方案经理团队的建立，完成方案策划和需求建立的职责。落实在商务上，方案经理要能够比较清楚地对承接的软件系统进行功能策划、需求范围界定、工作量估算等，这些可以为商务管理工作提供基础的参考数据。
上面我针对项目实施过程中商务管理的问题写了一些文字，仅仅代表个人的看法。其它的几个层次的问题，在以后可以和业内的朋友多一些交流沟通，一起为这个行业的发展做一些探讨。

软件服务项目中的商务管理问题相关推荐

软件外包项目中的进度管理
案例 A公司是一家美资软件公司在华办事机构,其主要的目标是开拓中国市场.服务中国客户,做一些本地化和客户化的工作.它的主要软件产品是由总部在硅谷的软件开发基地完成,然后由世界各地的分公司或办事机构进行 ...
管理java版本号_微服务项目中如何管理依赖版本号？
本文是微服务项目代码组织形式三部曲中的第三篇,也是最后一篇,通过这三篇文章,相信大家对于如果组织微服务中的代码已经有了一个基本认知,前面两篇分别是: 微服务项目搭建,到底要不要聚合工程? 在微服务项目 ...
java版本号管理_微服务项目中如何管理依赖版本号？
本文是微服务项目代码组织形式三部曲中的第三篇,也是最后一篇,通过这三篇文章,相信大家对于如果组织微服务中的代码已经有了一个基本认知,前面两篇分别是: 第三篇相对来说要简单一些,本来没打算写,但是上周有 ...
微服务项目中如何管理依赖版本号？
本文是微服务项目代码组织形式三部曲中的第三篇,也是最后一篇,通过这三篇文章,相信大家对于如果组织微服务中的代码已经有了一个基本认知,前面两篇分别是: 微服务项目搭建,到底要不要聚合工程? 在微服务项目 ...
软件项目中的人员管理和团队建设
注:来自程序员第七期. 软件项目管理中的人员管理活动是一个闭环管理的过程: 对每个人员的评价可分为几个方面进行: 项目相关的技术能力管理能力软件技能而相应的培训计划也应该扩展到很多和项目技术并不 ...
浅析软件开发项目中的需求分析
[摘要]在软件开发项目中,需求分析是关乎软件项目开发成败的重要因素.现在的软件项目中返工开销占了总开销很大比例,而导致返工的主要原因是需求分析不明确.针对这一情况,文章阐述了软件开发中需求分析任务.需 ...
对软件外包项目中甲方外包管理的思考（一）——人员外包和项目外包
一.概述在软件外包项目中,甲方(发包商)通过资金或其它资源获取乙方(承包商)的开发服务,以达成其软件需求目标.为了让外包项目按时按质按量完成,甲方需要做好项目的采购管理.外包管理,其中采购管理的核心 ...
声光报警器 | 在软件开发项目中加入声光告警、语音通知方案
在IT软件开发项目中,有的客户有这样的需求,希望在公司的生产环境中安装硬件设备,比如声光报警灯.语音通知设备等.当软件中的某些重要信息或者异常事件发生时,向设备发送消息,通过警示音.灯光.语音三个维度 ...
现代IT项目中的需求管理如何做？
现代IT项目中的需求管理如何做? 领测软件测试网我们知道现代项目管理的六要素是:时间.成本.质量.组织.范围.客户满意度,实际上,要满足这六个要素,计划一个良好的需求分析是实现这六因素的前提,如果我 ...

软件服务项目中的商务管理问题

软件服务项目中的商务管理问题相关推荐

最新文章

热门文章