Conversation

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

需求如同迷雾一般抓不住,捉摸不定,内在往往被表象所蒙蔽。可需求又总是不断的在人与人之间流动传递,这个过程十分容易造成所有人的对需求的理解是不一致的。这会产生大量的常见的浪费:来回的返工、修Bug;PO和团队前期调研不足,对需求没有充分认识,在迭代中频繁的变更需求导致一个功能反反复复的做等等。 那么到底需求的本质是什么?并不是我们常在需求文档中看到的各种解决方案。而恰恰是这些客户或者PM表达出来的解决方案掩盖了用户的真实需要(need)。这些need可能是某个用户的问题,可能是用户想要达成的目标等。Need如同宝藏一般,需要我们去挖掘。因为大多数时候,大家表达自己的需要的时候,往往通过具体的解决方案来描述的。直接把解决方案拿来当做需求往往会导致用户的问题迟迟不能被真正解决,还可能会带来负面效果。其实用户有问题来找我们解决,是因为我们是这方面的专家,可我们却没有针对用户的问题设计解决方案,反而使用用户告诉的解决方案。这本身就不符合逻辑。 还有很多时候,用户自己都不一定清楚自己真正的需要。我们需要通过访谈,观察等形式和用户一起来挖掘他们的真实需要。

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(二)

上次说到在我们改变翻译方式后的一个月,我们的burndown chart上的线变成水平的线,离理想的进度线越来越远,到底出了什么问题呢? 来看看我们的电子白板Excel吧 从第3章到第9章,我们确实翻译完了,也做了两次review,但是我们没有基于这些review来做修改,这并不是真正的做完了。因为需要交付时,我们并不能直接这样交付,还是得做最后的修改的。于是,紧接着的一个星期,我们就完成这7章的扫尾工作。我们终于又朝着理想线逼近啦! 但是我们依然还落后一些进度,该怎么办呢?其实仔细想想,整个翻译团队并没有发挥最大的产出。当两个翻译在翻译章节的时候,reviewer是在等待翻译好的章节,此时他们是没有产出的,直到有可审核的章节时,才有产出。如何才能利用这段时间来提高产出呢?很简单,让reviewer也做翻译。同时每个章节还是要遵守之前的约定,一个人翻译,要有另两个人来做审核。

Agile

用敏捷的方式翻译敏捷经典《User Stories Applied》(一)

数年前Mike Cohn写了这本User Stories Applied: For Agile Software Development,而我从2007年才真正开始接触敏捷,没想到2009年我有机会能够参与翻译这本有关用户故事的经典著作,我感到十分的荣幸。 这次翻译我们一共四个人参与,我和石永超(Stone)主要负责翻译,滕振宇(Daniel)和李国彪(Bill)主要负责审核,大家都是兼职来做这次翻译的。多人翻译首先考虑的是两个问题:要有个Central repository,大家可以能在上面更新或拿到最新的版本;还要有公共的标记,谁要翻译哪一章就做一个标记,避免翻译重复。既然需要一个公共的Repository,上面放的都是Word文档,我们马上就想到了Google Doc。接下来是标记问题,