记得***次做项目经理，中途接手一个银行项目，开始内心是拒绝的，因为这事：
人多，团队***高峰30多号人；事杂，需要和行内十几个系统进行对接；除此之外，少不了做项目永远的痛：工期紧。在进组的前***，想到这一大摊子事，不知道从哪里下手，心虚的很。
这时，有位老领导跟我说：
“不管对外的计划怎么包装，项目经理必须有一张对内的计划，能够随时并真实的反映出项目现状。”
就是这句话，不仅让我顺利地完成项目管理生涯的漂亮“起步”，也为后续形成自己的管理方法论打下基础，受用***今。
没错，我是“计划”的信徒。
但是说起“计划”，自然联想起另外一话：“计划赶不上变化”，因为项目出现延期情况是大概率事件，没办法，谁叫影响项目进度的因素太多，要么无法预测，要么不受控制。
既然计划和现实之间存在鸿沟，为什么还要花时间和精力去“做计划”？
“计划”是看穿泡沫的镜子制定一份完整计划，需要考虑的事情大致包括：
目标是什么？实现目标需要做哪些事情?每件事情需要哪些资源?每个任务，关键阶段的完成时间，产出物？风险点和应对方案？看，这本身就是以“上帝视角”全局推演的过程，事情能不能成，整个计划确定下来，心里也就清楚了一半。
回到开篇说的故事，之所以能顺利“起步”，并不是靠面上的一纸计划，而是在制定计划的过程中，无形对项目现状完成了一次深度梳理，计划做的越细，对细节了解就越全。一来，可以帮你找到项目中重要且紧急的事情；二来，也不***于让你的管理，变成团队眼中的“添乱子”。
“计划”是出征前的仪式想要顺利完成一个项目，抛开外部风险不看，能否在内部形成合力，***关重要。
对上，要符合公司战略方向，得到领导认可，只有这样，在需要领导助攻的时候，才会显得有理有据，不那么唐突。对下，要让团队每一个人对目标形成共识，尤其要搞清楚各自手中的任务对整个项目进度影响的程度，避免陷入大家不急，只有你急的窘境。而做计划，就是这么一个统一上上下下的意志和决心，明确战略方向，盘清资源家底的过程；是摇旗出征前，必不可少的仪式。
“计划”是事故后的黑匣子即便项目出现延期，或者彻底挂掉，从团队的角度出发，要善于复盘，***少死也要死的明白。
“计划”的好处，会让理想和现实之间的偏差，具象的显示在你面前，就像淘宝买家秀和卖家秀一样，会帮你更直观的修正对事物原有判断。
每一次的修正，目的是降低下一次的踩坑几率，毕竟大部分的问题还是人为导致，你对计划的控制力变强，就是对项目的控制力变强。
***后做了这么多年的项目，个人感觉，要做出一份靠谱的计划很累，过程里有太多的不确定，等着你去确定；这种走出舒适区的恐慌感，没有人会喜欢。
关键是，这种恐慌感不会随着经验的累积而消失，每一次都像***次，这是计划***令人讨厌的地方。
但是，如果一个项目，按照既定计划走出你想要的模样，其中产生成就感，经历一次就会上瘾，这也是“计划”***诱惑人的地方。
满足用户需求，是作为产品经理的基础能力，这一点在任何一个团队都是值得肯定的，我们通过满足用户的需求来实现自我价值，从而为团队，为企业创造价值，可现实总是比较复杂的，许多生活中的事情无法用 0 和 1 来正确的诠释，编码世界比真实生活要简单的多，不是 0 就是 1 。
盲目的满足用户需求，会让我们迷失自己的本心，我所面对的是数以百万乃***千万计的庞大用户群体，不要说每个用户的需求了，即便是每个用户说一个字，就已经不是人力所能及的事情了。
这也是从根本上决定了产品无法满足所有用户的需求，不可能存在十全十美的产品。
这句话大家并不陌生，换一个角度来理解，这个现象实际上是在告诉我们，不是所有的用户需求，我们都要满足。同时，这也是在为我们的产品生涯，敲响警钟。
我仍然记得一次一次满足了客户需求，满足用户需求后，看到数据的变化，看到用户的反馈时的心情，无比兴奋，这是来自于客户或者用户的高度认同，是一种自我价值的实现，
可实际上，这种情况非常的正常，谈不上自我价值的实现，也谈不上高度认同，多数时，只是获赠者对赠与者的一种感谢。仅此而已。
换言之，用户需要一个苹果，你将苹果给了用户，他便会向你表达谢意，并夸奖你，而实际上，你可能是卖鱼的！
这样的夸奖，就如同被发了一张“好人卡”，除了自我安慰，没有其他意义了。
作为产品经理来讲， 我们会接触到形形色色的用户，对应的是五花八门的需求，***容易犯下的错误，便是去询问用户想要什么，然后再将用户想要的做出来，获得一张又一张的“好人卡”，糟糕的是，我们乐此不疲。
有选择的去响应用户的需求，忌讳盲从，忌讳依赖用户需求，是作为新一代产品经理需要警惕的一句话，因为我们许多人都曾经或者正在这句话里，被虐的醉生梦死
有选择的去响应用户需求市场上存在许多“杂货铺”，不算太大的门面，陈列着五花八门的商品，有厨房用品，也有卧室用品，还有学习文具以及更加琐碎的周边产品，人们总是会将商品种类的数量与销量进行简单的挂钩。
记忆当中，许多产品都在忙于堆砌功能，这就像杂货铺心理一样，我们简单的将用户喜好与功能的数量进行了对接，这是因为我们极度的缺乏安全感，也缺少自信。
我们开了一家餐厅，准备了许多食材，作为餐厅的舵手，我们想要吸引更多的食客，***好是远近闻名，当大家想吃饭时，都会***时间来到我们餐厅。
喜欢吃粤菜的，我们有专业的粤菜师傅，喜欢吃川菜的，我们也有专业的川菜大厨，不仅仅是八大菜系，西餐，印度等比较流行的外国菜，我们也会提供，还有小吃，甜点等等。
对于舵手而言，舍弃任何一个菜系都是无法理解的，他总是这样告诉身边的人“如果我们不做粤菜，那喜欢粤菜的食客，就要跑到别人家的餐厅了”
贪图功能的数量，实际上是我们自身的不自信以及对产品缺少安全感导致的，因为我们就像这位餐厅的舵手一样，担心“少了某些功能，用户就会被其他产品抢走”。
不难想象，当餐厅正式营业时，他的厨房 一定比就餐区还要大很多，每天所需要付出的成本也会高许多，对于产品也是一样的。
和餐厅有所差异的，当产品出现堆砌功能时会更加的凄惨，原因在与不论餐厅支持多少种菜系，我们总能知道餐厅是吃饭的，可产品一旦功能过载以后，没有人知道，这款产品到底是做什么用的。
选择方法：如何选择合适的用户需求去响应，我有三个建议，但在我们继续下去之前，我需要慎重的提醒你，这三个建议既不是***的，也不是***的，不同的环境下，我们会有不同的方法来对待，即使是我个人在遇到不同问题时，也会有不同的判断方法，这些方法总共的数量，远远超过五种，甚***说同一个问题就会有两种以上的方法来处理，并且他们的处理结果还是不一样的。
你可以将这五种方法视为对自己的启发，在实际的工作种去求证，去培养意识，***终仍然需要建立自己独特的判断方法，并且不断的丰富他。
***条：是否符合产品本身的定位有人渴了，有人饿了，也有人无聊了，但饿了的人不会去电影院吃饭，渴了的人不会去饭店喝水，无聊的人也不会去喝水打发时间。
用户的需求是五花八门的，由于懒惰***上的人性使然，我们总希望在自己遇到困难时，能有外力来帮助我们，这需要我坚定的认识到产品本身的定位。
支付宝做社交，微信做电商，京东做相机，这样的混搭让人们眼前一亮，很容易意识到功能和产品的定位出现了偏差，所以我们还是很少见到这样的案例的，因为这些情况足够显眼，足够突出，实际上只是因为问题太大了，而不是因为我们可以忽略这个问题了，即功能与产品定位不符合。
我们将这些跨域的环节缩小一点，自拍相机增加了拼图功能，图片社交增加了语音留言，资讯产品增加了微博功能，这样的组合是否已经让我们产生了疑惑？
看上去 拼图功能和自拍相机都是属于图片处理类的，而且自拍的用户也确实存在拼图的诉求，这确实是存在用户需求的，回到我的命题中，只要我们思考一下，这款产品本身的定位是拍照工具，还是图片处理，拼图工具，就能感觉到一丝不和谐。
事情本身没有***的，正如支付宝确确实实做了社交，尽管微信还没有做电商，而有一些自拍相机也确实存在拼图功能，而某些图片社交软件也确确实实增加了语音留言，这种情况，我们都会称之为“转型” 或者“尝试转型”
当产品发展到一定规模时，为了让价值继续增加，又或者为了商业模式等一系列问题，或多或少都会经历转型风波，有的活的更好，有的没有变化，也有许多转着转着就死了。
因此，当出现功能与产品本身的定位存在混淆时，这表示产品本身的定位也在渐渐的发生改变，反过来理解，如果没有做好转型的想法，那切忌功能与产品本身的定位不符合。
（未完待续）
即学即用你觉得支付宝做社交失败的***大原因是什么？ 闲聊，闹闹磕，请畅所欲言。（回答之前，不如再看看 “是否符合产品本身定位”这一段）
这就是我所理解的产品架构三部曲。
先梳理一下大部分PM画功能流程的常见错误，方便理解其边界。
混入业务维度特别容易把业务模块也画到功能流程图里面。
区分你的功能流程图里面有木有业务模块并不难。***的判断标准是该图中的每个节点都应该是这个产品中真实存在的功能名称，否则应该是混入了其他东西。
真正的难点在于如何将业务流程映射成合理的功能流程，以及功能流程如何映射成恰当的业务流程。
混入页面维度其次容易将页面写到功能流程图里面。比如某页面只是某个功能的子集，你非要把它写到功能流程图里面，是不合适的。
比如微信里面，发送照片给好友是一个功能，但是涉及到的页面“照片”、“选择相册”、“某一相册详情”以及操作“选中某一照片”，他们都不是功能，完全不应该显示在功能流程图里面。
当然某些功能的命名，有可能和页面是一样的。
混入操作维度每个功能可能包含很多操作，比如微信中发送照片给好友，包含了”点击相册”，”滚动照片列表”，”选择照片并发送”等操作。需要正确区分操作不是功能。
功能流程是什么讲了一些常见的错误画法之后，再次定义一下功能流程的概念。
功能流程是指产品的所有功能以及相互间关系。
功能间关系注意功能是相互独立的，但是通过合理组合，可形成新功能。不太建议用一级功能二级功能，父功能子功能的叫法。
包含哪些元素功能，使用矩形表示。
功能流向，使用有线箭头表示。
条件，使用有线箭头上的文字表示。
已定义流程，使用组合矩形表示。不是必须的，如果整个产品的功能太复杂，可能需要。
详见我整理的功能流程图资料，点击查看。
功能命名要么是名词，比如购物车。可加定语，比如我的红包。
要么是动宾短语，比如确认订单。
要么是通用叫法、比如我的。
可以参考同行业的TOP5竞品。
如果功能简单，产品层面的1个功能尽量对应着Axure的1个Page。如果很复杂，请拆分到多个页面。
详见产品需求文档需要遵循的命名规则。
功能定位功能是逻辑意义上的概念，用户是感知到该产品具备哪些功能。一个功能可能是跨越多个页面，也可能存在于某页面里。而页面是物理意义上的概念，用户可以在产品里面看到包含哪些页面。
另外功能本身是相互独立的。但是通过合理组合，可形成新功能。不太建议用一级功能和二级功能，父功能和子功能的说法。
如何画功能流程图 罗列所有功能按照PM设定的用户使用产品流程，来画出每个节点的功能。从***打开APP开始算起，进入首页会有多种走向，均需分别画出来。
请注意不要随意把页面名称画进来，除非你确定含有一个同名的功能。
比如上图乍一看，好像这几个都是功能，画得好像并没有错。点击对应的原型地址，方便理解下文。
可事实上，首页只是页面的叫法，而不是功能。另外它***少包含了发布邀约，查看邀约列表，频道列表三个功能。
用有向箭头关联使用有向箭头将功能之间联系起来。注意箭头方向代表用户的使用步骤。
如果你是使用Axure，请不要傻乎乎的使用默认模式拖一根线到2个功能矩形框上，而是切换到连接线模式然后鼠标移动到矩形框连接红点并关联到另外一个。
很多功能是有前置条件的，请使用有向箭头并辅以文字表示。
所谓的条件就是前后端需要判断的逻辑。常见的条件有3种逻辑结构。
上面说的几个常见错误，***好检查一下有没有犯。
得到功能流程图根据上面的步骤，我大概画了一下微信客户端主要的功能流程图。
如果你们的产品比较复杂的话，可能需要根据用户角色、前后端不同来分别画出对应的功能流程图。
比如微信的功能流程图，***少有用户使用微信，用户使用小程序，自媒体使用公众号，***开发公众号，***开发小程序等很多个。
简单来说，你先得清楚你们的业务需要多少个产品来支持，产品间的关系是什么，每种产品需要多少种用户角色，相互间的关系，有多少个端。