Skip to content

Latest commit

 

History

History
261 lines (166 loc) · 17.6 KB

why-empathy-is-important.md

File metadata and controls

261 lines (166 loc) · 17.6 KB
Raw
title description
同理心 ApiHug设计之本
极具同理心, 为什么同理心会融入到 ApiHug 设计中.

概念

同理心几乎是每个软件工程师必备软技能。许多人无意识地表现出同理心。但如果积极正向的练习它，就有更多无限潜力。

什么是软技能，不像你学个语言或者框架这些硬技能， 沟通、逻辑思维、解决问题、团队合作和同理心属于这些范畴；这些技能可能在你整个软件工程师的职业生涯发挥更大的价值。

忘记这些技能可能和你学习这些技能同样困难， 看一本书或者一段视频后不一定就能立即提升你的沟通技巧，这些技能有的是天生，有的必须后天不断的练习和实践。

Empathy is seeing with the eyes of another, listening with the ears of another and feeling with the heart of another. – Alfred Adler

同理心是人类一种深刻的情感， 同理心是情商的核心。它能够促进我们对个人情感的认识、处理人际关系和建立更牢固的联系。

同理心 Vs 同情心

同理心(Empathy), 同情心(Sympathy); 虽然只有只有一字之差，分别还是非常大。

同情心 指理解他人的痛苦，在本质上更多的是一种“认知能力”，实际上会与人保持一定的距离。比如常见： “对你的损失感到抱歉。”， “至少...”。

同理心 体会他人的感受, 需要一种“能够真正感受到对方的感受”的情感成分, “同理倾听者 Listening”与“问题修复者 Fixing”。

Empathy is sincerely visualizing yourself in the shoes of the person who has lost something.

Empathy is a choice and it's a vulnerable choice. Because in order to connect with you, I have to connect with something in myself that knows that feeling. – Dr. Brené Brown

Brené Brown Youtube 解释， 同理心的四种品质：

  1. 换位思考，以他人的方式看待世界; Perspective taking, the ability to see the world as others do
  2. 勿用评判角度; Staying out of judgement in these perspectives
  3. 感知他人的情绪，并且建立连接(换位思考); Recognizing the emotions in others and relating
  4. 基于情感共识上的交流; Communicating with that emotional understanding

软件开发同理心

用户

同理心可以帮助你和你客户之间建立连接， 协助你将更好的产品传递给你的客户。

她不仅用来具象、加强您的品牌在客户中的形象，更便捷你传递其他的价值和观点给客户。

更甚在面对棘手的客户纠纷、产品延迟、线上事故等， 更能引起客户的共鸣，为你在处理这些问题时候提供更多的缓冲。

当思考用户的需求和愿望时，同理心帮助你带入他们的视角，而给你一个全新完全不同的视野。

更不用说UX/UI 上面设计师对于使用同理心的技巧， UX设计者几乎都基于同理性，时刻将用户为中心铭记在心。

如 交互设计基金

Collecting insights about the social and cultural backgrounds of the users, their psychological traits, their feelings of frustration, and their goals will help you develop a broad knowledge of the users.

面向前端，同理心换位思考比较自然，但同理心也适用于后端工程师。

想象一下您希望如何存储数据以及您希望该信息的安全程度。您希望文档细致程度以节省将来的宝贵时间，或者哪些部分将来有发生安全漏洞可能？

你希望你的 API 有哪些说明和约定俗成，方便调用者理解，不容易犯错，将来的维护者扩展？

这一切都归结于换位思考。就像演员必须具有非凡的同理心！表演是愉悦观众，而不是你自己!

同事

团队合作和同理心是相辅相成的。牢固的关系建立在倾听和理解上，而不是互相审判和指责。

和队友感同身受，有助于团队共同成长。队友向你宣泄，虽然对解决问题无助，但你可以倾听（不带判断）。

利用同理性感知别人的感受。想象一下，一名队友因犯错而受到严厉谴责。如果换作是你，你会有什么感受？

拥有同理心让您能够更好地与他们沟通。在他们迫切需要的支持的时候伸出援助之手。

同理心也可以大大协助你处理同事间复杂的人际关系。尝试从不同角度观察一些的异常，可能是出于愤怒、恐惧还是悲伤。

换位思考（使用同理心）是解决工作争议的绝佳方法之一。

同理心就是以你希望别人以你期望被交谈的方式和你交谈。它需要正念（mindfulness）。当您下次在工作中遇到困难情况、或者在日常对话中，将同理心视为一种行之有效的方式。

一般的软件项目都有非常长的生命周期、和大量的角色参与， 个人可能身兼多职，现代分工下，大部分人只有一个角色。

开发者习惯性的将问题抛给 QA、运维或者客户支持部门，因为他们认为自己工作在代码提交合并完以后就完事了。

同理心能帮你更深层次理解你团队成员的工作，换位思考由于自己的疏忽给其他同事带来的困境和混乱；从而多方位、更负责打磨自己设计和实现。

未来工程师

代码是另一种沟通形式。我们应该努力降低将与代码交互的人理解难度。同理心可以帮助我们设身处地为这些人着想。

大部分工程师都有接手遗留项目、别人项目经历，宛如进入秘境，全新的代码，架构，逻辑； 无从下手，无所适从。

如果你是当初项目负责人，想象未来有人接手你的项目， 你希望留下些上面给他？

你会让你的代码可读性更强、避免复杂的逻辑、勿过度抽象、很好的命名规范。

更好的组织你的文件目录、保持代码整洁； 保持文档同步、 README 写好、单的 how-to; 有意义的备注、完整的单元测试。

有了同理心，您更有可能构建可维护的代码。当一个开发人员未重视同理。他很快就会为了速度而牺牲可维护性。他不会在系统的设计上考虑其他开发人员或未来的自己。将同理心注入你的日常开发工作点点滴滴，你将编写出更完备的文档和更清晰的代码。

一念善心起，诸事皆吉祥；一念恶心起，种种灾难生。

同理心驱动

编程语言不仅仅是人和机器之间沟通的语言， 她也是人和人之间交流的工具， 为组员之间，未来的自己，其他的继任者； 所以这个意义上，编程和写作非常类似。

编程是一种交流方式，而交流的本质在同理心， 所以程序工程师一旦掌握同理心后将受益匪浅。

来自 corgibytes 的 Goulet（专门做系统重构）甚至将同理心植入到公司的核心文化内。 Empathy-Driven Development 正是针对工程师提出一个兼具理论和实践的新的开发理念。

从工程师角度， 关于同理心的一些理解上纠偏：

  1. 同理心不是一种抽象、感觉、形而上学， 她是我们日常的身体力行， 换位思考，解决问题；是每日持续的训练；
  2. 同理心是超越软件工程的存在， 写代码，提交PR,设计测试是软件工程师的日常，工程师们是解决问题的高手，但是工程师首先得是个优秀的交流者，代码是和机器交互的手段， 更重要也是和人交流方式，这也是保持团队多样性、包容必要土壤；
  3. 同理心可以被培养，和你学习一个编程语言或者框架一样， 同理心的训练同样可以被拆解成步骤，循序渐进的培养；

大部分的技术上的差距，可以通过学习来拟补，大部分的开发者都能认同这个事实； 回过来想想大部分的软件工程师们在沟通交流，同理心都欠发展：如何合作，如何创建更好的产品。

锻炼获得

和学习编程语言， 或者有一项体育运动一样， 训练同理心，亦是有章可循，循序渐进。

停止抱怨学会感恩

这样的场景对于绝大部分程序员并不陌生： 当你在接受一个老项目， 看到一堆‘烂’代码时候，逻辑混乱，神秘命名，甚至有误导性的注释，没有意义的commit 描述， 甚至带有诅咒的备注； 可能你会心里暗暗骂娘。

但是请你暂且按下心中的怒火， 设身处地想想当时的情况， 当初写下第一行代码的人， 没有人生来就想写‘烂’代码， 可以想象当时的境况，时间，预算，技术局限等等， 也许你就释怀。

所有解决问题之道不可能考虑到所有情况， 没有代入感的审判已有的逻辑和代码，让你无法达到共识， 而浪费宝贵的时间和精力(愤怒)， 一个成熟的解决问题方式，是换位思考，当初他们为什么做出这样的选择。

像考古学家一样挖掘

当一位考古学家，试图还原一个古人生活的场景的时候， 她没有全部的画面，只能通过有限的片段拼凑： 一个陶罐、一个硬币、一块砖头等等；

当然这些片段越多，越丰富越好， 这些片段， 宛如你代码里留下的痕迹， 越丰富对未来开发者(考古学家)越友好。

固然通过这些“代码痕迹”或者代码本身，重构整个项目的架构是可行， 但是在代码里留下丰富、人性化的痕迹是更好的做法， 这是富有同理心的表现，是对进来自己，和后继的开发者的友好，省去了大量的他们的时间和精力， 这也是对 proactive perspective-taking 和 problem-solving最佳实践。

Leave the code better than you found it.

‘烂’不是当下躺平的理由， 避免更 ‘烂’才是永恒的斗争。

像作家一样思考

作家可能是最会把同理心带入的人，因为她的工作就是让她的读者深入角色。PS, 工程师们应该体验写如何写作的课程。

很多的写作技巧可以被使用都工程师日常工作，甚至自己的提升中， 比如：

  1. 尽量使用随和的语调进行沟通，包括避免技术术语， 或者不安全带有攻击性
  2. 换种视角，用第二人称的 你 带入
  3. 不要妄加猜测， 不要试图以为所有人都知道你说的概念， 做好铺垫和上下文解释。

好记性抵不上烂笔头， 将你点子和思路记忆下来，将来变成你完整思路的素材。同时不断分享和磨炼他们直到成熟。

Good writing is simple writing.

写作是你思想的结晶，想象下: Artifacts of your ideas; 写出来，表达出来，以一种引人入胜，故事的方式。

开发实践

将 Empathy-Driven Development 同理心驱动开发植入到我们的开发流程中，和引入一个开发框架一样简单。

Test-Driven Development 测试驱动，可以简单分成： 红(失败)、绿(成功)，重构几大步骤，同样EDD可以简单拆分成： 受众(Audience)和动作(Action); 受众(Audience) 包含所有和你内容和产品产生交互的人， 内容产品包含最终的产品、代码、手册文档； 对于 受众(Audience) 需要甄别他们：

  1. 身份角色(Individual)
  2. 上下文(Context)
  3. 需求(Need)

动作(Action)：

  1. 最佳方案(Best Action)
  2. 可行性方案(Feasible Action)
  3. 产出(Secondary Artifacts)

下面举个登记簿应用关于错误码提示的例子， 分解如下：

身份角色(Individual) 上下文(Context) 需求(Need) 最佳方案(Best Action) 可行性方案(Feasible Action) 产出(Secondary Artifacts)
消费者 使用APP过程卡壳了 清晰明了的解决方案 明确校验，积极反馈，视频引导 明确校验，积极反馈，文档手册 良好组织更新的错误码wiki
客户经理 快速准确处理工单 清晰的信息，完备参考手册 错误码手册，操作手册 添加错误码文档手册需求 内部需求系统，Github issue, JIRA
开发者 六个月后修复代码 清晰代码，低耦合、易懂，独立例子 修改所有bug，包括边缘测试 修复所有出现边缘用例 良好自解释代码，测试用例，提交备注，Github issue,JIRA ,用户场景

长期以往，反复锻炼， 当这些变成你的潜意识， 和TDD一样，开始大家觉得繁琐，进展缓慢， 拖累进度；有很多借口，很多过程输出(文档，描述)无关紧要，或者时间仓促、工期很赶。 但是综合大部分工作不是一次性的， 短期的投入，举手之劳，可以大大降低后期的耗费，其实是一种非常值得的投资。

这些就像飞行员开飞前的检查列表， 一旦你非常熟练后，这些动作其实非常快， 她变成你潜意识里的条件反射，变成一个习惯。

让这些“副”产品伴随着你的代码， 沉淀为组织的宝贵资产， 日后其他程序员接手时候，他能够非常愉悦的代入，不需要有情绪的抵触，或者索性重新发明轮子，这才是对组织最大的无形的贡献！

ApiHug

在 API 领域，终端客户、开发者都是你服务的对象；以 EDD Empathy-Driven Development 同理心驱动开发方式拆解 API 整个生命周期。

关联身份角色暂时拆分为七个，将来可能细分到更多。

受众(Audience)

  1. 身份角色(Individual)
    1. 终端客户
    2. API消费者(第三方调用)
    3. BA: Business Analyst, 需求分析师
    4. API 设计者
    5. API 开发者
    6. API 测试人员
    7. API 运维管理者
  2. 上下文(Context)
    1. 通过终端(App,Web,PC)实现自己述求
    2. 调用API集成到自己服务中
    3. 用例（User Case）分析拆解、领域划分
    4. API 标准，管理、设计
    5. 底层语言、框架选择，代码实现，单元测试
    6. 根据用例，测试用例，保证需求实现一致，边缘测试
    7. 版本更新换代，环境隔离，运行时健康监控，API 性价比
  3. 需求(Need)
    1. 功能一致，体验流畅（正、反流程都人性化）
    2. 设计合理，文档清晰， SDK, 技术支持培训
    3. 共同语言，信息完整性，技术业务友好
    4. 标准一致，流程规范，工具完备，复用性强
    5. 标准统一，规则一致，标准框架，自动化、低代码，核心业务聚焦
    6. 版本一致，沟通统一，标准一致
    7. 流程规范，节点清晰，责任明确， API ROI

动作(Action)

  1. 最佳方案(Best Action)
    1. 功能引导说明、体验完美，符合人性
    2. 完善文档、引导说明，DEMO, 完备升级换代方案
    3. 一致工具，标准流程，统一标准，统一术语
    4. 一致工具，标准流程，统一标准，统一术语
    5. 统一框架，统一基础，清晰架构
    6. 统一框架，统一工具，统一标准
    7. 统一流程，统一节点审批、审计流程
  2. 可行性方案(Feasible Action)
    1. 完整技术说明文档， 用例
    2. 完整技术说明文档， 用例， 培训资料， DEMO
    3. 技术术语库， 模板
    4. DSL, 工具栈， API Repository， 复用, 管理面板(UI Portal)
    5. 工具栈, 基础框架，代码生成，辅助SDK
    6. DSL, 管理面板(UI Portal), 基础框架
    7. 管理面板(UI Portal), 流程审批， CI/CD
  3. 产出(Secondary Artifacts)
    1. 生态，用例，标杆，传播
    2. 生态，统一行业标准
    3. 统一标准，业务和技术纽带， 组织资产积累
    4. 统一标准，知识库，组织资产积累, 领域知识扩展
    5. 基础框架、领域知识扩展，架构设计能力提升
    6. 域知识扩展, 组织资产积累
    7. 域知识扩展, 流程数字化

围绕 API 的软件工程开发， 自然遵循软件开发生命周期(Software Development Life Cycle，SDLC)，将同理心注入整个开发的生命周期，是 Apihug 核心文化和设计基础；诚然Apihug 无法解决所有的问题，Apihug 努力将关于API开发里面所有的干系人，以及从需求，设计，开发，管理等等一系列环节； 聚拢在一个屋檐下，用统一的语言，减少分歧，建立共识；采用行业统一的标准， 最大挖掘现有资源和工具，极少的侵入，最低的学习成本，围绕api打造一个卓越的团队。

Refer