这里是译者的一点题外话，翻译《数字时代的企业进化》过程中，我也在不停地思考自己身边的数字化案例，包括由我所在公司提供咨询及开发服务的企业，诚然，与书中的大型企业的数字化相比，我们所经历的更多是中小企业的数字化转型，虽说其单体规模不大，但麻雀虽小，五脏俱全，数字化转型的方方面面均已涉及。从我们接触到的客户来看，大部分来自服务业或加工业，提出数字化转型的方式也非常简单——开发一个APP/小程序或者开发一套系统！
开发的目的是什么呢——完成线上下单及发货或服务闭环，也统筹企业资源到对应的订单上（以前是人工调度资源，业务一多就转不过来了），自动统计分析业务数据及员工绩效，定制开发一些促销功能，运用社交网络做一些数字化营销等等。
也有将业务拓展架构到数字化的服务业高层管理者，比如总部要在更大范围的区域开设分店，他希望借助于数字化，只需招聘新员工完成标准培训，数据导入定制开发的业务系统，快速“复制”“粘贴”一个新门店到他的企业版图，新店即可开门营业。
《数字时代的企业进化》提到的运用数学公司未来力量的大思维及领导力，前面这位企业高层“复制”“粘贴”拓展门店的想法，真的有异曲同工之妙，大胆且富于想象力。我们也给予这家企业更长远的数字规划建议——有更多门店及客户的时候，更深入地挖掘数据来优化当前的业务逻辑模型，从而更高效合理地配置服务资源，获得更高的客户满意度及忠诚度。
说到这里，有一个非常关键的问题我们还没谈到，《数字时代的企业进化》书中也没有详细的探讨，那就是如何来进行数字化所需的软件开发？
没有开发，数字化的第一步无法迈出，所有的数字化的好处通通无从谈起！
怎么迈出这一步？外包给软件开发公司，还是自己招聘开发人员？
我们的客户无一例外，都没有自己的开发团队，其专注于服务业或加工业，对于软件开发确实距离遥远。
如果你的预算充足，对于数字化的进度也比较宽容——2～3年以上的摸索期，那么可以自己招聘开发人员，组建开发团队。这里的关键，是先招聘到一位货真价实的有实际工程经验的开发主管，然后主管开始磨合团队，抽象业务逻辑，开发框架选型，架构布署开发环境，来来回回地和业务部门开会讨论功能需求，直至写出第一行代码，算是迈出了第一步。后续是复杂度更高的前后台的功能开发堆叠，反复的需求更改及代码返工，各种各样的bug需要修复，慢慢地迈向正式产品测试部署。
如果你忙于原有的业务，没有太多时间及耐性，那么挑选一个专业的团队委托开发，这是大部分中小企业的选择，专业的人做专业的事，这没什么不好。但和自己组建开发团队时招聘一个称职的技术主管一样，如何找到一个称职合适的开发团队呢？
这是个很难回答的问题，那么我们可以换个角度来思考——我通过网络或朋友介绍而接触到一个开发团队，如何判断这个团队是不是合适呢？我们建议综合考虑下面的因素：
1.采用的是什么样的开发方法？
常见的开发方法主要有两类，一是你提出所有的开发需求，对方给出一个报价，完成全部需求开发，交付软件产品，可能历时几个月或一年以上。二是以较小的周期迭代开发，比如每周汇总功能需求，每周开发并演示，甲方可以每周持续地提出功能需求。
两者的区别显而易见，打个简单的比方，犹如一杯酒，是一口闷，还是一小口一小口快速地多次喝完。如果这杯酒变质了，一口闷直接下肚，一小口的，第二口即可放弃，软件开发也类似，2个月，开发完成交付，如果这时候发现开发结果不符要求，怎么办？推到重来？
还有一点，从我们给客户开发的实际情况来看，甲方的开发需求是很难、几乎不可能一次就能描述清楚的，而且随着开发的深入，甲方会越来越频繁地完善、更改甚至完全推翻最初的功能需求，那么，上面说的第一种开发方法（也称瀑布式开发）无法适应这样的场景，而第二种开发方法，即迭代式敏捷开发方法，可以满足这样的场景。
其实不难理解，开发过程中，我们一直在细化并完善产品方案，很多细节在最初也考虑不到的，另外，甲方的业务市场，包括同行竞争，情形也是无时无刻不在发生变化的，不停地调整功能需求，也是为了更好地满足自身的业务运行需要，看似变来变去的提出需求，一点也不过分。那么，这样一直变化下去，何时交付产品呢？
很简单，敏捷迭代的背后，是测试驱动开发（TDD）和持续集成（CI）。TDD是在代码的时候先写测试，CI是每周开发的功能一点一点持续的累加起来，开发一个功能，就有用一个功能，并且这些功能的测试集成是自动完成的。原则上，只要甲方觉得当前的功能已经够用，可以在任意一个以周为单位的节点宣布产品阶段性开发完成，可以布署到正式服务器，准备产品上线。
那么，是不是一定选择第二种开发方法的团队呢？这得根据实际情况来衡量，第一种开发方法（瀑布式）一般对应的是一口价的费用方式，而第二种（敏捷迭代）一般是按人月的方式报价。这和装修时按总价还是按人工计价类似，甲方也可能担心第二种方法会不会导致磨洋工的情形？我们一般对于有这种顾虑的新客户，建议先按总价的方式合作一个月，然后客户再决定接下来的合作方式。
2.PM能否听懂你的需求？
PM指开发团队的产品经理，是工程师和甲方客户之间的桥梁，把甲方的业务需求“翻译”成工程师能懂的开发需求，同时把控着整个软件产品的定义及交付，拿行业流行的说法，PM就是这个软件产品之“父”，其重要性不言而喻。
所以PM必须要能理解甲方的真实需求，对业务流程进行抽象，完成软件产品的功能及整体架构。如果几次讨论下来，你对PM理解你的需求有疑惑，那么是否让这个团队来做开发，你得慎重！
3.能否提供长期稳定的维护？
开发完成，然后上线运营，这只是一个开始，后期的维护是数字化业务正常运营的保障。基于软件工程的复杂性，第三方一般不愿意也难以维护他人开发的项目，很多时候，读懂及修复他人写的代码比自己重写代码还要麻烦。
所以，找一个开发团队时，最好一并考虑并协商好后续的维护事宜。
4.软件源代码是否具备完整的知识产权？
这涉及到你的后续融资，知识产权有问题的产品显然无法吸引到投资人。你得确认，支付费用买到的是完整产权的包含源代码的产品，还是仅仅是一份软件使用权。
5.有过哪些开发实例？
通过开发团队已经开发完成的APP或系统，实际使用体验一下，可以快速感受软件的交互设计在哪个级别或者是否符合你的要求，了解这些实例中的甲方客户及其业务，大致有数开发团队能驾驭的项目规模及开发复杂度。
6.技术栈是否完整？
随着开发的推进，业务需求的细化或变更，bug不断出现，项目开发的复杂度快速上升，团队的技术储备是否完整，以及技术高点处于什么样的程度，关系到项目开发的成败，需要关注团队中的这块长板，这决定驾驭项目复杂度的天花板。
7.是否和你能经常当面沟通？
软件开发及交付，理论上都是可以远程进行的，甚至开发团队也可以是分布在各地， 通过线上实现远程协同。但甲方和开发团队之间，当面沟通和远程沟通的效率差异巨大，无论视频还是语音，沟通效率远远低于面谈，其他的沟通方式就更不消说了。
既然你选择数字化转型，这势必关系到你的业务运营调整及长远布局，你也必定高度重视接下来的数字产品开发，那么，不停地完善、更新各种各样的开发需求不可避免，需要和开发团队频繁地来回探讨，这需要找一个和你路程距离不太远，并且愿意和你经常当面交流探讨的团队。
当然，这些都是和数字化及软件开发紧密关联的因素，在选择开发团队的过程中，你已有的判断合作方是否值得信任的经验仍然很重要！
