项目过程管理真实历程

      5,6月份 ，在淘宝工作很忙,也很充实,一个接一个的项目和日常,使我在项目过程管理中得到了真实的历练,流程上也梳理的比较清晰,自己心里默默感觉在工作节奏,业务理解,技术上也不断在成长。现在把我所实践过的项目管理过程分享给大家。
      项目刚启动的时候,需求在主体功能是清楚的,但是细节方面并不是很清楚,PD只是和你讲要做这些功能,其实这个阶段也是我心里最犯嘀咕的时候,因为听PD说每一个需求的时候,我并不完全知道每个需求实现上的难易程度。只能靠自己对业务的理解和平时做项目和日常积累下来的业务经验去判断和度量。真正需求比较清楚的时候是需求说明书也就是PRD文档,在TB会对PRD有个正式会议评审,评审的时候一定要把产品设计师,运营，测试，研发都叫上,尤其是运营和开发,PRD评审的时候,运营的意见和对产品的理解直接关系到产品的用户体验,产品是否得到用户的认可,所以PRD评审阶段我会关注运营的意见,还有就是要关注每个与会者的意见,若大家都听PD讲PRD文档,一点意见都没有,这肯定是一个不好的信号，这个时候我就要跳出来多问PD几个反问句,一方面是看看大家的反映,另一方面是看看自己对PRD的理解。高质量的评审会议,一定要在激烈争论中和建议中才能把需求疑惑问题解决掉。每次PRD评审都会有个评审结果,用来跟踪评审中出现的问题,会后PD会根据问题，去修复PRD中的缺陷或bug。
      PRD评审结束以后,开发同学就要根据bugfix 以后的PRD文档去设计UC和技术方案,在TB这步骤很关键,直接关系到系统可用性，稳定性，扩展性，所以在TB技术方案的设计和选型时很重要的一步.对与开发的UC要根据PRD写的全面和清晰，在写UC的时候对PRD不理解地方一定要找PD去确认，哪怕是一个小小的文案。技术方案一定要把关键业务主流程和分支流程梳理清楚,便于测试去理解,项目组的研发成员也能去理解.这个阶段的评审我最关注测试意见,因为我们的产出物直接服务于测试,而且也对将来产品或功能是什么样子进行了更具体的描述。这个阶段的评审也会产生评审记录,对评审结果进行bugfix.
      接下来最后一关的评审就是测试评审了, 测试会根据PRD文档,UC，技术方案去写测试用例,也是测试评审最关键的部分,这个阶段开发同学一定要关注每个测试用例是否都覆盖到自己的UC中和PRD中，是否有遗漏或理解上的差异，都要开发同学去仔细的听，这是我们保证产品质量的最后一关,将来测试是否发现太多bug的关键一步。
      TB项目过程管理的每一步都渗透这项目组成员的智慧和汗水,如何高质量的交付产品是研发成员基本的职业素养，在项目过程中不断的去磨练和成长,你会为自己的付出和进步感觉到满足。希望后续的项目或日常能更加顺利,不断的去磨练,去成长，去超越自己。