Weekly | 科技管理。

这周事故复盘的时候,我惊讶的发现,这个世界上绝大部分人的对于“科技管理”这四个字,是没有概念的....

Weekly

  • 又看了两本伊坂的书,太喜欢了,甚至这大哥会是我这辈子最喜欢的作家。

如果有“问题”儿童,是不是也有“答案”儿童呢。——余生皆假期

  • 小望开始慢慢的吃辅食了,然后南瓜过敏……肚子疼的第一次哭的失去理智,希望你以后可以当个答案儿童。
  • 这周的代码都是在服务器的Code Server上完成的,以至于回到家里并不想在本地写代码,因为还得调整本地的编译环境。Remote Coding看起来迟早会成为趋势。
  • 打算四十岁之前写出一本小说,不知道有没有可能呢?

科技管理

这周事故复盘的时候,我惊讶的发现,这个世界上绝大部分人的对于“科技管理”这四个字,是没有概念的。同事有个比喻,管理管得像个“包工头”,我觉得不能更贴切的形容大部分草台班子的现状。

之前写过的

对于软件开发来说,第一要务是实现业务价值,第二则必然是保证质量和生产安全。之前在公司做了Philosophy of Production Resilliency的演讲,粗糙的介绍了生产管理的底层逻辑。但生产环境管理终究是科技管理的最后一道防线,太迟了。

科技管理,对于软件质量保障的三道防线,应该是漏斗的关系:

技术标准 > 质量控制 > 应急响应

因此,所有的生产事故,本质上都是这三道防线全部失守造成的,而复盘的优先级,理应从第一道开始。所谓的科技管理,最终的目的其实是建立完整可落地的交付标准和流程,把有效的三道防线纳入管理框架的设计中,并长期不断的通过度量和反馈机制,修正细节,提高效率。

可惜,我接触到的大部分同学对管理的理解粗糙的令人发指:派活,监工。

管理是技术活,需要的抽象设计落地的难度并不输业务领域建模(虽然后者我也没见过几个人能干好,大概智力的金线就摆在这了)。但管理的困境很多时候是政治性的,并不像代码或者设计那样,一目了然,不可辩驳,这更让人沮丧,更让我这种轻度社恐更容易感到悲伤。

是的,悲伤。

以上。

Built with Hugo
Theme Stack designed by Jimmy