/ Conversation

沟通是需求管理最重要的部分

WhatTheCustomerWanted 需求如同迷雾一般抓不住,捉摸不定,内在往往被表象所蒙蔽。可需求又总是不断的在人与人之间流动传递,这个过程十分容易造成所有人的对需求的理解是不一致的。这会产生大量的常见的浪费:来回的返工、修Bug;PO和团队前期调研不足,对需求没有充分认识,在迭代中频繁的变更需求导致一个功能反反复复的做等等。 那么到底需求的本质是什么?并不是我们常在需求文档中看到的各种解决方案。而恰恰是这些客户或者PM表达出来的解决方案掩盖了用户的真实需要(need)。这些need可能是某个用户的问题,可能是用户想要达成的目标等。Need如同宝藏一般,需要我们去挖掘。因为大多数时候,大家表达自己的需要的时候,往往通过具体的解决方案来描述的。直接把解决方案拿来当做需求往往会导致用户的问题迟迟不能被真正解决,还可能会带来负面效果。其实用户有问题来找我们解决,是因为我们是这方面的专家,可我们却没有针对用户的问题设计解决方案,反而使用用户告诉的解决方案。这本身就不符合逻辑。 Requirement_Hotel 还有很多时候,用户自己都不一定清楚自己真正的需要。我们需要通过访谈,观察等形式和用户一起来挖掘他们的真实需要。 这还只是从用户那得到真实的需求,后面还有产品经理,业务分析师,开发人员,测试人员等等。想要最终真正的解决这个需求,需要所有人对需求有正确一致的理解。如果还只是单向点对点的传递,那会需要大量来来回回的反复传递,还不一定有好的效果。那为什么不让这些坐在一起讨论呢?有时候,可能没有办法把用户拉到办公室来,那么能不能有一个用户代表呢,他预先做了大量的挖掘工作,最了解用户的真实需求。然后他和其它所有角色一起来分析需求并设计解决方案(包括业务和技术上的)。我们需要多角度的分析和意见:PM和BA确保我们做的事情是有价值的,Dev和QA提供技术可行性的意见,Dev和UX提供可用性方面的意见。 dfv-chart   那么如何确保大家的理解都是一致的呢?有个大家都比较熟悉的工具——用户故事。Ron Jefferies对用户故事提出了3C:Card(卡片) ,Conversation(沟通),Confirmation(确认)。 首先卡片帮助我们可以“抓住”需求,拿着这个卡片,大家就知道是说哪个需求。卡片还有一个特点:小。有限的空间意味着你不能在上面写太多的字。我还会让团队用粗的彩笔写,不仅为了看着醒目,也是为了写更少的字。这就是为了让团队能够拿着这张卡片去沟通,并且确保卡片上描述的主体是需求。 需求要进入准备开发还需要许多的细节,这些细节都包含在后面的2个C中。

沟通这个C是最重要的,贯穿整个用户故事的生命周期。从一开始写用户故事的时候,可以由PO描述需求,阐明问题,开发团队来写用户故事,PO可以通过Review大家写的用户故事来确认团队是否理解了需求。同样,在对用户故事进行估算时,也是很好的帮助团队强化对需求的一致的理解。估算的方式有很多种,但无论哪种都需要大家把各自对故事的理解(工作量的估算需要建立在一定认识上,而不是拍脑袋)暴露出来,大家看到不同的想法,再重新融合。与此类似的还有对用户故事的排序(order),拆分等等。

确认这个C是帮助团队确认每个用户故事的需求边界,也就是每个用户故事的验收条件。大家需要一致认可当这个验收条件得到满足的时候,就可以认为这个需求被满足了。这个过程依然还是强化沟通的过程,确保大家在某个需求上的目标和理解是一致的。因此,验收条件往往需要非常具体的实例,这样就不会带来二义性。具体内容可以参考我参与翻译的《实例化需求》。

由此可以看出沟通对于需求的重要性。需求不是一个冗长的需求文档所能解决的,需要大家不断的沟通。我做过一个小小的调查,发现团队里几乎没有人会从头到尾看完需求文档,对文档中信息的接收程度只有不到30%。因此写文档之前不妨先想想写文档的目的是什么,现在写的文档是否是达到目的最好方式。

 

Jackson Zhang

Jackson Zhang

Odd-e敏捷教练,主要涉及组织,团队,产品,技术,工程实践等,曾为多家知名企业提供教练与培训服务。译有《用户故事与敏捷方法》,《.NET单元测试的艺术》和《实例化需求说明》。擅长工程实践(如测试驱动开发,单元测试,重构,持续集成等),产品探索(Impact Mapping,Pretotyping,Lean Startup等)与团队协作。zbcjackson AT gmail.com

Read More