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