Концепция, Продукт И Оценка: Как Оптимизировать Процесс Разработки Мобильных Приложений

Технический руководитель мобильного digital-агентства Улучшение цифровых технологий Андрей Чевозеров написал колонку для CPU о преимуществах и недостатках налаженного процесса предоставления услуг мобильной разработки, в которой оценил свой и чужой опыт и обсудил, как можно оптимизировать этот процесс.



Концепция, Продукт И Оценка: Как Оптимизировать Процесс Разработки Мобильных Приложений

Здравствуйте, меня зовут Андрей, и я уже полгода работаю и оптимизирую работу нашей небольшой команды мобильных разработчиков Improve Digital.

Мы уже работали с такими крутыми брендами, как Infiniti и ТНК, и выполнили несколько сложных финансовых мобильных проектов, но до сих пор не знаем, как именно сделать процесс работы с клиентом удобным для обеих сторон.

Именно об этом удобстве и неудобстве предоставления услуг по мобильной разработке я и хочу поговорить.



Главное рост прибыли, остальное мало волнует

«Бери, что дают, или оставь» — девиз целого ряда компаний в сегодняшней России.

Это касается не только госсектора, где такое отношение уже давно принято, но и частных компаний.

Главное – рост прибыли; остальное мало волнует. Это парадокс, ведь довольный клиент вернется снова и может привести с собой друга, а недовольный не вернется и отговорит еще десяток друзей.

В то же время мы все, естественно, хотим чувствовать себя комфортно.

Удобно гулять по улице, удобно смотреть телевизор, удобно работать, удобно делать покупки.

Однако магазины и парикмахерские по-прежнему работают с 9 до 18 без выходных.

Как такие заведения зарабатывают деньги – загадка.



Концепция, Продукт И Оценка: Как Оптимизировать Процесс Разработки Мобильных Приложений

Авторские иллюстрации



Черт возьми, это именно то, что мне нужно в жизни!

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

Продукт для нас не менее важен, чем клиент, для которого мы его создаем.

Если нам это не интересно, мы не будем этого делать.

Если идея кажется нам безумной, мы прямо говорим об этом клиенту.

Я не хочу создавать дерьмовое приложение, не интересное пользователям.

И это не потому, что мы ленимся или пытаемся оградить заказчика от необдуманных вложений.

Это сделано для того, чтобы не допустить появления на рынке очередного бесполезного товара, которым завалены все магазины.

Теперь мы знаем наверняка, нам бы хотелось, чтобы каждый, кто установит наше приложение на свой смартфон, сказал: «Блин, это именно то, чего мне не хватало в жизни!»



Мы спросим об этом у клиента

Но все началось, конечно, не так.

Сначала мы предложили клиенту семь последовательных этапов разработки, включая аналитику и дизайн.

А это явно не то, что нужно и ему, и пользователям.

Остановлюсь подробнее на том, почему вся наша система дала сбой и не приносит вау-результатов.

Несмотря на то, что мы старательно избегаем слова «аутсорсинг» и называем себя не иначе как «агентством», с точки зрения подходов и процессов мы ничего радикально не изменили.

Основная проблема такого «аутсорсингового» подхода заключается в том, что мы снимаем с себя всю ответственность за принятие решений.

На любой вопрос, возникающий в процессе разработки, сразу всплывает удобное решение: «зададим клиенту».

Понятно, что не каждый клиент готов круглосуточно ждать письма с вопросами от руководителя проекта.

В результате мы затягиваем сроки, даже не подозревая об этом.

Мы не стоим сложа руки, а ждем ответа от клиента.

Вот как мы работаем.

Та же ситуация применима и к нашей итеративной разработке.

Мы честно пытались реализовать метод критической цепочки, однако сделали это совершенно неправильно.

А кроме того, ему пытались навязать итеративную разработку из Agile, не задумываясь о том, что клиент не всегда готов проверять работу раз в неделю в строго установленный день, а тем более оперативно давать обратную связь.

Как следствие, повышенная нагрузка на руководителя проекта, обострение отношений с клиентом, срыв сроков.

Из-за этого стали появляться простои — «ведь мы ждем решения клиента».

И по всем канонам классического учета затрат мы компенсируем простой, работая над другими проектами.

Это приводит к срыву сроков не по одному, а сразу по нескольким проектам.

Идея проста до безобразия: невозможно добиться результатов топовых агентств, если работать как обычная шарашка на аутсорсе.





Простая экономика, ничего нового.

И теперь я вам расскажу, что мы планировали со всем этим делать.

Мы рассмотрели все этапы проекта: от аналитики до загрузки в магазин.

Фактически проект с оценкой разработки около 300-400 часов длился в среднем 3-4 месяца.

При этом в проекте в любой момент времени были задействованы как минимум два программиста и менеджер.

Такой подход был никуда не годен и, на мой взгляд, только практически полное отсутствие на рынке компаний, которые работали по-другому, заставило клиентов продолжать работать по этой схеме.

На самом деле, как оказалось, нет смысла выполнять операции последовательно.

Более того, даже на верхнем уровне работу можно смело распараллеливать.

Например, никто не мешает вам приступить к разработке UX сразу после быстрого анализа рынка, когда станет понятен ключевой функционал и целевая аудитория.

А поскольку наша команда настолько модернизировала UX-разработку, что черновик занимает в среднем 4-6 часов, можно сразу приступать к проектированию.

Разработку мобильного приложения для продукта можно представить на примере завода.

Есть технологический процесс, последовательность операций, а машины – это отделы (аналитики, проектирования, инжиниринга, разработки, тестирования).

Сырьем являются деньги; по сути, мы «перерабатываем» деньги в готовое приложение.

Таким образом, если на заводе запас сырья перед машиной есть ее связанный капитал, то у нас это действительный капитал, деньги клиента.

И чем дольше эти деньги у нас, чем дольше нет готового продукта, тем выше потери клиента.

Это простая экономика, ничего нового.

Но именно это и вызывает недовольство клиента, когда речь идет о сроках.

На практике клиент довольно часто готов заплатить немного больше, но никогда не желает отодвинуть выпуск еще немного назад. Если кто-то охотно соглашается перенести дату релиза, присмотритесь к этому человеку: возможно, у него вообще нет денег, и при таком подходе он никогда не будет.



Концепция, продукт и оценка

Итак, наши бизнес-процессы были атакованы в первую очередь.

Семь последовательных шагов переродились в два этапа: «Концепция» и «Продукт».

Этап «Концепция» объединяет не только аналитику и разработку стратегической концепции, но и новую UX-схему, стиль и цветовую схему, эскизы дизайна, архитектуру верхнего уровня всей системы и эскизы архитектур каждой ее части.



В совокупности с действительно полезным поиском места мобильного приложения в бизнес-модели клиента и эффективной презентацией результатов это должно дать вау-эффект.

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

Сейчас мы еще дорабатываем «Концепцию», но уже опробовали некоторые идеи на проектах и получили очень хорошие результаты.

Этап «Продукт» касается в первую очередь технической стороны разработки.

Его ключевой особенностью станет полная реализация критической цепи.

Еще один важный момент, который необходимо проработать и реализовать, – это подход к оцениванию.

Ограничение часов полностью убивает креативность и мотивирует разработчиков задавать вопросы, а не предлагать варианты.

Единственное преимущество рейтинга в часах — его легче продать; Умножьте часы на тариф и получите сумму.

Есть гораздо более продвинутые способы расчета стоимости проекта; это тема для отдельного материала.

Теперь мы знаем, что больше не будем оценивать проекты часами.

Клиент платит за сроки и качество, а не за часы.





Общий

Этот год объявлен годом бесконечных улучшений.

Мы многому научимся, наступим на десятки ошибок.

Тогда мы обязательно расскажем вам, что произошло.

Вместе с данным постом часто просматривают: