工作中的一些小体会，都是平时突然跳到脑子里的一些片段文字，有些也是目前自己做得不够好，写出来自勉之。
一. 取舍之道
很多道理已经被古人讲完了，比如大道至简的一句话：好钢一定要用到刀刃上。
你可以说，那是因为钢不够多，如果够多，就不用这样了。这恰恰就是我们生存的环境——资源永远是有限的，时间、人、精力都是有限的。
把事情从简单想复杂——体现你的系统性，全局观，长远规划，但是要落地了就要把复杂再回归到简单，让开发、需求方很明确地知道如何开始“咬下第一口”。
要点：
1. 取舍之道，一定要建立再系统、全局之上。
2. 取舍之道，可按照用户群、功能、内容、体验多维展开，每个维度都可以取舍。
3. 舍是多样的：并不是绝对不做，而是分阶段去做，明确现在做什么，将来做什么，以及为什么这么划分。
下图是我喜欢用的取舍之道模型：
想做的事情很多，但是要结合现实（资源和能力），但是这可能还不够，还要考虑竞争者，是不是你要做的事情别人更有优势，是不是他们很容易超越你，这些因素都要考虑进去，最终得到能做且能做好的事情，目标明确。但是这取舍还不够，接下来进行时间的取舍，也即所谓的轻重缓急，什么事情是现在不做不行的，什么事情是可以放放的。
按照半年一个周期的话，会把前面几个月作为重点突破，先交付出可供试点或内测的版本，此时注重的是商业模式的清晰，定位的清晰，之后稳打基础，做一些重的事情，第三个阶段加强运营和体验优化。
最近看到另外一句话，分享给大家：think big, start small, do smart.
2. 关于抽象能力的重中之重
记得当时刚转岗做产品经理的时候，去给一个大神级的人物汇报产品方案，该神人动辄提到：抽象化，不要听太具象的，就是让我讲一些抽象的概念。
当时不理解，你们扯来扯去不就是最终要看产品原型吗？现在原型都有了，还要抽象干嘛？
在后续的工作中，即使没有人再耳提面命，自身也体悟到抽象思维的重要性。难怪有人常说：把事情想复杂了，很容易，但是把复杂的事情想简单了，是个更需要功力的活。
把事情想太简单或者太复杂，可能都不够有功力，真正的高手就是要把简单的事情先复杂化（全面、周全、系统），然后——抽丝剥茧，再把复杂回归到简单。
从简单到复杂，体现的是系统化，全面性。
从复杂到简单，则更多要进行抽象化思考。
抽象就是从表面看到本质，从片面看到整体，然后抽出那些稳定的、共同的特征。
平时我们会考虑代码的复用性，组件的复用性，同一个功能对不同场景的复用性，有了复用的能力，就能够用更少的开发去满足更多场景的同类需求问题。考虑复用性或者便捷的拓展性，是产品经理必须要考虑的。
其一，我们的产品要满足的是一个需求类别而不是具体的某个需求。从而能够从一个具体的需求，看到一类的需求，看到衍生的相关的需求，甚至再对需求进行分类，看到更高层面的需求。进而才能够系统性解决同类的需求而不是就事论事点对点解决问题。
其二，产品经理要考虑投入产出比，让最小的投入取得最大的效益，所以每次的投入都要试图解决一类问题，或者多个类的相关问题，不能够处理具体案例就了事了。
有开发背景的产品经理对比设计出身的产品经理而言，抽象能力普遍要好一些，因为开发的一些专业课已经对此进行过系统训练，比如UML,比如系统架构。
而设计出身的产品经理，原本的优势恰恰在于将抽象的思维具体化，让更多人明白到底是讲的什么，毕竟面向用户，是无法抽象化的。而恰恰是这个优势，凸显出了一个思维上的不足，那么就是抽象化能力上的略微欠缺。当然，我们可以能够更加擅长使用概念图（concept map）,以及讲故事（story talking）将思维具体表达出来。在讲故事或者图像化的时候，也是一种对具体案例进行抽象归类的提炼。
画图，也是一种提升抽象能力的好方法，这里的画图，万万不是线框图，ps视觉图。这种图反而顿时从抽象到具象了，这图一定是架构图或概念图。
前天，还和一个开发讨论某个产品的架构，我对着密密麻麻的文字说：你画个架构图出来看看吧。该同学说：有图确实会直观些，但是画图会比写这些文字多好几倍的精力。
图不是单纯为了直观，画图本身是一种理解、提炼、加工、组织的非常好的思维过程。图本身可体现：次序、轻重、层次、关系……这些多维的信息，单纯通过语言的描述，很容易避重就轻，讲到云里雾里，讲的人和听的人都不自知，其实通过图则直接了当地可表达出来这些多维信息。画图过程本身就是一个抽象思考的过程。
大道至简，只所以到最后简了，正是因为抽象。
PS: 平时多看看一些concept map 图，有助于提升抽象能力。
最后，发布这篇杂思录的时候，恰好在图书馆翻了下人民邮电出版社的教材《软件工程》，看到Grady Booch（UML语言的创始人）的一句话：抽象是一种人类处理复杂问题的基本方法。书中还有一段话专门介绍抽象概念的，我觉得这本教材写得很烂，但是对于抽象的描述比我上面写得到位，分享给大家：
“在哲学中，抽象可以理解为以缩减一个概念或是一个现象的资讯含量来将其广义化的过程，从而只保存与一些特定目的有关的资讯。比如，将一辆银色的女式自行车抽象为一辆交通工具，只保留一般交通工具的属性和行为等资讯；将抑郁抽象为一种情绪，以减少其在情绪中所含的资讯量；将其高校的计算机专业的研究生抽象为学生。”
“抽象主要是为了降低问题的复杂度，以得到问题领域中较简单的概念，好让人们能够控制过程或以宏观的角度去了解很多特定的事态。抽象还可以理解为人们认识复杂的客观世界时所使用的一种思维工具。在客观世界中，一定的事物、现象、状态或过程之间总存在着一些相似性，忽略它们之间非本质的差异，而将其相似性进行概括或集中的求同存异的思维方式也可看作是抽象。”
有时候，我们会评价一个演讲者，“太抽象了”，要记得区分“讲不清楚”和“讲抽象”的差异哦。
3. 看远一些，想远一步——做长期规划，看清现在。
有喜欢打三国杀游戏吗？如果用里面的术语说就是：
从万箭齐发到诸葛连弩（中长期）、铁索连环（系统性） 。
产品经理要向上发展，必须要做一个产品线的中长期规划。至少规划里包含两个季度，才能称之为中长期，而有时要一眼看到1～2年后产品线可能的形态。当然，也有一些大产品经理的蓝图可能告诉你这是3年规划。
规划的东西不一定会按规划落地，有可能振振有词讲一年规划的同学，在2个月后就改变了规划方向，找到了别的突破点，或者产品后来的面貌全然和规划无关。规划一定会有变数，内因外因各种不可抗力或因为执行过程中输入更多信息发现规划确实是要调整。但是，这也不能说明规划就没有意义。
中长期的规划会让人更加理解目前做的一切是为了什么。
人有一个明显区别于动物的特征就是：追寻事物背后的意义。作为团队成员，其实都会问自己：我们做的这一切有没有意义。
太片断化的执行单纯就是在做一个个项目，只有中长期规划能够体现出使命、价值观或者形而上但是又可被解释成意义的东西。开始很激动人心，中途很枯燥，但是如果有一个让人激动的前景，那么就可很大程度上抵消掉中途的乏味。
另外，藏在自己心里的规划意义也不大。产品经理的规划，不管形式上多么乏味，也需要秀出来，多多秀给团队成员，让他们理解，争取他们支持，吸取他们的看法，略略进行调整。让大家觉得这个规划是我们一起参与而绝对不是产品经理一个人意淫出来的方向。
中长期规划模型，从内容、形式、目标受众、体验四个维度都可以延伸出中长期的规划：
服务的目标客户：是否有延伸的可能性，比如首先服务于高级用户，如数据分析师，让他们有能力建设自助式报表，之后提供更丰富的容易使用的组件，让普通用户可参与。
内容和功能：首先做什么其次做什么，里面也可以再分不同的维度，比如数据产品中，就可以再分成数据价值（从做统计到做分析、监控、预测、挖掘）、业务价值（如何从支持共性和通用的需求到支持个性化的业务需求）、平台价值（基础功能的升级，如开放）
体验：单纯体验也可以一个中长期规划进行升级。
如此类推，自己可以创建一个指导进行中长期规划的模型，每次的方案可用多个维度进行组合得出一些方向性的关键词。然后再想做哪些项目，然后再有所谓的功能列表。
4. 做不忙的产品经理
刚好前面提的几点：
抽象：提升系统化能力，从错综复杂提炼出核心信息，从具体需求、抽象需求延伸出共性、稳定需求，从表面现象深入到本质。那么就能够真正抓住核心、本质以及共性的东西，避免多走弯路。
取舍：对什么该做什么不该做，什么现在该做，什么是将来要做的心中有数，
长远规划：知道接下来会做什么。
都是可以帮助产品经理变得不那么忙的方法。如果能够做到透了，那么这个产品经理不会太忙
最起码不会让心给忙没了。
产品经理的核心竞争力你以为是监工吗？是项目经理吗？是秘书吗？不是！最核心的仍然是产品规划和设计能力，然后是从概念到推动落实的能力。
所以如果把自己的精力分配给各项工作的话，理想情况我认为是应该这样的：
除此之外，我们可以通过以下一些方法减少自己的忙：
1. 工作中时常要“系统化”——时刻做好文档沉淀和流程优化。
如果一个问题频繁出现，那么就应该被沉淀下来，做到随时、人人可查阅，减少重复咨询。
如果一个环节经常出出现，那么就应该召集一个会议或讨论，用1个小时的时间充分讨论清楚，文档备份，立此为证。
2. 提升整理能力
邮件
文档
问题
至抽屉
还有：开发在辛辛苦苦地加班，作为产品经理，我不应该装作很忙的样子，在公司陪着他们吗。
从人性上讲，陪自然很好，但是不陪也不会怎么样。
对于开发而言，最重要的是信任他们评估出来的工期，然后把需求整理清楚，避免开发返工或者因为理解错误而延期。此外，调节工作氛围，把他们当成真正的伙伴而不是你的资源。做到这些，不陪着加班又怎么样？当然，你也不希望他们天天加班吧。
5. 学习
学而不思则惘，思而不学则怠。对产品经理而言，思考占据平时工作最大份额，该多吃6个核桃就多吃点。除此外，思想需要经常升级，甚至换代。
这句话来源于今天和一个小同学的沟通，小同学的学习精神太值得学习了。我们绝对不能仅仅靠经验和资历存在着，一定要学习升级进步。
最后，有一位朋友问我，离开交互设计岗位，是不是因为不喜欢设计，我说不是。相反，产品经理也在做设计，而且不仅仅是在设计界面、交互，而是在设计一种模式, 不仅仅是how it feels , 或者 how it looks , 或者how to use it. 而是how it works。 如何因为一个idea或者一句话一个反馈，或者灵光一瞬，能够从具体到抽象再到具体地实现出来，能够借助简单或者复杂的系统，协同多种资源开发、运营，让整个事情run起来。这种成就感是更为强烈的。
网友评论