做一些基础的项目管理工作，不要太多也不要太少。
我会在面试项目经理时问”你如何知道产品是否可以按时交付？”
- 创建一张简单的计划表并持续维护
- 只需包含任务列表和每个任务的工程量评估
- TODO：截项目管理电子表格示例图，www.shippinggreatness.com有下载
- 包含：
- 概况：剩余开发人日、编码测试时间、发布时间
- 发布日期：团队成员各自工作量
- 任务分配： 团队成员各自工作量
- 任务分解区域
- 余量假设和你大致需要的开发测试比也需要填写
- 一些团队判断五天的开发时间中只有三天是具备生产力的，所以60%的生产率估值非常合理
- 只在周二和周四推送代码，有时间修复
- 当项目所有主体工作尘埃落定，整个团队都集中精力修复Bug时，我会停止使用项目计划表，转而使用Bug列表和Bug燃尽图
- 如何拿到评估量，技巧
- 如果你不是工程经理，那么让你的工程经理去要评估量
- 表面上接受评估结果，工作量太大的话，将这个任务分解成多个小任务
- 认识到你的权力，向团队承诺你会权力支持他们，他们也要做出类似的承诺
- 只跟踪剩余时间，着重于吸纳古墓的实际情况，便于你发现项目何时可以编码完成 * 要求不考虑余量的评估，在项目计划表中清晰地标出余量这个参数
- 每周一次在团队会议上评估个任务的剩余时间
- 跟踪Bug，观察燃尽图
- 燃尽图：反映你的Bug数量随时间变化情况的图表。
- 为不同严重等级的Bug各绘制其数量随时间变化的曲线。
- 当Bug发现/修复率降到1以下时，你便能通过计算Bug数归零的日期来预测产品何时能按照给定的质量等级发布了。
- 如果你对测算出来的发布日期不满意，你只有两个选择：降低你的质量标准，或者增加工程人力以更快修复更多bug。
- 谨慎管理你的依赖
- 目的：将风险最小化；一些技巧：五个如果
- 如果去除它可以运转，那就去除它
- 如果内部能构建，那就内部构建
- 如果必须添加一个依赖，那就趁早添加。把风险最高的问题放在最前面去解决
- 如果必须添加一些依赖，那就依靠它上一个已构建的版本
- 如果交付的早，被依赖伤害的可能性就小
- 目的：将风险最小化；一些技巧：五个如果
