人脸识别atm问世
研发团队交付能⼒弱？或许你还缺少痛点挖掘的⽅法“ 痛点，在产品思维中是⼀个频繁被提及的⾼价值关键词，能挖掘出并消除⽤户的痛点，就有可能成就⼀家独⾓兽企业，⽐如消除“最后⼀公⾥”交通不便痛点的共享单车企业，让⽤户体验到出⾏的便利；在软件研发思维中，痛点的挖掘和消除，也能成就研发交付能⼒的提升，让做研发执⾏的⽤户也能感到组织的良好成长氛围和⾃我的进步。通过多次观察不同研发团队负责⼈谈论痛点的思路和痛点挖掘结果，本⽂想对研发团队中为什么要挖掘痛点和如何挖掘痛点做出分析和总结。”
01
松潘地震
—
为什么要挖掘痛点
软件研发活动，涉及研发流程、规范、团队协作、专业技能要求等多⽅⾯的组成因素，各⽅⾯也需要持续改进才能匹配软件这样需求变化快和技能变化快这样的现状要求。⽽纵观各⽅⾯持续改进的⼿段，⼀般都是在原有基础上做加法操作，⼤动⾻架的操作⽐较少，也不好实施。这种改进⽅式，随之带来的，就是流程的臃肿、规范的多⽽杂散、协作⽅的增多、专业技能要求增⾼等问题，这些问题经常也会是调研⼀线开发⼈员的意见反馈时，他们提的较为频繁的问题。如果不去改善这些问题，那么研发组织的交付能⼒只会逐渐恶化，最终交付不顺畅、⽆法快速响应客户诉求⽽错失良机。 但所有问题并不都是痛点，痛点是问题背后的本质原因，针对研发组织⽽⾔，⽆法及时交付⾼质量软件的本质原因就是研发组织的痛点，所以问题背后的痛点挖掘，是学习型组织必须持续进⾏的⼀项改进活动。
当然，痛点挖掘再重要，也得有前序和后序动作相互作⽤，才能产⽣价值和收益。⼀般的动作步骤如下图描述，先到痛点挖掘的出发点，再采⽤合理的⽅法进⾏痛点挖掘，再针对性给出改善⽅案，进⽽对⽅案进⾏效果评估验证，最后将验证通过的⽅案举措规范化到研发活动或研发流程当中，作为固化的动作来执⾏，让痛点挖掘和改善的价值最⼤化被利⽤。
仔仔动力联盟02
—
从何处挖掘痛点
痛点的挖掘，从出发来源上讲，分为主动式和被动式。
主动式主要是研发组织当中的积极者，凭借着对未来更优⼯作⽅式和⼯作环境的期望，来持续寻求改
进。例如，研发流程相对顺畅，但交付效率期望再提升30%，这时就需要主动从交付效率维度深⼊分析，到阻碍效率提⾼的因素，“如何消除阻碍因素的影响”就成为痛点挖掘的切⼊点。
被动式主要是当前组织已经⾯临交付能⼒问题，前⾏受阻，需要直⾯问题做改进，才能让恢复组织的⽣产⼒。例如，交付给系统测试部门的软件，频繁被提严重故障单，质量表现很差，这时就需要被动的从质量交付出发，分析哪⼀类故障泄露占⽐⾼、哪⼀类功能的故障泄露占⽐⾼或哪些⼈或团队的故障泄露多，以此作为痛点挖掘的切⼊点。
对于主动式或被动式的痛点挖掘来源，挖掘⽅法上基本类似。
03
科尔曼—
灵石二中
如何去做痛点挖掘
痛点来源于问题，属于问题的本质性描述。从问题出发挖掘痛点是⾸要的，挖掘出的是否是痛点需要验证，痛点挖的是否到位也需要有准则来验证，⼀般步骤如下。
3.1 从问题表象切⼊
**问题并不能和痛点直接等同，因为有些问题可能只描述了⼀个不理想状态的表象。但痛点的挖掘，⼜是来源于问题的表象。**从问题表象做切⼊，寻问题背后的本质原因之后才有可能挖掘到痛点。⽐如所在的研发组织连续⼏个迭代都⽆法按期交付需求，这其实就是个不理想的问题表象，这个问题背后，是因为交付流程某个环节频频阻塞造成的，还是因为流程整体的不合理导致？有了这些WHY，就算是⾛到了问题本质挖掘的环节。研发活动中的问题表象⽐较多，⽐如⽆法按期交付需求、任务多却成就感低、⼯作效率低下、故障泄露多、资源浪费严重等。
包仁3.2 通过问题本质挖掘痛点
继续刚才的例⼦，所在的研发组织连续⼏个迭代都⽆法按期交付需求，分析数据后，发现是因为交付流程某个环节频频阻塞造成的；再次分析，这个环节的阻塞⼜是因为有协作⽅的介⼊，但协作⽅⼜在节奏上和资源投⼊上不能与协作的期望相匹配⽽造成的。到这⾥，已经⾛在问题本质的路上了。挖掘本质的⽅法总结如下：
（1）放眼全局，聚焦点
连续⼏个迭代⽆法按期交付需求的问题要分析，需要将整个交付流程摊开去⾯对，从整个流程的全局去分析，会发现阻塞环节是在不同协作团队的功能集成上，功能集成环节作为分析的聚焦点被关注。
（2）聚焦局部，分析本质
聚焦到功能集成环节后，做深⼊分析，发现最本质的原因是某个协作团队在⼤多时候都⽆法按期交付⾃⼰的功能，导致整个功能的集成进度受阻。
（3）扩散到关联因素，做全⾯分析
如果只关注到某个团队的参与⼒度不充分的因素上，那么可能仅仅只分析到了局部的原因，需要扩散到关联因素。关联因素，包含需求的计划制定、⼈⼒资源的投⼊、协作⽅的任务优先级等，这些也是直接影响能否按期做功能集成的重要因素。
3.3 验证痛点挖掘到位
挖掘到的是否是痛点？是痛点，但是否挖掘到位？也是执⾏过程中必须要⾯对的疑虑。继续刚才的例⼦，“连续⼏个迭代⽆法按期交付需求”问题的本质分析为“协作⽅在节奏上和资源投⼊上不能与协作的期望相匹配”，这是否就算是到了问题的本质原因并挖掘到痛点了吗？
若肯定的回答“是”，那么“如何提升协作⽅的参与⼒度”就作为痛点，来被讨论和制定改善⽅案。在讨论改善⽅案时，就会有⼈提出“为何协作⽅不愿意及时配合？”这种发散性疑问，这个疑问⾜以说明问题的本质原因还是挖的不够到位，这样就难以让讨论者的思路直接聚焦到改善⽅案上，⽽是仍然在是否
是痛点的疑问上徘徊。
若否定的回答“不是”，那么意味着问题的本质还可以分析的更加深⼊。再仔细分析，协作⽅的参与⼒度不够，是因为交付的⽬标在协作⽅那⾥的优先级并没有⾼到值得去投⼊充分的资源来保证交付不受阻，说简单点，就是交付⽅和协作⽅的⽬标和计划上未达成共识，那么痛点就变成了“如何保证交付⽅和协作⽅在⽬标和计划上达成共识”，此痛点的描述，很⾃然地就会让讨论者去直接思考如何针对达成共识做改善，从⽽，也才有可能讨论和制定出贴切的解决⽅案。
⽆论出的痛点是“协作⽅在节奏上和资源投⼊上不能与协作的期望相匹配”还是“被协作⽅和协作⽅的⽬标和计划上未达成共识”，想判断是否是痛点，可以反向的思考这两个“痛点”给研发交付带来的影响是什么？显然它们两者都能影响到需求是否能按期交付，所以它们都是痛点，只是对于改善⽅案的制定来讲，挖掘的到位程度不⼀样。
所以，是否是痛点，痛点挖掘是否到位，都应该有个验收准则才能更客观的去评估。是否是痛点，总结为⼀句话：去反向思考挖掘出的痛点是否会造成问题表象的发⽣。痛点挖掘是否到位，总结为⼀句话：挖掘出的痛点，能否让⼈看到后就能沿着习惯性思维去想改善⽅案是什么，⽽不是还停留在这是否是痛点的疑问思考上，那么，这时挖掘出的就是较为到位的痛点。
04
—
痛点的改善和效果验证
痛点挖掘有出发点，也有了体系的挖掘⽅法，只要做到位，对于研发组织的交付能⼒提升来讲，输出的痛点结果就是组织的基本改进⽬标了。有了改进⽬标，就⽅便去聚焦想法和资源进⾏改善⽅案的输出，以求达成⽬标。由于针对不同的具体问题，改善⽅案可能相差甚远，需要展开篇幅去专门讨论，此次不做简单讨论。但改善⽅案的效果验证却是相当关键的动作。
总体来讲，可从⽅案实现视⾓和⽤户视⾓两⽅⾯来验证。继续⽤本⽂的例⼦来说明，“保证被协作⽅和协作⽅在⽬标和计划上达成共识”的改善⽅案是从需求规划优先级⼀致、版本节奏匹配、开发计划和功能集成计划同步⼏个⽅⾯合⼒矫正，那么，从⽅案实现视⾓看，改善效果验证通过的完成定义，就是⽅案中设定的优先级是否⼀致的指标、版本节奏是否匹配的指标、开发计划和功能集成计划是否同步的指标表现符合预期；从⽤户视⾓看，改善效果验证通过的完成定义，就是研发的交付顺畅程度所对应的指标有所增加、交付效率对应的指标有所提升，研发组织的交付是否进⼊到⼀个顺畅且持续产⽣提效增益的发展状态。
将验证通过后的改善⽅案中的举措规范化到⽇常的研发流程或活动中是极其必要的动作，也是让挖掘出的痛点不再表现出“痛”的最彻底的⼿段，充分体现痛点挖掘的意义和价值。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议