敏捷开发产品管理系列之四：新产品研发

plug

本文是敏捷开发产品管理系列的第一篇。（序言及设立迭代目标，产品版本规划，产品用户群规划，新产品研发，预估会议，Product Servant，Product Owner团队，产品线管理）
这里所指的新产品研发，不是指自己企业的新产品，而是特指那种在行业中初创，前途不明，尚需市场检验的新产品。敏捷开发可以在很大程度上帮助这种产品的开发过程。
新产品的第一要务策划新产品的第一要务是：谁会买这种产品？为什么？
开发新产品的第一要务则是：它与以往产品的核心差异是什么？
这个听起来不难理解，但是做起来有困难。因为一般产品开发往往是先做“最重要的功能，最基础的功能，最影响架构的功能”，这很容易在很久以后，才能看到产品的核心差异。
因此，虽然不可能完全脱离重要性、基础性、架构性的制约，但仍然应该常记：验证与市场上以往产品的核心差异是第一要务。
% a( K6 J1 X* ?4 C新产品研发如何快速体现核心差异（一般是创新性的价值观），是新产品研发的中心。
具体做法很多，下面举一个例子。
& d5 D' i2 S* R# r7 L曾经有一家游戏企业，希望能用“广种薄收”的方法来做新游戏。但是发现每个游戏上来都要做可视化、用户登录、商店、NPC、场景、帮派……这些基本功能，所以经常游戏开发开始很久了，还看不出游戏“好不好玩”这个最重要的核心。这就极大地制约了人才、资金的流动性。
后来他们决定：开发一个基本平台完成上述基本功能，任何团队拿到这个平台，直接在其上开发“核心玩法”，在规定时间点上公司领导会评审游戏的可玩性，来决定其去留。这就是一个让团队将开发重点从基础功能转移到核心玩法。
" j3 ]- h7 q. a$ N' C+ s; N+ Y& `8 n再举一个我自己的例子。
我们正在开发的产品在市面上已经有很多了，因此尽管从敏捷开发的角度看应该尽快做一个“可工作”的产品出来，但我们实际过程却相反。
' P# k8 m8 Z5 n7 Q5 [( M我们的确有“可工作”的产品，但只限于部分体现核心价值的功能点上。单单靠这些功能点，整个产品其实跑不起来；但整个产品跑得起来不，并非我们评价产品成功的要素；反而是少数不连贯的功能，体现了我们产品的价值。因此在早期的开发工作中，整个产品其实不能完整地“工作起来”，但是那几个能体现核心差异的功能，却能帮我们验证是否值得完成整个产品。
敏捷开发的帮助敏捷开发正好可以利用优先级排序、评审会、迭代交付等实践，帮助完成上述步骤。
# V1 N4 X; s5 o* x' a: z尤其是迭代交付。即使只有3个月的初创期，也不要认为时间比较短可以在前期作出完整的功能或设计。迭×××发能够保证在第3个月的判断点来临之前，自己与仲裁者能有多次沟通的机会，仍能改进产品的方向；而且在真正的时间点上，一定有可交付的功能，而不是一堆做了一半的文档。
“只有一堆文档”虽然未必导致老板直接把项目砍掉，但至少会让他很为难。不如用迭代给他一些“看上去可以，但仍有待判断”的功能，以便获取更多机会。

8 \) @7 ~1 B, e% j  h; M) d) f% A0 U

bow

开发新产品的第一要务则是：它与以往产品的核心差异是什么？ 这个听起来不难理解，但是做起来有困难。因为一般产品开发往往是先做“最重要的功能，最基础的功能，最影响架构的功能”，这很容易在很久以后，才能看到产品的核心差异。