如何实现环保行业的产品升级:最新版本的忒修斯之船

 
     本文将结合环保产业数字化转型发展中各类数字化产品的现状及其未来潜在发展方向进行分析。或许分析结论与读者的实际经验有出入,但如果能引发一些思考和讨论,也算开卷有益了。
 
 

     

     在科技创新日新月异的时代里,包括环保行业在内的各传统行业纷纷针对局势做出响应:小到智能办公软件系统推广应用,大到企业级数字化转型解决方案落地。在这个过程中,提供业务调度、数据管理、安全防护等各类服务的软件产品和水务环保信息化公司纷至沓来。如何使这些软件产品不致沦为落水即融的孤岛浮冰,而是能够长期续航、顺势应变,成为不断汇入信息化时代之海的大船,是本文想要探讨的命题。

 

 

大家或许听说过这样一个故事:

 

忒修斯之船(The Ship of Theseus),是最为古老的思想实验之一,源自古希腊哲学家普鲁塔克所记载的希腊传说故事。传说中的雅典国王忒修斯与雅典的年轻人们击败怪物米诺陶,自克里特岛回到雅典,当时他们所搭的30桨船被雅典人保留下来,作为自克里特岛归还者的纪念碑。随着时间推移,30桨船上的木材逐渐腐朽,而雅典人会用新的木材来替换坏掉的零部件。最后,船上每根木板都被换过了。
 
 

此图片来源于网络

 
     在这个故事里,忒修斯之船身上到底发生了什么,最终又成为了什么呢?忒修斯之船的故事对软件产品研发并更新迭代有什么启示?带着这样的思考及疑问,让我们重新回到软件产品生命周期的讨论里。

 

首先,需要造一艘“船”
如前文所提到的,在数字化转型的热潮下,敢于吃螃蟹的企业纷纷投入资源研发软件产品,形成软件产品的1.0版本,信息化业务能力初具雏形。然而,许多传统行业企业转型研发的信息化产品自诞生之日起便不再更新,“出道即巅峰”的现象比比皆是,着实令人扼腕!之所以出现这种情况,究其原因,此类软件产品往往具有如下特性:
 
1. “边开车边学车”地做出来了
 
 

      传统行业转型研发软件时,项目负责人和核心团队要么由业务领域专家担任,信息化系统开发经验较少,要么来自IT部门,对于本行业的业务体系和管理流程并不熟悉。

      由这样的团队承担研发任务,势必会一边梳理业务、一边设计功能、一边对接技术,不得已时还得寻找各类现有软件产品参考其设计思路(更有甚者直接模仿其基础逻辑),就像“边开车边学车”一样。

2. “边开车边找路”地开到站了
 
 
       对业务与技术的理解不断更新致使研发目标及实现该目标的技术路径反复变更修正,“车到山前必有路”式模糊规划执行困难,“想当然”制定的计划与现实情况频频冲突,初期设计时经验不足产品不能满足后期复杂需求……种种问题导致研究过程和结果无法事先全面把控,“边开车边找路”即使磕磕绊绊到达了终点,这样的软件产品毫无疑问不会太完美。
3. 到站时刻,终点还在远方
 
 
       如果将前述产品与市面上更加成熟的软件产品作对比——拿地图功能与导航软件比较,拿派单功能与打车软件比较,拿检索功能与搜索引擎比较,就会发现,如果软件研发的目的不仅仅停留在将传统业务“线上化”,而是希望用数字化工具真正解放生产力、优化生产结构,那么还有很多事情要去做。在建造第一条“船”的过程中,研发团队积累了核心需求梳理分析、业务逻辑拆解重塑以及软件开发工作组织的全流程经验,面对一款具备了基本功能但还不甚完美的产品,如何对它进行改造升级成为团队摆在眼前的问题。

 

然后,修缮更好的“船”
      产品升级,也称为“产品迭代”这个概念的含义很广,既可以通过外观上“改头换面”让软件产品耳目一新,也可以对现有软件功能进行“不破不立”的更新,当然,产品升级还可以由各类细节修改逐渐累积形成,就像我们可以从不稳定的扶手、破损的地板开始一点点替换木船上的部件一样。增加说明按钮或润色UI设计等功能优化,调整代码结构以提高页面跳转稳定性和加载速度,都是产品升级过程中替换上的零部件。
什么时候开始修船?

产品升级究竟应该在什么时刻开始着手呢?当软件产品已经难以覆盖用户需求,日常使用举步维艰时,显然应该开始升级优化了。在产品使用过程中,用户反馈了很多值得优化的功能点时,是不是也可以开始?实际上,产品升级的契机伴随着软件服务业务的一生长期存在,在第一艘“船”的航行过程中,只要留心,随时能够发现可以且应当被替换的木头。产品升级,任何时候都可以启动。

从哪块木头换起
 

      在软件产品应用过程中,形形色色拥有不同业务理解和操作习惯的人在基于自身使用情况呼唤着产品更新。然而,任何一款产品都不可能做到满足所有人的需求。

1. 需求的复杂性
 
      用户总是根据自己的应用需要对软件提出修改要求。这些需求可能在技术实现上相当复杂,需要投入难以预计的业务分析和开发工作量,甚至涉及一个行业数字化转型过程的深水区;也有可能只是结合常用办公软件的操作提出交互层面的优化建议,此时用户常常将软件与最强大、最普及的办公软件相比较,比如任何一个数据库软件都逃不过与Excel比较的命运。
2. 保证核心功能
 
 
      针对不同的声音,研究团队需要提炼其中最核心用户群体的最核心反馈,进而巩固现有产品优势,保证核心功能能够持续稳定地提供服务。就像船最重要的功能是实现水上航行,或许会有人提出船在沼泽地里不能航行是一种重大缺陷,但如果因此给船加上履带,使其丧失了在水中航行的基本能力,显然是买椟还珠。
3. 个性与共性
 
       虽然每个用户都是基于个人经验提出独特的建议,但汇总不同用户的反馈,可以总结出此类用户对软件产品的共性需求。此外,如果某个软件产品可以成功地应用于一种业态,那么它就具备推广到其他相似业态的可能性。用户对该产品在此业态场景中提出的意见,也可以为其他业态所应用,成为软件产品拓展服务领域的基石。
 

水滴石穿非一日之功

  船体更新如何持之以恒?

      在软件产品升级过程中,外部环境包括行业趋势、政策支持、科技发展和用户思潮等等各方面都在不断变化,研发团队需要保持灵活且持续应变能力。船需要推动水流,才能在水流中航行。
1. 持续服务能力
 
      软件产品必须不停自我提升以保持持续服务的能力。升级缓慢、没有及时更新技术而落后于同行,或是服务中断、失去既有用户粘性,都可能导致软件被用户抛弃。
2. 即时维护能力
 
      如前文修缮扶手、更换地板的比喻,一艘船在航行过程中完全可能面对各种各样的小规模破损,软件产品也随时可能面临各式各样的故障。提升产品自身性能、减少缺陷是解决上述问题的根本之道,但现实中故障总是难以彻底避免,因此,事故发生后的即时维护能力必不可少,这就要求产品团队做好灾备容错方案,并能够在关键时刻及时解决各类技术问题。
3. 快速更新能力
 
      当软件产品面对的业务场景发生巨大变化,或者相应的业务数字化实现思路出现重大突破时,产品应能够针对变化敏捷调整、全面更新。这要求软件研发团队可以在关键时刻快速整合、攻坚克难,以“战时状态”开展重大版本更新工作。

 

 
 
     以上是对打造具有持续生命力的数字化产品的研发团队提出的要求。这支团队或许起步时是半路出家,但在软件产品逐步发展成熟的过程中,必须实现自我迭代升级,形成专业的项目管理模式、足以支持产品持续优化的研发能力、面向市场的营销及客户服务体系在各大企业中都有软件产品团队孵化的成功经验,值得参考的模式不胜枚举,对于读者所在的团队而言,最重要的是根据自身企业特点、业务模式和实践经验总结适用方法、持续运转并自我调整
 
 

 

 
结语
 

 

最后,让我们再重温一下“忒修斯之船”这个故事。

     在漫长的修缮维护工作中,忒修斯之船上的每一根木头都被替换过,甚至很可能替换了不止一次。而一个成功的软件产品,在版本更新的过程中,软件的外观设计、功能架构甚至底层代码都可能会发生变化。无论是手机应用市场里的当红APP,还是个人电脑上长久陪伴的办公软件,总是在不断推出更新版本。伴随着软件产品的长期推广使用,用户群体以及他们对软件的理解都可能发生改变,可能唯一不变只有开发者对核心业务不断加深的理解和对完美产品的不懈追求。
 
      就像忒修斯之船,无论发生了怎样的替换变更,其本质仍然是“归还者的纪念碑”。更何况,即便产品最终已经完全转入了新方向,那又如何呢?无非说明,无论是研究团队还是软件产品,最终都已经走向了新的时代