你好 我叫Oleg，我是Alfa Bank的前端开发人员。 我想告诉您一些哲学故事-有关开发的工程方法，关于我的第一份工作和在那收集的佣金，为什么清单很重要（并挽救生命）的故事。
还有关于如何继续有效地工作，而不是从事很多小的而不是非常艰巨的任务的知识。
一切始于混乱。
他们说，在我的第一份工作（不是Alpha，不是）上，我被某种方式吸引，立即陷入了困境，伙计，现在您从事CRM，工作就在那儿。 该做什么和怎么做-我一点都不明白。 在这种情况下，他们通常会做什么？ 没错-他们跑到同事那里，开始与他们一起检查如何将代码交付到服务器，git的工作方式，我们使用的实践以及不使用的实践等等。 这种方法对我有所帮助，并且我不断建议其他人这样做。 提出询问，即使您觉得很明显，也要指明需要澄清的内容。 这很正常。 不问是不正常的。
我的下一步是使用书籍。 因为当我返回问题并获得诸如“ Yuzay linter”之类的答案时，我发现自己想知道自己该怎么做，但是我不太明白为什么。 我非常想知道腿在所有过程中的成长情况，因此我决定在书籍中寻求帮助。 “纯代码”，“完美代码”-通常，我去了标准集，他们说功能不应超过30行。 我必须马上说，这无助于理解一切并控制混乱。
是的，我开始写明显更简洁的文章，但是我通常无法解决的一堆任务形式的混乱并没有消失。 同事们决定提供一些明智的建议，例如“ Dude，您只是没有足够的优势，让我们在这里阅读一下优势，如果您也提供Scrum-master，一切都会变得很酷。”
好吧，是的。 敏捷就是一件好事。 但是当您在团队中工作时。 单面Edge有点奇怪。 我开始进一步挖掘，发现了改善书籍。 然后我遇到了系统限制理论和《目的》一书。 许多人可能都读过它，因此，我仅简要地指出，这里的主要信息之一不是立即改善所有方面，而是首先找到一个问题并加以解决。 已修复-寻找下一个并修复它。 作者通过工程方法来解决这个问题，因为工程师做了类似的事情-他们寻找问题并加以解决。
好吧，这是歌词，让我们更进一步地练习。
生活中
假设您在真空中进行某种球形处理，其中有设计人员，前端人员和测试人员。 设计人员可以在一天内绘制出布局和按钮，前端可以在三天内完成，测试人员则需要两天。 这似乎是一个简单的方案，并且很明显可以在哪里改进流程-在前端，因为它的工作最多。 也就是说，优化的重点是找到过程中最慢的阶段。
但这是一个包含三个变量的简单示例。 当然，工作通常会有所不同。 和很多不同。 当您有一个后端，文档，CI / CD和其他重要的控件时，该过程将变得很复杂。
然后就不可能立即抓住并说出哪个过程最慢以及从哪里开始。 在这里，最慢阶段的优化过程如下所示：
- 我们必须找到最慢的限制。
- 决定如何尽可能地使用它。
- 使一切服从决策。
- 制定（扩大）限制条件。
- 返回并重复。
听起来可能有些混乱，所以我将详细介绍。
该怎么办，您是否有其他并行任务在忙？
在这种情况下，您将搜索总共几天的最长路线。 在上面的图片中大约是6天。 从这个过程开始，要经过最长的过程。 事实证明，在此示例中，您将改进后端，因为它需要4.5天。 这也不是那么困难，但是当您开始并开始这样做时，您会发现生活变得更加轻松。
我将回到工作混乱的例子。 我有很多任务，但我没有时间。 我意识到前端（即我）存在局限性，问题不在测试人员中，因为他发现了错误，即在我这一边。 为此，我开始考虑如何使用此限制。
他决定我们需要更改流程，以便只有一个切入点-一个人来决定我们是否执行任务。 因为在某些情况下有人来说：Oleg，我们需要将此处的按钮向右移一点。 然后再来一个。 在半小时内，其他人也完成了类似的任务。 似乎没有什么东西和垃圾，但是最后我还是完全缝了起来，试图取悦所有人。
现在，我尝试并行执行不超过2个任务（并行而不是同时执行）。 以前，我可以给测试人员一个任务，然后执行以下操作，但是如果测试人员发现一个错误，我必须检查，记住并切换到那里编写的代码，这比经常切换时听起来要难。 通常，切换是昂贵的。 尝试并行执行两个以上的任务。 3个任务已经可以缝制了。
让我们考虑一下如何使其他一切服从于决策。 听起来似乎是合乎逻辑的，是的，如果任务太多，那么您就不需要幻灯片吗？ 例如，您希望一个人在三天内完成三个复杂程度几乎相等的任务。 如果三分之二的时间里他只完成一项任务，很可能他不适合计划，那么从上方扔给他更多的任务是一件令人沮丧的事情。
有关限制的更多信息
当然，可以扩大限制。 在我们的示例中，雇用另一条战线。 这也是合乎逻辑的，更多的战线-他们将有时间完成更多的任务。 然后限制将转移到另一个地方。
还有一种方法，他们不扩大单位数量，而是扩大自己的能力。 我有一个生动的例子-如果我知道前端，那么测试人员可以在前端帮助我。 在我的同事那里，Scrum管理员开始自己编写前端，因为他很感兴趣，他在那里眨眼间做了一些功能，他很开心，团队也提供了帮助。 我不希望在家中这样做，因为结果可能会大不相同，但例如，有这样一种方法-是的，并且有时可以。
检查清单
检查员确实有助于使生活更轻松。 这份
Alfa-Bank清单现在对我的工作有很大帮助
，其中需要完成许多步骤。
Cheklists甚至挽救了生命，我将摘录自
“理解风险。 “如何选择正确的路线 ”：
在航空业的曙光中，飞行员乘坐的飞机装备的技术装备不如今天。 仅在B-17轰炸机的体积过大且无法由一个人控制时，清单才开始在美国空军中使用。 2009年，当两架发动机从拉瓜迪亚机场起飞后立即在美航1549航班上失速时，飞行员在这种紧急情况下执行了所有清单操作，包括尝试重启发动机。 再次根据检查表，空乘人员严格监控了乘客为紧急着陆所做的适当准备。 此类清单是提高安全性的简单且廉价的方法。
在医学上，观察到不同的情况。 每年，滥用中央静脉导管都会引起大约8万例血液感染，结果，在美国医院的重症监护室中约有28,000人死亡。 那些能够生存的患者平均在重症监护上平均要多花一星期。 治疗此类感染的总费用估计为每年23亿美元。 什么可以拯救这些人？ 更好的药物来治疗感染，更好的技术？ 答案是：改善错误文化。
2001年，约翰霍普金斯医院的Peter Pronovost为复苏医生起草了一份简单的清单，以检查这些措施是否可以减少感染的传播。 这是旨在防止危险细菌进入患者的五个连续步骤：
1）用肥皂洗手；
2）用洗必泰防腐剂治疗病人的皮肤；
3）用无菌纸遮盖病人；
4）戴无菌口罩，帽子，围裙和手套；
5）将导管插入静脉后，在导管上涂抹无菌材料。
在此列表中，每项保护措施都是众所周知的，没有任何新内容。 Pronovost要求在其重症监护室工作的护士检查医生是否遵循这5条规则。 护士报告说，在安装导尿管时，超过三分之一的患者有一个或多个这些规则未得到遵守。 当时医院的血液感染率为11％。
Pronovost说服医院管理部门允许护士在错过五项规定措施中的任何一项时停止医生。 这项革命性的创新违反了医护人员（主要是女性）无权向外科医生（主要是男性）进行指导的等级结构。 严格遵循这些说明的一年后，医院患者的血液感染率从11％降低到0（！）。 在接下来的15个月中，仅发现2例此类感染病例。 仅在这家医院，指示清单就防止了43例感染，8例死亡，并节省了200万美元。
为了证明使用检查表的效果不仅限于他的医院，Pronovost说服了密歇根州的一百多个重症监护病房参加大规模的联合研究。 重要的是要注意，他们每个人都制定了与自己的文化最相关的行动清单。
参与研究的重症监护病房报告说，以前由于使用导管，他们总共有695例血液感染。 大多数部门开始使用清单后仅三个月，患者的感染率就降为零。 在进行研究的一年半中，其余的重症监护病房也设法显着降低了该指标。 实施这项挽救生命的大规模计划，无需使用昂贵的技术，也无需增加医院工作人员的数量。也就是说，这些要点中的每一个都是已知的，这不是某种新颖性或其他东西。 Peter只是以清单格式设计了它，并使其成为必需。 仅此而已。
我们不仅尝试改善结果，还尝试改善其他结果，因此我们会不断更新工作清单。 如果我突然忘记了某些东西，但在此过程中没有做任何事情，则将其放在清单上，以免下次忘记。 以前，模型经常被返还给设计师进行返工，尽管他说他立即理解了所有事情并且会正确地做，然后他只是问了我们一份清单，我把其中的一部分用于设计，并且变得更加容易。
我按动作对清单进行了排序-1个动作= 1个清单项目。 这里的主要目的还在于不要过分休息，也不要为了检查清单而进入检查清单。 页面组成是一个很好的观点。 “组成控件”-甚至更多，将有助于避免忘记控件及其细微差别。
清单可以是分层的：页面布局->页面布局->页面布局。
为什么仅仅编码还不够
需要测试。 但是并非总是需要它们。 例如，您进行了一次降落，并且不打算稍后再返回-那么就没有必要非常努力地进行降落了。 您可以用单元覆盖选择器，也可以使用end2end，但是其余单元测试则浪费时间。
但这就是为什么编码还不够的原因。 再说一次，这是第一批作品的一个例子-我不得不改变一些东西，我去找同事谈论，他们回答说他们很忙。 我的冲刺正在燃烧。 没有人可以帮助。 结果，他开始了解自己的其他能力。
假设您具有一些良好的技能，例如，使用CI / CD。 设计师为您提供了布局，然后去度假，您需要进行一些编辑或提问，但是直到他从度假回来之前，这个过程是值得的。 扩展您的技能，因为如果过程中的弱点在设计方面，那么，设计师出于多种原因被缝制了，您可以为他提供帮助。 这是另一套知识，但可以掌握。 当然，我不是在谈论完全替代专家，而是在谈论基本技能。
结论
以工程师的身份处理此问题很有用。 即使您的工作不是工程性质的。 它使您不必连续介绍所有内容，而可以发现问题并仅介绍有助于其解决方案的内容。
需要交流和讨论解决方案。 沟通原则上很难高估。 有时，由于所谓的静默主动性而出现问题。 我们有一个案例，给我们一个.Net开发人员和一个简单的任务，让他编写测试。 他迅速编写了所有内容，测试，单元测试，选择，然后由于某种原因开始做超出任务范围的事情。 显然，相信这将对我们有用。 结果，他所做的所有事情使我们花费了很多时间进行额外的同步，然后所有这些本质上都变成了垃圾。 只是因为基本的沟通问题。 不要那样做
好吧，有用的书籍清单：
- 系统限制理论（E. Goldratt）
- 关键链项目管理（E. Goldratt）
- Gemba Kaizen-一种降低成本并提高质量的方法（今井男）
- 敏捷管理：领导力和团队管理（A.Jürgen）
- 极限编程说明（K. Beck）
详细的介绍可以在
这里找到。
您是否使用清单，您是否认为它们是必要的？ 如果您有任何维护或创建清单的方法，请分享评论。