一、互联网产品的发展阶段概述
1、初创阶段
面临挑战：1、如何满足痛点和商业目标？2、能否解决用户的痛点？3、产品体验如何？
主要目标：找到用户痛点，做好功能分析，迅速上线验证，种子用户认可。
主要策略：1、根据用户需求，做好需求分析；同时建立自媒体通道，为种子用户和后期运营打基础；2、迅速完成原型，做好设计，快速开发，做好产品测试，保证用户体验；3、获取种子用户，跟踪并做好意见反馈，做好数据分析，不断改进和提升产品体验，以获得种子用户的认可。
2、成长阶段
面临挑战：1、如何运营产品才能快速提升流量和知名度？2、如何转化或者变现？
主要目标：获得用户，转化变现，建立品牌，名声远播。
重点策略：1、利用前期积累的种子用户迅速推广，扩大影响力；2、加强运营团队建设，主要围绕运营展开工作，一方面做好拉新，促活和留存工作；另一方面搞好品牌建设；3、做好数据分析，用户方面要重点关注用户留存率，DAU（日活跃用户数量），MAU（月活跃用户数量），以及付费用户数据和ARPU（每用户平均收入）等数据；推广方面要重点关注推广渠道数据，根据数据优化渠道组合；品牌方面要重点关注百度指数等等数据；产品方面要重点关注页面访问数据，跳转数据，访问时长，用户使用路径等等方面；要围绕数据和用户做好功能更新和产品迭代。
3、成熟阶段
面临挑战：1、如何保持新用户稳定增长？2、如何稳定的将用户变现从而实现盈利？
主要目标：活跃并维系好老用户，同时保持新用户增长，继续稳定地实现创收盈利。
主要策略：1、活跃并维系好老用户，主要利用运营手段，采取激励体制激活他们；2、继续数据分析以及产品迭代工作；3、继续做好用户转化变现工作，进一步提高营收能力。
4、衰落阶段
面临挑战：1、如何将流失的用户拉回来？2、有没有机会创新或者产品能否转型？
主要目标：尽力做好用户回流工作，同时更新产品线，寻求创新和转型，以求解决用户新的痛点，从而继续占领市场。
主要策略：1、想办法了解和触达流失用户，然后通过运营将他们最大程度的回流；2、关注竞品的动态，做好竞品分析，借鉴竞品模式，提升产品竞争力，以求从竞品手中抢夺用户，或者不被抢走用户；3、进行市场调研（包括竞品分析），寻求新的项目机会，或者更新产品线，想办法满足用户日益增长的新需求的目的。
二、传统互联网项目管理流程
1、立项规划阶段
主要角色：产品经理；
工作目标：分析、理解、控制用户需求；一端对接用户，另一端对技术人员
2、计划执行阶段
主要角色：项目/研发经理；
工作目标：
1、计划阶段：制定分目标，起止时间，参加人员及人员所属任务；
2、执行阶段：掌控监督开发的各个环节，即时反馈阶段性的成果并协助、指导项目组成员的工作，保障项目的顺利交付；
3、测试发布阶段
主要角色：测试经理（测试经理是一个泛称，很多公司没有测试经理岗位，可能是测试主管，或者测试组长。也有很多公司，没有测试管理岗，没有测试负责人，统一归项目经理管。）
工作目标：测试任务分派和问题监控与反馈。
注意事项：
1、如果说产品经理管理的是“产品”，那项目经理管理的就是“人”，产品经理保证的是产品“有人用”，而项目经理保证项目的按时按质“完成”；
2、虽然说产品经理，项目经理，测试经理分别具有不同的职责范围，但很多时候的也存在职责重叠的情况：时间的概念、进度的规划、质量的要求等可能是三者协调一致的结果，也可能一人分饰两角；
3、在很多中小企业的项目经理也是产品经理，或者没有测试经理，这个并不奇怪。所以项目管理并不是一个单项流转的过程，三者所承担的角色也不是一成不变的；
4、传统互联网项目管理的经验优势还是建立在风险把控、沟通管理和进度管理上；
5、项目管理始终关注的是进度，质量，成本和范围四个要素，要把项目做好则首先需要保证过程的稳定性。
三、谈谈敏捷
1、什么是敏捷？
敏捷的起源：2000年初，美国在计算机行业已经走了几十年，瀑布流、螺旋模型、快速迭代…各种各样的软件开发流程雨后春笋各领风骚一段时间。虽然不断变化和完善，但互联网的加速发展让传统方法显得笨重，难以快速适应变化。有十七个程序员（程序员改变世界）在美国犹他州的一个风景区开了个碰头会，找到了一个团队耦合度高，流程极其灵活的方法，他们把它称为agile program development。
敏捷宣言：这十七个程序员如同开宗立派的长老，在会议之后给自己起了个名字“敏捷联盟”，他们不仅赋予了新方法名字，还有宣言，甚至纲领。
敏捷遵循的原则：
1、agile：迅速，敏捷。这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街；
2、sprint：字面意思是短跑冲刺，一个开发阶段被认为是一次冲刺，一个个 sprint 首位相连，构成一个项目；
3、scrum：本意指的是英式橄榄球中一股脑争球这一战术或行为。scrum 即为这样一种方式，大家一拥而上，团队是球员，球是产品目标，人员环环相扣，围绕着产品目标进行工作。这里面多少有点“统筹法”的影子，人员深入协作以达到最优化效果；
4、product backlog：即需求池。待办事项列表。敏捷需要维护一份详尽的需求列表。这份列表常常要求 scrum 持有人（一般是产品经理）对所有待开发事项有深入了解，并且能够把待开发事项分解成更为细致的任务（或者跟敏捷教练一起，后面我们会再次提到敏捷教练）；
5、story board：故事版，看板。在开发领域，故事版是任务流转的可视化窗口，一般有“待开发”“开发中”“待测试”“返工”“待发布”几个区块，所有任务由任务操作者负责流转至于下一个步骤，这样任何一个人项目成员都能看到任务的完成情况；
6、burt down chart：一个 sprint 内，人/时是一个比较固定的值。在这个时间框架充分安排开发任务，每天进行时间结算，绘制时间燃尽图。项目成员通过燃尽图获知时间进展，若项目燃尽所用时间与预期时间契合，则需求时间预估和安排合理，若不契合则需要在下一个 sprint 进行调整。
如何敏捷？
用了敏捷工具就敏捷了吗？jira、redmine、禅道、百度的icafe、阿里的aone、腾讯的tapd……我们在 tapd 上建迭代，建需求，研发、测试等着收到需求流转的邮件之后开始干活…任务在测试和研发之间流转，bug 提给研发，研发解决 bug …..我们宣称：我们敏捷化了！我们习惯于敏捷软件的便利，拉群解决一切，然而却丧失了敏捷的初衷，scrum 的本意。
假设没有工具，敏捷怎么做？
1、PM：确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责；
2、SM scrum master：SM 全称 scrum master，中文称敏捷教练。一般说来，SM 需要由对技术开发以及当前项目明晰的技术经理担任。SM 是 Scrum 教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
3、白板，笔，便利贴；如果还有电脑可用，excel 或者 word，甚至写字板都可以，没有电脑那就白纸好了，总之你得找个地方写下你的需求池（backlog）；
4、需求池示例 backlog；任务名称、平台、详细描述、优先级按照P0-PX逐渐递减；
5、确定一个sprint周期：PM SM 单独开会确认，统揽需求，SM分解，得出开发列表；
6、scrum 会议，讨论 sprint 功能点；成员讨论所需时间，需求是否match 人力时间，需求排入 sprint，每个任务的预估时间在最后由敏捷教练（sm）综合判定；
7、scrum 会后产出：a、整理这个 sprint 内的需求列表；b、整理每个需求的预期开发时间；c、撰写故事版上的小纸条；d、把小纸条贴到故事版上；e、制作一个燃尽图；
8、每日项目短会：agile 的日常修炼；a、参会人员：SM、PM、scrum 成员；b、站会干什么：昨天大家分别做了什么事，遇到了什么问题，如何解决或寻求解决方案；昨天任务的完成状态，剩余多少时间，是否需要进行时间修正（增加时间或减少时间），把已完成的任务流转到下一环节（把纸条从一个item内撕下，贴到下一个item里去）；功能测试后是否有返工？c、会后更新燃尽图；
9、会议种类：sprint计划会议、每日站立会议、评审会议、回顾会议；
敏捷不需要文档吗？
从长期和宏观上看，文档对于敏捷团队和敏捷的实施利大于弊——节省在一些常规问题上的沟通成本，同时降低错误的发生概率。对于一个将要长期实施敏捷的 团队来讲，文档让后续的工作效率更高。
产品文档：需求、加入日期、版本、呈现和详细方案；
概要设计：敏捷的常规迭代中，概要设计不是一个必须的文档。但全新项目、重构以及重大新功能则必须输出概要设计文档。研发 leader 责无旁贷，这个落你身上了；
接口文档：必要且重要。包括接口说明、字段定义、字段类型、值定义、数据上报、错误码等。一般来说约定之后由接口开发者更新文档，如果你们没有云端存储的能力，至少咱们人手一份，定期更新；
长久来看，文档是提高效率的一大利器。空间上，文档传播范围更广；时间上，文档流传性更好。
注意事项
敏捷是一种流程、方法、理念，甚至信仰。
用了敏捷管理软件不一定就是敏捷。敏捷的初衷是团队成员能够更加紧密地配合完成工作，线上的的流转如果削弱了这种配合性，反倒背离了敏捷的本意。实际上只要有白板纸张和笔，你的团队就能开始敏捷。
我们敏捷了，不是不要文档了。在外部交流多、世代跨度长的情况下，文档的必要性显而易见。长期的面对面沟通最终会导致低效，这也是敏捷缺陷的根源。
大项目开发中可以走敏捷，具体问题具体分析，需要根据项目特点制定敏捷计划。
四、敏捷与传统项目管理的区别
1、焦点：传统项目管理处理事，敏捷聚焦人；
2、管理：传统项目管理侧重控制，敏捷侧重促进；
3、需求方参与程度：传统项目管理需求方参与在需求收集和交付阶段，敏捷要求需求方全程不断参与；
4、职能团队协作：传统项目管理职能团队单独工作；敏捷要求不同职能协作或结对；
5、产品功能：传统项目管理要求功能大而全、尽善尽美；敏捷侧重聚焦重点功能；
6、测试：传统项目管理要求测试在开发周期结束时介入；敏捷要求测试迭代或驱动代码改进；
7、文档：传统项目管理要求文档齐全；敏捷要求文档准备必要的文档；
注意事项
不同的管理方式适用于不同类型的项目，Scrum更适用于未知、不可知或持续变化的项目；
传统的管理方式有如计划经济体制，Scrum有如市场经济体制，适应变化的能力不同；
敏捷极大地缩短了用户与开发者，预期目标与实施状况，投资与投资回报之间的反馈回路。
以上介绍了互联网产品各个阶段的情况与传统瀑布流项目管理和敏捷的区别，两种组织方式各有利弊，在决策选择落地何种项目管理方式的时候，一定要注意团队文化、团队组织能力，组织架构等方面的因素。生搬硬套注定会失败。
永远记住项目管理的三字精髓：“看情况”。