产品研发思考2023
2023-02-10 09:55:04 4 举报AI智能生成
结合2022年产品研发团队管理从团队规划、研发流程、技术架构等维度的思考总结
作者其他创作
大纲/内容
技术力量比较分散，没有统一的技术体系
各研发团队只关注自己的绩效，相互之间很难协同
注重小团队作战以及快速迭代
敏捷开发
开发模式
目前现状
也不容易有核心的技术积累
形成了大大小小的技术孤岛
可以聚焦业务目标，降低沟通门槛
优点：
资源无法复用，团队经常重复劳动
缺点：
1、产品型研发组织结构
技术比较强势
所有需求汇总，统一指派，按产品驱动
适合业务比较稳定的公司
2、职能型研发组织架构
3、前两种的组合模式：业务线（配技术团队） + 底层技术团队
几种方式
1、一个团队在做的事情要相对稳定，不建议频繁更换，不利于积累经验
2、无论是对商业、产品还是技术类的知识，都需要有一个系统化的积累过程，这样才能进步和成长
3、在底层系统比较稳定的时候，适当抽出少量人员做项目是可行的
分配原则
搭好底层积木是前提
产品经理、开发、测试的能力很差，还有很多技术挑战不好解决
基础架构建设、人员能力提升
1、如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织
业务成功是最重要的，其他的问题可以在发展中解决
2、如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构
降低对于大多数开发、测试人员的专业能力要求
将研发规范管理和基础平台能力建设两个功能凝聚在一起
赋予权利
统一规划
统一建设
统一组件
统一规范
3、设立技术管理委员会，统一建设基础平台和研发管理平台
架构选择
组织架构
技术委员会
前端技术组
JAVA技术组
算法技术组
C++技术组
技术小组
虚拟组织
产品性能
基础架构
运维平台
统一存储
基础架构部
研发部门
提供基础服务能力的同时，提供对应的自助化运维能力
做好运维和整个技术架构体系的融合，不能割裂
要考虑如何打造和体现出整个技术架构的运维能力，而不是运维的运维能力
基本思路
片面地从运维的角度看运维
片面地从运维的角度规划运维
运维价值
标准化体系以及 CMDB（运维管理系统）
应用配置管理
资源管理
1. 运维基础平台体系建设
标准化
服务化
基于开源产品的二次开发或自研的中间件产品
2. 分布式中间件的服务化建设
提升整个研发团队效率的关键部分
拉通运维和业务开发的关键纽带
从应用创建
研发阶段的持续集成
上线阶段的持续部署发布
再到线上运行阶段的各类资源服务扩容缩容
整个软件或应用的生命周期的管理体系
3. 持续交付体系建设
如何快速发现线上问题
如何快速定位问题
如何快速从故障中恢复业务
如何有效评估系统容量
软件系统线上的稳定性保障
如何对故障应急响应
如何对故障进行有效管理
如何对故障复盘
如何加强日常演练
运作机制的建设
4. 稳定性体系建设
确保我们制定的标准、指标、规则和流程能够有效落地
技术平台
管理流程
执行人的沟通协作
运作机制方面的建设
5. 技术运营体系建设
从价值呈现的角度看运维
团队以虚拟形式重新规划了不同职责
作为共性要求提出
要能够有制定输出标准的意识和能力
能够有规范流程制定的能力
同时能够将标准和流程固化到工具平台中
最后能够确保承载了标准和规范的平台落地
要求团队每个成员都要具备技术运营意识
靠团队协作来执行
要有一定的规划、设计和落地能力
能力要求
对技术运营体系
规划思路
要站在怎么能够打造和发挥出整个技术架构体系运维能力的视角，而不仅仅是发挥运维团队的运维能力
一方面运维团队要主动出击，去沟通，去推进
另一方面，必须能得到上级主管甚至是更高层技术领导的支持
跨团队协作
协作模式
从团队需求和运维价值呈现层面成立的虚拟组织
包括 IDC 运维、硬件运维、系统运维以及网络运维
基础运维
主要是业务和基础服务层面的稳定性保障和容量规划等工作
应用运维
包括数据库、缓存以及大数据的运维
数据运维
主要是提供效率和稳定性层面的工具开发
运维开发
岗位
从实际的人员管理以及技能维度来划分
运维部门
促进职能协作上的融合
无法走出运维低价值的困局
团队规划
编码【人类才智】⟹代码审查【人类才智】⟹静态检查【机器】⟹单元测试【机器】⟹测试【机器】⟹构建【机器】⟹部署【机器】⟹监控【机器】⟹自动扩（缩）容【机器】
静态检查、单元测试和构建环节发生在每一次代码提交之后，由代码版本库的代码提交事件触发执行，如Gitlab 的 Webhook
静态检查由各语言的语法 Lint 工具和 bug 检查工具组成，前者包括 JS 的 eslint、Python 的 pylint 等，后者包括 Java 的 findbugs 等
1. 静态检查
基本上每种语言、每种框架都有支持单元测试，如 JS 的 Mocha、Python 的 unittest、Java 的 JUnit、Go 的 testing
让测试工程师参与到单元测试编写中来，每一次项目的测试用例评审，一部分用例一定要转化为开发工程师的单元测试。或者说，测试工程师需要参与到开发工程师的单元测试审查和覆盖率评估中，对应的，开发工程师也要参与到测试用例评审中。这二者相结合，黑白盒、单元集成测试才能真正有机的为项目质量负责
2. 单元测试
例如前端的 webpack、后端的 maven、客户端的打包等
构建（Build）是需要开发工程师根据项目的部署策略编写对应的构建打包脚本
3. 构建
1）静态检查、单元测试、构建
自动化测试由测试工程师维护，由两块工作构成：测试用例管理、自动化测试脚本编写
测试用例管理流行的工具有 Excel、Qmetry、TestLink
1. 测试用例管理
常用的框架有 LoadRunner、Selenium、Appium 等
这里的自动化测试，主要指的是黑盒测试和集成测试，和开发工程师维护的单元测试做一个区分
2. 自动化测试
2）自动化测试
1. 部署
前端Sentry
后端Cloud Watch（AWS）、loggly
异常监控
APM 探针实时收集应用服务器代码层面的性能信息；
机器状态（cpu、mem、load）、应用服务响应时间等
性能监控
2. 监控
配合日志收集器工作
3）部署、监控、自动扩（缩）容
迭代机器里的流水线
Jenkins、Bamboo、Solano CI
Continuous Integration系统
研发流程
形成事业部自有的技术体系
完成各业务产品的深度融合
利用AI技术向各个部门赋能
主要目标
技术线总监 + 技术专家
成员组成
组织定期会议
组织研发评审
云计算、大数据、AI、分布式数据库等
主题
内部自荐
外部聘请
讲师
月度技术分享
工作模式
各部门轮流对各自领域的技术进行分享和推广
运作模式
成立技术委员会
构建技术体系
顺势推进
利用一些时间窗口和契机
新技术的推动
允许不同团队选择适合自己的开发机制，不必强行来推动敏捷 DevOps
对于发展比较迅速，人员比较年轻的团队，多运用正向激励
而对于情况相反的团队，可能负向激励会比较奏效
对于不同团队，也应该有不同的激励手段
管理方式的调整
对于自己 Own 的事情和系统负责，不是简单的别人给你派活，你来做，而是要有强烈的责任感，出了问题要第一时间跳出来想解决方案，而且要一竿子跟到底去真正解决问题
要去总结和思考自己 Own 的事情和系统，看怎么才能把它们做的更好，是沿着业务支撑的方向走，还是沿着技术驱动的方向往前走
要推动自己 Own 的事情和系统去跟外部合作，并拿到结果
要站在客户的角度去思考问题
1）有担当
执行力和速度感并不是加班，而是要擅总结、有方法
是你要不停的熟悉项目和系统，主动总结和思考，去发现问题和改进问题，然后主动去沉淀出相关的技术和工具
真正的执行力和速度感，是来自你清晰的思路和深厚的功底，是一个厚积薄发的过程
2）执行力、速度感
一是要弄清楚重点是什么，必须要在重点事情上拿结果；二是要提出和做到有挑战的事情
可以从你的 OKR 中看出你想创造的价值是什么？实现的思路是什么？思路中有几个核心问题需要解决？具体打算怎么解决？
如果能把这些都想清楚，做出来的 OKR 自然会比较好。对于那些先定一个不太难的 OKR 的做法，哪怕把它完成了 120%，也并不赞同
我们考核的不是OKR的达成率，而是OKR的挑战性或者精彩性
3）有挑战、做精彩
员工之间开放交流，思想碰撞。大家对如何做好一件事情有不同的看法，在交流、碰撞的过程中，就能把自己的方案逐渐完善。
鼓励大家乐于和勇于把自己的观点表达出来
会基于他的思考跟他有针对性的沟通，告诉他怎么样能思考的更深入，让想法更具可行性等
越有想法、越爱表达的人，建议考虑对其重点培养
4）大声说话、开放皮实
制定文化方向
什么样的研发就算一个好研发?
什么样的测试就算一个好测试?
什么样的运维就算一个好运维?
我们认同什么样的人？
我们 Hire 什么样的人？
我们做什么样的 Leader？
思考题？
不直接把结果告诉大家，而是带领团队去思考
大家对于“好”的定义和认知是否一致？
1）要根据之前的共识确定选拔标准，不再是之前简单的能把活干了就 OK，而是要看他是不是够快，是不是有创新能力，这些将成为提拔人才的标准
这样就形成了一个机制，管理层能对文化有比较清晰的认知，如果有员工不符合团队文化，他们也会比较敏锐的感知到
2）各个管理层隔几个月要做一次群 Review，反思自己哪做的好，哪做的不好，先保证 Leader 层面的味道
管理者
1）跟大家讲一下公司的目标、规划和发展情况，以及下一个季度技术和产品的规划等
担当奖
最快执行力奖
大家有没有自己的 Idea
能不能想出对用户有帮助的功能
或者行业里边哪些技术可以和我们结合
创新奖
2）对优秀员工进行表彰，设立的奖项则完全匹配之前提到的文化
让获奖项目总结他们是如何有速度感、快起来的，在管理、执行上沉淀了哪些工具和措施
打攻坚仗的项目
每3个月组织一次技术开放日
1. 树榜样、荣誉体系
1）跟员工做 One One 的深度沟通
有哪些地方值得表扬
有哪些地方需要加强
在项目复盘的时候也会复盘这个东西
2）对于我们追求的快、速度感、执行力、Ownership 等特质，他们究竟做的怎么样
如果你一直鼓励这些文化，它们就会慢慢深入到每个人心中
3）当你鼓励什么的时候，什么就会生长起来，当你反对什么的时候，什么就会消失掉
2. 员工 One One、项目管理
1）对于认同我们、在这儿做出贡献的人，我们就一定要对得起他
2）如果大家真的观点不一样，那还是尽早分开，避免更多的沉没成本
3.Hire、Fire
员工
大力打造荣誉体系，并树立榜样来进行鼓励
并不是每个人都能认同和融入的
但不认同并不代表他不好，也许只是不适合
在这件事情上要坚决一点
文化如何落地
工程师文化
技术管理
对业务需求的提炼和抽象，使用一套方法论对产品（项目）所涉及需求的业务进行业务边界划分
◎ 业务平台化，相互独立
◎ 基础业务下沉，可复用
（1）将业务平台化
将核心业务精简（利于稳定）
（2）将核心业务和非核心业务分离
（3）隔离不同类型的业务
◎ 在运行时优先保证主流程的顺利完成
◎对辅助流程可以采用后台异步的方式，避免辅助流程的失败影响主流程的失败回流
（4）区分主流程和辅助流程
设计原则
业务架构
需要指出系统的层次、系统开发的原则、系统各个层次的应用服务
应用架构介于业务与技术之间，是对整个系统实现的总体架构
◎ 一切以稳定为中心
◎ 架构尽可能简单、清晰，追求小而美，不要大而全
◎ 不过度设计
（1）稳定
◎ 将稳定部分与易变部分分离
◎ 将核心业务与非核心业务分离
◎ 将电商主流程和辅助流程分离
◎ 将应用与数据分离
◎ 将服务和实现细节分离
（2）解耦
◎ 应用抽象化：应用只依赖服务抽象，不依赖服务实现的细节和位置
◎ 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片
◎ 服务抽象化：应用虚拟化部署，不需要关心实体机的配置，动态调配资源
（3）抽象
◎ 跨域调用异步化：在不同的业务域之间尽量异步解耦
◎ 非核心业务尽量异步化：在核心业务和非核心业务之间尽量异步化
◎ 在必须同步调用时，需要设置超时时间和任务队列的长度
（4）松耦合
◎ 服务自治：服务能彼此独立修改、部署、发布和管理，避免引发连锁反应
◎ 集群容错：应用系统集群部署，避免单点服务
◎ 多机房容灾：多机房部署、多活
（5）容错设计
应用架构
数据架构是对存储数据（资源）的架构，其设计原则和应用架构设计大同小异，在设计时需要考虑系统的业务场景，需要根据不同的业务场景对数据进行异构设计、数据库读写分离、分布式数据存储策略等
（1）统一数据视图，即保证数据的及时性、一致性、准确性和完整性
◎ 应用系统只依赖逻辑数据库
◎ 应用系统不直接访问其他宿主的数据库，只能通过服务接口访问
（2）数据和应用分离
（3）数据异构，即在源数据和目标数据内容相同时做索引异构，在商品库不同维度的内容不同时（如订单数据中的买家库和卖家库）做数据库异构
◎ 将访问量大的数据库做读写分离，例如订单库
◎ 将数据量大的数据库做分库分表
◎ 将不同业务域的数据库做分区隔离
◎ 对重要的数据配置备库
（4）数据库读写分离
（5）采用关系数据库。除成本因素外，MySQL的数据库扩展性和高并发支持能力较强，公司的研发和运维在这方面有一定的技术积累
（6）合理利用NoSQL数据库。在数据库有能力支撑时，尽量不要引入缓存。另外，要合理利用缓存做容灾
数据架构
技术架构是对在业务架构中提出的功能（或服务）进行技术方案的实现，包括软件系统实现、操作系统选择和运行时设计
（1）无状态，即尽量不要把状态数据保存在本机上
◎ 复用粒度是有业务逻辑的抽象服务，不是服务的实现细节
◎ 服务引用只依赖服务抽象
（2）可复用
◎ 跨业务域调用，尽可能异步解耦
◎ 在同步调用时设置超时时间和队列大小
◎ 将相对稳定的基础服务与易变流程服务分离
（3）松耦合
◎ 服务可降级
◎ 服务可限流
◎ 服务可开关
◎ 服务可监控
◎ 白名单机制
◎ 制订服务契约
（4）可治理
◎ 基础服务下沉、可复用，例如时效、库存和价格计算
◎ 基础服务自治、相对独立
◎ 对基础服务的实现要精简，并可水平扩展
◎ 对基础服务的实现要进行物理隔离，包括基础服务相关的数据
（5）基础服务
技术架构
架构设计
静态化：动态数据和静态数据分离
异步化：使用异步化减少主流程中的非关键业务逻辑
并行化：使用多线程并发处理，缩短响应时间
内存优化：减少对象大小，减少对象创造，数据模型优化
去重复运算：业务逻辑优化，或者使用缓存
减少数据库操作：数据冗余，数据缓存等
缩短数据库事务：短事务，异步化，最终一致性等方式可以考虑
精简代码逻辑：去除冗余代码，诸如过度设计检查等代码
精简日志操作：日志大小要关注，注意IO上的瓶颈；日志太多，说明生成的string也会多，也增加了gc负担
架构优化
虽然是做技术规划，但如果脱离了业务支撑，是引起不了老板兴趣的
1）紧扣业务
老板只会为解决实际问题的技术规划买单。规划的开头最好能从实际问题出发，比较容易引起老板的注意
2）从实际问题出发
只有能落地的技术才有说服力，老板不会被天花乱坠的技术词汇给迷惑的，他只会关注最后能落地是哪几项，应该重点谈落地的目标和计划
3）重点在落地
其中一个哥们说了很多，非常丰富，但关键点不突出，结果在老板看来就是个零。在表述规划的整个过程中，一定要紧扣关键旋律，让老板用最短的时间理解你的意图
4）突出关键点和关键路径
有的哥们搞得规划面面俱到，结果搞得老板不相信，他想要的东西不是大而全的，而是在一个阶段里能一刀见血的，因此搞规划切勿四面开花，把最关键的、老板最关心的抠出来，并确保把它搞定
5）少、准、狠
老板很关心目标，这个胜于具体的行动计划，他需要用这个来最后check你的结果，因此不量化的目标是通不过的
6）目标要量化
技术规划少不了合作方的支持，在汇报之前一定要知会到相关方，最好能达成一致，因为老板一定会在汇报过程中质疑你是否做过沟通，有好几个哥们因为这个做得不到位，导致老板觉得这个规划是纸上谈兵，不靠谱
7）和相关的人要事先沟通清楚
如果这个规划只需要你自己或小范围几个人就能搞定，老板会觉得没价值，他希望看到是能involve更多的人，最好还是跨团队的人，只有具有影响力的事情才有规划的必要
8）具有足够的开放性
做汇报前，最好能把相关的数据拿到手，并且一定要精确，含糊的说辞最容易遭到PK
9）数据最具说服力
以上几点都是在听评审的过程中最受质疑的几点，这对自己以后做技术规划具有参考意义
架构设计评审从哪方面入手？
架构评审
当事人发起架构决策申请
由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至技术委员会解决
在产研中心部门内，或联合 技术委员会，完成架构评审
将结果发还至当事人征询意见
由当事人判断是否仍有疑虑，需要进行架构仲裁
若需要则发起仲裁会，解决分歧；若不需要则结案归档，执行决策
决策流程
产品负责人
技术负责人
架构师团队
架构负责人
部门内协调解决
技术委员会负责人
技术专家
业务专家
如果评审仍有分歧
评审组织
架构决策流程
决策反馈模板
从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
「重要性」的标注是为了提升决策效率；
「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地
模板要求
第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
第四、无论是流程还是表格，都不仅是一样工具，更是一种思维模式，越早养成这种思维模式，对个人成长的帮助越大
推进效果
逻辑清晰、完整，能让他人能够准确理解
让当事人将架构背后的逻辑讲明白
填写标准
这种“外部价值”包括：公司利润、人效、资源利用率、业务风险，等等
1）要学会站在全局视角看待问题，学会看到技术架构的“外部价值”
2）具备相当的技术深度，以及非常好的学习能力和逻辑思维
如何做好决策
架构决策
产品研发思考2023
0 条评论
下一页
