Управлять удаленной командой — на порядок сложнее, чем работать в офисе, это требует куда большей подготовки от руководителя. Офисные сотрудники обычно могут пройти к другому столу и задать кому-нибудь вопрос каждый раз, когда он у них возникает. С дистанционной работой всё далеко не так просто.
Сотрудники могут быть активными в разное время, заниматься семейными делами в середине рабочего дня (и это нормально — люди должны работать тогда, когда они могут быть наиболее продуктивными). Но это значит, что если возникает недопонимание, его гораздо сложнее устранить. Далеко не все люди будут стучаться в разные чаты, пытаясь что-то уточнить.
На практике чаще получается так, что люди просто руководствуются своей логикой, и решают вопросы так, как им кажется верным. Это случается и с новичками, и со «старичками» (а что, я ведь отлично знаю, как всё устроено!), особенно если периодически всё меняется. Так как сообщать удаленным сотрудникам о методах и процедурах работы вашей команды, если они не могут просто кричать соседу по офису: «Эй, а как мы здесь проводим проверку кода?»
Контрольные списки!
Мы в 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/ЧИТО)
При заказной разработке ПО желательно проводить тесты, которые автоматически подтверждают, что код работает. Чтобы протестировать по методу RITE Way, каждый тест должен быть:
- Читабельный (Readable)
- Изолированный, чтобы ничему не повредить, или интегрированный, если проходят тесты интеграции (Isolated/Integrated)
- Тщательный (Thorough)
- Определенный и четкий (Explicit).
Тоже — вроде бы, всё очевидно. Но очень полезно это документировать, чтобы сотруднику всегда можно было показать, какого именно из пунктов он сейчас не придерживается.
Контрольный список для длительности тестирования
- Модульные тесты выполняются менее чем за 10 секунд.
- Функциональные тесты должны выполняться менее чем за 10 минут.
- Проверки CI / CD должны выполняться менее чем за 10 минут.
5 вопросов, на которые должен отвечать каждый модульный тест
- Какой компонент тестируется?
- Каково его ожидаемое поведение?
- Каков его фактический результат?
- Каков его ожидаемый результат?
- Как можно воспроизвести ошибку теста? (Дважды проверьте, что ответы на приведенные выше вопросы отвечают и на этот вопрос).
Кстати, этот список очень похож на контрольный список для отчетов об ошибках (который идёт следующим). И такое совпадение не случайно: все юнит-тесты, которые не принесли ожидаемого результата, в итоге должны становиться хорошими отчетами об ошибках.
Список для отчетов об ошибках
- Описание ошибки (включая её расположение)
- Ожидаемый результат
- Фактический результат
- Инструкции по воспроизведению ошибки
- Среда (версии браузера/ОС, расширения)
- В виде бонуса: снимок экрана или скринкаст, демонстрирующий ошибку.
Компоненты должны соответствовать принципам FIRST
Они обязаны быть:
- Сосредоточенными (Focused)
- Независимыми (Independent)
- Многоразовыми (Reusable)
- Небольшими (Small)
- Тестируемыми (Testable).
Контрольный список производительности UI
Программные UI должны соответствовать такому уровню производительности:
- Отвечать на действия пользователя менее чем за 100 мс.
- Анимация должна длиться не больше 10 мс.
- Процессы времени простоя должны быть объединены в блоки размером менее 50 мс.
- Загрузка должна происходить менее чем за 1 секунду.
Контрольный список готовности к непрерывной доставке (Continuous delivery)
- Минимум 80% кода покрывается модульными тестами.
- Все критические рабочие процессы прошли функциональные тесты.
- Все критические интеграции прошли интеграционные тесты.
- Существует система для включения и отключения функций в производственной среде. По умолчанию все незаконченные функции отключены.
Контрольный список CI / CD
- Каждая фиксация в мастере должна сначала пройти процесс пулл-реквеста. Слияние должно быть заблокировано до прохождения полной проверки.
- Каждый пулл-реквест должен быть рассмотрен коллегами перед объединением в главную ветвь.
- Каждый пулл-реквест должен пройти полный набор автоматических тестов, настроенных на остановку процесса интеграции в случае возникновения какого-либо сбоя.
- Каждая фиксация запускает собственную изолированную сборку для тестирования, демонстрации и проверки. Ссылка на сборку добавляется к данным в окне проверки кода.
- После прохождения всех проверок слияние с основным проектом разблокируется.
- Автор пулл-реквеста должен разрешить слияние (и впоследствии нести за него личную ответственность).
- Слияние должно запускать автоматическое производственное развертывание нового интегрированного кода. Следовательно, главная ветвь всегда должна отражать текущее состояние сборки продукта.
Rubrain.com — крупнейшая платформа для поиска топовых разработчиков в Восточной Европе. К нам обращаются как большие компании (PwC, Deloitte, Сбербанк, ЕВРАЗ), так и начинающие бизнесмены, которые ведут поиск программистов для стартапа. Мы предлагаем outstaffing, софтверный аутсорсинг, frontend-аутсорсинг, готовые команды для создания игр, команды разработчиков блокчейн и других специалистов для любых ваших проектов.
О том, как работает аутстаффинг ИТ-персонала в Rubrain.com, можно узнать тут.