互联网产品项目从立项到结束经历三个大的阶段，分别是规划阶段、实施阶段、交付阶段，每个阶段的重点都有所不同。

1. 规划阶段

项目规划阶段需要进行项目立项，在立项过程中，需要确定项目组成员，建立项目组织结构图，并确定各项目组成员的责任。

另外，在项目立项会完成之后，需要发送项目立项通知。陈述项目背景，确定项目组成员与具体责任，确定项目的长期目标，定义项目的重要里程碑和相应计划，以及确定项目的范围，避免后期有超出项目范围的需求产生。

项目规划阶段的重点是确定项目需求和项目资源，一般情况下是先确定项目需求，确认项目的具体范围和项目目标，之后再确定投入的项目资源。

（1）项目需求

项目需求的确定包括制定项目的需求范围、判定需求是否超出范围、确定项目的需求，另外也包括确定项目的长短期目标和项目交付件的质量要求。项目目标和质量标准也是项目需求的一部分，应当在规划阶段一并确定。

其中，也需要规划项目需求管理计划，确定需求沟通会的具体机制，包括沟通会的时间、内容、参与人员。另外，需要设立项目需求池，将项目的所有需要投入需求池，并标注需求的当前状态，需求池的内容也应当定期向项目组成员披露。

收集项目需求时需要做预判断，判定是否超出项目范围，如果没有超出，则纳入需求池，如果超出项目范围则拒绝需求。最终，需要从需求池中确定进入开发计划的需求。

需求相关的讨论，包括需求的反馈、评审等，尽在在需求沟通会上完成，避免在其他会议上针对需求相关内容进行讨论，这里也体现了控制沟通的重要性。

此外，对需求范围的控制和对需求方的期望管理也十分重要，需要使需求方的期望和需求对等，避免出现期望超出需求范围的情况。

（2）项目资源

确定项目需求之后，根据项目的具体要求和未来产生可能产生的收益来评估需要投入的资源。这里的资源包括人力资源和物资资源。人力资源一般是以产品、设计、开发、测试的人员投入进行计算，一般以人天来统计，物资资源根据情况各有不同，根据实际情况统计即可。

根据确定投入的资源来估算成本并制定预算，预算可以在成本的基础上做一定比例的上浮，留出合理的预算空间，以应对紧急情况的出现。上浮的比例视公司和项目的情况而定。

在人力资源确定之后，需要将工作和职责与人员进行关联。将整个项目拆解为可估算、可分工、可控制的的活动，并创建工作分解结构WBS，并将每项活动划分到对应的责任人或责任人组。

2. 实施阶段

项目实施阶段阶段的重点是把控项目进度，监控项目风险，并为此进行持续的沟通

（1）项目进度

对项目进度最好的定义标准便是时间。

确定项目资源投入之后，需要根据需求和资源确讨论项目的开发周期，确定项目的Deadline，树立项目里程碑计划，一般情况下需要定义原型确定、设计稿确定、开发完毕、测试完毕4个里程碑。

在这个过程中，最重要的一个产出就是项目进度的甘特图。项目甘特图中最重要的三个元素，一是将项目需求和目标进行拆解，拆分为可估算、可控制、可分工的活动；二是为活动确认唯一的责任人或责任人组；三是为每一个活动确定Deadline，并标注相应的前置事件。

每日都需要例行的对项目进度进行跟进，并在甘特图中更新，同时知会到项目组所有同事。

（2）项目风险

互联网产品的开发过程中，经常会出现的风险有三种，延期风险、人员变动风险和质量风险。

其中，最常见的是延期风险。针对延期风险，需要采取两种行为，一是项目的日常监控，在风险未出现时提前预警，需要项目经理对项目进度有实时把控，且对项目进度有提前的心理预期，需要将心理预期和实际进度进行对比，结合时间进度，判定项目是否存在延期风险；二是风险出现之后的弥补措施，延期风险出现之后，切莫贸然的增加资源尤其是人力资源的投入，首先需要掌握导致项目延期的问题，给出解决方案之后，依然由相应的负责人进行跟进解决，如果暂无解决方案或者解决方案也无法避免延期风险，则需要评估导致延期的部分是否对项目的目标和质量有很大影响，结合需求方的评估，考虑是否将带来问题的功能点进行剥离，如果不剥离，则风险不可控，可能会导致项目整体延期。

人员变动的风险一般情况下较少主动出现，针对人员风险，也是采取两种行为，一是在项目开始之前，确定项目成员时提前了解相关信息，尽量避免有此风险的人员进入项目组；二是如果在项目过程中发生人员变更，务必将变动人员和交接人员预留重叠时间，除了顺利完成项目工作交接之外，尽量保证在变动之前，交接人员已经正式接手项目工作。

质量风险大多出现在项目即将开发完成的阶段或者项目的交付前的测试阶段。有可能出现两种问题，一是产品的视觉或者交互BUG较多，这种问题大多由UI和产品确认，确认为实现问题后，按照设计稿修改即可；二是产品的逻辑BUG较多，这种问题大多由测试和产品确认，确认为实现问题后，按照原始文档的描述修改即可。出现质量风险且在风险消除后，需要明确引起风险的责任归属问题，以便对项目组成员进行后期的考核评定。因质量问题大多出现在项目后期，一旦出现，弥补的成本较高，因此需要尽量在前期避免，一是在项目进入开发之前，针对逻辑和交互视觉进行详细沟通，二是在项目进行过程中监控以了解项目的实际情况，出现问题即刻确认并调整，避免后期积压质量问题。

针对项目风险的管理，大体可以总结为三部分，第一是在项目规划阶段确定哪里可能会出现风险；第二是针对可能出现的风险提前制定应对措施；第三是在项目实施过程中，实时监控项目进度，针对有可能出现风险的地方提前进行预警并采取应对措施。

（3）保持沟通

沟通需要贯穿项目始终，有几个大的原则需要注意：

一是在项目规划阶段确定沟通渠道和对应的沟通机制，沟通渠道主要包括IM群组、邮件群组、项目例会等，沟通机制包括各个渠道下对应的沟通目的、沟通内容、沟通时间和参与人员等。之后在项目实施过程中，按照既定的机制和渠道保持沟通；

二是明确各个模块的沟通人员，一般情况下是各个模块的负责人，也有可能是各模块负责人指定的人员，与各个模块负责人沟通的事项范围理应不超出其负责的活动项；

三是项目相关信息的及时同步，确保有关项目整体的信息，包括项目进度、项目变更、项目里程碑、项目成果等在项目组内部的及时同步，同步方式按照沟通机制确定的即可；

四是把控项目组的内部沟通，确保干系人获取的信息不跨界，控制项目会议和邮件的知会范围，避免由于沟通过度反而影响项目的正常进展，另外确保干系人得到且只得到他需要的信息。

3. 交付阶段

（1）项目质量

交付阶段需要重点把控的是项目质量。项目质量既包括在项目规划阶段设定的商业目标或运营目标等，也包括项目交付件本身的质量是否达到质量标准。

商业目标或运营目标在项目正式交付之前无法评定，只能是在项目正式上线运作一段时间之后甚至在项目结束后，才能获取相应的数据来判定是否完成商业目标或运营目标。虽然有一定的滞后性，但是在项目复盘中的重要性是不可取代的，毕竟产品最终还是要服务于具体业务，只有产品的健壮，但是不能满足业务要求，产品的存在也是缺乏意义的。

互联网产品的质量大多指的是产品的视觉和交互是否达到初始设计的要求，需要由设计和产品来进行评定。另外就是产品逻辑的正确性和合理性是否与产品文档描述一致，需要由产品和测试来进行评定。质量评定的标准则是产品BUG数量的多少，而BUG数量的多少来源于测试用例和实现效果之间的差异，而测试用例则是依据设计稿和产品文档进行撰写。测试在此过程中，则同时会审视规划问题和实现问题，并在测试过程中判定责任的归属问题，有些时候是因为产品在规划阶段设想的不够周全导致BUG的产生，有些则是在实现阶段未按照具体要求实现。

（2）项目上线

项目质量通过测试之后发布上线，属于项目阶段性结束，发布上线公告，着手准备项目复盘是不可缺少的工作。

发布项目上线通知，需要明确项目上线的时间，上线的具体内容，最好能有相应的示例，如果有后续跟进事项和其他需要说明的事项，也一并在上线公告中说明。

最后，收集项目规划和实施过程中遇到的问题，找出问题出现的原因，并给出相应的改进措施，制作项目复盘材料，沟通项目组安排项目复盘会议，有针对性的总结经验，前车之鉴，后事之师。