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

Сотрудники могут быть активными в разное время, заниматься семейными делами в середине рабочего дня (и это нормально — люди должны работать тогда, когда они могут быть наиболее продуктивными). Но это значит, что если возникает недопонимание, его гораздо сложнее устранить. Далеко не все люди будут стучаться в разные чаты, пытаясь что-то уточнить.

На практике чаще получается так, что люди просто руководствуются своей логикой, и решают вопросы так, как им кажется верным. Это случается и с новичками, и со «старичками» (а что, я ведь отлично знаю, как всё устроено!), особенно если периодически всё меняется. Так как сообщать удаленным сотрудникам о методах и процедурах работы вашей команды, если они не могут просто кричать соседу по офису: «Эй, а как мы здесь проводим проверку кода?»

Контрольные списки!

Списки в помощь разработчикам

Мы в 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, можно узнать тут.