wuyufa1994的博客

一、需求分析产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助，原因如下：1、产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求。优秀的产品经理是需要有技术广度的，他不一定要深入了解技术的原理，但一定要理解技术的边界。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？2、对用户原始需求的理解是很难传递的。很多时候，产品只是发了个产品文档过...

一、协作管理在产品经理的职位要求里，无一例外都会提到“沟通能力”。协作、项目管理、产品跟进、迭代安排等，很多产品经理的分内之事。不过，单纯的沟通是解决不了问题的。协作的核心在于，如何在同一个目标即“实现好的产品”下共同合作，实现共赢。在《高效能人士的七个习惯》一书中提到了“双赢思维”，描述了我们在人际交往中最重要的指导思想。作为产品经理，跟其他部门的协作在很多情况下并不存在标准的答案，问题常...

跟了解订单的生命周期就能勾画出电商购买流程、了解帖子的生命周期就能勾画出论坛的交流场景一样，从需求的生命周期就能勾画出整个产品设计到实现的流程。在相对成熟、处于发展期的团队，需求管理就是产品经理的核心工作之一。就像长途驾车既要保证方向正确、目标清晰，也要保证在驾驶中的平稳、安全不出差错。需求在不同的阶段，产品经理对这个需求要负的责任是不同的。但需求要牢牢把控在产品经理手中。产品经理对每个需求都...

一、产品经理要不要懂技术？大家通常提到的产品经理，除了常规意义上全权负责产品的产品经理之外，还有产品设计师、用户体验产品经理，以及后台产品经理、需求分析师等很多种。不同的公司，产品经理负责的事务也各不相同。从行业角度，也可以分为技术型产品的 PM、设计型产品的 PM、运营导向产品的 PM。再细一点划分，还可以分出电商产品的 PM、社交产品的PM或者搜索产品的 PM等。在某招聘网站上，产品经理的...

用户体验到底是什么概念呢？发布于2012年的ISO 9241-210标准将用户体验定义为“人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应”。这个概念当然比较严谨了，但不够直观。好的用户体验可以囊括很多产品的特性，让用户觉得满意。互联网知名的信息构架专家、Semantic Studios总裁 Peter Morville曾经提到，他认为用户体验包含7个模块，可以用蜂窝模型来展现。...

用户研究的目的是理解用户，是一系列方法的笼统概称。凡是能够协助我们理解用户并以研究得到的结论，指导我们设计产品和优化产品的方法和工具都可以算作用户研究的范畴。用户研究是个很大的课题，可能会在规模略大的公司才出现，但对产品经理来说，从做第一个版本的产品开始，其实就要开展用户研究的工作了，获取一些用户相关的数据和信息，才能做进一步需求分析和产品设计。我们在第3章里提到的找用户痛点的方法，也可以算是用...

产品经理不应只关心浮于表面的需要，而是要关心需求背后的真正诉求。阿尔伯塔大学的一门关于软件设计的课程中，用Want（需要）和Needs（需求）来区分这两者，前者是“希望在产品中看到的功能”而后者是“确定的具体问题，留待产品解决的问题”。对于很多用户表面的要求，以及形式上我们“看似”要满足的需求，很多其实都值得商榷。对待这些需求，我们最需要做的是发掘更深处它们代表的是什么、真正的问题在哪里。下面...

MVP是埃里克·莱斯所著《精益创业》中提到的概念，它的目的是验证两件事：一是产品满足了用户需求；二是产品能够创造商业价值。这恰好跟前文我们提到的，初创团队的产品经理应该探讨产品模型和商业模式对应。MVP就是验证它们的手段。许多产品都是从小做大的，而非起初就做得非常臃肿。打开微信，我们能看到它有许多功能。在图3-1中，我们可以看到微信大致的功能概览。作为已经有五年多寿命的国民级产品，微信的功能远称...

在刚开始做产品的时候，我心里想到的无非就是找到需求做功能，做完了再找新的需求做功能，以为产品经理就只是不断发现需求、不断实现功能的人。后来，遇到很多前辈，他们都会提到“核心价值”这件事，起初我很不理解：只要满足用户的需求，不就都是有价值的吗？经过了几年的成长，我终于意识到了核心价值的意义。产品经理的经典书籍《用户体验要素》里提到了产品设计的多个层级，提出了Web时代互联网产品要自下而上设计的概...

在知乎上，有一个提问是：“我有一个App创意，如何将其实现？”关注的人非常多，因为大家平时都会有很多想法，也想把这些想法付诸实践，看能否做出一款可用的互联网产品。事实上，所有的产品不仅仅是一个点子就能支撑的，还要考察具体实现的逻辑是否清晰、方案是否可行。在产品尚未成型、什么都没有时，作为产品经理要有建立在对市场和用户的理解上的雏形方案。在相对成熟的公司，也要清楚公司的产品是怎样从简单的点子和想...

当我们谈到接口的时候，通常会涉及以下几种含义，下面先简单介绍。我们经常说一个库或者模块对外提供了某某API接口。通过主动暴露的接口来通信，可以隐藏软件系统内部的工作细节。这也是我们最熟悉的第一种接口含义。第二种接口是一些语言提供的关键字，比如Java的interface。interface关键字可以产生一个完全抽象的类。这个完全抽象的类用来表示一种契约，专门负责建立类与类之间的联系。第三种接...

在面向对象的程序设计中，开放-封闭原则（OCP）是最重要的一条原则。很多时候，一个程序具有良好的设计，往往说明它是符合开放-封闭原则的。开放-封闭原则最早由Eiffel语言的设计者Bertrand Meyer在其著作Object-Oriented Software Construction 中提出。它的定义如下：软件实体（类、模块、函数）等应该是可以扩展的，但是不可修改。扩展window.o...

就一个类而言，应该仅有一个引起它变化的原因。在JavaScript中，需要用到类的场景并不太多，单一职责原则更多地是被运用在对象或者方法级别上，因此本节我们的讨论大多基于对象和方法。单一职责原则（SRP）的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就具有两个职责。每个职责都是变化的一个轴线，如果一个方法承担了过多的职责，那么在需求的变迁过程中，需要改写这个方法...

模式和重构之间有着一种与生俱来的关系。从某种角度来看，设计模式的目的就是为许多重构行为提供目标。在实际的项目开发中，除了使用设计模式进行重构之外，还有一些常见而容易忽略的细节，这些细节也是帮助我们达到重构目标的重要手段。这里挑选一些进行介绍，其中有一部分思想来自Martin Fowler的名著《重构：改善既有代码的设计》，虽然该书是使用Java语言写成的，但这些重构的技巧，有很大一部分可以为Ja...

适配器模式的作用是解决两个软件实体间的接口不兼容的问题。使用适配器模式之后，原本由于接口不兼容而不能工作的两个软件实体可以一起工作。适配器的别名是包装器（wrapper），这是一个相对简单的模式。在程序开发中有许多这样的场景：当我们试图调用模块或者对象的某个接口时，却发现这个接口的格式并不符合目前的需求。这时候有两种解决办法，第一种是修改原来的接口实现，但如果原来的模块很复杂，或者我们拿到的模块...

状态模式是一种非同寻常的优秀模式，它也许是解决某些需求场景的最好方法。虽然状态模式并不是一种简单到一目了然的模式（它往往还会带来代码量的增加），但你一旦明白了状态模式的精髓，以后一定会感谢它带给你的无与伦比的好处。状态模式的关键是区分事物内部的状态，事物内部状态的改变往往会带来事物的行为改变。初识状态模式我们来想象这样一个场景：有一个电灯，电灯上面只有一个开关。当电灯开着的时候，此时按下开关...

在程序开发中，许多时候都并不希望某个类天生就非常庞大，一次性包含许多职责。那么我们就可以使用装饰者模式。装饰者模式可以动态地给某个对象添加一些额外的职责，而不会影响从这个类中派生的其他对象。在传统的面向对象语言中，给对象添加功能常常使用继承的方式，但是继承的方式并不灵活，还会带来许多问题：一方面会导致超类和子类之间存在强耦合性，当超类改变时，子类也会随之改变；另一方面，继承这种功能复用方式通常被...

在我们生活的世界中，每个人每个物体之间都会产生一些错综复杂的联系。在应用程序里也是一样，程序由大大小小的单一对象组成，所有这些对象都按照某种关系和规则来通信。平时我们大概能记住10个朋友的电话、30家餐馆的位置。在程序里，也许一个对象会和其他10个对象打交道，所以它会保持10个对象的引用。当程序的规模增大，对象会越来越多，它们之间的关系也越来越复杂，难免会形成网状的交叉引用。当我们改变或删除其中...

职责链模式的定义是：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。职责链模式的名字非常形象，一系列可能会处理请求的对象被连接成一条链，请求在这些对象之间依次传递，直到遇到一个可以处理它的对象，我们把这些对象称为链中的节点，如图13-1所示。现实中的职责链模式职责链模式的例子在现实中并不难找到，...

享元（flyweight）模式是一种用于性能优化的模式，“fly”在这里是苍蝇的意思，意为蝇量级。享元模式的核心是运用共享技术来有效支持大量细粒度的对象。如果系统中因为创建了大量类似的对象而导致内存占用过高，享元模式就非常有用了。在JavaScript中，浏览器特别是移动端的浏览器分配的内存并不算多，如何节省内存就成了一件非常有意义的事情。享元模式的概念初听起来并不太好理解，所以在深入讲解之前...