博客

近阶段（大约一个多月）一直在投入某个开发项目中，没有机会静下来思考一番。对于自己而言，

忙碌是一种不好的现象，不应该认为是一件理所当然的事情，应该是一种危机的存在

，这种状态持续两周后，便开始有点心慌，上周项目发布后终于有时间好好思考和总结一下了。下面主要总结一下近阶段有成长空间的点，从某种角度来说也是提升个人认知的要点，共勉。

• 
  遇到问题时，不要气急败坏，也不要一味地去推卸责任
  

  日常作为项目 pm 时经常遇到阻塞项目的各种问题，经常有些人会心急和气急败坏，就会出现投诉和推卸责任的现象，这是下下策，最终的结果是不但僵化了合作关系，而且还没有解决问题。所以遇到问题时，先要想办法解决问题，寻求最优解，达成共赢。

• 
  产品解决方案不能违背产品设计初衷
  

  在批判性地去看一个产品解决方案时，不能违背解决产品设计的初衷。以近期需求评审为例，为了解决某个业务痛点，产品设计上增加了额外的链路，虽然临时解决了业务痛点，但增加了入驻的复杂性，进一步加剧分销商入驻成本。

• 
  从代码 reivew 方面来提升业务思考
  

  近期代码 review 过程中的一个思考点，常规的代码 review 是大家围在一起看代码规范、并发等技术性问题，但缺乏从产品视去 reivew，最好的方式是以用户角度先去体验产品，结合代码设想各种异常场景，从而反思代码和产品设计上的不足。个人认为这也是提升业务思考的一种办法。

• 
  怎么分析与解决业务问题
  

  这一点的命题范围有点大，拿身边的事例来说明一下。大家都清楚分销商入驻成本高，组内某位同事通过一线对接分销商、体验整个入驻流程等方式得出入驻过程中的“难受”点，再进行问题分类，最终得到优化策略。这一套分析问题和解决问题的思路很值得学习，分享下：

  ​ 以客户视角去体验产品，并根据现实情况去分析客户遇到的痛点和系统优化点，最后去做分类和提出解决方案。比如直接和客户对接，结合实际对接体验和客户反馈的问题，得出对接痛点的结论，同时对问题进行分类分析，最终得出优化策略（比如区分对接客户优先级、引进答疑工单、客户诊断工具、对接流程节点标准化等）。

• 
  理解一件事情发生或产生的前因后果，凡事总要问个为什么
  

  日常工作遇到一件事情时，要知其由来，自己需要做些什么，做完之后后续还要做什么。比如：

  • 遇到一行代码报警，不要只想到怎么解决，要知道什么场景下产生的，再得出最佳解决方案。举个例子，某行代码出现NPE，不是判空一下就行，要想一下什么业务场景下会出现 NPE，再想怎么解决，说不定根本不用修改代码。
  • 接到运营的诉求，要多问一句为什么会有这个诉求，说不定会有更好的解决方案，因为你是了解背后原理的人。
  • …