【产品学习】从技术转型到产品的一些心得和建议

       最近我们公司有技术也想转型到产品，想要咨询我的一些建议，在这里也顺便总结一下。

       转型到产品的有两种，一种是技术转型到产品经理，另一种是其他行业、其他岗位转型到产品经理。而从技术转型到产品，也分两种，一种是技术有一定的沉淀，想试试更大的发展。另一种是技术实在做不来了，自己有几分优势就转型吧。

       个人觉得，如果是做技术的，还是建议要有一点沉淀吧，不然自己去培训了半年，出来找不到工作，就要转型产品，其实自己还是不了解这个行业，只是知道皮毛，还不如一开始就去培训产品经理。这里并没有看不起谁的意思，只是最近带团队，有个刚从前端转型过来的，我表示非常苦恼，想不明白，为什么做过前端，也不懂数据库，心累。刚接手的时候，每个人都在吐槽，太坑了。

       吐完苦水，还是讲下一些建议吧。

       首先，你要知道，你为什么要转型，你的目标是什么？

       我一直告诉自己，要成为一个不可替代，能解决所有扔给我的问题的人。要在团队建立起靠谱的形象是件不容易的事。

       那么，想成为一个产品经理，是要做什么？

       一个有点规模的公司，都会经历这个流程：需求收集、需求分析、需求确认、原型文档输出、需求评审、技术开发、验收产品。对于产品来说，每个阶段，都是不可缺席的。

       一、需求收集

       来源有很多，有业务部，有客户，也有自己挖掘。要从别人使用中、提出的疑惑中，时刻思考产品，如果客户重复工作，思考如何从产品层面解决。简单来讲，就是从不同的用户群体，以不同的形式收集到各种需求，这是最基本的工作。我们一般都是以表格的形式记录下来，多人协作的话推荐使用共享文档，例如腾讯、石墨等可根据个人习惯自便。

       二、需求分析

       我个人认为，需求分析是一项非常重要的能力。其实需求收集的过程，跟需求分析的过程是分不开的，来自其他人的需求，如果只是单纯的记录下来，那其实没有什么意思，你的作用，难道就是汇总？需求收集的同时，跟需求方沟通，了解要做这个需求的原因。你总得分析下为什么别人想要这个功能吧？多问点为什么，要了解客户真正的需求，什么才是真正的需求？

       是的，有时候客户说的功能，其实并不是他想要的，你得从中发现，他为什么要做这个功能，他的目的是什么？举个很简单的例子，客户要加个字段，你就说，收到，然后就让技术加了，有可能造成系统冗余，越来越难维护。

       需求分析的过程，也包括了评估这个需求能不能做，要不要做，怎么做，什么时候做，做多久。自己能不能评估得准确，要看经验和能力了。没有做过技术的，可能评估不出来；没有足够的经验，也许也不清楚改动起来会牵涉到多广。这个需求值不值得做，互相取平衡点，懂得取舍。

       三、需求确认

       这里说的确认需求，就是分析后，确定准备要实现的功能。

       需求整理完成后，梳理流程，跟技术确认，跟需求方确认了解决方案后，基本上可以直接进入下一步了。当然，小需求也可以直接跳过，大功能都是要确认一下的，你也不敢确保自己做的东西就是别人想要的是不是？你也不敢确保技术会不会砍你，吐槽一个天马行空的产品经理？

       需求确认了，就要经历评审、排期，尽量不要让需求插队。分析好需求，确认好需求，就按照进度来，凡事都有个先来后到，即使是来自老板的需求，也要有足够的分析能力，评估应不应该插队。

       四、原型文档

       这里将原型、文档一起写，其实也是自己的习惯，原型图旁边写着PRD，方便直观。

       这里就不教大家怎么学习使用工具了，一般Axure等画原型图的工具，一两天就能直接上手了。刚接触产品，是可能真的不知道怎么写文档，可以参考一下别人怎么写。我告诉我的团队，画原型图，要把自己当做设计师，尽量输出比较高保真的，我喜欢偷懒，经常会使用一些元件库，方便快捷还美观，逐渐总结一套自己的风格。写PRD，要把自己当做一个开发，要考虑周全，逻辑清晰，不要给开发、测试误解的机会。

       这里太多学问了，有空的时候我再单独谈谈怎么写PRD吧。

       五、需求评审

      评审会，也是要求产品经理需要一定的表达能力、自信、气场。开会前，要知道这次的重点是什么，先整理下。先把需求提出的原因跟大家讲，不至于他们不理解为什么要做这些。详细讲怎么做，改动哪里，哪些要注意的地方，balbala......

       评审会，也叫批斗会，有可能会被技术反驳得怀疑自己，有可能直接被技术打回来，这就需要考验你的情绪、心态、气场、反应能力以及情商了。被技术质疑，应该要怎么稳住；没有考虑到的地方，应该要怎么当场脑筋急转弯；一时没想好的，要怎么表述；需求有问题的，应该要怎么圆场......

       六、技术开发

       进入到这个阶段，产品基本上终于是告一段落了，（忙完了这期需求又可以忙下一期了）。

       如果产品是属于开发初期，那还远远未到功成身退的时候，如果产品是属于中后期，你就可以吃吃瓜，冲冲浪，补补脑，回答一下技术的疑问，补充一下需求文档之类的。

       七、验收产品

       验收其实是个比较重要的阶段，有很多产品可能不会去验收，测试完成了就可以了。但是作为产品，你自己都不看一下出来的效果吗？万一跟你的预期差太远怎么办？

       我之前做开发的时候，也老是很烦我的产品，让他看一下做的功能，他就首先看一些无关紧要的东西，例如界面啊、一些交互啊。当我自己成为产品经理的时候，我也是第一眼就注重体验，二话不说顺手先给开发提个禅道......

       产品上线，不可避免会遇到延期，应该怎么跟上级甚至老板解释，也是一项考验。具体问题具体分析，是实话实说还是投机，就要看你自己，看什么项目，看什么环境了。

 

       总结一下吧，这一年半来，累是很累，但是我一年就获得了两年的经验，不亏了。

       自从做了产品，脑细胞不够用，感觉自己的头发掉得更厉害了，迟早要秃。自己做过技术，操心的东西也更多了，前期还是会不可避免会一直站在技术的角度去思考，没有很好地转换角色。但是利大于弊吧，技术有什么不懂的，我可以帮忙找解决方案，不管是思路还是百度谷歌，都知道技巧去查。当程序出现了bug，其实自己都能快速定位到问题，还能自己查询数据库，自己动手，丰衣足食。

       总的来说，给几点建议给大家：

1、我们想的理所当然，不是别人想的理所当然，原型文档要写详细

2、了解客户的真正需求

3、分析产品，取平衡点

4、控制好情绪，特别是跟开发争论的时候

5、认可开发，自己有方案时也可以听下开发的想法，开发被认可，会给更多的正反馈

6、控制好排期，需求尽量不插队

7、产品的3种核心能力：沟通力、决策力、执行力