作者回复: “人对了,事情早晚都没问题,如果人不对,事情对也是暂时的” — 我也学到了。
作者回复: 我自己其实也是不够聚焦,没有能够形成积累效应。两周前跟一个老同事一起吃饭,他说了一个词我颇受感触,这个词叫做:“战略耐心” 舍得,说起来容易做起来不易,舍比得难。
作者回复: 积木 谢谢你的留言,我觉得你说的很好。现在的我会问自己两个问题: 我现在的解决方案(很多时候是架构设计)是聪明的解决方案吗?是不是有更优方案(不要轻易停止搜索) 我做的事情本身对业务的价值和因为我当前做了这件事而不能做另外一件事所造成的机会成本。
作者回复: Trapped 关于第一个问题,我会尝试用第一性原理的,我们公司目前很强调开发效率,但是我并不认同基础架构部门搞一个下一代的CD pipeline 的基础架构是解决问题的关键,具体来说我们现在的2021年第一季度就是要交付基于Tekton 的CD 方案,而我并不认为这是关键,各个业务部门真的是因为没有一个CD pipeline 而使得开发效率(这里主要指测试效率)不高吗?我自己有一些假设,比如做性能测试,做失效性测试不方便的根本原因是缺乏测试的框架代码和模拟环境效率太低。毛主席说没有调查就没有发言权,所以我在给一个叫陆凯的读者的回复中说我2021 年要仔细去看一下我们部门的一个小组的开发效率问题,然后我再回复他。 关于第二个问题,我想我们两个人做一个小作业的尝试,你能不能先去看一下《道德经》里面“治大国如烹小鲜”那一段,随便看一下历史上各个时代的人对这一句话的注解,然后你结合你的理解再回复一下这个题目,好吗?
作者回复: 你负责测试的模块是后端模块还是权限模块,逻辑变动非常频繁吗?我想理解一下为什么你觉得提升自动化测试覆盖率ROI 很低。 我一直觉得测试用例覆盖率高对于回归测试是很有帮助的。
作者回复: BertGeek 我想问一下,你准备怎么解决部门工作效率的问题,怎么解决沟通成本的问题。这两个问题我现在也在处理,需要先提升自己的认知。很多的事情我们要向内求而不是向外求。最近几个月我反思了很多,得出的结论就是问题在我,不知道你会不会认可。如果需要,你可以回贴,把你说的部门效率和沟通成本的事情展开说一下。 关于从核心问题出发这一点问我高度认同,但是记住核心问题往往都不容易解决,我们坚持做对并且难的事情。
作者回复: 不要轻易放弃,可以把整个专栏都看完以后再回来看这道题。特别是技术决策那三篇文章。
作者回复: 我其实对这些指标持保留意见的,我觉得负责该效率的部门应该把自己最优秀的人派到一线去,去寻找那些关键瓶颈。一定要深入到客户中去。