Polonium Arts

Российская компания, специализирующаяся на разработке мобильных приложений и комплексных IT-решений для бизнеса. Мы создаем программные продукты, которые достигают поставленных бизнес-целей. Расска...
Страна: Россия
Город: Москва
Год основания: 2010
Количество сотрудников: 21-50
Специализация:
Количество приложений: 20
PR/Медиа:
Не по годам: сколько нужно времени, чтобы бизнес заработал
http://www.the-village.ru/village/business/case/157861-skolko-nado-vremeni-chtoby-raskachat-biznes
Polonium Arts о мобильных приложениях и зеленых ограх
http://www.computerra.ru/45758/pavel-abdurahimov-polonium-arts-o-mobilnyih-pril/
Связной запустил мобильное приложение для iOS и андроид
http://android-robot.com/svyaznoy-zapustil-mobilnoe-prilozhenie-dlya-ios-i-android/
Карту «Тройка» теперь можно пополнить через мобильное приложение «Моя Тройка»
http://corp.cnews.ru/news/line/kartu_trojka_teper_mozhno_popolnit
Показаны записи 1-12 из 20.
Образ жизни
Free
Развлечения
Free
Развлечения
Free
Фото и видео
Free
Финансы
Free
Музыка
Free
Путешествия
Free
Образ жизни
Free
Развлечения
Free
Бизнес
Free
 
 
14-09-2017, 14:13
Polonium Arts

Мобильная разработка изнутри. Невменяемые заказчики

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

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

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

Этот пост написан для двух целей:

1) чтобы отпугнуть мудаков и никогда с ними не работать;

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

Повальная некомпетентность

Люди, принимающие решение о разработке, традиционно ничего в ней не понимают. Им и не нужно — для технических, операционных и других вопросов в компании есть предназначенные для этого сотрудники. Но проблема в том, что примерно 80% этих людей тоже ничего не понимают.

Пример, за которым не нужно далеко идти: чтобы приложение взаимодействовало с системами заказчика (мы называем их “контурами”), нужно мобильное API. В 99% случаев у заказчика его нет, поэтому мы предлагаем своими силами разработать мобильное API и middle-сервер. Все, что требуется от IT-специалистов заказчика — помочь нам связаться с контурами, чтобы приложение получало необходимые данные.

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

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

Непонимание принципов мобильной разработки и нежелание напрягаться приводит к тому, что на этапе сбора требований что-то “забывается”, что-то не додумывается, что-то додумывается не так, как на самом деле нужно. Это обнаруживается в процессе разработки, когда уже согласованы план и смета. Начинаются срочные правки, переносы спринтов. Когда наступает дедлайн, человек заказчика внезапно исчезает. Также внезапно появившись, удивляется — почему сдвинуты сроки?

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

Вывод: в процессе разработки будут моменты, когда надо работать руками — это нужно четко доносить до сотрудников, которые будут ответственны за коммуникацию с компанией-разработчиком. Заказчик должен быть участником, а не наблюдателем.

Завышенные ожидания

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

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

Был один парень из провинциального городка, который заказал приложение для местной редакции. Что-то вроде приложения LifeCorr, в котором любой человек может прислать видео и получить за это вознаграждение. Парень честно оплатил разработку, получил хороший продукт и… На этом все. Со временем он перестал оплачивать поддержку, сервера отключили, продукт медленно умер. Публика так и не узнала о нем, потому что парень жил в плену завышенных ожиданий.

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

Вывод: надо быть готовым к тому, что инвестиции в приложение не ограничиваются стоимостью разработки. Платить придется всю жизнь — сначала за продвижение, за техническую поддержку и развитие, в конце концов, за сервера. Приложение не начнет грести деньги лопатой сразу же после запуска.

Суперидея

Боль, нечеловеческая боль каждого разработчика — идеи заказчика. До того, как начать писать код, мы тратим около месяца на написание технического задания. Разбираем его под микроскопом, согласовываем с заказчиком, разбиваем на спринты и получаем красивый план, отвечающий на вопрос “когда появится эта фича?”.

Все это летит в трубу примерно сразу. Каким бы ни был план и сколько бы мы его не согласовывали, однажды мы обязтельно получим письмо: “Мы с коллегами решили, что нужно сделать эту фичу. Срочно, это мастхэв”.

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

Мы вывели названия двух персонажей, которые чаще всего пишут такие письма — “это же недолго” и “мы подумали, что это логично”.

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

“Это же недолго” и “мы подумали, что это логично” способны парализовать разработку, без шуток. Они появляются в самый неподходящий момент — посреди спринта, когда команда полным ходом реализовывает согласованные задачи. “Это же недолго” и “мы подумали, что это логично” не понимают, что если в спринте заявлены три задачи, то реализовать эти три задачи и столько же суперидей не получится. Не получится, какими бы мелкими, логичными и недолгими они ни казались.

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

Вывод: разработка — это не кружок самодеятельности, где сегодня можно смастерить чайник, а завтра — бегемота. Если сегодня мы мастерим чайник, то завтра мы будем мастерить крышечку к нему, потом ручечку, потом носик, потом чашечки с блюдцами, потом починим отломавшийся носик, а уже потом, может быть, украсим композицию бегемотом. Хотя к этому времени потребность в бегемоте успеет отпасть.

Хочешь убить разработку — пригласи маркетолога

Маркетолог необходим для создания продукта — он знает аудиторию, знает товар и умеет его упаковать. Но маркетологов нельзя пускать в разработку.

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

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

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

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

Маркетологу почти невозможно объяснить, что делать все и сразу — плохая идея. Выпустить MVP с минимальными базовыми возможностями и наращивать функционал итерация за итерацией — хорошая идея, годами доказывающая свою эффективность. Выпуская маленькие обновления, можно очень быстро и незаметно для пользователей фиксить баги, сохраняя репутацию вдумчивой клиентоориентированной компании; выпуская огромный проект одним махом, нет ни одного шанса не утонуть в океане негатива от пользователей. Между масштабом обновления и количеством следующих за ним сложностей есть линейная зависимость. Но маркетолог хочет полностью упакованный продукт с салютами и фанфарами в первой версии.

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

Как надо делать, чтобы не облажаться

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


Знакомство

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


Предварительный этап

Первым делом мы пишем техническое задание. Техническое задание пишем обязательно, так как именно по нему нам предстоит отчитываться по выполненной работе. Заказчик не поленился прочитать много страниц текста, отдавая себя отчет в том, что это — и есть его будущий продукт. Конечно, если мы не работаем по agile, где на каждый спринт пишется отдельное техническое задание.
Мы переходим дальше — к прототипам.

Заказчик понимает, что скучный согласованный прототип сэкономит кучу энергии во время отрисовки дизайна, и не спорит с тем, что прототипы нужно пережить. А еще заказчик понимает, что при отрисовке дизайна прототип может измениться примерно на 20% — например, если контента окажется больше, чем предполагалось, или меньше.

Дальше мы рисуем дизайн. Сначала набрасываем концепцию, потом детализируем. Каждое действие согласовываем с заказчиком, чтобы ему все нравилось. Под “нравилось” подразумеваются глубокие, осознанные симпатии — такие, которые не приведут к редизайну через полтора месяца. Заказчик не уезжает в Арктику, не отключает телефон — он готов давать комментарии по макетам быстро (в течение 1-2 дней).

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


Разработка

Заказчик все еще на связи и не исчезает накануне сдачи задачи. А если исчезает, то не удивляется, когда разработчики оказываются переключены на другие проекты и его правки ставятся в общую очередь. Он понимает — если на текущую неделю мы согласовали разработку каталога, идеи и правки (даже самые выдающиеся) по главной странице присылать не надо.

Заказчик полностью согласен, что выпускать надо MVP и наращивать функционал постепенно — ведь он знает, что только так можно получить желаемый продукт и не утонуть в болоте негатива от пользователей.

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


 
разработка
мобильная разработка
заказчик
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться