导读：需求没有登记不要发给技术，否则技术的时间不知道花哪去了。
目前的问题，技术的时间不按计划来，有些新需求，今天提，今天就插入到日程表，干扰既定目标。
计划，听起来有点抽象，简单来说，你去超市之前想好买哪些东西，那你可以很快买完，不用兜圈子，
但你没计划，你到超市就会随便逛，中途你老婆，老妈来个电话，让你买点东西，你花费时间自然多了。
我们的解决办法是：”计划管理“+”窗口管理“
计划是让我们提前锁定开发的时间，雷打不动的推进高价值事情（项目交付）
窗口是让我们把临时的，非紧急的事情（售前售后），化零为整的集中到某个时间窗口去处理
一、目的
时间在哪里，结果就在哪里，所以，管理时间，就是管理预期，管理结果
计划表，本质上是资源分配表，可以提前化解冲突，让风险领先问题半个身位，做前置处理。
我们决定推行项目计划制，并结合番茄工作法来提高时间价值。
我们把团队的时间分为两种，固定时间和碎片时间
固定时间，排除不必要的干扰，专注于处理我们预期内，计划内的事情，保障项目交付。
碎片时间，是计划外的突发性，临时性事件，处理我们预期外的事情，保障项目维护。
我们的策略是，减少碎片时间，为项目交付让路，确保时间价值最大化。
为确保策略有效执行，以下是实施细则，我们需要从全局视角来看待，并给予支持。
二、效率提升
举个例子，我们从1数到10，很快，很顺利
如果中间穿插着字母，比如1a，2b，3c，4d，越往后越卡顿，效率降下来了
我们应合理降低切换的频率，优先服务于目标和计划，才能提高产量和质量。
三、全局统筹
做月度计划，是为了站在全局高度，提前分配项目资源，在源头上化解项目后期的冲突
每月中旬前，项目经理基于当月交付目标，申请开发资源，制订当月开发计划，锁定目标
项目经理每周汇报进度，检查月计划，发现堵点和难点，及时沟通，及时解决，追赶目标
四、计划管理（固定时间，处理重要紧急的事情）
1、售前需求沟通
售前需求沟通相对紧急，时效性较高。
我们约定，每周一三五，晚上加班时间，项目经理开放售前沟通的窗口。
工作日上班时间，尽量让项目经理专注于手头的需求管理和项目推进工作。
需要紧急沟通的，一个项目经理和产品经理，一周内最多配合一次。
2、需求文档整理
每个项目的需求时间，遵循以下约定
项目经理跟客户沟通之日起，三天内输出《需求初稿（含模式）》
产品经理在接到需求文档之日起，五天内输出《需求复稿（含业务流程）》
产品经理在项目签单之日起，七天内输出《需求终稿（含交互原型）》
产品经理在输出需求终稿之日起，五天内完成需求评审和最终定稿，并送交客户确认
原则上，没签单的原型，排在已签单原型之后处理，需要优先的，应给出充分理由。
产品经理接到新需求工作后，当天调整日程计划表，发项目总监，同步到协作中心。
3、需求工期评估
工期评估依赖于需求，理论上，需求终稿的评估最准，复稿次之，初稿最粗糙，评估不准。
我们约定，每周三和五，专门处理工期评估事宜，其他时间，用于消化需求，输出需求文档。
业务等不及的，我们走简化流程（跳过需求评审，使用初稿和复稿的需求），凭经验报工期。
4、需求合理拒绝
回顾过去，有很多不匹配的需求，我们没有及时拒绝，浪费人力去评估，最终被证明没有价值
因此，在源头上，从公司利益出发，对于投入大于产出，产品结构不符等需求，及时予以拒绝
拒绝需求，项目经理或产品经理应提供充分理由，经技术专家和项目总监一致同意的予以拒绝
5、培训开放时间
培训的紧迫性相对没那么明显，我们约定，每周四下午，项目经理开放培训窗口。
当周有培训需求的，优先跟客户约好周四下午培训，周四不方便的顺延至周五上午。
6、项目进度同步
每周一18点~19点，项目经理集中汇报本月开发计划的进度，反馈上周遇到的问题和卡点
五、窗口开放（碎片时间，处理非紧急事件）
1、系统演示
每周一三五晚上，需在下班前通知，预约
2、售前需求
每周一三五晚上，处理售前需求
2、售后需求
每天晚上18点以后，处理当天售后需求
3、操作培训
每周四下午（周五上午），集中处理培训需求
4、评估工期
每周三和五，专门处理工期评估事宜
5、需求会议
每天晚上18点以后，处理当天的需求沟通
6、整理文档
每天晚上18点以后，处理文档工作
六、碎片时间（紧急类事件清单）
紧急事情，无论何时，接收到，应当立即响应。