[随笔] 具有产品意识的工程师

具有产品意识的工程师

最近一段时间是公司的晋升季，我也对过去一段时间的工作进行了全面的复盘，识别、分析与改善不足之处的同时，也继续完善并发扬光大做的好的方面，这其中对“成为具备产品意识的工程师”有着深刻的体会。

研发人员的试错成本

研发人员的底线是交付产品需求，将抽象的产品需求转为化具体可执行的代码逻辑，这一过程首先需要充分理解需求，而需求表达通常会带有严重个人认知“偏见”，甚至是逻辑漏洞。

而研发人员经常面临的情况是，没有时间充分收集、理解需求背景、初衷，但却需要快速交付，甚至是需求倒排；所以经常性的，研发人员学会了“假设”，通过“假设”或者说“我以为xxx”，去弥补产品经理或需求描述留下的“空白”。这种情况往往十分危险且代价昂贵，轻则交付的功能不能满足预期，重则完全偏离了业务初衷造成严重影响，而这更像是为研发人员的“试错”买单。

所以很多时候，研发人员不是在写代码，而是在摸索中学习业务领域知识。

为了解决这种问题，需要产品经理和研发人员通力合作：

1. 产品经理：需要尽力将需求描述清楚，提供逻辑严密、通俗易懂的目标、要求，并且在项目实施过程中与研发紧密合作，尽早发现走向的偏差
2. 研发人员：通常具有严谨的思维逻辑，需要尽早帮助产品经理发现需求设计的漏洞，同时也需要尽早的参与项目，就像边缘计算贴近数据源头一样，研发人员也要尽量贴近需求源头，更好的理解业务或需求本身。

而一旦降低了研发试错成本，这何尝又不是一种“降本增效”呢。

产品架构

研发人员在精进技术能力、优化迭代技术架构的同时，也在摸索中学习业务领域知识，可以从以下几点出发：

1. 了解公司、部门的商业模式，了解钱是怎么赚的
2. 与产品同学建立并保持良好牢固的关系，有着较强的沟通能力
3. 积极参与产品构想、意见
4. 对用户行为、对数据敏感
5. 具有好奇心、喜欢问“为什么”
6. 对产品、工程的权衡能力：在充分了解需求背景、技术底层能力的情况下，需要同时兼顾产品与工程两者
7. 对“边缘case”、“极端场景”的务实处理
8. 注重快速的产品验证，以及对预期值差异的分析

DDD

写到这就不得不再提一下DDD了，在这些年的工作中遇到了不少DDD布道者，有大师更不乏骗子，并且也从未亲身参与到一个纯血DDD的项目中，更多的是充血+贫血，甚至是各种模式的缝合怪，但却丝毫不影响我理解DDD。

它不是一种架构或设计模式，而是一种思想，一种解决复杂问题的手段，特别是面对复杂且专业的领域问题的时候，能够帮助我去将熵。它要求研发人员在早期就积极参与学习领域知识，甚至提供了整套方法论去了解产品需求本身，让研发提高产品意识。

就像DDD虽然已经提出了快20年，但依然没有普及一样，研发人员也大部分依旧停留在交付需求、钻研技术甚至更多的时候在炫技，没有真正意识到，技术永远是为业务服务的。