为什么信息共享很重要

介绍

我搬到现在的公司已经四年半了。
在主要开发和维护我们自己的软件包的同时，我们正在开发以引入它，同时对其进行修改以满足现有客户的需求并为新客户重新制作它。

从年龄上来说，我大概30岁左右，基本上是个开发者，但有时我也能做PM/PL。

我经常因缺乏信息共享而烦恼（技术信息和与公司相关的信息），
我想组织和分享我遇到的问题以及如何改进。

参考

首先，信息共享很重要。 . .让我感慨的文章介绍

如果不共享信息会发生什么

在某个项目...

“除非 A 先生，否则我不能做这项工作” “除非我问 B 先生，否则我不知道”......

……真的是这样吗？

即使在开发期间确定的前提仍然是模棱两可的，如果在开发结束并开始维护之后发生这种情况，或者甚至在移交给另一个人之后开始新的开发之后，A先生是否只是B 先生在分享信息方面是松懈的吗？我会想。

当出现问题并且您说“没人理解……现在我遇到了麻烦”时，B 先生冲了出去！
（附上只有B先生知道的信息）毫无困难地解决了！
称赞“B先生！”的老板

这真的好吗？

如果你不能分享信息...

需要不必要的工作和不必要的人员

信息不共享，因为没有人实际做而做的工作已经由另一个人做，导致工作浪费。可能会导致维护需要时间。

此外，必须确保无穷无尽的人数，因为除非是 A 先生，否则它是未知的……除非是 B 先生。

处理失败时的问题

如果你因为只有 A 先生能理解而继续保持现状，而当 A 先生不在的情况下出现问题时，另一个人会尽力寻找原因和应对措施，或者等待顾客，我去拿。
由于其他人努力查明原因并采取临时应对措施，他们可能会做出与原负责人想法不同的更正，也可能出现浪费工作。

此外，如果不共享连接目的地信息并且只有负责人知道，则甚至可能看不到日志。
当你生病休息时，或者当你为了改变节奏而休息时，你接到一个电话，你必须分享它。你们不喜欢彼此。 . .

质量不高

没有留下有组织的信息，所以阅读源代码，阅读可能保留的消息和电子邮件的历史记录，以及花费大量时间获取信息的操作是浪费时间。您最终可能会使用 .

结果，没有时间花在本来应该做的工作上，检查操作的时间减少了，本来应该改写得更漂亮的部分就原封不动了，这导致质量没有提高。也许吧。

导致技能失败

如果无用的工作时间继续增加，就会导致加班时间增加以赶上最后期限。
当您有空闲时间时，您可能无法调查您认为会深入调查的事情，但您可以让它们保持原样。

此外，如果加班时间增加，私人时间难以确保，即使您认为可以利用自己的时间学习，甚至可能被剥夺那段时间。

良好信息共享的好处

与我上面写的相反，

减少浪费的工作
无需保护不必要的人员
故障排除时更易于访问
- 相互建立信任

另外，我不能直接说“质量会提高！”或“它会导致技能提高！”增加。

为什么不再共享信息/如何共享信息

“为什么我们停止分享信息？”
从这里开始，我将列出我实际经历过的事情，这就是无法共享信息的原因。

信息共享系统不足

我不认为仅仅通过引入信息共享工具并说“是的，那么请使用这个工具来共享信息”就可以解决信息共享不足的问题。

我认为在某种程度上制定规则，然后在如何共享信息上达成共识，这将是很好的。

例如，我认为最好粗略确定以下规则并在操作时对其进行改进。

将长期信息放入类似 wiki 的工具中
- 编写后检查内容，以免过时信息无人看管
在作业管理工具中记录你做了什么
- 为每个任务设置问题，并添加工作期间发生的注释或评论。
- 当出现某种故障时，写下工作历史/调查细节等，以便您以后查看
  - 如果您可能会参考命令、日志位置等，请将它们写在 wiki 上
联系聊天工具以获取短期信息
- 使用聊天工具传达会议的日期和时间，但留下会议内容，包括与无法参加的人分享的意思。
  - （我觉得用作业管理工具来累积“会议纪要”+作业名称按日期等类别就可以了。）

评价体系差

例如，评价体系

如果你经常参与制作新事物，你的评价会上升。
如果你参与了很多项目，你的评分会增加

如果您处于诸如

专注于参与新项目，而不是将信息留到以后
如果现在很好，那很好

可能就是这样。
（当然，我不是说100%不好，但是如果这样的人继续增加，技术债会不断积累，可能会变得无法尝试新事物。可能不会。）

另外，正如我上面写的，有些人故意（？）不共享信息并将其保留为王牌（？），以便在遇到麻烦时通过提供来获得良好的声誉。如果你在公司允许你这样做的情况，并且你处于被评估为在你遇到麻烦时有用的人的状态，我认为你应该尽快退出。

您可能会认为您是唯一受益的人，而其他大多数人都是大麻烦。

此外，红色项目的评级将低于赚取可观利润的项目。
如果这样做，就会陷入一个负循环，其中可以省略的部分（≒工作留下信息等）将被省略，这样就没有更多的信息了。
我认为其中一个原因是，评估系统已经变成“仅仅产生了多少利润？”与评估直接挂钩。

信息共享没有优势

比如，你先分享在执行过程中容易出错的部分，过了一会说“没听到”或者“没看到”，分享的人会怎么想?

如果我是你，我以后可能会停止分享信息，说：“如果你看不到，分享就没有意义……”。

另一方面，如果有比我分享的更多的反馈，我想我会更愿意分享。

有些人不分享信息

哪个是第一位的，
组织中会有人不分享信息→那我也不必分享→那我也不必分享...
我认为在某些情况下，信息不会在这样的链中共享。

不知道信息以什么状态共享

我现在工作的公司也是如此，但有时只有上层管理人员在谈论它，而信息没有传递到下层。
上层就像一个信息中枢，信息没有流到下层，我觉得这很重要。
我认为，如果高层管理人员接受这一点，并且组织可以一起思考如何改进，它就会改进。（虽然这是一个来自下面的想法）

说到我自己的理想主义...

DM基本禁止

正如文章中所写，我试图解释为什么最好不要在 Slack 中使用带有 GIF 的 DM，
我认为最好禁止除个人信息和不可避免发生的秘密信息以外的 DM，让属于公司的任何人都能平等地了解公司。

另外，我认为最好保持 Slack 中的频道和 Teams 中的团队/项目尽可能开放，而不要将它们设为私有。
我认为通知可能会令人讨厌或类似的事情，但最好将信息的接收者基本上看不到的东西静音+只有提到的通知（规则设置）我认为操作很重要消息工具由

不要造成只能从特定位置获取信息的情况

在我现在的公司，有很多会议，比如董事会会议、执行会议、产品规划会议等，除非你是特定的职位，否则你是不能参加的，而且信息记录在会议记录中等等。它没有已在网站上发布，因此无法轻松获取信息。

说实话，这种情况会让人很焦虑，比如“我们公司接下来会采取什么样的政策？”但是，因为无法立即知道信息，我处于非常不舒服的状态。

心理安全性也低，在信息被分割的状态下检索信息有障碍，所以必须保持开放，而不是处于不去就无法获取信息的状态我认为将其保持在可以根据情况查看的状态也很重要。
我们认为，通过划分超出必要的信息范围，防止容易出现信息差异的情况也很重要。

完成后留出空间留下信息/信息

我认为项目的流程大致如下。

需求定义
设计
发展
单元/集成测试
发布工作

好像开发一个功能需要2个工作日，所以不要把2个工作日作为计划，给自己一点余地，把它设置为2.2个工作日左右。估计这样的时间.

其实我现在工作的公司把总工作预估的10%左右作为缓冲，还有潜在的bug等等），目前的情况是10%左右没有轮换。

即使你向客户提供大约 10% 的缓冲，你也可以满意并下订单，但如果增加到 20%、30% 等等，我认为你不会被说服.
向客户收取您自己承担的技术债务也是荒谬的。

在我现在所在的公司，如果我们向客户提交一个工作时间估计为 N 个工天，每个工天是多少 N × M 日元（M 日元/工天）并收到订单，工作期间将被设计为在里面工作。
因此，即使你有 10% 左右的缓冲，溢出的数量也会减少利润，并且有些项目是不可能的。

随着债务（包括缺乏信息，源代码中的错误等）的积累，有必要在未来的估计中考虑到这一点。减少了估计的工时，但实际工作必须完成超过，而且利润正在稳步下降。

为了防止这种情况发生，我认为重要的是不要创造债务，创造足够的偿还余地，并实际制定时间表。

在最后

当我搬到现在的公司时，它已经处于无法共享信息的状态。
这不是我自己的债务，但我因为债务而无法做我想做的事，我真的很痛苦，因为我被不公平地评估了。

老实说，我认为将我现在的公司转变为一个信息共享良好的组织对我来说是相当困难的。

但是，与其把公司当成一个大单位来思考，不如在一个项目或一个团队中工作，或者与一个新成立的团队一起在从一开始就牢固共享的状态下进行。我可以它，所以我要建立一个可以共享信息的团队。

与其为了个人的理由而刻意分割信息、获取评价、谋取个人利益，不如以符合公司和社会整体利益的方式行事。我希望如此。

原创声明：本文系作者授权爱码网发表，未经许可，不得转载;

原文地址：https://www.likecs.com/show-308633109.html