【IT168 分析评论】

    需求相关

    产品早期多为老板驱动，PD驱动，特别是市场不成熟的时候，我将之不成熟的比作“主动进攻”；后期会逐步转变为用户驱动、销售驱动、服务驱动，更像“被动防守”。(在主动进攻的时候要加快第一次的迭代速度，以获取最快速的用户反馈，减少风险)

    管理需求，特别是日常的小需求，包括收集、状态跟踪，两个团队用excel，两个团队用mantis+excel，一个团队用QC，都ok。用mantis的团队说，mantis适合收集，跟踪，方便记录存档与反馈，但管理还是由各个产品的PD自己做，多用excel。大家都会按需要开产品会，召集产品相关方共同确定接下来一段时间做哪些需求。(关键是需求的粒度和条目化，后续对条目化需求的跟踪，Excel是很好的方式，但是Excel又无法替代需求文档。)

    需求的优先级谁定，安全的做法是谁获益谁负责（俗称老板拍脑袋），但PD是专家，应提供专家意见给老板，当然高层授权的专家负责制也许更好。(优先级的结构化决策方法，可以从多个维度对优先级进度评估)

    部分团队的需求文档直接在wiki上写作，管理。(很好的方式，直接实现需求到设计实现文档的结构化和条目化，类似现在推Doors等工具都是为了实现需求和设计开发过程的结构化，Word文档一开始并没有，而是后续结构化工具导出的。)

    部分团队需求评审与UC评审分开，需求评审偏商业，UC评审偏技术。(立项前需要还在用户需求和DEMO抛弃原型阶段。立项后的需求重点是UC开发，需求已经转化为产品需求和软件需求。)