О разрушительной силе мелочей: в чём проблема? | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Разработчик на Spring Framework
-5%
iOS Developer. Professional
-8%
Golang Developer. Professional
-6%
Базы данных
-12%
Agile Project Manager
-5%
C# ASP.NET Core разработчик
-6%
Android Developer. Basic
-10%
React.js Developer
-4%
MS SQL Server Developer
-8%
Scala-разработчик
-8%
Java Developer. Basic
-8%
Алгоритмы и структуры данных
-9%
Разработчик IoT
-13%
PostgreSQL
-8%
Подготовка к сертификации Oracle Java Programmer (OCAJP) Python Developer. Professional Разработчик программных роботов (RPA) на базе UiPath и PIX Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов Node.js Developer Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes iOS Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool"
Инфраструктура
DevOps практики и инструменты
-12%
Базы данных
-12%
Network engineer. Basic
-10%
Network engineer
-4%
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Administrator Linux. Professional
-6%
Разработчик IoT
-13%
Основы Windows Server Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP NoSQL Супер-практикум по использованию и настройке GIT Супер-интенсив «СУБД в высоконагруженных системах» Экспресс-курс «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

О разрушительной силе мелочей: в чём проблема?

DevHead_Deep_LAST_11.07_4_site.png

Начну с банальности: разработка ПО — деятельность плохо предсказуемая. Трудно с высокой точностью определить объём предстоящих работ и предугадать все «узкие» и «скользкие» места. Это происходит из-за того, что самой области свойственна высокая неопределённость и изменчивость, поэтому, даже имея на руках детализированный план действий, можно с уверенностью сказать, что что-нибудь пойдёт не так.

Управление разработкой или управление проектом по разработке подвержено влиянию неопределённости в ещё большей степени: добавляются проблемы, связанные с коммуникациями, интеграцией и т.д. и т.п.

Как мы боремся с этой вариативностью?

  1. Пытаемся детализировать планы, чтобы найти потенциальные источники проблем и заранее подготовиться.
  2. Набираем в команду людей опытных, чтобы они подсказали нам, где прячутся неожиданности.
  3. Набираем людей умных и высококвалифицированных, чтобы они не спасовали перед неожиданно возникшей проблемой.

И это всё правильно, но…

Но весь мой опыт указывает на то, что причины большинства тактических провалов далеко не в отсутствии вышеперечисленных факторов. Под стратегическим провалом я понимаю ситуацию, когда мы запустили продукт в срок и в должном качестве, а он «не взлетел». А под тактическим — срыв сроков, релиз с ошибками, неудачную попытку релиза и прочие «факапы»: — Админ выкатил код и ушёл, не дождавшись от разработчика подтверждения, что всё ок. — В пятницу бросились править злой баг и выкатили вместе с хотфиксом апдейт, запланированный на понедельник и ещё не проверенный менеджером.

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

И так далее...

Декомпозиция, опыт, квалификация — это попытки прояснить ситуацию, увеличить объём того, что мы знаем. Это попытка избежать ошибок, связанных с незнанием. Но в описанных мной примерах причиной ошибок является не “незнание”.

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

Другими словами проблема в «мелочах»:

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

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

Избегание подобных «досадных ошибок», кстати это относительно недорогой процесс, может дать значительный эффект. В некоторых областях эффект более чем значим: Атул Гаванде в своей замечательной книге «Чек-лист» описал, как насаждение привычки мытья рук перед хирургической операцией снизило количество смертей из-за осложнений на несколько десятков процентов.

Поэтому игра стоит свеч и я убеждён, что каждый руководитель должен сосредоточиться на искоренении глупых ошибок в своих процессах и командах.

Ещё

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

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться