文/马丁·卡根（Marty Cagan）
在优秀的公司里你会发现，尽管每个产品特点不一样，场景不一样，但它们都有非常重要的相似点。程序员只有在一个优秀的团队中，才能迅速成长，才能开发出一流的产品。
那么，对于程序员来说，什么样的产品团队才是好团队呢？科技产品领域公认的思想领袖，硅谷产品集团创始人马丁·卡根提炼了如下洞见：产品发现是产品管理、用户体验设计以及工程实现的紧密合作。在产品发现中,有经验的团队先处理各种风险, 然后再开始编写产品软件代码。产品发现的目的是快速区分哪些是好点子, 哪些是坏点子,其输出是一个经过验证的功能清单。1. 用户会为我们的产品买单吗? (或用户会选择使用我们的产品吗?)
此时，优秀的产品团队有个重要的小秘密：程序员常常是最好的创新来源，他们在产品发现阶段就被邀请参与进来。但现实中，很多程序员仅仅被用来写代码。
优秀的产品团队是在产品发现的过程中,而不是之后,验证创意的可行性。如果程序员在开发产品的最后阶段才了解产品创意,那么注定会失败。在决定打造产品之前,需要确保产品的可行性。这不仅节省了大量的时间,还能够尽早获得程序员的反馈,有助于完善解决方案,对于共同学习也是至关重要的。程序员常常告诉产品经理,不用担心产品创意的可行性, 因为他们之前可能构建过很多类似的东西。然而,有几种情况,程序员可能会认为存在重大的可行性风险，比如：算法、性能、使用团队以前未使用过的技术或第三方组件或服务等。这样情况下，有经验的团队会熟练使用可行性原型技术，让一个或多个程序员创建可行性原型。程序员通常用代码创建可行性原型(与大多数由产品设计人员使用专用工具创建的原型不同)。一个可行性原型离可商业交付的产品还有很长的路要走，它的目的只是收集数据来表明性能是否可以接受, 通常没有用户界面、错误处理和任何典型的产品化工作。根据我的经验, 建立一个可行性原型通常只需要一两天的时间。如果公司正在探索一种重大的新技术, 例如利用机器学习的新方法,那么可行性原型很可能需要更长的时间。可行性原型所需时间通常由程序员来估计,但是团队是否会花费这个时间取决于产品经理判断是否值得这么做。我看到过很多团队在没有充分考虑可行性风险的情况下进行交付，结果严重低估构建和交付某件东西所需的工作量。有时,为了解决在产品发现中的重大风险,需要收集一些实际的使用数据。
但是在花费时间和金钱构建一个实际可扩展和可交付的产品之前,需要在发现过程中收集好这些数据。这就是实时数据原型的目的。实时数据原型是一个非常有限的工具。它不具备一个产品通常需要的东西,例如完整的使用案例集、自动测试、完整的分析工具等。实时数据原型比最终产品小得多, 并且在质量、性能方面也大大降低。它需要运行足够好,以便为一些非常特定的用例来收集数据。这就是实时数据原型。当创建一个实时数据原型时,程序员并不会处理所有的用例。它们不涉及国际化和本土化工作,不解决性能或可扩展性问题,也不创建自动化测试,它们只包括正在测试的特殊用例。实时数据原型只是产品的一小部分，占最终交付产品工作5% -10%,却可以提供很大的价值。
首先,这是代码,必须由程序员创建实时数据原型,而不是设计人员。其次,这不是一个业务上可以装运的产品,它还没有准备充分,不能用它去跑业务。如果实时数据测试进行得很顺利,产品经理决定向前推进并生产,要让程序员花费必要的时间去完成必要的交付工作。绝对不允许一个产品经理对程序员说“这就可以了”。如今,有非常好的技术用来创建一个实时数据原型,可以在几天到一周的时间内创建出公司所需要的东西。一旦创建出一个原型,就可以基于它进行快速迭代。当谈论验证技术可行性时,程序员实际上在试图回答这几个相关的问题:我们知道怎样构建产品么?
我们的团队是否有技术来构建产品?
我们有足够的时间来构建产品么?
我们是否需要改动任何架构来构建产品?
我们手头有构建产品所需的所有组件么?
我们了解构建产品所涉及的依赖关系么?
产品的性能可以接受么?
它可以扩展到我们需要的规模么?
我们是否有测试和运行所需要的基础架构?
我们负担得起发布的成本么?
程序员对于在产品发现中审核的大多数创意都会快速思考这些问题, 然后简单地说“没问题”。这是因为大部分工作不是全新的,程序员之前通常多次构建过相似的东西。但是,肯定有一些创意不是这种情况,程序员对其中一些或许多问题可能会很难回答。面对这种情况，普通的产品团队常常是抛给程序员们一堆创意——要求他们给出某种形式的评估, 无论按时间、故事点或任何其他单元——这几乎肯定会失败。要么就是临时委任程序员,但他没有时间进行调查和思考,很可能会给出一个保守的答案, 一般来说是让产品经理放弃。然而, 优秀的产品团队是这么做的：
- 让程序员一直跟着团队和客户一起验证这些创意(使用原型),了解了问题的所在,以及人们对这些创意的感受。
- 给程序员的问题不是“你能做到吗?”而是让程序员探索并回答这个问题:“做这件事的最好方法是什么? 需要花多长时间?”
程序员有时会反馈说,需要创建一个可行性原型来回答一个或多个问题。如果值得在这个创意上投入必要的时间,就鼓励程序员继续。我遇到了许多产品经理,他们讨厌程序员说他们需要额外的时间来研究任何产品的创意。对于产品经理来说,如果发生这种情况,意味着风险太大且太耗时。首先,许多好的产品创意都建立在解决目前可能出现的问题的方法上,这意味着需要新技术和时间来研究和学习这项技术。 其次,我发现当程序员有额外的一两天用于研究时,通常不仅给出了技术可行性问题的答案, 而且还可能有更好的解决方法。再次,通常这些项目对团队很有激励作用,因为为他们提供了学习和出彩的机会。优秀的产品团队会不遗余力打造具有凝聚力的团队，甚至在团队工位上，都会尽量做“共地安排”。“共地”的字面意思就是团队成员坐在一起。这听起来有点老派,尤其是在远程协作工具的效率越来越高的今天。但是顶级公司已经认识到了团队坐在一起的重要性。如果你曾经是一个共地产品团队中的一员,你可能已经明白我的意思了：当团队成员坐在一起,共进午餐,彼此之间建立个人关系,这时会产生一种神奇的力量。在其他条件相同的情况下,工位安排在一起的团队胜过工位分散的团队,事实就是这样。优秀的团队擅长很多技术, 可以快速尝试产品创意, 以确定哪些创意真正值得构 建。糟糕的团队在会议上形成优先路线图。
优秀的团队认为产品、设计以及工程同样重要,他们会在功能、用户体验以及底层技术之间相互协作支持。糟糕的团队各自为战, 并要求其他人以文件和会议的形式来获取他们的服务。
优秀的团队能够确保他们的程序员每天都有时间在产品发现过程中尝试原型, 这样他们就可以为如何使产品变得更好提供想法。糟糕的团队在项目最后冲刺阶段向程序员展示原型并进行评估。
更多精彩内容，见马丁·卡根（Marty Cagan）著《启示录：如何创造用户喜爱的产品（第二版）》。该书得到eBay前首席技术官、Nara Logic首席执行官、前小米产品总监、腾讯企点产品总监等国内外专家的大力推荐，被认为管理者、设计师、程序员、测试都应该认真阅读。
在本文下方留言，发表您在学习或者工作过程中的经验感想，机会总是靠自己去争取来的！小编将对留言进行精选，被精选的留言才会在留言区显示并获得相应的楼层（由于微信留言功能限制，最多只能显示100条）。
踩楼送书活动获奖须知：
1、活动结束时踩中指定楼层的精选留言将获得《启示录：如何创造用户喜爱的产品（第二版）》一本，共5名中奖者
2、活动结束我们会在本公众号公布中奖楼层的解压密码，并在3个工作日内收集到获奖用户信息后发出（收到奖品的小伙伴欢迎来留言区晒晒。）
3、获奖楼层下载地址（文件解压密码2019年9月5日公布）
百度云链接:
https://pan.baidu.com/s/1RmowZU9MwtLS6FGy2K29VA
提取码: 4692
活动时间：即日起至2019年9月5日下午4点整