背景
自己或者周围的同事有没有做过这种事情：一个自己认为只是内部改造的功能上线了，几天之后合作团队找过来问最近是不是有变更呀？接口行为发生变化了怎么不通知到我们呢？
自己认为纯内部的事情其实不是，影响没评估好。
或者有没有遇到过这样的事情：做出了一个自认为没有什么问题的方案开发完了，上线前给领导汇报变更影响。结果领导不同意这个开发方案，需要从长计议。
上面两件示例中的问题有个通用的解法：定制一套合理的项目流程。要说明的是做这件事的项目不一定是一个大佬。有可能是刚毕业没多久的同学，上级或者导师交给了自己一个需要做2周的任务，就算自己独立完成也都算一个项目。只有一个技术人员做，那这个技术人员就是这个项目的项目经理。
以下是自己的一个常用流程总结，可根据项目大小等情况合理选取部分环节，仅做参考。
需求评审
建议形式：会议形式
目标：定需求大方向
参加人员：技术经理、需求方
主要角色：主持人一名、会议记录者一名(建议主持人和会议记录者为不同的人)、能提出需求中的问题和疏漏的高阶人员若干
评审结论通知到：领导、参加人员
方案评审
建议形式：会议形式
目标：定需求细节、排期
参加人员：各方开发人员、技术经理、QA、需求方、潜在用户(比如一个通用组件可能其他团队也有需求)、相关合作方
主要角色：主持人一名、会议记录者一名(建议主持人和会议记录者为不同的人)、能提出方案中的问题和疏漏的高阶人员若干
评审结论及最终方案文档发送给：领导、参加人员
方案汇报
建议形式：会议形式
目标：达成共识、争取支持和资源
参加人员：领导、技术经理
如果方案有改动则需要重新发送给：领导和方案评审阶段的所有参加人员
动员会
如果是一个并非外部需求驱动的项目，比如在业务部门的长期实践中孵化出来的一个公司级的基础组件。做成一款自己的产品。这时候，最重要的事是要做的人都要有信心和信念把东西做好。自己没有注入灵魂的产品是不可能成功的。
这时候，作为项目经理+产品经理，需要把自己对项目的理解、思考、未来规划和所有实施人员对齐。
开发
建议形式：拉微信群、企业内部交流群沟通
目标：问题及时反馈沟通、进度同步
参加人员：各方开发人员、技术经理
联调
建议形式：拉微信群、企业内部交流群沟通。必要时可在工位或封闭会议室
目标：问题及时反馈沟通
参加人员：各方开发人员、技术经理
代码提测前评审
建议形式：会议形式
目标：对平时已经由个人review过的代码再次梳理，通过review代码发现潜在问题
参加人员：各方开发人员、技术经理、QA
验收
建议形式：会议形式
目标：确认完成的产品和需求的一致性，对之前没有完善的细节需求做补充
参加人员：各方开发人员、技术经理、QA、需求方
验收分为全新功能验收和旧功能改造升级。全新功能验收，主要依赖大家对产品的理解、领悟和感知。旧功能改造升级最好有新老结果对比。举例如下：
QA测试
建议形式：拉微信群、企业内部交流群沟通。必要时可在工位或封闭会议室
目标：找出并修复问题
参加人员：开发和QA
投产
建议形式：正规发布流程
参加人员：技术经理、开发人员
注意：需要通知到之前参与过的各方
总结
互联网下半场需要模式的转型：从野路子到正规军。