团队管理笔记

管理所学所用

开始接触管理的事务后，大脑的反应就要被迫加快了，思考->逻辑->评价->决策时刻都在发生。初级管理者要事为团队先，承受着更大的压力，自己缓解压力是必要的。害怕源于为无知，压力来自未知，做好明天的计划，活在当下。学习是缓解压力的好办法，首先接受自己的普通和无知，梳理一下自己的压力和焦虑，因为这些问题很可能前人已经经历过，找找相关的书籍，认识到自己的不足并做计划从容的学习。

管理者在不同的阶段下大概可以分为两个方向，且其间常会相扶共存。
领导型：做正确的是，一般在某一领域有一定的影响力，带领大家成长、做事并达成目标
管理型：正确的做事，有权利调控并有能力管理人和事，培养出更厉害的管理者
一般纯管理型管理者是从一个领导型管理者发展过来的，如果不是，这里只能分享一个从领导者在带着大家做事过程中成长并总结出来的管理经验😄。

初级管理者： 刚接触管理方面的工作，从一个人干活到带着大家一起处理更多更完整的事务，实现超过1+1>2的收益。
团队事务： 这里特指前端初级技术管理者需要做的团队事务

• 项目方面：整体项目计划制定、项目需求分析、跟踪进度、评估风险、对产品及运营需求制定技术方案并提出建议，项目推进，评估并协调需要的人力物力成本，推动调度各开发流程中的人力物力资源（scrum敏捷开发，瀑布流等）；
• 业务方面：参与团队上下游业务目标制定，并在团队内主导任务分解和里程碑计划，参与竞品调研分析及自身业务产品数据收集等，对交互设计有一定的理解；
• 技术方面：各项目技术选型、架构设计、发展规划、需求到上线及持续优化的流程和规范制定，技术需求规划及建设，技术分享；
• 人员方面：各成员业务目标设定与定期达成情况，成员个人成长（包括新人培训，站会周会、每周思考总结、技术成长、建立梯队及模块负责人制）规划与定期沟通及其他同级团队的资源福利竞争。
• 整体发展：团队组织架构(根据业务发展在不同的阶段和场景可能需要业务组、架构组、运营组、可视化组等，人不够的时候可以多职，从简到精过渡)；团队经验总结和规范制定（问题复盘、故障处理机制、开发上线流程制定等）；各项目技术选型决策；提升团队整体效率思考（工具建设、技术技能培训、激励活跃气氛、明确目标导向等）；环境等资源协调(开发到上线流程中会涉及到的外部资源使用等)；各种方案积累总结(安全方案、优化方案、稳定性方案等）；团队分享等业务和技术积累；跨部门间的合作协调等；
• 个人成长：自身还有开发任务，各方面知识的成长（熟悉业务、产品、交互、进度管理、技术建设等并做出决策）。

刚开始从核心开发人员到初级管理者，需要处理团队的各方面事情，很多时候不能适应自己不断被压缩的codeing时间，总感觉写码少了就很空很慌，担心自己技术落后等。这里可以推荐一些书籍：《能力陷阱》《黑天鹅》《反脆弱》等书籍，帮助你提升更广阔的的视野，走出恐慌，做出更好的选择。

note: 初级管理也不是一次性做好所有事情，是一个切换8(开发)/2(管理)到8(管理)/2(开发)切换的过程。可能每个人所处的阶段和团队需要不同，比如我现在还是7(管理)/3(开发)。团队事务里面也包括技术方面的思考和开发，所以不要看到一些语法记不清了、写码没有之前熟练了就担心自己会落后。

接下来给大家分享一下我的成长笔记

正念方法

准备阶段

• 安静挺直静坐，放松自然舒适的姿势
• 可以闭眼也可以睁眼
• 肩膀放松，体验臀部与坐垫的接触感
• 感觉这个身体正以这样的姿势坐在这里

觉察阶段

• 开始留意与观察呼吸
• 观察呼吸最明显的位置：鼻腔或者小腹，不要太在意，只是感受它的存在
• 观察一呼一吸及中间交替停止

说明

• 练习的过程中，如果开小差了，观察一下大脑在想什么，然后慢慢的把思绪回到呼吸上来。
• 无论开小差多少次，多么容易走神都不要在意，回过神来后再次关注到呼吸上，不断训练，关注这个过程，走神也是练习过程的一部分，没有关系，不要排挤。
• 无论自己是否有兴趣，是否相信，每天都练习专注呼吸5-15分钟，这个时间就只做一件事，关注自己的呼吸。

现在正念比较火，市面上有相应的书籍或者有声书、公开课等。正念还有包括身体扫描等，但总得来说都是活在当下，同一时间只关注一个很简单普通的事情，多的也做不了，让自己在这个过程中缓解紧张情绪，释放压力。我想数羊助眠也是这个原理，让大脑放空，关注到一个无聊的事情上，然后无聊到大脑什么都不想了，也许就睡着了。有的人数羊也睡不着，可能是数了几只就下来问自己怎么还没睡着，因为一直在想怎么还没睡着越想越烦，然后又来抱怨数羊不能助眠，巴拉巴拉又想一堆，越想越气。这个时候应该向上面说得那样，不要放弃，这些杂念都是正常的，发现偏离在数的羊后，再平静地拉过念头，再去数羊，不要想着别人数一百只就睡着了，自己怎么数了一千只还没睡着，可能数到一千零一只自己就睡着了呢？这都是正常的每个人的羊不一样多，多数数吧。😄

DISC自我认知

每个人的性格和诉求不尽相同，作为初级管理者要开始接触更多的人和事，团队中每个人的性格处事方式以及团队间每个人的也都不尽相同，我们需要知道并接受这个事实，并能站在对方的立场去思考问题，这样不仅能减少不必要的冲突，更能让每个人都得到得到尊重，在最好的状态下合作。

记住一点——你和你的团队成员是使命驱动的合作关系

1. 你们有共同的使命（使命是大家不可抗拒必须做到的，使命是公司及部门共同的目标，在其职干其事也是职业道德，就算食人俸禄就办其事也应该把使命放第一位，作为团队Leader，此时你的威信在于带着团队完成使命，给大家带来的价值体现和提升）；
2. 你要和团队共同成长（你帮助团队成员达成KPI-产出和个人成长，团队成员帮助你达成KPI-团队整体产出和个人成长。团队完成你制定的目标，团队成员达成你俩一起定制的目标，因此你们的关系是双赢的合作双方，只是职责不同，只有互相尊重，不应该也千万没有谁比谁底一等的想法，就算你年长也不应该有。很多初级管理者容易飘，感觉自己当了领导，什么都别别人强，但实际可能只是在某一些方面相对好一些，比如某一方向技术、对公司文化了解多一些。作为团队Leader，此时你的你的威信在于你能带着大家实现目标及成长，给业务和团队带来价值提升）；
3. 合作关系无论团队成员在职离职，你们的关系都是互惠互利合作过的朋友，某些原因不能在这里合作了就分开，有机会合作再聚集起来。（合作关系式的上下级关系可能在互联网这种快速发展和高强度的工作环境更加普遍与切合。作为团队Leader，此时你的威信在于团队成员可能因为某些原因离职了，但还是愿意与你合作，或作为长期朋友）。

D(Dominance) 支配型

人物画像

• 不喜欢被控制、监督，渴望获得成果，业绩
• 大胆，爱冒险，有野心，喜欢有挑战的机遇和工作，常常承担较大的任务
• 有前瞻性，独立工作，喜欢新鲜，善于创新和革新，开创局面
• 喜欢进行谈判和协商，表达自己，自信，直接果断
• 强势，好侵略，喜欢命令和指导别人

需要提升

• 要善于倾听，富有同理心，和别人咨询式的交流，不要太强势
• 要富有耐心，成为团队一员
• 要制定适度的目标，贯彻始终
• 要关注细节

怎么合作

• 不要给太细致的工作和规章制度，让他们自己发现问题
• 专注于业务
• 就事论事不谈感情，敞开谈判，协商
• 不要直接发号施令
• 不要安排耗时太久的事务

I(Influential) 影响型

人物画像

• 喜欢言论自由，得到心灵收获
• 乐观，热情，有魅力，自信，有说服力
• 对成就的认可
• 与人互动，建立关系，激励他人，在组织中的有威望，令人信服，受欢迎的，团队合作者，

需要提升

• 要控制好情感，要更客观
• 要更注重细节，更严肃，更加寻根究底
• 要自我提高，能够按时完成任务，贯彻始终

怎么合作

• 和他们谈论意见和看法
• 询问他们的感觉
• 记录共识之处
• 尽量认可他们的想法
• 建立关系
• 不要与之争论
• 不要太客观的就事论事，要照顾到对方情感
• 不要伤害他们的尊严和在大家面前价值感

S(Steadiness) 稳定型

人物画像

• 摆脱压力和紧张的工作期限，倾向体制和程序流程化的，稳定和放松的工作环境
• 有耐性并贯彻到底的专业工作
• 友善，善于倾听，善解人意，乐于助人，真诚，团队一员

需要提升

• 不要害怕争论和变化，更快适应变化
• 加快节奏，应付更多任务
• 摆脱流程化，主动开创

怎么合作

• 坚持平稳的节奏，提供保障稳定的环境
• 提出问题并倾听
• 对他们个人做的事表示兴趣，支持他们的观点
• 要贯彻始终，不要经常变革
• 不要催促他们

C(Compliance) 遵从型

人物画像

• 遵从制度，遵从事实，客观，谨慎，准确，严谨，喜欢秩序井然的环境，不喜欢开放式的指令
• 技术好，专业化，高标准，高精确度的工作
• 挑剔，紧张，大惊小怪，常陷于细节，钻牛角尖

需要提升

• 从全局把握问题，独立性
• 减除不必要的细节提高效率
• 直接了当的处理冲突

怎么合作

• 提供系统，有组织性的团队环境
• 列举事情的优缺点，提供证据
• 指示尽量书面化，有对应的细节要求1、2、3，不能太概况
• 不要催促他们

沟通表达

沟通的目的是更好的达成目标。

金字塔式表达

定义： 金字塔式表达是一种重点突出、逻辑清晰、主次分明的逻辑思路、表达方式。
金字塔的基本结构是： 结论先行，以上统下，中心思想明确，归类分组，逻辑递进。先重要后次要，先全局后细节，先结论后原因，先结果后过程。
金字塔式表达训练表达者：

• 关注、挖掘受众的意图、需求、利益点、关注点、兴趣点和兴奋点，想清内容说什么、怎么说，掌握表达的标准结构和规范。
• 突出重点，思路清晰，主次分明，让受众有兴趣、能理解、能接受、记得住。
• 自上而下表达，自下而上思考，纵向疑问回答/总结概括，横向归类分组/演绎归纳，序言讲故事，标题提炼思想精华

关键对话

什么是关键对话，在与对方有利益冲突、产生对立，也就是沟通不清楚就会造成什么不好的后果的对话场景。

CRIB（Commit Recognize Invent Brainstorm）

1. Commit 寻找并确定共同目标
   • 第一步就是要打破僵局（我们一直这样各执己见是行不通的；我们好像进入了一个死胡同，我们的目标是达成某一目的），提出要找到双方共同关注的目标；
   • 明确指出你们是寻求共同目标。(a.我是来帮助你达成这个目标的，我不是你的对立方; b.即使是利益冲突双方，要寻求共同受益的目标，客观的说我们任何一方也要完成某事拿到结果才能获益)。
2. Recognize 识别方法背后的目标
   • 找到对方谈话的真实目的，可能有些话不好直说，需要通过一些引导（a.跟我谈谈你为什么会提起这个话题；b.你为什么想这样做）；
   • 了解真实意图后我们关系从争执到为了达成共同目标而努力。
3. Invent 创建一个共同目标
   • 如果两个人的目标不一致，要尝试寻求双赢的折中，以达成各自的目的。
4. Brainstorm 头脑风暴寻找新的方法
   • 可以从时间维度做更长远的打算（这次我们先这样，下次我们还合作，寻求更大的利益，多一个朋友总比多一个敌人好）；
   • 这时候你们可能还可以憧憬美好的未来。

FFIA（Fact Feeling Influence Ask）

分享你的事实->说出你的观点和感受->影响和结果->询问对方的想法

1. Fact 分享你的事实
   • 用自己已掌握的事实作为开场（a.我们最经多次谈到这件事；b.我发现…；c.我应该…但是…）
   • 描述客观事实和你预期结果的差距，增强谈话的清晰度和指向性
2. Feeling 说出你的观点和感受
   • 说出事实后，下一步就是说出对这个事实的感受，表明有了这个事实才会有这样的感觉。（a.这件事让我感到…;b.由此我认为…，有理有据，对方想反驳心理也会开始反思）
3. Influence 影响和结果
   • 说出这样做对其他人，对团队整体的影响（a.这样让其他同事怎么想；b.这样让这个项目怎么进行下去）
4. Ask 询问对方的想法
   • 询问对方的想法和观点（很多时候一个人陷入某一个想法是想不到其他方法的，比如邓宁·布鲁克效应，知识点不足或认识缺陷的时候是辨别不到自己的错误的，并不是他们没有思考，就像在学数字从0-9，只学了0-8的人可能组合出10，333，887654321，…但永远不知道9的存在。0-9的数字比较基础，换个例子，是否还记得在没有学十六进制的时候你不知道0xA-F的数怎么表示）。
   • 保持谦逊，有效询问（a.你怎么看;b.你能帮我看看还有其他的解释吗;c.你的建议或意见），不要带观点的压迫式反问（a.难道不是这样;b.没人反对吧;c.我要怎么做你才能…）

AMPP（Ask Mirror Paraphrase Prime）

1. Ask 询问分享
   • 通过询问打破僵局
   • 你的真诚或许会让对方不显得太过对立（沉默或暴力反抗）
   • 方法有效则继续询问提起兴趣，缓和气氛
2. Mirror 映射确认感受
   • 询问过程中如果对方做出各种反应，可以反应给对方（a.听你的意思，你很看重这件事;b.看你不说话，你有些担心;c.听你的语气，你很不开心;）只描述反映，不作提问。
3. Paraphrase 复述
   • 时时对齐双方理解是否正确，鼓励对方继续表达
   • 你的复述给对方感到你的尊重，和对这件事的关注
   • 用自己的话复述，证明你真的理解了对方说的事情
4. Prime 推测
   • 在没有进展时推测对方的语义
   • 语气要真诚，让对方知道你只是在推测并非定论，对方可以随时打断你，并吸引对方进入你的话题，达到打破僵局开始沟通的目的（a.我理解你只是想要的到更多的支持;b.你的意思是需要我帮助…;c.我理解你想表达有更好的方案;）

总结一下，我们就是要从心开始，打破僵局，求同存异，找到共同目标，确定目标并开始行动。

目标管理

出发点：对结果和过程的控制
实质：

• 以结果为导向
• 目标和过程见得关系
• 发挥主动性，帮助团队成员成长，授权与目标达成获得成就感

PDCA (Plan Do Check Act)

1. Plan 计划
   • 制定目标和规划
2. Do 执行
   • 观察和记录计划的运作情况
   • 过程中的指导与反馈
3. Check 检查
   • 年度或季度评测反馈
   • 总结执行结果，明确完成情况，找出问题
4. Act 处理
   • 对成功的经验加以肯定和分享，对失败的要复盘思考，制定改进计划

向上管理

管理不仅要管理好下属，也要管理好上司。传统观念管理就是自上而下的，甚至有的认为向上管理是巴结、唯上的行为。大部分情况下我们和我们的领导都是在为公司效力，公司要为用户为社会负责，因此你和你的上司最根本还有合作关系，合作是为公司为社会负责也是对自己负责。向上管理也是让你配合你的上司取得更好的产出成效，共同提升。

向上管理的几个要点

1. 正确认识上下级关系
   • 上司是组织选的不是你选的，是我们适应上司而不是上司适应我们，建立和谐的上下级关系
   • 了解上司的DISC（见上面）性格特征
   • 了解上司的处境和要做的事（期望目标）
   • 你让上司卓有成效，他也会回报你成效
   • 跳槽除外，以上非极端情况总要面对的
2. 做好自己的工作
   • 有原则的去工作：敬业（干就好好干，能者多劳，永远比别人多做一点）、请示（任何时候都不要剥夺上司决策的权力）、服从（一般情况下先保证服从，上司的信任从服从那一刻开始）、沟通（完整的沟通包括发送、接受、反馈）、相依（和上司建立优势互补，你是有用的同事也能从中学习成长）、奖罚（有担当，敢于承担责任，SS有功欣然领赏，有过坦然补救和改过）
   • 做到五位一体法则：定位（知道自己该做什么，不该做什么）、到位（把工作做到位或超出预期）、站位（不是站队，是在什么位置就要干好这个位置的事再考虑其他的）、换位（懂得站在他人的角度思考问题）、补位（哪里需要就在哪里）
3. 配合提升（正确的汇报工作）
   • 建立机制、主动汇报（不做透明人）、准备充分（举证材料和备选方案）、中途汇报（让上司随时掌握你的动态，不至于风险失控）、把握轻重（坏消息要早说）、掌握分寸（不要擅自决策）、不要越权（不要越级汇报）、保持沟通（让上司知道你是可以沟通的，沟通可以试探自己的授权，主动沟通还可能获得先机，让上司了解更多，获得信任和更多信息，同时帮助上司做决策）
   • 怎么说：理清思路（任务、内容、重点、逻辑、方式、场合、时间、状态、可能性）、结论先行、突出重点（根清重要和紧急）、简明扼要（三句话总结）、数据说话
   • 怎么听：洗耳恭听（空杯学习心态，不要急着打断）、复述要点（复述表示自己听懂了，对方说了结论可以补充一个例子，说了一个例子可以总结自己的感受）、

---

项目管理

瀑布流开发模型

是一种预见性的开发流程，需要前期对产品需求分析透彻，对软件精细设计。严格遵从预设的过程扭转导致开发自由度较低，不便于需求变更。包括以下步骤：

1. 需求分析 产出需求文档PRD；
2. 概要设计 产出概要设计文档，包括但不限于业务流程图，将使用到的技术，系统要求等；
3. 详细设计 产出详细设计文档，包括类图，构件图，活动图，时序图，伪代码等；
4. 编码 产出经过单元测试的各功能模块代码
5. 集成 产出整个系统可运行版本
6. 测试 产出测试计划，测试用例，测试报告等
7. 上线及维护

迭代增量式开发模型

将一个较大的项目拆分成一系列短小且固定的项目，即每次实现产品的一部分功能，逐一迭代完成。相比于瀑布流模型，降低了开发风险，持续集成和测试也降低了系统出问题的风险，前面的功能能较早的交付并得到反馈，同时降低了需求变更带来的项目周期影响。

螺旋开发模型

核心就是不需要一开始就把所有需求和设计都搞得清清楚楚，抓最重要的功能，实现它，然后听取需求方反馈，再进入下一次迭代。

1. 制定计划 需求分析、技术选型并制定开发计划
2. 风险分析 识别和消除需求变更、技术选型、代码问题、人力项目进度等带来的风险
3. 开发阶段
4. 用户校验

敏捷开发模型 (Agile software development)

相对于瀑布流的开发流程，敏捷开发更强调团队开发成员与产品业务方见得紧密协作，面对面沟通，这比瀑布流的书面文档更有效。频繁的迭代交付新的版本，紧凑而自我组织型的项目团队更能很好的适应需求的变化，更注重开发中人的作用。

特点

• 即时交流，弄清需求，个体和互动高于流程和工具
• 方案Demo，立即体验，工作的软件高于详尽的文档
• 实时预览，及时反馈，客户合作高于合同谈判
• 快速迭代，版本交付，响应变化高于遵循计划

技术关键词
快速迭代、持续集成(CI CD AutoOps)、自动化构建部署、自动化单元测试、设计模式、代码重构

Scrum

scrum是敏捷开发方法的一种，包括一系列过程和角色，用于迭代式增量软件开发过程。每一次迭代有一定的时间期限和明确需求清单，如每次发版一般有固定的时间及迭代需求。提倡项目组所有成员坐在一起，进行及时沟通，强调个体互动高于流程文档。承认问题无法完全理解或定义，进而关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

主要角色包括：

• Scrum Master: PMO，项目负责人，进度推进，风险预警，对结果负责；
• 产品负责人: 需求方或需求直接对接人，确定产品的方向和愿景，定义并及时同步产品的内容给开发人员、优先级及交付时间；
• 软件开发人员: 包括前后端各职能开发人员及设计师等（一般10人以下的开发小组）。

过程：（包括但不限于）

• 需求功能清单: 每次迭代的需求列表，Wiki、Word…
• 冲刺燃尽图: 一个公开的项目完成图，JIRA…
• 会议: 需求评审会(1-2h每次，较大变动或前期需求评审) 每日站会（15min内，昨天完成的，遇到的问题，今天要完成的），项目总结会（2h左右，每个迭代周期结束后复盘项目中的问题和总结经验）
• 节点: 预发（预发环境，团队内部人员较正式的使用）、内侧（正式环境，较大范围内部人员较正式的使用）、公测（或灰度，正式环境，需求用户参与使用提供反馈机制）、正式开放上线