在知乎上看到ID“已退乎”发的帖子——“外包公司的选择与外包客户的选择-甲方乙方的坑”，其中列出了10个软件外包业务中常见的坑，如下：
大多数情况下甲方都提不出合适的需求，甚至连想要什么都说不明白搞不清楚。
甲方的企业中或者团队中没有懂得互联网或者IT方面的人，甚至整体年龄偏大，互联网和 app 了解不多。
甲方企业或者团队普遍不具备运营能力，或者低估了后期运营的难度与投入。
预算不足，以及对持续投入的预估不足，预算难以到位。
对于企业外包项目，很多时候甲方对接人没有足够的权限去调用足够多的资源，甚至很多时候只是个传话筒。
甲方对于项目重视程度不够。企业项目表现在把外包开发当成了普通采购，而创业项目甲方过于注重商业模式等商业运作，并没有好好考虑过外包软件的各个方面。
项目的实际需求随着市场改变而变化很快（企业业务软件也是如此）。
甲方在项目没有经过调研，经过计划，连需求都提不出来的情况下，就要求提早报价，而乙方不得已提早报价，甲方后面拿这个报价去卡乙方。
乙方迫于工期压力与业绩压力，不得以为甲方妥协，报出不现实的开发时间，并在开发中采取拖延战术来延长开发周期。
在业务软件外包时，甲方将软件外包服务当作普通采购，以为是一锤子买卖，考虑不长远。
帖子作者因为个人原因没有对所列问题一一作答。但这些问题挺接地气，是普遍存在的行业问题，绝对是实战经验的总结。
逐条归类，不难看出这些“坑”的根本原因是甲方对自身的需求不清晰，更不清楚用IT手段实现这些需求需要哪些资源和流程，但事情又不得不做，盲目启动，引发一系列的连锁“坑”。
术业有专攻，甲方也确实有苦衷，IT技术是有相当门槛的，各行企业自己有IT部门的都不多，更何谈有既懂业务又懂IT的人才，不懂又怎能想明白说清楚？
以前（至少十年前）的软件开发可以提前制定方案，成年累月的实施，前提是系统需求变化不大，不快，相对固定，有规律，模块化。如今，别说IT实现了，就业务本身，经常三五个月就可能发生根本性的变化，市场风云莫测，不是人力能够决定的，那么软件开发怎么能未雨绸缪呢？
那什么样的软件开发工作方法能适应当下的市场变化呢？
今天我们用“他山之石”来启发一下思路。
他山之石
何志森，一位“非主流”建筑设计师，四年前因为在“一席”的一场演讲为大众所知。下面先简单介绍一下他的故事。
何志森2010年开始读建筑学博士。第一年主要做参数化，每天用电脑画各种各样很漂亮的图。一次他回福建老家去华侨大学拜访一位老师的时候，偶然看到了小贩用晾衣竿把盒饭传递给围墙后面的学生，当时就被原地震撼了——“这是我们设计师设计的围墙，他们用一根晾衣竿就把它给捅破了。”
回到墨尔本之后，他毅然决定不再做参数化了，转而开始做人文实地考察。他用了四年时间跟踪了一位在围墙上卖盒饭的小哥，完成了他的博士论文。这四年里，他目睹了平凡的打工人是怎样用生存智慧和草根策略，把设计师在电脑上做的各种各样的图、在现实中做的各种各样的空间给颠覆的。
2015年他博士毕业回国，发起了一个Mapping工作坊，开始了三年在中国各大建筑院校间边流浪边教学的游牧式教研生活。
那么Mapping是什么？他用一个具体的例子说明。下图左边是纽约曼哈顿地图，右边这个地图，是一个穆斯林在曼哈顿生活了20年之后，把曼哈顿每一个摄像头都标出来了，最后发现三条没有摄像头的路。左边是地图，右边是Mapping——把看不到的东西挖掘出来，就像是侦探一样。
他的Mapping工作坊给参与的学生提的要求也很明确，有这样几个步骤。
选择一个目标，可以是人，可以是物体，越小越好。
你要长时间地跟踪观察这个目标。
你要把自己变成目标，如果你跟踪研究一条狗，那么就把自己变成狗。
你要发现这个目标与城市之间的关系，呈现这些关系，然后基于这些关系提出你的设计主张。
他的演讲中提到好几个例子，感兴趣的可以自己看。这里只展示一个典型案例。
他在华南理工大学建筑学院做的一个工作坊，有一组学生选择跟踪一位卖冰糖葫芦的阿姨，想通过近距离观察阿姨的售卖轨迹，去理解小贩是如何使用设计师设计的公共空间。
几天的跟踪和观察，让学生们感同身受地体会到阿姨生存的不易，不仅要时刻逃避城管的驱赶，还不能喝水——为了避免上厕所的麻烦，从凌晨五点以后就不能喝水了，糖葫芦不卖完，不敢喝水……
学生们先是用电脑建模，为阿姨设计了三条逃跑路线，可以在最短的时间内逃离广场；之后又专门为阿姨设计了一个变形金刚售卖车——可以变成一个厕所，可以变成一个卖花的、卖衣服的流动摊位，不仅只是卖冰糖葫芦，在不同的地点有不同的变法。
何志森说：“如果没有调查跟踪，没有把自己的角色变成她，那么学生永远不可能设计出这样子的作品。”
借以攻玉
他的演讲很有启发性，充满人文关怀和独立思考，他的Mapping工作坊一直在做，有自己的公众号，很多有意思的案例故事。这里我们还是回到软件行业，虽然说建筑设计和软件开发隔行如隔山，但性质相通——都是专业技术门槛比较高，通过专业技能为人们的生活和生产提供便利。
他提出的Mapping思维就很像敏捷开发，真正的目标导向，以人为本，拥抱变化，不能纸上谈兵，闭门造车，一定要近身观察和了解你要服务的人的生活轨迹、工作流程、商业逻辑，还要通过人与人的沟通和互动，先达成彼此一致的目标和信任，不断磨合，最终才能做出性价比最好的设计，而且还要与时俱进。
抛开实际操作中可能会遇到的人情事故（甲方、乙方的企业文化、管理风格、企业政治……）和实际困难不谈，本质上，好的软件开发完全可以借鉴何志森Mapping工作坊的原则：
明确一个目标，开发要实现什么功能，越具体越好。
功能实现都涉及哪些环节？底层商业逻辑是什么？谁是这个功能的实际使用者？你要长时间地跟踪观察这些使用者，了解他们的需求细节。
你要把自己变成目标，变成实际的使用者。如果你跟踪研究一条狗，那么就把自己变成狗。
你要发现这个目标与企业整体业务（战略）之间的关系，呈现这些关系，然后基于这些关系提出你的设计主张。
还是老生常谈的那句话，真理是相通的，在不同的行业，做事的方法论、价值观可能有不同的称谓，但本质往往相同。
有人可能会说实际情况复杂得多，理论上行得通，现实中寸步难行。是，没错，“现实”总是难以撼动的，但并不是撼不动。谋事在人。何志森做Mapping工作坊的真实原因也是想在高校找工作，却一直没找到，甚至引来同行的非议和舆论的质疑……但这不影响他两次走上一席的讲坛，用他的故事和案例给千千万万人带来启发；不影响他的工作坊给参与者的生活、工作甚至价值观带去一些转变，一抹亮色……
尽人事，听天命。根据二八定律，在样本中占大多数的，不一定是正确的。无论你处在什么位置，都可以有自己的选择。软件行业中也已经有敏捷的践行者。
何志森说：“我觉得设计这门教育不是教那些围墙里面的学生如何画图，如何被规范，而是教他们如何思考和创造生活。我们的学生离生活太远了，学生离开学校时带走的应该是一个富有人性的价值观，而不是满脑冰冷的规范。只有这样子回到工作的时候，他的设计才会考虑到不同人群的感受，才会真正地接地气。”
对软件开发，亦如是。
