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

Коротко о себе

• Пишу программы с 1988 года• 10+ профессиональный опыт в IT• 10+ из них team lead/PM в разных

пропорциях• Автор ряда статей по архитектуре ПО и

менеджменту http://goo.gl/pIYzP

USS Nimitz CVN-68

Он большой

4 года строительство + 3 годя отладка

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

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

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

В чем разница

• Размер (бюджет, объем в человеко-часах, …)• Требования (стабильность требований,

детализация, ожидаемая надежность, …)• Различная структура и размер команды• Разная индустрия и как следствие разная культура• …

Не забываем, что для мобильных приложений angry birds это довольно большой проект

А может ну его это менеджмент?

• На самом деле если проект небольшой и Вы готовы к рискам, то можно и без менеджмента

• Зачем менеджер нужен– Борьба с хаосом– Позаботиться о рисках– Окружающий framework

А теперь серьёзно

• Менеджмент различного толка программных проектов также может сильно отличаться

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

• Управление мобильными проектами совершенно точно имеет свою специфику. В чем она заключается?

Как правило небольшой размер

• Для web проекта 3dev*6мес это средний размер.

• Для мобильных проектов пол года - это вечность первый iPad вышел в начале 2010, iPad 2 в начале 2011.

• Специфика жанра такова, что для мобильных устройств не так много больших приложений. Основная масса приложений весьма мала. Не меньше 25% приложений в AppStore оценочно «стоят» меньше 5 ч/мес

Что это значит?

• Не времени на – «раскачивание»– «долгоиграиющие» практики в управлении

• Ошибка в одну неделю уже хорошо заметна• Небольщой бюджет не позволяет применить все-

все хорошие практики, которые Вы знаете• Надо реагировать и принимать решения быстро• Как следствие надо постоянно мониторить

состояние, чтобы был шанс вовремя среагировать

Time to market

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

• Такое бывает и не с мобильными приложениями, но в мобильном мире эта ситуация значительно чаще распространена.

• Вполне реальный случай, когда опоздание в день это «все или ничего» (успеть с апрувом до Рождества)

Если Вы опоздаете на день, Вас реально могут начать ПОДВЕРГАТЬ СУРОВОЙ КРИТИКЕ

AppStore review

• iOS & WP7 для релиза необходим процесс апрува приложения для AppStore

• Для iOS он может быть особенно не прост и болезненен

Более «подвижный» жизненный цикл

• Классический цикл– Системный анализ– Анализ требований– Проектирование– Кодирование– Тестирование– Сопровождение– Где-то здесь

подразумевается написание документации

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

прототипов начинается еще не этапе продаж

– Анализ требований и проектирование как отдельные этапы проводятся крайне редко, часть в параллель с кодированием

– После апрува в AppStore речь о сопровождении может уже и не идти.

– Документирование вообще редкость

Что делать?

• Не пытаться жестко придерживаться классической модели, не плыть против течения

• Не говорить «это безумный заказчик, он хочет начать писать код без 1-2 недельной стадии сбора требований»

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

Малая детализация и текучесть требований

• Часто приложение в голове заказчика на этапе продаж и на момент релиза могу отличаться >50%

• Часто на старте разработки все что есть, это набор картинок в экранами (а бывает, что нет и этого)

• При этом часто этих картинок на 80% достаточно.• Заказчик очень сильно look & feel ориентирован,

часто он сможет Вам сказать что он хочет только после того как подержит в руках прототип.

• Частенько бывает «я тут посмотрел в AppStore» на приложение конкурентов, надо все переделать.

Что делать

• Наладить гибкий, легкий процесс управления требований, позволящий быстро и легко все переписать и заново согласовать.

• Регулярно, не реже раза в неделю показывать приложение заказчику (если позволяет процесс то лучше даже чаще).

• Писать код так, что бы было не больно его ломать когда все поменяется

• Понимать как должно вести себя типичное приложение и понимать что значат все эти кнопочки

Молодое сообщество разработчиков

• Реально нужно где-то 5 лет чтобы сформировалось зрелое сообщество разработчиков, с 2008 прошло 3 года.

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

…

• Многие стандартные практики, это нечто из области фанатстики, например – Для iOS среды разработки continuous integration

наладить мы так и не смогли (если кто-то знает как расскажите!)

– Бывает на собеседование приходят люди у которых 4 приложения в AppStore но они не умеют работать контролем версий.

• В целом сообщество это микс из матерых волков пришедших их С++/Java и молодежи начавших жизнь непосредственно на мобилках

Как быть?

• При формировании команды надо понимать - кто откуда пришел и что умеет.

• Тщательно отслеживать совместимость членов команды.

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

Тесная связь с «физикой»

• «Берем iPad и медленно поворачиваем его экраном вниз на себя, приложение крэшится»(с) мой любимый баг

• «Если при просмотре обучающего видео поступает входящий звонок и во время его пользователь регулирует громкость, после окончания звонка не сохраняется текущая позиция»(с) заказчик

• «При быстром листании ленты новостей пальцем, лента бежит не гладко»(с) текущий проект

Что делать

• +30%-45% на стабилизацию vs +10%-20% для web проектов, в плохих случаях и +60% на стабилизацию может быть не достаточно

• Иметь check list• Договориться для каких моделей тестируется

приложение и иметь эти модели физически в наличии. Очень важно держать устройство в руках.

• Некоторые разработчики делают UI на порядок лучше и быстрее чем другие. Учитывайте это.

• Нужен хороший тестер

Много проектов на одного PM

• Проекты маленькие, целого PM для них много• Часто бывает 50% PM, или 33%, или даже 25%• Держать в голове 4 контекста сложно, все

записывайте• Не шлите письма вместо одного заказчика

другому• Если проект который Вы менеджите на 25%

времени «сопротивляется», вовремя что-то с этим делайте. Не ждите пока бабахнет, в мобильных проектах все происходит быстро.

Пошив на заказ

• Каждый заказчик «безумен» по своему• Вводить в проект все полезные практики не

хватит не времени ни бюджета• В каждом случае рецепт это sanity level + набор

средств сшитый под конкретного заказчика • Если что-то пойдет не так Вас спросят – А у вас была такая-то практика?– Нет? Ну тогда понятно почему у вас все плохо.

Summary

• В мобильных проектах нет времени и бюджета на полноценные PM практики

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

• К счастью проекты короткие и заказчики понимая что хотят странного более толерантны (в среднем)

• Также спасает тот факт что мобильные разработчики среднем весьма про активны и часть работы PM делают сами, надо только не мешать тем кто помогает и держать за руки тех, кто наоборот

Что осталось за бортом

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

проектами

Вопросы

Спасибо