软件外包的坑,他山之石能填否?
发布时间:2024-07-16 03:19

在知乎上看到ID“已退乎”发的帖子——“外包公司的选择与外包客户的选择-甲方乙方的坑”,其中列出了10个软件外包业务中常见的坑,如下:
大多数情况下甲方都提不出合适的需求,甚至连想要什么都说不明白搞不清楚。

甲方的企业中或者团队中没有懂得互联网或者IT方面的人,甚至整体年龄偏大,互联网和 app 了解不多。

甲方企业或者团队普遍不具备运营能力,或者低估了后期运营的难度与投入。

预算不足,以及对持续投入的预估不足,预算难以到位。

对于企业外包项目,很多时候甲方对接人没有足够的权限去调用足够多的资源,甚至很多时候只是个传话筒。

甲方对于项目重视程度不够。企业项目表现在把外包开发当成了普通采购,而创业项目甲方过于注重商业模式等商业运作,并没有好好考虑过外包软件的各个方面。

项目的实际需求随着市场改变而变化很快(企业业务软件也是如此)。

甲方在项目没有经过调研,经过计划,连需求都提不出来的情况下,就要求提早报价,而乙方不得已提早报价,甲方后面拿这个报价去卡乙方。

乙方迫于工期压力与业绩压力,不得以为甲方妥协,报出不现实的开发时间,并在开发中采取拖延战术来延长开发周期。

在业务软件外包时,甲方将软件外包服务当作普通采购,以为是一锤子买卖,考虑不长远。

帖子作者因为个人原因没有对所列问题一一作答。但这些问题挺接地气,是普遍存在的行业问题,绝对是实战经验的总结。

逐条归类,不难看出这些“坑”的根本原因是甲方对自身的需求不清晰,更不清楚用IT手段实现这些需求需要哪些资源和流程,但事情又不得不做,盲目启动,引发一系列的连锁“坑”。

术业有专攻,甲方也确实有苦衷,IT技术是有相当门槛的,各行企业自己有IT部门的都不多,更何谈有既懂业务又懂IT的人才,不懂又怎能想明白说清楚?

以前(至少十年前)的软件开发可以提前制定方案,成年累月的实施,前提是系统需求变化不大,不快,相对固定,有规律,模块化。如今,别说IT实现了,就业务本身,经常三五个月就可能发生根本性的变化,市场风云莫测,不是人力能够决定的,那么软件开发怎么能未雨绸缪呢?

那什么样的软件开发工作方法能适应当下的市场变化呢?

今天我们用“他山之石”来启发一下思路。

他山之石

何志森,一位“非主流”建筑设计师,四年前因为在“一席”的一场演讲为大众所知。下面先简单介绍一下他的故事。

何志森2010年开始读建筑学博士。第一年主要做参数化,每天用电脑画各种各样很漂亮的图。一次他回福建老家去华侨大学拜访一位老师的时候,偶然看到了小贩用晾衣竿把盒饭传递给围墙后面的学生,当时就被原地震撼了——“这是我们设计师设计的围墙,他们用一根晾衣竿就把它给捅破了。”

回到墨尔本之后,他毅然决定不再做参数化了,转而开始做人文实地考察。他用了四年时间跟踪了一位在围墙上卖盒饭的小哥,完成了他的博士论文。这四年里,他目睹了平凡的打工人是怎样用生存智慧和草根策略,把设计师在电脑上做的各种各样的图、在现实中做的各种各样的空间给颠覆的。

2015年他博士毕业回国,发起了一个Mapping工作坊,开始了三年在中国各大建筑院校间边流浪边教学的游牧式教研生活。

那么Mapping是什么?他用一个具体的例子说明。下图左边是纽约曼哈顿地图,右边这个地图,是一个穆斯林在曼哈顿生活了20年之后,把曼哈顿每一个摄像头都标出来了,最后发现三条没有摄像头的路。左边是地图,右边是Mapping——把看不到的东西挖掘出来,就像是侦探一样。

他的Mapping工作坊给参与的学生提的要求也很明确,有这样几个步骤。 

选择一个目标,可以是人,可以是物体,越小越好。

你要长时间地跟踪观察这个目标。

你要把自己变成目标,如果你跟踪研究一条狗,那么就把自己变成狗。

你要发现这个目标与城市之间的关系,呈现这些关系,然后基于这些关系提出你的设计主张。

他的演讲中提到好几个例子,感兴趣的可以自己看。这里只展示一个典型案例。

他在华南理工大学建筑学院做的一个工作坊,有一组学生选择跟踪一位卖冰糖葫芦的阿姨,想通过近距离观察阿姨的售卖轨迹,去理解小贩是如何使用设计师设计的公共空间。

几天的跟踪和观察,让学生们感同身受地体会到阿姨生存的不易,不仅要时刻逃避城管的驱赶,还不能喝水——为了避免上厕所的麻烦,从凌晨五点以后就不能喝水了,糖葫芦不卖完,不敢喝水……

学生们先是用电脑建模,为阿姨设计了三条逃跑路线,可以在最短的时间内逃离广场;之后又专门为阿姨设计了一个变形金刚售卖车——可以变成一个厕所,可以变成一个卖花的、卖衣服的流动摊位,不仅只是卖冰糖葫芦,在不同的地点有不同的变法。

何志森说:“如果没有调查跟踪,没有把自己的角色变成她,那么学生永远不可能设计出这样子的作品。”

借以攻玉

他的演讲很有启发性,充满人文关怀和独立思考,他的Mapping工作坊一直在做,有自己的公众号,很多有意思的案例故事。这里我们还是回到软件行业,虽然说建筑设计和软件开发隔行如隔山,但性质相通——都是专业技术门槛比较高,通过专业技能为人们的生活和生产提供便利。

他提出的Mapping思维就很像敏捷开发,真正的目标导向,以人为本,拥抱变化,不能纸上谈兵,闭门造车,一定要近身观察和了解你要服务的人的生活轨迹、工作流程、商业逻辑,还要通过人与人的沟通和互动,先达成彼此一致的目标和信任,不断磨合,最终才能做出性价比最好的设计,而且还要与时俱进。

抛开实际操作中可能会遇到的人情事故(甲方、乙方的企业文化、管理风格、企业政治……)和实际困难不谈,本质上,好的软件开发完全可以借鉴何志森Mapping工作坊的原则:

明确一个目标,开发要实现什么功能,越具体越好。

功能实现都涉及哪些环节?底层商业逻辑是什么?谁是这个功能的实际使用者?你要长时间地跟踪观察这些使用者,了解他们的需求细节。

你要把自己变成目标,变成实际的使用者。如果你跟踪研究一条狗,那么就把自己变成狗。

你要发现这个目标与企业整体业务(战略)之间的关系,呈现这些关系,然后基于这些关系提出你的设计主张。

还是老生常谈的那句话,真理是相通的,在不同的行业,做事的方法论、价值观可能有不同的称谓,但本质往往相同。

有人可能会说实际情况复杂得多,理论上行得通,现实中寸步难行。是,没错,“现实”总是难以撼动的,但并不是撼不动。谋事在人。何志森做Mapping工作坊的真实原因也是想在高校找工作,却一直没找到,甚至引来同行的非议和舆论的质疑……但这不影响他两次走上一席的讲坛,用他的故事和案例给千千万万人带来启发;不影响他的工作坊给参与者的生活、工作甚至价值观带去一些转变,一抹亮色……

尽人事,听天命。根据二八定律,在样本中占大多数的,不一定是正确的。无论你处在什么位置,都可以有自己的选择。软件行业中也已经有敏捷的践行者。

何志森说:“我觉得设计这门教育不是教那些围墙里面的学生如何画图,如何被规范,而是教他们如何思考和创造生活。我们的学生离生活太远了,学生离开学校时带走的应该是一个富有人性的价值观,而不是满脑冰冷的规范。只有这样子回到工作的时候,他的设计才会考虑到不同人群的感受,才会真正地接地气。”

对软件开发,亦如是。

服务热线
在线咨询