Распределенная команда разработчиков. Как ей эффективно управлять?

Несколько слов о себе и компании, которой управляю.

Programming Store – ресурсный центр по разработке на 1С. Мы подключаем наших специалистов в период нехватки собственных разработчиков у фирм-франчайзи или у компаний со своим ИТ-отделом.

Мой опыт в ИТ начался в 2006 году с фирмы-франчайзи, где я вырос от разработчика до руководителя отдела разработки. С тех пор прошло 15 лет. За это время я успел поработать ИТ-директором в розничном холдинге, а семь лет назад принял решение открыть ресурсный центр, которым мы с партнером управляем по сей день.

В Programming Store мы занимаемся удаленной разработкой и встраиваемся в распределенные команды, а порой и сами выступаем распределенной командой, подключая тимлидов и аналитиков.

Мы работаем в основном под чужими брендами – это связано с соглашениями о конфиденциальности.

За семь лет мы научились работать практически с любыми проектами, любыми системами управления и любыми задачами. Наши заказчики, приходя к нам поработать на тестовые пару месяцев, остаются с нами надолго, расширяя или сжимая команду в зависимости от потребностей собственных проектов.

За семь лет мне удалось поработать и со стороны заказчика крупного клиента и со стороны исполнителя – в фирмах-франчайзи и в компаниях на аутсорсе.

В этом докладе хочу кратко поделиться собственным опытом и «пятью правилами ProSto».

Правило №1. Просто выбери технологию

Любой проект начинается с выбора системы управления.

Технологий множество, но я выделяю две базовых, от которых все отталкиваются, – система стандартов PMI и философия гибкого управления Agile.

Плюсы PMI:

• прозрачность бюджета;

• последовательные этапы;

• четкое планирование;

• документация и регламенты;

• роли и обязанности.

Плюсы Agile:

• простота запуска;

• гибкость;

• вариативность ролей в команде;

• легко добавить новых участников;

• множество вариаций – Kanban, SCRUM, Lean. Лично от себя рекомендую рассмотреть вариацию Lean.

Помните, если вы выбрали какую-то технологию, то придерживайтесь ее правил. Они работают, если не пытаться менять коней на переправе.

Правило №2. Просто собери команду

Сразу оговорюсь, что слово «команда» будет звучать достаточно часто. Раз мой доклад о разработчиках, то и речь будет идти о команде разработки.

Мой опыт сбора команд на первоначальном этапе проектов разработки позволяет сформировать некий усредненный портрет разработчика, который нужен заказчику. От запроса к запросу он может варьироваться, но всегда включает в себя определенные вещи.

Идеальный программист по ожиданиям заказчика – это:

• сертифицированный специалист с опытом работы 5-7 лет;

• знающий тематику проекта;

• уровня senior или middle+;

• умеет писать по стандартам и проводить качественное тестирование собственных разработок;

• умеет определять сроки и не срывать их;

• он адекватен и умеет общаться с руководителем проекта;

• и, конечно же, он любит работать и быть на связи 24/7.

Мотивы у заказчика по сбору команды из таких разработчиков просты – это нужно для того, чтобы успешно выполнить проект. Чтобы разработчик либо реализовал задуманное, либо мог оперативно подключиться и скорректировать план работ, и ситуация шла своим чередом.

Еще каждому РП хочется, чтобы команда была неравнодушна к проекту и хотела его успешно завершить точно так же, как он и сам.

Вроде бы никаких сверхъестественных требований. Но собрать команду таких специалистов – очень сложно, довольно дорого и порой нецелесообразно

У команды тоже есть свои интересы, цели и ожидания. Разработчики в команде хотят:

• Работать с интересными задачами в команде профессионалов.

• Развития собственной квалификации. У каждого разработчика, даже внешнего, есть свой личный план развития. Я рекомендую разговаривать с разработчиком о его плане развития, чтобы встраивать его личный план в проект, проводя ротацию между блоками.

• Соблюдения договоренностей. Каждый разработчик приходит в команду проекта с определенной целью: программировать, проектировать или тимлидить.

• Видеть результат собственного труда.

Вроде бы не сложно и понятно, осталось только совместить. Если оттолкнуться от целей заказчика и команды, то напрашивается довольно простой ответ: в команду проекта разработки должны входить специалисты разного уровня, – и каждый из них должен заниматься своим и не лезть в чужое.

Как собрать эффективную команду

На этом слайде я привел рекомендуемые пропорции для состава команды. В зависимости от уровня и величины проекта состав команды может варьироваться, но пропорции примерно такие:

• Один архитектор.

• Пара сеньоров, которые выстраивают правильную культуру написания кода и решают сложные задачи.

• Три-четыре разработчика уровня мидл – это основной костяк разработки любого проекта.

• Парочка «вчерашних» джунов, которые делают несложные вещи.

РП на проекте знает, что у него есть эксперты, которые выстраивают архитектуру и решают ключевые задачи.

Остальные задачи уходят в потоковую разработку на мидлов и джунов.

Эксперты не деградируют, а мидлы и джуны работают в команде профессионалов – все довольны. Мидлы и джуны успевают даже порешать что-то сложное и подрастить свою квалификацию.

Но как же быть с неравнодушием команды? Как быть уверенным, что тот уровень разработчика, который заявляется, действительно этому соответствует?

Для этого просто проводите интервью каждого кандидата в вашу команду. Только проводите его правильно.

Цель интервью – не завалить кандидата и показать, какие вы опытные или продвинутые. Цель интервью – выявить реальный опыт разработчика, сопоставить его с целями и задачами проекта. Понять, насколько он релевантен, и определить на какой блок человек больше всего подходит.

• Проводите интервью самостоятельно или отправляйте своего хорошо подготовленного сотрудника, а не просто другого разработчика, который что-то там поспрашивает.

• Подготовьтесь к интервью и понимайте то, о чем будете спрашивать. Зачастую ответы кандидатов строятся на их опыте и не совпадают с учебником или гуглом. Не поняв ответ разработчика, вы можете забраковать хорошего специалиста.

• Оценивайте софт-скилы кандидата. На этапе интервью вы сможете понять, насколько человек впишется в команду, которую вы собираете на проекте.

Правило №3. Просто держи команду в тонусе

После того как мы собрали команду, главное – ее не разрушить, а наоборот, максимально долго держать в эффективном состоянии.

Например, у нас был проект, поделенный на два этапа, – разработка и запуск.

Наши специалисты отзывались об этом проекте очень лестно. Управлялся проект на Agile – это гибкие технологии, ежедневные стендапы и взаимопомощь. Каждый знал и понимал, как его работа влияет на весь проект в целом. РП на проекте был заряжен, открыт, постоянно общался с командой и решал их проблемы. Пока не начался запуск, проект работал на 150%.

Но на этапе запуска все пошло не так, как планировали. РП стал катастрофически мало времени уделять команде и управлению ей, потому что большую часть времени проводил у бизнес-заказчика, объясняя ему, почему все пошло не по плану.

Стендапы отменили, приоритеты задач – только высокие, причем какой из них выше из десятка назначенных – надо было решать самому разработчику.

Когда РП появлялся на связи, он мог задать вопрос, почему какая-то приоритетная задача не сделана. Получив ответ, он просто пропадал дальше, не давая никакой обратной связи.

То ли он информацию принял, то ли нет? Что делать дальше? Бросать текущую задачу и делать ту, про которую спрашивал РП? Полный ахтунг! Таких моментов становилось все больше и больше.

РП со своим чайко-менеджментом – «прилетел, поорал и улетел», – привел за месяц работоспособность команды из эффективной практически к нулю.

У нас работало пять специалистов, и через месяц они все просили снять их с проекта. Штатных разработчиков заказчика, как я знаю, даже пришлось отправлять экстренно в отпуск, чтобы они окончательно не выгорели.

Это один из примеров, как можно хорошую и эффективную команду за месяц привести к нулю.

Я не могу сказать, как РП должен был правильно поступить в этой ситуации, так как просто не знаю о договоренностях и обязательствах, которые были между РП и бизнес-заказчиком. Но РП точно не должен был бросать свою команду.

Что влияет на эффективность команды

Разберем факторы, которые заставляют команду работать эффективно и с душой.

• Грамотная и регулярная обратная связь.

• Понимание важности своей роли в проекте. Если человек считает, что он не нужен, он так и работает.
  Когда я говорю про обратную связь, я имею в виду не только обратную связь от РП к разработчику, но и обратную связь от разработчика к РП. Потому что для РП разработчик – это тот же клиент, только с другой стороны. Если вы РП, принимайте обратную связь от разработчиков, например, через метод оценки «360 градусов».

• Соблюдение договоренностей. При сборе команды каждый участник приходит на проект разработки с какими-то своими целями: проектировать, программировать, развивать компетенции. Соблюдайте эти договоренности, а в случае их нарушения объясняйте участнику, почему это происходит, и насколько долго это продлится. Обязательно получите от человека подтверждение, что он это принимает и понимает.

• На команду проекта сильно влияет уровень тимлида – он должен быть закаленный. В первую очередь, тимлид должен уметь работать с людьми и не воспринимать их как «винтики» проекта. Если разработчики видят, что РП о них заботятся, то и они будут со всей душой стараться не подвести своего руководителя.

• Команде важно всегда видеть результат собственного труда. Сюда входят выпуск пресс-релиза и поздравление о запущенном контуре системы.

• Говорите «спасибо», если вы получили нужный результат. Это мотивирует. Например, у нас был проект, на котором год длился период разработки и еще год – период запуска. По его завершению спустя два года с начала проекта РП написала команде благодарственное стихотворение, в котором упомянула практически каждого участника, а их было немало – около 50 человек. Потом к этому РП хотели попасть не только те ребята, которые участвовали на проекте, но и ребята из других команд.

Правило №4. Просто выстраивай коммуникации в команде

Все, о чем я говорил ранее, выявляется при общении. Коммуникации в команде крайне важны.

Именно коммуникации и правильное общение помогают сформировать и поддерживать единую картину мира на проекте, где каждый участник команды – разработчик или аналитик – четко понимают, что происходит.

Разберем, что нужно сделать, когда вы собираете проектную команду:

• Провести качественную установочную встречу, на которой всем участникам нужно донести:

  • для чего нужен проект;

  • какие цели он преследует;

  • какие должны быть конечные и промежуточные результаты проекта;

  • кто за что в этом проекте отвечает;

  • кто какие задачи выполняет.

• Сформировать единую картину мира.

• Определить регулярность встреч.

• Настроить инструменты коммуникаций.

С распределенными командами работают другие правила игры, чем с офисными.

Уже нет возможности на кухне за чаем пофлудить, пообщаться о том, как идут дела на проекте. Нет возможности дернуть коллегу за рукав и попросить быстренько что-то посмотреть.

Мы переехали в сеть, и это накладывает определенные рамки и границы.

Как настроить коммуникации в удаленной команде

• Выберите для себя три канала связи – текстовый чат, видеосвязь и электронная почта. И сделайте акцент на ключевых инструментах, которыми вы будете пользоваться.

  • Если вы используете мессенджеры, они должны быть удобными, с системами быстрых заметок и желательно с возможностью трансляции и интеграции. Лидеры решения у нас известны: Telegram, Skype, Zoom, Slack.

  • Если это почта, она должна быть функциональной, удобной и быть доступной из любой точки мира и из любого браузера – это не должен быть Exchange в закрытом контуре.

• Электронную почту желательно выбирать с хорошим календарем-планировщиком. Причем, календарь-планировщик нужен вне зависимости от того, какую вы технологию используете на проекте, в случае планирования гибкость – не значит расхлябанность.
  Наш самый ценный ресурс – это время. Меня раздражают ситуации, когда время крадут – нарушают продолжительность встречи или опаздывают. Или не готовятся к встрече, тратя время на рассуждения без какого-либо эффекта. Любой инструмент управления временем экономит время.

• Назначайте и проводите регулярные встречи – это вынудит других участников к ним готовиться, а значит более структурировано давать и воспринимать информацию. Запланируйте на старте проекта регулярные встречи на весь ход проекта и проводите их, не нарушая.

• В распределенной команде мы общаемся в основном текстом, поэтому помните – то, что мы пишем, люди будут читать. Поэтому используйте четкие формулировки и избегайте двусмысленности во фразах.

• Если вы видите, что переписка заходит в эмоциональный или текстовый тупик, переходите на голосовое общение. Прошу, не звоните без предупреждения, потому что это дестабилизирует собеседника. Лучше назначать созвон через 5-10 минут и не опоздать на него.

• Выработайте для команды правила общения на проекте. Они помогут дисциплинировать команду и используются как инструмент контроля сотрудников. В нашей команде используются такие правила:

  • реакция на электронное письмо – в течение 30 минут;

  • реакция на сообщение в корпоративном мессенджере – 15 минут;

  • в срочной ситуации делаем звонок – на него всегда отвечаем. Если не баловаться с приоритетами и не звонить по каждому поводу, работает отлично.

Правило №5. Просто не забивай на контроль

Работа в распределенных командах и в удаленном режиме вывела на первый план два важных аспекта: доверие и контроль. Наша с вами задача – найти баланс между этими двумя аспектами, ведь излишний контроль точно так же вреден, как и излишнее доверие.

Я выделяю несколько вариантов контроля:

1. Критерий отклонения производительности разработчика от нормативных параметров. Каждый разработчик работает с разной производительностью, если мы говорим о сеньорах и мидлах. Причем с течением жизни разработчика на проекте его производительность не будет меняться. Будет меняться квалификация, но средняя скорость программирования останется той же.

Измерьте среднюю скорость программирования разработчика относительно собственных нормативных значений. Тогда у каждого разработчика появится планка производительности.

Если производительность вдруг начинает падать и опускаться ниже планки, тогда имеет смысл вмешаться. Возможно разработчика поставили на задачи, которые он просто не тянет, или он слишком много отдыхает в перерывах, – такое тоже возможно.

2. План/факт работ на месяц и неделю. Хорошее правило – на этапе постановки задач привлекать разработчика для установки сроков. Когда разработчик участвует в установке сроков именно той задачи, которую он выполняет, он берет на себя за это ответственность – тогда ему уже гораздо сложнее эти сроки нарушить.

Если сроки будут съезжать, разработчик сам инициирует созвон и корректировку сроков с объяснением причины:

• либо была допущена ошибка на этапе установки сроков;

• либо выявились какие-то подводные камни.

Если сроки назначить принудительно, разработчик может ответить: «Сроки изначально были нереальные». Наверное, все хоть раз слышали эту фразу.

3. Ежедневная отчетность. Требуйте от разработчиков ежедневных отчетов о том, на что было потрачено рабочее время. Как только вы перестанете вести отчеты, вы потеряете не только инструмент контроля за разработчиком, но и инструмент контроля за бюджетом и этапом.

К тому же ни один разработчик 30 апреля не вспомнит о том, что он делал 3 апреля – ему проще выдумать задачу, чтобы хоть что-то написать.

Следующие два варианта контроля больше подходят для гибких технологий.

4. Нахождение на рабочем месте. Очень интересный элемент контроля, я подглядел его у одного из наших заказчиков.

Утром, когда команда выходит на работу, все здороваются в корпоративном мессенджере. Уходя на обед и возвращаясь с него, они тоже об этом пишут. И вечером, когда уходят с работы, прощаются. Вроде бы нехитрый элемент вежливости, но он позволяет понять, где и сколько сотрудник находился.

5. Визуальный контакт. Во время ежедневных стендапов, еженедельных встреч и созвонов просите участников команды включать камеры. Если камер нет, пусть либо купят, либо запускают чат на телефоне. От этого вы получаете визуальный контроль сотрудника, видите, где он находится.

Если сотрудник из раза в раз находится на одном и том же месте, и это место на ваш субъективный взгляд предназначено и подходит для работы, – все отлично. Если же разработчик каждый раз на новой локации или вокруг него бегают дети, скорее всего, его работоспособность будет страдать.

Есть еще пара неплохих, но спорных инструментов – например, мониторинг активности рабочего стола разработчика. Я их в доклад включать не стал, но их тоже можно рассмотреть.

Инструменты для постановки и трекинга задач

Поскольку у нас ресурсный центр, мы встраиваем свои процессы разработки в учетные системы заказчика. За это время мы поработали, наверное, со всеми системами, которые существуют.

Есть, конечно, топ-лист инструментов, с которым все знакомы:

• Jira;

• СППР;

• Redmine;

• Bitrix 24;

• 1С:Документооборот;

• Trello.

Я не буду подробно останавливаться на этих инструментах. Единственное, что скажу – ведите задачи хоть в Гуглдокс, только ведите и не забывайте их фиксировать. Не сваливайтесь при установке задач в переписку и в телефонные разговоры.

Мы у себя в компании используем собственное решение на базе 1С:Документооборот.

Система учета и трекинга задач – это лишь часть качественной постановки. Нам важно понять, что задача разработчиком принята и будет выполнена именно так, как и предполагалось. Есть несколько хороших инструментов, которые помогут в постановке задач.

1. Контрольный пример в постановке. Мы в разных вариациях делали по-разному.

• Можно просто описать, какие данные должны быть на входе, а какие – на выходе.

• Или предоставить видео проведения контрольного примера.

• Или вордовский файл со скринами о том, как меняется информация.

2. Узнайте, как будет решаться задача. После того как разработчик принял задачу и проанализировал, созвонитесь с ним и узнайте, как он собирается делать задачу. Так вы сможете отловить ошибки, если разработчик понял задачу неправильно.

3. Задачи не более 16 часов. Это цифра, которую вы можете варьировать. Главное, не делайте бесконечных задач больше недели.

Если задача на день-два, вы можете на ежедневном стендапе контролировать ее статус выполнения. Если прошло 8 часов, а экватора задачи нет, значит надо вмешиваться и уточнять. Когда я говорю про 16 часов, то имею в виду полное время выполнения задачи – от анализа до завершения тестирования, а не только время на программирование.

4. Предоставьте разработчику доступ к полному ТЗ на проект. Есть такие специалисты, которым для того, чтобы понять частное, сначала нужно увидеть полное. Сотрудник потратит день на чтение ТЗ, зато у него сложится полная картина мира о том, что происходит на проекте, и как его небольшая задача встраивается в большой блок.

Инструменты для повышения эффективности

Но разработчику на проекте нужны не только инструменты по постановке задачи. Для повышения эффективности важно использовать:

1. Подходящую среду разработки. Опираясь на свой опыт, я считаю, пока что не придумали ничего надежнее и проще, чем набор хранилищ – хранилище разработки, тестирования, поставки и продуктива.

Есть проекты с применением EDT и GITа, но их не так много, чтобы получилось сформулировать обширное мнение, насколько это надежно и удобно. Хотя те связки, которые мы видели, работают хорошо.

Небольшой офтоп про поставку и сборку релизов. Собирать релиз может не только суперопытный сеньор-архитектор с максимальными скилами, но и просто внимательный и аккуратный мидл. Это существенно сэкономит бюджет проекта, а эффект будет тот же самый.

2. Регламент проекта. Он используется как путеводитель – что делать, как делать, куда бежать разработчику в случае возникновения различных ситуаций.

Например, что делать, если сломались коммуникации с консультантом или у него все задачи с приоритетом ушли на тестирование. Это все должно быть в регламенте проекта, чтобы разработчик не выяснял это в процессе наступления ситуации.

3. Регламент разработки. Большинство разработчиков знают стандарты и пишут по ним, но часто бывает так, что на проекте принято решение в чем-то не следовать стандартам. Это должно быть отражено в регламенте разработки.

4. Код-ревью + АПК. Помимо прочего в регламенте разработки обязательно должно быть прописано, как надо проводить код-ревью – каким правилам код-ревью нужно следовать. Удобно автоматизировать код-ревью, подключить к нему конфигурацию АПК – она экономит время.

5. БСП. Каждый разработчик на вашем проекте должен знать, что содержится в БСП. Не ждите, что сотрудники с этими знаниями придут на проект. Подготовьтесь – скорее всего, многих придется этому учить.

6. Не изобретайте велосипед. Берите любые инструменты, которые экономят время: шаблоны, модифицированные консоли запросов и отчетов, специализированные системы для автоматического обновления.

Если кто-то выпустил нужную вам подсистему, купите ее. Если есть время и возможности на проекте, лучше доработать велосипед, который вы купили, и превратить его в мотоцикл.

Надеюсь, вам пригодятся пять правил ProSto:

• команда;

• тонус;

• коммуникация;

• контроль;

• и технология.