毋庸置疑，产品新人和产品老鸟之间普遍有着很大的差距，其中有一点体现在思维的缜密程度上。新入行的产品小白在考虑产品流程、写PRD文档时思考的
往往很单一片面，感觉都能说的通了，确不知遗漏了很多细节，很多可能的分支流程也都没有想到，在被开发测试的同学问的时候要么一脸茫然、要么随意的给一个
方案，这往往是不够干练优秀的体现。
那么作为一名产品新人，到底该如何成长为一名思维缜密的产品经理呢？经过一段时间的摸索思考，我感觉可以从三个角度来不断提升自己：
作为产品，多问自己问题
站在开发的角度来实现需求
站在测试的角度了体验功能
作为产品，多问自己问题
做产品设计多了之后，会发现很多细节、流程其实是相通的。当我们第一次遇到某个细节问题时，没有想到很正常，但是第二次第三次仍一直想不到那就说明有问题了。
为了应对这种情况，可以归纳一些特定的问题，在以后做设计写文档的时候时不时的问问自己，进而来帮助自己思考的更加全面。
比如当遇到用户输入项的时候，就要学会提问：是否是必填项？数据格式是什么？有没有字符限制？什么动作（时间节点）触发校验？......把这一串问题想一遍之后，往往会考虑的更加细致
再比如遇到限制条件时就要记得问自己：会有哪些不满足条件的情景？当遇到这些情景的时候该怎么处理？
还有当有数据交互的时候要记得问自己：数据是否有必要实时刷新？是下拉刷新还是进入页面刷新？
这一系列情景下的问题，可以根据自己遇到的情况不断的整理，逐渐累积为自己的一个问题库。养成习惯之后，每次遇到这些情景，就会下意识的想到这些问题，从而帮助自己思考的更加全面。
站在开发的角度来实现需求
看多了网上程序猿砍杀产品狗的新闻，感觉开发和产品的关系紧张的很，其实现实中还是挺美好的，我司的程序猿脾气都还是很好的。当然，开发和产品之间
确实有很多可能产生矛盾的点，更改需求、功能阉割等这些问题暂且不谈。主要说一下产品经理该如何交付一份详细可执行的文档或说明。
产品新人在最初的一些项目中，免不了经常被开发问各种产品需求实现的细节问题，问的自己也会比较沮丧，自己当初怎么会没想到这些问题呢？其实就是没
有学会站在开发的角度来考虑需求，此时如果产品经理有技术基础会更容易明白，没有的话经过项目的实践积累也能够做到。把自己当成开发，如果要实现这些需求
的话，我需要哪些条件说明呢？
比如获取数据的粒度问题。产品新人的文档中很可能有这样的描述：记录订单提交的时间、获取天气情况...然后就没然后了。可是在写代码的时候，开发需要知道时间是精确到分呢还是秒呢？ 天气是获取温度风力还是什么鸟东西呢？
再比如要给出足够明确的规则。产品新人很可能会写：推荐销量最多的商品...然后又没然后了。可是开发实现的时候需要知道销量是按照件量还是订单数计算呢？销量是计算多长时间呢？如果是一周的话，是自然周呢？还是之前7天的数据就可以了呢？
这样的例子不胜枚举。总体思路就是，作为产品不仅要需求描述出来，还需要站在开发的角度来考虑如何实现需求，如果你是开发需要哪些说明和条件才能用代码实现出来呢？虽不用会具体的实现方法，但想想必要的条件说明能更好的帮助我们把需求描述的更加详细。
站在测试的角度体验功能
除了开发会来问问题，测试人员在写测试用例的时候也会经常来骚扰产品经理，因为在某些测试场景下，软件/系统 到底如何反应或者如何处理才是被当做是正常的呢？哪些又是bug呢？产品新人很可能又忘了做出相关的说明。
测试人员通常习惯在各种极端情况下来测试产品功能，虽然在用户实际使用中很少有这种情况，但是既然存在可能性就要考虑清楚应对方案。所以作为产品经理，也要学会站在测试人员的角度“变态”的体验功能，考虑需求。
比如同样是在输入项，测试人员就会喜欢试：输入特殊字符会怎么样？超出了字数限制会是什么反应呢？必填项不输就点下一步又会是什么提醒呢？需求文档中把正常的流程描述的很清楚，可是这些特殊情况的处理是否都想到了呢？
再比如在付款或其它流程中，测试人员又开始变态的尝试了：我中途退出应用行吗？突然断网了我该怎么办？ 还可能会尝试一下多设备登录是否可行呢？咦，你这个优惠活动，我可不可以钻个漏多参加几次呢？
测试人员就是这么一群人，不管三七二十一的采用各种可能的手段来体验功能点，找到bug是他们的目的，可是把正常的反应和意外的bug定义清楚就是我们产品经理的职责。学会站在测试人员的角度来体验产品、测试功能，能很好地帮助我们把需求定义的更加精准。
总结
成为一名思维缜密的产品经理，不是一朝一夕的事情，需要项目的实践，不断的思考总结。「作为产品多问自己问题」「站在开发的角度来实现需求」「站在
测试的角度体验功能」只是我个人总结的三个思考维度，在这三个思考维度基础之上，我希望自己能成长的更快一些，走的弯路更少一些，早日成为一名思维缜密的，欢迎关注微信：pmschool。
网友评论