时间: 2021-07-30 09:33:55 人气: 0 评论: 0
编辑导读：产品经理在经过职场的熏陶后，或多或少都**积累一些产品知识，并且有了自己的心得感悟。本文作者从自身工作经验出发，谈谈工作中的感想，以及对产品的一些发散性思考，希望对你有帮助。
谈一些工作中的感想，以及对产品的一些发散性思考，主要包括以下方面内容。
做事篇：
产品篇：
这条是最近做事一个很深的感悟，接一些看似很简单的需求，做起来如果自己不思考周全，并用心推进，那么简单的事情也容易变得复杂，尤其是牵扯到多人的小项目，因为大家的忽视与低投入，其实更容易将问题复杂化。
所以说没有简单的事情，有的只是将想事周全，做事认真的人。
拿我个人举例，在对项目的时候对于同事的想法持保留态度，但是因为害怕冲突就“嗯嗯”的糊弄过去，没有及时提出讨论对齐，这导致项目整体目标并不清晰，自己也容易陷入自我怀疑与迷茫，认真听取同事的想法，坦率并及时的反馈，这才是真正做好事情的路径。
在遇到困难的时候，愁眉苦脸，大发牢骚是完全不能解决问题的，人性总是倾向于推卸自身责任，直接表达负面情绪，但仔细思考，在面对问题的时候，抱怨除了自我发泄，将负面情绪传递给别人，并起不到任何作用。
以后遇到问题的时候，应该在抱怨之前问问自己，是不是眼下有更重要的事情，思考解决问题的方法，工作中不要带入太多自我的情绪，这是职业操守，也是做人修养。
这里说的“局外人”，在工作中更多指的是项目合作方之外的人，比如隔壁桌的同事（与本项目无关），从他人处获取更真实的对问题的看法，有时候可以带来新思路和新方法。
重视局外人，使得局外人价值发挥最大化的途径就是“问”，敢于问问题，善于问问题，这是需要不断学习的。
我在一个项目中遇到一个很麻烦的问题是打点缺失以及数据落点的随意，相信大家也**遇到因为前人并未很好的完成自己应该做的事情，导致到我们接手的时候发现是一滩烂泥的情况，这是因为他们在做自己项目的时候并没有主人翁意识，没有对他人负责的意识，不要成为自己唾弃，被后面人狂骂的这种人。
做事多想一步，在做完的基础上尽量做好，少给后来者挖坑，共勉。
以我自己举例，一个项目之前提的，然后交由了其他组的同事做，虽然自己也在群里，但自己屏蔽了群消息通知，就再也没看过了，结果最后同事做完发现因为与自己其他项目存在耦合，但因为之前漏了消息，同事也没及时通知，导致影响了手上项目的进展，你说这不怪自己怪谁呢？
究其原因，在同一个部门里，大家都对同一个产品做优化，那么一定**有工作交叉耦合的地方，这就是我想说的“没有与己无关的事情”。
如果不是自己的事情就高高挂起，不关心也不了解，那么对于自身业务也容易造成影响，或是因为因为不熟悉其他同事业务而错过自己项目可优化点，或是别人所做项目没考虑你，导致自己项目难以推进。
最近在做项目的时候发现一个严重的问题，自己以为写的清晰明了的复杂需求文档，很多RD并不**像你一样逐字逐句地去读去了解，这就容易导致：
换位思考，面对一个复杂项目动辄上千字的MRD，我是RD我也犯怵，草草看一眼遇到问题再问显然对他们来说效率更高。
那么有什么解法呢？
目前我的想法是将需求文档结构化，以“总-分”的形式写，具体如下如图所示：
MRD具体写法
具体来说，就是通过将需求拆分成一个个细碎需求点，并每个需求点分别建立一个小需求文档，依附在整体大MRD下的形式来写MRD，具体需求的框架通过“需求详解图”来给出，而在“需求拆分与项目管理”中，可以让项目方很清晰地看到需求拆分成哪些子项目，这些子项目分别的优先级与完成进度如何。
通过结构化降低了单个文档的信息密度，通过项目管理将需求整体进度收拢呈现，这种写法我觉得是可行的，具体效果待我后续践行再和大家同步。
在做事的时候，信息共享是重要一环，只有及时的信息同步才**消解各方信息差，促进项目更好地完成。
“报”和“问”同样重要，“报”指的是汇报，将自己的进展与遇到问题与项目成员以及上级同步，“问”指的是遇到问题时，及时问可能知道的人，不要害怕去问他人，不知道并不可耻，不知者不问才可耻，因为你耽误的是所有人的时间和精力。
PS：不要将别人的告知当做理所当然，所以态度一定要谦卑。
啰啰嗦嗦也总结了这段时间自己工作中的一些感想，有踩坑经验之后对很多之前觉得简单的道理有了更深刻的认知，这种认知的迭代正是自己的成长吧，与诸君共勉。
随心将夜，微信公众号 : 互联网菜鸟产品进阶之路，人人都是产品经理专栏作家。关注社交赛道和社区发展，擅长分析行业趋势。
本文由@随心将夜 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
