一个月前，我从上一家公司离职，入职有妖气，转型成为一名产品经理。关于上一份工作的事情，我会在另外一篇博文中详细说明。但总的来说，我对这次转型是满意的，是朝着自己喜爱工作迈出的第一步。

产品经理在中国的发展非常迅猛，业界已经有「阿猫阿狗都能来当产品经理」的说法了，黑产品经理成为了一种新的时尚，喷产品经理成为了许多人茶余饭后的消遣，所以我对自己的职业目标是「成为一个受人尊敬的产品经理」，为此给自己提的要求是说人话、做人事，不做白日梦。当然，成为一个优秀的产品经理并不容易，有许多新知识要学习。

产品经理不仅要有世界观，还要有方法论，找到正确的做事方法是对工作的影响至关重要，不仅要有趁手的工具，还要有良好的习惯。

工欲善其事必先利其器

入职的时候公司提供了一台台式机电脑，i5 六系处理器，8G 内存，1T 的硬盘，配置非常好，还有一台 27 吋显示器，常用的软件包括 Chrome、Axure、Office、RTX 等都已经预装好了，不过由于习惯问题，我在玩了一会公司提供的电脑之后，还是选择把显示器接到自己的电脑上。要花额外的时间习惯不同电脑的使用方式，包括界面风格、快捷键等，不如直接使用自己的电脑。

产品经理方法论有一个基本流程，从想法（idea）的产生和搜集，到想法的整理和记录，再到原型的制作和需求文档的产生，都需要不同工具的支持。在我的具体工作中，如果有新的想法，在讨论的过程中会使用 XMind 脑图工具记录下来，当然记录得很乱，缺乏分类条理和逻辑；随后使用 OmniOutliner 大纲工具整理最初记录的想法，同时对想法进行标记和注解，以便后期审阅时的理解；而流程图则是对复杂逻辑的梳理，既便于自己审阅，也便于设计和技术对于需求的理解，流程图的制作我选用的是 OmniGraffle；到制作原型图时，我们团队习惯于使用 Axure，原型工具何其多，选择适合自己和团队的工具才是至关重要的；而对于需求文档，不管使用什么工具撰写，都会导出一份 PDF 存档。

Mac 上的脑图应用，说得最多的似乎是 MindNode，而且相对其他脑图来说，售价也不是很昂贵（￥128）。XMind 在去年曾经搞过一次促销活动，仅需 1 元即可获得 XMind Plus 的永久使用权，因此 XMind 成了我的脑图工具，但不得不说，Plus 的功能仍然有限，但是 Pro 版的费用又太昂贵，并且 XMind 的资源占用率非常高，所以基本上，过了初期的 Idea 搜集期，XMind 就不会再在工作流程中出现了。不过非常凑巧的是，我们团队一直以来都使用 XMind，而且利用率很高，各类梳理工作都会依赖 XMind 完成。

大纲（Outline）是我非常推崇的一种记录和整理的方式，从脑图到大纲，可以很快速地整理内容的逻辑顺序，并且对每一条内容进行注解和说明。使用 OmniOutliner 对整个大纲进行标记，可以很快速地导出各种类型的文档格式，便于分享和传阅。OmniOutliner 的标记和分享功能非常强大，简单地说，OmniOutliner 能把大纲做得非常美观和漂亮，并且支持导出各种文档格式，甚至拿 OmniOutliner 当作唯一的写作工具都丝毫不为过。不过在实际的工作流程中，许多产品经理喜欢把想法搜集与整理合并为一步，并在脑图中体现，但这样的问题在于，如果导出的是图片格式的脑图，在分享时，其他人不能方便地编辑和修改。

如何最快速和直观地描述产品逻辑？面试的时候，多数面试官会考察产品经理的流程图绘制能力和水平，因为流程图就如同导航一样，对技术的工作起到指导性作用，跟着流程图走，一步一个脚印，总能走到终点。语言中难以描述的条件、判断和循环，都能在流程图中方便地表现出来。流程图的只做不挑工具（当然，前面提到的大纲也不挑工具，纯文本一样可以写好大纲），甚至手绘都是搞笑快速的方式，多数产品经理直接在原型工具中绘制流程图，没有任何问题。我在对比了不同的工具后，选择了 OmniGraffle，原因仅仅是 OmniGraffle 的一手智能对齐，以及对 Visio 格式的支持，包括导入和导出。如果想要一款轻量级的流程图工具，我推荐 Gliffy，一款 Chrome App，简单粗暴，好用不打折。

虽然在成为产品经理之前，我对各类原型工具都略有了解，不过在第一次使用 Axure 时，还是有些不适应，原因在于我最初是以一个画图工具（类似 PhotoShop）的习惯去使用 Axure，不过在使用了之后，认为 Axure 的核心在于交互而并非画图，这从 Axure 的工具栏中也能看出来，提供大量成型的基础控件，而没有让你「从零开始创作」的制图工具。不过在原型工具的使用方式上，我发现不同的产品经理有着不同的使用习惯，比如有些产品经理追求高保真高还原度的原型图，原型图与最终效果保持高度一致，包括页面的尺寸、颜色和交互都精益求精，甚至自己承担了设计的职责；而有些产品经理则是利用基本的图形进行组合，力求把需求讲明白，并给予设计师最多的话语权。而我属于二者中间，仅对产品关键部分做高保真原型，并最大限度地刻画细节，而其余部分则以简单的图示表示，既要确保自己对产品关键部分的控制权，又要让设计师有可发挥和想象的空间。

撰写需求文档是产品经理最重要的一项工作，可谓成也需求文档败也需求文档，为什么这么说呢？我认为原型是让设计和技术直观地感受产品形态，而需求文档则是让设计和技术精准地认识产品细节，你的产品到底是什么样子，都由需求文档里的一个个文字决定的。最后产品出了什么问题，都得对照着需求文档来一一校验。需求文档就像是产品的个人档案，产品是什么、为什么、怎么样，都体现在需求文档里。万一开发和产品打起架来，你没有需求文档，或者需求文档里写得不清楚，死无对证，那基本就没得玩了，不仅工作进度受影响，个人能力还会遭到质疑。

写需求文档对工具是真的没有要求，但是如果想要把需求文档写得好，写得漂亮，建议还是选用排版能力较强的工具。许多产品经理推崇使用 Markdown 写需求文档，我当时就表态：「你让我用 Markdown 写需求文档，我先一巴掌呼死你再说」，Markdown 用来写写博客还行，用来写需求文档，排版能力的短板造成的影响就是必须花费更多的时间来解决各种描述问题。一个典型的例子就是交叉引用，在 Markdown 中无法很好地实现；另一个例子是版本控制和多人协作功能的缺失。Microsoft Word 迭代到现在，它的功能完全对得起售价。

习惯成自然

良好的习惯是高效工作的最强有力的保证，职业习惯不是一句空话，产品经理的习惯包括语言习惯、画图习惯、文档习惯和沟通习惯。保持良好习惯的含义在于——能让别人听得懂你说的话，能让别人看得懂你画的图，能让别人读得懂你的文档，以及最重要的是，能让别人能尊重你，而不是在背后骂你煞笔。一个非常重要的事实是，有越来越多的产品经理正背负着「煞笔」的骂名，而且名实相副，丝毫不过分。比如许多人，包括我自己非常讨厌的一句话：「你先做着看看」。

优秀的语言习惯的含义在于让别人知道你在说什么，也就是「说人话」。几个简单的原则是，不用「大概」、「可能」、「也许」、「尽量」等不准确的词语，一个行业潜规则是，你跟我说「大概」，我就默认你没说过这句话；你跟我说「尽量」，我就默认你做不到或不做；你跟我说可能，我就默认是不可能（「可能」带有不确定性，而「不可能」却是确定的）。不说废话，一句话能说玩的事就不要拆成两句来说，少用各类语气助词和修辞方式，用准确的形容词。保持严肃和客观，不要在不适宜的场合恶意卖萌。

画图习惯对于产品经理来说也许不像设计师那么严格，但仍然不能忽视画图的习惯，原型图的好坏会直接影响设计和技术的工作效率。画图以准确和清晰为基本前提，颜色交错的地方要做好区分，注意图像清晰度，主次分明。更细节的包括，元素的对齐，控件的一致性，色彩的运用，都是需要注意的地方。

文档习惯我认为是产品经理最需要重视的一个个人习惯，但实际上重视的文档习惯的人并不多，文档习惯包括写作习惯、命名习惯和存档习惯。写作习惯指的是为了让你的文档可读性更高，描述更准确而养成的习惯——例如，我会制作自己的 Word 文档模板，模板的内容包括页眉页脚，各级标题的格式，字体，段落，目录，行间距等；另外，我建议每一份文档都在首页增加修订记录表格，记录每次修改的版本号、时间、内容等信息。其他的写作习惯还包括中文与英文和数字之间的间隔，标点符号的使用等。

命名习惯和存档习惯是最不受人重视的两个习惯，文件的归档离不开命名，良好的命名习惯能带来优秀的视觉效果和检索能力。文件命名方式有很多种，因人而异，但基本的原则是应该包括你和你的团队认为重要的信息，例如时间，姓名，版本号等信息。另外，给程序员的文件，最好不要包含空格，毕竟空格是电脑的大敌。而存档习惯则是对于文档的合理归类和存档，可以以项目为基础，每个项目建立文件夹，根据不同类型的文件在进行二次归类。另外，利用好标签功能，按照另一个维度对文件进行整理，便于以后的索引和查找。例如，每个项目里都会包含项目原型和需求文档，而对项目原型和需求文档进行标签，则可以快速索引所有同类文件。

沟通应该是每个人都应该掌握的基本技能，但可惜掌握这项技能的人并不多，不会沟通的人，你和他说三句话都嫌多。不懂得说重点，废话多，爱打断都是非常不好的习惯。良好的沟通习惯应该是从小养成的，尊重他人，言简意赅，主次分明，都是良好的沟通习惯。让与你聊天的人明白你的意思，让与你聊天的人觉得与你聊天没有压力，让与你聊天的人感到愉快，那么你的沟通能力应该是没有问题的，能做到的人并不多。

最后

作为一个新晋的产品经理，我自认为我做得还不错，希望在以后的工作中，能更快更好地朝着目标前进——成为一个真正受人尊敬的产品经理。