回顾一个内部加急项目踩的坑

1. 计划赶不上变化快

项目（架构）设计不足，导致项目模块拆分颗粒度不够，前期的预想功能被砍掉，中途重新启动了新的功能。

2. 研发“真的不看”原型

懒（又不做产品需求文档又不做需求讲解的）产品经理最终都会死的很惨！

即便是讲解了需求，也要定期做需求拆解；

需求的变更要多途径同步，包括不限于当面沟通、群同步、抽时间原型演示（跨团队还有必要发邮件做备份）；

如果时间允许，产品需求文档还是必要的。

3. 多说，多干！少说，少让步！

先不管实现难度，先考虑拓展性。

实现效果可以让步，拓展性却会时刻影响产品经理的大局观。

4. 研发的技术研究也在时刻提升

早先前端的难题，临项目结尾发现前端已经解决并实现很好——说明研发生产力本身就在时刻提升。

问题暴露：一方面需要公司内部能够及时分享同步有突破性的技术研发成果，另一方面需要产品项目成员在项目的开展阶段多去研发取经了解技术研究成果然后同步出来。

5. 做产品不能闭门造车

5.1. 产品发布要有节奏有规划。

项目预期管理中要有至少不少于2个Sprint 的规划，并且有预期实现的项目节点；

5.2. 定期收集需求。

需求可以来自任何一个部门或同事，前线同事汇总需求经由整理后确认是否实施、实施周期等，组织前线人员沟通会议

5.3.定期同步进展。

包括不限于项目进展汇报（周报或PPT）、实现效果展示（提供URL及测试账号）、各子系统之间的关联进度

6. 缺少发布流程

项目拆分模块太多，发布时无串联动作。

需要有发布流程，并且每个大的业务模块有个统筹负责人（骨干）。

既然来了，就关注下吧

题图：思考与辩论的喇嘛