Post on 16-Jun-2015
«На проводе» или два эпизода из жизни распределенной команды
Калугин Александр, info@pmarcor.com
Disclaimer• Практический опыт, а не серебряная пуля.• Без изящества.• Выводы сделаны на нерепрезентативной
выборке. Вам может не помочь.• Юридическо-финансовые вопросы - за
кадром.• Не упоминаются проблемы и вопросы,
связанные с технологиями.• Офисы в России, в том же часовом поясе.
3
Что было1. Компания по заказной разработке ПО.
2. Один офис разработки. Низкий turnover.
3. Большое количество проектов.
4. Проектная структура организации.
5. Гибкий процесс, документированный только на высоком уровне. Иногда процесс модифицируется под заказчика.
4
Чего хотели1. Увеличить размер команды. Не менять процесс.
2. Новый офис просто должен стать еще одним орг подразделением, сотрудники которого должны влиться в проектную структуру компании.
3. Сотрудники нового должны участвовать в разработке наравне с сотрудниками основного. Должно быть не критически важно, собирается ли команда проекта из сотрудников одного или нескольких офисов.
4. Возможность выполнения проектов полностью командой доп. офиса.
5
Что сделали. Эпизод #1Решили создать офис «с нуля» в другом городе:
1. Нашли руководителя офиса.
2. Развернули мат базу.
3. За короткое время набрали команду ~10 человек (программисты) из различных компаний. Нет явных лидов
4. Начали работать.
Что же получилось... (см. на обороте)
6
Технологические моменты1. За одним компьютером Remote Desktop
2. Личный разговор Skype
3. Митинг Skype Conference Call (with video)
4. Совместное редактирование, спецификации Google Docs
5. Общий Bug-Tracker, ПО по управлению проектами
6. Общий SVN
7
Эпизод 1. Картина 1. Испытытательный срокПроблема
Очень тяжело удаленно оценивать работу новых сотрудников: То ли он старался, но не получилось, то ли не старался.
Решение• Средства слежения• Краткосрочные командировки (~1 недели)
в основной офис. • Дополнительные процессы review
8
Эпизод 1. Картина 2. Стиль работыПроблема
Помимо процесса, есть еще и стиль работы «неписаные правила». Не понимают приоритетов, срочности, что можно, а что нельзя и т. д.
Решение• Case Studies
• Лекции новичкам о том «как мы работаем».
• Попытки научить нового руководителя офиса.9
Эпизод 1. Картина 3. Мы с тобой одной кровиПроблема
Так как все новички, у всех по началу не получается то, что требуют «эти из основного!». Непроизвольно объединяются перед лицом общего врага – основного офиса.
Решение• Разделение «по проектно». Пресечение• PR основного офиса, помощь со стороны его сотрудников• Team-Building
10
Эпизод 1. Картина 4. Проблемы с лидеромПроблема
Сложно найти dev-lead-ов, которые смогли бы эффективно работать в рамках сложившегося процесса. Быстрый набор команды – нет времени лидера подготовить.
Решение• Даже лидеры – в рядовых ролях. Dev-lead-ы из основного офиса.• Постепенное воспитание Dev-Lead-ов.• Осмысление и формализация роли Dev-Lead-а. 11
Эпизод 1. Картина 5. СтеснениеПроблема
Сотрудник, если его подключают на проект, так как он лично не знаком с его участниками из основного офиса, стесняется задавать вопросы, если что-то непонятно, или сообщить о проблемах.
Решение• Team-building. Совместные корпоративы. Видео-конференции: «Чтобы было видно
глаза»• Инициатива со стороны сотрудников основного офиса. Kick-off митинги.
Перекрестное опыление 12
Эпизод 1. Картина 6. Непонимание задачиПроблема
Программисты, и даже Dev-Lead-ы – не самые эффективные коммуникаторы. Удаленный сотрудник, которому ставится задача – не всегда ее понимает корректно. Контроль результата в процессе – затруднен.
Решение• Более формальная письменная постановка, формализация архитектуры• Специальный контроль понимания постановки. Обсуждение архитектуры. Фаза
прототипирования. Специальные процессы Review.• Короткие командировки (~1 неделя) при подключении к новому проекту. 13
Эпизод 1. Картина 7. «Вслепую»Проблема
Невозможно вместе что-то порисовать. Разное понятие «о прекрасном» -- невозможно удаленно объяснить про «2 пикселя влево».
Решение• Исправление GUI багов и GUI задачи –
в основном офисе.
• Более формальные и детальные проработки GUI
14
Эпизод 1. Картина 8. НеудобствоПроблема
Сотрудники основного офиса не хотят работать с новыми сотрудниками, так как это сложнее. И результат менее предсказуемый
Решение• Реклама сотрудников нового офиса, их уникальных скиллов.• Выделение дополнительного времени «на процесс».• Временные подключения и «Чередования задачи». • Период привыкания.
15
Эпизод 1. Картина 9. НедовериеПроблема
У менеджеров основного офиса нет уверенности в «добросовестности» сотрудников нового офиса. Сложно составить мнение о производительности.Руководитель офиса – тоже новичок.
Решение• Кросс-оценивание.• Чередование задачи.
16
Эпизод 1. Картина 10. «Рулёж»Проблема
Нет возможности поговорить tet-a-tet .
Решение• Командировки менеджеров
• Командировки сотрудников нового офиса
• Попытки наставления нового руководителя офиса.
17
Что сделали. Эпизод #21. Dev-Lead/Менеджер из основного офиса, по cемейным
обстоятельствам переехал в другой город.
2. Узнав об открытии офиса, некоторые из сотрудников изъявили желание переехать.
3. Начали работать.
4. Более постепенно набрали новичков.
18
Эпизод 2. Проблемы, которых не было1. Стиль работы транслируется руководителем офиса.2. Более планомерный рост – противостояние
основному офису, если и возникает - то более конструктивное
3. Руководитель офиса является опытным лидом – возможно выделение подпроекта как задачи новому офису. Сотрудники, перешедшие из основного офиса – менторы для новичков: как в технологиях, так и в процессе.
19
Эпизод 2. Картина 1. Испытытательный срокПроблема
Очень тяжело удаленно оценивать работу новых сотрудников: То ли он старался, но не получилось, то ли не старался.
Решение• Руководитель офиса может оценивать работу
новичков
20
Эпизод 2. Картина 2. «Рулёж»Проблема
Нет возможности поговорить tet-a-tet . Сложности сообщения отрицательного feedback-а или приободрения.
Решение• Руководитель офиса выступает в качестве ресурс-менеджера, который
может проводить соответствующие встречи лично.
21
Эпизод 2. Картина 3. НедовериеПроблема
У менеджеров основного офиса нет уверенности в «добросовестности» сотрудников нового офиса. Сложно составить мнение о производительности.
Решение
• Есть возможность использовать мнение руководителя офиса, как опытного сотрудника
22
Эпизод 2. Картина 4. СтеснениеПроблема
Сотрудник, если его подключают на проект, так как он лично не знаком с его участниками из основного офиса, стесняется задавать вопросы, если что-то непонятно, или сообщить о проблемах.
Решение
• Есть возможность подойти к более опытным сотрудникам, или руководителю офиса при необходимости
23
Эпизод 2. Оставшиеся картиныПроблемы которые наблюдаются и во втором эпизоде
• Непонимание задачи. Другая интерпретация требований (не всегда более опытные товарищи, занятые на другом проекте могут пояснить.
• Сложности для dev-leads в основном офисе
• GUI задачи (по началу, только перешедшим сотрудникам, или в основном офисе) 24
Эпизод 2. Новая картина 1. «Челночный бег»Проблема
Сильный dev-lead в новом офисе может руководить командой в основном. При этом команда как бы «выпадает из жизни» основного офиса.
Решение• Выделение роли ресурсного менеджера в основном офисе, чтобы
помогать Lead-у из дополнительного офиса.
25
Эпизод 2. Новая картина 2. Параллельные мирыПроблема
Более зрелая команда в новом офисе начинает развивать процессы разработки и технологические приемы независимо от основного офиса.
Решение• Внутренние конференции по процессу и по технологиям
• Создание online систем документирования и обмена знаниями (Wiki, новостная лента, и т. д.) 26
Эпизод 2. Новая картина 3. Потеря контроляПроблема
Укрупнение задачи более опытной удаленной команде и уверенность в том что она ее выполнит позволяет головному офису не вмешиваться во внутренние процессы. Однако в результате, становится сложно сравнивать производительность и квалификацию отдельных сотрудников.
Решение• Чередование задач• Аудиты 27
Выводы1. Капитан Очевидность: Процесс меняется
2. Капитан Очевидность: Все зависит от людей
3. Требуется привыкание к снижению уровня личного общения. Это можно сделать заранее.
4. Требуется формализация процесса, особенно постановки задачи. Это можно сделать заранее.
5. Требуются работающие механизмы инспекции. Введение дополнительных этапов прототипирования. Это можно сделать заранее.
28
Выводы #26. В чисто проектной структуре необходимо выделение
специальной роли – ресурсных менеджеров. Требуется специальная подготовка.
7. По возможности, дополнительный офис должен формироваться постепенно
8. Необходимы специальные механизмы управления знаниями. Это можно сделать заранее
9. Необходимо готовить дев-лидов к работе с удаленными программистами. Это можно сделать заранее
29
Спасибо за внимание!Калугин Александрhttp://pmarcor.com/ info@pmarcor.com Twitter @pmarcor
30