如何做好一个项目或迭代的负责人

首先，我将一个任务（以下称项目）从两个层面来分类，一是产品层面，二是技术层面。并且，从产品层面分为：产品级和项目级，从技术层面分为：正常迭代和技术优化。无论是哪一种类型，都离不开同一个流程。
一、初期：
1、需求会&问题确认：
在初期，无论是什么项目都会有由产品经理发起的需求会，作为最接近用户的一环，测试人员在会上起着至关重要的作用，可以根据我们对现有业务的了解和用户的体验，对需求提出很好的质疑和建议。当然了，所有的问题也不会在会上短短的时间提出来，在会后或编写测试用例的时候对一些细节可能还会有一些问题，一定要做好记录（如：需求问题列表）并通知产品及时回答或更新需求原型。
2、用户故事卡片拆分：
需求确认后，作为整个项目负责人就可以进行用户故事卡片的拆分，并通知相关技术负责人在规定时间内给出合理排期，再由负责人确认敲定并通知产品经理。
3、技术方案评审：
还有一点很重要的就是技术方案，它关乎对整个项目需求的具体逻辑实现。了解清楚技术实现和约定，会对项目跟踪和把控有很大帮助和作用，所以一定要参加技术方案评审会。
（1）知道功能是如何实现的，为什么要这样做，也会帮助我们做出更具有针对性的测试计划，也可以帮助我们判断它的合理性。
（2）尽早判断、把控项目可能出现的风险。
4、编写测试用例（或测试计划）&评审：
测试用例的编写在需求会后如果没有流程和故事上的严重缺陷就可以着手了。虽然在需求会及之后已经确认一些问题，但在编写用例的过程中还是会遇到一些细节问题，可继续在问题列表补充并通知产品解答，完成后需召集项目参与人员进行用例评审并完善。对于技术优化来说，可能没有详细的测试用例，但一定会有测试计划。
二、中期：
1、进度&交付质量把控：
在项目进行中，不仅要完成自身要完成的任务，最重要的是要把控整个项目的进度，眼界就要从自身的微观任务扩大到宏观的角度上。可以采用早上站会的方式来同步进度，用5 - 10分钟的时间确认已完成的故事卡片以及当天要完成的故事卡片。如果没有按照预期进行，需要评估风险并通知产品。
2、记录与沟通：
（1）项目负责人需要对开发过程中出现的问题和重要节点进行记录，即项目迭代记录。上述说到了进度同步，有些在技术方案评审时未考虑完善的问题会在实际项目开发过程中暴露出来，也有些产品需求也有可能会出现变更，也就是说中间可能会出现与故事卡片排期相比延期的情况，怎么办？找相关人员搞清楚原因及具体完成时间并同步给产品，然后作为摩擦力记录下来。我们所有记录的东西都是为最后的复盘提供素材，作为我们要改进、变得越来越好的依据，所以一定要把这些阻碍我们前进的问题记录下来，避免、改进。
（2）项目进行过程中沟通是至关重要的，它起到的作用就是信息同步和达成一致共识。因为项目所涉及的人员不止一个，沟通信息的入口是很多的，所以为了信息同步和一致，就需要一个媒介作为唯一的出口，可以QQ群或微信群等即时通讯工具。如果其他成员像项目负责人提出问题，负责人确认后需要群里通知给出确认答案，但如果是其他人确认的问题也需要在群里周知到大家。
三、后期：
1、回归测试&上线：
（1）项目进入后期阶段，也是到了最后的关键性阶段，涉及到很多关键的节点，如：测试完成时间、服务端的上线时间和客户端的封板时间。对整个项目的回归测试和兼容性测试，以及对现有功能的回归测试，还有bug的验证和回归，并在测试备忘录记录流程中任务完成时间。
（2）凡是涉及到上线，都要相关负责人提前编写上线备忘录，也就是上线计划，其中包括上线内容、步骤及回滚方案。
四、复盘：
（1）bug分析：
项目结束后需要对bug list中的bug做出归类并分析，然后做出统计并通知相关负责人进行分析，作为复盘会依据。
（2）复盘会：
作为项目的负责人召集项目的参与人员并作为主持人召开复盘会，回归项目迭代中关键节点的实际交付时间、bug产出和遇到的摩擦力。并以此为依据，讨论所遇问题的解决方案或改进方法，达成一致后指定到专人负责改进方法，并在以后的项目迭代中使用后再次进行复盘。