关于AMM模型的一些思考

首先,关注价值!产品的运作成功与否,在于产品价值的高低,对于绝大部分市场项目来说,价值就是,快速的交付高质量的客户所需要的产品。这里强调,快速和高质量,自己交付的产品对于客户的高价值,以此为目标,再衍生出一系列的版本周期,外部质量指标等具体的子项。

其次,产品的运作需要项目和团队的支撑。团队我们期望的是能职责共担的,稳定、高效运转的团队,团队内有非常好的沟通协作机制。当团队基本运作步调稳定后,我们期望团队能不断拓展自己的能力,包括个人能力的拓展,团队迭代交付力的提升,团队DOD能力的拓展等。

产品的运作往往由几个团队共同来支撑,所以会有项目级跨团队协作的一些需求。因此,根据自身的情况,可能需要有稳定的跨团队沟通协作机制,保证团队间沟通协作顺畅运行。最好能做到团队,项目都有稳定的一致的迭代运作机制,保证高质量特性的高优先级交付。

如果产品本身还对其他的产品有所依赖,再往更高一级走,是希望能把本产品相关干系人,甚至干系产品流程尽可能打通。比如,保持统一的迭代交付节奏,和他们保持频繁的需求价值优先级评估和需求梳理,尽可能更频繁的从外部干系人得到关于业务,质量等价值的反馈,用于指导我们的改进。

总结来说,就是内在的团队和项目反馈环需要转的越来越顺畅,团队和项目的交付能力需要不断的拓展,并尽可能把外部客户的反馈环和内部反馈环打通,提升稳定的交付高价值用户功能的能力。

再次,在工程实践部分,需求环节,我们期望的是需求传递的不失真,一方面尽可能多的和外部客户进行交流,将外部客户拉近我们的团队,从一开始的需求场景梳理,到后面验收环节,都期望听到来自客户的声音。同时,期望可以通过团队内各种角色的广泛参与,保证需求在团队内的传递和交流更加顺畅。引入需求体系化,强调在更系统全面的分析出新增需求对存量系统功能的影响外,更重要的是关于产品功能体系演进的管理策略。

在开发环节,强调简单设计,设计涌现,强调团队集体设计,通过小步快跑的重构方式,在clean code等指导下,保证项目的架构体系的不断演进,内建质量的不断提升。

在测试体系方面,需要围绕着缩短交付周期,减少测试尾巴的目标,根据项目实际情况,根据ROI制定出项目的测试策略,并用该测试策略指导项目更好的做好测试分层的建设,测试用例的管理,最终期望做到绝大部分测试工作都能在迭代周期内完成,系统测试越来越短,项目交付能力越来越强的目的。

除此以外,配置管理作为一个很重要的支撑,对于我们开发质量的内建和反馈,测试体系的建立都是非常重要的支撑,根据产品实际情况,选择更适合的配置管理工具,以此作为各项工程实践的有力支撑。

最后,度量和文化。度量强体系化,选择什么样的度量指标比选择什么样的度量工具重要。度量是能将业务目标和改进目标整体串起来的一个有力手段,让我们能够快速的对风险、进展进行管理,从度量出发去驱动出一系列的改进,再回到度量系统自身的改进。度量本身是为了支撑我们的价值目标的达成而做的,因此绝不仅仅是一些指标,而且指标背后的根因分析和改进措施的落地反馈。

文化就像组织的生态系统,一个好的生态系统能培养出更优秀的人和团队。当上述基本点都已经存在,项目节奏建立起来后,想要更进一步的突破,就需要注重团队、人员的培养,打造出一个学习型组织,让组织具备更强大的持续学习的能力,当人不再是作为一个资源而存在时,才能不断拓展其能力,让我们的生态系统更加健康的为产品运作提供良好的环境。

总结来说,模型需要从项目本身的痛点和目标出发,关注价值,关注目标的达成,价值的实现,以此开始结合项目实际去做,需要更系统的去思考和改进。

关于AMM模型的一些思考_第1张图片
图片发自App

你可能感兴趣的:(关于AMM模型的一些思考)