产品设计

一切商业的本质是需求，互联网的核心是解决效率问题。

产品价值

产品价值 = 用户规模 * 使用时长 * 使用频次 * 花费金额

产品目标

目标用户、市场规模、竞争对手、竞争优势

竞争优势

• 成本优势（运营广告成本、传播成本、迁移成本[ToB，微信]）
• 无形资产（品牌、专利、政府资源）- 创新程度（iphone，外卖）

垄断产品特征

• 免费
• 用户关联（微信）
• 流程简单（越复杂越重的业务越不能达到垄断）

产品方法论

数据分析驱动决策、假设检验、AB-Test

管理技能

作为一个管理者，公司希望是能够提升收益（开源）和提升效率（节流）。具体的就是管事理人。管理者需要具备的特征：

• 激情：领导力，拥有感染他人鼓励他人的能力
• 人才：怎么培养人，怎么把人凝聚在一起
• 好学：拥有极强的学习能力
• 产品：理解产品和业务，自己要去用产品，分析Case。一个Leader应该是最理解业务的人，这是能创造收益的事情。
• 开放：能够和别人交流沟通，学习他人，共同成长。不要固步自封，有什么就要说出来。

管事

事情优先级：根据四个象限决定事情的优先级。
项目管理：收益+成本+进度+风险。推动事情的进展

理人

管理人里面最重要的是能够站在对方的角度，关注对方的成长。主要的几个技能是：

• 招人：招来价值观有能力的人，关注候选人的好奇心+学习能力+总结能力。
• 识人：发现对方的优点。按能力和意愿分为四个象限，没能力不愿意干活的是要剔除出去的，没能力愿意干活的是可以考虑留下的，有能力愿意干活，有能力不愿意干活。
• 用人：扬长避短，发挥每个人的优点
• 养人：关注对方的成长
• 留人：给每个人找到他的位置，给他最大的空间，leader需要为底下员工着想。

成长

• 技术：个人技术进步和团队整体的技术进步，开技术学习班。
• 业务：团队业务未来的发展，需要leader想清楚，这是最重要的。
• 向上沟通：老大给的任务，做什么，为什么做。定期同步给老大进展。跟老大要资源。把老大当做一个投资人，提老板解决问题。
• 横向沟通：跨团队合作，找到共同利益，换位思考，人脉建设，如果找不到跪舔。
• 向下沟通：团队建设，团队凝聚力、团队稳定性、团队人才发展，团队效率。

业务流程

对于一个技术管理者来说，最重要的目标是为公司创造收益（开源）和提升效率（节流）。业务流程梳理是提升效率的核心。

统一开发规范

• 统一命名规范：保证应用名模块、目录、类、方法、变量等拥有统一的命名规范，方便其他人查看或CodeReview
• 统一IDE代码模板，格式化统一。
• Maven使用规范：二方库、三方库的版本统一定义到parent pom中，业务都依赖parent pom。版本统一
• 代码Commit规范：生成统一Commit-Log，比如[Infra][Suggest][Data-Streaming][Tested] title，describe，test等
• 统一API规范：rpc接口：success，errorCode，errorMsg。Http Rest接口类似
• 异常处理规范：直接返回、抛出异常、重试处理、熔断处理、降级处理
• 分支开发规范：master，分支名字规范（用户名开头）， 单元测试流程（覆盖率超过75%），merge request流程（gitlab），提测流程（CodeReview），上线流程（Jenkins持续集成，Dev、Staging、Dark-canary、Canary、Prod），hotfix流程
• 统一日志规范：日志级别，记录上下文（traceid，用户id，订单id，关键数据）等
• 统一工具和框架：mybait（类似hibernate）， jetcache（本地cache），http-client组件，抽取全局唯一ID，分布式锁，幂等公共组件等

统一开发流程

我们目前主要在用的是瀑布模型。需求评审、测试用例评审、技术架构评审、开发与测试，验证与上线，jenkins持续集成。

需求管理

撰写需求文档和写测试用例，使用jira管理需求

架构评审

评审架构的合理性和扩展性，避免过度设计，包括但不限于架构设计、测试方案、监控方案、报警方案等。架构设计从架构的五个特性看：正确性，高性能，高可用，可扩展性，安全性

• 技术选型：组件选择对比，方案对比（资源占用，耗时，可支撑的QPS，机器）
• 高性能：目前的QPS，TPS，耗时是多少？随着业务的增加是否有突发性能抗压的能力?如何实现高性能?
• 高可用：单点故障，多活，数据丢失和恢复，宕机补救方案，主要是容错性。
• 可扩展性：随着业务的发展，在架构扩展性上怎么支持业务
• 可伸缩性：扩容方案，手动或者自动，怎么横向扩展
• 弹性处理：消息、接口重复处理是否导致幂等，服务自动降级，哪些业务降级，熔断策略，限流，熔断对用户的影响，服务是否做了隔离，是否会影响全局
• 兼容性：上下游梳理，新老系统的切换，升级方案，通知上下游
• 安全性：SQL注入和XSS攻击，是否有数据泄露的风险，怎么防刷，日志统计，数据是否加密传输，密码是否明文
• 可测性：测试环境和线上环境差异？怎么做压测？怎么做单元测试和模块测试？
• 可运维性：上线前是否需要预热？业务是否需要归档处理？上线后需要怎么维护服务？
• 监控和报警: 对外依赖接口是否添加了监控和报警？应用层面的内部代码是否添加了监控和报警？系统层面的组件是否有监控和报警？

详细设计文档

代码评审

主要关注可测性、可读性、可理解性、容辨性。具体关注的内容包括：编码规范，潜在bug，文档和注释，重复bug，复杂度，监控和报警，测试覆盖率

发布计划评审

评审上线流程，看看有没有疏漏的地方。

项目管理

项目管理的核心是为达目标不择手段。主要关注：收益+成本+进度+风险。使用每天站会的方法同步风险和进度。项目管理工具jira管理每个需求的进度。

技术规划

作为一名技术管理者，需要提前做技术储备。除了产品需求以外，还需要做自己的技术规划。技术团队主要目标是服务质量、运营成本、开发效率。

服务质量

• 定期做系统健康度巡查。机器各个指标，接口各个指标是否正常，保证服务质量。必要时刻放一把火 Chaos_Monkey。
• 弹性和可靠性：从数据一致性，幂等，防重攻击，熔断，异地多活、降级、SLA方面去想。保证极端情况下的服务质量。
• 可伸缩：快速扩容

运营成本

• 性能优化

开发效率

• 架构优化：解除系统之间的耦合，遵从微服务的开发原则，服务单一职责等