mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
81 lines
6.8 KiB
Markdown
81 lines
6.8 KiB
Markdown
|
A 3-step process for making more transparent decisions
|
|||
|
|
======
|
|||
|
|
|
|||
|
|
|
|||
|
|
要让你的领导工作更加透明，其中一个最有效的方法就是将一个现有的程序开放给你的团队进行反馈，然后根据反馈去改变程序。下面这些练习能让透明度更佳切实，并且它有助于开发“肌肉记忆”，此二者可以持续评估且调整你的工作。
|
|||
|
|
|
|||
|
|
我想说，你可以通过任何程序来完成这项工作—即使是那些“范围外的”的程序，像是晋升或者自行调整程序。但是如果第一次它对于机内测试设备来说太大了，那么你可能需要从一个不那么程序的方法开始，比如旅行批准程序或者你的寻找团队空缺候选人的系统。（举个例子，我使用了在我们的招聘和晋升程序）
|
|||
|
|
|
|||
|
|
开放程序并使其更佳透明可以建立你的信誉并增强团队成员对你的信任。它会迫使你以一种可能超乎你设想和舒适程度的方式 “走透明的路”。以这种方式工作确实会产生额外的工作，尤其是在过程的开始阶段——但是，最终这种方法对于让管理者（比如我）对团队成员很有效的负责，而且它会更加相容。
|
|||
|
|
|
|||
|
|
### 阶段一：选择一个程序
|
|||
|
|
|
|||
|
|
**第一步.** 想想你的团队使用的一个普通的或常规的程序，但是这个程序通常不需要仔细检查。下面有一些例子:
|
|||
|
|
|
|||
|
|
* 招聘：如何创建职位描述、如何挑选面试团队、如何筛选候选人以及如何做出最终的招聘决定。
|
|||
|
|
* 规划：你的团队或组织如何确定目标年度或季度。
|
|||
|
|
* 升职：你如何选择并考虑升职候选人,并决定谁升职。
|
|||
|
|
* 经理绩效评估：谁有机会就经理绩效提供反馈，以及他们是如何反馈。
|
|||
|
|
* 旅游：旅游预算如何分配,以及你如何决定是否批准旅行（或提名某人是否旅行）。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
上面的某个例子可能会引起你的共鸣，或者你可能会发现一些你觉得更合适的东西。也许你已经收到了关于某个特定程序的问题，又或者你发现自己屡次解释某个特定决策的基本原理。选择一些你能够控制或影响的东西——一些你相信你的成员关心的东西。
|
|||
|
|
|
|||
|
|
**第二步.** 现在回答以下关于这个程序的问题：
|
|||
|
|
|
|||
|
|
* 该程序目前是否记录在一个所有成员都知道并可以访问的地方？如果没有，现在就开始创建文档(不必太详细;只需要解释这个程序的不同步骤以及它是如何工作的)。你可能会发现这个过程不够清晰或一致，无法进行文档记录。在这种情况下，用你认为理想情况下应该使用的方式去记录它。
|
|||
|
|
* 完成程序的文档是否说明了在不同的点上是如何做出决定？例如，在旅行批准程序中，它是否解释了如何批准或拒绝请求。
|
|||
|
|
* 程序的输入是什么？例如，在确定部门年度目标时，哪些数据用于关键绩效指标，查找或者采纳谁的反馈，谁有机会回顾或“停止活动”。
|
|||
|
|
* 这个过程会做出什么假设？例如，在升职决策中，你是否认为所有的晋升候选人都会在适当的时间被他们的经理提出。
|
|||
|
|
* 程序的输出是什么？例如，在评估经理的绩效时，评估的结果是否会与经理共享，任何审查的方面是否会与经理的直接报告(例如，改进的领域)更广泛地共享？
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
回答上述问题时，避免作出判断。如果这个程序不能清楚地解释一个决定是如何做出的，那也可以接受。这些问题只是评估现状的一个机会。
|
|||
|
|
|
|||
|
|
接下来,修改程序的文档,直到你对它充分说明了程序并预测潜在的问题感到满意。
|
|||
|
|
|
|||
|
|
### 阶段二:收集反馈
|
|||
|
|
|
|||
|
|
下一个阶段牵涉与你的成员分享这个程序并要求反馈。分享说起来容易做起来难。
|
|||
|
|
|
|||
|
|
**第一步.** 鼓励人们提供反馈。考虑一下实现此目的的各种机制：
|
|||
|
|
|
|||
|
|
* 把这个程序公布在人们可以在内部找到的地方，并注意他们可以在哪里发表评论或提供反馈。谷歌文档可以很好地评论特定的文本或直接建议文本中的更改。
|
|||
|
|
* 通过电子邮件分享过程文档，邀请反馈。
|
|||
|
|
* 提及程序文档，在团队会议或一对一的谈话时要求反馈。
|
|||
|
|
* 给人们一个他们可以提供反馈的时间窗口，并在此窗口定期发送提醒。
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
如果你得不到太多的反馈，不要认为沉默就等于认可。你可以试着直接询问人们，他们为什么没有反馈。是因为他们太忙了吗？这个过程对他们来说不像你想的那么重要吗？你清楚地表达了你的要求吗？
|
|||
|
|
|
|||
|
|
**第二步.** 迭代。当你获得关于程序的反馈时，请让团队对流程进行修改和迭代。加入改进的想法和建议，并要求确认预期的反馈已经被应用。如果你不同意某个建议，那就接受讨论，问问自己为什么不同意，以及一种方法和另一种方法的优点是什么。
|
|||
|
|
设置一个收集反馈和迭代的时间盒有助于向前推进。一旦反馈被收集和审查，你应当讨论和应用它，并且发布最终的程序供团队审查。
|
|||
|
|
|
|||
|
|
### 阶段三：实现
|
|||
|
|
|
|||
|
|
实现程序通常是计划中最困难的阶段。但如果你在修改过程中考虑了反馈意见，人们应该已经预料到了，并且可能会更支持你。从上面迭代过程中获得的文档是一个很好的工具，可以让你对实现负责。
|
|||
|
|
|
|||
|
|
**第一步.** 审查实施需求。许多可以从提高透明度中获益的程序只需要做一点不同的事情，但是你确实需要检查你是否需要其他支持（例如工具）。
|
|||
|
|
|
|||
|
|
**第二步.** 设置实现的时间表。与成员一起回顾时间表，这样他们就知道会发生什么。如果新程序需要对其他程序进行更改，请确保为人们提供足够的时间去适应新性能，并提供沟通和提醒。
|
|||
|
|
|
|||
|
|
**第三步.** 跟进。在使用程序3-6个月后，与你的成员联系，看看进展如何。新流程是否更加透明，更有效，更可预测？你有什么经验教训可以用来进一步改进这个程序吗？
|
|||
|
|
|
|||
|
|
### 关于作者
|
|||
|
|
Sam Knuth；我有幸在 Red Hat 领导客户内容服务团队；我们提供给我们的客户所有产生的文档。我们的目标是为客户提供他们在企业中使用开源技术取得成功所需要的洞察力。在Twitter上与我联系
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/open-organization/17/9/exercise-in-transparent-decisions
|
|||
|
|
|
|||
|
|
作者：[a][Sam Knuth]
|
|||
|
|
译者：[MarineFish](https://github.com/MarineFish)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]:https://opensource.com/users/samfw<!doctype html>
|