Об эксперте: Андрей Демин, генеральный директор tada.team.
Почему стоит присмотреться к методам айтишников
В психологии есть понятие «потоковое состояние» — ощущение максимальной продуктивности, когда человек полностью включен и сконцентрирован на задаче. Это состояние обязательно для работы программиста, которому одновременно нужно держать в голове большое количество абстракций и переменных, и при этом писать или редактировать код.
В Ninlabs research проанализировали 10 тыс. сессий программистов и сделали два вывода:
- Программисту нужно в среднем 10–15 минут, чтобы продолжить редактировать код после того, как его отвлекли, то есть вернуться в «потоковое состояние».
- У разработчика в среднем только один непрерывный двухчасовой сеанс «потока» в день. Остальное время фрагментировано из-за внешних факторов, а не по желанию самого программиста.
Поскольку в ИТ-секторе распространены удаленные команды, отвлекаться приходится часто. Получается, что большое количество времени далеко не дешевый специалист тратит впустую. Понимают это и в компаниях. И так как про дистанционную работу в секторе ИТ узнали задолго до начала пандемии COVID-19, то и оптимальные формы взаимодействия ищут давно. Вот пять правил, которые могут пригодиться не только в нашей сфере.
Правило 1. Привлекать минимум людей на встречи
Если можно сократить количество встреч и видеоконференций, то сделать это необходимо, попробовав решать вопросы без постоянных звонков. Правило мы выучили еще в первый год пандемии. Сейчас время его расширять: чем меньше людей начинают встречу, тем лучше.
Часто на видеозвонок собирают всех, кто имеет отношение к теме. Но не всегда участие какого-то высококлассного специалиста нужно. Чтобы не тратить его время впустую, на встрече должен быть только необходимый круг людей. Остальных можно подключить в процессе решения локальной задачи или для ответа на вопрос, если потребуется, и сразу после этого отпустить работать. Так мы минимизируем количество встреч для каждого конкретного участника команды.
Правило 2. Ограничивать количество задач
Многие разработчики привыкли работать по Agile и Scrum. Весь процесс разбивается на короткие отрезки времени — недельные или двухнедельные спринты. Во время каждого программисты решают конкретный, понятный и измеримый перечень задач. На встречах между спринтами они рассказывают о статусе выполнения и получают новые задачи.
Все дополнительные запросы в ходе спринта либо переходят на следующий отрезок времени, либо сдвигают текущие задачи, если они приоритетнее. Делаешь либо А, либо Б. Одновременно А и Б не получится.
Когда есть конкретный список задач, и ты понимаешь, что их объем внезапно не увеличится, проще настроиться на работу, распланировать день или неделю, и сосредоточиться в процессе.
Правило 3. Автоматизировать все, что может быть автоматизировано
Существуют задачи, которые повторяются из раза в раз. Их можно автоматизировать. Если говорить про наш опыт, то мы используем сервис GET Lab, который хранит код, отвечает за сборку тестовых стендов с тестовых серверов. Достаточно залить код, и он уже собирается автоматически. Специалисту приходит уведомление о готовности или об ошибках, когда что-то произошло и нужно его внимание. В результате человеку не нужно за всем следить в процессе.
Мы и наши клиенты для автоматизации рутины используем открытый API tada.team. Например, у нас есть сайт, где пользователи могут писать пожелания по новым функциям и проголосовать за них. Мы создали бота, который собирает самые ожидаемые опции и переводит в задачи на нашей платформе. Их мы сможем обсудить во время ближайшего спринта.
Автоматизировать можно многое в любой сфере. Например, в логистике дать возможность клиенту видеть путь доставки, чтобы он не отвлекал диспетчера. И отправлять пуш-уведомления логисту только тогда, когда водитель отклонился от маршрута. На складе — настроить печать одним кликом сотен счет-фактур вместо того, чтобы сто раз нажимать одну кнопку, и так далее.
Правило 4. Убирать все раздражители
Программисты по-разному подходят к планированию дня. Кто-то четко расписывает день и придерживается графика, кто-то использует «методику Pomodoro» — разбивает рабочий день на отрезки в 30 минут: концентрируется 25 минут на работе, чтобы поймать «состояние потока», и после дает себе 5 минут на отдых, — или ставит таймер на компьютере, а кто-то предпочитает плавающий график. Но общее у них одно — в процессе активной работы все раздражители лучше убирать.
Разработчики стараются изолировать себя на время от новостей, отключают пуш-уведомления или мобильный интернет, не заходят в мессенджеры. Если нужно срочно добраться до человека, можно позвонить. Помогает разделение инструментов коммуникации на личные и рабочие: например, почта для работы, мессенджеры — для личных переписок.
В опен-спейсе тоже действуют обычные правила. Нельзя громко и долго разговаривать: либо говори тихо и коротко, либо уходи в переговорку, чтобы не мешать.
Правило 5. Упрощать доступ к инструментам коммуникаций и информации
Доступ к любой информации компании должен быть упрощен до пары кликов. Например, во внутрикорпоративную платформу можно вшить записную книжку с профилями сотрудников. Так, при добавлении нового сотрудника в чат получится увидеть его должность и фотографию, чтобы потом узнать в лицо, изучить зону ответственности и, в нашем случае, стек технологий. Наличие общей записной книжки также упростит добавление сотрудников в чаты команд.
Интеграция внутрикорпоративного мессенджера с канбан-доской позволит быстро устанавливать задачи и назначать исполнителей прямо из переписки, а к каждой задаче прикреплять тематический чат.
Поскольку многих действительно раздражают короткие голосовые сообщения — порой их неудобно слушать или нужно искать наушники, — можно интегрировать в инструменты коммуникаций автоматическую расшифровку. Так мессенджер выведет содержание голосового сообщения в текстовом виде на экране.
Это несколько примеров, как упростить доступ к информации. Открытый API, наличие готовых модулей внутри платформы для создания чат-ботов и простой синхронизации данных с другими приложениями делают возможности по обеспечению удобства общения внутри команды почти безграничными.