关于互联网产品管理与产品设计

关于互联网产品管理和产品设计,曾一度有些迷茫。虽然一直沉淫于产品设计和用户体验,但确实也做了很多产品管理的相关工作,并且这部分“沟通”的时间所占自己工作的比重也在逐步加大。而除了互联网产品设计外,产品管理更是涉及到了软件/互联网企业经营的方方面面:

继续阅读

PRD中写用例的注意事项

产品需求文档(Product Requirement Document,PRD)在 WEB/软件项目中的作用不言而喻,一份好的 PRD  能够使整个项目事半功倍,因此花在 PRD 上的时间成本通常也是非常可观的。我见过几个内部需求项目,PRD 的 word 文档竟然也有几十M之巨,产品需求人员在其中所耗费得精力可见一斑。

chinapm 中汤圆将 PRD 的核心概括为

该文档中,侧重的是对产品产品功能和性能(即“产品需求”)的说明,相对于MRD中的同样内容,要更加详细,并进行量化。

而 PRD 中这个“详细”和“量化”究竟到什么程度,是产品管理者经常遇到的问题。一方面,如果 PRD 中的需求描述或用例说明没有具体到具体细节操作,一旦开发人员理解有误或不完整,则会对出现不断的变更或返工(通常,开发人员喜欢闷头开发);另一方面,如果将 PRD 内容描述得过分细致,则又会出现很高的成本,何况百密一疏的情况也是非常多见的。如何解决这个问题呢?

编写有效用例》一书中提到了描述事件流程的基本方法,不论具体的用例是由需求人员做,还是技术人员做,都是需要了解的。对于用例中的 include 部分一定要细致入微,而 refine 部分则可以分清优先级考虑。

include,表示你要在一个用例当中包含另一个用例,并且被包含的用例是必须的,如果缺少被包含用例,则主用例就不能完成。比方,在用户管理场景中,要删除一个用户,你必须先查询到该用户,然后再点击删除。那么查询用户用例就是删除用户用例的一个include用例。
refine,是指对一个用例更精细化的描述。精化过程不会改变原来用例要包含的内容,只是更加细致。比方,取钱是一个用例,在描述用例场景时,你会用核对帐号,效验密码等活动来描述取钱的场景。在概念分析时,你可以把核对帐号,效验密码等定义为用例来描述取钱的过程,这时核对帐号,效验密码这些用例就是取钱的一个精化。它们实际上描述的仍然是取钱这个过程,但是取钱在概念阶段被精化成了核对帐号,效验密码等粒度更小的用例,这此用例仍然需要描述用例场景,例如核对帐号的过程、效验密码的过程等。
这些精化出来的用例向上要能够满足取钱用例场景的需要,向下则要更进一步能接近系统分析所需要的粒度。
同样的道理,如果需要,核对帐号,效验密码等用例在系统分析阶段还可以再次精化。但是它们虽然改变了名字,所描述的内容也从业务描述精化到了系统交互,但描述的仍然是取钱这一个业务。

当然,最重要得依旧是团队合作。在项目运行中,可能发生任何事情,但只要大家做好沟通,没有什么问题是不能被解决的。coffeewoo 中有篇关于这方面的解答非常经典,我就不班门弄斧了。临近春节,快递都放假了,不然也想尽快拜读一下他的大作《大象–Thinking in UML》。

需求变更-要效率还是要规矩?

需求变更在项目管理中是经常遇到的问题,特别是当项目进展到尾声时,一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微,在开发阶段滴水不漏,在流程管理上规规矩矩,但无奈的是,我们的客户总是希望拿到更完美的产品。于是乎,变更就成了结项后的潮水,一波一波,无休无止。不是你的产品坏,是这个世道变化快……

如何对需求变更做科学的规划和控制?在做好需求变更管理的前提下,分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时,应该如何处理呢?特别是一些在需求中非常重要,但从技术上很好实现的需求变更时,是否还要走正规的需求变更流程?要效率还是要规矩,就成了许多产品经理心头的疑问。

首先,需要确定:是否真的需要走需求变更流程?灵活点说,需求是变了,但走不走这个流程是另一码事。如果项目几乎结项了,这时的需求变更就像百米赛跑后,裁判说这个跑道不标准,少跑了一米要重新跑一样;一鼓作气后,项目团队都疲惫不堪时,再次击鼓的效果可想而知。其实针对这时需求的变化,特别是技术上很好处理的问题,直接在结项后作为升级内容即可;毕竟版本得改动可小可大,小的版本变更从流程上讲要比需求变更简单的多;

其次,还有一个偏方,是我最近经历的项目变更得解决方案,即将这个需求分解放在其他相关项目中完成。在项目日程已经排满,并且项目间有一定相关性时,这不失为一种好办法。如果项目是迭代设计的,那么采用这种办法再合适不过了;

最后,当非变更不可时,如果没有针对不同变更得不同流程得话,唯一要做得就是做好前后沟通了。在有正规流程时,走正规流程是必须的,也只有这样,项目才能真正可以控制。如果对流程不满,除非能够很快吧流程修改或完善了,否则一步一步做吧。所谓得追求效率而抛弃规矩,是对项目不负责任的原则性问题。

需求变更就像误差,可以控制,但又无可避免;但是因为前期工作没有到位而引起了需求变更,就太不应该了,错误是不应该出现的。出现需求变更时,先不忙着救火,而是冷静下来先考虑问题产生得原因,比做救火员要有意义的多。后面会详细讨论这个问题。