个人管理经验总结

发表于 |
  • 情商、基于别人的角度思考
  1. 以身作则
  2. 技术功底，才能令人信服
  3. 保证成员 免干扰、休息时间如无必要不打扰
  4. 情商，基于别人角度考虑
  5. 真诚、谦虚、透明
  1. 避免用“以为”作为借口，基于“对方角度”、“将心比心”的方式，思考问题；
  2. “将心比心”的方式不奏效？一般大公司都追求一定的人才密集性，基本不会出现这个问题；
  3. 注重沟通的有效性（阐述事情的上下文），避免浪费双方的时间；
  4. 正在靠谱的人，当离职的时候，基本不需要什么交接，现有的文档修修补补即可，因为平时善于同步团队信息和分享。做到了可替代性很强，同时“不可替代性”很强。

《技术领导力：程序员如何才能带团队 》- 周明耀 - 总结

  1. 技术管理，技术在前，管理在后。一个技术从业者，核心竞争力是技术能力。技术管理最大的特性是表率，是感染力。
  2. 管理看起来套路很多，其实最终都是人性和策略，理解人性，善用策略，就能做好管理。对于聪明人来说，有实践机会，管理可以在短时间内达到一个不错的水准，但技术永远需要长时间积累。
  3. 很多技术领导带团队取得了一点成绩，就开始沾沾自喜，以为这事离了自己不行，其实是团队作战的功劳。大部分情况下，不是团队离不开领导，而是你离不开你的团队！
  4. 作为技术管理者，需要持续保持自己的技术能力，需要不断强化自己的管理能力和方方面面的综合性能力
  5. 只有做好当前的事情，你才有资格谈技术理想
  6. 在软件行业，没有在专业上的持续学习和成长，是不会成功的。技术变革如此迅速，如果不坚持学习，可能大学毕业几年后就被淘汰了。在不断更新的软件开发行业中，这并不意味着你不需要使用大学里学习的知识，而是除此外还需要不断地增加对新的技术、工具、方法、框架的深度认识和理解。
  7. 做好自己。- And now, as I lie on my deathbed, I suddenly realize:If I had only changed myself first, then by example I would have changed my family.From their inspiration and encouragement, I would then have been able to better my country, and who knows, I may have even changed the world.如果一开始我仅仅去改变我自己，然后作为一个榜样，我可能改变我的家庭；在家人的帮助和鼓励下，我可能为国家做一些事情。然后谁知道呢？我甚至可能改变这个世界。
  8. 在做这些决定之前，有没有做足充分的技术调研、产品调研工作，能不能尽量详细地说清楚已有框架、产品的实现原理、优缺点、是否适用于你的产品场景等，这些都是前期技术调研的工作，也是体现我们脚踏实地做事的一个环节。
  9. 一个人的逻辑能力属于软实力，它是决定你是否可以承担团队领导职责的关键因素。
  10. 举事以为人者，众助之；举事以自为者，众去之。
  11. “平时的艰苦训练是战时胜利的保证，这才是对士兵的最大仁慈。我是一个很坏的家伙。我要让他们尝试每一分钟的地狱生活，然后我又为他们痛哭！”
  12. 为了公司、自身的形象，我们需要无比庄敬自强，公平待人，不可欺负弱势的人，也不可以做损及他人或自己的事。同时，我们需要一个谦卑的团队负责人，谦卑的人不会固执己见，而是会虚怀若谷地聆听他人的言论。
  13. 有了真诚，才会有虚心，有了虚心，才肯丢开自己去了解别人，也才能放下虚伪的自尊心去了解自己。建筑在了解自己了解别人上面的爱，才不是盲目的爱。
  14. 我在生活中也是一个很仔细的人，也喜欢仔细的人。仔细的人一般做事都比较负责，愿意承担责任，也懂得抓细节。抓细节是作为一名技术团队管理者必须做到的。所谓的管理浮于表面，一般都是说管理者不关注细节，例如不参与设计、不参与代码审核，而只是高喊要注意开发设计、注意开发质量，这样的领导对于技术团队来说，尤其是一线技术团队经理来说，是不合格的，也是不能服众的。我觉得一个仔细的人，他一定也是一个善于观察的人，而善于观察、思考其实也是一个团队领导者所必须具备的品质，否则他的团队一定会在某一阶段或者一直处于混乱状态。
  15. 一个人一生如果想要获得过人的成就，就注定与读书和终生学习形影不离。功利性的学习是非常狭隘的，收获也是非常有限的，但是终生学习的回报却是不可估量的。
  16. “钱能买到一切有价的东西，独独换不回健康，也唯有生命才是无价的。”我们经常会听说有人得癌症了，有人又猝死了，这些例子数不胜数。虽然我能理解健康的重要性，但经常无可奈何。一个现场问题出现了，我们要一直忙到凌晨，可能偶尔还需要通宵应对。但是空下来以后，一定记得好好睡一觉，把睡眠补回来。因为只有保持身体健康，才能更好地带领团队。
  17. 回到技术管理工作。一直有同仁问我，什么时候可以转为技术管理？如果在军队里面，一个士兵说我杀敌本领不行，是不是可以升为将军？同样的道理，最好是技术能力比较强之后再转管理，水到渠成，技术不行的人即使转了管理，也难使人信服。
  18. 从技术转管理本身就是一个很大的转变，一旦跳进去，就很难爬出来了。我认为最大的差异就是，技术面对的是系统性问题，需要的是逻辑思维能力，是智商，而管理需要面对的很多是非逻辑思维能力，是情商。系统问题需要智商，而人是活的，你要理解人，就需要情商，情商是什么？我个人理解，情商就是如何站在别人的角度看问题。
  19. 作为技术团队管理者，你也需要有一定的技术功底，能够让“英雄”觉得可以从你这里学到一些知识，这样才能合作愉快。最后，需要对“英雄”的薪资、福利有所倾斜，并且多和他们沟通，让他们自己选择技术方向，为他们指明职业发展方向，并把他们放入关键项目里。
  20. 大多数公司内部都是垂直组织结构，所以管理团队、管理自己的团队领导岗位，大致上可以分为向下管理、向上管理、对外管理、自我管理这四个方面，管理的最终目标是：“不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境”。
  21. 成功地管理程序员最重要、最关键的因素，是在技术层面得到他们的尊重。
  22. 你所选择的这位空降管理者，你需要充分考虑他是否有良好、可以被证明的履历，这样才能让他获得团队的尊重。所以说，一般情况下技术团队是不会空降高管的。（真实！）
  23. 我们要学会保护团队成员，让他们免受组织中的各种问题、争议和“机会”的干扰。
  24. 公司内部非重要部门组织的会议，尽量不要放在周五的晚上和休息日进行。利用这种休息时间，看起来很有效率，其实是在过度使用研发资源，过度消费员工对公司的满意度。周五晚上和休息日可以打扰研发人员的事情是：（1）现场问题，必须立即处理（不处理会损害公司未来利益）；（2）重要客户提出需求，要求立即做出回复（不处理会损害公司当前利益）；（3）特别重大的突发事件（对你和公司都很重要）。
  25. “信任但要核实”，这是里根总统经常引用的一句谚语，也是列宁的口头语。
  26. 记住，没有记录的会议，相当于没有开过。每一个重要会议，都需要有完整的会议记录，包括参加人员、讨论议题（逐一写下来）、讨论过程大体描述、每一个议题的最终结论（包含流程图）、遗留问题、下一次会议时间及议题等。
  27. 你老板的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大、文字更少、项目符号更多。
  28. 另外，你还要避免只把问题带给领导的情况，最好是拿着几套潜在的解决方案和问题一起交给他。即使你没有特别好的解决方案，或者没有找到最好的解决方案，也会让领导觉得你已经做好了自己的功课，过来找他是为了寻求他的建议和忠告，而不是直接把问题抛给他。
  29. 公平、公正，是做事、做人的基本原则。
  30. 如果程序员觉得没有前途，不思进取，而资质较好的程序员很快又被提拔为管理者，那我们的软件开发将很难有技术和人才的积累。
  31. 作为一名团队管理者，有一点是需要做到：“不要作恶！”
  32. 程序员都是些无拘无束的人，常见的激励方法往往没什么用。除了进行必要的技术监督并把开发实践和过程落实到位之外，善于利用程序员的自我意识和改变世界的欲望也很关键。这就需要一类既能理解程序员的工作方式，又能理解工作本身的技术管理者，他们不仅能有效地激励程序员超常发挥，而且能按时交付结果。
  33. 杰出的程序员偏爱能够满足他们更高理想或要求的公司和项目，他们非常在意自己所做的事情，常常为了想要的结果而超负荷工作，而不会在某种压力下自愿做低技术含量的重复劳动。
  34. 大公司可能会采用“矩阵管理”方式组建团队，这意味着团队成员都有各自隶属的职能领域，但为了完成某个指定的项目，被“临时”分配到了一个矩阵型的团队中。这样能够在项目人事配备方面获得最大的灵活性，但是也带来了考核的难题。如果团队成员很优秀，这不会是一个问题。但是当团队成员表现不佳时，则可能成为“临时”团队负责人的烦心事。这个问题通常被称为有责任但没有权力。（真实！）
  35. 不要小看了这两个词的力量，正是这两个词决定了OKR和KPI的本质差异：OKR关注的是目标，KPI关注的是指标。当我们关注“目标”的时候，我们会思考接下来我要做的事情是什么；而我们关注“指标”的时候，我们会思考自己的工作如何评价。
  36. 彼得·德鲁克在《管理的实践》中说：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”
  37. OKR让我们做正确的事情，KPI让我们正确地做事情！
  38. 软件的主要目的就是把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效率的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相地延长人类生命。
  39. 一个合格的开发经理必须同时做到“按预期交付成果”“让客户满意”“让员工满意”
  40. 从这些工作任务的性质来看，开发经理是项目的推动者、技术的输出者，也是关系的协调者。总的来说，开发经理往往是决定一个项目成败的关键人物，要求其职业素养高、技术能力强、综合能力强、职责范围广。也正是因为要求太高，所以很多公司将开发经理、项目经理区分开，即项目经理可以不用管技术，专心做协调、进度把控工作。
  41. 软件开始开发前需要确定投入与产出的比值，也就是ROI（Return On Investment，投资回报率），一旦确定需要创建，就需要安排一系列的资源来支撑这个软件的生存，这是需求的最原始描述。
  42. 在需求评审阶段，邀请产品、开发、测试相关人员进行需求评审，产品需求评审主要针对以下几个方面进行：❑ WHY：为什么做这个需求？❑ WHAT：需求的价值是什么？❑ WHEN：需求期望什么时候上线？截止日期？❑ HOW：需求是否完整？正常场景是什么？异常场景是什么？技术上分别怎么应对？
  43. 对于还未上线运营的新系统，一般会让应用的产品经理或负责人给出一个预估的比例，但是这个预估需要我们进行评估，不是随意的。对于已上线运营的应用，一般会分析实际的交易数据来确定交易比例，这样会更加精准。
  44. 当你去问一个老人很多问题的时候，虽然可能很快得到解答，但当有一天，有很多新人来问你问题的时候，你就能体会到什么问题该问，什么问题不该问。
  45. 总结项目经验教训的目的在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。再重申一句，复盘会不要太严肃，它不是“批斗会”，而是为了总结经验，不断优化，不再犯同样的错误。
  46. 在项目中发生需求变更是难免的，我们不能抵制变更，但是一定要用切实有效的办法控制变更。需求发生变更后一定要认真仔细修改相关的文件，如需求文档、项目计划、设计文档等，并通过书面方式通知团队成员，不能在会议上一笔带过，并且要确保团队成员都准确地知道了变更的内容以及下一步的计划。注意，再小的变更都会给项目带来影响，多次微小的变更可能引发连锁变化，所以不能因为变更影响小而疏忽怠慢。
  47. 向进度落后的项目中增加人手，只会使进度更加落后”，这句话摘自《人月神话》。（实际还是看具体情况）
  48. 根据时间管理的经验，安排工作的原则顺序为：重要/紧急工作>重要/不紧急>不重要/紧急>不重要/不紧急。
  49. 缺少强有力项目管理能力的技术领导，很容易让团队的部分成员陷入迷茫。提出的命题很大，但是落实到每位技术人员身上，一部分人会迷茫，不知道每天应该干点什么，所以最好的方式是对工作进行拆分，每天的工作要能说清楚它的具体目标、要求标准等，这样才能让大家有存在感和参与感。
  50. 为了更好地设计系统、理解技术，你一定要组织调研项目和预研项目，这是因为你或者团队不可能什么技术、框架都懂，更何况技术发展非常快，只有针对技术进行调研、预研，才能够真正跟上技术发展的潮流，否则终有一天你会被技术岗位淘汰。
  51. 业务、架构和技术之间是共生的关系，而不是互斥的关系。先有业务问题，才会有技术来解决业务问题。而业务的长大要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了架构，也形成了新的技术。所以在这三者的关系里：业务是核心，技术是解决业务问题的工作，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，技术需要架构来合理组织，以提升效率。软件和业务最终是要合体的。
  • 正如很多管理环节，领导交代工作，喜欢你够聪明，自己去领悟。奉行的是好话不说第二遍，这样好像显得彼此的效率都很高，实际上这是很模糊的，下属极易做错做偏，不仅成功率低，往往还需要大量的成本去弥补。
  • 在日本的管理中有一个问五次原则，1告诉你去做什么。2让你复述一次。3做这件事的目的是什么。4你觉得行动过程中会有哪些问题，哪些你能自己搞定，哪些需要我来协助。5如果全权交给你来做，你会有什么想法和创意。
  • 看似好像很啰嗦繁杂，却实在地提高了沟通的效率和质量，有效避免了理解偏差和权责不清导致的错误和矛盾。
  • 有些人身上的光环是自己有本事，有些人身上的光环完全是公司的，一定要分清楚。
  • Leadership并不是当领导和经理，而是一种特征，这种特征有如下两个简单的表象：
    • 帮人解问题。团队或身边中大多数人都在问：“这问题怎么办？”，而总是你能站出来告诉大家这事该怎么办？
    • 被人所依赖。团队或身边中大多数人在做比较关键的决定时，都会来找你咨询你的意见和想法。
摘自陈皓

技术领导力是：

尊重技术，追求核心基础技术。
追逐自动化的高效率的工具和技术，同时避免无效率的组织架构和管理。
解放生产力，追逐人效的提高。
开发抽象和高质量的可以重用的技术组件。
坚持高于社会主流的技术标准和要求。

那么作为一个软件工程师怎样才算是拥有“技术领导力”呢？我个人认为，是有下面的这些特质。

能够发现问题。能够发现现有方案的问题。
能够提供解决问题的思路和方案，并能比较这些方案的优缺点。
能够做出正确的技术决定。用什么样的技术、什么解决方案、怎样实现来完成一个项目。
能够用更优雅，更简单，更容易的方式来解决问题。
能够提高代码或软件的扩展性、重用性和可维护性。
能够用正确的方式管理团队。所谓正确的方式，一方面是，让正确的人做正确的事，并发挥每个人的潜力；另一方面是，可以提高团队的生产力和人效，找到最有价值的需求，用最少的成本实现之。并且，可以不断地提高自身和团队的标准。
创新能力。能够使用新的方法新的方式解决问题，追逐新的工具和技术。

Leader 和 Boss 的不同
再或者用通俗的话说，Leader 是大家跟我一起上，而 Boss 则是大家给我上，一个在团队的前面，一个在团队的后面。

如何成为众人愿意追随的 Leader
说白了，要成为一个大家愿意追随的人，那么你需要有以下这些“征兆”。

帮人解决问题。团队或身边大多数人都在问：“这个问题怎么办？”，而你总是能站出来告诉大家该怎么办。

被人依赖。团队或身边大多数人在做比较关键的决定时，都会来找你咨询意见和想法。

《清单革命》