new
This commit is contained in:
@@ -0,0 +1,87 @@
|
||||
---
|
||||
number headings: auto, first-level 2, max 6, 1.1
|
||||
---
|
||||
|
||||
## 1 引入
|
||||
### 1.1 一个敏感的话题：跳槽因为啥？
|
||||
1. 加薪水
|
||||
2. 团队以及个人的提升
|
||||
3. 工作氛围
|
||||
|
||||
## 2 成长
|
||||
### 2.1 个人成长 vs 团队成长
|
||||
|
||||
一个团队里只有头狼非常强，能干啥？
|
||||
头狼需要一个强大的团队，所以正确的成长应该是，团队每一个成员向一个方向共同成长，向一个目标共同努力，大多数人都提升了，这个团队才强大，才能建成养老院。
|
||||
|
||||
### 2.2 主题
|
||||
|
||||
#### 2.2.1 选题基本要求
|
||||
确定主题的过程，应该经过团队集体的参与，这样可以更好把握主题的方向，与团队，项目的发展有一定的关联。
|
||||
为了使团队整体有更多元化的成长方向，主题不限于技术，还可以有产品，运维，学习成长，但要求是必须是团队产品成长过程中衍生的，未来可能需要的，能够促进团队产品发展的。
|
||||
|
||||
#### 2.2.2 主题库
|
||||
基于项目产品的日常工作，产品的发展思路，确定提出主题，加入主题库。
|
||||
考虑我们当前的人员情况是以技术为主，所以前期主题可能以技术研究为主，其他为辅。
|
||||
|
||||
|
||||
### 2.3 方向小组组建
|
||||
按岗位类别划分研究方向，目的还是促进团队的集体成长。
|
||||
|
||||
![[学习成长/学习/团队管理/团队成长/Untitled Diagram.svg]]
|
||||
#### 2.3.1 前端方向
|
||||
组件库
|
||||
|
||||
|
||||
#### 2.3.2 后端方向
|
||||
1. 基础
|
||||
1. 程序单元测试
|
||||
2. java代码规范学习与讨论 - [[《阿里巴巴JAVA开发手册》]]
|
||||
1. 提高
|
||||
1. 日志管理
|
||||
2. 进阶
|
||||
1. 日志分析
|
||||
2. 分布式锁方案与实现
|
||||
3. 程序动态化 - 脚本语言在项目中的应用，脚本引擎lua, groovy。
|
||||
4. 高级
|
||||
1. 深入基于spring cloud的微服务架构
|
||||
2. DDD设计模式
|
||||
|
||||
#### 2.3.3 项目管理与运维方向
|
||||
1. 方法约定
|
||||
1. 服务器管理
|
||||
2. 产品版本管理
|
||||
2. 中小型项目独立运维
|
||||
1. Docker
|
||||
2. Docker Compose
|
||||
3. 大规模集群化运维
|
||||
1. Docker
|
||||
1. Kubernetes
|
||||
1. Helm
|
||||
4. 产品项目打包规范
|
||||
1. 后端服务
|
||||
1. 前端网站
|
||||
1. APP
|
||||
1. 小程序
|
||||
|
||||
#### 2.3.4 测试方向
|
||||
```ad-note
|
||||
```
|
||||
功能测试
|
||||
自动化测试
|
||||
压力测试
|
||||
|
||||
#### 2.3.5 产品研究
|
||||
保险，社区融合
|
||||
智慧成市的产品方向
|
||||
元宇宙
|
||||
区块链
|
||||
|
||||
### 2.4 成果输出
|
||||
博客或沙龙
|
||||
#### 2.4.1 沙龙组织
|
||||
|
||||
|
||||
#### 2.4.2 团队技术博客
|
||||
|
||||
#### 2.4.3 库
|
||||
@@ -0,0 +1,11 @@
|
||||
# 为什么要打造一个学习型团队？
|
||||
## 领导方式？
|
||||
确定目标->拆解->分配，这种领导方式是在摧残人与生俱来的激情，内在动机、自重、尊严，好奇心、学习的快乐。
|
||||
## 学习型的文化
|
||||
团体共同努力下，才会形成文化。即让学习成为一个团队的文化。
|
||||
* 个人学习
|
||||
* 团队学习：在工作中培训，利用集体智慧进行真正的共同思考、共同行动。互相聆听，
|
||||
|
||||
首先给学习型团队做一次解释，
|
||||
|
||||
学习型团队
|
||||
@@ -0,0 +1,30 @@
|
||||
### OKR
|
||||
OKR是一个明确目标，设定目标的方法论。大目标，团队目标，细化到个人，层层向下。
|
||||
OKR （Objectives & Key Results）目标与关键结果管理法，是一种目标管理理念，包括目标和关键结果 2 个部分：
|
||||
|
||||
- 目标 **Objective**，是组织希望在近期实现的、有激励性的目标，也通常是其长期使命与愿景的体现。
|
||||
|
||||
- 关键结果 **Key Result**，是实现目标的关键路径，通过量化的 KR，我们可以判断结果是否达成。
|
||||
明确目标，目标聚焦，执行效率
|
||||
|
||||
|
||||
### 操作流程
|
||||
```mermaid
|
||||
graph LR
|
||||
制定-->跟进-->复盘与打分
|
||||
```
|
||||
|
||||
#### 制定
|
||||
使用 OKR 管理法的的第一步是制定一系列合理的目标（O）与关键结果（KR）。
|
||||
|
||||
制定 OKR 时，团队需要充分讨论，保证所有成员都可以向着同一个目标前进。为了保证团队目标一致，「对齐」至关重要。以个人制定 OKR 为例，员工需要思考自己如何能够为团队目标做出贡献，并初步制定出个人 OKR。
|
||||
|
||||
## 跟进 OKR
|
||||
|
||||
组织的内外部环境不断变化，持续的追踪反馈对 OKR 的实施至关重要。团队可以定期检查目标的完成进度，及时沟通并调整方向。
|
||||
|
||||
## 复盘打分
|
||||
|
||||
在每个 OKR 周期将要结束时，组织、团队和个人需要对 OKR 的完成情况进行复盘并打分。打分时通常要参照 3 个标准，即目标完成程度、目标挑战性和个人努力程度。
|
||||
|
||||
在 OKR 中设定的目标通常是激进的、充满挑战的。如果得分有 0.6-0.7，就已经是不错的表现了。如果得分总是很高，这可能代表 OKR 的制定过于保守，没有起到激励作用。
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
number headings: first-level 3, max 6, 1.1
|
||||
---
|
||||
|
||||
“是拥有目的性和战略性、能够长期保持共同行动的集体。在团队中，成员们需要共同规划，一起解决问题，定期回顾和反省自己的工作情况。与家庭相比，更像是一个运动团队。”
|
||||
摘录来自: 彼得•费利克斯•格日瓦奇. “如何管理10人以下小团队：谷歌核心团队实现10倍速成长的高绩效秘诀（全球人才培养战略资深培训师教你打造媲美谷歌的最强小团队！后浪出品）。” Apple Books.
|
||||
“业绩最终是指“高层经营者的评价”
|
||||
## 团队主要问题
|
||||
### 1 研发
|
||||
#### 1.1 前后端接口对接
|
||||
##### 接口分析
|
||||
接口功能包括
|
||||
1. 基础的业务逻辑
|
||||
2. 部分前端的操作逻辑，如界面显示内容，因状态的不同，显示不同的内容等，需要后端数据的支持
|
||||
3. 前端的调用逻辑，后调用的接口可能对较早调用的接口有参数依赖
|
||||
|
||||
因此，在确认了产品原型后，前后端主要的研发对接人员，应该综合上面3点讨论每一个接口的实现。
|
||||
Reference in New Issue
Block a user