-
常规的项目管理
-
需求分析
-
明确原始需求【必须要接触最原始的用户需求】
-
忽略需求方提出的所谓解决方案——最佳实践1
-
竞品分析
-
撰写UseStory
-
拉FeatureList
-
分期实现小步快跑
-
轮询各个系统负责人，评估对所有系统的潜在影响——最佳实践2
-
项目启动
-
以会代训：启动会——最佳实践3
-
约定项目占用资源
-
列出干系人
-
项目进展每周三周五与干系人分享——最佳实践4
-
Project计划
-
拉里程碑
-
拆解到以1～2人天为单位的子任务——最佳实践5
-
列出前置资源
-
项目跟催
-
延期预先通告
-
需求变更管理
-
拒绝不紧急不重要需求
-
重要但不紧急需求放在下一次迭代做
-
评估对所有系统潜在影响
-
以会代训，会议纪要作为执行决议
-
设计评审会
-
跨部门难题推进会——最佳实践6
-
周报
-
周报上先列timeline——最佳实践7
-
子任务列表，对应的完成百分比
-
风险预警
-
紧锣密鼓
-
站立晨会——最佳实践8
-
任务看板
-
定期定时项目协调会——最佳实践9
-
快马加鞭
-
日报
-
工时统计
-
产品研发测试锁定会议室集中办公——最佳实践10
-
周日联调
-
以演示会作为阶段性deadline推动——最佳实践11
-
测试用例评审会
-
实施计划
-
数据迁移
-
项目经理收集整理本项目涉及改动的系统、需重新部署的系统和模块、数据表结构变化列表
-
盯住验收
-
分批实施
-
部署计划和实施方案
-
上线后的问题处理预案——最佳实践12
-
关键因素
-
向下关注
-
三岁宝宝端水的段子
-
发出指令，必须深入了解执行步骤和执行细节
-
代入式思考，落实到执行层面
-
导演和制片主任模式
-
了解背景知识
-
给出备选方案
-
跨部门征求要不要这么做，而不是征求怎么做
-
养成拉List清单的习惯
-
发现问题
-
放大问题或认清问题
-
尊重海恩法则
-
每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患
-
脏数据和投诉背后隐藏着致命真相
-
不能等死