Есть два вида ошибок.

1. Ошибки инноватора.
Когда ошибка, это обратная связь на проверку гипотезы.
«Не ошибается только тот, кто ничего не делает» — отсюда.
Здесь ошибки ожидаемы и приемлемы и должны превращаться в lessons learned.

"Failure is an option here. If things are not failing, you are not innovating enough" — Elon Musk pic.twitter.com/5tc7yGFAOd

— Curiosity (@MAstronomers) September 20, 2024

2. Ошибки плохого исполнения (Bad execution).
Например, не сданная вовремя платёжка или отчет. Не сделанный или не проверенный бекап. Там, где нет неизвестности и ожидается безупречное исполнение.
Здесь ошибки неприемлемы.

Если они регулярно возникают, это может быть следствием нескольких факторов: недостаток навыков, непонимание задач, плохая мотивация, отсутствие четких инструкций или перегрузка другими задачами.

— Что делать?
— Выяснить причину.
— Как?
— Спросить человека напрямую!

Если проблема в непонимании задачи, недостатке знаний или навыков — организовать обучение, передачу знаний и тренировку.

Если инструкции кривые — переписать, точнее, пусть сам и перепишет понятно.

Если сотрудник перегружен — разобраться, что там за аврал, почему он возник и решить эту проблему

Если не хочет (!) — выяснить в чем причина и найти способ чтобы сам захотел.

Вопрос со звездочкой, кстати. Что нужно, чтобы сотрудники сами хотели?

Наконец-то встретил баг на фронтенде, который привел к потерям в $$.

На скриншоте рост костов за Google Cloud Storage за одну неделю.

На одном из проектов предварительный кост за Google Cloud вырос в четыре раза.

Выяснилось: криво поставленный скрипт продуктовой аналитики на сервисе с огромным траффиком вызывал множественные повторные загрузки огромного числа файлов из Google S3.

Недавно слушал аудиокнигу “самостоятельные дети”, она начинается с очень интересного раздела про стресс.

Что под влиянием страха человек (любого возраста) сначала вырабатывает адреналин (с реакциями бей или беги), а под длительным влиянием стресса — вырабатывает кортизол. При этом есть особенность, что у животных кортизол исчезает из крови в течение десятков часов (одних суток), а у людей он держится несколько дней, иногда до недель.

И под влиянием кортизола у человека угнетается сначала когнитивная функция, способность запоминать (кортизол разрушает клетки в мозге которые отвечают за память). Человек начинает «тормозить», ошибаться, потом начинаются нарушения сна, которые усугубляют потерю когнитивных функций и снижают мотивацию (внутреннее желание и порывы) человека к действию, человеку становятся безразличны его деятельность и смыслы к существованию.

Снижается уровень дофамина, норадреналина и серотонина.
Хронический стресс приводит к выученной беспомощности — если чтобы человек ни делал, ситуация не улучшается, зачем вообще пытаться? Это чувство заставляет думать, что человек не в силах справиться с задачей, хотя на самом деле вполне качественно мог бы её решить.

А дальше, если стресс не уменьшается, кортизол приводит к изменениям в головном мозге создавая сначала депрессивное состояние, а потом вызывает эту болезнь, с печальными последствиями.

Это очень коррелировало с теми вещами которые я до этого писал про выгорание (Burnout).

Так что, несмотря на то, что короткая «живительная» обратная связь, «морковка сзади» может оказаться полезной, «активировав» человека на короткий период, постоянно прибегать к ней — пагубный способ управления.

Окошмаренные люди, на продолжительном периоде мотивированные агрессивными сроками, обвинениями, угрозами увольнением, в страхе и стрессе, как правило, замыкаются и замирают, а не демонстрируют инновации и свои лучшие качества.

Как-нибудь я расскажу о совершенно лютом проекте, на котором весь менеджмент и команда разработки набрала в среднем +15-20 кг, заедая стресс.
Проект был крутой, с агрессивными сроками, огромным количеством фич и высокими рисками.

Полезные ссылки
Тест Бойко (Диагностика уровня эмоционального выгорания)

Оказалось, что многие разработчики не знают, что можно не создавать коммит изменений в коде, чтобы переключиться на другую ветку, что-то поправить и вернуться к своей текущей задаче.

Бывает удобно, когда нужно быстро пофиксить баг и вернуться.

1. Способ через git stash

Если вы внесли изменения в вашем рабочем каталоге и хотите переключиться на другую ветку без коммита, вы можете использовать `git stash`. Это временно сохранит ваши изменения и очистит рабочий каталог.

Вот шаги:

1. Сохраните изменения с помощью stash:

git stash

2. Переключитесь на другую ветку:

git checkout [имя_ветки]

3. Если вы захотите вернуть свои изменения на текущей ветке, используйте:

git stash apply

Если у вас несколько сохраненных изменений в stash, вы можете увидеть список всех stash с помощью:

git stash list

И применить конкретный stash с помощью:

git stash apply stash@{номер}

Учтите, что `git stash apply` применяет изменения, но оставляет их в stash. Если вы хотите применить изменения и удалить их из stash, используйте:

git stash pop

2. Способ через git worktree

git worktree позволяет вам иметь несколько рабочих копий одного репозитория. Таким образом, вы можете работать в одной ветке в одной рабочей копии, а в другой ветке — в другой рабочей копии.

1. Добавление новой рабочей директории для другой ветки

Например, вы работаете над функцией в ветке `feature-x`, но вам также нужно срочно внести изменения в `master`.

git worktree add ../worktree-master master

Это создаст новую рабочую директорию `worktree-master`, где активной будет ветка `master`.

2. Создание новой ветки в новой рабочей директории

Если вы хотите начать работу над новой функцией и хотите, чтобы у нее была своя рабочая директория:

git worktree add ../worktree-feature-y feature-y

Если ветка `feature-y` еще не существует, она будет создана автоматически.

3. Просмотр списка рабочих директорий

git worktree list

Это покажет вам все текущие рабочие директории и их связанные ветки.

4. Удаление рабочей директории
   Если вы закончили работу в дополнительной рабочей директории и хотите ее удалить

rm -rf ../worktree-feature-y
git worktree prune

Здесь мы сначала удаляем директорию, а затем говорим Git очистить устаревшие рабочие директории с помощью команды `prune`.

3. Самый не технологичный способ: сделать клон проекта в соседней дирректории

Да, можно сделать git clone репозитория в соседнюю дирректорию, сделать срочные изменения и запушить их, не трогая при этом ничего в текущей рабочей копии.

1. Интересный факт, что в 12 принципах лежащих в основе Agile, пункт про техническое совершенство идет четверым с конца. Даже развернулась небольшая дискуссия в Linkedin на этот счет.

Если читать их по порядку, может сложиться представление, (в духе манифеста) что несмотря на то, что мы ценим нижние 4 пункта, верхние четыре мы ценим все-таки больше. Так ли это?

Техническое совершенство и вообще все параграфы этого документа снизу вверх, на мой взгляд, должны рассматриваться как фундамент для достижения Agility.

(попалась картинка в тему)

2. Agile Manifesto очень гибко обходит вопросы сроков и бюджетирования, так что вот два обоснованных мнения на этот счет от ChatGPT:

A. While there is value in meeting deadlines, we value technical excellence more.

By emphasizing technical quality, we ensure the foundation for resilient and adaptable solutions. A fixation on deadlines might risk the integrity and sustainability of our work. We believe that by striving for excellence today, we reduce the risk of future setbacks and rework, leading to better outcomes in the long run. Even in the face of time constraints, our commitment to quality remains paramount.

B. While there is value in technical excellence, we value meeting deadlines more.

In a rapidly evolving environment, delivering on our commitments in a timely manner ensures trust, momentum, and immediate value. Technical quality is vital, but we believe that it should not compromise our ability to meet the expectations set with our stakeholders. Balancing excellence with timeliness, we ensure both immediate impact and a foundation for continuous improvement. In our journey, the punctuality of our deliveries stands at the forefront.

На моем опыте, у бизнеса и технических команд возникает конфликт интересов в точке соблюдения сроков и обеспечения качества кодовой базы. В случае работы по итерациям, обязательство заделиверить что-то в конце спринта — это компромисс между поставкой ASAP (в интересах бизнеса) и бесконечным доведением до идеала (в интересах технических команд).

Помогает прозрачность в обе стороны: технические команды должны знать, почему что-то важно для бизнеса, какие последствия, а бизнес должен быть информирован о том, что что-то важно в технике и последствия. Это увеличивает доверие и становится проще договариваться.

Эта хайповая картинка хотя и пытается рассказать о том, что Agile это про итеративный импрувмент, на мой взгляд, некорректна.

Здесь две проблемы:

1. Предполагается, что на каждом этапе заказчик хочет разного: то скейтборд, то самокат, то велоспед. Что правдой не является: заказчик обычно сразу знает, что он хочет именно автомобиль, а не какой-то эфемерный транспорт каким бы паршивым он ни был. Если дать ему самокат вместо автомобиля он его сразу отвергнет.

2. Так как из скейтборда невозможно сделать самокат, а из самоката невозможно сделать велосипед, как и из велосипеда невозможно сделать автомобиль — предполагается что результаты предыдущей работы выбрасываются и новый этап начинается с нуля. Так не бывает, обычно весь импрувмент как раз и строится на основе предыдущих разработок (привет легаси!)

Мы всегда идем от автомобиля. Он должен быть самым простым, хоть как повозка на колесах, но это всегда автомобиль, на каждом шаге.
Вот правильная картинка про Agile:

Reference: Allen Houb

Наткнулся на блестящий комментарий к видео с беседой о проблемах скрам и том почему аджайл все-таки не работает. Если нет времени смотреть все 1.5 ч интервью:

Большинству компаний не нужна гибкость, им нужен водопад с высокой пропускной способностью. Они уже определились с объемом работ, сроками и ресурсами. Они просто думают, что Agile каким-то волшебным образом повысит производительность (и винят разработчиков, когда это не происходит).

Попался невероятно хороший пост про баги и проблемы платежных систем, которые создают уязвимости и риски потери денег.

Ссылка на хабр: 20 лет проблем приема платежей

Документ на ~450 страниц который поможет разобраться с GDPR. Внутри много схем, картинок, ссылок и всяческих примеров.

Скачать документ

Не всегда для того чтобы победить проблемы с деплоем, сформировать отдельные команды для работы над разными частями продукта нужно заниматься такой русской народной забавой как распиливание монолита на микросервисы.

Пара статей по этому поводу, не теряющих актуальность на сегодняшний день
https://m.signalvnoise.com/the-majestic-monolith/ от 2016г
https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ и от 2020