大家都知道懂点技术的产品经理更吃香,那么有没有可能快速给自己的大脑武装上技术思维呢?(本文源自给团队的产品小伙伴培训的一点思考)
关于产品经理(尤其是 ToB 产品经理)需要懂技术的文章网上一搜一大把,不过我感觉大部分切入角度都不太对。因为对于不懂技术但是想要了解技术的产品经理来说,难点不在于要懂什么技术,而在于为什么要懂这个技术以及这个技术对产品经理本职工作有何影响。所以本文我会尽量以产品经理的视角来梳理各个重要的知识点,希望对大家有所帮助。
浅尝,但无须辄止
随着计算机学科几十年的快速发展,即使是作为开发人员,想要事无巨细了解各个细分领域也已经变成了几乎不可能完成的任务,所以更别说对于没有太多技术背景的产品经理了。所以对于懂技术这个事情来说,一定要把握好度,这里我简单总结了一下:浅尝,但无须辄止。
因为技术领域多,所以需要一定数量的浅尝来建立技术的感觉和思维,只需要大致了解基本的的原理即可,剩下的可以在实际项目中,多和技术人员切磋,这样就可以在最有用的地方继续深入,即无须辄止。
带着目的去浅尝技术
如果说开发人员学习技术的目的是为了更好地开发,那么产品经理去了解技术的目的一定是更好地设计功能。所以针对项目开发的不同阶段,产品经理经常需要思考的问题以及对应的技术点如下:
问题一:项目的时间安排是怎么样的?如何推动开发人员?开发人员是如何分工的?
这个是软件工程中的经典问题,目前最常用的开发模式有两种,产品经理可以根据实际情况自行判断(附有链接,可以点开详细了解):
笼统来分的话,开发人员主要分为前端和后端,前后端一般通过事先设计好的接口 API 完成数据交互:
- 前端:运行在用户的设备上,用户直接能看到的内容
- 后端:运行在服务器上,用户看到的内容背后的逻辑部分
一个良好的前后端分离的工作流程,前后端工程师的工作没有相互依赖关系。
问题二:某个具体功能要如何设计,才能尽可能降低开发人员理解的难度继而减少开发时间?
这里的关键在于设计模式:软件设计模式(Design pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
如果一个功能是基于经典设计模式进行设计的,开发人员就可以非常自然地将功能实现出来。
注:这一部分难度相对来说比较大,有时间我会更详细说明介绍一下。对设计模式的理解可以认为是通向高级产品经理最重要的一步。
问题三:数据是如何存储的?如何拿到最新的数据?
这里涉及两个概念,一个是数据库,一个是同步/异步。
- 数据库常用的比如 MySQL 为主的关系型数据库,需要关注的是主键、索引、关联表。需要能够看懂 ER 图,以及基于 ER 图去推演功能逻辑的具体数据变化。
- 同步与异步,需要了解这两个的差别,以及具体适用的场景,并能够运用到功能设计中。
在此基础上,需要熟悉数据流图(Data Flow Diagram),产品经理需要了解业务数据如何在各个模块中流转,并能够在需求变化时及时修改 ER 图和 数据流图。
问题四:某个功能会在哪些平台上线?是否需要针对性调整?
如果一个功能在 Web 端,小程序以及 App 上都要上线,那么就需要去了解不同平台的差异,其中 Web 端和 App 端自由度相对来说比较大,小程序则依赖于 API 的开放,所以产品经理需要去了解同一个功能在不同平台的实现方式。
比如在这里可以看到微信小程序的相关能力,功能设计要以这些能力为基础来进行设计。
问题五:如何快速排查是前端还是后端出了问题?
这里只需要两个简单的工具,一个是 Chrome 的控制台,一个是能够访问数据库的管理工具。通过 Chrome 控制台,可以快速定位问题;通过数据库管理工具,可以及时发现导致问题的数据根源。
了解开发人员的习惯
彼此了解才有默契,而开发人员因为经常跟机器打交道,很多时候有些习惯是高度一致的,这里列举如下:
- 同一个功能,好的开发会有一个统一的方法,在不同地方使用。所以尽量保证功能的可复用性。
- 开发不喜欢在代码中处理 if else 以及写死的逻辑,因为迟早要改,改还容易改错。所以最好有统一的机制兜底,定制化的另外处理
- 开发看懂的文档才是好文档,尤其是核心概念的理解,需要对齐,这涉及到具体的计算公式。文档中给出的测试场景越详细,开发就能够在提交测试之前尽量多覆盖
- 添加字段没有想象中简单,因为还需要处理老数据,以及兼容多种不同类型的数据,所以要慎重。
- 自己负责的功能,需要时不时跟开发进行跟进,并且将进度落实到文字记录中,边开发边测
- 如果遇到开发说不能做的,需要了解清楚为什么不能做,以及如何去曲线救国
- 高保真原型图可以凸显很多细节,在做 MVP 的时候高保真会拖节奏,但是正式产品,时间允许的话,高保真你好我好大家好
- 开发喜欢有连贯的时间去思考和编写代码,建议不要经常打断,每天预留几个时间段用来处理讨论和沟通问题
- 多数开发比较直接,刀子嘴豆腐心,说归说,还是会努力完成功能
写在最后
产品经理懂技术,其实不单单是一个技术问题,更是一个思维和沟通问题,这就需要双方都带着开放的心态,尽量换位思考,这样团队运转起来才会越来越快,最终达到:只要你一个眼神肯定,我的文档/代码就有谱的程度。
面试过很多产品经理,懂工具的很多,对领域的认识和理解有深度的很少。工具和技术能够很快学会,但对所在领域的热爱和深刻理解是需要长时间积累的,这才是一个产品经理最重要的价值所在。