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

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

#самизнаетекакиекнопки

Привет, я Андрей и я уже полгода занимаюсь проработкой и оптимизацией работы нашей небольшой команды мобильных разработчиков Improve Digital. Мы уже поработали с крутыми брендами вроде Infiniti и ТНК, сделали несколько сложных финансовых мобильных проектов, но до сих пор не знаем точно, как сделать процесс работы с клиентом удобным для обеих сторон. Вот об этом удобстве и неудобстве оказания услуг в мобильной разработке я и хочу рассказать.

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

«Берите, что дают или убирайтесь» — девиз целой кучи компаний в сегодняшней России. Это касается не только госсектора, где такое отношение давно уже привычно, но и частных компаний. Главное — рост прибыли, остальное волнует мало. Это парадокс, ведь довольный клиент вернется еще раз и может привести с собой друга, а недовольный не вернется и отговорит еще десяток друзей.

При этом все мы, естественно, хотим, чтобы нам было удобно. Удобно ходить по улице, удобно смотреть телевизор, удобно работать, удобно делать покупки. Однако до сих пор есть магазины и парикмахерские, работающие с 9 до 18 с выходными. Как такие заведения зарабатывают — загадка.

Иллюстрации автора

Черт побери, а ведь это именно то, чего мне так не хватало в жизни!

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

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

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

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

Несмотря на то, что мы старательно избегаем слова «аутсорс» и называем себя не иначе как «агентство», в плане подходов и процессов мы так ничего радикально и не поменяли. Основная проблема такого «аутсорсного» подхода в том, что мы снимаем с себя всякую ответственность за принятие решений. На любой возникающий в процессе разработки вопрос сразу же всплывает удобное решение: «мы спросим это у клиента». Ясное дело, не всякий клиент готов круглосуточно ждать письма с вопросами от менеджера проектов. В итоге мы затягиваем сроки, сами того не подозревая. Мы же не простаиваем, а ждем ответа от клиента. Это мы как бы работаем.

Та же самая ситуация и в нашей итеративной разработке. Мы честно пытались внедрить метод критической цепи, однако, сделали это в корне неверно. И вдобавок попытались натянуть на него итеративную разработку из Agile, не подумав о том, что клиент не всегда готов раз в неделю в строго установленный день проверять работу, а тем более оперативно давать обратную связь. В итоге повышенная нагрузка на менеджере проекта, обострение отношений с клиентом, срыв сроков. Из-за этого начали появляться простои — «ведь мы ждем решения клиента». И по всем канонам классического учета издержек мы затыкаем простои работой над другими проектами. Это приводит к срыву сроков уже не на одном, а сразу на нескольких проектах.

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

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

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

Мы пересмотрели все этапы работы над проектом, начиная от аналитики и заканчивая выгрузкой в магазин. По сути, проект с оценкой разработки около 300-400 часов длился в среднем 3-4 месяца. При этом на проекте в каждый момент времени было задействовано минимум два программиста и менеджер. Такой подход никуда не годился и, по-моему, только практически полное отсутствие на рынке компаний, работающих по-другому, вынуждало клиентов продолжать работать по такой схеме.

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

Можно представить разработку мобильного приложения продукта через аналогию с заводом. Есть технологический процесс, последовательность операций, а станки — это отделы (аналитика, дизайн, проектирование, разработка, тестирование). Сырье же — это деньги, по сути, мы «перерабатываем» деньги в готовое приложение. Таким образом, если на заводе запас сырья перед станком — это его связанный капитал, то у нас это реальный капитал, деньги клиента. И чем дольше эти деньги находятся у нас, чем дольше нет готового продукта, тем выше убытки клиента. Это простая экономика, ничего нового. Но это именно то, что делает клиента несчастным при разговоре о сроках.

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

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

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

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

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

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