Управлять удаленной командой — на порядок сложнее, чем работать в офисе, это требует куда большей подготовки от руководителя. Офисные сотрудники обычно могут пройти к другому столу и задать кому-нибудь вопрос каждый раз, когда он у них возникает. С дистанционной работой всё далеко не так просто.
Сотрудники могут быть активными в разное время, заниматься семейными делами в середине рабочего дня (и это нормально — люди должны работать тогда, когда они могут быть наиболее продуктивными). Но это значит, что если возникает недопонимание, его гораздо сложнее устранить. Далеко не все люди будут стучаться в разные чаты, пытаясь что-то уточнить.
На практике чаще получается так, что люди просто руководствуются своей логикой, и решают вопросы так, как им кажется верным. Это случается и с новичками, и со «старичками» (а что, я ведь отлично знаю, как всё устроено!), особенно если периодически всё меняется. Так как сообщать удаленным сотрудникам о методах и процедурах работы вашей команды, если они не могут просто кричать соседу по офису: «Эй, а как мы здесь проводим проверку кода?»
Контрольные списки!
Мы в Rubrain.com используем чеклисты уже много лет. При разработке программного обеспечения их особенно много, например, если использовать принципы SOLID в объектно-ориентированном дизайне. Но удивительно то, что многие этого не делают и не знают.
Недавно на эту тему для Kindle вышел бестселлер The New York Times — Checklist Manifesto. Если вы знаете английский, и занимаетесь менеджментом, это очень неплохое чтение. Её автор, Атул Гаванде — знаменитый американский журналист и хирург, занимающийся оптимизацией систем здравоохранения. Он рассказывает, как избежать простых ошибок, ведущих к фатальным последствиям. И что можно сделать в компании любого масштаба, чтобы она стала намного более устойчивой к человеческим факторам.
В частности, там описывается ситуация, особенно актуальная сейчас, когда весь мир страдает от худшей глобальной катастрофы со времён Второй мировой. Стивен Луби, профессор медицины и эксперт по инфекционным заболеваниям из Стэнфорда, с деньгами от Proctor & Gamble проводил исследование. Он проверял эффективность антибактериального мыла. И обнаружил его крайнюю эффективность: вероятность заражения при его использовании снижалась на 35-52%.
Но ещё более неожиданным было то, что бренд и стоимость мыла практически никак не влияли на результат. Разница была в пределах статистической погрешности. Важно было одно: как именно люди использовали мыло. Если участникам выдавали инструкцию, пусть даже самую «очевидную», вероятность успеха значительно повышалась. Достаточно было выдать людям самый элементарный список. Например, у исследователей был листочек с надписью:
Когда мыть руки:
— Перед приготовлением еды
— После чихания или кашляния
— После вытирания младенца
— После использования туалета
Большинство людей уже выполняли все или некоторые из этих действий, но некоторые — не все, или недостаточно тщательно. Списки сработали, вероятность заразиться у людей с «божественным листочком» снизилась на 20%. По этой же причине, кстати, в больницах есть эти плакаты со списками — что делать в случае той или иной болезни. Если вы всё это знаете, найдется кто-то, для кого подобная инструкция станет открытием.
Ещё один контрольный список в исследовании содержал такие инструкции:
— Используйте мыло.
— Полностью намочите обе руки.
— Трите мыло, пока оно не образует пену, полностью покрывающую обе руки.
— Мойте руки не менее 20 секунд.
— Полностью смойте мыло.
Это практически та же инструкция, которую нам повторяли из разу в раз во время коронавируса. И не зря! Исследование Стивена Луби показало, что её наличие повышало эффективность работы с мылом даже среди взрослых и вполне образованных людей. Всё-таки, следовать инструкции намного проще, чем задумываться о чём-то самому. Создание списков изменило поведение многих людей, и оказало гораздо больший эффект, чем все остальные факторы (тип мыла, стоимость мыла, расположение мыла), вместе взятые.
Когда мы прочитали Cheсklist Manifesto в бумажном виде в далеком 2014-м, мы начали пытаться создавать всё больше списков и коротких инструкций для своих команд разработчиков. Заносить все процедуры «на бумагу» (а точнее, в гугл-документы или в прикрепленные сообщения Slack). Даже если человек что-то забывает, он может легко освежить память. Или войти в правильное расположение духа, правильное настроение для конкретной задачи. Плюс такие инструкции совершенно незаменимы для новичков.
Конечно, все используют списки в своей работе. Но не всегда в таком масштабе. Если вы поговорите с членами наших команд программистов, особенно тех, которых арендуют у нас по договорам аутсорса, а не аутстаффа, вы увидите, что мы создаем чеклисты для очень многих вещей. Лучшие из них:
- Содержат короткие фразы, чтобы каждый пункт можно было запомнить.
- Являются обязательными к выполнению.
- Имеют только несколько ключевых пунктов.
Если список становится чересчур длинным, эффективность его выполнения, к сожалению, быстро снижается. Люди начинают видеть в пунктах просто дополнительные рекомендации.
Вот несколько примеров реальных списков, которые мы используем в некоторых наших командах разработки ИТ-продуктов. Часть из них (как FIRST и производительность UI) — хорошо известны, их разработали сторонние организации, сейчас их применяют тысячи компаний по разработке программного обеспечения на заказ. Некоторые другие (в том числе 5 вопросов, время тестирования, список CI/CD) — адаптировали или придумали мы, основываясь на лучших практиках индустрии.
Перед тем, как принять pull-реквест, в процессе Code Review следует проверить, что:
- Пулл-реквест достаточно небольшой (в противном случае, разбейте его на несколько)
- Код читабелен
- Код протестирован
- Функции задокументированы
- Файлы размещены и проименованы правильно
- Состояния ошибок отрабатываются должным образом
- В виде бонуса: приложены скриншоты или скринкасты, демонстрирующие корректную работу функции.
О правильном подходе к написанию Pull Request и грамотной реакции на чужие реквесты на Хабре есть хорошая статья.
При заказной разработке ПО желательно проводить тесты, которые автоматически подтверждают, что код работает. Чтобы протестировать по методу RITE Way, каждый тест должен быть:
- Читабельный (Readable)
- Изолированный, чтобы ничему не повредить, или интегрированный, если проходят тесты интеграции (Isolated/Integrated)
- Тщательный (Thorough)
- Определенный и четкий (Explicit).
Тоже — вроде бы, всё очевидно. Но очень полезно это документировать, чтобы сотруднику всегда можно было показать, какого именно из пунктов он сейчас не придерживается.
- Модульные тесты выполняются менее чем за 10 секунд.
- Функциональные тесты должны выполняться менее чем за 10 минут.
- Проверки CI / CD должны выполняться менее чем за 10 минут.
- Какой компонент тестируется?
- Каково его ожидаемое поведение?
- Каков его фактический результат?
- Каков его ожидаемый результат?
- Как можно воспроизвести ошибку теста? (Дважды проверьте, что ответы на приведенные выше вопросы отвечают и на этот вопрос).
Кстати, этот список очень похож на контрольный список для отчетов об ошибках (который идёт следующим). И такое совпадение не случайно: все юнит-тесты, которые не принесли ожидаемого результата, в итоге должны становиться хорошими отчетами об ошибках.
- Описание ошибки (включая её расположение)
- Ожидаемый результат
- Фактический результат
- Инструкции по воспроизведению ошибки
- Среда (версии браузера/ОС, расширения)
- В виде бонуса: снимок экрана или скринкаст, демонстрирующий ошибку.
Они обязаны быть:
- Сосредоточенными (Focused)
- Независимыми (Independent)
- Многоразовыми (Reusable)
- Небольшими (Small)
- Тестируемыми (Testable).
Программные UI должны соответствовать такому уровню производительности:
- Отвечать на действия пользователя менее чем за 100 мс.
- Анимация должна длиться не больше 10 мс.
- Процессы времени простоя должны быть объединены в блоки размером менее 50 мс.
- Загрузка должна происходить менее чем за 1 секунду.
- Минимум 80% кода покрывается модульными тестами.
- Все критические рабочие процессы прошли функциональные тесты.
- Все критические интеграции прошли интеграционные тесты.
- Существует система для включения и отключения функций в производственной среде. По умолчанию все незаконченные функции отключены.
- Каждая фиксация в мастере должна сначала пройти процесс пулл-реквеста. Слияние должно быть заблокировано до прохождения полной проверки.
- Каждый пулл-реквест должен быть рассмотрен коллегами перед объединением в главную ветвь.
- Каждый пулл-реквест должен пройти полный набор автоматических тестов, настроенных на остановку процесса интеграции в случае возникновения какого-либо сбоя.
- Каждая фиксация запускает собственную изолированную сборку для тестирования, демонстрации и проверки. Ссылка на сборку добавляется к данным в окне проверки кода.
- После прохождения всех проверок слияние с основным проектом разблокируется.
- Автор пулл-реквеста должен разрешить слияние (и впоследствии нести за него личную ответственность).
- Слияние должно запускать автоматическое производственное развертывание нового интегрированного кода. Следовательно, главная ветвь всегда должна отражать текущее состояние сборки продукта.
Источник: https://vc.ru/hr/186989-kak-eshche-luchshe-upravlyat-udalennoy-komandoy-podruzhites-so-spiskami
#МеждународнаяАкадемияМенеджмента #МАМ #Управление #Менеджмент #Руководители #Business #Management