最近的一周，产品开发逐步走向正轨（产品当前处于从0-1的阶段），我的工作也抽出一些时间用于项目执行跟踪，主要包括：
1 项目进度制定和跟进
2 当开发和UI设计人员遇到对需求、原型等不理解的时候，及时解答
3 一些临时性变更的调整和处理
4 ...
这里发现几点原则十分重要：
1 开发提出一些功能可能会花费较多开发时间，希望砍掉或修改设计，我的思考和处理如下：
① 必须确保功能的完整性
② 必须确保“说的过去”的用户体验
③ 目前是从0-1阶段，尽快上线，让真实用户见到产品更重要，复杂的功能在与前两点不冲突时可以砍掉，但要将砍掉的部分记录到需求池，等到时机成熟再进行迭代
④ 及时变更产品说明文档和原型设计，并和项目组成员、领导和其它相关部门同步信息
2 尊重资源
很多公司都是多个产品线并行执行，每个人都会遇到工作冲突，项目排期时应当充分考虑这个客观现实。我的解决方法是：
① 在制定排期时，乘以一个1.2~1.5安全系数
② 向领导层提前通报存在的风险，并告知我的处理方案
③ 将风险和解决方案写在排期表显眼的位置
3 时间排期的思考
其实时间排期是根据经验推算出来的，有经验的团队估算的时间往往是靠谱的。但对于新组建的团队，过去的个人经验往往会失真。需要经过一段时间的磨合，经过一两周的实际项目推进速度再估算排期会更加精准。
我的解决方法和产品迭代思维一样：在团队磨合过程中，时间排期也会从不成熟逐步迭代到成熟的过程。这个时期，产品经理应该定期与团队成员沟通排期的变化，更新项目排期表并通报给大家和管理层，就像定期迭代的产品一样。
4 阶段性成果演示
站在公司领导的角度想，从0-1的产品开发时长比一般的迭代周期要长很多，执行过程就像个黑体，中间出现问题很难发现，产品经理不可能及时知情。
我的思考：要有个定期成果演示（比如每周一次），
① 向领导、项目成员、甚至是特约用户演示，尽量用前端页面的形式展示
② 可能页面尚未完成，如按钮不能点击，数据是一堆“XXXX”，没有校验，但要让大家看出每周都在进步
③ 演示前要通报演示的范围和可能存在“八阿哥”，毕竟这就是半成品
④ 演示后让大家提出想法，比如是否符合公司的战略、用户体验、交互意见等方面，这样及时发现问题，便于产品调整，从而降低风险。提议尽量是开放性的，但要控制时间
⑤ 将大家的提议记录到需求池，并根据优先级决定是走需求变更还是今后迭代
