权衡的艺术-产品经理如何把产品做成功？

转自我的blog：www.gstarwd.com

基于网文二次创造

     那其实就是一门权衡的艺术 ~并且我觉得产品经理 和架构师的处境类似~产品经理 需要和架构师多沟通才行~(当然这么说的话就针对比较“大”的产品了~对，本文不针对“小”产品)

     产品经理如何把产品做成功呢？这个是大多数产品经理每时每刻在思考的问题。
“做正确的事”和“把事情做正确”这两个要素对于一位优秀的产品经理而言，因该是双向的，“做正确的事”更多时候是把握产品的方向和蓝图；在一些产品体系健全的公司，这项工 作主要是由公司的产品线经理 或者产品总监去完成。而在现实的中国IT企业中，这项工作往往是由产品经理去完成。
     那对于产品经理 而言“做正确的事”，究竟应该怎么做呢？
     如果想把一个产品做正确，就必须把握清楚这个产品的需求 ，这个需求主要从N 个方面进行一个描述：
客户的需求 对 于一些有甲方的企业来说，客户需求是放在第一位的，因为他们很清楚一件事，如果客户不满意，那还有何用户可言，客户对你的产品不肯定、产品不能满足客户的 需求；那这 个产品问世的可能性不大。所以说客户的需求尤其重要。所以产品经理在做产品蓝图规划时，必须要弄清楚客户空间想要什么，并想清楚客户的这个要求，如何在我 的这个产品里 做体现，更优秀的产品会考虑的更长远一些，及如何把客户的需求与产品完美结合。如果你的产品方向或思路得到客户的认可，对于后台的产品推广方面，将会得到 客户的更多关 注和支持。
     公司的内部需求公司的内部产品需求，要从N个方面去阐述。
     公司高层对产品的期望 产品经理 必 须要弄清楚，公司的高层对你所规划的产品，持有怎么样的期许，在公司的战略规划里，你的产品的方向和里程碑式的目标又是怎么？你所设计的产品如何给公司带 来 最大化的利益？你所设计的产品是否与高层的期望是一致的？这些疑问都是产品经理要去解决的，通过与高层的不断沟通，必须要弄清楚高层对于产品的深层次需求 是什么，当你 的产品规划案得到公司高层的认同时，你的产品工作就又上了一层台阶，在产品的天平上又增加了一块生要的法码。
公司的运营部门的需求有些公司的产品建设完成后，要交由公司的运营部门的，运营部门要去完成产品上市后的一系列运营 事务。因为你的产品做出来后，是要给运营部门来运营的，你的产品设计是否合理，有一项重要指标就是运营人员 在使用了你设计的产品之后，相关的转化率有没有提高？有没有有效的降低了运营的成本。产品经理必须要弄清楚运营部门需要解决什么样的问题？要实现什么样的目标？你所设计的产品有没有有效的解决运营部门的问题，就显得尤为重要。
公司技术支撑部门 的需求有些人不禁会想这个产品做出来后是给运营部门去运营的，技术支撑部门的需求真的需要考虑吗？这里的答案是肯定的。技术支撑部门对于产品的设计更多时候有自己的想法，有 时是降低产品的开发成本，实现重用性。
     用户需求说到这儿，估计很多UED团队的朋友要跳出来，可能会大声疾呼：“这哥们到底懂不懂啥叫以用户为中心的产品设 计啊？”当然“以用户为中心的产品设计”，是产品人员所追求的一个 目标。对于一些没有甲方的客户，UED团队 当然是设计以用户为中心的设计。
     我曾经遇到过一些情况，在充分以用户为中心的产品设计后，用户在体验上确实得到了一些改善，用户是用得爽了，但是运营部门却无法完成他的指标。也没有 达到高层的满意。 这种情况时常发生，所以对于产品经理而言，“做正确的事”这个方向上是相当有挑战的，有经验的产品经理可以很好的把这些需求点进行梳理和统一规划，很清晰 的完成操作。
当产品经理把产品牵涉相关的需求都考虑在内的话？那么成功的方向就离我们不远了？
话虽这么说~但是这样做很难~先来看一张图：

涉众利益相关人的影响

    上图其实是架构师的处境(图片来自 SoftWare Architecture in Practice 一书)~非常生动展示了架构师因为不同涉众利益人提出的各种要求而崩溃了~
     The Architecture Business Cycle 对一个软件持续发展的影响就体现在了图中~一个软件一个产品一种软件架构不仅涉及上面所提及客户，高管，技术人员的影响~~并且在产品的后期 持续性的受到运营人员 维护人员 市场推广人员的 影响~我所谓的影响就是需求的抛出~

     在公司里产品经理会时不时的对技术人员提出某个需求~而产品经理的上头会有一堆人对他提出需求~~这么看来技术人员是最辛苦也是最核心的人员了~呵 呵~高级技术人员可以抑或说架构师，他们又凌驾在一般程序员之上~对产品进行整体蓝图规划。然后产品（软件或者说软件的架构）在完成开发之后~再运营维护 阶段必然对运营人员~维护人员等产生influence~然后有返回来影响到这个产品~~

这个就是所谓的 The Architecture Business Cycle！简称ABC

The Architecture Business Cycle！

    最后我们回到本文的主题：产品经理如何把产品做成功？

    根据ABC原理 一个成功的产品是具备 可维护性 易用性 可测试性 等重要质量属性的！所以不能在产品的初期只是更具业务需求来规划产品。不然后期维护可能会很吃力~就是说需要在产品规划的初期对客户的需求进行考虑之外 还需要对后期维护可能会发生的问题进行科学的搜寻规划~（其实这些学科在国外都已经很发达~SEI早就有相关的Golden Practice-CMM CMMI 等 后面的文章我会介绍~）

     并且在自己的公司环境下~在权衡所有环节的情况下着重突出最需要的产品设计~这个绝对值一门艺术 ~而不是科学了~因为这个没有可重复性实践的可能~每个公司都不一样的环境就会导致不同的环境~即使客户需求一样~不同的工作环境就有不一样的总体需求！就会有不一样的最终产品~

我引用一句话：If it is true that, given the same technical requirements for a system, two different architects in different organizations will produce different architectures, how can we determine if either one of them is the right one?

    这句话就是我上面所说的：即使客户需求一样~不同的工作环境就有不一样的总体需求！就会有不一样的最终产品~

所以产品经理要想把产品做成功不仅需要充分理解显性需求，还需要充分挖掘自己所处的环境所带来的隐性需求！并且做出在不同隐性需求之间的权衡~很清楚~这已经不是科学~就是艺术~

把产品做成功是一门权衡的艺术！

 

本文参考：

http://www.xiuze.net

http://etutorials.org/Programming/Software+architecture+in+practice,+second+edition/