实际上,除了你自己,没人在意你做的是否达到完美。
别人只会注意,你是否已经完成,是否达到了要求。至于超出要求的那部分,至多会让别人惊喜一下。
为什么我仍要追求完美?
为什么要做对于目标来说毫无意义的改进?
完成目标不就行了吗?
也许只是为了满足自己。
 
 
「完成和完美哪个更重要」不是真正的问题。因为在不同上下文中,哪个都可以是更重要的,都有道理。
那么我的问题是什么?是「在工作环境中,如何在心态上和方法上做到先完成后完美?」
 
我犯的错误是对于高标准没有个定量的标准,目标太模糊就没有目标了。多高的标准算是最高标准呢?
对于工作,比如定 KPI,设定一个最高和最低的区间,两者都必须是可量化的标准。这样想追求最低的或者追求最高的,都能达成目标。可量化,就能知道最高标准会不会遥不可及。
 

 

问题

当进入一个陌生的领域,自己是一个小白时,处理限时任务时,如何权衡完成和完美。
 

答案

先完成,再完美。
先追求效果,后追求效率。
 

完美的分类
notion image
notion image

 

完成和完美

程度计量表
 
  • 任务(事情)是长期还是短期的?
  • 任务是紧急还是非紧急的?
    • 火烧眉毛的事情,比如舆情处理,必须第一时间尽可能完成任务。比如线上故障。
  • deadline
 

一切都跟时间有关

一件事情是长期的,
任务是短期的(因为我想不出一年时长的任务有什么意义),一个任务对应会有 1~N 种方案,从完成~完美的方案。
一个任务关联一个上下文。
当时间改变上下文,方案就不一定可行了。
 
方案不可执行,或者执行成本高时,就需要寻找替代方案。
 
例子,事件:软件声明周期,任务:软件构建,方案:软件架构
 

时间、上下文、方案

每一个任务都有 N 种可行方案(N ≥ 1)
 

可持续发展的方案

方案是否在一条线上?
 

历史包袱与迁移成本

方案升级很不容易,即使找到了最佳实践,历史包袱太重根本不可能使用新的方案,只能在旧的方案上修修补补
 

保证完成

我想到一个解决我问题的方法。比如时间限定是 N,任务内容是确定的,我还是一个小白。那么第一步是找到第一个能在规定时间内完成任务的方案,设为基准 P1。然后评估这个方案会消耗的时间 T1,且不急着执行。N - T1 是容许我寻找第二个可能存在更有方案 P2 的时间。如果实际时间超出了 N - T1,则开始执行 P1。如果花了时间 N2 找到了 P2,评估执行时间 T2,N - N2 - T2 就是剩下寻找 P3 的时间,以此类推。直到没有空闲时间为止。 对于小白评估方案的时间可能有误差,再加上保守时间或者乘上一个系数好了。
这个方案能保证一定完成任务,同时尽可能找到更优方案。
 

趋于完美

完美是个终点,如果你认为已到达了这个终点,那就意味着认为从今以后不会再出现更好的,你真得这么想吗?
我认为通常的完美实际上是局部最优解,在当前时间段,当前上下文,自己所能做到的最优解。而随着时间推移,自身对上下文的认知扩展,会找到更有的解。
只有当自己掌握了全部的上下文,才能得到全局最优解,即完美。这才到达终点,在此之前,都是趋于完美。
 
问题本质并不是如何发现可持续发展方案的方法论。而且如何快速成长的问题。可持续发展方案只是当我从小白达到更高层次,达到专家级别的自然产出而已。只要成长得更快,知识面就会很快覆盖到,到时自然就会有好的方案,无需别人指点
那么请教大佬就有动力了。请教大佬不是为了解决问题,而是为了帮助自己从小白快速成长为领域专家,从而自己可以想出问题的解决方案。
 

更好的方案

可以指出一个方案的缺点,但如果不能提出一个更好的可执行的方案,就不能否定或推翻这个方案。
 
要证否只需要有一个反例即可,可证明却要穷举或逻辑推论,证明的难度显然更大。
 

评估方案是否可接受

 
 
过程评估
结果评估
影响评估
 
评估不知是领域方案本身,更是跟人跟时间相关
 
假如上一个需求的方案是用 js 写的,下一个需求的方案不用 js 用 go 写,甚至推翻之前的系统新造轮子。如果可以按时完成,可以满足需求,那这种方案是可以接受的吗
又比如,项目代码充满了拷贝粘贴的代码,完全不考虑可维护性,但是能跑能用,性能还挺高。这样的方案能接受吗? 这些方案评判的必要条件有哪些?我在想这个问题
 
于是我从最必要的条件开始往上加。就总结出两条,按时交付,满足业务最低需求。似乎只要达成这两点的任何方案都是可以接受的。我在找反例。
从团队的角度考虑,不以个人的角度考虑。
所以必要条件分两类。 对外:按时交付,达到最低标准 对内:投入成本,团队及个人的成长,方案是否可持久使用
 
 

彻底解决 vs 可用?

 
即我以不管什么任务,不管之前什么历史包袱,我都重新来,并且按时达到最低可用的交付标准。这套打法是不是万能的?
 
 
 

可用方案 vs 最佳方案

最佳方案:一键自动,防呆,自检,监控等保证质量
防止人不会做出毁灭性的错误或者越改越乱
在一个安全稳定的环境快速试错,方案调优。就像 docker 容器,我在容器里随便怎么搞,就算出错了我销毁重建就好了,就几秒钟时间。
自检:执行后自检查状态
 
最佳方案需要积累,理论思想和基础的积累,没有积累只能被虐中成长。
什么都从零开始是不现实的,用社区框架就是用别人的积累。
最佳方案要从可用方案一步步改进,不可能一步到位,但加速是可以做到的。比如别人用一个月的时间,我用一周。
 

不完整的方案 vs 最大风险承受

技术方案大多是为了长期使用的,除了一次性的计算或者小脚本以外,其他方案都要考虑未来是否可持续,可维护。因为程序默认是不容错的,遇到问题就整个崩掉了,要做好兼容也是很大的投入。 那对于企业的经营方案感觉也是同理,如果这个方案的依赖上游有一环破了,整个方案就没法运转了。比如生产者停工了,或者运输链断掉了,导致己方受到很严重的损失。那么经营方案要在一开始就考虑整个链路的隐患问题吗?如果不考虑,当这个问题真的发生了,必然会受到很严重的损失。这个损失是
 
假设有一个创业企业,它有一套正在运行且没有出现过问题的方案,公司的营收都依靠这一套方案。但这套经营方案存在一定缺陷,如果生产者停工了,或者运输链断掉了,将会导致它受到很严重的损失。
  1. 当这个损失完全不可预估,大小多少都不知道。
 

明显的问题 vs 不被察觉的隐患

 
badge