温智全的博客

Elvin wen's Blog

看完了《刻意练习》,总结下来有以下四个主要步骤:

  1. 找个好导师(如果没有导师就去学习杰出人物的练习方式)
  • 求助导师或者学习杰出人物的做事方式,可以帮助我们建立高效的心理表征和练习方式
  • 我们可以通过 3F 法创建有效的心理表征:focus,feedback 和 fix it,聚焦在做的事情上,然后获得反馈,并根据反馈及时进行修正和提升
  1. 专注的投入
  • 练习时需要投入百分之百的精力,如果练习时变得懈怠,可以缩短练习时间,短时高效练习的效果要高于长时低效练习
  1. 根据反馈跨越停滞阶段
  • 反馈是刻意练习中很重要的一个部分,通过反馈,我们可以了解练习的效果和练习中存在的不足,这样能够帮助我们调整练习方法,不断地改进自身,建立更加有效的心理表征
  1. 保持动机
  • 动机是支持我们不断练习的推动因素,保持动机才能够保持不断地进步。
  • 动机不足的原因只有一个:前进的理由败给了停下脚步的理由,所以要保持动机,要么加强前进的理由,要么弱化停下脚步的理由。

我们的技能是需要通过不断的练习才能够提升的,无论是编码能力或者是系统设计的能力,刻意练习的效果往往要高于被动练习,就如我们通过大量的开发实践才能够总结出更加高效的系统体系和业务架构,在每次开发过程中更多的投入精力,获得的结果会更加令自己惊喜。

《掌控习惯》中提到了打造好习惯的四个定律,感觉对我们还是可以有所帮助的:

  1. 让习惯显而易见
  • 用习惯记分卡记录自己每天的习惯,并标注出来哪些是好习惯,哪些是坏习惯
  • 习惯叠加,将不同习惯叠加在一起使其更加显而易见,例如我吃饭之前先要洗手
  1. 让习惯不可抗拒
  • 让习惯联动起来,继当前习惯之后,我要完成一个我需要的习惯,接着完成一个我想要的习惯
  • 养成习惯时,提升执行习惯的次数的效果大于提升执行习惯的时间
  1. 让习惯简单易行
  • 习惯是切入点而不是终点,作为启动一系列习惯的起点
  • 两分钟原则,养成习惯时,缩减成两分钟可以完成的版本,比如读一页书,然后再逐步增长时间
  1. 让习惯令人愉悦
  • 打造即时满足感,完成某一个习惯之后,给自己一个奖励
  • 糟糕的坚持也好过放弃,连续放弃两次之后可能就养成了一个坏习惯

《清单革命》中提到了两类错误:“无知之错”和“无能之错”。

  1. 无知之错指的是没有掌握相关的知识,可以认为是专业知识不足以解决遇到的问题,针对此类问题,需要增强专业知识的学习,掌握通用解决方案,从而解决问题。
  2. 无能之错指的是犯错并非是因为没有掌握知识,而是因为没有正确使用,此类问题更加考验对已有知识的运用以及相关经验的积累,比“无知之错”更难解决。正所谓“知易行难”,光学习知识是不足以应对这个千变万化的世界的,实践出真知,多积累经验,应用知识,我们需要把重点放在“行”上。。。

最近在思考为什么我们要写周报,觉得有两方面的作用:

  1. 对自己,周报是检核项目进展明确项目计划、复盘与调整迭代策略的重要手段。因此,周报内容可以围绕项目进展、计划、经验总结、认知迭代几个方面去写,让自己能够在写周报的过程中不断总结不断进步。
  2. 对合作伙伴,周报可以让大家了解项目进展与问题,既能起到进展同步和暴露问题的作用,又能结合项目提出对合作伙伴的诉求,获得对方支持。

这周听到关于焦虑的解释与应用,觉得比较受用,分享给大家。

焦虑指的是我们对还没有发生的事情产生的负面情绪。关键词:“还没有发生”、“负面情绪”。还没有发生意味着我们是有时间改变它的,负面情绪意味着我们可以直面它、接受并改变它。当我们有这样的情绪时,可以尝试使用列清单的方式,把可能发生的最坏结果写下来,并从第三方视角审视一下,写下为了从坏变好,自己可以做什么事情,从而掌握主动权而不是等待坏结果的发生。

解决焦虑的最好办法,是解决那个引发焦虑的问题。不要沉浸在情绪里,要沉浸在行动里,用行动解决问题。

到深圳出差和对应的架构和业务开发面谈之后深有感触,真的是要多深入一线,才能够真正了解用户的需求,换句话说,只有真正的接触了用户在系统的使用过程中遇到的痛点,才能让我们启发我们更深入的去思考。相比基础架构,业务架构能够更多的接触到用户,也就能更能理解用户的痛点,能思考并提出解决用户问题的需求点,所以我们要多和业务架构以及业务的同学多沟通交流,这不仅仅能让我们更多的接触到用户的痛点,更能激发我们的思考,扩展我们的视野。

另外,在和用户聊需求的时候,不要直接问用户想要什么,因为大概率用户也不知道自己想要的功能具体是什么,也不要直接向用户讲解自己系统的功能,因为用户很可能缺少上下文,并不能很好的进行理解。我们应该跟用户聊他们的工作和使用场景,了解他们在此过程中遇到的问题和潜在的优化点,从而挖掘出用户的需求,并且通过挖掘用户使用场景验证方案的可行性。此外,做访谈总结的时候,最好把用户的原话写上去,因为每个人对于同一句话的理解可能是不同的,写上用户的原话,也能佐证自己的理解是正确的。

上次开会时育亮讲到,我们在写一个项目规划的时候应该从三个方面出发进行阐述,痛点,场景和解决问题,让我想到了之前的一个写作方法论——5w1H,痛点对应的就是 why,我们为什么要做这个项目;场景对应的就是 where,when,who,我们在什么情况下为谁服务,有哪些使用场景;解决问题对应的就是 what 和 how,我们做哪些事情,如何解决用户的痛点问题。这个方法不仅仅可以用在项目规划,在我们要向他人分享内容的时候也可以采用这种框架,能够让听众更加清晰地了解文章要讲述的内容。

在业务高速发展的系统中,在利用以往经验进行判断时,需要首先判断当前的业务是否还符合历史经验所处的背景和环境中,是否还适合套用经验,如果不适用,就需要摒弃以往的经验,重新思考针对当前业务环境,使用何种方案才能拥有更好的收益,否则很可能会产生反向的效果

  1. 最近学习到了一个方法论:抓主要矛盾,这个方法论意义为在我们面对众多工作的事宜时,要弄清楚当前的最重要最紧急的事情,并将其作为主要矛盾,并且这个主要矛盾随着事情优先级的改变也是随时改变的,需要解决主要矛盾之后再处理其他事宜,而不要让非主要矛盾占用了主要矛盾的时间
  2. 清晰的流程文档很重要,第一是可以省下每次去跟新同学讲解的时间,用节省下的人力去做更重要的事情,第二是可以帮助自己再次去理清思路,加深对整个项目的印象,第三是标准的流程文档可以避免出现人为疏忽而导致的问题。

又从育亮学到了一个关于制定规划的点:做长期规划的时候,不一定要基于现有的能力想我们能做什么,可以激进一些,

  1. 看看能不能与其他部门合作共同开发,共建更加适宜用户使用的平台;
  2. 跳出当前的能力圈思考我们还有什么可以做的,然后再收束成我们如果做需要什么样的能力,进而去锻炼相关的能力。