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

1. Гибкие методологии в мобильной разработке Павел Кравченко Service2Media, Ciklum

2. О себе ~3 года разработки (С/C++, iPhone, Android) ~1.5 года руководства командой ~1 год руководства в условиях распределенной команды

3. О чем? Субъективный опыт работы руководителем в распределенной команде Решение проблем и достижение удовлетворения от работы всех членов команды

4. Кому ? Менеджеру проекта Руководителю Фрилансеру Всем остальным ;)

5. Наша команда

6. Почему распределенная команда? Снижение затрат (хотя эффективность удаленной команды ~70%) Поиск квалифицированного персонала Территориальное присутствие в перспективном регионе

7. Риски Классика Изъяны планирования Текучесть кадров Раздувание требований Нарушение спецификаций Низкая производительность Distributed mobile team Коммуникация Изъяны планирования Низкая производительность Раздувание требований Нарушение спецификаций

8. Причины проблем в распределенной команде Недопонимание (языковой барьер, культурный барьер, плохая связь, отсутствие личного контакта) Конкуренция команд (недостаток доверия, показатели работы офисов, перекладывание ответственности, сложность точного выяснения проблемы) Сложная цепочка согласования (часовые пояса, иерархия, отсутствие планирования коммуникации)

9. Причины проблем в распределенной команде Технические (общие ресурсы, скорость передачи данных, видео-голосовая коммуникация) Неравномерность нагрузки - отсутствие визуального контакта (ждем ответа от клиента, задерки в передаче ответа, сроки выясняются на ходу) Отдаленность проблем, планов и задач каждой из команд (обиды на ПМов, тестеров, клиентов, разработчиков)

10. Решаем проблемы Позитивное настроение Доверие Инициатива Документирование Регулярные митинги Тщательное планирование задач и ресурсов

11. Делаем процесс разработки приятным Снижаем ШУМ, разговоры не по теме Сглаживаем спорные ситуации Учитываем личные предпочтения Поощряем любую инициативу Решаем мелкие раздражающие проблемы

12. Scrum vs распределенная команда Планируем спринт, не учитываем зависимостей Не согласованы спринты (или не учтены риски) Нет финальной версии требований (бекенда, дизайна) Короткие проекты – Один разработчик на проекте - Много проектов - Багфикс - Частые переключения Нежелание тестировщиков перетестировать нефинальное приложение каждый раз Изменение требований на лету Есть ответственный за результат

13. Как работаем? Здравый смысл превыше всего Что-то похожее на Lean (акцент на мотивации команды, исключении затрат) Итерации произвольной длины

14. Оцениваем эффективность Анализируем отзывы (как программиста, так и его менеджера/заказчика) Набираем статистику на разных проектах Учитываем сильные стороны и пробуем применить их на благо команде

15. Управляем мотивацией Всегда настраиваем на позитив Хвалим за результаты! Находим общие интересы Помогаем расти и добиваться целей Собственный пример Учитываем ожидания (обоих сторон)

16. Наслаждаемся!