《Effective DevOps》阅读笔记 50

Where am I

《Effective DevOps》进度

Notes

《Effective DevOps》工具：文化加速器（10）

思考存在的问题（从一个基层员工的角度）

“大多数讨论都在透明而开放的公共渠道进行”

• 近期项目在进行架构演进，架构师、核心开发工程师以及项目经理之间进行了许多讨论交流，偶尔有一些讨论的邮件会被发送到同事们的邮箱。
• 只要不是必须保密，团队成员会想要能够收到所有的大家关于工作进行的讨论的邮件，因为他想通过阅读大家的邮件学习提升，甚至在有机会的时能够参与进去，他不想闭门造车。
• 他有想过向团队提出将这些邮件发送给整个团队的建议，但最终没有这么做，因为他可能担心Leader觉得没有必要，不同意，或者敷衍了事，或者让Leader觉得我是一个不知天高地厚，喜欢没事找事的人，又或者即使Leader同意，但是最终还是没能成功落实，做了吃力不讨好的事，因为这不仅是几个人可以完成的事，需要团队有一个共识。
• 项目组的成员可以按地域、按角色层级划分为几个小团体，不同的小团体之间沟通甚少，有的同事“身兼数职”，同时投入多个项目。小团体之间进行了什么讨论，得出了什么结论，对我们有什么影响，大家总是最后才知道的，没有“一个团队”的感觉。

“即时聊天有可能打断人们的工作，造成干扰，所以如果有人退出或关闭通知，以便能专心完成某个工作，这并没有问题”

• 有的团队成员的职责就是用来吸引来自团队内外的“进攻火力”，为其他成员争取到足够的时间完成更加重要的事情。例如：问题、运维、on-call接口人。
• 被打断的频率高到一定程度，会严重影响到员工的工作。全职的“问题接口人”真是灾难，看着时间一天天过去，而自己每天重复着毫无变化的机械的、不能让自己得到丝毫长进的工作，一个有进取心的员工也许会开始思考该怎么改变这样的现状
• 要采取实际的行动，为自己争取到一定的“静默时间”，专注完成真正重要的事情。如果不那么做，员工可能一直限于琐事，无法得到提升。

“在Etsy中，撰写文档被认为是一种工作，在实践中“尽力而为地更新wiki”很有帮助”

• 也许团队中的同事都自己维护着同一个项目中自己负责的领域的wiki，但是团队中的其他成员并不知道，没有发挥出最大的价值。
• 也许某个“吸引了大部分火力”的同事辛辛苦苦写了一个wiki，并且告诉大家wiki的存在，希望大家能够自己在其中查阅需要的信息，不要总打扰自己，但是大家依然更倾向于直接向这位同事询问，这位同事的工作总是不断地被打断，有点像是专业的服务员了，必须随叫随到。