zoukankan      html  css  js  c++  java
  • 转发:IT行业中的甲方乙方关系

    原文:http://byteh.blog.51cto.com/141786/1004046/

    混IT,必须理解甲方乙方

    By 韩宇斌 2012-09-23

    9月初,修改了QQ签名,把“甲方乙方”放在了最前面,似乎标志着我找到了最近工作中问题的症结所在,于是乎终于有心情再写一篇文章了。

    准备写之前,先搜索了“甲方乙方”,严肃客观的了解一下概念,有些许意外的是排在前面的全是关于电影《甲方乙方》,让我对着文字回忆了一把剧情,那经典的“打死也不说”……

    换搜索关键词:“甲方 乙方(注意空格)”“甲方和乙方”,于是找到了如下的文字,难道“甲方”和“乙方”应该是彼此独立的?

    民事法律关系中的两个平等主体。用于合同中的平等主体代称!

    甲方一般是指提出目标的一方,在合同拟订过程中主要是提出要实现什么目标。乙方一般是指完成目标,在合同中主要是提出如何保证实现,并根据完成情况获取收益的一方。 

    在合同过程中,甲方主要是监督乙方是否完全按照要求提供自身需求的满足。 

    在合同执行结束后,甲方一般需要付出资金或者其他,以获得自身需求所需要的东西。

    “拿人钱财,替人消灾”,通俗点说,甲方就是出钱的,乙方就是消灾的。

    在武侠小说的江湖世界中,似乎总有这样的情节:甲方(某有钱或有势的人)因为一些原因,希望某些目标人消失,就去找乙方(职业杀手或者高手)来帮助自己达到目的。

    在IT人的“江湖”世界中,也有类似的情节:甲方(客户)希望解决生产运营中的问题或者提高效率,就去找乙方(IT企业或者IT从业者)来帮助自己达到目的。

    武侠的江湖世界中,不知道是不是由于“理想化”的成分更多,情节通常会这样发展:乙方获得了需求,收了定金,独立或则在小头目的带领下,开始朝着“杀掉某些人”这个目的努力。难杀的主,佣金自然高些,如果甲方要求一个月内必须消失,佣金将必然会更高。任务完成,甲方会付给乙方剩余的佣金,没有天灾人祸(比如甲方先被灭了),甲方绝对不会因为目标是朝前趴着倒下而不是向后仰面倒下等等原因赖掉剩余佣金。 

    在IT人的“江湖”世界中,比武侠的“江湖”更复杂些。甲方提出要求,乙方分析和理解需求也是必须的,前期要评估难度评估实力确定可行性,中期要反复校正是否和甲方的目的一致,后期要对着需求去验证是否履行了合同。乙方带领团队完成任务并交付的人,叫项目经理。似乎没有什么特别的,但总有IT人会理解为什么很多IT项目都失败了:无法准时完工按时交付,交付后无法满足甲方的要求,虽然交付但一方或双方的利益已经受损……

    武侠的江湖中,乙方只需要“让目标消失”,至于为什么让目标消失,不是乙方关系的事情,甲方通常也不会告诉乙方。如果甲方只是要求“目标倒下“,就不会告诉乙方”杀掉他“,因为开价会明显不一样。

    IT的江湖中,乙方需要明白甲方的目标,还要明白甲方的目的,否则完成的东西就不一定是甲方真正想要的。没有经历过甲方乙方形式的项目开发的同学,也许会问为什么甲方不能把自己要做的表述清楚呢?为什么甲方昨天说的和今天就不一样呢?乙方明明是按照甲方需求中的描述完成了功能的开发,为什么甲方就是不认可呢?答案应该是有很多,而且还得看场景,下文会用我自己的实例尝试去表述一些原因。

    一、我 在“传统”软件公司看甲方乙方

    软件公司,开始在自己的日常词汇表里面变成“传统软件公司”,应该是和自己进入互联网公司有关,因为周围的人总是这么说,应该是相对于“移动应用软件”而言的。

    传统软件公司,应该还可以分为项目型公司和产品型公司,自己恰好在两种类型的公司都有从业经历,但本文主要说项目型公司。

    在项目型公司,甲方和乙方的概念更强些。在这家公司,曾经参与的一个较大项目,我们公司自然是负责完成项目开发的乙方,而客户就是提出需求立项招标的甲方。项目虽然比较令甲方满意的完成并交付,乙方也收到了全部的款项,但是按照合同规定的期限却是延期了,严格意义上也是失败的项目。现在回过头来看,其原因主要是需求的不确定和信息的不对称。

    公司其实在石油行业还是染指较多的,我参与的这个项目中,甲方的业务是非常专业的,不是简简单单的信息化。对于计算机专业的人来说,是绝对的外行,沟通起来就会有比较严重信息不对称。打个比喻就好比我们在岸上看湖里的水,感觉比较浅,一旦跳进去才发现原来水还是比较”深“的。比这个更有挑战的是,从项目开始到验收,甲方的主要项目负责人换了3次,每个人都有自己的所长和对业务的理解,每个人都会认为自己的工作方式是最正确的……

    我们的工作方式基本是:千方百计地”逮“甲方了解需求(他们很忙),确认需求,然后就是设计开发,希望能做出一个满足甲方需求的产品。开始前,尽量的去要求甲方给出所有需求细节并理解,完成了结果ZZZ。一旦出了问题,就会觉得当时是按照甲方某某某的XXX需求并确认了YYY等疑问,出了WWW问题是甲方不知道自己想干啥,甚至试图追求让甲方签字确认自己的需求这种手段……

    事实上,更让老板觉得生气和被动的是,当时的项目组并没有采取任何确认需求的书面手段,全是口头确认。合同规定的交付期限即将来临,而第2任的甲方项目负责人几乎把第1任的业务思路完全推翻……仔细的斟酌合同的内容,我们没有履行完乙方的责任,我们也没有任何证据表明我们的软件是按照甲方的要求来做的,乙方的责任出现延期不但不能全额付款,还要缴纳违约金,然后申请延期,老板真的很生气……

    后来,经过双方沟通与协商,把合同中明显没有提到的内容加到了“延期申请书”作为了其中的延期原因之一,由甲方的名义走了申请延期的手续……

    项目终于验收了,然后项目经理就辞职了。老板比较满意我在项目中表现,维护期(因为有尾款要付)就基本由我负责了。在独自一人出差去甲方企业,履行合同规定,办理尾款手续时,我总结了之前的经验,小心翼翼的拟写了一份类似”工作确认书“的文档,请甲方的领导为我的工作打分并签字确认……

    甲方就是甲方,乙方就是乙方,即使你和一些人相处愉快,但拿出来合同,依旧是契约关系!

    二、我到了“不差钱”的互联网公司看甲方乙方

    毛毛:爷爷,我饿了 

    赵本山:这儿有面条没? 

    小沈阳:78元一碗 

    赵本山:啥面啊?这么贵? 

    小沈阳:苏格兰打卤面 

    赵本山:是不是卤子贵呀? 

    小沈阳:卤子不要钱。 

    赵本山:先来一碗卤子吧,孩子饿了 

    小沈阳:妈呀,没这么上过啊。

    赵本山:那是我没来,我要来你们早就这么上了,去吧去吧。

    小沈阳: 这老爷子 我要说面条不要钱还要面条了呢。

    没错,上面就是赵本山、小沈阳著名的春晚小品《不差钱》中的台词,我觉得自己有时候就向小沈阳在小品中的处境……

    假设的甲方提出的需求是“喝卤子”,我以传统的乙方的心态就接受了,虽然也会觉得“ 妈呀,没这么上过啊”,但终究还是照办了。过了若干时间,甲方感到“口干舌燥”没法子唱好歌上星光大道了,于是就会说,你怎么能让我喝卤子呢,你不知道那东西咸死人吗?我以乙方的心态会说:是您自己要的卤子呀,我说没上过,那个谁还说他要来早这么上了呢!

    你觉得甲方活该吗?我真的就没有责任吗?

    在传统的行业,也许我没有错,或者我能找到不需要乙方负主要责任的合适理由,最多我不算一个优秀的项目经理,不至于对所在的企业造成巨大损失。但是在互联网公司,我的思路就是错了,甲方乙方的观点在这里是很严重的“思想问题”。

    CTO说,“你觉得互联网公司和传统软件公司的最大区别是什么?”

    我回答了速度、节奏、模式、用户等等内容……

    CTO说,“你没有抓住关键!你所呆过的传统软件行业几乎都是建立在原有业务规则已经成型,你们的工作只是信息化而已!”

    我感觉似乎突然触电了,思索了若干秒后,点了点头,话都说不出来。

    CTO继续说,“互联网的特点在于没有现成的规则,我们所做的几乎全都是创新甚至全都是尝试,充满了很多不确定性,所以我们节奏必须要快,必须要不断的试错,从若干次尝试中找到正确的……成功的互联网企业,对开发人员的要求更高,要能够主动适应变化……项目经理,不能只用甲方乙方的心态降低对自己的要求,完成了某某说的就大功告成……”

    继续拿“不差钱”说事,调研需求之前要明白团队的最终目标不止是吃完面,而是要上星光大道,无论吃面还是喝卤子,只是实施的细节或方法。

    上菜前---

    小沈阳:老爷子,卤子咸,喝了对嗓子不好,您再考虑考虑?孩子这个机会难得,不要因为一碗面影响了前程。如果不要进口的非转基因的苏格兰面粉,会便宜些。

    赵本山:来碗卤子,哪那么多废话!

    上菜后---

    小沈阳上菜: 孩子,饿的话先喝碗卤子,慢慢的喝,这玩意贼咸。我给你端了碗水,就着一起喝,啊!(对赵本山说)老爷子,门口有买烧饼的,是不是买俩让孩子就着吃,那卤子真的贼咸。

    这样一来,是不是会好些?

    其实理解“甲方乙方”并不只是在IT行业有用,哪行都有各自的门道和规矩,合同对双方是个法律层面的约束,要重视!但是好的合作,甚至扩展到好的员工,往往需要做的更多一些。

    找到了症结,绝不意味着能够马上找到灵丹妙药,药到病除,似乎又有犯病的意思,疗程不足,要坚持服药加强锻炼啊…… 

  • 相关阅读:
    PointToPointNetDevice doesn't support TapBridgeHelper
    NS3系列—10———NS3 NodeContainer
    NS3系列—9———NS3 IP首部校验和
    NS3系列—8———NS3编译运行
    【习题 7-6 UVA
    【Good Bye 2017 C】 New Year and Curling
    【Good Bye 2017 B】 New Year and Buggy Bot
    【Good Bye 2017 A】New Year and Counting Cards
    【Educational Codeforces Round 35 D】Inversion Counting
    【Educational Codeforces Round 35 C】Two Cakes
  • 原文地址:https://www.cnblogs.com/ambon/p/4445256.html
Copyright © 2011-2022 走看看