Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
«На проводе» или два эпизода из жизни распределенной команды<br />Калугин Александр, info@pmarcor.com<br />
Об авторе<br />Ph.D, PMP<br />Менеджер менеджеров<br />Автор http://pmarcor.com/<br />2<br />
Disclaimer<br />Практический опыт, а не серебряная пуля.<br />Без изящества.<br />Выводы сделаны на нерепрезентативной выб...
Что было<br />Компания по заказной разработке ПО.<br />Один офисразработки. Низкий turnover. <br />Большое количество прое...
Чего хотели<br />Увеличить размер команды. Не  менять процесс.<br />Новый офис просто должен стать еще одним орг подраздел...
Что сделали. Эпизод #1<br />Решили создать офис «с нуля» в другом городе:<br />Нашли руководителя офиса. <br />Развернули ...
Технологические моменты<br />За одним компьютером Remote Desktop<br />Личный разговор  Skype<br />Митинг  Skype Confere...
Эпизод 1. Картина 1.Испытытательный срок<br />Проблема<br />Очень тяжело удаленно оценивать работу новых сотрудников: То л...
Краткосрочные командировки (~1 недели) в основной офис.
Дополнительные процессы review</li></ul>8<br />
Эпизод 1. Картина 2.Стиль работы<br />Проблема<br />Помимо процесса, есть еще и стиль работы «неписаные правила». Не поним...
Лекции новичкам о том «как мы работаем».
Попытки научить нового руководителя офиса.</li></ul>9<br />
Эпизод 1. Картина 3.Мы с тобой одной крови<br />Проблема<br />Так как все новички, у всех по началу не получается то, что ...
PR основного офиса, помощь со стороны его сотрудников
Team-Building</li></ul>10<br />
Эпизод 1. Картина 4.Проблемы с лидером<br />Проблема<br />Сложно найти dev-lead-ов, которые смогли бы эффективно работать ...
Постепенное воспитание Dev-Lead-ов.
Осмысление и формализация роли Dev-Lead-а.</li></ul>11<br />
Эпизод 1. Картина 5.Стеснение<br />Проблема<br />Сотрудник, если его подключают на проект, так как он лично не знаком с ег...
Инициатива со стороны сотрудников основного офиса. Kick-off митинги.  Перекрестное опыление </li></ul>12<br />
Эпизод 1. Картина 6.Непонимание задачи<br />Проблема<br />Программисты, и даже Dev-Lead-ы – не самые эффективные коммуника...
Специальный контроль понимания постановки. Обсуждениеархитектуры. Фаза прототипирования. Специальные процессы Review.
Короткие командировки (~1 неделя)при подключении к новому проекту.</li></ul>13<br />
Эпизод 1. Картина 7.«Вслепую»<br />Проблема<br />Невозможно вместе что-то порисовать. Разное понятие «о прекрасном» -- нев...
Более формальные и детальные проработки  GUI</li></ul>14<br />
Эпизод 1. Картина 8.Неудобство<br />Проблема<br />Сотрудники основного офиса не хотят работать с новыми сотрудниками, так ...
Выделение дополнительного времени «на процесс».
Временные подключения и «Чередованиязадачи».
Период привыкания.</li></ul>15<br />
Upcoming SlideShare
Loading in …5
×

"На проводе" или два эпизода из жизни распределённой команды (Александр Калугин)

1,205 views

Published on

  • Be the first to comment

"На проводе" или два эпизода из жизни распределённой команды (Александр Калугин)

  1. 1. «На проводе» или два эпизода из жизни распределенной команды<br />Калугин Александр, info@pmarcor.com<br />
  2. 2. Об авторе<br />Ph.D, PMP<br />Менеджер менеджеров<br />Автор http://pmarcor.com/<br />2<br />
  3. 3. Disclaimer<br />Практический опыт, а не серебряная пуля.<br />Без изящества.<br />Выводы сделаны на нерепрезентативной выборке. Вам может не помочь.<br />Юридическо-финансовые вопросы - за кадром.<br />Не упоминаются проблемы и вопросы, связанные с технологиями.<br />Офисы в России, в том же часовом поясе.<br />3<br />
  4. 4. Что было<br />Компания по заказной разработке ПО.<br />Один офисразработки. Низкий turnover. <br />Большое количество проектов.<br />Проектная структура организации. <br />Гибкий процесс, документированный только на высоком уровне.Иногда процесс модифицируется под заказчика.<br />4<br />
  5. 5. Чего хотели<br />Увеличить размер команды. Не менять процесс.<br />Новый офис просто должен стать еще одним орг подразделением, сотрудники которого должны влиться в проектную структуру компании.<br />Сотрудники нового должны участвовать в разработке наравне с сотрудниками основного. Должно быть не критически важно, собирается ли команда проекта из сотрудников одного или нескольких офисов. <br />Возможность выполнения проектов полностью командой доп. офиса.<br />5<br />
  6. 6. Что сделали. Эпизод #1<br />Решили создать офис «с нуля» в другом городе:<br />Нашли руководителя офиса. <br />Развернули мат базу.<br />За короткое время набрали команду ~10 человек (программисты) из различных компаний. Нет явных лидов<br />Начали работать.<br />Что же получилось... (см. на обороте)<br />6<br />
  7. 7. Технологические моменты<br />За одним компьютером Remote Desktop<br />Личный разговор  Skype<br />Митинг  Skype Conference Call (with video)<br />Совместное редактирование, спецификации  Google Docs<br />Общий Bug-Tracker, ПО по управлению проектами<br />Общий SVN<br />7<br />
  8. 8. Эпизод 1. Картина 1.Испытытательный срок<br />Проблема<br />Очень тяжело удаленно оценивать работу новых сотрудников: То ли он старался, но не получилось, то ли не старался. <br />Решение<br /><ul><li>Средства слежения
  9. 9. Краткосрочные командировки (~1 недели) в основной офис.
  10. 10. Дополнительные процессы review</li></ul>8<br />
  11. 11. Эпизод 1. Картина 2.Стиль работы<br />Проблема<br />Помимо процесса, есть еще и стиль работы «неписаные правила». Не понимают приоритетов, срочности, что можно, а что нельзя и т. д.<br />Решение<br /><ul><li>Case Studies
  12. 12. Лекции новичкам о том «как мы работаем».
  13. 13. Попытки научить нового руководителя офиса.</li></ul>9<br />
  14. 14. Эпизод 1. Картина 3.Мы с тобой одной крови<br />Проблема<br />Так как все новички, у всех по началу не получается то, что требуют «эти из основного!». Непроизвольно объединяются перед лицом общего врага – основного офиса.<br />Решение<br /><ul><li>Разделение «по проектно». Пресечение
  15. 15. PR основного офиса, помощь со стороны его сотрудников
  16. 16. Team-Building</li></ul>10<br />
  17. 17. Эпизод 1. Картина 4.Проблемы с лидером<br />Проблема<br />Сложно найти dev-lead-ов, которые смогли бы эффективно работать в рамках сложившегося процесса. Быстрый набор команды – нет времени лидера подготовить.<br />Решение<br /><ul><li>Даже лидеры – в рядовых ролях. Dev-lead-ы из основного офиса.
  18. 18. Постепенное воспитание Dev-Lead-ов.
  19. 19. Осмысление и формализация роли Dev-Lead-а.</li></ul>11<br />
  20. 20. Эпизод 1. Картина 5.Стеснение<br />Проблема<br />Сотрудник, если его подключают на проект, так как он лично не знаком с его участниками из основного офиса, стесняется задавать вопросы, если что-то непонятно, или сообщить о проблемах. <br />Решение<br /><ul><li>Team-building. Совместные корпоративы. Видео-конференции: «Чтобы было видно глаза»
  21. 21. Инициатива со стороны сотрудников основного офиса. Kick-off митинги. Перекрестное опыление </li></ul>12<br />
  22. 22. Эпизод 1. Картина 6.Непонимание задачи<br />Проблема<br />Программисты, и даже Dev-Lead-ы – не самые эффективные коммуникаторы. Удаленный сотрудник, которому ставится задача – не всегда ее понимает корректно. Контроль результата в процессе – затруднен.<br />Решение<br /><ul><li>Более формальная письменная постановка, формализация архитектуры
  23. 23. Специальный контроль понимания постановки. Обсуждениеархитектуры. Фаза прототипирования. Специальные процессы Review.
  24. 24. Короткие командировки (~1 неделя)при подключении к новому проекту.</li></ul>13<br />
  25. 25. Эпизод 1. Картина 7.«Вслепую»<br />Проблема<br />Невозможно вместе что-то порисовать. Разное понятие «о прекрасном» -- невозможно удаленно объяснить про «2 пикселя влево».<br />Решение<br /><ul><li>Исправление GUI багов и GUI задачи – в основном офисе.
  26. 26. Более формальные и детальные проработки GUI</li></ul>14<br />
  27. 27. Эпизод 1. Картина 8.Неудобство<br />Проблема<br />Сотрудники основного офиса не хотят работать с новыми сотрудниками, так как это сложнее.И результат менее предсказуемый<br />Решение<br /><ul><li>Реклама сотрудников нового офиса, их уникальных скиллов.
  28. 28. Выделение дополнительного времени «на процесс».
  29. 29. Временные подключения и «Чередованиязадачи».
  30. 30. Период привыкания.</li></ul>15<br />
  31. 31. Эпизод 1. Картина 9.Недоверие<br />Проблема<br /> У менеджеров основного офиса нет уверенности в «добросовестности» сотрудников нового офиса. Сложно составить мнение о производительности.Руководитель офиса – тоже новичок.<br />Решение<br /><ul><li>Кросс-оценивание.
  32. 32. Чередование задачи.</li></ul>16<br />
  33. 33. Эпизод 1. Картина 10.«Рулёж»<br />Проблема<br />Нет возможности поговорить tet-a-tet. <br />Решение<br /><ul><li>Командировки менеджеров
  34. 34. Командировки сотрудников нового офиса
  35. 35. Попытки наставления нового руководителя офиса.</li></ul>17<br />
  36. 36. Что сделали. Эпизод #2<br />Dev-Lead/Менеджериз основного офиса, по cемейным обстоятельствам переехал в другой город.<br />Узнав об открытии офиса, некоторые из сотрудников изъявили желание переехать.<br />Начали работать.<br />Более постепенно набрали новичков.<br />18<br />
  37. 37. Эпизод 2.Проблемы, которых не было<br />Стиль работы транслируется руководителем офиса.<br />Более планомерный рост – противостояние основному офису, если и возникает - то более конструктивное<br />Руководитель офиса является опытным лидом – возможно выделение подпроекта как задачи новому офису. Сотрудники, перешедшие из основного офиса – менторы для новичков: как в технологиях, так и в процессе. <br />19<br />
  38. 38. Эпизод 2. Картина 1.Испытытательный срок<br />Проблема<br />Очень тяжело удаленно оценивать работу новых сотрудников: То ли он старался, но не получилось, то ли не старался. <br />Решение<br /><ul><li>Руководитель офиса может оценивать работуновичков</li></ul>20<br />
  39. 39. Эпизод 2. Картина 2.«Рулёж»<br />Проблема<br /> Нет возможности поговорить tet-a-tet. Сложности сообщения отрицательного feedback-а или приободрения.<br />Решение<br /><ul><li>Руководитель офиса выступает в качестве ресурс-менеджера, который может проводить соответствующие встречи лично.</li></ul>21<br />
  40. 40. Эпизод 2. Картина 3. Недоверие<br />Проблема<br /> У менеджеров основного офиса нет уверенности в «добросовестности» сотрудников нового офиса. Сложно составить мнение о производительности.<br />Решение<br /><ul><li>Есть возможность использовать мнение руководителя офиса, как опытного сотрудника</li></ul>22<br />
  41. 41. Эпизод 2. Картина 4.Стеснение<br />Проблема<br />Сотрудник, если его подключают на проект, так как он лично не знаком с его участниками из основного офиса, стесняется задавать вопросы, если что-то непонятно, или сообщить о проблемах. <br />Решение<br /><ul><li>Есть возможность подойти к более опытным сотрудникам, или руководителю офиса при необходимости</li></ul>23<br />
  42. 42. Эпизод 2. Оставшиеся картины<br />Проблемы которые наблюдаются и во втором эпизоде<br /><ul><li>Непонимание задачи. Другая интерпретация требований (не всегда более опытные товарищи, занятые на другом проекте могут пояснить.
  43. 43. Сложности для dev-leads восновном офисе
  44. 44. GUI задачи (по началу, только перешедшим сотрудникам, или в основном офисе)</li></ul>24<br />
  45. 45. Эпизод 2. Новая картина 1. «Челночный бег»<br />Проблема<br /> Сильный dev-lead в новом офисе может руководить командой в основном. При этом команда как бы «выпадает из жизни» основного офиса. <br />Решение<br /><ul><li>Выделение роли ресурсного менеджера в основном офисе, чтобы помогать Lead-у из дополнительного офиса.</li></ul>25<br />
  46. 46. Эпизод 2. Новая картина 2.Параллельные миры<br />Проблема<br /> Более зрелая команда в новом офисе начинает развивать процессы разработки и технологические приемы независимо от основного офиса.<br />Решение<br /><ul><li>Внутренние конференции по процессу и по технологиям
  47. 47. Создание online систем документирования и обмена знаниями (Wiki, новостная лента, и т. д.)</li></ul>26<br />
  48. 48. Эпизод 2. Новая картина 3.Потеря контроля<br />Проблема<br /> Укрупнение задачи более опытной удаленной команде и уверенность в том что она ее выполнит позволяет головному офису не вмешиваться во внутренние процессы. Однако в результате, становится сложно сравнивать производительность и квалификацию отдельных сотрудников.<br />Решение<br /><ul><li>Чередование задач
  49. 49. Аудиты</li></ul>27<br />
  50. 50. Выводы<br />Капитан Очевидность: Процесс меняется<br />Капитан Очевидность: Все зависит от людей<br />Требуется привыкание к снижению уровня личного общения. Это можно сделать заранее.<br />Требуется формализация процесса, особенно постановки задачи.Это можно сделать заранее.<br />Требуются работающие механизмы инспекции. Введение дополнительных этапов прототипирования. Это можно сделать заранее.<br />28<br />
  51. 51. Выводы #2<br />В чисто проектной структуре необходимо выделение специальной роли – ресурсных менеджеров. Требуется специальная подготовка.<br />По возможности, дополнительный офис должен формироваться постепенно<br />Необходимы специальные механизмы управления знаниями. Это можно сделать заранее<br />Необходимо готовить дев-лидов к работе с удаленными программистами. Это можно сделать заранее<br />29<br />
  52. 52. Спасибо за внимание!<br />Калугин Александр<br />http://pmarcor.com/<br />info@pmarcor.com<br />Twitter @pmarcor<br />30<br />

×