自我们分析-产品的原则和方向

    开发人员经常不理解产品需求。“××功能有用吗？”

    开发人员经常在争论某个功能的具体设置。“××要显示吗？还是不显示吧。还是显示吧。”

    开发人员经常怀疑自己所做产品的价值。“这东西做出来有人买吗？”

    开发人员经常羡慕人家做的东西。“哇，××做的真强～”

    设计人员经常对设计方案左右不定。“这样比较好，那样也有道理。”

    。。。。。。

    上面这些情况仅仅针对我所在的环境，其他公司我不清楚。这些问题看起来似乎很好笑，开发者似乎都在为产品经理着想，似乎都在为设计师着想，设计师似乎搞不清自己到底该设计什么样的东西出来。自己都不认可自己的产品和设计，怎么能做出让用户认可的产品和设计呢？

    “怎样能做出成功的产品呢？”我常绕着这个问题胡思乱想。我们没有完整的团队，只是一个开发组，我也没做过××经理，“没有调查，就没有发言权”，所以从个人理解来说说。

    先说说我觉得一个产品应该怎么去做。

    第一，定出产品的原则和方向。由谁去定？产品经理嘛。定义一个产品的信息来源是啥？从市场， 从他对产品所在行业的理解，从他对用户的理解，最好还有他对产品创新的理解。看千鸟的《产品经理的责任》中有句话，“合格的产品经理才是产品合格的根源”，十分赞同。

    第二，产品的原则和方向出来了，那就开工吧，交给项目组。项目经理要做的，是依据产品的原则和方向去实施，去全力的带动整个项目团队来做好产品。这里边包括N多东西，要考虑时间、流程、成本、人力、质量等等一堆要考虑的东西。

    第三，下面就是项目组成员。简单的分就是设计师、工程师。设计又分，体验设计、交互设计、视觉设计；工程又分，前端开发、后台开发、测试。如果涉及到硬件，还要有硬件工程师和工业设计，这个我暂时还不了解。项目组成员在项目经理的协调下，各司其职，融合的协作来做出产品。

    这么多职能划分，至少差不多这么多人。人不是机器，不会机械的去按照任务做事，去写代码，去测试，去设计。每个人对产品都有自己的想法。大多数人都有一种心理，要证明自己的观点是正确的，希望自己的观点能够影响别人或者某样事情。也许自己并没有察觉，这是一种潜意识。这样的心理带来的是辩论，在形式上可能就是开会。就如《Don't make me think》里说的，web设计团队讨论可用性是在浪费时间，项目组成员讨论产品的方向也是在浪费时间。“没有调查，就没有发言权”，这句话用在这里挺恰当，因为每个人都是从自己的个体角度去谈产品的方向。

    大家有想法，很好。一时间，大家似乎都有市场眼光，都有为用户考虑的心。但想法要有个约束，有个方向。没有方向，那就成了发散式的个人观点。这个方向就是产品的原则和方向。如果项目组成员对产品的原则和方向不清楚，不认可，不理解，那问题就大了，带来的是项目进行过程中的混乱，最终产品可能失败。

    产品的原则和方向是产品经理来敲定，敲定就结束了吗？不，原则和方向的传达更重要。我们不能只得到一句“以家庭和SOHO用户为目标的××”和一张功能列表，我们要知道为什么是这个原则和方向，为什么是这些功能。不仅仅是告诉我们“要怎样”，还要告诉我们“为什么这样”。让所有成员认可、理解产品的方向，打消大家的疑虑。从项目经理到项目组成员，都要对产品有一致的认识。这样带来的好处有这么些：

    对产品，在传达产品原则和方向的过程中，团队成员一样会从技术的角度、从设计的角度提出自己的观点。产品经理也许出身技术、设计或者市场，他们的观点也是有不完善的。这样，产品经理与工程师、设计师的观点相互碰撞、融合，可能会弥补这种缺陷，对产品的完善是很有帮助的。

    对个人，“噢～，我是要做这么一个产品，它会带来××样的价值，会××的影响使用者的工作和生活，我的辛苦和努力是有意义的”。

    对团队，心往一处想，劲往一处使，把上面那句话里的“我”改为“我们”，“噢～，我们要做这么一个产品”。这对于团队的融洽协作十分的好。

    对设计师，在解释什么是这个原则和方向，为什么是这些功能的时候，将给设计师提供十分重要的信息，这些都是重要的设计依据。

    “合格的产品经理才是产品合格的根源”，产品原则和方向的准确传达是产品顺利开发的前提要素。

    PS：想起上上次UCD书友会的时候，我说出我们团队的困惑，振之分析出我们的问题出在交流和沟通上，当时一下子清晰了很多，现在越想越是这个问题。我们貌似没有产品经理，好像项目经理就是在做产品经理的事，问题是，一年也只有一次和项目经理短暂的面对面会议交谈，因为他在台湾。项目的实质进程管理都是由开发组组长在管。这是一个大问题，下次再探讨。