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