1、了解MVP，全称Minimum
Viable Product，指“最小化可行产品”。MVP是一种产品理论，MVP 的功用就是让我们接触客户，从早期就根据客户的回馈来改进产品。
※MVP不是每个迭代做出产品功能的一部分，而是要交付一个可用的最小功能集合。
※MVP不是产品上线的1.0版本。
MVP 的功用就是让我们接触客户，从早期就根据客户的回馈来改进产品。所以我们要做到：以用户为中心。用户第一：不将问题留给用户。
以用户为中心：为用户服务的观点在公司内部依然成立，凡接收上道工序的产品进行再生产的下道工序，就是上道工序的用户，“为用户服务”和“下道工序就是用户”是公司全面质量管理的一个基本观点。
2、项目型项目通常有以下一些基本特征：
※【特定性】项目开发是为了实现一个或一组特定目标；
※【综合性】项目要综合考虑范围、时间、成本、质量、资源、沟通、风险、采购及相关方等十大知识领域的整合；
※【复杂&不可逆】项目的复杂性和一次性；
※【最终要交付】项目是以客户为中心的；
※【系统工程】项目是要素的系统集成。
→结论：因为项目型项目的【复杂&不可逆】+【最终要交付】，我们要提升项目的交付质量，达成上线目标，动态平衡“QCDRK”，就要想方设法地：早试错+去复杂。即，推行MVP思维，实现持续“交付”。
3、践行MVP思维，实现持续交付。
Rule No.1 ：高起点开发
※开发不从零开始， 而是从“平台产品”+“类似可运行项目”+ 组件化开发+低代码开发 开始；
※需要PMs积极主动地熟悉并掌握公司产品架构+产品平台特性；
P.S1. 此处PMs = 项目经理A角/Project Manager A
+ 项目经理B角/Project Manager B
+ 产品经理/ProductManager
※需要PMs间保持互动，共享项目情报，调用成功案例；
※动手开发(编码)前不欠业务债：需求分析充分到位，需求边界清晰，需求变更流程机制科学合理。
Rule No.2 ：去复杂
管理不是从个人经验开始，而要从团队经验与团队配合开始；
A、项目启动会议前制定细致的项目计划
· 详细计划符合3人天以下颗粒度
· 条件允许的话，1人天的颗粒度更好
· 充分沟通论证计划，与开发团队达成共识
· 将执行期的风险充分暴露并具象化(杜绝到时候再说)
B、聚焦问题不放过，问题管理实现“清单化”
好处1：全面消除管理信息差（真的好）
好处2：减少低效的“重复性口头复述”，避免一人一个说法，一次一个意思（解放PMs，减少焦虑）
好处3：容易跟踪，闭环到位（可控）
· 管控化整为零：将最终交付质量，分解到过程交付质量
关键质量活动
Rule No.3：减少项目集成前的“黑盒期”
改变的“上线前统一集成”方式为“尽早集成，持续集成”(此处，集成SI≈交付/准交付)
A、尽早交付，包括两部分：
· 内部交付 —— 开发工程师向项目组交付（非常重要，想想PMs为什么项目后期会焦虑不安，因为这是最大的一个黑盒子）
· 内部上线演示 ——面向项目组全员+内部干系人/PMO+邀请的同行专家（非常重要，是团队测试活动，也是PMs的一次主动验证活动）
B、尽早SIT: 尽早实施软件集成测试，随时准备好向用户交付——【以客户为中心：主动缩短用户反馈周期】
C、这里交付并不是全部功能都做完了再集成、再测试
D、将黑盒变白盒，好处多多：
· 项目开发过程将会呈现“前紧后松”的状态，其管理成效是：项目中后期将会进入“高速巡航状态”，即：管理投入低，质量提升快
· PMs会明显感受到：“担忧最终交付的焦虑感”会慢慢被“期待交付演示的内在驱动力和潜在成就感”所替代
· 项目团队小伙伴在看到“MVP成果”后，信心和开发效率都会持续提升
Rule No.4：保持积极行动的姿态
无论是关键质量活动过程控制，还是“缺陷率统计·最佳实践活动”；想到容易，知道不难，但做到MVP，需要积极行动和坚持精神；
PMs应该时常想象一下：美妙的“高速巡航状态”；团队成员在看到“MVP成果”后的喜悦（信心效率双提升）、团队的鼓励、用户的赞许……，那么，推行MVP持续交付这件事将会变得容易许多；
作为PMs，想象一件重要的事情做成功后的场景，并将这种场景带来的好处与可能面临的暂时性困难，告知团队成员。这是一种行之有效的管理技巧，会加速我们达成管理目标。
4、结语：实践运用，比知道重要。
一则名谚：“听过的我会忘记，看过的我能记得，做过的我才理解”。
网友评论