团队协作

猪齿鱼已上线工作日历，欢送申请收费试用！ https://choerodon.com.cn/#/ia... 日常团队合作中，大家都心愿本人的注意力可能专一于须要实现的、重要的事件，让工作变得更聚焦且简略；而领导者们也心愿能及时理解团队合作的状况，帮忙团队更好地协同。为了使团队合作更高效、更易于治理，咱们通常会做一些打算，比方迭代打算、周打算、PI打算等。然而这些打算往往是一个待办列表或者是一个路线图，并不能使每个人每天某一时间段聚焦在须要实现的事件上，并且，当工作有工夫抵触时，也无奈及时发现，协同团队成员的工夫也十分艰难。 面对上述问题，猪齿鱼全新推出“工作日历”性能，让工夫管理更迷信，让团队合作更高效。 接下来，让咱们来看看猪齿鱼是以哪6种形式，让团队从猪齿鱼工作日历中受害的。 01 以日历取代待办事项列表，高质量治理工夫 待办事项列表是晋升工作效率的好办法，能够清晰的地看到每天的事项安顿。每实现一项事项，团队成员能够通过拖拽的形式，将该事项拉到实现事项列表，且该事项出现划掉的状态。然而，要想在一天内把须要做的事件都实现，并不是一件简略的事件。有些工作破费的工夫很长，然而在列表中却很难进行预估。 猪齿鱼工作日历则可能通过工夫维度，很快把每天的待办事项治理起来，使每个事项须要破费的工夫高深莫测，并且能够应用周视图、月视图的形式查看工作项，用工夫治理去推动待办事项的进度。 日历工夫治理图 02 跨我的项目创立工作项，集中管理工作 项目管理中经常会呈现一人负责多个我的项目的状况，不同的我的项目我的项目节奏也会不同，很容易导致会议或工作项的抵触。比方A我的项目打算10：00-11：00有需要评审会，B我的项目则打算10：30开始迭代回顾会，两个会议的工夫呈现重合。这种不合理的会议安顿，容易使员工的工夫碎片化，导致每天的工作事项无奈聚焦，影响进度。 应用猪齿鱼工作日历，可将集体参加的每个我的项目的工作都以工夫维度集中在一处，作出明确的工作划分。每位用户都领有本人的工作日历，创立不同我的项目的工作项，并对立用日历模式治理，防止我的项目间的工作抵触。 03 可告诉工作项所有相干人，信息实时同步 我的项目中的一个工作项或会议，经常须要多人合作实现，这就须要对所有的经办人、参加人一一告诉和确认，既耗时又影响效率，有时候还会因为告诉不到位，而呈现信息差，导致工作项提早或勾销。 在猪齿鱼工作日历中，用户能够疾速创立工作项或会议，保护对应的负责人及参加人，告知大家须要实现的工作项及加入的会议信息，对应的工作项或会议信息也会同步到其工作日历中。 04 父工作视角管理工作项，疾速对齐工作指标 在猪齿鱼中，当一个工作须要多人合作时，能够将这个工作拆分为多个子工作，被拆分的这个工作称之为父工作。父工作和子工作的进度会由不同的责任人来跟进和实现。对于团队成员而言，从猪齿鱼工作日历的父工作视角，可将工作项治理起来，疾速对齐工作指标。 举个例子，一个开发工作能够被拆分为多个子工作，比方前端工作、后端工作、产品工作、UI工作等等。作为开发人员，将可能更好地聚焦本人的工作，并在规定的我的项目周期内实现交付，还可随时查看父工作下本人的工作安顿、预估工夫、实现信息等，疾速对齐工作指标，防止因关联工作的提早而带来整个我的项目的提早。 猪齿鱼工作日历 05 一键订阅到本地，工作生存东倒西歪 记录在猪齿鱼工作日历上的工作项和会议，可订阅到本地日历。如果你正在应用本地日历记录生存中的事项，但又心愿同时管理工作和生存的工夫，能够一键订阅猪齿鱼工作日历到本地，与本地日历疾速交融，从而更灵便地安顿本人的工作和生存，让本人的工作和生存东倒西歪。 06 极易应用和调整，学习成本低 通过猪齿鱼，用户可疾速创立工作日历的工作项，并进行调配经办人、参加人等配置项的设置，还能够以拖拽的形式疾速调整工作项的预计工夫。极低的学习老本，极易操作的界面，让使用者在短时间内就能够疾速上手，迅速利用于项目管理中，即刻满足团队合作的须要。 让团队的工作布局更清晰，让工作和我的项目合作更通明，让团队的工夫和停顿放弃同步！立刻在您的我的项目中开始利用猪齿鱼工作日历吧，请拜访猪齿鱼官网申请试用吧！ 申请收费试用 https://choerodon.com.cn/#/ia...您也可致电400 168 4263 转 81072 分割咱们理解更多。 本文由猪齿鱼技术团队原创，转载请注明出处：猪齿鱼官网 对于猪齿鱼 猪齿鱼Choerodon数智化效力平台，提供体系化方法论和合作、测试、DevOps及容器工具，帮忙企业拉通需要、设计、开发、部署、测试和经营流程，一站式进步管理效率和品质。从团队协同到DevOps工具链、从平台工具到体系化方法论，猪齿鱼全面满足协同治理与工程效率需要，贯通端到端全流程，助力团队效力更快更强更稳固，帮忙企业推动数智化转型降级。戳此处试用猪齿鱼

在传统组织中有多个部门，它们专门负责特定职能——营销、财务、人力资源、经营等。很多时候，这些部门各自为政，只有在波及多个部门时才会共享信息。不过，构建和交付软件的古代需要须要可能高速解决大量问题。随之而来的是须要有一个残缺的团队来反映提供解决方案的各种专业知识，这就是跨职能团队的用武之地。 什么是跨职能团队？跨职能团队是一群来自不同畛域的人聚在一起，用他们各自独有的能力来实现一个独特的指标。跨职能团队不仅是横向的各种职能专业知识的碰撞，也是纵向的自上而下的构造比对。 由团队成员和次要决策者组成的跨职能团队并不少见。跨职能团队对于实际 DevOps 办法的组织尤其有用。其价值能够通过多种形式体现进去： 跨职能团队有助于缩小要害决策的官僚作风。这里的指标是在须要疾速做出决策时有必要的示意。这使得跨职能团队非常适合 DevOps，其中麻利思维是实现更快迭代和进步后果品质的要害。 跨职能团队还能够进步解决问题的能力。在DevOps办法中，品质和总体客户价值十分重要，因而呈现的任何问题都须要有最佳的解决方案。跨职能团队领有跨职能专业知识的各种人员，每个成员都能够提出不同的想法。例如，当探讨如何展现产品服务，取得无效的客户反馈时，营销专家的意见比拟有参考性。他们更晓得客户与产品互动的正确条件，并提供有价值的反馈。 跨职能团队进步团队凝聚力。能够激励不同部门的人合作，使之更多地理解他们之间的差别（次要是在工作中）。这有助于拉近他们的间隔并建设关系，这在合作时会派上用场。这样一来，群体思维和繁多的回声室就会隐没，发表非主流的或者不同凡响的意见的人会更自在。 跨职能团队面临的挑战尽管跨职能团队的想法听起来很妙，在实践中也相当简略，但高达75%的跨职能团队并不胜利。跨职能团队受到工作习惯和亚文化差别的困扰。来自组织不同部门的每个成员都有本人习惯的工作形式。这就使得适应新的工作形式有点艰难。记住，如果每个团队成员都有本人的偏好，也可能并不习惯这种工作形式。跨职能团队面临的其余挑战有：指标不统一、沟通不畅、误会角色和指挥链、工具不同及办法抵触。 指标不统一每个团队成员都能够为整个我的项目做出奉献。但很容易遗记他们的工作与其余团队成员之间的分割。这是很常见的问题，尤其对于长期来调整产品的团队成员来说。但它常常会导致人们对某些问题产生误解，比方某个特定成员的工作何时应该进入周期。成员们在实现工作时，可能也只会做最低限度的工作。这些抵触会延长到更小的细节，如数据存储格局和其余方面。后果是交付品质参差不齐，须要从新审查产品，这会拖慢团队的速度。 沟通不畅跨职能的团队成员往往难以进入良好的沟通节奏。首先，它们可能用于不同的通道，这可能导致信息不同步。其次，通信频率可能存在差别。一些团队成员可能喜爱频繁发送告诉，告知他们所做的每一个更改。但其他人可能只想接管更重要的里程碑和重大变动的音讯。有些人可能更喜爱书面总结和简短的语音记录，而另一些人则想要工夫更长的面对面会议来分析打算、发现、剖析等。未能及时、统一地接管要害信息可能会导致失误和后果提早。 误会角色和指挥链在许多跨职能团队中，一个部门的成员可能会提出倡议，而这些倡议必须由另一个人施行。例如，商务人员可能会倡议开发一种性能来跟踪无关用户行为的特定指标。开发人员和 UI 设计师可能仅仅将其视为倡议，直到下级有人签字再落实口头。但我的项目负责人可能曾经将其视为不须要任何额定许可的我的项目。 从实质上讲，团队成员可能对他们每个人的工作有所理解，但并不理解团队最终目标的全部内容。有时，工作只须要对接一两个其余成员的人甚至可能不晓得其余成员到底在做什么。 工具不对立在许多传统组织中， 数字化转型并不全面，如云计算这样的技术可能还没有渗透到整个组织中。此外，在日常工作中，很多部门可能会应用不同的工具。无论是自动化测试还是对于软件开发生命周期进度的交换，领有太多不同的工具都会让人头疼。一旦团队成员开始单干，那将所有相干数据集中在一个中央并且实现齐全可见就极富挑战性。 办法抵触在一个部门中，相当于测试和质量保证的局部个别放在最初。而另一个部门可能会采纳麻利办法来实现我的项目。当来自这些不同办法背景的成员会面时，他们实现我的项目的办法可能会导致进度不同步。 建设胜利的跨职能团队的注意事项要建设一个胜利的跨职能团队，有许多方面须要留神。 具体的领导：除了每个职能都有一个领导之外，整个团队须要有一个端到端的领导者。每个团队成员还应该晓得由哪个领导收回具体的指令。明确的指标和打算：必须从一开始就为团队制订一个次要指标，并制订具体的打算/路线图，并在时间表上绘制里程碑。每个团队成员的能力都应该体现在它如何实现最终目标。除了提及专业知识之外，还要议论该人员将要实现的工作。频繁评估：为团队中的每个职能起草评估零碎，以确保他们不会应用谬误的办法进行评分。此外，跟踪总体目标进度并剖析数据以确定问题是总体团队凝聚力还是特定性能。无效沟通：确保每个人都晓得他们会花最多工夫与谁交谈以及他们将议论什么。让他们在工具、音讯的性质/组成、频率和其余实际方面保持一致。灵活性： 以这样一种形式构建团队，无论贡献者的理论地位在哪里，你都能够接管输出。为忽然扩张留出空间，成员更容易找到替代者。这能够通过始终保存文档来实现，以便新进入者能够疾速上手。在成员中造就麻利的心态，以便他们以预测任何曲线球并可能相应调整的形式工作。分割和信赖：进行有助于增强团队外部关系的练习，这样成员就不会胆怯提出意见，不会胆怯抵赖失败。建设胜利的跨职能团队的雷区建设和保护一个继续胜利的跨职能团队，要防止以下谬误： 不合理的优先排序： 防止只反对一项性能而疏忽其余性能。这可能被视为偏袒，使其余团队成员士气高涨。在提供资源和满足其余需要时尽量获得均衡。当资源不够富余时，以最小的付出给个体最大的利益。无序的等级制度：不要造成这样的状况：一个成员总是跑到不同的成员身边，要求他们批准继续执行某项操作。明确哪些行为是低危险的，由成员自行决定，哪些须要下级批准。宏观治理：尽量减少与重要布告和进度查看无关的会议数量。在须要创造力的中央，给团队成员留出空间，让他们本人想出最好的解决方案来进行合作。如果这种文化不被激励，团队成员将应答一直降级的渺小挑战，而向领导者寻求无奈取得的解决方案。指责：防止在呈现问题或未达到目标时进行指摘的习惯。在许多跨职能团队中，失败通常是由多个不同职能的人解决失当造成的。因为许多工作依赖于别人，所以这并不总是一个人的错。重点是要从胜利的职能中汲取的经验教训，尤其是那些也能够利用于其余畛域的经验教训。

云效我的项目合作是连贯团队合作的桥梁。突破部门边界，市场经营、产品经理和工程师能够共享同一个工作台。以「合作」的形式，多样化的工具整合，展示更严密的跨部门合作，发明更多业务增长。多元视角赋能每一位成员，让企业、团队和集体以更高效的团队合作形式围绕指标 发明成绩。点击立刻体验 我的项目类型云效中，我的项目是贮存工作并帮助企业治理指标、工作流程、截止日期及文档的的外围，是合作的根本单元。能够将须要实现的指标创立成我的项目，邀请团队成员退出一起发展工作，独特达成指标。 我的项目分为「一般我的项目」和「工作流我的项目」两种类型。 云效一般我的项目：工作通过看板列进行归类，应用勾选框示意工作实现状况，可自在拖拽看板中的工作。 云效工作流我的项目：工作须要在多个看板列中进行流转，应用工作状态标识工作实现状况，拖拽看板中的工作须要依据工作流程的设置。 Tips: 一般我的项目与工作流我的项目不能相互转换。在企业空间首页鼠标挪动到我的项目卡片以及切换成列表视图可看到我的项目类型的标识。我的项目创立和删除一、创立我的项目 1、创立形式能够点击导航栏上的蓝色加号全局创立按钮，抉择创立「我的项目」。 也能够在首页上的「最近浏览的我的项目」模块点击加号或点击查看全副我的项目进入进行创立。 2、创立空白我的项目 间接创立空白我的项目，输出项目名称、我的项目简介并抉择我的项目分组，点击「实现并创立」即可。 3、从模板中创立 能够依据本人的应用场景从官网我的项目模板库中抉择创立。 抉择从模板中创立，进入欠缺我的项目信息界面会展现该模板已设置好的工作板流程以及默认会开启哪些利用插件。输出项目名称，点击「实现创立」即可。 二、删除我的项目 点击我的项目右上角「菜单」，进入「我的项目设置」。在「更多」操作中，我的项目的拥有者能够抉择将我的项目「移至回收站」或者「归档我的项目」。 如果须要彻底删除我的项目，须要先将我的项目移到回收站，而后从最近浏览器的我的项目中点击进入全副我的项目，切换到「回收站」分组下找到该我的项目，鼠标移到该我的项目上右上角呈现删除或回复的按钮，能够疾速操作。 也能够进入该我的项目，在右上角「菜单」-「我的项目设置」-「更多」中操作将我的项目彻底删除。 Tips： 只有我的项目拥有者能够进行我的项目的归档和删除操作。彻底删除的操作不可逆且无奈撤回和复原，请审慎看待。我的项目界面创立好我的项目后就进入到了我的项目界面。 我的项目界面分为 5 个局部： ① 我的项目导航栏：左侧展现以后我的项目已开启的利用，可间接切换。右侧显示我的项目成员按钮以及我的项目菜单，点击可查看以后我的项目成员及角色，进入菜单可进行我的项目设置。② 我的项目侧栏：由搜寻框、工作分组和我的项目视图组成。搜寻框素来查找我的项目分组或视图，工作分组能够更好的治理不同类别的工作，视图除了零碎预设外还可自定义。③ 工作看板：我的项目中的工作会以卡片的模式展现在工作看板中。同时看板中的每一列即为工作列表，能够用来示意工作所处的阶段或状态。④ 工作看板操作栏：位于工作看板的左上角。能够切换看板视图、依照条件筛选显示工作、依照条件对工作排序展现，同时点击最右边三个点，能够导入导出我的项目内工作以及将工作看板切换为演示模式。⑤ 我的项目布告：位于左上角项目名称右侧，显示为一个「i」。点击可查看以后我的项目的我的项目布告，新退出我的项目或者新创建的我的项目有布告内容后进入我的项目即可看到。我的项目管理员和我的项目拥有者有权对布告内容进行更新。 Tips： 收起侧栏可点击侧栏两头的三角箭头，或点击工作看板左上角的图标按钮。当我的项目布告被更新过但以后成员还未查看过期，我的项目成员进入我的项目时我的项目布告做蓝点提醒。我的项目 布告更新形式反对 markdown，反对更新到我的项目和我的项目模板中。我的项目菜单我的项目菜单位于我的项目界面的右上角，点击即可开展查看。 ① 我的项目设置：能够批改我的项目信息，设置我的项目偏好，进行工作设置，日程设置，分享设置，自动化规定，调整工作权限，或者退出和归档、删除我的项目。② 标签：能够直观地看到每个标签所波及到的工作、日程、分享或者文件的数量和具体内容。还可在标签名称右侧的下拉菜单中抉择「编辑标签」做相应批改。③ 利用核心：即利用商店。可开启或敞开以后我的项目利用，也能够返回利用商店查看更多利用。④ 查看回收站：外面是以后项里被放入回收站的工作、文件、日程、分享等内容，可在回收站中彻底删除和复原。⑤ 复制我的项目：疾速将以后设置调整好的我的项目进行复制，方便快捷。一般我的项目还能跨企业复制。⑥ 保留为我的项目模板：将以后我的项目保留为企业级的我的项目模板，能够在企业外部共享。⑦ 订阅我的项目内容至第三方日历：将我的项目内容订阅到第三方日历上不便查看。 Tips: 我的项目可归档，也可放入回收站。工作只能放入回收站，无奈进行工作的归档。工作流我的项目不反对跨企业复制。我的项目成员一、增加成员 点击右上角「成员」图标，在成员列表中有蓝色按钮「邀请新成员」。 增加成员有三种形式： 可间接抉择从部门或者群组中抉择须要增加的成员，或增加整个部门进入到我的项目中。 能够点击邀请界面右上角的「通过链接邀请」按钮，对方能够拜访链接间接退出我的项目。邀请链接在 48 小时内无效。 二、调配成员角色 我的项目拥有者和我的项目管理员能够在我的项目成员列表中调配各我的项目成员角色，并通过成员前面的标识作辨别。 鼠标移到须要批改的成员名字上，右侧会呈现下拉按钮，点击即可关上成员菜单，勾选对应角色即可实现设置。 须要留神的是，新的权限赋予之后请揭示成员及时刷新页面以使新的权限失效。 ...

简介： 埋点作为记录用户行为的惯例伎俩，随同着前端技术的倒退早已历经春秋，不过直到“增长黑客”系列实践呈现，才真正让埋点剖析变得外延丰盛且有章可循。 作者 | 金戟起源 | 阿里技术公众号 埋点作为记录用户行为的惯例伎俩，随同着前端技术的倒退早已历经春秋，不过直到“增长黑客”系列实践呈现，才真正让埋点剖析变得外延丰盛且有章可循。 与产品畛域的“增长”相似，“提效”始终是研发畛域里长盛不衰的主旋律。在软件研发过程中，随同着我的项目发展，同样会以事件的模式记录下许多与代码库、流水线、工作相干的行为数据。这些数据的起源虽与页面埋点不尽相同，其实质用处却有许多可类比之处。然而当产品经理们纷纷开始通过埋点的实时数据争分夺秒调整市场营销策略时，研发团队的TL和PM们仍然只能应用统计办法+汇总指标为主导的预先剖析伎俩，在每个版本和迭代实现后对团队效力进行回顾和评估，并乐此不疲地议论如何将迭代周期从一个月缩短到两周，从而取得“更快的反馈”。 本文将探讨一种尚未被实际过的方法论，即是否将“增长黑客”实践作用到研发过程的改良上，从而实现更牢靠的定向效力优化？ 一 研发团队的北极星指标在进行增长指标制订之前，团队往往须要先确定一项可能反映团队胜利状况且易观测的“北极星指标”，譬如销售额、签单率、沉闷用户数等等。对于研发团队来说，要害的指标次要是需要实现时长、性能缺陷率、用户满意度，诸如此类。以“需要实现时长”为例，这是一个绝对主观且间接反映开发团队响应用户需要速度的指标，即一个需要从提出到最终交付可用，所须要经验的均匀工夫长度。 接下来咱们定义一个绝对现实的需要交付过程，并参考产品流量剖析的“转化漏斗”构造示意进去： 相应的，将我的项目中的所有需要都增加进来，能够绘制出相似这样的“需要交付门路图”（示例，理论阶段划分应该更丰盛）： 尽管略显毛糙，但通过这种展示形式咱们的确可能追回不少在平常只统计后果数据的图表里失落了的信息。譬如同样是两个花10天实现的需要，一个开发用了7天，另一个开发只用了1天，其余工夫花在了期待测试上，它们的差别在交付门路图上就能被清晰的辨别进去。 这样做的另几项益处包含： 即便一个须要还未最终交付，而是被阻滞在了某个环节、或者呈现了返工，也可能在第一工夫以异样流量的模式显著的展示在门路图上，从而及时引起TL和PM的关注。 岂但能直观的看出总体的各阶段交付停顿状况，也能从单个需要角度查看流经的每个节点，并找到其余状况相似的需要，便于剖析它们的共性特色。 用于预先剖析时，可做交付后果的反向追溯，譬如查阅未按时交付的需要流经此前各节点的比例。 基于以上参照，咱们能够得出以研发需要价值转化的“效力黑客”模型（对应增长黑客的AARRR模型）： 有了北极星指标和可视化的门路，接下来的关键在于用数据领导效力改良。 二 时间轴上的AB测试并非所有客户都值得投入大量力量来维系，增长团队总是优先专一于高价值客户的留存。在进行效力改良时也该当首先辨认差别，而后因材施教。 正如增长团队罕用的“RFM模型”客户分类办法，针对研发需要，同样能够通过与效力相干的正交维度来分类出可采纳不同应答措施的需要汇合，譬如“RIW模型”： A（Activity）需要的近期活跃度（相干事件频率）I（Importance）需要的重要水平（优先级、间隔打算实现的剩余时间）W（Workload）需要关联的已投入开发工作量（譬如代码批改行数） 三个维度能将所有样本分为8组，这个粒度非常适合圈定重点，同时又防止信息太多适度发散。而抉择以上三组属性，不仅是因为它们具备较高区分度，还因为这几项指标的观测值都较容易取得且可能高频更新，从而在研发过程中及时发现异常样本并进行纠偏。 软件研发是一项脑力劳动为主的流动，影响研发效力的因素包含且不限于开发者的集体能力、团队气氛、公司文化、我的项目进度压力、成员间的默契度、内部沟通老本、相干流程工具等等，其中绝大部分都是无奈简略用数值化掂量的主观成分。尽管以往提及研发提效时，咱们会出于技术可控的角度，着重议论平台能力、研发流程、工具反对等“疗程短，见效快”的办法，但真实世界的研发提效伎俩要丰盛得多。既能够采纳技术工程伎俩，如晋升构建速度、简化上线流程、改良公布工具；也能够采纳组织文化伎俩，譬如优化奖惩策略、建立先进标杆、调整人力构造、晋升员工福利、增强技能培训等等。那么到底哪种提效办法才最适宜研发团队呢？ 对此，增长实践早就给出了答案，不管黑白猫，只有抓住老鼠就是好猫：做个AB测试。 与面向产品用户的AB测试不同，进行我的项目研发时，不能间接以单个需要为粒度进行AB测试（不便于项目管理），相比之下，团队或者迭代都是比拟适合的AB粒度。具体的AB办法大家一点也会不生疏，譬如让两个我的项目团队采取不同的提效策略，比照成果，相似于“试点”和“样板间”。或者让同一个团队在不同的迭代里别离尝试一些新的提效办法，而后依据成果来决定保留或放弃，这就是在“时间轴上做的AB测试”。 喏，一个新概念就这么被发明进去了，不过当初还放弃苏醒着的读者很快就会发现，这也不是什么陈腐的主见，迭代回顾和改良会议不就是做这事件的嘛！其实不尽然。以往迭代回顾时的可剖析数据次要是迭代燃尽图和需要/缺点累积图，反映的是整体的趋势状况，“整体均值”往往会覆盖部分问题，这是达不到“AB测试”严谨性要求的。而前述的“需要转化门路”和“RIW散布”状况恰好可能补救上迭代过程细节，为效力改良的办法提供领导根据。 三 舶来主义的局限在许多方面，通过埋点剖析增长策略与通过研发事件剖析提效策略之间确有共通之处，譬如埋点的四大因素： 此四项因素研发事件皆有，因此凡是埋点可用之计划，研发事件皆可套。这是舶来主义。 然而增长关注的是固定的一群用户，谋求拉新留存；提效面对的是突飞猛进的需要，谋求按时交付。因为两者的剖析对象和指标不同，实质上仍然存在差异： 用户来到了又会回来，能够继续追踪；需要实现就完结了，下次进来的是新需要。这也是需要不适宜做为AB测试粒度的起因。拉新和留存能够越高越好，不设下限；交付效率不能单方面适度奢求，否则以就义品质和疲劳战术换取“提效”终将得失相当。页面门路绝对固定，譬如必须先通过下单页能力进入付款页；需要门路则不肯定，譬如一个“开发超期”的工作最终仍然可能“按时交付”。此外，埋点记录的页面点击总是实时精确的，而需要的状态依赖人工更新，实际操作未必及时，采集的事件数据因而常常存在工夫偏差，这是研发数据分析的一项老大难问题。更充沛的自动化是一种解决思路，譬如在阿里云·云效的新版合作产品中，反对通过规定让研发行为与工作更新关联（比方代码提交触发工作开始、流水线公布触发工作实现等），此举将非常有助于减少效力剖析的准确度。 最终，即使是模式化的借鉴，是否无效还须要实际来证实。 四 畅想与小结增长和提效，两个看似驴唇不对马嘴的主题，因为一个脑洞，被分割到了一起。 用产品思路经营技术团队，用埋点数据还原研发过程，用转化门路洞察要害瓶颈。效力黑客，让我的项目进度更主观，让研发过程更通明。 原文链接本文为阿里云原创内容，未经容许不得转载。

采访背景介绍您去政务服务窗口办理过业务吗？在过来，常常是怀抱一个满满的档案袋，排队几小时，后果被告知“材料有余”。而今足不出户，很多政务服务拿着手机或者电脑就能够网上办理，政务办理变得像“网购”一样便当。数字政务、数字民生、数字农业......数字化曾经逐步渗透到了产业动脉与生存点滴当中。这些实实在在的效率晋升离不开所有深耕数字化畛域的企业与组织。 作为产业互联网的新兴力量，新腾数致网络科技有限公司 （以下简称新腾数致） 正在为民生、政务、金融、农业等畛域注入科技力量，推动数字化在产业中的落地。为了能按时保质交付业务我的项目给客户，新腾数致在本身外部的研发效率、经营效率等方面踊跃求进。每一个想要跑得更快的企业，都是为了让客户走得更远。本次采访将聚焦于新腾数致在软件开发效率晋升的摸索与改良，CODING 带您一起看看新腾数致如何借助新思维、新工具，让本人跑得更快。 采访对象介绍新腾数致：用数字科技连贯城市和农村新腾数致作为新心愿团体和腾讯独特投资成立的公司，依靠新心愿产业劣势与腾讯互联网科技能力，致力于推动民生、产业和政务的数字化倒退。公司四大业务板块： 数字政务：作为数字政府集成解决方案的提供商，助力政府数字化转型，用数字化伎俩改善营商环境，缩小我的项目审批工夫； 产业金融：构建连贯企业、金融机构以及政府部门的产融关系数字平台，为中小微企业提供智能融资、普惠金融、供应链金融等服务； 数字农业：整合了新心愿在农牧业等方面的教训，通过叠加大数据、云计算等数字化伎俩，输入农业产业互联网端到端解决方案，为大量的中小农业企业和农户服务； 数字民生：以参加“新基建交融场景”为门路，解决老旧小区革新和新基建建设、社区商业“老破小”、街区急需状态提档、业态降级、党群核心亲民化革新、垃圾分类等痛点问题。新腾数致研发总监金涛：瀚海行舟，逆水行舟十年以上出名金融、电商行业公司软件研发与治理教训，曾发表系统性文章《程序员探险记》。目前专一于大数据与云技术在金融科技领域与利用的联合翻新。 每日三省吾身：“如何按时交付”CODING： 金总，您好。从您过往的教训当中，能够看出您在软件研发畛域有着相当丰盛的治理教训。在新腾数致所处的产业互联网畛域中，你认为最大的一个研发效率难题是什么？ 金涛： 数字政务是新腾数致一个重要的业务板块，咱们在成立初期帮助政府做了很多数字政务的我的项目。在政务行业，不仅需要变动快，而且要的急。 咱们在服务政府我的项目的时候往往是忽然来了一个需要，在需要可能存在很大不确定性的状况下，就须要研发尽快实现。这时候十分须要一个优良的研发工具严密合作，将需要，工作拆分细化后跟踪治理起来，防止信息传递的失落和跟踪执行不到位，做到端到端的输入输出治理，防止无奈按时交付的危险。 CODING： 目前市场上研发工具的选型空间还是很大的，包含开源工具、各大云厂商提供的平台、或者是针对单个研发环节的工具等等。新腾在研发工具选型上是如何思考的？或者说哪些起因促使你们抉择了 CODING？ 金涛： 最感动咱们的一个起因就是 CODING 的一站式服务，这防止了本人搭建零碎来回切换，登录繁琐，系统维护等等问题。 在没有应用 CODING 的时候，咱们须要本人搭建相干的工具。比方需要治理用 Confluence，工作跟踪用 Jira，测试治理用禅道，代码治理应用 GitLab，制品库应用 Nexus，代码扫描工具应用 SonarQube，继续集成应用 Jenkins，继续部署应用 Spinnaker…… 自行搭建这么多工具会带来很多问题： 本人在服务器上搭建和保护零碎，须要投入不少的精力，同时零碎的可用性还不能失去很好的保障。因为这些零碎没有互相买通，存在反复登录和来回切换等问题。因为是开源的零碎，有些零碎的用户体验做的不够好。文档资源也很无限，碰到问题得不到很好的反对。开源零碎面对企业级利用还存在性能上的有余，比方企业微信的挪动端反对，腾讯云的集成，权限管制，统计性能，平安问题和日志审计等。开源零碎在性能配置的灵便度上比拟弱。辞别黑盒式研发CODING： 那在实现工具选型后，你们是如何应用 CODING，通过 CODING 进行哪些研发效率上的优化？ 金涛： 首先咱们依据 CODING 中的最佳实际，进行了麻利开发的培训分享，让大家从思维文化上承受这种理念。 而后配合应用 CODING，因为没有了多个零碎来回切换的繁琐操作，零碎交互体验也很好，这让大家更违心配合去应用 CODING 发展工作，麻利的研发流程能力真正推动起来。在这个过程中，大家的工作内容全副在零碎中记录下来，不仅让研发过程更加通明高效，而且在过程中能更好的管控危险。防止了过来黑盒式的研发治理形式带来的低效和危险。 而后通过 CODING 的 DevOps 反对，联合腾讯云的 K8s，缩小了继续集成和继续部署中一些反复的人工操作。提高效率的同时还缩小了出错的可能性。 CODING ： 麻利落地，理念后行，能够看出你们在应用工具之前，先进行的是理念布道和观点对齐，这值得不少研发团队借鉴。在后续 CODING 应用过程中，有哪些令人印象粗浅的体验吗？ 金涛： 我比拟过很多开源和付费的研发合作工具，CODING 的交互体验是十分杰出的，零碎界面简洁易用。 而且 CODING 的工作流配置性能很弱小，默认的看板中只有未开始、进行中、已实现 3 列。咱们自在定制看板为 6 列：需要输入中，UI 设计中，开发中，测试中，需要验收中，已实现。而后为需要、工作和缺点定制了属性字段和状态，最初为某个看板列指定能够显示某几个状态的需要、工作、缺点。在状态变更步骤中，还能够指定更新某个属性值，比方咱们配置了“需要验收中” -> “已实现”的状态变更，这个操作会主动将需要的进度更新为设置的 100%。 ...

在我的职业生涯中，遇见过许多专业人士，他们在技术上十分健全，对本人的畛域和技术有很好的把握和专业知识，然而因为不足软技能，他们错过了降职、现场机会、高级技术面试以及职业生涯中的机会。很震惊吧，技术好却不能降职？的确如此，我敬爱的敌人：随着寰球趋势的一直变动，企业正在寻找技术过硬、同时具备优良软技能的专业人士来退出他们的团队。在这篇文章中，咱们尝试分享一些要害的根本软技能，咱们认为这是在DevOps角色中，或者事实上，任何软件配置文件中都须要的。看一看，试着把它们作为你共性的一部分来进行倒退。依据谷歌的说法，“软技能”指的是“能让一个人与别人无效、谐和地互动的集体特质”。比方，你上大学时可能疏忽了小组学习。在那些日子里，团队工作是最乏味的工作。然而，在“事实世界”中，与别人单干并将工作委托给每个人在DevOps中是十分必要的。最胜利的DevOps工程师不仅是疑难杂症问题的解决者，也是优良的沟通者、同理心者和领导者。因为DevOps的将来将由人工智能主导，软技能将变得更加要害。软技能将决定你是否能很好地和共事共事。简而言之，也就是意味着你是否适宜这家公司。 让咱们看看2021年成为DevOps 专家所需的一些重要软技能。 1.同理心日常的同理心只是指你如何了解他人的观点，DevOps中的同理心则是把你本人放在共事和客户的地位上进行换位思考。用和善的语气而不是平易近人的语气靠近共事，有助于营造谐和的工作环境。在一个了解和敌对的环境中，提出新想法要容易得多。如果你不喜爱某人的想法，那么就给你的反馈一些踊跃的倡议。当前你能够解释你不喜爱什么，而后用另一件踊跃的事件完结。表白不同意见时能够采取“先肯后否”的模式，但不是“yes……but”，而是“yes……and”，即“我认为你做的很不错……如果是这样会更好”的句式。通过与客户建设这种同理心，能够确保产品或服务满足客户的需要。比方，如果你的网站点击率很高，就阐明你在优先思考潜在客户的需要。 2.团队单干开发人员的大部分工夫的确是独立工作的，但很多时候开发人员也必须与团队其余成员一起工作或互动，比方极限编程中的结对编程。与别人单干会使你的工作更乏味，还有可能取得将来工作的助益。与团队一起工作通常是发明连贯产品的最佳形式。对于开发人员来说，常常与共事接触总是一个好主见。如果无奈与团队成员面对面交换，能够应用在线应用程序来保持联系和更新。 3.急躁对共事放弃急躁是团队在DevOps环境中独特工作的要害。你可能是团队中最好的程序员，但如果你善待其余团队成员，技术将毫无意义，因为开发人员并不是一个人在同一个我的项目上工作，他们离不开团队单干。因而，作为开发人员，急躁和毅力将使您走得更远。在艰难和顺境中所体现出的急躁是雇主们所须要的。花点工夫答复每一个问题，解决每一个艰难，会为当前的工作排除许多阻碍。 4.适应性适应能力是DevOps最重要的软技能之一。作为技术宅，咱们晓得软件和硬件是一直倒退的。然而，依然有许多经验丰富的开发人员致力跟上新的编程语言、框架和工具的步调。因而，开发人员必须定期投资更新他们的技能。然而如何表白你的适应性呢？有几种办法：● 通过硬技能证实本人的适应性，学习一门新的编程语言或一项新技能。这证实你有很强的适应能力和学习能力。● 能够在简历的工作经验局部增加更多的数据来证实你的适应性。这将表明你齐全可能适应学习新事物并在不同的环境中进化。● 论述你有多喜爱团队单干，以及他人一起工作的舒适感。 5.责任感责任感意味着对你所有的谬误承担责任。当疏忽本人的谬误时，你或其余团队成员可能会再次犯同样的谬误。抵赖本人的谬误并不容易，但从久远来看，这将是你为团队做的最好的事件。因而，敢于承担责任对任何领导者来说都是必不可少的。如果你有足够的勇气抵赖本人的谬误，你的团队也会被激励这样做。最终，每个人都会采纳这种软技能，利用本次的犯错来剖析哪里出了问题，以及在当前如何防止这样的谬误。 6.工夫治理无效地治理你的工夫能够让开发人员专一于重要的工作，并更无效地实现工作。当你有很多事件要做时，治理工夫可能会很艰难。合理安排优先级、番茄工作法等小技巧能够无效地治理你的工夫。工夫治理能够让你工作一段固定的工夫，必要时能够劳动。另外，尽量避免多任务处理，因为这对工作效率不利。“stop starting，start finishing”，通过缩小在制品，让本人全神贯注地分心于一项工作会让工作效率大幅度晋升。 7.高效沟通无论是全职工作还是兼职工作，沟通技能都是须要造就的要害技能。甚至当近程工作时，这也是至关重要的。开发人员/DevOps专业人士应该晓得如何与各种背景和文化的人交换。对于开发者来说，了解人们的情绪、他们说了什么以及他们怎么说也很重要。很多时候，须要应用电子邮件和即时消息等书面交换形式进行互动，那么这个时候简洁的写作技巧对于DevOps专业人士来说也是至关重要的。 论断综上所述，一个人要想在DevOps畛域取得成功，除了具备过硬的技术、具备DevOps工具和技术外，还必须具备上述的软技能。 本文译自：https://dzone.com/articles/es... 咱们曾制作过一本《程序员生存手册》，与上述观点不约而同。实际上，不仅是DevOps，所有程序员在强调硬技能的同时也需关注软技能的修炼。《手册》的内容篇幅较本篇文章更为空虚，且给到了本质无效可落地的职业倒退路线。 《程序员生存手册》别离从技能篇、办法篇、倒退布局篇、资源篇、治理篇五个局部来介绍相干的常识，涵盖了每位程序员从初入行业到筹备转型，直至最终实现本人人生价值的全过程。心愿能为浏览到这本手册的每一位程序员提供一些进步能力的新途径，以及进行职业规划的新思路。 纸质版现已绝版，有趣味的能够在这里支付电子版：https://www.zentao.net/download/80328.html 也能够来GitHub为手册添砖加瓦：https://github.com/easysoft/z...

一、对于研发效力的冷思考 Robin（茹炳晟老师）在1.7号“冬哥有话说”的最初，提出对于研发效力的三个冷思考，外围问题是：研发效力的晋升，是否真的让咱们的工作和生存晋升？ 效率晋升了，然而咱们的工作时长有没有缩小？工程师有没有从中获益？技术升级，其实含糊了咱们工作与生存的界线。咱们正在被咱们亲手发明的工具所压迫，沦为这些工具的奴隶。既然是冷思考，Robin本人也论述了本人的观点，冬哥就不进行侧面答复了，回放可看：http://l7i1.com/GUV4c4 法国作家安托万·德·圣·埃克苏佩里的《小王子》是冬哥最喜爱的书籍，大略没有之一，每年都会看一遍，每次都有新的发觉。恰好昨天在看的时候，有三则寓言触动了我，想来与本话题相干，分享给大家思考。 来自《小王子》的三则寓言寓言1：卖止咳丸的商贩“你好。”小王子说。“你好。”商人说。 他是个卖止咳丸的商人，每星期只有复用一粒，就不会感到口渴了。 “你为什么要卖这货色？”小王子问。 “它能够大大节约工夫。”商人说，“专家做过计算，每星期能够省下53分钟。” “省下的53分钟用来做什么呢？” “想做什么就做什么....” “是我的话，”小王子喃喃自语，“如果我省下53分钟，我就缓缓的朝一池泉水走去...” 研发效力的目标是什么？节约进去的工夫用来做什么？做更多的需要还是更好的均衡工作与生存？ 寓言2：数星星的商人“占有这些星星对你有什么益处呢？”“能够使我富裕。” “富裕对你有什么用呢？” “能够再去买别的星星。” 商人坐在那里为“属于本人的星星”计数，他认为他领有星星，使得他很富裕。但真实情况是，他忙得连低头工夫都没有。 很多人说研发效力是老板要做的，需要也是老板加的。 好，问问老板，富裕是什么？富裕对他意味着什么？他真正想要的是什么呢？ 寓言3：惭愧的酒鬼小王子问那个酒鬼 ：“你在那儿干什么呢？”“我在喝酒。”酒鬼哭丧着脸答复。 “你为什么要喝酒呢？”小王子问。 “为了遗记。”酒鬼答复。 “遗记什么？”小王子问。他曾经开始有点儿同情他了。 “遗记我的惭愧。”酒鬼垂下脑袋抵赖说。 “为什么感到惭愧？”小王子又问，他想帮忙这个人。 “为喝酒感到惭愧！”酒鬼说完这话，就把本人封闭在长久的缄默之中。 因为喝酒而惭愧，为了遗记惭愧而喝酒。 酒鬼能够轻松的跳出那个循环，却埋头沉沦不自知，世人又何尝不是如此。 惭愧的是什么？想要的是什么？你能够为此走出的一小步是什么？ 如同静止总是挂在嘴边，却从未口头。 每天十个俯卧撑，每天15分钟步行，如果你做到了这一小步，会怎么？如果更近一步的话，还有什么？ 还能够做什么与当初不一样的事件？如果能够更好，咱们还能做什么？ 研发效力改良也是如此，你能够优化的一小步是什么？如果做到了这一步，还有哪些？进而从零碎的角度看，想要更好，还能够做什么？ 你说扭转不了老板，好，那么扭转本人如何？ 咱们不去扭转老板，咱们抉择老板如何？抉择工作如何？ 问问本人，工作的目标是什么？达成后对你意味着什么？你真正想要的是什么呢？ 被困在零碎中？技术含糊了咱们工作与生存的界线？你能够做出扭转的一小步是什么？ 你在规避什么?你在挽留什么? 能不能 彻底地放开你的手? 敢不敢 这么义无反顾坠落? Just let time go on. With no fear in your heart.

关注成员成长很早之前，现代管理之父德鲁克提出过一个影响深远的观点，“21世纪的组织，最有价值的资产是组织内的知识工作者和他们的生产力。”现代企业的各位管理者，遇到最大的两类问题就是战略和组织，看不到、想不到、做不到，这“三不到”的问题归根结底都是人的问题。能够看到、想到、做到“重视人才”的企业，成功的概率总是会大那么一点点的。你的公司呢？ 阿里有一句话流传甚广，“员工是公司借给你的资产,你的责任就是让他增值。”作为组织力溢出的阿里，这句话是很值得我们深思。早年在阿里的时候，曾在内部分享时听马老师明确地说过，阿里巴巴就是“客户第一、员工第二、股东第三”，当然这条至今应该也没有变过。相信“客户第一”这句大家都认，“员工第二”呢，你怎么看？ 作为一个企业，活下去是最大的使命，公司的各位管理者都需要在不同的层面不断的思考，如何才能够让企业持续发展，并且越来越好。在不断向外看、向外寻、向外学的过程中，希望都留出足够的时间给内部，给成员。 成员的判断标准 团队成员在成长时，其实很希望获得类似玩游戏时打怪升级的快乐体验的，所以我们需要给团队成员一个可以看得见点得亮的技能树。这个技能树是团队成员成长的判断标准，一般HR是称之为“胜任力模型”，但我这边主要是自己的一些经验总结和知识沉淀，还不够成熟和体系化，所以大家当做是简化的判断标准即可。这个判断标准包含三块内容，能力、经验、认知，分别对应于“你能做什么”，“你做了什么”，“你知道什么”。 首先是左下角的能力这块，这块是绝大部分管理者都熟识的，也是应用相对最好的。我这边简单的再做了一下小分类，以开发的同学为例，专业能力我们会关注开发语言的学习能力、框架的应用和改造能力、技术重难点的攻坚能力、故障问题的定位能力等等；通用能力我们会关注理解能力、总结能力、表达能力等等，高阶一些我们会关注共情能力和领导力等等。这块有很多更体系化的归类描述，我就不班门弄斧了。 比较希望引起大家关注的是其他两个判断标准，关于经验和认知。 关于经验经验和能力很容易搞混，判定你能做这个事情，你就应该有相关的经验。其实这里有一个误区，能力获得的方式有很多，直接看书习得和亲身经历获得。不是说看书习得的能力就不是好能力，但是作为管理者，我们问问内心，如果要做一个项目，是找一个已经做过很多次项目的同学，还是一个可以把项目管理说的头头是道但没有实操经验的同学？不是全面否定纸上谈兵，但确实纸上得来终觉浅啊。对于经验，这是需要关注的第一层。 需要关注的第二层是失败的经验。成功经验很宝贵这个就不展开了，大家很容易理解。大家可以停下来考虑一下看，有过成功经验但没有失败经验的人，他去重复成功之路时，这个路径的适应性到底有多强？很多时候是突破认知的，突破的是他自己的认知，更是启用这个成员的管理者的认知 -- 因为我“不知道自己不知道”（这个我们一会展开聊）。我们一定要小心那些赢了但不知道怎么赢的人，相对的，那些失败过的人，即使是赢了，他对于成功，也是会保持敬畏和反思的，这个思维很重要！然后，使用有失败经验的人也需要小心，我们不要去用屡战屡败的人，运气这么差不行啊（开个玩笑）。但我们确实是要敢于去用屡败屡战最后能赢的人。 （我老大推荐给我的一本老书《大败局》，也推荐给各位） 举个栗子，在运维届有一个千年老梗，“我执行了rm -rf /，现在怎么登录不上去服务器了”。有过这个经历的同学应该这辈子会被运维界封杀。但是，我们思考一下，这个失败的经验真的是永不录用的点吗？做了这个事情的小菜鸡，在真的理解了自己做了什么之后，他对于运维、对于系统甚至对于知识，应该这辈子都会有敬畏之心了吧，对他自己来说，一个命令、一个参数、所处环境没搞清楚，绝对不会再去冒冒然执行的了；对团队来说，这样子的人成长起来以后是可以交出自己的后背的。（话外音：如果不幸有雷同的故事，我们应该思考一下制度规范、管理约束、执行监督这块，这些东西以及和这些东西有关系的人，更应该被重点关注！） 关于认知认知是一个很大的话题，前面的描述“知道什么”，更多的是你沉淀的知识的多少，这里想跟大家具体聊的是“怎么去理解和认识自己”。认知的四阶段，成员的自我认知，是直接影响他的成长的。  我举软件项目的一个栗子帮助大家感受一下。“我们要去快速占领小程序的入口，谁来看看怎么做一个小程序”，这时候，前端一两年经验的小白跳出来了，我来吧，web端移动端的我都做过了，小程序也不会有什么不一样的；与此同时，从后端转去前端的技术专家提出了不同的看法，小程序看起来是一个不太一样的技术体系，我们还是先去研究一下再做判断。 不知道自己不知道，这个状态其实在团队中很多的，一个人是很难完整的在这个状态里的，有可能是一时，也有可能是一事。我们一定要能够正确地识别出来，在这个状态中是比较盲目，比较冲动，也比较无畏的，就像故事中的小白一样，这不是一个好的认知状态。 知道自己不知道，这个状态在团队中其实也很多，绝大部分优秀的人都是在这个状态被识别出来的，而不是大家以为的“知道自己知道”。我个人认为这是一个比较好的认知的起步状态，很像是一个脚已经放在起跑器上的跑步运动员，重要的是，发令枪也在他自己手上。这个状态的中的同学总是很谦虚，有敬畏之心，行事相对谨慎。 知道自己知道，这是一个比较优秀的状态了。这个状态中的同学，知道自己知道的边界，会尽力把事情控制在自己可控的范围内。 不知道自己知道，这是一个卓越超凡的状态了。这应该是一种打通了任督二脉去学习武林绝学的感觉吧。 成员的成长辅导 经验相关前面一节提到，我们要放开对失败经验的成见，敢于启用有失败经验的同学。那对内，我们也应该要敢于让同学尝试可能失败的事情，也应该要放开必须成功的紧箍咒。成功学的书很多，我们却硬要来聊聊如何帮助“失败”（因吹丝挺）。 我们首先明确，我们不是为了失败而失败，是为了成功正视失败。在成功的道路上，我们允许荆棘也允许坎坷。怎么做？首先第一点，“控制黑边界”，失败是一个完整彻底不可控的失败，还是一个部分暂时掌握中的失败，差别很大。我们一定要控制好失败的边界，失败尽量不影响最终结果，失败尽量不影响太多成员。尽可能让可能的失败在掌握中，前期，管理者一定付出大量的脑力、体力和心力，就可能出现的风险点做出充分的预估，做好完善的保障，保证出现失败时整体可控。第二点，“总结全经验”，有没有做总结分析，有没有做思考沉淀，是衡量这次失败价值和意义的分水岭。没做总结，白失败了，经验值都给别人了。出现了失败，不但要总结，还要尽可能的全面总结，这个当事人自己要把这个失败的前世今生总结到位，把再来一次可能成功的路径一定要找到位。同时，跟这个失败有关系的所有同学，要一起参与进来，不是来讨伐的，是来一起思考、一起共创的，从不同纬度、不同角度，把这个事情的上上下下里里外外弄个清清楚楚明明白白。（这个事情上，曾经地阿里“太白”--白老师、现在的校宝COO--杰哥，宇宙无敌，只要这个阵地他敢把旗子插上去，就没有我们不敢冲上去的，原因就在这里，带着大家赢，输了也是赢，最终一定赢。）最后第三点，“出发再启动”，已经失败的同学再次踏上征途，无论之前的总结多么的到位，心情总是有所起伏的，出发前，作为管理者一定要做好启动的动作，要告诉他，为什么再出发，再出发为什么能赢，把成功的路径指给他看，重点就是要把他的状态调整到位，要把他的情绪引导到位。 认知相关认知四个状态中，最不好的状态就是“不知道自己不知道”，如果深陷这个状态无法自拔的同学，建议不要去做只有神才能做到的事情了。但对于只是某一时间段或者是某一个具体事情上无法突破的，我们要尽可能的辅导帮助。如果真的是一个好的同学，从不好的状态“不知道自己不知道”到起步的状态“知道自己不知道”，我们要做的事情其实也比较简单，就是让他看到。比如之前小程序的故事中，在小白看到了技术专家拿出来的技术可能性分析、技术方案后，我相信他会进化的，毕竟我们大部分人都是这么过来的。“看到”是不好的状态进行跃迁的基本辅导手段，后面的状态的跃迁，需要的是更多成员自身的主观能动性了，我们之后有机会再聊。 成年人不会轻易改变自己，除非他自己想改变，认知的变化可以理解为改变一个人的心智，其实是一件非常难的事情，所以如果你有幸做到了，请相信，你只是遇到了一个优秀的同学，不代表你就是一个优秀的管理者了。 大道至简 最后跟大家分享传奇CEO-杰克·韦尔奇在《商业的本质》说的一句话，希望大家能在管理之路上越走越实。 本文作者：古月山水阅读原文 本文为云栖社区原创内容，未经允许不得转载。

摘要： 在技术型公司团队中最重要的文化是学习能力，只有不断的学习整个团队的竞争力、创新能力才能得到提升，战斗力才能越来越强。我是来自阿里云-云通信技术团队的玄照，2015年底进入阿里，刚渡过三年醇，正迈向五年陈的路上。个人兴趣爱好广泛，静的、动的，音乐、游戏、电影、运动都比较喜欢。 程序生涯启航第一次接触编程是在高中时期“非常不重要”的计算机课程Basic语言，现在回想起来仍然清晰的记得当时第一堂上机课时运行编写好的代码时的那种神秘、好奇、激动的心情，我想应该是从那个时候开始坚定了到今天的程序员生涯。因为偏科严重，大学并未能如愿进入计算机相关的专业，但因为兴趣还在，所以大学时代对软件编程课程格外关注，有时间也会偶尔到学校计算机学院去旁听自学一些课程。 可能就是因为内心始终有一份“执念”，所以运气还不错，毕业就找到了一家软件公司从事网页设计相关的工作，从此开始了转型之路，从网页设计、到测试、到割接脚本、到前端开发、再到后端开发，因为心之所向，所以不管哪里有空缺我都愿意补上去，通过三年的时间，自己也从团队的边缘做到了核心开发。 那个阶段个人的成长和进步还是非常迅速，我认为这主要得益于三个方面：首先是看书学习，当时很明确自己的不足，所以充分利用业余时间阅读了一系列JavaScript、Struts、Hibernate、SQL、编程思想、JVM虚拟机、编程思想、设计模式等技术基础相关的书来补齐自己的短板，让自己的技术体系逐步趋于全面；其次是阅读代码和实践，能主动去找机会承担需求，申请到对应的代码权限，阅读同事的代码知其然知其所以然，从中吸取经验，在实现需求更改代码的过程中也能合理的引入书中学到的一些技术点去落地；最后是虚心请教，遇到不懂的问题一有机会就会向人求教和讨论，工程师们都很热心，能耐心指导，纠结的问题能够快速的得到答案，从而提升自己的效率。 进入阿里云，跳出舒适区到目前为止我经历了三家公司，选择来到阿里主要的原因有两点。一个是源自于自己的危机感，当时自己呆在一个职业生涯的舒适区，工作上的挑战度和个人的成长在当下的技术氛围环境下很难突破，希望能在更大的平台和有更多优秀技术人的环境中取得个人技术上的突破；其次是对阿里的好奇和向往，在所有的项目技术选型前，不管服务框架、服务治理、消息中间件、数据库、读写分离、缓存、事物处理、发布流程等涉及的技术点和流程都会不同维度的与阿里内部或者开源的中间件进行比较，总感觉得自己站在外面，了解的都是“点”，不能有体系化、深入的了解，确实进入内部了解下阿里整个的技术生态和体系。 接到offer后其实也有过纠结，从舒适区到一个这么有挑战的公司去也还是需要一些勇气，所以决定来之前给自己和家人做了很多心理建设，回想当初，心理上的准备也是我能顺利通过试用期和快速适应阿里氛围和节奏的关键因素之一。 在阿里第一年，我的感触非常多，印象最深的还是两个词：拥抱变化和绩效。阿里文化中提到比较多的词之一就是拥抱变化，也是新人参加百阿培训必定会提的，这个文化的含义我觉得也只有切身经历后才能真切的体会背后的含义，其中节奏的变化、人员的变化、工作内容的变化、团队的变化等等随时都有可能会发生，所以拥抱很重要，拥抱不仅代表对于变化的接受，还需要对于变化能快速的调整自己，学习补足自己来适应变化。 进入阿里也是第一次接触了解到云通信的业务，逐步的去学习Freeswitch开源工具、软交换、运营商的组网等知识。随之而来的也是一系列的变化，试用期内核心成员转岗，随后主管也变了，独自一人承接整个平台，平台也处于孵化阶段，问题不少，从需求设计开发、客户支持、资源接入、计费结算等等都需要人工介入，压力特别大，过程很痛苦。但是十分庆幸当时自己的坚持，那一年把所有事情都扛了下来，自认为很满意，绩效自评的时候给了自己3.75，但最后主管评价是3.5，一开始特别想不通，也开始回顾、反省和总结，后来想明白了，3.75注重的是结果，并不是你过程中有多辛苦，能否把业务支撑下来，而是你能不能让平台能力、让业务变的更好，能不能发挥周边同学的力量和你一起协同作战，其实这一年自己在这些点上做的并不是很好。 伴随云通信一起成长第二年，经历了我在阿里最重要的一个项目，作为项目PM，完成了我所负责的平台从孵化阶段到产品化的转变，并为云通信业务上云商业化打下了一个坚实的基础。项目制定了明确的业务目标和技术目标，经过上一年的沉淀和问题梳理，从多个维度将平台能力做了全面的提升。首先是产品化和标准化提升，解决客户接入渠道、协议多样问题；建立资源引入、测试、上线、下线的标准流程；解决人工计费、结算、对账的效率问题。 其次，构建沉淀统一的智能决策平台，基于静态、动态规则的二级路由调度平台，实现调度规则收敛以及基于成本、质量等多维度的资源调度自动化。 第三，平台架构以及稳定性的提升，全面梳理核心链路的单点问题。应用、机房级的容灾能力建设，网关全链路的心跳探测机制，实现分钟级自动隔离和恢复；供应商链路上多专线和容灾体系的构建，去除依赖，链路精简，降低系统复杂度。第四，运维保障体系的构建，去除过于技术化的表达式配置，将配置结构化、线上化；线上问题定位、排查工具；以及监控、告警体系的构建。 项目结束后，整个平台的产品能力和稳定性得到了极大的提升，同时也能让其他团队的同学介入进来参与到整个平台能力的建设和运维中。在此基础上产品也快速的实现了商业化，成为阿里云云通信业务重要的组成部分。 也基于此，这一年也获得了主管晋升提名的机会并成功通过。关于晋升，之前其实也没有任何心理准备，讲的也都是基于两年内的平常的思考和总结。所以我非常认同，在职场中晋升是一件水到渠成的事情，最重要的是看你自己做的工作能否让业务或者平台发生改变并往好的方向发展，让业务产生更大的价值。 技术型公司需要这样的你基于自身的经验，我认为在技术型公司团队中最重要的文化是学习能力，只有不断的学习整个团队的竞争力、创新能力才能得到提升，战斗力才能越来越强。关于学习，我的方法首先还是阅读经典书籍，对于要解决的问题、涉及到新的技术通过阅读能够全面、体系化的获取到需要的知识点。其次是像优秀的人学习，我会刻意的多观察高层级优秀同学解决问题、思考问题的方法和思路，同时遇到问题也会向他们请教、交流获取答案。 以上是我基于自己经验的一些看法，希望能给到即将来或者想要来阿里同学一些帮助。 最后，作为云通信业务的基础技术团队，技术同学的主要工作职责是各产品线技术平台的构建、能力优化以及技术创新。随着业务的发展，整体技术面临的挑战也还是比较大的，也非常希望在分布式环境下对系统架构优化、稳定性、高并发、性能优化经验丰富有想法的Java技术牛人加入我们，一起做世界上最好的云通信技术平台！ 职位申请链接：https://job.alibaba.com/zhaopin/position_detail.htm?trace=qrcode_share&positionCode=GP525299 本文作者：山哥在这里阅读原文 本文为云栖社区原创内容，未经允许不得转载。

命名禁止缩写精简扼要地对class命名，请勿使用自定义缩写。class name的命名必须是行为、有语意的。禁止在非特殊情况下写！importantCSS本身有权重设计，任意地使用!important会造成权重混乱而无法维护。不可轻易限定宽高用户可以自行设定自己的浏览器，例如Android手机可以设定显示字体大小，写死的高度会让字体相互重叠。RWD失效移动设备的高度是无限的，宽度是有限的。请不要把宽写死。img请让它自动缩放请不要替img的容器设定宽或高，让它根据设备自行缩放。请使用bootstrap的img-responsive。如果确实要用： width: 100%; height: auto;如果要给img border-radius设定样式，请使用父元素控制行为，保持img只载入图片，没有样式。优先使用grid排版请不要花很多时间在写media query，设定一堆breakpoint，自己写组件样式，自己控制每种设备上的容器宽度。请使用grid system，这些都是已经成熟的框架，而且有些也已经帮你处理了浏览器相容问题。不可直接over write或在原本框架的class增加内容直接写一个新的class，不要覆盖原有的设计。不要再已有的class上添加样式，请额外单独写一个。设计RWD网站，请遵循移动设备优先原则设计师的设计顺序，以桌面版优先，再设计手机版。前端工程师拿到视觉图，开始写HTML/CSS时以手机版为第一优先。手机开启网页很吃手机效能和网络状况，前端工程师一开始就以手机版为优先，可以让HTML一开始载入，使用最少的效能快速载入网页。当开始制作桌面版时，只会少许跑版，做适当微调即可。相反，如果先制作桌面版，当手机版画面被切掉或是跑版，需要花更多时间去调整。再来是iPhone手机的retina，会将图片放到手机上时自动做两倍缩小，在一开始制作时即可发现图片载入是否吃效能。为了让图片能在iPhone上有更好的体验，建议移动版优先。 不可使用html tag selector请直接定义class的样式，不需要指定html tag。层级不可以超过三层超过三层表示耦合度太高，不具有弹性、可维护性。用一样的element时不要把一堆东西全部写在里面，请把排版相关的独立出来把border-radius写在img上面，请把img保持干净。定位，例如position: absolute;不要随意none掉画面上的tag或行为请注意如果要none掉一些样式，请依照使用程度决定。使用程度遍布整个网站，请直接使用reset.css使用程度中等以下，请定义一个classreset.css常见的a tag不要有underlinelist消除原有样式请在reset.css上定义，并且设为第一载入次序有JavaScript行为的class可以为命名加入name space#js-project-show {}请勿任意使用br hr tagbr是换行，请使用在p tag里面，当p里面文字过多时可以使用。hr是快速划线，但是即将被淘汰，请直接使用border写在class里面。br必须去思考父区块是不是display: block;，如果要换行，应该思考是不是下一段文字。线条请都是用border去写。

今天我们讲讲如何利用站会，更好地实现促进团队有效协作和聚焦，促进价值顺畅流动和交付，同时及时的暴露问题和风险。站会的目标说到站会，人们最熟悉的Scrum站会，典型的形式是团队围成一圈，依次回答三个问题：昨天做了什么？今天准备什么？有什么阻碍或问题？通过站会，Scrum团队成员了解其他成员的工作，从而更好地协作，达成迭代目标。看板方法应用得当，可视化价值流实践执行到位，以上三个问题完全可以清晰地展示在看板上，所以没有必要再回答这些问题了。那站会的目标是什么呢？回到精益看板方法本身的目标：顺畅和高质量地持续交付有用的价值。相应的，看板站会要聚焦于价值的流动，而非个人工作。站会的目标是：促进团队有效协作和聚焦，促进价值顺畅流动和交付，同时通过站会同步需求进展和暴露问题及风险，把可视化价值流实践落地到位。站会的前提在建立了如下图的精益看板系统的可视化价值流，明确流转规则和限制在制品数量的三个实践之后，还需要管理价值流动和建立效能反馈闭环并持续改进。管理价值的流动具体包含管理价值流动过程，价值的输入和价值的输出，关于管理价值流动过程的一个很重要的实践就是每日看板站会。关于如何建立精益看板系统，后续会有专门的文章来详细讲解。云效看板示例：入口站会组织形式1、频次：每天（每个工作日），时长不超过15分钟，一般在早上，具体时间团队可根据实际情况调整，建议9:45或10点开始；2、三个相同：同一个团队在同一时间、同一地点在看板前进行日站会，形成固定的节奏后，会变成团队的习惯；3、协调人：团队成员站在围在看板前，由一位协调人来带领团队从右往左（⬅️）逐列走读看板；协调人可以固定，也可以轮流进行；4、电脑：为了让站会更加聚焦和高效，负责投屏和记录的同学可以带电脑，其他人不需要带电脑；站会前：需求和任务的状态已更新1、团队已按照统一优先级的规范更新需求的优先级，辅助优先级，状态、期望日期等2、开发同学按照实际情况更新需求和任务的状态（任务向需求对齐）。需求负责人负责协调把开发中的需求拆分成任务（如下图），并协调需求从开发完成，测试，直到发布完成为止；已拆分好的任务需指派到个人，任务的颗粒度在1-2天的工作量，确保每天都有看得见的进展 ，及时暴露风险和问题；任务责任人已更新好任务的状态和截止日期；如有外包-接口人合作：外包同学也需要在站会前更新状态，接口人按照流转规则进行状态流转。站会重点关注的信息站会上不需要检视每一张卡片，本着“促进价值顺畅流动和交付” 的目的，我们要重点关注影响价值流动的问题和阻碍项，如下图所示，绝大部分问题会标记橙色或红色，可以很清晰地体现在看板上。瓶颈和队列：某个环节不顺畅时，需求积压形成队列，这就是瓶颈所在，瓶颈是站会第一重点关注点，因为系统的流量往往是由瓶颈决定，只有解决了瓶颈问题，价值才能顺畅地流动。看板上的表现就是某一列的需求卡片数量特别多。关键的缺陷：缺陷会阻碍需求的流动，而且缺陷多容易出现需求积压，从而阻碍其他需求的流动。阻塞需求流动的缺陷需要及时解决，期待做到缺陷日清（缺陷发现后24小时内解决，甚至当天就解决），在Fixed状态（指缺陷已修复，待提出缺陷者验证）的缺陷需要及时验证和关闭。保持缺陷及时发现即时解决和关闭，保持存量缺陷保持低水位。站会时需要抽1-2分钟过一下整体缺陷的状况。重点关注的需求：指涉及重点商业利益或风险的重点需求，看板上会用红色的标签来凸显。阻碍和问题：指因外部（如依赖）或内部（如设计缺陷）原因无法正常流动的需求。团队需关注被阻碍的需求，跟踪和推动问题解决，及时恢复它们的流动。看板上会红色的阻碍项来标记。到期或即将到期的需求：部分需求有明确的完成时间要求，例如存在对外承诺的需求。如果它们即将到期或已经到期，就需要特别关注，以确保承诺的达成。看板上快到期的需求会用橙色凸显时间，已到期的需求会用红色凸显时间。中断：指某个步骤供给不足，价值流出现中断，如上图中，就绪（待开发）这列没有需求，此时上游队列需要尽快供给到该列。未反应在看板上的问题：走读完看板，还需要添加一个问题：“是否有为反映在看板上的问题需求沟通”。团队当然需要关注没有反映到看板上的问题，同时，团队和站会的协调人需要有意识地思考，这类问题是否可以和应该反映在看板上，以提高可视化和执行的效果。站会中：促进价值顺畅流动站会上，团队按照"站会重点关注信息6+1"从右向左检视各列，促进价值顺畅流动，同时要避免在一个问题上花费过长时间，耗时长的讨论要放在会后小范围进行。15人以内的团队，站会要能在15分钟内完成，在现实中，效果不好的站会，往往耗时会比较长。站会中讨论带来的变化，需即时更新到看板上，如有问题，也需求及时记录。下图给出了站会中应该做到和应避免的问题：还需要明确的是，站会只是团队沟通的一个场景，更多的沟通要在平时和更小范围内发生，而不是过度依赖于站会。站会后：信息透明，风险和问题跟进站会需要达成的成果：看板已处于最新的状态，反映站会讨论的结果识别阻碍需求流动的问题，并现场解决或则安排会后跟踪的Action团队成员了解项目的整体进展和状态团队成员清楚工作的优先级会后小范围讨论需求较长时间才能解决的问题。总结：站会的目标是：促进团队有效协作和聚焦，促进价值顺畅流动和交付站会要以价值交付为线索，从右向左检视需求的状态，聚焦于发现和处理价值流动中的问题不应该依赖站会检查每个人的工作，价值交付的状态和问题应该已清晰的体现在看板上，良好设计和应用的看板是高效站会的基础更多的协作应该即时发生，不应该完全依赖站会来进行团队协作一个好的站会，帮助团队了解整体的价值流动状况，促进有效的协作，并即使处理价值流动的问题，保障价值顺畅流动。附1：站会Checklist:需求和任务的状态在站会前已更新；提醒带电脑同学合上电脑，只有投屏的同学使用电脑；从右往左检视各列，按照6+1类关注点进行；开发中的需求数量是否已超过卡片数量的限制；开发中任务是否向需求对齐；需求是否按照既定的流转规则进行流转；单独快速过一下缺陷的总体状况，保持缺陷库存低水位；记录要跟踪的问题和依赖项；会后小范围讨论遗留要解决的问题；附2：站会中会碰到的问题：Q：在Scrum站会中，典型的形式是团队围成一圈，依次回答三个问题：昨天做了什么？今天准备什么？有什么阻碍或问题？为啥看板上不需要回答这三个问题了呢？A：看板方法应用得当，可视化价值流实践执行到位，以上三个问题完全可以清晰地展示在看板上，所以没有必要再回答这些问题了，同时我们需要按照需求来组织站会，关注价值流动，而不是按人来组织站会。Q：开发同学站会上讲了很多，可产品经理同学却听不懂，同时对需求的进展也不太清晰A：按照Scrum的方式，回答三个问题，开发同学往往说的是技术实现和细节，产品经理自然会听不懂。需求作为价值是产品经理的输入，看板关注的是价值流动，不是任务的完成情况，需求的状态和问题可以很清晰地在看板上体现出来，同时在开发中的需求也会拆分成各端或各模块的任务，拉通技术各角色之间的协同。这样既可以看到价值的流动，也可以看到任务的进展和对齐，产品和开发同学都可以一目了然知道目前的进展与问题。Q：为啥看板要从右到左检视各列，而不是从左到右检视呢？A：从右往左，一方面体现价值拉动的方向，另一方面是为了更好地贯彻“暂缓开始，聚焦完成”的原则，让接近完成的需求尽快的完成，而不是开始更多的需求开发。譬如测试中发现的Bug，从右到左更方便优先解决Bug。Q：站会时间到了，但还有个别同学没有到，是等他还是不等？A：团队需要共识此类事情发生的机制，避免这样的事情发生。当确实有个别成员迟到了，一般建议站会还要在固定的时间和地点进行，当然团队对于迟到可以有团队处理的办法，譬如邀请迟到的同学给大家买水果吃等等。Q：团队处于两地，甚至多地，站会如何开？A：电子看板的好处就是便于异地开发，各地成员都打开看板页面，同时用电话会议的方式接入，进行异地站会。目前Aone看板已可以做到需求卡片移动后瞬间同步。Q：两个需求都进行了近一半却都不能提测？如下图A：图中用红框圈起来的两个需求，一个是前端任务已完成，后端任务在处理中，另一个是前端任务在处理中，后端任务已完成，这总情况需要避免，团队需要聚焦其中一个需求，让其快速完成，而不是启动两个，让两个都只是完成一半或90%。附3：团队开站会的照片：Aone（云效）协作域团队信息平台诉讼团队阿里云飞天一部工业大脑CEM客户运营平台的物理看板的站会站会上很多人都带电脑，效率就会相对低，不建议出现这种情况。作者介绍：洪永潮（花名：舍卫），现就职于阿里巴巴研发效能事业部阿拉丁团队，先后负责手猫、手淘、天猫新零售等阿里内部多个部门的效能提升，曾担任MPD、GIAC、RSG、 DOIS等大会的讲师。关于云效：云效，一站式企业协同研发云，源于阿里巴巴多年先进的管理理念和工程实践，提供从“需求->开发->测试->发布->运维->运营”端到端的协同服务和研发工具支撑。支持公有云、专有云和混合云的协同研发，助力企业产品快速创新迭代和研发效能升级。云效产品：项目协作 https://www.aliyun.com/product/yunxiao-project代码托管 https://promotion.aliyun.com/ntms/act/code.htmlMaven公共仓库 https://m.aliyun.com/markets/aliyun/ali-repo制品仓库 https://m.aliyun.com/markets/aliyun/repo-manage持续交付 https://www.aliyun.com/product/yunxiao-cd测试平台 https://www.aliyun.com/product/yunxiao-testing本文作者：云效鼓励师阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：复盘是项目结束后必不可少的阶段，好的复盘会议能够有效地促进团队成长。今天，阿里项目管理专家鹿迦以自身的经验，为大家分享如何做好一个项目的复盘。这篇文章分成两个部分，第一部分简单阐述对这种回顾会议的理解，认识会议的真正价值；第二部分是分享个人操作的团队回顾会议流程。在阿里天猫新零售的天地会项目中，因为我参与的团队是成立不到2个月的feature team，再加上团队成员来自于多个不同的BU（有钉钉的、天猫新零售的、手淘的），团队处在一个快速磨合成长期，在合适的节点上开展一个有效的团队回顾会议（也可以叫做复盘会议）可以对团队成长和进化起到一个非常明显的加速作用。抱着这样的信念，我们上周组织了一个团队回顾会议，基于团队成员的反馈这个会议算是取得了令人满意的结果，大家不仅加深了相互的了解、公开暴露了一些团队中隐藏的问题，更帮助大家对这些问题做了比较深入的探讨和分析，并产出了可落地的行动。一、我理解的团队回顾会议回顾会议（retrospective meeting）是来自敏捷方法scrum，这个会议是Scrum检视与调整的一个重要的环节，在这个会议上，我们鼓励团队对自己的开发过程进行改进，并确定什么样的调整可以使下一迭代的效率更高、结果更令人满意和更易于工作。就像我们频繁的迭代和交付是为了快速地获得外部用户的反馈，进而帮助我们做产品需求的调整一样，每个迭代的回顾会议就是想更快地得到大家对团队工作问题和改进点的反馈，帮助团队内部的工作效能和能力的不断提升。但是开好回顾会议并不简单，甚至我认为回顾会议是团队中最难开好的一个会议，但开好了也是价值最大的一个会议。我们整理了一下，认为这个会议可能达到的五个层次：单向宣讲式的回顾会议：团队管理者事先完成了整个回顾分析，会上只是面向团队成员做一个回顾结论的宣讲和说明。很明显，这种层次的回顾会议不仅很有可能不能发现团队最重要的问题，更不利的是很难让结论取得团队成员发自内心的认同。各自表达式的回顾会议：团队成员没有真的想敞开内心参与回顾会议，往往只是迫于会上的点名而击鼓传花式地各自讲自己的内容和观点，对其他人的观点没有回应，也没有质疑。这是明显的团队成员害怕冲突的表现，团队成员之间没有真正的融合，背后真正的问题可能是没有建立团队成员之间的信任。争论推责式的回顾会议：大家抢着发言，但是气氛紧张，经常有不礼貌地打断他人讲话的情况出现，大家都极力避免责任被认定到自己的头上，往往需要老板在最终的时候决策。定责式的回顾会议是我们需要极力避免的，这个不是我们回顾会议的目标，定责的行动往往会导致大家关闭沟通的门，导致真正的问题被掩盖。发散讨论式的回顾会议：回顾中抛出的问题很多，讨论的的过程中往往还会从一个问题跳跃到其他问题上，导致会议中涉及的论点不断发散，最终往往由于问题过多，没有时间也没办法形成能落地的结论。没有结论的会议，也就没有办法拿到最终的会议价值。聚焦共创式的回顾会议：明确回顾的目标是通过团队共创的方式发现团队持续进化的机会，鼓励大家用坦诚、合作、成长的心态挖掘团队改进的机会，并通过区分优先级以在最有价值的机会点上切实落地改进的行动。这个层次才是我们理想的情况，是我们追求的目标。二、可参考的回顾会议流程我们操作的回顾会议基本流程是参考了《Agile Retrospectives》这本书中所划分的会议5个阶段：准备收集数据产生见解确定改进项结束会议那我就按这几个阶段来讲讲怎么做。2.1 准备准备阶段其实是非常重要的，一些初次主持回顾会议的同学往往会忽视这个阶段，一上来就让大家写小卡片，这样不仅效果不好，次数多了更给人枯燥重复、走形式的感觉。准备阶段我往往会选择做下面几件事：设定一个安全的环境回顾会议不仅仅希望大家能参与进来，更重要的是能敞开心扉，大家没有顾虑地把问题暴露出来，找到改进的办法。但事实是肯定有人担心回顾会议会成为一个批判会议，在认为这个会议的目的是找到这个迭代中犯错的那个人，并把他拎出来痛批一顿，看以后还有谁敢再犯。如果这样大家肯定会有所保留，担心说错话，会议上就找不到真正的问题。一般我们会直接声明这个会议的目的，绝对没有想追究任何人的责任的意思。不仅如此，我们还需要在会议过程中避免讨论任何个人责任的问题。了解与会人的心态这是个很有意思的事情。会议本来就令人沮丧，更何状是回顾会议这种看似是锦上添花的会议。与会者都是带着什么心态来参加的呢？这里有一种非常有意思的收集与会者心态的小活动，叫做“ESVP”：Explorer （探索者）Shopper （推销者）Vacationer （度假者）Prisoner （囚犯）这四个角色代表了四种与会的心态，可以通过与会者不记名的投票（匿名的在贴纸上写上代表自己真实心态的角色首字母），统计完现场公开结果，就能知道会议室里大家的实际心态情况。统计的结果不一定总让人欢欣鼓舞，但这个小小的活动往往能有效的唤起大家内心的思考，帮忙确定会议的基调，很有价值。激活大家的发言欲望事实证明，一个会议上，如果一开始大家就可以不需要发言，只是听，那么很大机会大家在整个会议上都将保持沉默，没有什么想说的，尽管会议中后期你希望更多人参与发言。办法是一开始就破冰。简单常用的方法是让大家按座位顺序轮流用一个词形容他/她对这个迭代的感受。只让用一个词说实话非常难，不过没关系，这个时候大家就会开始脑子飞快的转起来了，到底哪个词比较合适。这样不仅把大家带到了回顾的思路里，更重要的是大家一开始就有机会开口表达自己的想法了。把大家带到这个迭代历史的回忆中来在开始收集数据之前，让大家先回忆这个迭代到底发生了什么，这个至关重要，不然暴露的问题很可能变成天马星空的抱怨。上面用一个词描述这个迭代的感受是一个很好的方法，但除此之外还有心情曲线法也是很有意思的方式。方法很简单，就是让大家画一条基于时间轴（标注团队的关键时刻或里程碑）的心情曲线。如图是一个团队真实的曲线结果，每个人都不一样，分享这个曲线的过程甚至能加强团队成员的相互了解，加强信任感。2.2 收集数据收集数据一般包含收集做得好的部分，做得不好的部分，有时还会创新想法部分。这个环节是回顾会议最具代表性的，发贴纸，然后大家各自写，一个问题一张贴纸……如下图就是一个真实的例子：上面这个方式用得非常广泛，就不多讲了。除此之外还有一些变形的方式：通过视觉化的、隐喻性的方法做引导，比如帆船回顾法。模拟论坛接力留言的方式，一个问题一张A4纸，大家按顺序传递加上自己的简介，通过书写来收集数据。2.3 产生见解收集到了数据只是第一步，如果顺利，到此为止我们就能收集到大量的、反应真实情况的好的和需要改进的点。接下来我们需要整理了。先分类，因为大家是各自独立写的，所以肯定会有重复的，所以把同类的放到一起我们才能让满墙的纸片不那么凌乱。分类需要花一点时间，但这个过程也是刚好让大家都了解其他人写了什么的好机会，所以我往往会邀请组员上来和我一起来做分类，一个人做卡片宣读，允许大家讨论，一个人把相同意思的卡片贴到一起。对做得好的部分，我们需要提出来鼓励大家，希望我们能坚持下来，甚至做得更好。这个部分在实际操作中往往比较忽视，大家更愿意快点调到待改进部分。无论如何，如果发现团队士气低落，需要鼓励的话，这时就是很好的机会，每个做得好的地方你都能有感而发。对待改进的部分，这个是本次会议的核心内容，不过很不幸，往往团队总结出来的待改进方面会比较多（>5个就算多吧），可会议时间有限，对这个部分，我们首先要做的就是确定优先级最高的核心问题（不超过3个）。确定的办法最常用的就是投票，比如每人两票。2.4 确定改进项当我们确定了待改进的重点之后，我们就需要讨论得出针对这些问题的改进方案。不过别急，不要这么快就跳到了改进方案上来，针对问题我们要先分析问题的根源，找到问题最根本的原因，我们再针对原因采取改进行动，这样才能对问题做到根本的解决。鱼骨图或5W的方法寻找问题根源最常见的方法有鱼骨图法，如下图，使用方法就不解释了，大家自己google。还有一个理论就是5个WHY，也是一个很好用的方法。分组讨论讨论寻找问题根源的的过程往往非常费时，这里常用的一个方式是把组员分组，每个小组专门讨论一个问题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度。SMART的改进计划一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行。这里给大家一个小窍门，在每产出一个action的时候就问一下大家“这个action可以执行吗？能判断是否完成吗？”，这样往往就能帮忙准确判断是否SMART。避免产出过多改进计划当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。2.5 结束会议结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力。但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后，我会请大家当众宣读一下卡片内容，并亲手交给自己感谢的人，纸片格式如下：三、提供几个需要注意的地方一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。会议产生的改进计划怎么有效地跟踪？一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效地使得改进落地。前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。本文作者：鹿迦 阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。

写在最前：纯属吐槽，随笔，勿喷！就在前些天，下班回家的路上，看到群信息，说：听说京东裁员了～，也是在上上月，也一度被传的沸沸扬扬的：阿里、京东、华为相继被曝停止社招，新闻也是满天飞舞，不管是裁员，还是停止社招，这些事情没有落在亲身经历，没有落在自己身上我们都会觉得不痛不痒，毕竟一个旁观者，永远无法感受当事人的喜怒哀乐～。俗话说：人无远虑 必有近忧，假如当你遇上裁员，又该如何面对~今天看到这个新闻，第一时间想到的是自己，当然啦，大家别慌，我没有被裁，不用紧张，工作几年下来相信大家或多或少遇到过一些要么自己、要么身边的朋友、同事，都有过一些欠薪、公司倒闭、团队解散甚至裁员的事。嗯，还有刚刚过去的掘金往事不堪回首为什么说想到自己呢？我没有被裁过，但团队解散过，这个事情得从去年说起：从毕业到现在，工作也有些年头了，这些年多多少少也遇到过一些机会，2014年中旬，一个阿里PHP大佬，自己创业，做婚庆的电子请柬，记得那个时候特别流行H5移动微场景制作，某企秀、兔*，之类的公司应风而起，包括到现在好像也还做的不错，当时是兼职业余时间帮做一些前端工作，一直持维了近一年时间合作的都很不错，后面更是亲自邀请我让去他公司玩一下，来回车票都包销（公司在湖南），再后来提出让全职去他公司(合伙性质)，基础保底年薪是20W，但最近因为不在深圳、觉得项目并不是特别看好等原因放弃了～15年左右，当时是在个游戏公司，有个领导出去创业，当时拉了几个团队的同事，其中也有我，是的，结果你已经猜到了，我最后没有去，主要受当时所在的游戏公司部门的产品经理特别变态、真的特别变态，天天加班到12点，早上晚到一会，开会点名批评(公司是有这个福利的，加班晚第二天能晚到)，说我们部门不能搞特殊（到底谁在搞特殊？？），要按时上班，当时一度特别烦躁，想着去了创业公司……。…… 中途也有小米公司，某部门新组件的研发负责人的邀请，这些都是后话了，就在去年、对去年，今天都还清楚的记得2018-07-26，这天去了前面提到的解散的公司报到，当时也是之前某公司的领导找到我，说他将出任某公司研发总监职位，新成立的子公司，问我是否有兴趣一起，在考虑过综合因素后最后决定去了，主要是公司也在深圳、薪资是有涨幅的，更重要的是了解了一下母公司的背景(挺强、有干爹的那种`)资金方面不会出问题，钱都不是问题了，未来钱途还是问题吗？回头想想这些年，因为种种原因，错过了很多机遇，随着年龄的增涨，是时候博一下了(哪怕是失败，自己也并不会损失什么)，跟几个不错的朋友也讨论过后，也认为觉得一次不错的机会，所以就欣然前往了，公司是从0开始的，一切都是从0开始的，包括第一行代码都是从0开始写的，每一天都是从早到晚的在忙，赶着把产品上线，几乎每天都在加班，但团队的每个同事们都毫无怨言，因为这些都是在已知的预料之中。日复一日，产品迭代了又迭代、APP、PC端、小程序等都陆续上线，慢慢走上正轨，业务也开始接入，团队成员都感觉看到了胜利的曙光。然而，人在家中坐、锅从天人上来，暴风雨来临的总是显得特别的宁静，在3月初中旬左右(往事不堪回首～)，周末还约了同事一起穿越了南澳东西涌。新一周周一，一如往常的去公司上班，刚坐来，准备大显身手，开始元气满满的一天，领导发来消息让去他办公室一趟，后面说了些公司的情况：大概意思是总部对于子公司业务、管理层的不满，做采取一些措施，但这个不会影响到下面员工等等之类的，他可能也会有所变动等，提前跟我说一下。然后又过了没有几天，领导叫去了全部leader，说总部出于某些原因，子公司可能不会再投资了～～，是不是很棒棒？？晴天霹雷～、刺激不？？第一反应是先来让几个深呼吸、再呼吸，然后轻轻的扶住墙、嗯，扶住墙～上右图为公司一同事当时的感慨～事情已经这样了，后面也就不用再继续讲了，我没有遇到过裁员，但我经历了团队解散，是不是很优秀？？看到这里，可能有些同学会认为我的经历的些扯了，合伙是假，压榨、利用、……等是真的；但我想说：如果你遇到这样的事情，应该值得高兴，至少还有被压榨、利用的价值，换个角度讲，凡事没有绝对的公平，任何事如果没有一定的利益关系捆绑，都难以长期维持，所以不存在利用一说。至少我觉得自己很棒，能得到大家的认可。如果你连利用的价值都没有，那么恭喜你，裁员标签，可能就要落在你身上了，前路在何方？说了这么多，其实是想表达不管是裁员、欠薪、还是团队解散，当这样的问题发生时？我们该怎么做、怎么做、怎么做呢？？我只能说送上四个字：## 未雨绸缪 ##首先，好好跟公司沟通，维护好自己应有的权益，哪怕仲裁，这点不可妥协～；其次 ，不要因为这种小意外，而否定了自己能力，自信的人最美（你永远是最棒的），此处不留爷 自有留爷处。然后 好好静下心来，好好复习准备下一份工作，只要你活好，走到哪里都不怕，条条大路通罗马，你的星光大道就在前方；最后，也是最重要的，工作之余，我们也应该多关注一些技术的发展趋势，不断的学习，强化自己的专业技能，才能不会被时代的洪水淹没。特别是近两年，互联网一直处理一个高速持续的过程发展，前端更是如此：React、Vue、Angular等，甚至还有衍生出的 React Navite 、H5的新特性dialog、showModal()等等，常常会有网友在调侃老了、学不动了，调侃的同时却又阐述着无奈，迫于生活的压力，不得不提速前行。未来的路我们是无法预知的，谁都不知道明天将会发生什么，我们能做的就是未雨绸缪，在事情未发生之前，自己多做、多想、多学。一入IT深似海，从此妹子是路人，最近不是React、Vue都发布了新版本吗？好好学吧????。以上来自突然的一些想法就吐槽一下（勿喷），给自己一点危机感，不管裁员/团队解散是否属实我们都努力前行，加油，你是最棒的。欢迎关注公号：IT平头哥联盟，一起学习进步更多文章：webpack4配置详解之常用插件分享webpack4配置详解之慢嚼细咽如何给localStorage设置一个有效期作者：苏南 - 首席填坑官链接：http://susouth.com/交流：912594095、公众号：honeyBadger8本文原创，著作权归作者所有。商业转载请联系@IT·平头哥联盟获得授权，非商业转载请注明原链接及出处。

这是一篇译文，觉得它很不错就把它翻译了一下。原文名为 8 Tips for Great Code Reviews，这篇文章不管是对提升个人编程素养，还是协调团队间的合作都有一定的指导意义。在学校里没有教给你的一项本领就是怎样做一个好的代码审查(CR)。你学习了算法、数据结构、编程语言的基础知识，但没有人会坐下来对你说:“下面是如何确保你能获得很好的反馈的方法。”代码审查是创建优秀应用的关键过程。经过审查的代码往往质量更高，bug更少。健康的代码审查文化也提供了额外的好处：限制了巴士因子，它是培训新成员的一个很好的工具，代码审查是分享知识的好方法。在我们深入讨论之前，有必要对这篇文章中的观点限制一下适用环境。限制条件是：你在一个信任的环境中工作，或者你和你的团队正在努力提高你的信任。你应该能够在非代码场景中交付反馈，或者在团队中交付反馈。你的团队希望生成更好的代码，并且理解完美是一个动词而不是形容词。我们明天可能会找到更好的做事方法，我们需要保持开放的心态。你的公司重视高质量的代码，并且理解事情可能不会“交付”得那么快。“交付”是用引号括起来的，因为很多时候没有经过测试和审查的代码可能根本无法工作。既然我们已经指定了一些基本限制条件，那么让我们开始吧。1. 我们终究还是人要知道有人会在你要检查的代码上花时间。他们希望它是伟大的。你的同事的行为是出于好意的，没有人想要发布糟糕的代码。保持客观很难。确保始终对代码本身进行评论，并尝试在上下文中理解所编写的代码。尽你所能的把偏见去掉，不要这样说：“你用一种使人困惑的方式写了这个方法。”，试着换一种说法，把事情说成是关于代码本身和你对它的解释：“这个方法让我有点困惑。这个变量有没有更好的名字?”在这个例子中，我们解释我们作为读者对代码的感受，这与自身的行为或意图无关。它是关于我们和我们对代码的解释。每一个拉请求（Pull Request）都是一个艰难的对话。试着与你的队友达成共同的理解，并一起朝着更好的代码努力。如果你只是了解一个团队成员，并且你对拉请求（Pull Request）有关键的反馈，那么一起浏览代码。这将是开始与同事建立关系的好机会。和每位同事这样做，直到他们不再感到尴尬。2. 自动化如果电脑能决定并执行一条规则，就让电脑去做吧。在空格和制表符之间争论并不是对人类时间的有效利用,相反把时间花在就规则应该是什么达成一致上。这些机会可以让你看到你的团队，在低风险的情况下如何处理“不同意和承诺”。现代的编译语言工具和语言可以开启语法检测功能，并反复使用它们。在Ruby中，有Rubocop；在JavaScript中，有eslint；在CSS中，有stylelint。找到你需要的语法检测工具，并将其插入到构建工具中。如果你发现现有的语法检测工具动力不足，可以尝试写你自己的！3. 每个人都是代码审查者将所有代码审查责任都交给Shirley，咋一听来是很有诱惑力的。虽然，在编写代码方面，Shirley是一个奇才，她总是知道什么是最好的，她了解公司制度的来龙去脉，而且她在公司工作的时间比你们团队的集体任期还要长；然而，Shirley理解了这些事情，并不意味着她的团队中的其他人也都理解。年轻的团队成员可能会犹豫是否要在Shirley的代码评审中指出一些问题。我发现将评审分发给团队的不同成员会产生更健康的团队动态和更好的代码。一个初级工程师在代码评审中最有力的一句话是：“我觉得这很混乱”。这些都是使代码更清晰、更简单的机会。推广这些评论。4. 增强可读性我们使用GitHub来管理我们的代码项目。几乎每个GitHub上都支持Markdown，这是一种向评论添加html格式的简单方法。拥抱Markdown是让代码变得更加可读。GitHub或你选择的开发工具可能有语法高亮显示功能，这对于插入一些代码片段非常有用。对于内联代码使用单回勾()或者对于代码块使用 （``）可以更好地交流思想。熟悉标记语法，特别是在注释中编写代码时。这样做将有助于使你的评论更加具体和集中。5. 至少留下一句积极的评论代码审查本质上是负面的。在把代码发送之前，告诉代码的作者这个代码有什么问题，这是基本。但有些人在这这个代码上面花了时间，他们希望你能指出怎样才能做得更好。因此，至少留下一句正面的话。让它有意义和个性化。如果了解到他们一直在努力的解决问题，那就大声喊出来，这可以简单 ???? 或 “Love this.”在每个代码评审上留下一些积极的内容，可以微妙地提醒我们，我们是在一起的。如果我们创建更好的代码，我们都会受益。6. 提供替代方案我常常尝试着去提供一个可替代的实现方案。对那些只学习了一门语言或框架的人更应该如此。当要注意表达的方式。如果表述不正确，可能会让人觉得你傲慢或自私。“尽量保持客观，并讨论你所提供的备选方案的利弊。”如果做得好，这将有助于扩展每个人的技术知识。7. 审查延迟保持一个极快的代码审查速度非常重要的。(实现这个规则很简单：保持审查代码足够小。)长时间的代码审查延迟会扼杀生产力和士气。如：“3天前，你被分配去审查一份xxx的任务”，这听起来很刺耳。如果你希望减少自己的审查延迟，我建议遵循以下规则：在编写任何新代码之前审查代码。作为一种直接处理延迟的策略，尝试在代码评审上进行配对。启动一个屏幕共享来浏览和讨论评论。对解决方案进行配对，使代码达到批准的状态。8. 对于发件人来说：保持内容尽量小你在代码评审中收到的反馈质量将与拉请求(Pull Request)的大小成反比。为了最大限度地保持反馈的尖锐和建设性，要知道较小的请求会让读者更容易接受。如果你的拉请求（Pull Requests）很小，怎么办？这时你需要有一个不同的地方来进行详细的描述。如：这个单一的拉请求（Pull Request）如何适合本周或本月的工作？我们要去哪里，这个拉请求是如何让我们到达那里的？这种对话类型的方式在表现效果方面是很好的，因为对于较小的Pull请求，你很难记住它的编写上下文。小 这个概念会因语言的不同和团队的不同而不同。对于我自己来说，我试图让Pull请求总数少于300行。结论希望这8个技巧能帮助你和你的团队有更好的代码审查。通过改进代码审查过程，你将拥有更好的代码、更快乐的团队成员，带来更好的业务。

本文转载自我的博客Git 可以说是目前最受欢迎的版本管理工具了，很多团队也都在用它来管理自己的项目代码。在一个多人协作的项目中，往往采用的是一个分支一个特性进行开发，随着每天的代码提交、合并，仓库中会有越来越多的冗余分支。这么多死分支不仅会掩盖真正在使用的分支，而且也为管理带来不便。如果你像我一样，也经常被淹没在 git branch 或 git branch -r 返回的分支大海中，那么，就是时候考虑给你的 git 仓库做一次大扫除了！本地分支与远程分支大扫除之前，首先给自己做个深呼吸，回忆一下远程仓库和远程分支的概念。我们本地的仓库既保留有本地的分支，也保留有跟踪远程仓库的 remote 分支（类似 remotes/origin/** 这种的）。后者相当于是远程仓库分支在本地仓库的代理，每次 git fetch 或 git pull 时，都会将远程仓库的分支同步到本地对应的 remote 分支上。比如远程仓库新增了一个 feature/add_a 分支，那么我们在本地 git fetch 后，会得到一个 remotes/origin/feature/add_a 分支，这个名字表示 origin 这个远程仓库下的 feature/add_a，origin 是本地给远程仓库默认起的名字，你当然也可以改成别的名字。理清楚了本地分支和远程分支，本地仓库和远程仓库，接下来我们就动起手来做清理吧！本地分支清理查看我们本地的分支只需要执行一下git branch我们还可以找出所有已经合入到 master 的本地分支git checkout mastergit branch –merged针对这些已经合入的分支，如果确定已经不会使用的话，就可以将其删除了git branch -d feature/XXX如果十分确定所有合入的分支都不再需要了，那么可以考虑一次性解决（(^*) 是匹配当前分支，其余 (master|dev) 部分可以根据自己项目的实际情况进行修改）git branch –merged | grep -v “(^*|master|dev)” | xargs git branch -d这么一来，就可以安全地删除所有已经不再需要的分支了。除此之外，也可以浏览一下没有合入 master 的本地分支，检查看看哪些分支已经废弃，不需要继续开发了git branch –no-merged针对这些分支，只用 git branch -d 命令会收到系统的善意提醒。如果十分确定可以删除，那么可以使用强制删除命令（一定要确认好啊）git branch -D feature/XXX经过这么一番清理，相信你的本地分支现在已经十分轻佻了，git branch 返回的结果看起来也十分清爽。接下来就来清理一下本地的远程分支。远程分支清理远程分支的查看只需要在 git branch 命令加一个 -r(–remotes) 参数即可git branch -r远程分支的清理，一方面是清理远程分支中，已经合入 master 的分支，另一方面是清理远程仓库已经删除了的分支，而本地还在跟踪的。第二种情况的清理非常简单，只需要执行git remote prune origin事实上，我们可以在每次 git fetch 时，添加一个参数 -p (–prune)，这样每次 fetch 远程仓库时都可以顺手删掉本地多余的分支（建议将 git fetch -p 直接 alias 到 git fetch 命令~）。再来看第一种情况，虽然同样可以通过 git branch -r –merged 来查看已经合入 master 的分支，但由于远程分支不只是自己开发的，所以还需要别人的确认才能进行删除。好在我们可以在命令行的帮助下快速筛选出每个人的分支，然后就可以把这份统计摘要发给 TA 来确认。for branch in git branch -r --merged | grep -v HEAD; do echo -e git show --format="%ci %cr %an" $branch | head -n 1; done | sort -r | grep AUTHOR_NAME这行命令首先是过滤出所有已合入 master 的远程分支(git branch -r –merged | grep -v HEAD)，然后遍历每个分支，展示(git show)其最后一次提交的绝对时间(%ci)、相对时间(%cr)和作者(%an)信息，按时间倒序排列(sort -r)，最后过滤出作者是 AUTHOR_NAME 的分支。如果想查看更多的信息，可以在 git show 的 format 加上 %s（提交信息）和 %h（commit SHA1 前缀）这样一份报告，给到相关开发同学，确认之后，就可以执行批量清理了。注意，远程分支的删除应该到远程仓库去删除（否则下次 fetch 还会再拉下来），因此需要我们把这个删除动作 push 到远程仓库。最后，如果你 push 了删除动作到远程仓库，不要忘了提醒下其他同学 git fetch -p 来同步删除自己本地的远程分支哈！git push origin –delete feature/YYY找找我是谁如果自己经常换机器开发、push 代码，而且不同机器的 git config 不完全一样的话（比如我不同机器上 user.name 有的是英文名有的是中文名），提交的作者签名也不一样，这时还需要根据不同的 user.name 进行查找……不过好在我们有命令行，用以下命令就能得到仓库里所有提交过的作者了~git shortlog -s ...