文章目录
近阶段(大约一个多月)一直在投入某个开发项目中,没有机会静下来思考一番。对于自己而言,忙碌是一种不好的现象,不应该认为是一件理所当然的事情,应该是一种危机的存在,这种状态持续两周后,便开始有点心慌,上周项目发布后终于有时间好好思考和总结一下了。下面主要总结一下近阶段有成长空间的点,从某种角度来说也是提升个人认知的要点,共勉。
-
遇到问题时,不要气急败坏,也不要一味地去推卸责任
日常作为项目 pm 时经常遇到阻塞项目的各种问题,经常有些人会心急和气急败坏,就会出现投诉和推卸责任的现象,这是下下策,最终的结果是不但僵化了合作关系,而且还没有解决问题。所以遇到问题时,先要想办法解决问题,寻求最优解,达成共赢。
-
产品解决方案不能违背产品设计初衷
在批判性地去看一个产品解决方案时,不能违背解决产品设计的初衷。以近期需求评审为例,为了解决某个业务痛点,产品设计上增加了额外的链路,虽然临时解决了业务痛点,但增加了入驻的复杂性,进一步加剧分销商入驻成本。
-
从代码 reivew 方面来提升业务思考
近期代码 review 过程中的一个思考点,常规的代码 review 是大家围在一起看代码规范、并发等技术性问题,但缺乏从产品视去 reivew,最好的方式是以用户角度先去体验产品,结合代码设想各种异常场景,从而反思代码和产品设计上的不足。个人认为这也是提升业务思考的一种办法。
-
怎么分析与解决业务问题
这一点的命题范围有点大,拿身边的事例来说明一下。大家都清楚分销商入驻成本高,组内某位同事通过一线对接分销商、体验整个入驻流程等方式得出入驻过程中的“难受”点,再进行问题分类,最终得到优化策略。这一套分析问题和解决问题的思路很值得学习,分享下:
以客户视角去体验产品,并根据现实情况去分析客户遇到的痛点和系统优化点,最后去做分类和提出解决方案。比如直接和客户对接,结合实际对接体验和客户反馈的问题,得出对接痛点的结论,同时对问题进行分类分析,最终得出优化策略(比如区分对接客户优先级、引进答疑工单、客户诊断工具、对接流程节点标准化等)。
-
理解一件事情发生或产生的前因后果,凡事总要问个为什么
日常工作遇到一件事情时,要知其由来,自己需要做些什么,做完之后后续还要做什么。比如:
- 遇到一行代码报警,不要只想到怎么解决,要知道什么场景下产生的,再得出最佳解决方案。举个例子,某行代码出现NPE,不是判空一下就行,要想一下什么业务场景下会出现 NPE,再想怎么解决,说不定根本不用修改代码。
- 接到运营的诉求,要多问一句为什么会有这个诉求,说不定会有更好的解决方案,因为你是了解背后原理的人。
- …