目录

1.产品经理 ---已完成

2.UI设计师 ---已完成

3.前端工程师 ---进行中

4.后端工程师 ---未完成

5.测试工程师 ---未完成

6.运维工程师 ---未完成

7.App工程师（Android/iOS） ---未完成

8.算法工程师 ---未完成

10.运营 ---未完成

11.大数据工程师 ---未完成

每一个职位下面会分成：工作内容，职业技能，发展前景，薪水范围，成长阶段，入门门槛，天花板，职业素养，学习方法，学习路线，适合人群

一 产品经理

1 工作内容

沟通需求，整理功能列表，做竞品调研，出原型图，出设计文档，写验收标准，讲解需求，验收Demo，测试项目，上线后运营推广，收集用户反馈，健身，撕逼，写点产品文章混圈子，参加个线下聚会，熬夜，请程序员吃烧烤，学点基本的技术常识。

产品经理本质上分成两种，一种是有自己想法的产品经理，一种是有老板想法的产品经理，或者是有客户想法的产品经理。

当我们说到互联网的时候，第一个神奇的岗位就是产品经理，产品经理没有门槛，大学里没有特殊的职业，也不太有年龄限制，各行各业都要融合，月薪从几K到几十K都很正常，经常加班但是有头发，和程序员的爱恨情仇曲折动人，对性别友好，可男可女，你就算是属乌龟的也可以设计宠物应用，产品好和坏无法衡量，你判断不出来倒底是产品没设计好，还是技术没做好，又或者是运营没推好，甚至是大环境不好。

这个岗位几乎是最神奇也是最神秘的岗位，人人都是产品经理，但是又好像谁都做不好产品经理，入门容易，出彩难，写不了代码的可以去做产品经理，混了几年之后哪怕没有点产品思维，画的原型漏洞百出，一点都不妨碍他在老板面前谈笑风生，还能随时加个需求让程序员加点班。

最疯狂的时候，传统行业的人几乎将互联网思维等同于产品思维，好多老板都有危机意识，四处去取经，想了解什么是产品经理。

产品经理这个岗位，本质是面对需求的，需求往往来源于两个地方，一个是用户，一个是老板。

所以产品经理的主要工作，很大一部分来源于叫做业务逻辑的梳理，特别是在2020年的今天，各行各业和互联网的融合越来越密切，金融，汽车，医疗，电商，电影，教育等等，在过于，你做金融行业的产品经理，你可能会考一个证券行业从业资格证，但是像餐饮这种怎么办？供应链呢，社区电商，分销呢？

以证来证明你在某一个行业有经验，知道一个行业里的痛点，很难有说服力了。所以，在一个产品经理，并没有真正的从事一个行业长达数十年的时间里，很难直接把握用户的需求。

这就是出现了另外一个角色，就是行业专家，又或者是创业公司老板，或者是在别的行业赚了钱，但是又觉得赚钱太累的大老板。所以产品经理的工作内容，慢慢发生了一些转变，从自己直接接触用户，变成了从业务专家的嘴里收集需求。

无论是外包公司还是做自己项目的公司，都避免不了这种了解行业需求的场景，特别是对于刚入行的人来讲，要花很长的时间去理解一个行业的基础知识。但不管是哪一种，都需要收集需求。

很多人会比收集需求，直接跳到画原型，你也可以理解为，产品经理就是一个画原型的，没错，他的交付物确实是原型，但是原型并不是真正的核心，而只是产品经理产出物的展现。

在画出原型之前，产品经理应该先整理一份功能列表，这样可以快速的敲定功能的边界，产品的功能列表，我们推荐使用模块，二级模块，描述，备注的描述方法。

功能列表整理之后，相当于需求的边界圈定好了，那么第二件事，要做的就是设计每一个具体的模块，怎么设计？很简单，就是“抄”。文雅一点叫模仿，从各行各业各种适合你的需求里找相似点，找灵感，对比别人做的好和坏，我们通常把这种厚脸皮的行为叫做“竞品调研”，以及你的手机上至少要装200个App。

当然竞品调研并不仅仅是抄而已，在修真院里，有一套体系来尽可能把竞品调研这件事融合成自己的知识体系，简单来说就是分场景和解决方案，通过对各种竞品的分析，整理成不同场景的不同解决方案，然后来对比自己要设计的内容属于什么场景。这样，当你做完竞品调研，你就已经对这个行业一知半解了。

之后就是画原型，在这个工作之前，产品经理的岗位都只是一个看着大多数人都能做，并未完全显示出来专业性的部分，而在画原型的环节，你就需要注意一些专业术语和设计规范了。这包括网页，App，后台，H5，小程序等各种各样的元素组件，还包括了一些大小，尺寸，布局等。

虽然产品经理和UI在布局这种交叉领域里经常眉来眼去，但是你无法把布局这件事完全剥离出来。

布局其实就是人生的缩影，处处在做选择，比如说，登录注册，你会发现，现有的登录注册五花八门，从用户体系，到输入验证码，限制提示等等等，各种各样的布局都是选择困难症的恶梦。表单里倒底应该是左对齐，还是右对齐，还是两边对齐？抱歉，一个产品经理一个设计哲学，研发团队通常很难受，可是这是信仰，不是么？

布局结束了，产品经理的工作内容还没有完全结束。他要去写验收标准，这也是很多产品经理不注意，很多研发忘记要，导致出现各种各样扯皮的事情的原因。大部分产品经理都默认为验收标准是以自己为准的，同时是研发能够理解的，而且一旦自己心里的验收标准发生变化，研发团队就会立刻感知到。当然我们也推荐修真院的写验收标准的方法：做什么动作，看到什么结果。

当验收标准做完之后，产品经理的工作看起来结束了，很多产品经理也以为自己的工作结束了，实际上才开启了第二阶段，和研发团队的亲密砍杀阶段正式开始了。不是你画好原型，产品就能上线了，你需要借助研发团队，才能把东西做出来。这一点和男人生孩子很像，在没生之前，一个男人的很开心的描述孩子出生之后要做什么，然后眼睛里闪着小星星，一脸的渴望，却只能眼巴巴的看着女孩儿，这种事情他一个人做不到，哪怕他对未来有多好的设计，买了多少套学区房，总得有人和他一起生孩子才对。

嗯，就是这种感觉，他说的天花乱坠，研发小伙伴你记清楚了，他只是想要操你，或者是他不想，但是一定会这么做。对于研发团队来说，很多时候听产品经理讲需求就是这样的，一边听，一边做好了准备。

所以如果你想做一个产品经理，你就需要明白听你讲需求的这些秃子的心理活动，也难怪他们经常会在你讲需求的时候睡着，举一个例子，你做了100，原型上展示出来的可能只有60，研发团队可能在听需求的时候只听了5.嗯，又或者是0，大部分的人都希望你赶紧讲完，然后自己边做边看原型。。。。或者是压根就不看原型。

不管怎么样，当枯燥的需求讲解完成以后（啊，我漏掉了需求评审的环节，你们还想听么），就产品经理就可以轻松一点了。

不不不，清醒一下吧，到了研发阶段，才是产品噩梦的开始。研发团队就好像慢慢睡醒的考拉一样，开始提问，质疑，你不得不反复的去讲一遍又一遍你以为自己讲了很清楚的事情。

如果只是和研发团队交流还好，但在实际工作中，你会发现，研发团队这些秃子们都是属于心思慎密老奸巨滑的画风，善于在鸡蛋里面找恐龙刺，而且，还真的可能被他们找出很多。

如果这些找出来的问题你能拍板还好，如果不能拍板，你还要和老板或者是客户反复交流，传达，把老板的意思翻译给研发听，把研发的意思翻译给老板听，还要注意照顾双方的情绪。所以，你看着自己的工牌，突然间就会有种恍惚，产品经理突然变成了产品翻译官？

好不容易研发阶段完成了，到了Demo阶段，你会惊奇的发现 ：我靠，怎么做成这样了？

而且，各种流程走不通，很多超出正常人类理解的问题，你在页面上点一个按钮没反应，然后研发团队说：稍等我看一下，过了3秒钟他对你说，好了，你再试一下。你再点按钮，有反应了。很开心，然后你发现列表的排序是反的，就跑过去跟他说排序反了。等他改完，你想再测试一下，再点按钮，发现又没反应了。

最要命的就怕是在Demo阶段发现了致命错误，好像是地面上一直扔着有100块钱，但是你和研发的小伙伴们都视而不见，直到最后自己月光了才突然间发现这100块钱就安静的躺在那里，从来都没动过。

假设Demo阶段完成了，进入了测试阶段，在测试环境你还是需要给测试人员解释，这个是Bug，这个不是Bug，这个为什么要这么设计，这个只能这么。

产品上线之后呢？做为产品经理，产品上线的当天，往往是受伤害最高的一天。上线可能会不成功，可能你在测试阶段验证过的问题又出现了，研发团队告诉你是环境问题，配置问题，版本问题，脏数据问题，总之就是不可能没问题，我们又不是阿里，你又不给我们开阿里的工资，怎么可能不写Bug？

如果上线这一道关卡过了，用户真正使用了。。。做为产品经理才会明白，原来之前大家还是一个团队，老板还是很友善的，用户呢？

用户只会骂娘。你他娘的是意大利炮友么，设计出来这么难用的问题？你在这一刻才会瞬间理解人人都是产品经理的意思原来就是人人都可以骂产品经理是傻逼，哪怕你做出来的是微信，支付宝，拼多多，豆瓣等等等等。

不要着急，有用户来骂你还是好的，至少你还能微笑着听下去，想办法整理，汇总，抛弃来指导你的产品改进方案。真正的痛苦是什么？

是用户压根不理你的产品，没人骂你，就是不用。

这大概就是工作内容的一个简化的描述了，你害怕了么？不要怕，做产品真的很有意思，就是经常挨打。

2 职业技能

Excel，PPT，Word，Axure，禅道，Jira，脑图，流程图，MVP，敏捷开发流程，运营数据分析，表达能力，沟通能力，忽悠能力，和研发团队的的撕逼能力，以及赖以生存的行业知识体系。

产品经理对于Excel的要求并不高，会写功能列表就好，功能列表也可以用思维导图，但是我们尝试了很多次之后，还是觉得Excel更合适一点。

PPT就不一样了，产品经理对PPT制作的技能，还是有一点点要求的，主要是内容的组织形式，其次是展现形式。并不需要特别花里花哨，但是你看罗胖的PPT就很好，特别适合大舞台，PPT往往是展现给研发的一个非常重要的窗口。一般而言都是用来介绍项目的背景，竞品分析，自身方案的选择。

Word在敏捷开发中，用得的不多了，过去称之为产品需求规格书，很正式，到最后大家发现需求用Word来描述。。。实在是太慢了，那边研发团队的孩子都生出来了，你这边还在跟人牵手手，来不及。所以通常都用Story来代替，Story也很少用Word来展现，要么是直接Txt文本，要么是Excel，要么是直接用Wiki，或者是禅道等云端的管理工具。

禅道&Jira，都是缺陷管理工具，也会支持敏捷开发，在这里对两种工具的使用本身不难，相对而言，我们更喜欢禅道的使用体验。在这里最麻烦的就是怎么写好Story和分好优先级。

脑图是产品经理在使用过程中的利器，将老板的火花，用户的抱怨，自己的碎碎念等快速记录和整理的好方式，梳理思路必备的东西，推荐使用百度脑图。

流程图这里主要用于描述业务逻辑比较复杂的时候。画流程图的工具也用ProcessOn这种在线的内容，画流程图的时候请记住一点，不要花超过10个节点的流程，如果超过了，屏蔽掉细节，抽像一层，节点太多了，真的很难受。一个总的流程图+无数小的流程图，足以让你把业务逻辑讲清楚。但除了流程图之外，我们还推荐使用角色事件图，这是受Design Thinking的启发，流程图的最大的问题就是无法展示多个角色，竖轴是角色图，横轴是时间线，用方块来标识不同角色在不同时间点的事件序列，这种展示和设计效果，相对于流程图来说更简单直接，也更清楚。

MVP和这些工具不太一样，但是也可以称之为技能。MVP最核心的思想，就是将“我说的一切都有可能是错的”发挥到了极致。不要先开发程序再交给用户或客户使用，太慢了，来不及，你赌不起，最快最好的方式，就是在程序还没开发出来时就先在线下或线上跑通，有种手动拉高铁的爽快感。

敏捷开发就是另一个非常重要的思想了，在整个产品的技能要求中几乎占用了一半的江山，而且，大部分产品经理都不太懂敏捷开发，只是把他当成了开发流程，还有很多人认为在中国不适合推行敏捷开发，其实他们都是错的--敏捷开发的Story本身就是一个非常非常关键的概念，是贯穿了产品经理设计的主线。Story本身就代表着实际的假想用例，Story的价值就是决定了这条故事线的优先级，我们依据Story去争论，验收，假想，结合MVP会得到产品经理很重要的战略思想：确保大家在做正确的事。

运营数据分析属于产品和运营的交叉领域，在某种程度上，你很难分的特别细致，无论怎么说，漏斗模型，转换路径，关键的数据指标，你还是要学习的，连日活和留存的概念都不了解的话。。。。不太好去忽悠老板拿高薪呀。

表达能力其实不是产品经理独自要有的，任何一个岗位都需要。所以如果你的表达能力有限，或者是不够好，不是因为你做产品经理才需要提升，任何人都需要提升自己的表达能力，当然每个人的风格不同，你可以啰嗦或者是简洁，其实问题都不大，关键是，想要表达的好，一定要自己想清楚。

沟通能力是产品经理很重要的个人能力了。如果你的性格内向，不太爱跟人沟通，或者是没有沟通的技巧，在选择这个岗位的时候要特别的注意。产品经理可以说是项目中的太阳，唯一的光和热，需要和上级平级下级用户等等所有的能想到的角色都沟通。同时，因为产品经理自己只有设计能力，没有任何实施的能力，也不具备资源调度的能力更没有资金，所以产品经理要推进的每一件事，都要靠“嘴”。要哄着所有的人干活，这么想想也不错了，产品经理动动嘴，研发团队跑断腿，挺好。

忽悠能力是产品经理被人忽视，但是在实际项目中又特别重要的能力，产品经理要忽悠所有人，有时候连自己都要忽悠。正式的名称应该叫做调动大家的积极性，让所有人明白所做的事情的价值，而不是一个单纯的工作，对用户来说，也要想办法用产品说话，让他们感受到或者是你来挑逗他们的喜怒哀乐，是的，你也可以称产品经理是天外邪魔，他们不在你身边，用能掌握你的情绪，控制你的财富，还能占用你女朋友或者男朋友的时间。

撕逼能力是产品经理必备的，和研发团队吵架，或者是友好的交流都是常有的事情，更多的时候是他们不接受一种做法，而你认为又必须这么做的时候。而且研发团队常常会攻击到你个人，认为你的思维不严谨，逻辑性不强，准备工作不足，不接地气，异想天开，或者就是一个传话筒，没脑子，爱折腾，时时刻刻记着要坚强，坚定不移的撕过去~~

行业知识大概是产品经理成长过程中最核心的能力了，没有脱离业务的产品经理，特别是你在一个行业工作几年之后，通常都会问到你对一个行业了解多少，这个赛道里有多少种模式，大家的玩法是什么样，数据量多少，哪家活的好，哪家撑不下去了，和商战一样，越到中高级，越会注重这些，所以，从现在开始积累吧~~

3 发展前景

产品经理，研发，运营被称为创业公司的铁三角，由此可见产品经理岗位的重要性。正常来讲，一家公司，研发团队和产品经理的比例为4:1或者是8:1，产品经理本身的岗位决定了公司的方向，属于公司组织结构中的关键岗。

岗位路线通常会是：初级产品经理->高级产品经理->产品组Leader->产品总监->事业部负责人->CEO

初级产品经理：通常做的是偏执行，落地的一线工作，熟知工作流程，有业务知识背景，能和研发团队撕逼，可以理解Leader布置的任务，能验收Bug，收集有用户反馈等等，这些知识都属于能把事情做好的入门沉淀。

高级产品经理：熟悉竞品，对商业模式有一定的认知，对行业的游戏规则相对熟悉，对行业痛点相对敏感，能够带着新人完成项目，具备独立设计系统的能力，能够负责一个完整的小中型系统，和研发团队也比较熟悉，产品设计中的漏洞较少，有一些线上产品的经验。

产品组Leader:其实Leader岗算是管理岗，做了Leader未必就是一个高级产品经理，做了产品经理，未必能做好Leader。leader更多的是任务分配，进度把控，规范制定和节奏控制。所以在规范上会更偏重，也会经常和其他各组Leader协调解决问题。

产品总监：产品总监和纯管理岗不同了，最重要的就是把握产品的方向，寻找一个行业的切入点。全公司都在盯着你看，到底要设计一个什么样的产品？整体的节奏感和人员的编制也很重要，如果你是一个产品总监，你一定要在这个行业里有人脉，有交流，熟悉各个对手的数据，规则，动向，包括国内和国外的。

事业部负责人：在更大的公司里，产品经理很可能会上长升到一整个事业部负责人的角色了。你要管的人范围更大，不只是在产品内部，还要对整个产品的交付负责了。你需要对每一个环节熟悉，还要能够制订目标，核算成本，随时调整产品的方向和节奏，确保自己的事业部能做出成绩。

CEO：产品和运营都是CEO的最佳人选，技术出身的CEO也有，相对较少。做一个CEO，就是要为业绩和股东负责，要么是拿出来规模，要么是拿出来利润，又或者是能搞定投资，还能够搭建起一个好的团队。产品经理如果是经历了以上几个岗位，对于多件事情并行执行应该是很熟悉了，也擅于整合资源，能够跳出当前的平台站在更高的视角，全局化的看问题。

如果你对这些偏管理岗不太感兴趣，你依然能够在产品经理这个岗位上找到自己的发展路线，你可以选择一个小而美的方向，设计出来用户体验精致的产品，能够“让用户尖叫”，或者是让“好的产品自己会说话”，也可以选择一个热点，紧跟着风口起飞，管他落地之后到底是不是光着屁股，更可能抓住某个红利，如直播，公众号，小程序，带货等等等等各种各样的机会，快速赚一笔热钱。

上可以留名千古，下可以小富即安。任何人任何性格都可以在产品经理的岗位上展现自我，只是喜欢你的人是多是少而已。

互联网的每一个岗位，养家糊口问题不大，但是产品经理是一个独特有魅力的岗位，在某种程度上，你就是上帝，你可以创造所有一切不存在的东西。只是上帝有点多，到处都是而已。

============2020年1月19日更新分割线~~~=============

4 薪水范围

薪水范围通常和公司，学历，产品，城市，工作年限有关联，很多人都说过知乎的平均薪水高，emmmm，然而这在某种程度上是事实，又有人说，薪水范围是特例，可是如果一个人的资质普通，硬件条件一般，通过自己的努力+选择能够得到一个相对较高的薪水，就不能按平均薪水来计算，就是说，这是一个正常努力可达到的薪水。

以产品经理为例，北京入门的薪水在8K~12K之间，这组数字是大部分人都能达到的，少数人在转行做产品之前有其他优势，比如说上海一个小姑娘有日语优势，她本身的产品设计能力一般，但懂日语又懂产品的少呀，所以薪水还不错。

这种就是特例了，而二线城市，郑州，武汉，西安，成都这样的公司，2年内的产品经理薪水在6K~9K之间（虽然国家划成了新一线，但是从实际感受来看，北上广深还是属于一线，这些不错的省会算是二线，不要纠结这个）。

到了三年左右，就是一个分水岭，可能很多人的薪水过不了15K，也可能很多人三年就到了18K~24K。这个分水岭，就取决于你在过去做的产品好还是坏，因为你不是刚入门，给你定薪的，就是你过去项目的用户量，行业影响力。比如，微信的产品经理，出来之后薪水相对会比其他人高很多，因为他们的经验有可能给那些不如微信的人启发，让这些公司少走弯路。

这个时候的产品经理可以称之为中级产品经理了。

五年左右，又是一个分水岭，五年的产品经理，在北京可能会冲到30K了，也有可能五年，他的薪水仍然只有18K。五年里你在这个行业里应该有一些人脉，见知，你的管理能力会有进一步提升，在公司里都有可能被称做产品大神（其实都知道是在调侃），你关注的大概并不已经是页面交互这些细节，而是更深层次的商业模式。

同时薪水的增长是这样的，在前期，你从8K跳到12K，通常要花一到两年的时间，但是你从30K跳到40K，通常只需要一年的时间。

十年左右，大概就已经是普通的产品经理的巅峰了，再往上意义也不大，你的潜力其实在三年和五年的时候已经确定了，好一点的冲击年薪百万，差一点的在25K~30K，也就是说，工作年限越长，薪资差距越大。

可以用一个简单的二八定理来描述，入门，3年，5年，10四个阶段，每一个阶段都只有20%的人升到下一个阶段，剩下的80%的人留在当前的阶段。所以造成，随着时间的增长，有同样工资经验的人，差距越来越大。

而在刚刚说到的武汉这些二线城市，从目前来看，月薪30K差不多封顶了，而在一线城市，诸如北京，50K，80K还不算特别难见。

当然这么算下来，还是有一大批人，到不了顶。

大概这个意思，emmmm，表嫌弃我画的丑。这是以北京为例，如果是其他城市，50K的的天花板会低很多。

说到底，薪水和各个环节都很密切，只能看一个大的趋势，别人10年能拿到多少钱，不代表你不能超过他，也不代表你比他低。但是，很多行业里，你是很努力也比较难拿到一个相对高的薪水，大概有两个值是你在评估薪水的时候关注的，一个是平均薪水，这是最没有意义的，一个是努力薪水，这是更重要的。如果你入行之前就拿的主意是，我不太努力就是想拿个平均薪水，那你估计拿的是最差薪水。如果你入行之前想的就是，我要拿努力薪水，很可能你努力十年之后才发现自己只能拿一个平均数。

在当前的社会结构里，你能通过努力拿到一个相对不错的薪水的行业，已经是越来越难了。

============2020年1月20日更新分割线~~~=============

5 成长阶段

岗位路线通常会是：初级产品经理->高级产品经理->产品组Leader->产品总监->事业部负责人->CEO

重新看一下岗位路线，和成长阶段是有一些差别，从岗位的角度来说，会有一些偏管理和职位和行业背景的因素在里面，包括技术也是一样的，什么时候你都不可能做一个纯技术或者是纯产品。

但是我们说到成长阶段，就只是单纯从做产品的能力上去谈起，那么，一个产品经理应该怎么样按步就班的去成长呢？

1.从测试开始学习

2.从基本的组件和模块开始

3.学会整理功能列表

4.培养竞品分析的能力，给自己的设计寻找依据

5.画好事件角色流程图

6.讲好用户故事

7.注重Story的优先级

8.完善验收标准

9.学会敏捷开发流程

10.理解MVP

11.大胆做预测，谨慎做预案

12.从零开始获得种子用户

13.收集用户反馈

14.从数据增长中看产品缺陷

15.深入了解一个行业的主流商业模式

16.看大方向，看行业趋势

17. 分别学习2B或2C的设计技巧

18.用产品和数据说话

19.将产品归结于梦想，做你坚持要做的，要改变的，要创造的事情

20.在金钱和梦想中妥协，并达成一致

这其实是一个很长的话题，我期望能够在这篇专栏里完善下去。

从零开始学产品

这里的成长阶段，也受限于我自己的个人能力，只能列出来这么多。我一直都相信，IT修真院是一个伟大的产品，我们的DWS学习模式是一个教学方法上无限接地气又非常洋气的产品，不是体现在交互体验上，而是整个培