测试到产品经理的进阶之路

俗话说，不想当将军的士兵不是好士兵。长时间做测试工作的测试人员，有些有可能会有转型的打算，不想继续在测试道路上踟蹰前行。当下IT领域大火的产品经理或许是你转型的不二选择。那么如何才能顺利转型进阶成产品经理呢？我谈谈我的想法，希望给寻求这部分职业的人以启迪！

一、产品应该是好的需求

作为产品首先思维要清晰，业务需求明确，一方面可以快速与上级领导、合作人员沟通清晰，将需求达成一致。另一方面可以快速的将需求灌输给开发人员。所以测试人员要想进阶为产品经理，应该具备以下软实力。

1、良好的沟通能力。话谁都会说，但是说的漂亮、表达准确就非常难了。需要平时多积累、首先要敢于沟通，再次才是善于沟通。

2、良好的撰写文档的能力。千万不要小瞧这个能力，一个优秀的产品画出来的流程图思路清晰，一目了然。写出来的需求文档业务描述准确，无啰嗦缀语。

当然还应该具备硬实力。对开发框架、存储过程、SQL语句、以及管理工具的使用有独到的见解。就我目前接触到的产品经理大多是具有3年以上开发经验的人在担当。

二、产品应该具有优秀的SQL编写能力

诚然，产品作为一个项目的领头人，可以事事依赖开发测试，但是如果真的都这样做了？自己在开发测试中的技术方面的信服力肯定会大大折扣。当然处处都有辩证法，也不需要任何技术都精通。但是基本的SQL能力是一定要具备的。为什么要这样说呢?我们大家都知道一个项目正式上线运行后，需要进行一段时间试运行，确保项目确实满足投放条件。对于非web的系统，例如接口类，根本没有web界面只能通过后台数据库的存储数据正确与否来辨别程序功能是否正常。这里我展开说下两种SQL的书写。

第1种：优秀的产品经理一定善于创建视图。因为提数验证程序功能时，不是每张表的所有数据都需要，我们要从多张表中提取数据进行验证。创建视图这里有三个问题需要注意下：

（1）一般能采用左连接 lEFT JOIN ON进行的，不要使用等值连接。左连接如何写？教程很多。我只强调一点：LEFT JOIN左边的那个表一定是数据库中所有表的基准表，这个表的数据在你关联的其他表中尽量都有对应的值更佳。这样可以方便ON语句后面的连接。

（2）一般建立视图时都要进行分组，因此要善于使用group by子句。

（3）尽量使用count(1)来统计列数，而非使用count(*)。

之所以要注意以上三个问题是因为，这样书写出来的SQL针对大数据查询时（一般大于10万条）查询效率高，性能优越。对count(1)优于count(*)做下具体实例说明：我本地有一张表auther此表我插进去了大于2万条数据。执行结果如下：

可见执行select count(1) from auther所消耗时间为24毫秒，执行select count(*) from auther所耗时间为25毫秒，我们有理由相信数据更多时，这个差别会更大。

三、产品要有超抗压能力

虽然说有压力才有动力，但是不得不说产品经理要承担超乎寻常的压力。领导催催催，业务急急急，开发不作为，更加上需求变更频繁，所以需要承担超乎寻常的压力。必须学会自我调节、自我放松。同时要有良好的修养，更要有良好的定力，不因为外界因素而影响。

四、产品经理一定要有大局观

这个是日积月累的结果，业务催的急、时间短什么功能要在最短的时间内做完，什么功能可以延误，为什么可以延误。还拿保险来说：要对险种A进行开发开发时间为1个月，产品经理就直接将整理好的额需求草草交代给开发，然后就着手做，这样短的时间肯定是做不完的，最后的程序只能是不伦不类。此时需要产品经理有大局观的认识，作为保险产品：

，很显然保险产品的赢利点在于保费收取，所以承保功能应该是放在第一位的，出了保单意味着投保人有可能会提出更改保单信息，或者退保，那么批改操作次之，如果时间紧急，就应该优先将这两部分功能优先集中资源进行开发。其他3个模块的功能后续跟进。原则就是：
（1）优先使用的功能集中优势资源优先开发；

（2）前后模块功能有联系的应该善于分支开发，最后进行有效整合。总之大局观无处不在，体现在关键时候的决策。

看到这里，不知道对想转型做产品经理的测试同学是不是有所帮助，总结下如果你想转型做产品，就需要衡量下你是不是已经满足上面我说的四个条件。如果没有达到，请继续积累，要相信量的积累终究会产生质的变化！

测试可以进阶为产品！