谈谈我身边的中小企业的数字化转型尝试——《数字时代的企业进化》阅读拓展1:如何去选择开发团队?

这里是译者的一点题外话,翻译《数字时代的企业进化》过程中,我也在不停地思考自己身边的数字化案例,包括由我所在公司提供咨询及开发服务的企业,诚然,与书中的大型企业的数字化相比,我们所经历的更多是中小企业的数字化转型,虽说其单体规模不大,但麻雀虽小,五脏俱全,数字化转型的方方面面均已涉及。从我们接触到的客户来看,大部分来自服务业或加工业,提出数字化转型的方式也非常简单——开发一个APP/小程序或者开发一套系统!

开发的目的是什么呢——完成线上下单及发货或服务闭环,也统筹企业资源到对应的订单上(以前是人工调度资源,业务一多就转不过来了),自动统计分析业务数据及员工绩效,定制开发一些促销功能,运用社交网络做一些数字化营销等等。

也有将业务拓展架构到数字化的服务业高层管理者,比如总部要在更大范围的区域开设分店,他希望借助于数字化,只需招聘新员工完成标准培训,数据导入定制开发的业务系统,快速“复制”“粘贴”一个新门店到他的企业版图,新店即可开门营业。

《数字时代的企业进化》提到的运用数学公司未来力量的大思维及领导力,前面这位企业高层“复制”“粘贴”拓展门店的想法,真的有异曲同工之妙,大胆且富于想象力。我们也给予这家企业更长远的数字规划建议——有更多门店及客户的时候,更深入地挖掘数据来优化当前的业务逻辑模型,从而更高效合理地配置服务资源,获得更高的客户满意度及忠诚度。

说到这里,有一个非常关键的问题我们还没谈到,《数字时代的企业进化》书中也没有详细的探讨,那就是如何来进行数字化所需的软件开发?

没有开发,数字化的第一步无法迈出,所有的数字化的好处通通无从谈起!

怎么迈出这一步?外包给软件开发公司,还是自己招聘开发人员?

我们的客户无一例外,都没有自己的开发团队,其专注于服务业或加工业,对于软件开发确实距离遥远。

如果你的预算充足,对于数字化的进度也比较宽容——2~3年以上的摸索期,那么可以自己招聘开发人员,组建开发团队。这里的关键,是先招聘到一位货真价实的有实际工程经验的开发主管,然后主管开始磨合团队,抽象业务逻辑,开发框架选型,架构布署开发环境,来来回回地和业务部门开会讨论功能需求,直至写出第一行代码,算是迈出了第一步。后续是复杂度更高的前后台的功能开发堆叠,反复的需求更改及代码返工,各种各样的bug需要修复,慢慢地迈向正式产品测试部署。

如果你忙于原有的业务,没有太多时间及耐性,那么挑选一个专业的团队委托开发,这是大部分中小企业的选择,专业的人做专业的事,这没什么不好。但和自己组建开发团队时招聘一个称职的技术主管一样,如何找到一个称职合适的开发团队呢?

这是个很难回答的问题,那么我们可以换个角度来思考——我通过网络或朋友介绍而接触到一个开发团队,如何判断这个团队是不是合适呢?我们建议综合考虑下面的因素:

1.采用的是什么样的开发方法?

常见的开发方法主要有两类,一是你提出所有的开发需求,对方给出一个报价,完成全部需求开发,交付软件产品,可能历时几个月或一年以上。二是以较小的周期迭代开发,比如每周汇总功能需求,每周开发并演示,甲方可以每周持续地提出功能需求。

两者的区别显而易见,打个简单的比方,犹如一杯酒,是一口闷,还是一小口一小口快速地多次喝完。如果这杯酒变质了,一口闷直接下肚,一小口的,第二口即可放弃,软件开发也类似,2个月,开发完成交付,如果这时候发现开发结果不符要求,怎么办?推到重来?

还有一点,从我们给客户开发的实际情况来看,甲方的开发需求是很难、几乎不可能一次就能描述清楚的,而且随着开发的深入,甲方会越来越频繁地完善、更改甚至完全推翻最初的功能需求,那么,上面说的第一种开发方法(也称瀑布式开发)无法适应这样的场景,而第二种开发方法,即迭代式敏捷开发方法,可以满足这样的场景。

其实不难理解,开发过程中,我们一直在细化并完善产品方案,很多细节在最初也考虑不到的,另外,甲方的业务市场,包括同行竞争,情形也是无时无刻不在发生变化的,不停地调整功能需求,也是为了更好地满足自身的业务运行需要,看似变来变去的提出需求,一点也不过分。那么,这样一直变化下去,何时交付产品呢?

很简单,敏捷迭代的背后,是测试驱动开发(TDD)和持续集成(CI)。TDD是在代码的时候先写测试,CI是每周开发的功能一点一点持续的累加起来,开发一个功能,就有用一个功能,并且这些功能的测试集成是自动完成的。原则上,只要甲方觉得当前的功能已经够用,可以在任意一个以周为单位的节点宣布产品阶段性开发完成,可以布署到正式服务器,准备产品上线。

那么,是不是一定选择第二种开发方法的团队呢?这得根据实际情况来衡量,第一种开发方法(瀑布式)一般对应的是一口价的费用方式,而第二种(敏捷迭代)一般是按人月的方式报价。这和装修时按总价还是按人工计价类似,甲方也可能担心第二种方法会不会导致磨洋工的情形?我们一般对于有这种顾虑的新客户,建议先按总价的方式合作一个月,然后客户再决定接下来的合作方式。

2.PM能否听懂你的需求?

PM指开发团队的产品经理,是工程师和甲方客户之间的桥梁,把甲方的业务需求“翻译”成工程师能懂的开发需求,同时把控着整个软件产品的定义及交付,拿行业流行的说法,PM就是这个软件产品之“父”,其重要性不言而喻。

所以PM必须要能理解甲方的真实需求,对业务流程进行抽象,完成软件产品的功能及整体架构。如果几次讨论下来,你对PM理解你的需求有疑惑,那么是否让这个团队来做开发,你得慎重!

3.能否提供长期稳定的维护?

开发完成,然后上线运营,这只是一个开始,后期的维护是数字化业务正常运营的保障。基于软件工程的复杂性,第三方一般不愿意也难以维护他人开发的项目,很多时候,读懂及修复他人写的代码比自己重写代码还要麻烦。

所以,找一个开发团队时,最好一并考虑并协商好后续的维护事宜。

4.软件源代码是否具备完整的知识产权?

这涉及到你的后续融资,知识产权有问题的产品显然无法吸引到投资人。你得确认,支付费用买到的是完整产权的包含源代码的产品,还是仅仅是一份软件使用权。

5.有过哪些开发实例?

通过开发团队已经开发完成的APP或系统,实际使用体验一下,可以快速感受软件的交互设计在哪个级别或者是否符合你的要求,了解这些实例中的甲方客户及其业务,大致有数开发团队能驾驭的项目规模及开发复杂度。

6.技术栈是否完整?

随着开发的推进,业务需求的细化或变更,bug不断出现,项目开发的复杂度快速上升,团队的技术储备是否完整,以及技术高点处于什么样的程度,关系到项目开发的成败,需要关注团队中的这块长板,这决定驾驭项目复杂度的天花板。

7.是否和你能经常当面沟通?

软件开发及交付,理论上都是可以远程进行的,甚至开发团队也可以是分布在各地,  通过线上实现远程协同。但甲方和开发团队之间,当面沟通和远程沟通的效率差异巨大,无论视频还是语音,沟通效率远远低于面谈,其他的沟通方式就更不消说了。

既然你选择数字化转型,这势必关系到你的业务运营调整及长远布局,你也必定高度重视接下来的数字产品开发,那么,不停地完善、更新各种各样的开发需求不可避免,需要和开发团队频繁地来回探讨,这需要找一个和你路程距离不太远,并且愿意和你经常当面交流探讨的团队。

当然,这些都是和数字化及软件开发紧密关联的因素,在选择开发团队的过程中,你已有的判断合作方是否值得信任的经验仍然很重要!

发表评论

电子邮件地址不会被公开。 必填项已用*标注