微信号:gh_d690f895de78

介绍:信运部内部员工devops交流平台,大家一起玩转Devops~

知识点归纳(1)

2016-07-13 14:18 业开部

本文将对上周四(2016.07.07)举行的交流会做一个知识点的归纳和梳理,主要包括:
1、对于业务方强制要求的需求应该如何处理
2、对于需求人员工作现状的建议
3、IBM Design Thinking Intro
1、对于业务方强制要求的需求应该如何处理
Q: 有时候,需求人员在日常工作会遇到业务人员不理解系统上的实施难度,强制要求上线某些功能或者业务,面对这种情况有什么好的解决方案吗?
A:理想 情况,需求的提出通常是经过商业、技术、用户三个层次的衡量,但目前需求提出时更多可能只是从商业要求的角度出发,而由于技术的原因,可能是系统设计缺陷等,会出现实施上的困难,这类需求即使按时上线了,质量也是难以保证。首先如果业务人员有it背景,沟通起来会比较方便,这个问题也比较好解决。如果没有it背景,可以采取可视化等一些辅助的手段帮助其理解实施上的困难,以及可能产生的风险点(比如上线缺陷情况、延期等)。我们还可以通过“5why”来沟通,确定其业务价值,是否一定需要上线,是否有其它替代方案能产生差不多的效果,其投入产出比是否值得。

2、对于需求人员工作现状的一点建议
现在大多数需求人员承担的是部分po加pm的职责,不仅需要了解需求,还需要做一些事务性的管理工作。同时,对上线进度、上线质量背负kpi的指标,普遍工作负荷都比较大。有时候赶着上线一些工单,但质量不理想,需要反复的进行修复,造成成本、人力的浪费可能还高于工单实施成功的价值,反而得不偿失。我们可以将一些问题和情况先可视化出来,度量其影响程度和改进成本,再来讨论改进方式。比如说建立需求后评估机制就是一个很好的做法,虽然我们无法直接影响业务方,但我们可以通过在一些维度对需求工单的实施效果进行评估,并及时将问题反馈回去,用数据说话。再比如说我们是否可以将需求实施的价值流可视化出来,(如各环节占用时间),找出价值链上的短板,针对性的做改进。再来就是精益思维里的“限制在制品”、“Less is more”,实施scrum时,对每个迭代中团队的工作容量是有记录的,结合上线质量,团队和我们需求人员都可以逐步了解和清楚团队的工作质量和工作容量(数量)的关系,减少因为数量太多负荷太大而影响质量的情况。

IBM Design Thinking Intro
Design Thinking 有很多方法体系,IBM融入具体实践,将其总结成一套具体的方法论,他能帮助设计出真正符合用户需求的产品,当然这种思维理念也可以运用在其它场景。
因为时间问题,敏捷教练向大家简要介绍了设计思维了部分内容——共情图、现状图、可行性/重要度。
简要来说,共情图(Empathy Map)类似于用户画像,终端用户对产品才是最有发言权的,所以只有真正了解用户,站在用户的角度,思考她们的痛点、痒点、兴奋点,想他们想到的,甚至挖掘他们的隐藏需求,才能设计出“好产品”。共情图主要从四个方面入手:用户想些什么,用户做些什么,用户会说些什么,用户的感受是什么。
现状图(As-is Scenario),基于共情图的基础上,列出用户在使用产品时的步骤,以及相应的想法、做法和感受,他关注的是步骤中用户的体验,引发团队找出现状中可以改进的点,同时讨论针对改进点的big idea/crazy idea,可以采取便签贴的方法来记录。
可行性/重要度:将现状图中的big idea 便签贴按照容易度/影响价值贴在响应的地方。根据投入产出比的原则来选择先实现和解决的内容/功能。
上述对产品的设计可以进一步延伸至release map和road map,结合时间,来对产品规划高阶的发布和路径图。接下来,就可以按照scrum的方法,进入具体的迭代了。这样,也和之前的scrum方法论和知识点很好的衔接串联起来了。
本次交流会也有给大家推荐一本书:《管理3.0:培养和提升敏捷领导力》适合敏捷开发人员、敏捷从业者、教练和项目经理阅读,对团队领导和开发经理尤其有用。《管理3.0》以科学为基础,结合复杂性系统理论,通过轻松诙谐的写作风格和诸多解释与隐喻,将敏捷管理的要义娓娓道来。
快,关注这个公众号,一起 (涨) (姿) (势)



 
一起玩转Devops 更多文章 知识点归纳(2) 敏捷破冰之旅(六) 知识点归纳(3) 敏捷破冰之旅(七) 知识点归纳(4)
猜您喜欢 美女的 Swift 体操 - 高阶函数 今天这组产品经理的图貌似火翻天了吧~ 如何成为一名Java冠军程序员? 性能测试:农夫与骡子的故事 Google:Andriod系统前景不容乐观