TW洞见 | 公益IT的精益之路
今日TW洞见
文章作者来自ThoughtWorks：熊节。图片来自网络。
本文版权归【ThoughtWorks中国】（微信ID：思特沃克ThoughtWorks）。任何个人或单位未获得明确的书面许可，得对本文内容复制、转载或进行镜像，否则将追究法律责任。
不止一位在公益机构工作的朋友对我说：现在大家都在谈数字化、谈“互联网+”，我们机构也想用互联网思维武装自己，你看我们是不是应该开发一个某某某系统……听他们畅想自己的数字化宏图，在这场对话中扮演“IT专家”角色的笔者往往却只能泼冷水地说：开发系统太贵了。笔者在一篇题为《开发软件有多贵》的文章里曾粗略估计，自行建设并拥有一个普通IT系统的成本可以轻易地达到上百万人民币。这个级别的开销对于普通的公益机构来说，无疑是难以承受的。
应该看到，大多数组织、大多数人看待IT的方式，本来就是由少数几家大企业通过不懈的广告宣传给培养出来的。也就是说，“主流的”IT视角是为金融、电信、零售……这样的大型商业机构服务的，因为这些机构才是IT大厂商的主要顾客。这种视角的差异，决定了主流的IT话语未必适用于公益机构。1968年，一位名叫梅尔文·康威的程序员指出：IT系统的结构与组织机构的结构相匹配。按照“康威法则”我们不难明白，为什么传统上大家观念中的“企业应用”都是大规模、整体化、高复杂度、高定制度的软件系统，例如ERP、CRM等等——因为现代的大企业正是这样，由大批专门人才紧密结合成一个个部门、再组合成高度内聚的商业机构。
然而公益机构的结构并不经常像企业这样紧密内聚。很多时候，公益机构的运作是以少量全职员工加上捐赠者、志愿者、政府等各方力量共同构成的松散组织来进行。当组织结构的性质变化，照搬企业IT的建设思路自然会遭遇困难。且把定制IT系统高昂的成本放在一边不谈，公益机构既难像企业那样对志愿者进行高密度的IT培训，又难像企业那样严格约束志愿者，实施定制IT系统的难度可想而知。更不用说公益机构面对的问题域往往不像商业领域那样有清晰的定义，这又给IT建设增加不少变数。
面对成本受限又充满未知的领域，《精益创业》提供了一条切实可行的路径。以“开发-度量-学习”的循环快速迭代，精益创业方法提倡验证性学习、灵活调整方向、以及“快速地失败、廉价地失败”。作者介绍了一个创业者开始网上订餐业务的故事：这位创业者没有开发任何复杂的软件系统，只是手工把几家餐馆的菜单放上网，然后自己接电话收订单、自己到餐馆取餐、自己送货兼收款，以此验证自己的点子，随后在营业额上升、人手不敷的时候才开发软件来自动化。这种建设IT系统的方式，对于公益机构而言不无借鉴意义。
沿着精益创业的路径，公益机构不太可能建设出像企业应用那样高度集成的“IT系统”，更有可能建设出一系列简单IT工具组成的“IT生态”：用WordPress之类的工具搭建的简单网站用作机构介绍；微信订阅号用于传播内容；金数据用于收集捐赠者信息和招募志愿者；内部的捐赠者管理和志愿者管理则用有版本管理的Excel表单完成……有趣的是，这样的IT生态却恰好与公益领域多方协作的生态结构相匹配，又因为大量借用现有软件工具而降低了所有使用者的学习曲线，于是这样“生长”出的IT系统不仅成本较低，而且往往比以企业模式集中实施的IT系统更为使用者们接受。
借用现有软件、让IT生态“生长”，不表示公益机构的IT建设不需要规划设计，只是设计的重心不再是单一的IT系统，而是与公益生态对应的IT生态。《商业模式新生代》把听来高冷的“商业模式”放在一张纸上描绘出来，帮助设计者思考一个机构、一个“生意”最根本的要素：顾客、价值、渠道、客户关系、收入来源、核心资源、关键操作、重要合作、成本结构。虽然公益不是商业，但这种灵活而可视的方法同样有助于公益机构厘清生态系统中各方的关系与协作模式，进而定义与之匹配的IT生态。
媒介学家德布雷说，吸引人关注某一问题最好的方式是通过互动，“让观众参与”。在思考公益机构的IT规划与建设时，需要跳出企业IT内聚、内向的视角，纵观整个生态系统，设计各种IT工具在各方交互中扮演的角色。对于资金有限的公益机构而言，这可能是一条更实用且效果更佳的数字化路径。
各类干货洞见精选职位招聘
活动预告总结长按二维码可直接关注我们~