2021-07-06 技术管理

什么是软件架构？软件架构应该包括哪些主要内容（或软件架构应该描述哪些问题）？
答：软件架构是软件的结构以及各组成成分(子系统或模块)之间的相互关系；其主要内容包括：1、设计软件系统结构(软件结构) ；2、用户界面及数据库设计；3、编写概要设计文档 (1)概要设计说明书。(2)数据库设计说明书。(3)用户手册。(4)修订测试计划。4、评审

程序员、技术主管、架构师的区别：
程序员：代码设计、代码实现、代码评审
技术主管： 研发任务管理（工作量评估、排期；工作分解、分配；风险识别）
技术技能提升（代码规范制度和推广、生产力工具研发和推广、最佳实践总结和推广）
架构师：关键数据决策;系统设计、抽象、封装;技术蓝图
技术管理最重要的两个任务：
完成工作目标.
培养下属.

技术管理者需要为团队成员服务，有人需要资源就给协调资源，有人不明白目标就帮助他明确目标并制定其个人目标，
不同的模块间接口无法确认就组织相关人员讨论，xxx任务完成的好就给予明确肯定，
xxx所从事的技术方向迷茫就协助找到发展方向，
有人突然情绪低落效率低下及时发现背后的原因并在必要时提供支持… …(感觉是不是像保姆)

影响力的六大原则也是应该知晓的：互惠原则，承诺一致，社会认同，喜好，权威，稀缺

激励别人无非就两个因素（基础因素与动力因素）：
基础因素：（薪水、工作条件、环境、地位等）
动力因素：（挑战性、成长、成就、认可等）

技术管理者还需要几点，以身作则，勇于承担责任，共情能力，时刻牢记公司，团队，项目目标，情绪控制，不传递负能量，不耻于下问 ，复盘 等等.(慢慢改变吧!!!)

技术提升：
1.学习的东西需要进行检索
2.穿插练习，有助长期记忆.
3.反思是检索的一种
结论：平时可以尝试技术分享，讲解给别人听，重构代码，严格要求自己，写DEMO，或者自己写一个小项目等等来检索或者练习
自己学习的设计模式，性能优化，自定义view，动画等等知识点，有问题的再重点去学习，掌握. 后续也可以进行一些总结，反思，优化；

OKR目标管理学习：
平时很忙如何学习，建议做好年计划(列出目标与关键结果)，分解为月计划，再细致分解到周计划，然后每周或者每个月检查成果.
习惯养成指南：
找到内在驱动力、降低改变的难度、让改变可视化、奖励、允许例外
提升途径：
参与开源项目、写博客、迭代重构

阅读优秀源码，不只是单单阅读，要理解别人为何这么做，要是你做会如何做，最后可以尝试自己写一个类似的检索与练习下.
用指标严格要求自己: 代码风格，内存，CPU，APP大小等等优化，交付时间，BUG率，冒烟测试通过率等等
讲给别人听，就是可以做一些分享，或者平时解决问题，能不能说明白原理，眼睛过的，不代表你真的懂.

避免能力陷阱：

做的越多就越擅长，越擅长就越愿意去做。这就容易被你当前的状态所局限。
这样的一个循环能让我们在这方面获得更多的经验，但却容易陷入能力陷阱，在其他方面无法突破。

项目管理：
如何分配任务，跟踪进度，沟通，等等，是一个刚进入 技术管理者 应该必备的技能.
按照公司，团队 实际情况，合理应用项目管理手段（比如敏捷，瀑布等等）.
在开发前，建议项目的团队成员需要知道任务的优先级，尤其是多任务并行的时候.
也可以善用清单 对于项目各个环节进行把控检查.

3.1 技术管理者进行项目管理主要解决几个问题

建议拿到或者讨论 项目或者需求，第一件需要做的事情就是技术可行性评估.
项目或者需求，我感觉执行应该符合 Smart原则.
各个项目需要分清 轻重缓急.

先不要急着给出承诺以及开发计划，先了解几个方面：

背景了解一下，为什么做这个事情，解决什么问题，目的不明确的不接.
做哪些东西，具体的需求内容，不知道具体内容的，不接.
最傻屌的需求举例：做一个聊天软件，我做你TMD，聊天有那些具体需求内容哈，范围那么大！！！
邮件需要发出来(至少你的上级应该知道这件事情)，还要有需求规格文档等等.
还要了解他们是否已经需求，设计 评审过，没有评审，尽量不要接.

3.1.1 任务分解

任务分解需要搞清楚几件事情：

做成什么样子，demo? 提测？发出去的版本？问清楚才能开始做任务分解，因为影响开发的时间以及质量问题.
什么时间完成，截止日期，没有具体的截止日期不做. (影响 质量，开发的时间，排期等等，需要根据具体的开发周期商讨磨合)
资源是否到位(设计，测试，其它部门，外部 协助等等)，协调资源.

顾名思义，就是将一个项目分解成N个小任务，参考敏捷开发的需求池概念。
开发任务分解(将一个或者多个需求分解成几个开发任务)，定人，定时间(开发周期)。
技术选型(适配分辨率，Rxjava，网络请求库等等)，架构，技术难点，风险 需要暴露出来，包括选用新技术也需要考虑几个方面(学习，招聘，时间，机会成本，风险也需要考虑).

比如，开发一款影视工具，有影视搜索，影视详情等等. 影视详情可以分解出很多小任务或者实际的开发任务(API接口 2天，界面 3天，逻辑代码1天，设计资源 等等)

1.对于需要使用的新技术，要估算学习和调研的时间。
2.我们需要编写什么样的接口？
3.我们需要创建什么样的架构？
4.我们需要更新哪些表？
5.我们需要更新或是编写哪些组件？
6.根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。
7.对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。

3.1.2 任务分配问题

注意几点：

不要担心别人做不好，学会授权，辅助培养.
多给别人选择的机会.

也可以尝试改善分配工作的方式：所有任务列出来，然后进行分配(每个人从任务池挑选适合自己的，自己想做的)

3.1.3 进度跟踪

不是安排了开发任务就放任不管了，需要进行进度跟踪。
可以 每天的站会 也 可以单独的沟通，主要是为了 提前发现问题，对 进度，风险把控。

会需要关注的3个问题：

昨天做了什么？
今天准备做什么？
需要哪些同事配合或遇到什么困难？

站会注意事项：

避免讨论具体问题，会议后私下讨论。
时间最好为5~15分钟之内。

站会只是提了一个方式，根据实际情况而定，如果大家都加班到了10点，你还一大早9点开站会或者开会同步问题，我想大家心里一定是TMD的，换位思考，共情下.

3.1.4 多任务并行如何处理

将所有的需求列入需求池，按照每周的开发计划来，不急就排到下周或者下下周，排期.
如果真的很急，那就找上上级以及相关人员商讨，任务的优先级，看看那些需要扔出来的.
比如 有需求 A1, A2, B1, B2 正常弄，中间插入 C1，说的很急，必须这周完成，那么找上上级以及相关人员商讨，如果B2优先级不高，那就排到下周去.
多任务并行需要考虑优先级，人力资源等等问题.

4. 目标管理

作为技术管理，一定要确保团队目标与公司目标一致、个人目标与团队目标一致，只有这样，才能产生协力，有效实现预期。
让每个人都有参与感(共同制定团队目标和个人目标. 让员工参与到上层目标分解到团队目标，团队目标分解到个人目标的过程)
三种目标(公司目标，团队目标，个人目标)[必须符合Smart原则]
团队，公司，个人目标一致，才能产生协力，有效实现预期.
要将团队成员的个人目标与团队相结合，就必须理解下属的痛苦，快乐，为何在这里工作等，
针对每个具体的个人来考虑团队目标对于他个人的意义.

Smart原则：
specific: 目标一定要明确，不能模糊
measurealbe: 目标的可衡量性，是否有一个实现目标的标准
attainable: 目标的可实现性，一个目标必须实现，或经过努力是可以实现
relevant: 目标必须和其他目标有相关性，完成这个目标对你的其他目标有何帮助？
timed-based: 目标必须有明确的截止时间，一个目标在一定时间内达成才有意义。

OKR(“O”就是目标，—Objectives，“kr”即关键结果——Key Results)

比如定了目标，提升团队的10%效率，关键结果 有 公共库，统一开发环境等等.

5. 时间管理

按优先度排级 四象限法则：
第一象限： 重要紧急
第二象限： 重要不紧急（项目计划、团队建设等）
第三象限： 不重要不紧急
第四象限： 不重要但基金

6. 压力管理
   发泄、换角度、暂停

7.冲突管理
竞争、回避、退让、妥协、合作

8.沟通
沟通 是 无论技术人员，还是技术管理者，都应该必备的被动技能
有效的反馈机制：
自我评估：项目评估，关键目标分析.
下属的反馈：一对一沟通，周期性会议
同级的反馈：一对一谈话，邮件等.(同级可以是其它部门负责人，比如测试，产品等)
上级的反馈： 主动，持续，周期性的让上级给你反馈.
结论：向他人收集反馈，事先准备话题列表，提高沟通效率. 收集反馈信息后，进一笔分析，分出正面，负面. 只有将反馈与经历结合，炼化成经验和教训，才能指导后续的行动，不断进步.
8.1 沟通的几个要素
循环沟通4步骤： 学会倾听、澄清自己的理解、提出自己的观点、确认对方了解自己的观点
情绪管控、保持信息一致性、同理心（换位思考）
沟通的三大要素： 指定明确目标、达成一致结论 、语言和非语言结合
1.沟通应该形成闭环
2.沟通最重要的环节，倾听，第一，体现对对方的尊重；第二，通过聆听别人把话讲完、讲透，更容易理解别人所要表达的真正含义。有效聆听才是沟通中最为重要的。
3.还有最后一个，需要注意，情绪的控制，一切的沟通是围绕解决问题的，不是争吵，更不是抵触情绪，会给别人留下不好合作的印象.

8.2 作为技术管理者，日常的沟通分为几种
8.2.1 向上沟通

向上管理以及沟通搞清楚几个问题：

表现符合上司的期待吗？
上司信任你吗？
了解上司的管理风格吗？
上司有那些优点吗？
了解自己的需求与期待吗？
与上司讨论过自己的职业生涯规划吗？
了解上司的文化背景吗？
适应于多为上司共事吗？

需要做到的几件事情：

喜欢你的上级，不要抱怨或者恨他，至少要理解他。积极配合老板完成工作。
了解上级的处境，为他排除万难，助他一臂之力，让你的老板工作更有成效。
把上级当成鲜活的个体，摸透老板偏好的工作习惯，向老板的习惯靠拢。
了解上级的强项和弱点，代替老板完成他不擅长的，无法照顾到的或者不愿意做的工作。
让上级知道你打算做什么，不打算做什么，正在忙什么，目前处于什么状态。主动反馈。
珍惜老板的时间和资源，不要用琐事耗尽老板的时间和经历。
管理双方的预期和目标。上级每年，每季度都会对你又期望。主动沟通，及时反馈，避免造成上级对你的期望和你自己的期望有偏差。

原则：将事情做好为出发点与上司沟通；注意力放在积极寻找解决方案上（多提方案，少提困难）；
主动，持续，周期性的让上级给你反馈，定期和上级沟通，了解他对你的评价，聆听他的建议（一方面汇报自己的工作，让他知道你的状态，另一方面管理过程遇到的困惑抛出来，请他指点下）.

8.2.2 横向沟通
原则：用宽大的胸怀与平级沟通、助人就是助己；
要领：用感恩的心态对待平级给自己的帮助、建议或批评；体谅他人的难处；平时多建立联系；

8.2.3 向下沟通

其实，对待技术人员最要紧的两个字就是——尊重。
如果我们能给他们足够的尊重，他们就一定会配合我们的工作.(其实无论是技术人员，还是其它人，我们都应该尊重别人)
多和下属沟通交流，了解他的生活，工作，真正地关注，关心，倾听对方。（比如聊房子，车子，房贷，喜欢的球星，游戏等等）
原则：采用适合下属的语言，尊重下属的人格、换位思考、多聆听
要领：关心下属的角度出发、目的是协助下属解决遇到的问题和帮助他们成长、就事论事、不翻旧账

可以定期进行一对一的沟通，回避与下属的沟通，就是放弃了彼此了解，建议信任的机会，团队会越来越消极… …
一对一沟通，首先对话前问自己（来自关键对话）：
希望为自己实现什么目标、 希望为对方实现什么目标、希望为我们之间的关系实现什么目标、要实现这些目标，自己该怎么做？

参考谈话过程：
1.开始时阐明目的，为沟通定调：比如，“今天想请你帮忙我，我这段时间管理上做的事情有什么效果”。“和你谈谈最近的工作结果，一起讨论下一步工作安排”。等等
2.分享事实经过和你的想法：比如，“月初引入每日站会… …担心给大家带来负担，因此想…” 。
3.征询对方的观点，鼓励对方做出尝试：比如，“我想知道你对这件事的看法”。“我希望听你坦诚地讲讲发生了什么事情”。征询对方观点，多用开放式问题。

8.2.4 其它沟通(外部客户或其他合作单位的沟通)
要领： 避免自己观点强加于对方、用我们的心态来解决合作过程中遇到的问题、因势利导，尽量不要触碰到底线