背景

近年来, 在组织团队的任务跟进方面, 存在一部分欠缺, 存在进度滞后的现象. 进展存在阻塞, 但是又没有及时感知到, 申请杨州哥等协助, 导致问题长期阻塞的情况.

因此在这里整理了一下目前主要的几个诉求.

诉求

记录和评估方面

  • 工作量记录
    • 预研类不可预计的工作量, 当存在ddl时, 如何确保人力是否需要追加
    • 繁琐的必须做的任务的工作量, 当存在坑时, 需要能够识别.
    • irdms有工作量任务统计要求, 所以总体的时间是需要同步到这里的.
  • 利用团队的力量 共同解决难点(PS. 从产出角度, 如果是已经踩过的坑, 让新人快速绕过, 最省时间, 同样产出最大化)
    • 存在阻塞或者坑时, 能够让其他人也发现问题, 看看是否能够共同解决
    • 能够识别出踩坑后耗时的工作量, 用以区分是否有新发现, 还是进入到了错误的分支
  • 避免无效任务
  • 工作量和产 出价值 符合 对应的水准
    • 是否显著的可评分?
    • 由于大部分水平是相近的, 其实大概输出的概率是相似的
    • 根据表格识别出绩效优劣, 直接输出结果.
      • 这种严格需要一个综述概况的表, 难度较高
    • 团队整体评估 预计任务的工作量? 然后咱们算加权平均? 来代表这个任务的难度? 然后产出的时候就拿完成的任务的工作量来比较?
      • 感觉可以, 这样至少每个任务都是大家全部参与过评估的了?
      • 有异议的则增加具体的评估理解, 然后多轮次达成一致.
      • 紧急需求和重要慢慢做的需求, 其实评分可以靠近的.
      • 一些任务的完成情况的评价? 还是相关人员的复盘?
    • 调研类, 无法评估时长的这种? 则另说, 看调研后的产出和用时吧?
      • 估计大部分情况下, 产出的评价是很贴近的. 怎么才能拉开区分度呢?
  • 任务描述, 如何体现价值?
    • 同样写一句话的任务, 复杂度肯定是不同的. 怎么评价呢?

进度同步

  • 站立会 进度同步
    • 关键任务 和 阻塞的内容, 口头简述
  • 任务详情记录
    • 继续在任务上继续详细信息
    • 一眼直观可见每个人/每个大OR任务进展, 不必具体点进去
    • irdms记录任务长期计划
    • hikke拆解详细子任务, 建议子任务不超过16小时.

任务安排

  • 杂活如何安排, 一些比较耗时的工作, 产出角度可能没那么大.
    • 十分需要领导的理解, 领导在判定这部分时, 需要理解其确实有工作量. 接收该任务的人的评估要求需要适当放低. 比如合格起步.
  • 难度较高的模块, 当出现没人能解决的问题时, 此部分时间可以接受.
  • 难度可能适中的模块, 如果阻塞的问题实际上其他人可能解决过, 这部分的时间是可提升的. 所以需要通过一个手段比如站立会, 快速感知. 而不是长期被阻塞在其中. 评估标准中, 是否有人协助并不那么重要, 不过复盘时, 如果没有站立会, 确实需要一个这个来体现任务的难度.
    • 另外有人协助的模块和没人协助的模块
      • 没人协助的是否需要增加评价?
      • 如果有人协助, 协助的人应该加分在团队协作层面吧?
      • 然后主任务的进度如果落后了, 这个属于个人水平过敏啊
      • 不过像是一个全新的组件, 没人协助是正常的, 这种情况下耗时久咋算呢?
      • 学习曲线, 评估是
  • 关键任务安排
    • 关键任务. 是否要搞成基本很赶的那种? 是否要给一些自定义的任务时间? 关键任务要平均分吗? 还是

初步计划

  • 初期将OKR拆解成大任务, 周会等中间采取JIRA看板方式同步具体进展.
  • 周会
    • 同步OKR进展(根据每周站立会进展, 可以确认是否需要变更, 然后绩效的任务也跟着变化即可)
      • 通过在周会中确认进展是否恰当, 是否存在滞后
      • OKR, 提供整体目标, 然后具体任务都是为了这个目标服务的. 基于这个整体目标, 大家可以自行对任务进行调整.
      • 整体目标是固定的, 然后任务的细节是会随着调研或者开发过程中逐渐发现问题而调整的.
    • 月度总结, review整体进度, 然后确认.
      • 似乎跟周会存在重合, 先实践再确认月度是否需要?
    • 拆分详细的周目标和 月目标用?
  • 站立会
    • 通过站立会把存在的障碍, 和需要的帮助协调了. (口头沟通即可, 无需记录. 具体记录的还是个人通过任务和进度来记录)
    • 每天下午5点做站立会吧? 这样刚好?
  • 大任务进展同步
    • 超过16小时的任务, 拆分下一步计划, 将任务明确. 以细节来理.
    • 大任务到底单独跟进
    • 输出具体目标的大任务的每日进展的表? 通过hikke平台进行吧 这个就不通过那个irdms了, 不方便记录和复盘.
    • 这个hikke 是用于闭环所有任务? 还是仅关键任务呢?
      • 需求列表里肯定是把所有大任务都给描述上. 那一些小任务, 是在irdms那里自己添加? 嗯
  • 评估的时间不准确, 或者预计耗时长, 无法让项目经历认同很正常, 此时就应该拆解出具体的任务细节, 以及实际过程执行的效率来有理有据的说明, 达成一致后, 再上升领导看增加人力或者调整任务计划.
  • 耗时优化则通过规范化,流程化方案, 进行配置管理, 减少重复的投入
  • 敏捷在这方面的考虑可能更倾向于拥抱变化, 及时更新计划.

可参考指标

统计开发工时, 可以通过irdms查看统计的工作量和一些日常任务的分类占用时间.

这部分可以用于参考, 和考虑将一些占用时间多的赋能给其他部门进行.

调研

白盒的前提的基础模板最好是有一个经过迭代验证过的计算模型, 否则白盒可能带来更大的不公正. 现阶段还是沿用其他组一样的黑盒模式吧.

然后重点就是让任务的进展都在把控中, 重点就是OKR的理念, 每月同步进展, 更新绩效计划具体的任务和小目标. 然后这种情况下, 是否存在因个人原因脱钩, 才是需要考虑的点. 一切按计划进行, 则绩效就没那么重要了.1

评估点

业务贡献：包括需求把控，业务项目和业务创新。

技术贡献：包括设计重构、技术影响力、Code Review、创新提效和代码质量。

团队贡献：包括招聘、新人培养和团队氛围。

scrum

Scrum实践总结-团队绩效评估_hellion2的专栏-CSDN博客

自发认领任务?

目前一些耗时长, 产生质量等方面价值的事情, 个人成长性较少, 预计不太可行.

工作量评估, 可让所有人参与?

投票过程采用求大同、存小异、取平均的方式。计划会议过程采用：讲解需求->提问与解释->匿名出牌->讨论->重新出牌->达到近似一致->采取平均的流程，确保大家都理解功能点的业务需求、处理方式

评估

绩效评估的统计及公布。每个sprint迭代结束时候的反思会公布统计排名结果。邮件发送给全体成员，并记录到项目的总的绩效统计中。在项目奖的分配上严格按照工作量的统计结果计算。

360评价?

绩效排名的指导原则：

团队内提前对齐标准，形成正确预期，不能有惊喜 信息收集要全面，要体现多元价值观，避免单一标准 定性与定量结合，任何数据都只是参考，警惕虚假的精确性

字节跳动，到底是怎么管理11万员工绩效的？ - 《财富管理》杂志社

OKR

目标对齐

评估主观

质量这块，量化难度太大，但也不是完全没法量化，它有一部分是可以量化的，在我看来，质量可以分成三部分：代码质量：代码本身的质量决定了对后续开发的友好程度研发质量：研发阶段产生的bug运维质量：产品上线以后的故障情况和资源消耗情况其中，第一类，我认为没法量化，我的做法是不考核，只作为努力提高的方向和主观考核依据，因为它产生的成本可以通过自己后续的努力重构来弥补，原则上应该谁挖的坑谁填（这样还是会有问题，可能导致"透支"，即坑越挖越大最后人跑了留下个烂摊子，但我没找到更好的办法了，摊手）。第二类，很难用bug数量来衡量研发质量，所以这块我比较倾向于用红线的形式来考核：冒烟bug、build break、低级bug和regression做记录，其它bug视为正常研发中的沟通。第三类我认为是可以量化的，通过线上服务器消耗、故障恢复时长等来做考核，这种考核的优点同样是投资人和老板看得见，不需要担心指定的KPI偏离了大方向。总之呢，技术管理这事其实挺复杂的，现在这个发展阶段，很多问题都没答案，我觉得我能给的最重要的建议是“不要瞎搞”，宁肯全用主观评价，也不要引入错误的量化指标。

作者：winter 链接：https://www.zhihu.com/question/19995922/answer/138897200 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

市场机制

如何量化衡量一个程序员的工作量和工作效率？ - 知乎 > 市场机制每个人的工作效率不同，如何量化工作效率也是一个问题。假定公司需要解决一个 bug，这个 bug 由普通程序员来解决，需要1个月，但天才只需要1天时间。那么给天才的报酬就应该比普通人高一些。代码除了数量和质量不同，难度很可能也不同。难度越高，相应的报酬也越高。继续假定公司需要解决一个 超级难搞的 bug，这个 bug 由普通程序员修复是不可能的，这个bug远远超过了任何普通程序员的能力，他们根本就无法定位问题。而天才可以修复这个 bug。这区区几行代码的难度是什么，需要评估。如何评估这些不同，是让所有人都头大的难题。但如果我们换一种方式思考，所有的问题就迎刃而解了。让所有程序员对同一个任务的难度打分，然后将任务分配给打分较低的程序员。 > > 作者：松柏 > 链接：https://www.zhihu.com/question/20422695/answer/15095960 > 来源：知乎 > 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 >

黑盒评估

由理解这些的TL来在心里建立一些代价的评估标准. 对内遵循TL的设计, 对上级汇报组内评估后的结构, 代价由TL来承接即可.

TL来确保 重构额代价可接受

Q： 你这个设计重构怎么量化？ A： 这个很难用系统标准化，更多的还是要依赖TL的专业能力进行评分，但即使是这样，也比以前什么都没有完全黑盒要强。至少在传达一个信息，我们鼓励好的设计，鼓励不断地重构优化。

Q：我们现在的业务需求已经在堆积，一线同学根本没有时间去做重构优化。 A：这个问题开篇其实已经说过了，你是要不断地裹挟在业务需求和烂代码里面呢，还是花时间improve，然后更快地支持业务。这个权衡应该不难做，关键是要看决心和能力。对于很多业务，我没有看到推迟几天上线就会影响业务格局的业务场景，所以作为技术团队，我们就应该在User Story之外，加上我们的Technical Story，把完成业务需求和系统重构都当成我们的核心任务。

如何量化考核技术人的 KPI？_阿里技术-CSDN博客

任务执行前, 大致明确计划, 然后根据信息动态规划更新进展

这篇同样指的是OKR的动态跟进进展, 及时更新计划.

作者：知乎用户 链接：https://www.zhihu.com/question/19995922/answer/139929808 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

我觉得量化管理是做不到的，更多的是「set expectation」和「manage expectation」，然后通过「calibration」是做到更大范围内的公平公正。什么是「set expectation」，就是在事情没有做之前就要先说好事情做成功应该是什么样子的，需要付出怎样的代价。例如说，「未来 3 个月优化用户注册流程，使得用户注册转化率提高 10%」。如果一个 E5 的工程师跟经理说，「我能在未来 3 个月提高用户注册转化率 10%，你觉得怎样？」那么经理有几种回应的方法：1.「这很好，你去做吧，做好了至少 E5 能够拿一个 meets all expectation。」2.「这太简单了，只能算 E4 的工作，你 E5 做出来了也只能拿 meets most expectation。」3.「这可能比你想象中的要复杂，能做出来的话你升 E6 没问题，但有一些可能存在的问题你先要想清楚。」这样「set expectation」做好了，好处就是双方不用猜测到底自己做成怎样然后对方会给什么结果。然而这样的事情不是做一次就结束的，因为工作过程中会获得新的信息，然后这些新的信息会带来新的抉择，就如同一个动态规划执行的过程一样，所以中间必须不停地「manage expectation」。可能需要沟通的状况例如：1.「我们一个月就把转化率提升了 8%，我们应该把三个月的目标重新设置为 20%。」2.「我们第一个月只提升了 2%，在研究同类产品的注册转化率后我们觉得提升 5% 就封顶了，目标应该调整为 5%。」

接下来的问题就是怎样保证公平公正。因为每个人会都会想把 expectation 往下调，那怎样说明你做了你这个级别应该做的工作呢？就只能通过「calibration」来横向对比了。如果其它在这个级别的人做出来的结果跟你相似，那你做的结果就是没问题的。这个横向对比不仅仅可以在不同人之间做，还可以在跨不同时间段做。

作者：知乎用户 链接：https://www.zhihu.com/question/19995922/answer/139929808 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

最搞笑的是有些答案提及 OKR 的 Objective 要能量化。OKR 中的 Objective 和 Key Results 分离就是为了让 Objective 不能量化只能指导方向，然后 Key Results 是否指向正确方向允许争论。如果 Objective 是「让用户更加享受我们的应用」，Key Results 可以是「增加用户使用时间到 X」或者是「App Store 评分增加到 Y」。但如果你拼命忽悠用户去 App Store 给你打高分，他们因此而不爽这个应用，那你就是满足了 Key Results 而违背了 Objective。OKR 存在的意义就是允许允许大家了解 Objective 从而盯着 Key Results 的实现方式，阻止违背 Objective 的行为出现。

作者：知乎用户 链接：https://www.zhihu.com/question/19995922/answer/139929808 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

OKR与绩效拆分

也就是说把 OKR 打分和绩效打分不放一起，中间隔 1 到 2 个月，这是一个反思并改进的过程。绩效评定出来之后，管理者需要和员工做绩效面谈，它分为两种，一种是内部激励，第二种是外部激励，内部和外部激励是分两次去进行的。第一次是去跟员工讲 OKR 的结果，主要是和他讲清楚哪些目标没做到？接下来应该怎么做？方法是否有欠缺？或者员工需要哪些帮助？从这个角度和员工聊，不涉及到工资和奖金，员工比较容易听进区去，不会友太大的抵触心理。

进度把控是绩效的重点, 快速发现问题并推进

创业公司是如何进行研发管理和绩效考核的？从豌豆荚说开去 | 人人都是产品经理

敏捷绩效管理三剑客：OKR 、KPI、CFR | CODING 洞见

周例会

会前充分准备：从成员们正在处理的事务入手，确定哪些是争议问题，哪些又是关键信息。 确定工作优先级：专注于促进 OKR 达成的事情。 状态确认：团队对于 OKR 达成的信心是上升还是下降了？大家是否愿意说出困难和风险？ 激发员工敬业度：要利用 OKR 激发员工的创造性思考，同时避免挑战性目标带来的消极情绪。 从大局出发：OKR 是对公司战略的执行，我们要从整体的角度来评判 OKR 的进展或问题，以及对未来的影响。

周例会的目标有三个：

评估目标； 在问题爆发前识别潜在风险； 在使用 OKR 之初，就严谨地把 OKR 管理方法融入到企业文化之中，确保团队持续聚焦；

腾讯

接下来说最重要的部分：过程度量和review 目前来说，我们是一个月review一次，review的过程接受跟进实际情况的部分调整，但这里得拉大家一起讨论处理。另外，对于大型项目，review的过程也可以发现kpi目标的制定是否有可度量的方式，如果不行，那需要再次细化kpi，避免出现最后核算的时候，确认不了是否能完成。

作者：匿名用户 链接：https://www.zhihu.com/question/20190597/answer/111073368 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

可能就是OKR的理念, 每月同步进展, 更新绩效计划具体的任务和小目标.

Peer Review

绩效考核中的PeerReview与结果分析 - 知乎 结论似乎就是没啥用目前

绩效结果 信任关系 花大量时间来确保公平

目标

公平、无偏差和清晰的反馈。反馈应该基于先前设定的预期，期望值应该经过校准，并清楚地说明该员工是否达到、低于或高于该预期。 激励。我希望我们在评估结束后都很受激励。这如何做到？首先承认所有好的工作，然后讨论下一步要关注什么。这里有一个棘手的部分：如果员工的实际表现不支持我试图传达的信息怎么办（低于预期）？ 建立信任。由于绩效评估是经理和员工之间信任的最大考验，我的目标是去扭转这种情况，并加强我们两人之间的信任。这至少要求评估是一次诚实的双向对话。

这篇里, 我觉得作者花了很多时间来处理这个, 花在具体的沟通上?

然后这里的说服的关键, 是要维持和下属的信任关系.

但是作为一个研发, 非完全的管理岗, 这样是否合适?

程序员：年底的绩效评估，你觉得公司的评估合适吗-InfoQ

没有时间也经常被认为是一个不肯花心思的糟糕的借口。

这种如果是偏管理岗, 我觉得这样做无可厚非, 毕竟体现深度. 但是研发岗且组人数不那么多, 目前不觉得这种做法是效益最大化的.

需要收集的

1：1 会议记录。

工程师参加的项目，他们贡献了什么？

产生的输出：代码，文档，电子邮件。

他们收到的反馈：同行反馈，通过电子邮件或其他方式收到的感谢，以及我能找到的其他反馈。

他们给出的反馈：代码审查、计划文档审查、与他人的交互。

自我评估：他们从自己的工作中收集到了什么？我会把这一个放到最后，尽可能收集他们可能遗漏的东西。

咨询其他组大佬

  • 根据OKR, 增加阶段性成果物, 然后增加例会, 汇报OKR进展.
  • 针对会踩坑的那种任务, 个人内部心里绩效合格打底, 但是需要确认进展合理. 的确有产出.

管理方面要关注沟通, 避免被陷入细节

我是如何失去团队掌控的？ - zer0black - 博客园

沟通

TODO: 将沟通这条进行方法论/系统化.

有效沟通元素

  • 沟通背景
  • 需求明确
  • 责任明确
  • 判定明确

反向澄清以减少信息预设的风险

汇报

  • 先陈述结果, what2
  • 再描述why, 通过什么措施做到的
  • how, 后续计划

组员做的不足时

  1. 认知错误时, 展示你理解的
  2. 多次没达到预期时, 说明哪些点没达到预期需要返工. 惩罚机制(事不过三)
  3. 对外, 承担组员的责任. 对内, 组员哪里做错了该怎么说就怎么说3

定计划

smart原则

若不足, 复盘时5W原则至少2条原因

不将每个单个事物之间进行逻辑上的联系, 以免造成心理暗示

也不将错误范围扩大到形而上的层面, 否定事儿不否定人

不扩大责任范围

不扩大这项建议的传播范围

  • 这条之前没遵循, 可能是一个问题的引起原因.4

沟通技巧的边界5

认知水平导致的无法沟通

利益和立场关系导致的无法沟通

执行尝试

执行方案

  • 每个人将每个任务拆解成1-2天的子任务, 尽量按实事求是预留出处理其他事情的时间的情况下创建任务单

遇到的问题

  • 任务单的变更频次极高.
  • 临时插入的任务较多, 预估不足
  • 任务变更时, 需要触发的流程较多
  • 任务每个人都是按满的2天算的, 当他关闭时, 是需要审批人确认才算完成的. 但是创建任务的ddl是包含审批的. 当天晚上点完成, 但是审批人第二天早上才看到任务结束.

Reference

别人家的技术leader是如何建设团队、管理人员、沟通工作的？ 这二十个问题，可能是你技术人生中已经或即将遭遇的痛点，怎么解？

  1. 透过 OKR 进行项目过程管理↩︎

  2. “后浪”职场生存指南_职场生涯_鸟哥笔记↩︎

  3. 下属工作没有做好，该如何跟他们说？ - 知乎↩︎

  4. 下属工作没有做好，该如何跟他们说？ - 知乎↩︎

  5. 什么是「有效」的沟通？如何面对难以沟通的人？ - 知乎↩︎