毕业至今已有2年多的时间，试着去回顾总结自己的收获，也明确接下来自己努力的方向。

一、过去：收获篇

1. 日常被开发怼

因为不是计算机方向专业，且对计算机相关知识了解较少，输出的需求时常不够严谨，被开发人员吐槽。

开发、测试与产品同学的日常对话：

• “导出没有写吗？”“漏了，等下加上哈”
• “权限呢”“漏了，现在补一下哈”
• “上线要重跑数据吧”“嗯嗯，要的，我定义一下时间范围”

很多产品经理可能跟我一样，经常被开发人员怼的哑口无言。当然，“逃避”是无济于事的，那怎样才能避免这种事情的发生呢？

1. SQL是必须要掌握的技能。需求输出时更容易站在开发人员的角度思考问题，且逐渐理解“后端主要是操作各种数据并将其存储/取值于数据库，前端主要将后端返回的各个字段根据布局进行渲染”这一过程。注意明确目的：减少需求缺陷，增加自己的被信任感。
2. 阅读团队其他产品经理的PRD文档，建议还是先从自己负责的产品着手，一方面是通过阅读他人的PRD，做出对比“若由你来输出，可能会遗漏哪些需求点”，另一方面是熟悉产品，避免缺乏全局性的思考。
3. 总结自己的需求模板（比如针对“字段”：1、字符的格式/长度校验；2、唯一性……）。曾经有句话让我醍醐灌顶，“信不信我5分钟内写完这个PRD文档，还不会有需求缺陷”，在「初级」产品经理每天花费时间最多的事情上——写需求文档，为什么不花时间去总结，既能提高效率还能减少出错。
4. 把握每一次需求输出的“质量”。实践是让你成长最快的方式，实践的密度取决于你的工作强度，但是质量却由你掌控。你可能做不到每个阅读文档者眼中的完美，但是务必每次都要发挥出自己的最高水平。因为一旦被贴上了“不靠谱”的标签，想要撕掉绝非易事，最好的解决办法是每次都做到尽善尽美。
5. 维护人际关系。曾经有位朋友就对我说过“熟人需求开发时间*1.5，非熟人需求开发时间*2”，即如果与对方是熟人的基础上，很多事情的推动会比较快，且需求有缺陷时也能耐心沟通而非一味抱怨。

但如果刚进入项目团队，在与大家还没有建立关系的前提下，该怎么办呢？

去了解开发人员抱怨的深层原因。表象是因为需求有缺陷导致频繁沟通进度阻塞，但是又会怎么样呢？

比如该开发人员在该阶段急需表现自己，不想让自己负责的项目有延期，就会表现的比较急躁。这是我实际遇到过的。

虽然别人在抱怨，但是我们也要去了解别人背后的动机，并尽可能去满足对方的诉求，带来合作上的双赢。

2. 日常被上司怼

产品内部同事是你平时在职场上接触最多的，你的表现会被贴上一些标签，这也决定了你能接触到什么样的需求（上司进行分配）。他们毕竟也是人，也时常“先入为主”的去评价你。

1. 把每次需求输出都当作自己的“作品”，每一次都是表现自己的机会。
2. 先动脑再动手。在动手输出某个需求时，你可以统计下在「需求调研」和「需求设计」上各自花的时间，看看他们占比。我们经常犯的错误是被分配到一个需求后，马上着手进行设计，然后一边思考一边输出原型，最终的结果经常是不尽如人意。

首先写下不同角色各场景下主要任务——在进行过程中遇到的痛点，即你要解决的核心问题——在该过程中能够给用户带来什么收益，先厘清这些（后续会专门介绍本篇文章不展开讨论）。

不要打开Axure直接就开始画页面，不要打开Axure直接就开始画页面，不要打开Axure直接就开始画页面，重要的事情强调三遍。

先从整体流程考虑，这一步的关键是：厘清主要问题并解决，边界问题则后续再思考；

二、未来：方向篇

提升自己有很多方式，对于我自己而言，试过花了几千块报培训班，花几百块加入知识社群，在各大网站进行碎片化阅读等等，但是缺少了主要目标，你只要清楚自己的目标后才能知道该学习什么，否则什么都学消耗精力效果还大打折扣。

学习和做产品是同一个思路：以终为始。

以下是我接下来每天都做的事情，仅供参考，读者可以根据自己目标来确定。

最好的学习方式：阅读。

读书是一件成本很低但是收获很多的事情，通过阅读某一领域的著作，你会对这一领域有认知上的突破。

现在有很多互联网细分领域的书籍，可以根据自己的需要进行挑选。

• 阅读的最好方式是多记笔记，读书其实是一场对话，是双向而非单向沟通，最好的是认真倾听但也能表达自己的观点。
• 多接触并了解用户。产品服务于用户，了解他们是一笔绝对值得的投资，比如每天抽时间浏览用户与实施同学之间的对话。
• 浏览相关数据。你可以看出哪些模块是用户使用最多的？每天的用户数多少等等。有利于帮助你了解自己产品的现状。
• 拿自己写过的某个需求进行复盘，随着时间流逝是不是有了更深的理解，如果现在让你来做会有什么不同吗？

坚持虽是痛苦的事情，但却能渐渐为你带来好处，与君共勉。

本文由 @【穎杭】 原创发布于运营派，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议