×

Crew resource management в IT-команде, или Чему нам поучиться у пилотов

Управление ресурсами команды — одна из наиболее важных задач, напрямую влияющая на качество выполнения проекта. Сегодня мы поговорим о Crew resource management (CRM) как о методологии обучения персонала, которая основывается не на технических знаниях, а на взаимоотношении членов команды, включая лидерство и принятие решений. Именно поэтому нам интересно рассмотреть некоторые аспекты этой методологии в разрезе управления командой разработчиков.

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

Методология CRM появилась в 1979 году на семинаре NASA по авиабезопасности и впервые была введена в действие в 1981 году в компании United Airlines. Сегодня CRM является обязательным курсом подготовки персонала в тех областях, где цена человеческой ошибки очень высока и может привести к катастрофическим последствиям.

Ошибки и их последствия

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

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

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

Несколько распространенных примеров из нашей IT-шной жизни:

  • Боязнь разработчика потерять репутацию, неверно оценить время на выполнение задачи приводит к тому, что «estimate» ставится уже по факту выполнения задания.
  • Сотрудник, не загруженный работой, не заявляет об этом руководителю из-за боязни быть сокращенным по причине невостребованности.
  • Опытный разработчик, который потратил больше времени на задание, чем предполагалось, боится показаться некомпетентным в глазах своих коллег.
  • Все эти случаи лишают команду возможности разобраться в ситуации, принять необходимые меры и планировать работу. Результатом является опоздание с релизами, овертаймы, постоянная гонка.

Стандартные процедуры и швейцарский сыр

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

Image Source: Wikipedia

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

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

Залог успеха выполнения любых задач — четкое понимание членами команды своих обязанностей и действий в той или иной ситуации.

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

Команда разработчиков всегда работает эффективнее, если есть набор standard operation procedures (SOP) для четкого понимания каждым членом команды своих обязанностей и задач всей команды в целом.

Нарушение правил

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

Выполнять правила всегда легче, если понимаешь их смысл.

Именно поэтому важно следить за тем, чтобы ваши процессы служили определенной цели, а люди понимали их назначение.

Если правило давно потеряло актуальность, может стоит пересмотреть или отменить его?

Практически все методики и практики в области управления проектами основываются на цикле Деминга, суть которого можно описать 4-мя фазами: Планируй, Выполняй, Контролируй выполнение, Вноси изменение в процесс.

Пересмотр процессов и правил для улучшения — обязательный элемент эффективной работы. Ретроспектива в Scrum — хороший пример такого принципа.

Многозадачность и приоритеты

Мы живем во время постоянно растущего дефицита ресурсов. Час работы IT-специалиста стоит дорого и мы не можем больше позволить себе роскошь работать над одной конкретной задачей длительное время. Участие в разных проектах, критические баги, консультации и помощь молодым коллегам требуют постоянного переключения. Без четко расставленных приоритетов наша работа рискует превратиться в суету и хаос, а эффективность будет стремиться к нулю.

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

Использование всех доступных ресурсов

В 1989 году капитан рейса 232 United Airlines в сложной аварийной ситуации принял помощь от пилота-инструктора, который летел в качестве пассажира. Именно идея, предложенная этим человеком, помогла спасти от неминуемой гибели сотни пассажиров злополучного рейса. Трудно отрицать, что сложенный воедино интеллект нескольких людей выше интеллекта одного, пусть самого опытного члена команды.

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

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

«Я начальник, ты — дурак»

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

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

Crew resource management предписывает опытным членам команды толерантно давать наставления коллегам, принимать во внимание их замечания, а также заявлять о готовности выслушать критику в свой адрес.

Опытные пилоты говорят, что обучение Crew resource management не заканчивается прохождением соответствующей подготовки. Навыки CRM воспитываются в повседневной жизни вне работы: в семье, в общении с окружающими людьми. Это выработанный стиль жизни, который помогает нам повсеместно. Для тех, кто хочет больше узнать о данной тематике, ниже привожу ссылки на доступные в сети ресурсы, а также некоторые полезные практики, взятые из работы Дениса Оканя — пилота гражданской авиации. Он один из немногих, кто освещает тему CRM среди русскоязычной аудитории.

Работайте эффективно, относитесь к людям с уважением, летайте безопасно.

Хорошие практикиПлохие практики
Знание и соблюдение правил и стандартов
Соблюдает правила и стандартные процедуры. Не соблюдает правила и стандартные операционные процедуры, не контролирует их соблюдение командой.
Вмешивается при отклонении от стандартных операционных процедур.Не вмешивается при отклонении от стандартных операционных процедур.
Консультируется с командой по вопросам отклонения от стандартных операционных процедур , когда необходимо.Применяет нестандартные подходы без объяснений.
Лидерство и управленческие навыки
Защищает собственную позицию.Мешает вовлечению членов команды во взаимодействие.
Берет инициативу на себя как для взаимодействия, так и выполнения задач.Не проявляет инициативы при принятии решений, собственная позиция не ясна.
Командует, если требует ситуация.Не дает оценки действиям.
Мотивирует команду выражением признательности, помогает, когда необходимо.Не помогает или лишает инициативы.
Планирование и координация
Поощряет участие команды в планировании и выполнении задачи.Все планирует сам, не привлекая команду.
Ясно сообщает о намерениях и целях.Намерения не сообщает и не подтверждает.
Меняет план с обсуждением в команде. Меняет план, не информируя команду.
Слепо следует плану, несмотря ни на что, даже если план потерял актуальность.
Создание и поддержание команды
Поощряет предоставление информации и обратной связи с членами команды.Блокирует открытость коммуникаций.
Не соревнуется с другими.Сохраняет барьеры между членами команды.
Соревнуется с другими.
Внимание к другим членам экипажа
Учитывает предложения других членов команды, даже если не согласен.Игнорирует предложения членов команды.
Принимает в расчет состояние и мнение членов команды.Не принимает в расчет состояние и мнение членов команды.
Предоставляет обратную связь.Не реагирует на проблемы другого члена команды.
Оценка риска и выбор решения
Рассматривает и оценивает риск, связанный с каждым вариантом решения.Неадекватное обсуждение факторов, связанных с командой.
Говорит о возможном риске, связанном с возможностями команды.Неинформирование членов команды о принятом решении.
Подтверждает выбранный способ действия.
Принятие решений
Собирает информацию и определяет суть проблемы.Не устанавливает характер проблемы или не способен ее диагностировать.
Обсуждает причинные факторы в команде.Не обсуждает возможные причины.
Принимает решение самостоятельно, не выслушав других.
Генерирование вариантов решения
Сообщает об альтернативных способах действия.Не ищет информацию.
Просит команду предлагать варианты.Не спрашивает команду об альтернативных вариантах решения.
Разрешение конфликтов
Сохраняет спокойствие в конфликтных ситуациях.Чрезмерно реагирует, настаивает на собственной позиции.
Предлагает варианты решения конфликтных ситуаций.Не идет на компромисс.
Концентрируется на том, что правильно, а не кто прав.Обвиняет других в ошибках.

По ссылкам можно найти увлекательные видеоуроки по CRM пилота Дениса Оканя, другие материалы Дениса по CRM.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному2
LinkedIn

Схожі статті




8 коментарів

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

Зайве тире перед цим реченням, воно по змісту не входить в перелік вище.

Почему-то вспомнилось
— Можно драться с двадцатью русскими истребителями или даже двадцатью «Спитфайрами», это даже возбуждает, потом можно и пошутить. Когда же атакуешь строй из сорока «Крепостей», пред глазами вмиг проносятся яркой вспышкой все твои последние грехи. С такими ощущениями мне все тяжелее требовать от каждого летчика гешвадера, особенно от самых юных унтеров, чтобы они воевали так же, как я.

А еще то, что сениорские пилоты меньше 100000 евро в Германии не получают.

Ближе к теме статьи — впервые о том, что риск довольно четко делится на оправданный и идиосинкратически (ничем не оправданный) я прочитал в мемуарах Михаила Громова — был такой пилот-рекордсмен. А уже потом столкнулся с этим в теории инвестиций.

Прекрасная статья. Сам несколько раз примерялся написать об этом, но не решился. А нас, авиаторов, в ИТ, оказывается вон сколько! :)

Отличный материал, но тема настолько обширная, что невозможно даже примерно её охватить. Недавно обсуждали CRM применительно к командам разработчиков и здесь есть одно существенное различие — это собственно через что с самых начал проходит пилот и разработчик.

В западных учебниках есть такое понятие airmanship. Мне больше всего нравится определение как «The exercise of sound judgment that results in optimal operational safety and efficiency.». Так вот пилоты этому навыку учатся со своего первого тренировочного полёта с инструктором и критически его проверяют во время первого соло вылета. Airmanship служит таким себе входящим фильтром для людей, которые могут стать пилотами и тем более коммерческими, работая в авиалиниях.

К сожалению, у разработчиков отсутствует подобный ключевой навык, поскольку разработчиками не становятся согласно определенной процедуре как у пилотов (PPL -> CPL -> ME/IR Ratings->MCC->Type Rating -> ATPL). Можно отучиться в универе, можно самому, можно на курсах, можно удалённо. Это создает некий винегрет из личных навыков и опыта, на который сложно натянуть стандартные процедуры CRM, её философию и ожидаемую профессиональную этику. Если даже в большой авиации есть примеры где применение CRM сбоило (случай Asiana 214) не раз, то что уж говорить о нашей индустрии.

Спасибо за статью. Не раз, перечитывая Дениса, непроизвольно проводил параллели с подобными процессами в сфере ИТ.
Но всё же, имхо, стандартные практики CRM достаточно хорошо экстраполируются на операционную деятельность, но не на проектную.

С другой стороны, проектная деятельность в ИТ все больше и больше становится похожей на операционную :)

Что такое операционная и проектная деятельность и чем они отличаются?

Підписатись на коментарі