2015-12-15-研发项目管理培训

研发项目管理系列培训游青华2015-12-14关于培训的题外话培训是否重要？所有人都太忙，所以不用培训新人报到后只要分配好任务他就会很快上手只要交代好工作，员工就会按照我们设想的达到目标员工经常达不到我们的期望培训很重要培训可以让新员工很快了解我们现有产品，了解现有产品的实现机理培训可以让下属清晰的知道你的期望培训可以让每个员工觉得我们是专业的培训可以让员工工作效率更高问题来了培训什么？职能培训管理培训•产品培训•技术培训•规范培训•智慧教育相关业务培训•。。。•如何做项目管理•如何做产品经理•如何开会•如何人力资源管理•。。。关于培训的题外话谁来做培训？管理者(PMer)主题第一讲研发PM职责需求开发与管理第二讲计划管理风险管理第三讲人员管理技术管理第四讲好的产品经理和差的产品经理PM职责与需求管理第一讲研发PM职责RDPM-JobModel范围功能范围性能范围进度整体进度里程碑进度周进度质量需求质量设计质量编码质量测试质量团队士气激励绩效技能需求管理：项目成功的关键因素需求不清晰需求不完整需求变更频繁清晰的远景和目标不切实际的用户期望信息传递失真业务方100%需求方50%设计人员16%开发人员8.4%需求的三个层次业务需求用户需求产品需求业务需求就是业务目标、愿景，它必须是业务导向的、指导软件开发的高层需求。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统（why），组织希望达到什么目标。也叫市场需求。用户需求是指描述用户使用产品必须要完成什么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what）。用例、用户故事、特性等都是表达用户需求的有效途径。产品需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），这些需求记录在软件需求规格说明（SoftwareRequirmentsSpecification）SRS中。产品需求包括性能指标和实现方式。面对新需求，问6个问题要解决什么问题？为谁解决这个问题？带来什么价值？如何判断和检验价值？有替代方案吗？为什么要现在做？需求池如何开发、管理需求开发需求管理需求获取需求分析需求编写规约验证需求需求基线需求变更需求跟踪如何分析需求逐层分解可回溯UserStory是重点基于Licecycle梳理US业务需求用户需求US产品需求SRSUserStory编写上海建炜信息技术有限公司PlanDoingXXX项目-ProductBacklogNo.CategoryItemPriorityEffort(Days)HowtodemoDescriptionStatusIteration1Iteration21√1.1资源上传Must8Plan√Doing√Done√Delay1.2个人空间管理Must1.31、PM梳理用户故事2、PM或PD编写用户故事3、用户故事必须确定优先级4、必须估算用户故事5、每个用户故事开发工作量不超过3天，否则就必须拆分6、US必须有验收标准7、US必须可独立交付8、US必须是有价值的产品需求规格SRS形式：可以和US文档合并SRS的主要内容功能简述：Assomebody,Dosomething,Forsomeobjective前置条件：基本流程：除了软件流程，还应该包括UI框架图（MOCKUP）可选流程：异常流程：举个栗子：手动控制云台1、US列表2、SRS描述（控制镜头拉伸与移动）1、功能简述：作为管理员可通过BS架构的导播台对摄像机云台的上下左右与拉伸操作手动控制，目的是为手动实现跟踪和切换2、前置条件：连接VISCA协议摄像机与录播主机，并登录导播平台,启动手动预览3、基本流程1)登录导播平台后进入”人工导播界面”(此处应该贴mockup界面线框图)2)选中要控制的摄像机画面3)点击一次“↑↓→←”按键能够实现镜头的上下左右移动4)持续按住“↑↓→←”按键，云台以每3秒加速5%的速度进行上下左右移动4、异常流程1）如果未选择摄像机，则提示请先选择摄像机“2）如果云台未控制成功，需反馈失败原因5、可选流程1）可提供HTTP接口，允许第三方程序发送云台控制指令2）第三方手动控制面板也可进行云台控制需求开发光说不练嘴把式选择一个你熟悉的产品场景每人5分钟完成业务需求US和产品需求SRSCaseshow需求验证What完整性可测试性易用性正确性US价值How需求评审快速原型与试用需求变更Onlychangeisneverchange!EmbracetheChange!变更请求PM影响分析PM/Test/Dev实施Dev/Test验证PM/TestPM统一记录6个问题工期影响功能影响质量影响更新PBList设计调整编码调整测试方案调整测试用例调整测试用例执行接受无情拒绝验证不通过需求跟踪When一般需求评审后（或者RDT达成一致后）就需要建立基线一旦基线（baseline）确立后发生任何变化都需要跟踪WhoPMWhat需求实现的符合度需求变更跟踪需求实现的进度跟踪更新PBList需求跟踪How开发阶段每周至少一次caseshow（关键时期每天一次）Codereview（主要Review业务逻辑正确性、覆盖面、异常等）大的需求变更（工作量超过5天）需要RDT集体讨论更新PBList,PRD文档,以及迭代计划参考资源PMBOK《软件需求最佳实践》——徐峰《启示录》---MartyCagan项目计划、进度与风险管理第二讲为何要制定计划联想：西方“慢节奏”社会出租车需要预约美国大学的课程表是准时的Why？一切都是提前计划好的计划的重要性思考：如果研发项目没有计划会怎样？建炜产品研发过程(GAP)概念阶段•制定业务计划书•下达开发任务书规划阶段•产品需求分析•产品架构设计•制定迭代计划开发阶段•产品迭代开发•持续集成•自动化测试验证阶段•产品试产验证•产品试用验证•产品完善发布阶段•产品发布•产品培训•产品推广•量产移交量产阶段•批量生产•产品维护产品研发产品规划产品维护产品研发项目需要制定哪些计划产品里程碑计划（迭代计划）开发计划产品测试计划培训计划用户验证测试计划试产计划开发计划最难制定何时制定开发计划每次迭代开始前，迭代会议中PDT小组一起制定(迭代)开发计划制定流程产品范围确认WBS拆分工时估算制定计划达成共识计划执行与控制执行跟踪修正产品范围确认制定迭代开发计划前提条件需求范围评审通过PRD评审通过设计方案评审通过快速原型已验证并评审通过产品范围确认工作任务拆分WBS迭代需求池PRD编写任务PRD评审任务设计与评审任务编码任务CR任务测试方案与用例编写任务测试用例执行任务需求任务开发任务测试任务文档开发任务迭代需求池架构设计任务•复杂任务拆分为简单任务•大任务拆分为小任务(3天)工时估算•首先评估出最可能时间、最乐观时间、最悲观时间，再按公式“（乐观时间+4*最可能时间+悲观时间）/6”计算出任务最可能的时间。•适用于任务有一些不确定性和风险性。三点法•多名专家进行评估（6-7名），结合每个专家评估出来的时间进行讨论确认，经过一至多轮的评估，最终估算最可能的时长。•适用于没有历史经验数据，第一次参与评估任务。专家估算法•需求时间：设计时间：编码时间：测试时间的比例为1：1：2：1。•评估时间顺序：编码=》US=》设计=》测试。经验值估算法制定计划关键路径的识别感谢聆听ThankYou