创新2.0时代的精益敏捷研发管理体系
2019-12-17
来源：超图集团 超图通讯
导读
超图软件自1997年开始研发平台软件产品，至今已经走过18年的时间。在这18年里，SuperMap GIS 平台软件产品从最初的com组件产品，发展到web产品、二三维一体化产品，再到如今的云平台产品。超图的创新步伐越来越大，迎合用户需求的创新产品推出速度越来越快，研发能力目前已经处于国内外先进水平。
超图是如何做到的？在创新2.0时代的背景下，超图的研发又有何“不一样”？ 本文将带您一探究竟……
以用户为中心
在创新2.0时代，超图产品经理的关注点由原来的以功能和技术为中心转移到了以用户需求为中心。产品经理不再重点关注某个功能所采用的技术是否先进、采用的算法是否最优、界面操作是否更流程化等，他们更加重视用户体验和用户的实际使用习惯，期望产品能够真正解决客户的需求。
产品经理通过多种渠道收集客户对产品的需求，如现场沟通、调查问卷、技术工程师代客户反馈等。超图研究院也会定期组织平台产品质量试用印象和建议有奖征集活动 ，用户只要反馈产品使用中的问题和建议，就有机会得到相应的奖励。产品经理会认真分析收集到的每一个问题和建议，分析和模拟用户的使用场景、使用习惯，持续改进产品，增加产品的易用性，使用产品更能满足用户的需求。
采用敏捷研发模式
在创新2.0时代下，软件的开发模式也经历了变化：由早期的瀑布开发模式演进到敏捷开发模式。早期瀑布开发采用自上而下(Top Down)的开发模式。它是指从一个应用的最高点开始开发，从最高点逐步往下层编码，直到开发完所有的任务。而敏捷开发采用自下而上(Bottom up)开发模式，即从一个应用的最底层开始开发。
在原来瀑布模型的开发模式下，整个研发过程过于封闭，开发周期一旦开始，中间过程中很难再加入任何用户的需求，而且开发周期控制难度大，开发时间周期长（有的版本开发周期会持续进行半年时间）。这就会造成一个尴尬的问题：待开发工作完毕进入测试阶段时，发现的问题很难改正，尤其是一些前期设计的问题，更改难度和成本会更大。如果开发前的设计工作出现了重大问题，甚至会有推翻所有开发工作重新开始的危机。
2008年，超图全面采用敏捷开发模式，研发人员每两个星期一个迭代，将整个产品开发任务分解到每一个迭代中。每天，团队成员通过站立会议汇报前一个工作日的任务完成情况、遇到的问题以及今天准备做的工作。每个迭代结束后，会有验收会议，验收中发现问题会及时修改。此外，如果有重要的客户需求，也可以随时安排到后续的迭代中去，使开发更加灵活，与用户需求的连结更加紧密。在敏捷开发模式下，超图的产品更新战略是：当经历若干次的产品迭代之后，就会基于这些更新推出一个重大的版本。
敏捷开发与传统瀑布开发模式对比图
鼓励全员创新
超图早期研发中心的创新机制是从上往下安排：创新点自上层提出来，公司的决策层集中负责把握前沿技术发展趋势，并据此进行产品的改进与迭代。而发展到后期，随着产品体量的增大，以及细分应用领域的增多，产品的创新机制开始有了一定的调整，现在基本是以自下向上的创新模式为主，即产品创新和改进的点来自于一线开发人员。除此之外，作为平台软件厂商，许多来自超图上下游的合作伙伴，以及一些二次开发商，也都纷纷开始参与到超图平台软件的开发过程中来。这种鼓励全员创新的机制，突破了传统自上而下的创新方式，使产品更接地气。
实行决策评审机制
因为很多创新点是来自于一线员工，所以超图在研发机制里设有一个组织PPAC（平台软件决策委员会）。PPAC的组成成员都是公司里的高层决策者和技术专家。当创新点被提出后，PPAC会做创新点评审工作，发现偏离及时纠正，发现错误及时砍掉。如此一来，如何判断创新点的正确与否，便成了PPAC面临的重要问题。
PPAC判断的重要指标就是能不能带来客户价值，能不能带来市场回报。而以客户价值为导向，是最为重要的准则。一旦创新点得到肯定，就会进入研发流程。决策评审可以有效地纠正研发过程中的错误，更有方向性的指导有效创新点被合理的应用到产品研发当中去。
精益质量体系
伴随着企业的不断发展壮大，产品的规模也越来越大，如何才能更好地保障产品质量？这是非常敏感的问题，也至关企业的生死存亡。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
