一思二想

事情是这样的。在以往的项目中，出现了因为某个测试工具没有按时完成而影响测试进度、而最终影响交付的经历。于是，项目团队便想把所有功能开发中与这个测试工具相关的工作和问题单独管理起来，一旦出现问题，可以重点跟踪，同时也便于对该测试工具做整体的把控。乍一看貌似很有道理，成立“工作组”，重点问题重点跟踪。但是，跳出来看看呢？

每个软件版本的发布，都包含了一系列新的功能（feature）的引入。在敏捷开发实践流程下，每个新功能由对应的功能开发团队（虚拟的）来端到端负责并最终发布的。每个功能团队对自己的feature全权负责，直至交付客户使用。其中包含软件开发的所有工作，从前期需求澄清、软件设计和实现，再到不同级别的功能、系统测试，其中自然要考虑测试工具的支持，缺一不可，我们才能将这个新功能交付给客户。如果功能团队对交付做出承诺，就需要对每个环节负责到底。

现在，因为以往项目中出现了某个测试工具的问题而导致的功能延迟交付，所以我们吸取教训，跳出功能团队和开发流程，将该工具相关的工作和问题横向管理起来、单独报告，这样做真的要去解决问题？还是说只是想找一个“篮子”，每个功能团队一旦遇到该工具相关的问题，就可以简单地丢到这个篮子里，世界就清净了？每个功能就可以顺利发布了？

另外一种思路就是，既然大部分功能都能正常交付（也使用到了该测试工具），而某些功能却出现了因此而延迟交付的问题，那是不是这些功能团队在实施中缺失了什么？或者忽略了对这些工具的跟踪？这些功能团队应该采取哪些措施来避免类似问题的发生？毕竟，只有每个功能开发团队最清楚自己对这些测试工具的要求。

问题：是流程问题还是执行问题？

这其中有个问题就是，如果在现有流程下遇到了某一个具体的问题，我们是打破当前流程，增加新步骤、新流程，还是说找到根本原因并改进当前流程的问题？或者说，就仅仅是这些团队的执行力度不够的问题。我觉得这取决于遇到问题的影响范围和通用程度。

执行力：流程的执行问题

如果只是个别功能的某些步骤有这些问题，大部分的功能仍然可以按时交付，那可能是这几个功能的对应执行团队在执行中问题。我们可以去分析和挖掘在执行过程中出现了什么问题？是否需要为遇到的特殊场景做流程的微调。

持续改进：对流程的持续优化和改进

如果大量的功能都因为相同的原因（某个模块），那可能是对应的模块出了问题，而不是功能开发流程的问题。这就需要对应的模块就回顾和反思对功能开发的参与方式、重视程度等等，从模块本身的工作流程来改进和优化对于功能开发的支持。同时，也可能需要在单个功能开发的流程和实践中增加对该模块的特殊处理等等。但是大前提并没有改变，功能开发的思维和迭代逻辑仍然不变。

思维转变：研发模式的转变

最坏的情况就是（其实并不坏），新功能开发本身的逻辑已经不满足最新市场需求，我们要换一个不同的维度和视角来重新设计研发模式来保证产品交付。就好比从软件设计、开发、测试的瀑布模式，到现在基于单个可用功能的端到端敏捷开发模式的转变一样。在未来，我们完全有可能转变到另外一个全新的模式。

从优化执行到对流程的持续改进，再到思维模式的变革，这是个递进的过程，看看我们面临的问题属于哪个层面？不要急于去“打破”，尤其是思维和文化，具体问题具体分析!

原文：https://mp.weixin.qq.com/s/usKHZzbNa8DVEUYLkfO42A

在面试中，经常会遇到比较“大”而“开放”的问题，比如说怎样才能达到月底的目标？如何才能避免工作中的“甩锅”？等等。这种关于HOW（如何）的问题，如果是自己正好处理或经历过的，自然好说。但如果是不熟悉的领域、或者一些“虚拟”的场景，乍一听会觉得无从下手。有时候甚至会脑子突然空白，不知道说啥，冷场不说，面试的结果也可想而知了。

我们来想想，这种问题之所以让人头疼，其实就是我们平时说的，问题太大，乍一听还比较空，都是一些鸡汤文里经常提到的一些话题。我们不能想鸡汤文一样，说些“只要踏踏实实做好每件事”、“从细节做起”、“保持良好心态”之类的大而无当的鸡汤励志口号。生活中遇到的一些实际问题，每个人都会自然地拆出个步骤一二三步，或ABC部分，然后按步骤、分布去逐个解决。对待面试中遇到这种问题，我们只要按相同的逻辑来思考和回答就可以。

1. 阐述自己对问题的理解，争取更多的思考时间

首先从问题本身出发，就问题进行拆分。

问题：如何避免工作中的“甩锅”？

我们拿到这个问题，先就事论事地对问题中的关键词进行分解，按类别、按步骤等等。

• 工作“甩锅”（做了不该自己做的事情，努力没有得到认可）

• “责任”甩锅（出错误以后，不是自己的问题却被拿来顶罪）

• …

2. 按某个维度对问题进行拆解

针对拆分后的几个方面，针对其中一方面，按某个维度来分析可能的解决问题的方法。这个维度可以是时间维度、空间维度、逻辑维度等等。

工作“甩锅”

既然是做了不该做的事情，那我们还可以进一步从事前事后不同角度来看？

• 事前

  是不是可以从工作划分、分配的角度来找原因？工作划分的时候有没有明确各个部分的工作内容、有没有考虑到不同工作之间的关系？分配团队的时候有没有考虑到团队之间的合作？

• 事后

  既然已经做了一些额外的工作，怎么让这部分工作变得“可见”？对自己可见，对团队和组织可见？事情一旦可见，就不存在“甩锅”一说了。

3. 结合自身经历，选择熟悉的方面提出有效、可行的方法和措施

经过第二步的分解，到这里一般已经很轻松地得到一些“显而易见”的措施或步骤。接下来提出具体方法和步骤的关键，在于结合自己以往的工作和项目经历做出取舍。很多时候解决问题的方法和步骤是相似的，大家都知道那个把大象放进冰箱的三个步骤，但是为什么有的人可以放进去，有的人却不行？关键在于对不同步骤的处理和侧重。结合以往的项目，每个人就会有自己的角度。提出来的措施才不至于高高在上而不可落地。

在面试过程中，我们并不需要真的一个一个把所有的方面都挨个说一遍。重在把自己的思路和逻辑说出来，有理有据，找其中最熟悉的，列举一些典型的可操作性的步骤和计划即可。

总结

最后，总结一下，针对这种看起来“大而空”的问题，我们要发挥佛教中的“灭度”精神，按上边提到的“三大步”，所有问题都可以“可操作”、“可回答”。

1. 从阐述对问题本身的理解出发，为自己争取时间；

2. 在阐述的过程中，按某个维度对问题进行拆分；

3. 结合自己以往的工作经历，选择熟悉的方面提出有效、可行的方法和措施；

这种问题，考察的是将事情“落地”的能力，重要的是展示自己的对问题的分析、处理和解决思路。找个问题试试？

原文：https://mp.weixin.qq.com/s/bP6G9aALTQclvPbOgvQOaQ

实验日记
无意中翻到Alice之前用过的一个笔记本，里边有几篇三年级刚学写日记时的涂鸦，简简单单，但是很有意思。当时的情景就这样跟着这些蹦蹦跳跳起来……

不记得自己小时候有过这种感觉。这就是童年吧，在没有“自觉”中自顾存在，不需要去迎合谁，讨好谁。随着长大，在意的东西多了，写出来的、说出来的都还是自己想的那个吗？

《实验日记》

2021年6月6日，星期日

今天，我已经养了虾，而且都在水里跳。还捉了一个“铁牛”。你们知道“铁牛”是什么吗？是一种昆虫，对植物危害很大。是害虫。

本来我可以带回两只“铁牛”，但是因为有一只在电梯关门的时候飞了出去，就只剩一只了。

我准备好实验材料，开始实验。我做了一个番茄标本。我用显微镜看了一下，差点吐出来。番茄皮是棕色的，还有一些纹路。我发誓以后再也不吃番茄了。:(

我还看了洋葱标本，这个不是我自己做的，是那里本来就有的。它的样子比番茄好多了。是有很多圆圈和黑点组成的。

原文：https://mp.weixin.qq.com/s/J65yoHUdKtXXUd3-4HwBeQ

我长着一双大大的又黑又亮的眼睛，一张笑不停的嘴巴。我在班里算高的了，总是在队伍的末尾向前望。在班里也算正常，不像有些同学一样瘦得皮包骨头，也不像有些同学一样胖得像一团肉，我的身体十分健康。

在晚上睡觉前，我总是像抢什么礼品一样争先恐后地跳上床，从书柜里随便拿起一本书，津津有味地看起来。等到爸爸叫我睡觉时才心不甘情不愿地把书放进书柜，躺在床上。

我也很喜欢画画。我每次画画都会把用品全摆在桌子上，身子坐直，才安静地开始作画。

我也会弹钢琴。我从四岁开始弹的，已经弹了六年了。现在我马上就要参加肖邦钢琴比赛了，我每一次练习都像表演一样。

同时，我也很乐观。别的同学如果不小心弄到我，我是不会怎样还手。但如果那个同学是故意的，那我不会客气。但我相信，不会有多少同学会故意弄我吧。

通过这次介绍，你知道我是谁了吗？

原文：https://mp.weixin.qq.com/s/l1G6AlyEs52KaFvUq3dvEA

这里重点学习一下回归算法

机器学习基础

机器学习 vs. 传统编程

三种类别

根据使用场景不同，有可以划分为三大类

监督学习

监督学习是根据已知的方法和规律，对新样本进行分类和预测。
监督学习就好比学生在学校学习各种知识和理论的过程。整个过程是在老师的监督下完成，所学知识的应用体现在平时的测试中，并且可以通过对比“标准”答案来不断改进和巩固学习成果，在下一次的测试中取得更好的成绩（预测效果）。根据目的不同，可以有分类和回归（预测）两种：

• 分类 —— 根据事物特征将其划分到已知的类别。
  • 根据事物的特征，将新遇到的事物（新样本）归类到已知的某个类别。
• 回归（预测）—— 根据事物的特征和预测将来的发展趋势。
  • 根据事物的特征和发展规律，预测将来的发展趋势。