http://mmeetup.ru

1. Особенности менеджмента
мобильных проектов

2. Коротко о себе
• Пишу программы с 1988 года
• 10+ профессиональный опыт в IT
• 10+ из них team lead/PM в разных
пропорциях
• Автор ряда статей по архитектуре ПО и
менеджменту http://goo.gl/pIYzP

3. USS Nimitz CVN-68

4. Он большой
4 года строительство
+ 3 годя отладка

5. Он все еще плавает и не скрэшился
от багов!!!

6. Что у них общего?

7. В обоих случаях требуется
менеджмент

8. В чем разница
• Размер (бюджет, объем в человеко-часах, …)
• Требования (стабильность требований,
детализация, ожидаемая надежность, …)
• Различная структура и размер команды
• Разная индустрия и как следствие разная
культура
• …
Не забываем, что для мобильных приложений
angry birds это довольно большой проект

9. А может ну его это
менеджмент?
• На самом деле если проект небольшой и Вы
готовы к рискам, то можно и без
менеджмента
• Зачем менеджер нужен
– Борьба с хаосом
– Позаботиться о рисках
– Окружающий framework

10. А теперь серьёзно
• Менеджмент различного толка
программных проектов также может сильно
отличаться
• Мир мобильной разработки фактически
перезапустился в 2008 году. Выход первого
iPhone существенно изменил ландшафт.
• Управление мобильными проектами
совершенно точно имеет свою специфику. В
чем она заключается?

11. Как правило
небольшой размер
• Для web проекта 3dev*6мес это средний
размер.
• Для мобильных проектов пол года - это
вечность первый iPad вышел в начале 2010,
iPad 2 в начале 2011.
• Специфика жанра такова, что для мобильных
устройств не так много больших приложений.
Основная масса приложений весьма мала. Не
меньше 25% приложений в AppStore оценочно
«стоят» меньше 5 ч/мес

12. Что это значит?
• Не времени на
– «раскачивание»
– «долгоиграиющие» практики в управлении
• Ошибка в одну неделю уже хорошо заметна
• Небольщой бюджет не позволяет применить все-
все хорошие практики, которые Вы знаете
• Надо реагировать и принимать решения быстро
• Как следствие надо постоянно мониторить
состояние, чтобы был шанс вовремя среагировать

13. Time to market
• В силу молодости рынка очень часто бывает
что заказчик торопится захватить нишу.
• Такое бывает и не с мобильными
приложениями, но в мобильном мире эта
ситуация значительно чаще распространена.
• Вполне реальный случай, когда опоздание в
день это «все или ничего» (успеть с апрувом
до Рождества)
Если Вы опоздаете на день, Вас реально могут
начать ПОДВЕРГАТЬ СУРОВОЙ КРИТИКЕ

14. AppStore review
• iOS & WP7 для релиза необходим процесс
апрува приложения для AppStore
• Для iOS он может быть особенно не прост и
болезненен

15. Более «подвижный»
жизненный цикл
• Классический цикл • Мобильные приложения
– Системный анализ – Часто кодирование
прототипов начинается
– Анализ требований еще не этапе продаж
– Проектирование – Анализ требований и
проектирование как
– Кодирование отдельные этапы
– Тестирование проводятся крайне
редко, часть в параллель
– Сопровождение с кодированием
– Где-то здесь – После апрува в AppStore
подразумевается речь о сопровождении
написание может уже и не идти.
документации – Документирование
вообще редкость

16. Что делать?
• Не пытаться жестко придерживаться
классической модели, не плыть против течения
• Не говорить «это безумный заказчик, он хочет
начать писать код без 1-2 недельной стадии
сбора требований»
• С другой стороны надо понимать, что
классически цикл придуман не просто так и
если вы начали кодировать раньше, чем
подписали договор, это не значит что вы умнее
всех, а у Вас реально есть ряд рисков о которых
нельзы забывать.

17. Малая детализация и
текучесть требований
• Часто приложение в голове заказчика на этапе
продаж и на момент релиза могу отличаться >50%
• Часто на старте разработки все что есть, это набор
картинок в экранами (а бывает, что нет и этого)
• При этом часто этих картинок на 80% достаточно.
• Заказчик очень сильно look & feel ориентирован,
часто он сможет Вам сказать что он хочет только
после того как подержит в руках прототип.
• Частенько бывает «я тут посмотрел в AppStore» на
приложение конкурентов, надо все переделать.

18. Что делать
• Наладить гибкий, легкий процесс управления
требований, позволящий быстро и легко все
переписать и заново согласовать.
• Регулярно, не реже раза в неделю показывать
приложение заказчику (если позволяет
процесс то лучше даже чаще).
• Писать код так, что бы было не больно его
ломать когда все поменяется
• Понимать как должно вести себя типичное
приложение и понимать что значат все эти
кнопочки

19. Молодое сообщество
разработчиков
• Реально нужно где-то 5 лет чтобы
сформировалось зрелое сообщество
разработчиков, с 2008 прошло 3 года.
• Мобильные технологии очень
привлекательны, сообщество
разработчиков подвержено эффекту
«золотой лихорадки», все, буквально все,
бросились писать приложения для
мобилок. Это и хорошо и плохо.

20. …
• Многие стандартные практики, это нечто из
области фанатстики, например
– Для iOS среды разработки continuous integration
наладить мы так и не смогли (если кто-то знает как
расскажите!)
– Бывает на собеседование приходят люди у которых
4 приложения в AppStore но они не умеют работать
контролем версий.
• В целом сообщество это микс из матерых
волков пришедших их С++/Java и молодежи
начавших жизнь непосредственно на мобилках

21. Как быть?
• При формировании команды надо
понимать - кто откуда пришел и что умеет.
• Тщательно отслеживать совместимость
членов команды.
• 20+ опыт разработки не всегда значит, что
человек лучше всех знает, что делать,
бывает, что молодежь начавшая
профессиональную карьеру с мобильной
платформы четче понимает как надо.

22. Тесная связь с
«физикой»
• «Берем iPad и медленно поворачиваем его
экраном вниз на себя, приложение
крэшится»(с) мой любимый баг
• «Если при просмотре обучающего видео
поступает входящий звонок и во время его
пользователь регулирует громкость, после
окончания звонка не сохраняется текущая
позиция»(с) заказчик
• «При быстром листании ленты новостей
пальцем, лента бежит не гладко»(с) текущий
проект

23. Что делать
• +30%-45% на стабилизацию vs +10%-20% для
web проектов, в плохих случаях и +60% на
стабилизацию может быть не достаточно
• Иметь check list
• Договориться для каких моделей тестируется
приложение и иметь эти модели физически в
наличии. Очень важно держать устройство в
руках.
• Некоторые разработчики делают UI на порядок
лучше и быстрее чем другие. Учитывайте это.
• Нужен хороший тестер

24. Много проектов на
одного PM
• Проекты маленькие, целого PM для них много
• Часто бывает 50% PM, или 33%, или даже 25%
• Держать в голове 4 контекста сложно, все
записывайте
• Не шлите письма вместо одного заказчика
другому
• Если проект который Вы менеджите на 25%
времени «сопротивляется», вовремя что-то с
этим делайте. Не ждите пока бабахнет, в
мобильных проектах все происходит быстро.

25. Пошив на заказ
• Каждый заказчик «безумен» по своему
• Вводить в проект все полезные практики не
хватит не времени ни бюджета
• В каждом случае рецепт это sanity level + набор
средств сшитый под конкретного заказчика
• Если что-то пойдет не так Вас спросят
– А у вас была такая-то практика?
– Нет? Ну тогда понятно почему у вас все плохо.

26. Summary
• В мобильных проектах нет времени и бюджета на
полноценные PM практики
• В среднем проекты более рискованны и требуют
больше внимания и более плотных проектных
практик
• К счастью проекты короткие и заказчики понимая
что хотят странного более толерантны (в среднем)
• Также спасает тот факт что мобильные разработчики
среднем весьма про активны и часть работы PM
делают сами, надо только не мешать тем кто
помогает и держать за руки тех, кто наоборот 

27. Что осталось за
бортом
• Управление требования
• Организация тестирования
• Конфигурирование команды
• Что такое Sanity level в упралении
проектами

28. Вопросы

29. Спасибо