Распространение ответственности
Инженерные идеи
Термин «распространение ответственности» относится к психологическому феномену, когда важные задачи остаются невыполненными, потому что каждый из вовлеченных людей считает, что это чья-то работа.
К сожалению, этот недуг - проклятие многих инженерных команд. Вот почему задачи, на выполнение которых уходит всего несколько дней, часто заканчиваются месяцами календарного времени.
Хотя я не являюсь большим энтузиастом интернет-мемов, я создал небольшое изображение, которое, как мне кажется, адекватно суммирует мои чувства по поводу патологий, наблюдаемых в командах разработчиков программного обеспечения:
Не говоря уже о юморе, есть причины, по которым подобные вещи случаются так часто. Основными причинами являются общая сложность задачи и неспособность планировщиков задач всесторонне охватить все второстепенные подзадачи, участвующие в выполнении задачи.
Например, предположим, что Алиса, Боб и Чак работают в интернет-стартапе. Алиса работает над серверным кодом, Боб пишет HTML и JavaScript, а Чак отвечает за разработку и развертывание. Они заняты работой над новой функцией, поэтому они разделили работу между собой в зависимости от назначенных им ролей:
К сожалению, как вы можете видеть, в общей задаче есть много серых областей, которые не покрываются работой, порученной Алисе, Бобу и Чаку.
И когда менеджер по продукту спросит: «Почему не выполнена задача X?», Алиса честно ответит: «Ну, моя часть сделана», и Боб и Чак скажут то же самое.
Отчасти проблема здесь в том, что никто не владеет всей задачей. Под «владеет» я не имею в виду менеджера по продукту; Я имею в виду того, кто в состоянии предпринять конкретные действия для продвижения задачи вперед. В нашем гипотетическом сценарии никто не несет ответственности за серые зоны, поэтому эта работа не выполняется.
Другая проблема заключается в том, что Алиса, Боб и Чак сильно изолированы. У каждого человека есть определенная территория или область комфорта, и он редко выходит за ее пределы. Алиса работает с серверным кодом, и ей неудобно работать с DevOps или клиентским кодом; Боб ничего не знает о серверном программировании; и Чак немного знает и то, и другое, но нервничает из-за вторжения в владения Алисы и Боба.
Кроме того, Алиса, Боб и Чак работают по разному расписанию; у них есть много других вещей, над которыми нужно поработать, помимо этой функции. Алиса, возможно, закончила свою часть раньше, но Боб занят работой над высокоприоритетной ошибкой и может не добраться до своей части еще две недели. А Чак не может даже начать, пока работа Боба не будет сделана. Таким образом, даже если работа может потребовать только дня или двух индивидуальных усилий, время, необходимое для завершения проекта, составляет три-четыре недели.
Другая проблема заключается в том, что вовлеченные лица могут даже не знать о существовании серой зоны. На иллюстрации выше очевидно, что есть большой кусок работы, который не выполняется тремя инженерами. Но большинство описаний задач - это не диаграммы, они обычно представляют собой маркированные списки, строки в электронной таблице или задачи в системе отслеживания заявок. Обычно они выглядят примерно так:
- Задача Алисы - напишите код сервера
- Задача Боба - напишите клиентский код
- Задача Чака - создать сценарии развертывания и запустить их
В таком представлении совсем не очевидно, что в задаче чего-то не хватает.
Это одна из причин, почему роль «инженера полного стека» стала столь востребованной в последние годы. Когда один человек работает над всей задачей, он не только создает отдельные части, которые были идентифицированы, они также вынуждены обстоятельствами применять весь «клей», который связывает эти части вместе.
(Обратной стороной, конечно же, является то, что один человек не может масштабироваться. В неделе очень много часов.)
В отсутствие «супер-программиста», который может делать все, другой подход состоит в том, чтобы лучше разделить задачу, чтобы ничего не упустить. Если есть работа по интеграции клиентского кода с серверным API, то ее следует включить в список задач.
Лучший способ избежать подобных проблем - осознавать, что они случаются, и пытаться компенсировать их во время планирования. Люди подвержены ошибкам, поэтому мы изобрели такие вещи, как двойная бухгалтерия и научный метод: методы, которые помогают нам компенсировать наши когнитивные недостатки и наблюдательные предубеждения.
