副标题：0岁PD的项目开发动态管理经验（强行拗了个词，哎呦好高大山的感觉）
因毕业答辩，我提前拟定好了项目开发的计划，给开发同学交代清了需求，放心回了学校：
先做“正式版”的【课程模块】；
同期另一位小伙伴做“乞丐版”的【适配首页模块】。
等快回公司的时候，跟开发的同学在微信上随便聊了几句，才发现之前定的计划被部门的小伙伴调整了一下，变成：
【适配首页模块】从“乞丐版”直接晋升为“正式版”；
之后再做“正式版”【课程模块】。
当时我就懵逼了，不是很理解调整的原因——
一层背景是：因为开发资源紧缺，我请求另一位小伙伴先做个“乞丐版”的【适配首页模块】，能配合马上要发布的新版APP做运营。先跑起来，之后再解决美不美观、好不好用的事；
二层背景：运营同学在“乞丐版”的后台时，会时不时地出现操作上的失误，比如配置课程的时候忘记填写价格、不知道如何添加课程小节等。如果这些失误放到接下来的商业尝试中，对于内容提供商与合作者来说，可能会发生不必要的麻烦。
嘶......怎么看这个安排也恰到好处的呀，怎么说变就变了？
之后，经过智琪的几句开导，我发现，在这个原始安排中我忽略了后台开发与App之间配合的时间维度。
一、理清现状
①因为开发资源被优先级更高的H5活动占领5天/人，开发后台模块不得不整体后推1周；
②从此时到新版App上线只有8天/人的工作时间，这8天/人得调整开发的优先级与公司整体进度配合、契合；
③在这一阶段，开发的主要选项有：【课程模块】、正式版【首页配置页面】、【订单模块】；
二、深入分析
①先解决“有”的问题，优先级上【首页配置页面】与【订单模块】>【课程模块】；
②【首页配置页面】与【订单模块】都没有，但由于目前处于商业化尝试阶段，内容必须撑起产品的门面，那么保证【课程模块】的容错率就使得它的优先级>【订单模块】；
③对于“正式版”【首页配置页面】与【课程模块】的分析，就是一个要再讨论的问题了！
1、改变后的效率提升上来看
可引入一个逻辑模型：
效率提升量=单次使用效率的提升*使用频次
①前者得在运营人员具体使用中才能体会，跟产品的性能、设计各方面都相关；
②当我们的没法评估前者时，看使用频次也是一种好方法！
③得出的结论是：配置首页与配置课程，在使用频次上都是每天使用的级别，【首页配置页面】、【课程模块】应属于“P0”这个最优先的主干功能模块，即使有使用频次的差异，也是微小且毫无意义的对比。
所以，我们这一项对比就不太行得通，但是这个思维的过程，非常重要。
2、从deadline来分析
新版App发布为我们制造了一个deadline，这8天/人开发时间内各模块的估算是：
【课程模块】20天/人
“正式版”【首页配置页面】5-8天/人
【订单模块】5天/人
综上，在deadline之内，我们有且只有选择“正式版”【首页配置页面】来作开发，其次是【课程模块】（这一阶段可以通过人工监督来尽量减少失误），最后才是等新版App上线1-2周左右才开始用的【订单模块】。
之后，智琪还点了一句：
早完成早使用，尽量避免重建部分工作量浪费。
当然，还有各种各样的因素影响者决策，so...在资源紧缺的条件下做出对的决策，是产品经理的必修课，fighting~
该分析方法适用于：开发资源紧缺的条件下（或以职能划分的产品团队中）。
6月1日 凌晨
