最近有幸被指派作为主R负责两个横跨两个月、涉及多个人力的项目，对于之前没有太多项目管理经验的我而言是一个挑战和学习的机会。在项目推进过程中，所得到的学习和感悟颇多，故决定将或由上级教授，或自己领悟提炼的经验，一一记录下来，以供大家学习。可能有些看起来颇为幼稚，但是谁没有个从不会到会的过程呢。
一、缓冲时间/预备队
项目正常应该留有一定的缓冲时间，因为总是有意想不到的事务，乃至紧急需求插入，占据原本的开发时间。按照上级从百度带来的时间预估习惯，一个跨月项目（1.5-2月+）一般预留1周工作日的缓冲时间。
二、把工作交出去
带新人、带团队新成员时，要在脑里和培养计划里有一个目标，就是能把大部分工作交接出去，交由新成员完成。这样既保证研发互备，又使主干研发有精力身兼多个项目而不用事事兼顾，避免被太多具体事务牵扯精力而丧失对整体的把握，甚至主干研发可以以先驱者角色，去考虑更多长远的问题。
三、保守的排期
项目对外承诺完成时间时，给一个保守稳重的排期，宁可被人认为开发效率不高，也不要带有一点乐观情绪去给一个有风险的排期。承诺了排期却没法按时交付，既影响印象又影响绩效。
如果项目完成时间由外部给出，且需要高优满足，通过倒排的方式来规划排期。
需要和PM确认外部/上级对项目完成时间的要求，避免出现：研发给出乐观排期 -> PM以此排期和上级承诺 -> 上级关注此事，变成需要高优响应的需求 -> 研发需要强力保证按时完成，成为悬在头上的达克摩利斯之剑。
四、过程中对进度和人力的把握
项目实施过程中，作为主R要每天都对进度和人力的投入和产出有所把握。
第一是保证进度是符合预期的，每天跟进项目进度并比照计划，能保证项目如期完成。如果项目开始一段时间后，发现实际进展和预期不符，可能造成延期后，要基于实际开发进度重新规划项目排期，并同步到上级和相关部门。同步排期变更的时间最好早于需要延期的时，比如：项目需要延期2周，则在项目开始后两周内重新规划排期并给出包含延期时间的新排期。
第二是方便灵活调度人力以弥补项目计划的不足。比如某个子任务比预期要的时间少，已经被组员提前完成，掌握进度的话就可以分配后续的子任务。如果某个子任务比预期的复杂，则可以根据各任务的人力情况，再重复组织人力去填任务。
推荐使用甘特图作为规划项目排期的工具（可以直接使用Excel画甘特图，或者有适当学习成本的OmniPlan），横轴为时间，粒度到每天，纵轴标记任务，按粒度从大到小分单元格，每个子任务一个最小单元格，并署名相应的负责人员，任务所排时间则用柱状表示，如果任务完成则变换柱状的颜色。例子：
五、对核心工作/重难点的评估和把控
做方案设计时，要把核心工作/重难点的复杂性考虑好，需要对重难点有足够深度的思考，思考其可行性、成本和收益，这些工作都需要以书面形式拿到方案评审上被人质询的。最好有相应的经验能推断大概的开发成本。对于核心工作的开发有中什么不能确认有效的（技术是否满足要求、满足性能等），最好在项目开始前能尽量以小规模开发和测试、借鉴他人项目的方式论证。只要核心工作的设计可行、工期安排合理，整个项目就不会失控太多。
六、明确的目标和可量化的预期值
接上回，在设计方案时要一直对照需求，以确保方案没有偏离目标，对于是否能达到目标，方案最好能给出可量化的指标，以让上级对你的方案有信心。比如新方案经测试能支持5000的QPS，新方案将能把计算时间从2小时降至30分钟，等等。最好不要使用比率，比如比原来快2-10倍，降低50%存储空间等等，因为如果base值就很低，那么你投入的开发成本在上级看来可能仍是不划算的，可有可无的。例子：
推荐的方案设计方法：将一件大项目的若干个目标和为此所做的工作内容拆解到小块，列出每个任务（甚至可以是每个任务的每个可选小方案）分别对应的目标和可量化的成本，验证和预测该方案是否能达到目标，且付出上述成本下的收益是否可观，是否值得去做。
关于资源：一个系统需要维护的人效，也即人力维护成本是很重要的，如果系统为了追求效率，在有效提高性能的基础上提高了人力维护成本，即把系统做得更复杂了，那么除非性能是生死线，不然大概率会被上级否决方案。（计算/存储）资源使用的原则是，只要资源没有被浪费，哪怕使用量很大，也是可以被接受的。
七、保持文档与开发进度同步
项目开发经常发生文档滞后于开发的情况，且因开发工作繁忙，业务细节又繁琐，开发后一般研发也没有太多的主观能动性去更新业务文档。但是落后的文档可能导致和外界对接时的沟通成本增加，和人交接或培养新人的成本上升，所以保持文档最新的收益也是值得研发花费时间的。
可以以开发前的方案文档为骨架，在开发中不断填充上内容，将需要了解该业务所需的所有业务知识和技术内容都按照章程去填充至各目录，随时更新开发中对方案的变更、待办事项和已知问题等。比如如果你的公司是使用wiki作为文档工具，可以为项目新建一个目录页，再附上各种子页面，最开始的子页面即是项目方案页。
八、测试用例
这个应该大部分研发都知道的，先写测试用例再写代码。如果先写代码再写测试用例，可能会按代码逻辑去考虑异常case，而不是按业务逻辑去考虑，容易测不出实际问题。测试用例也可以一直同步到文档，这样后面追责或重构时，也方便从测试用例获得有效信息。
