温智全的博客

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

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

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

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

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

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

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

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

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

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

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

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

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

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

年度规划会议中，育亮讲到了一个规划三角形的方法论，感觉受益匪浅。
对于 MS 平台，可以拆分为【平台，数据，架构】三个维度来开展规划；数据包括数据分析，数据存储的完整性和实时性等，架构包括现有架构的稳定性和可运维性等，平台包括易用性和便捷性等，可以从三个维度各自的特点来思考可以做的内容，而不是仅仅限制于其中某一个维度；
做规划的时候，还要注意点到即止，把大目标分解为几个更细粒度的方向，为每个方向打一个分数，规划每个双月需要把各个方向提升多少，最开始不用做太多，先提供最基础的能力，把特别缺失的部分先做到及格，然后通过迭代提升分数，不要把某个方向做到很高分数后才去做别的方向，做规划需要考虑均衡发展，避免头重脚轻。

做需求之前我们需要思考几个问题：

1. 为什么要做。已经是老生常谈了，不能为了做需求而做需求，而是要思考这个需求可以提升哪些指标，满足哪些用户需求，是否合理等等
2. 使用场景是什么。其实有的时候我们思考出来的需求可能是伪需求，乍看之下很有道理，但是如果不能结合使用场景来落地，那其实这个需求并没有实际的意义。能够满足使用场景落地的需求才是好需求。
3. 制定何种评估指标。其实这一点我们都做到了一部分，我们每次实现需求并进行验证时都在自己的脑海里有一套评估指标，比如返回值是否符合预期，数据是否正常修改等等，但是如果某个需求比较大，更好的方法是把这些指标书面化，然后再思考一下是否有遗漏，尽量避免人为导致的疏漏。
4. 实现到什么程度能满足业务的需求。大部分的需求也不是需要一步到位的看，我们在讨论一个需求时，如果能够先做出一个MVP版本满足业务的基本需求，然后再不断地根据业务的新需求迭代优化，可能是一个更加灵活和快速的方式