ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著

ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著

ID:8218871

大小:1.56 MB

页数:26页

时间:2018-03-10

ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著_第1页
ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著_第2页
ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著_第3页
ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著_第4页
ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著_第5页
资源描述:

《ArchSummit北京2015-《寻找多团队研发管理的最大公约数》-曾著》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、寻找多团队管理的最大公约数需求管理pizza模型曾著@胡莱游戏自我介绍•曾著互爱科技工程技术副总裁,入行16年,历经银行、证券、保险、智能硬件、互联网金融、游戏等多个行业,2010年初加入互爱科技,《胡莱三国》主程•互爱科技(胡莱游戏),《胡莱旅馆》、《胡莱三国》、《斩仙》、《新神曲》、《伏魔道》、《火柴人联盟》等问题的背景:一个爆款•《胡莱三国》2011年,登陆腾讯开放平台第7款游戏–SLG+社交玩法–超过4亿注册用户–长生命周期,到现在还贡献收入–收入创纪录问题的背景:扩张中的研发管理•游戏工作

2、室(20人)——>游戏制作、发行、运营的综合性公司(1000人)•业务扩张,产品类型多样化–页游,手游,移动社交,游戏发行平台等•引入了多个新团队–团队风格,技术架构,研发流程各方面都有较大差别–管理范围变大怎么办?•团队风格不统一,如何推行优秀的工程实践?•管理范围扩大,风险失控–去了解细节,疲于奔命,或者–跨过细节决策,挠不到痒处思路:找到研发管理的最大公约数,切入•共性的困难是需求管理•需求管理的几个目标–方向及时纠错,快速失败–管理优先级–减少等待–减少理解偏差–协助估算–方便进度跟踪需求管

3、理的Pizza模型产品愿景用户画像核心价值模块用户故事低保真模型系统交互概念模型领域模型设计与验布局位置,视觉证细节前后端协议设计,配色风格测试数据实例第一层:产品愿景,宪法•最根本的假设和战略意图–例,微信八条:用户价值第一、鼓励有价值服务、消除中介、去中心化、消除地理限制、生态系统、动态系统、社交流量•每一层都要查是否“违宪”–例,素食与海鲜•如第一层发生改变,即为放弃原产品,但快速失败是一种局部成功第二层:用户核心价值•用户画像–用户形象化–代入感,设身处地考虑用户体验例如“阿土伯”,“杜拉拉

4、”•用户核心价值例如P2P金融对于投资者:资产增值•产品设计原则和常识例如“用户体验要素”第三层:用户故事、模块•用户故事–Role,What,Why–强调用户价值–作为受管理的任务单元,驱动研发•模块(Epic)–相关用户故事的集合•高层的利益相关者,可更多关注前三层,因为受控任务单元的进度跟踪会暴露风险第四层:用户故事的概要设计**低保真模型系统交互设计概念模型•减少需求传递失真•用最小成本传递需求,活文档•凸显最容易反复出错的部分•独立验证单元,尽量竖切,快速验证第五层:细化设计和验证标准领域

5、模型布局位置,视觉前后端协议设计,配色风格测试数据实例•不同角色的关注重点–产品,开发,测试关注A–产品,UE,UI,原画等关注BA部分容易反复出错,•细节的特点是验证重点–A:逻辑的,隐藏的–B:直觉的,主观的独立验证单元系统交互设计低保真原型1,今日已签到数据实例2,今日未签到数据实例分离了交互设计和数据实例,简化文档工作进一步还可以借助工具自动化系统交互设计数据实例数据实例1,今日已签到2,今日未签到结合研发流程,以Scrum为例•调研阶段–产品愿景、用户核心价值、产品设计原则•每一个Spri

6、nt迭代前–用户故事–优先级•需求讲解会议–低保真原型、概念、系统交互描述•估算会议–一些典型的测试数据实例作为验收标准来估算•Scrum会议–标注完成的需求必须通过数据实例验证•产品演示会议–整体回归,review上层约束结合研发流程,以Scrum为例测试数据实例领域模型前后端协议测试数据实例案例1,•现象:产品的某个模块一个方向持续做了很长时间,上线后,该模块数据改善了,但产品整体数据变差了•原因:与产品主线冲突,(愿景,用户偏好,入口层次等等)•解决:每细化一层,必须验证上层约束发现冲突及时调

7、整案例2,•现象:某个迭代2周时间,预计最后3天统一调试,结果发现工程师声称完成的任务中有很多bug,改正这些bug花了整整一周半的时间.•原因:需求缺乏验收标准,工程师估算时,以写完程序或调试完主干业务为"完成"标准.•解决:–用户故事为工作单元,必须用数据实例验证后才算完成,–能提前发现:需求理解偏差或工作量估算偏差.案例3,•现象:某个产品,测试工程师用excel撰写了详尽的测试用例,但开发途中,需求一再改变,测试用例的修改工作量大,有的跟不上需求的变更速度•原因:文档维护成本过高•解决:分离

8、数据实例与交互设计描述文档–数据实例更容易变化和增加–去除重复描述总结:Pizza模型的特点•每个环节盯紧用户价值•用户故事作为受控工作单元,驱动研发流程,发现风险•支持和鼓励竖切验证–独立验证单元•测试实例•系统交互设计描述•低保真原型Mockup–不同特点的细节分开验证•逻辑A与直觉B最大公约数只是一个开始,接下来:•兼容并蓄•暴露风险和问题•推行最佳实践•提取可复用组件、服务、流程参考资料:与用户体验要素对比参考资料•《实例化需求:团队如何交付正确的软件》byG

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。