涂总，您好！提前祝您春节快乐。
组织架构的调整，使得我对产品的定位以及产品部门的职责变得非常清晰，前所未有的清晰。
最近一直在思考现有的问题和来年的规划，以邮件的形式跟涂总您分享下。
现状
1、目标一致性问题
目标如果不一致，所有的方向都很使劲，但会停留在原地。
2022 年上半年，项目的需求到不了我这里，而我们做的事情对项目的落地和增效又没有任何帮助。
项目组的需求得不到响应会有两个后果：
- 项目要想各种变通的方式来实现功能，花更长的时间；
- 变通的方式可能不是客户想要的方式，客户的体验差，这些日积月累的不好的体验可能就是日后投诉的根源。
甚至一些个别项目禁止使用二开，采用完全搭建的方式来实现，满足不了的地方需要借助一些第三方工具，这些工具都有学习成本，最终结果就是实施周期变长。
2、搭配问题
人无完人，我们需要充分利用每个人的长处，这样就可以拼成任正非所说的「高桶」。
元旦后，我被琪雅拉进了葛洲坝路桥的项目群，目的是要做技术支撑，经过几天的紧急问题处理和事后的分析复盘，发现了一些问题：
- 项目的顶层设计出现问题，交付给客户的是一个考评系统，互相交叉评价会产生大量的数据，没有提前预判；
- 技术上错误地使用数据库触发器，导致大量的表死锁，导致考评数据的生成不及时、客户使用过程中频繁出错；
- 不得不中途修改方案，这是项目实施大忌；
- 项目组成员非常幸苦，元旦假期加班、周末加班、工作日也每天晚上很晚还要响应客户的问题。
让本来不到一周就能顺利完成的事情，最终花了两周多的时间。
我在想，项目是不是应该分下类型，适合一线人员做项目经理的，就由一线人员担任；适合二线人员做项目经理的，那就应该让二线人员来担任？
每个人还是要在适合的位置，才能发光发热。
3、加减法问题
做加法的效果容易感知，比如多读了一本书，多记了一条笔记，那么很容易感觉到「积累」。
正是因为这种思想，产品上会不停地加功能，说好听点，产品功能非常丰富，说不好听的，臃肿，易用性差。
那产品应不应该加功能呢？答案是肯定的。产品团队肯定要按照节奏去迭代产品，但出发点是以项目落地增效为导向、以一线实施人员的使用痛点为导向、以最终用户的用户体验为导向。
以这些为导向，那产品的迭代就不完全是功能的叠加，而是：
- 解决用户实际问题的功能的增加；
- 某些功能使用体验的优化；
- 某些淘汰功能的弱化甚至删减。
4、复用问题
在代码架构中经常说要提升代码的复用性，目的就是为了提升效率。
在 2022 年了解到存在升级难、迁移难的问题。
葛洲坝事务系统花了很大精力做完，需要迁移到其他项目，有大量的改造工作，接近重做；
省厅的项目想要迁移到其他地方，也几乎不可能，或者说需要花费大量的精力；
江铃从版本 6 是升级到 7，前前后后花了好几个月。
很多项目应该是能盈利的，但因为升级和迁移的不顺畅，最终可能导致赚不了钱，甚至亏损。
我认为这一部分也应该作为产品团队 2023 年工作的重点。
2023 规划
目标清晰了，事情就好办了，剩下的就交给时间，静待花开。
根据涂总的的指示，我理解的产品部职责如下：
- 作为项目落地的强有力支撑；
- 项目资源不足，产品优先支持响应；
- 产品功能的迭代必须是能提升项目落地效率、提升用户体验。
目标明确，所以，2023 ，我非常有信心。
年前跟团队的每个人面谈时，我说我们应该往一个终极目标去努力，就是将 S2 交付给一线或二线之后，他们不会来找我们了，这样，我们可以做更重要的事情。
这个不找不是说部门之间有墙的屏蔽，而且他们自己在实施和运维的过程中碰到问题，可以自己找到答案。
当然，达到这个目标很难，可以先从下面的一些方面先入手：
- 收集一线人员的想法，他们跟客户直接接触，能更清楚客户的问题和习惯，以此来反推需求（已经跟一二线人员做了座谈）；
- 构建内部文档库，使用引导的方式进行让实施人员能自己找到各种问题的答案；
- 平台代码层优化，让每一个异常情况都是明确的，有路可寻的，运维阶段的问题排查可以大大提升效率；
- 项目代码的提交记录要和任务进行强绑定，为迁移和升级做好保障；
- 将项目运维过程中的很多重复性工作，工具化。
一定要打破「又不是不能用」这种错误的思想。
2022 年初，我在团队实行敏捷模式，大家觉得效果不错，沟通变多了，问题变少了。后来由于一些阻力没有继续。2023 年我将恢复敏捷模式，三周一个迭代，有序地进行平台功能的升级。
每个迭代的内容会和项目团队进行沟通确认，然后跟涂总您进行汇报，确保所做的事情都是有用的，有效的。
最后，我想说，不管经济形势怎么样，疫情是否反复，只要大家心是齐的，就不惧怕任何困难。
评论
评论组件按需加载，不影响文章阅读速度。