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.

Опубліковано: 23/01/19 @ 11:00
Розділ Різне

SEO Блог