阶级斗争

来源:互联网 发布:net编程软件下载 编辑:程序博客网 时间:2024/04/29 21:57

阶级斗争

案例一(项目沟通)

阶级就像一堵堵的石墙,看来冷漠、肃穆、壁垒森严。它们静静地对立着,守护着自己的领地,不会容许任何的越。利益是他们的核心。  

 

【项目介绍】

如果你接触过中国政府的IT项目,甚至只要是项目,相信这个项目只是

千万个项目中普通的一个。

建设内容:负责建设社区服务信息系统软件部分;硬件集成单独招标,由B公司负责;另有单独招标的一部分是社区的呼叫中心外包业务,由C公司负责。软件部分要求在40个日历天内完成。

相关角色:项目的建设方A单位。对整个项目进行总体监督及协调,并提供必要的帮助与支持;软件部分的中标单位B公司。负责整个项目与社区服务信息系统相关的软件子系统实现及安装调试直至上线,并最终通过验收;硬件部分的中标单位C公司。负责整个项目中所有硬件(包括网络)、布线、机房装修工程、外购软件部分。预先搭建可供软件安装调试的环境,实行独立验收;提供运营服务的中标单位D公司。负责整个项目上线后的运营工作。在前期,要与其他公司配合工程实施并根据运营需求对其他公司阐明对软硬件的要求;提供呼叫中心外包业务的中标单位E公司。负责提供呼叫中心服务,提供必要的接口与服务中心机房对接,并配合运营公司进行运营;提供网络接入服务的中标单位F公司。提供机房到互联网的通信线路及服务,提供服务中心机房到E公司的DDN专用线路;项目监理中标单位G公司。负责整个项目的过程与结果的监督、核查,并在项目实施过程中,协调各个公司进行有效工作。为各个公司提供必要的帮助。


【初次交锋】

A对技术可谓知之甚少,对软件技术更是甚少知之;G态度不甚明朗,但对软件开发过程以及所用到技术能够大致了解;D提的要求很简练“好用、实用”;E项目建设热情较高,但不懂软件的过程,前期也只能提出类似“原型建立之后再提具体要求”的意见;CF基本与软件部分的建设没有直接的利害关系。项目恰好处在需求阶段,如何能够在保证需求发掘的质量的同时配合项目进度呢?

这种情况似乎让项目无从下手。调研吧,无人配合,总不能一天到晚冒着炎炎烈日穿街过巷走访所有社区居民:你们需要什么?A也不允许你这样做;与AD商量吧,统一的大方向变了戏法说成20个(其实都是一个意思),不会对具体的需求形成有效的帮助。从哪里开始,哪条路最近呢?首先从当前的主要矛盾出发:如何才能形成一份用户认可的需求?

首先分析这个问题从“需求”说起。“需求”其实是两个词:先有“需”,再有“求”。很明显,我们的用户有“需”,也有“求”,所以我们的目标是确定的。那么现在剩下的就是“用户认可”了。在如此一个阶级繁杂的项目中,你无法去奢求A会直接认可B的用户需求,A需要的是所有的阶级都认可这个需求。

看起来似乎让所有阶级认可比让A认可复杂多了。其实不然,A的特殊地位决定了所有的阶级都是围着A的,只要A认可了,其他的阶级自然也认可了;但如今加入了更多的人来认可这份假定的需求,可以斡旋的资源反而更多了。换言之,CDEFG会参与到影响整个需求的认可进程。

管理学有个原则:复杂的事情简单化。我们直接在现存系统的需求上补充搜集ACDEFG对于项目的需求(此时,我们的搜集策略是单独与各个阶级分别沟通),并勾画出其中相互冲突的部分,在文档的编写过程中进行相应处理。在一周时间内,我们开始碰头讨论这份初稿(此时,我们特意安排了ABCDEFG各方的人员代表务必参加)。一个下午的时间很短,形成统一意见也很快。讨论结束后的签字是对所有阶级认可的直接诠释。

  【意料之外】

    在完成项目1.0版本的开发之后,我们按照事先制定的项目进度计划以及一份详细的培训与安装调试计划,准备在现场实施。一切都似乎很顺利!各方面的合作也似乎十分愉快。安装调试如期完成,此时,运营商提出了新的要求:不要直接进行培训工作,给几天的时间让他们的人员体验一下系统。我毫不犹豫的答应了。

    几天的时间足以改变很多,运营商的态度起了较大转变。我的隐忧也变成了现实:对于并不实心用事的D,进度他们也很关心,不过他们关心的是进度被拖了多久,怎么样才能拖得更久。他们提出了自己的意见:系统根本就无法使用。我想了很多办法去沟通,甚至让他们逐条逐条的罗列出来哪些不可用,效果不佳:“上有政策,下有对策”是不错的,今天提一点,明天两点的敷衍是他们的特长。无奈之下,只能找A、找G去协调,G很积极,可惜经验不足,无法对付DA不太懂具体的技术,不太愿意懂是否好用,协调的结果很符合习惯:能改的就尽快改,不能改的记下来再解决。总之,就是一切为了进度。没有协调出来问题的解决办法,倒是新的问题又付出水面:进度。也终于明白了什么叫“屋漏又遭连夜雨,漏船偏遇打头风”。如果在这种毫无效率的沟通中无休止的缠斗下去,势必一损俱损。

    心急如焚是无谓的消耗,并不能有助于解决问题。进度,实用,好用……无数个名词充斥着脑海。如何才能说服可恶的D呢?可转念一想,在利益面前,其实可恶的不只是DA也很可恶,不是吗?G也是,F也是…就连B也是。问题的根源只是因为他们都代表了自己的角色,为了自己的利益。

【情理之中】

你只有了解它,明白它,甚至是领悟它,才能真正控制它。

在这个案例中,对于A是这样,对于D是这样,甚至对于ABD之间的关系也是这样。从杂乱无章的千头万绪中,我首先去寻找当前的主要矛盾:A的盲目进度追求是一个;D的蛮横无理取闹的需求也是一个。细想一下,A的进度要求其实不只是针对B,它同样也针对E,针对DD的需求却明显只是针对BB的进度是最容易让整体进度延后的突破口,他们选的很准。

明白了AD的用意的确是情理之中,从而也就知道如何周旋。记得每位病人进行手术之前,医院总会让病人家属签下“生死状”,申明每个手术都是有风险的。项目管理也是这样,真正去执行一个决定的时候,会有两个结果:成功或者失败。尽管已经明白了问题的症结所在,当前要做的却远非去解决问题,而要先制定解决的计划,规避实施的风险。

针对ADB形成的三角,如果贸然行事,直接向A诉苦或者指出问题的症结在D等等类似的做法是并不明智的,因为你会的D也会。所以,最终A还是不知道到底相信谁,或者他根本就不会去考虑相信谁的问题。结果还是情理之中的:无休止的缠斗。项目又将进入新一轮的延期,这正在向D的目标一步步靠近。

其实,此时我们忽略了一个极其重要的角色:E。软件的使用者除了C之外,E也需要使用其中的一部分。不止是C对软件的是否可用有发言权,E也有。鉴于项目过程中,CE多次的冲突,相信应该很容易建立BE之间的互信关系。此外,我们还忽略了一个重要的角色:G。没错,此时最佳的投诉人选是G。于是,经过与G的反复沟通,以及让G进一步了解系统的1.0版本和与E的沟通,证实了系统的初步可用性,也避免了AB形成不良印象,还有就是避免了和D的正面直接冲突,同时发掘到了我们统一阵线的战友E。经过AD的沟通之后,B此时选择与D进行交流是最有效的。不出所料,D很快同意了先进行初步培训,并同意了开始录入一些初始数据和一些专业数据。

事情似乎正在一步步向好的方向发展,也就是向角色B所代表的阶级发展。此时,D的无休止拖延计划也在无休止地执行新的方案。尽管录入了数据,但他们在数据的格式上进行了故意的消极处理:所有的数据根本不进行分类,E的利益受到直接影响,因为他无法正常开展工作。没有多久,各个阶级重新回到谈判桌上,没有太费周章,精于统一阵线的E很快通过B在技术上进行了可行性论证,通过BF进行了数据流量论证,良好的阶级基础没有让D的计划存活太久。

一切开始重回正轨。针对项目的特点(数据录入量十分巨大),以及AD的特征,B要达成的目标很简单:如何让系统尽快上线。随着专业数据的不断输入,D投入的工作量日益加大,成本也不断增加;B方面系统培训按部就班;A还是在一旁不断的关注着项目的进度;G通过进一步对系统的了解,已完全成为B的代言人;此时,CEF的工作已进入尾声。

一场巨大的缠斗风波在无声无息中被扼于平静。系统整个后期工作十分顺利,D的无心用事也被显露无遗,不得不在极度挣扎中忍气吞声,痛苦的看着项目顺利推进。因为他们无法接受项目的进展顺利,但是,他们更加无法接受自己已经投入的成本和已经输入的大量数据,因为B按照自己提出的需求修改了而丢失。

此外,D在试运行期间都没能再提出一些实质性的修改意见。至此,A的急功近利急于求成,CF的置身事外置若罔闻,D的狗急跳墙苟延残喘,E的老于世故老练沉着都给人留下了深刻的印象。

   【结语】

       阶级斗争由来已久,合理利用其中的规律将会让你事半功倍。

       你的敌人的敌人是你可以信任的朋友。