Разработка «с нуля» может возникнуть в любой компании. В докладе расскажу:
-
Об особенностях таких проектов разработки приложений.
-
О том, как для них снизить риски, потому что рисков очень много. Очень много неизвестных, и ожидания у всех разные – не всегда на выходе получается то, как видел заказчик.
-
Поговорим про бизнес-моделирование и прототипирование.
-
А также про инструменты для этого всего.
Итак, поехали.
Особенности проектов разработки приложений. Заказная vs Тиражная
Классический проект внедрения подразумевает, что мы берем за основу ERP, УТ, Бухгалтерию или ЗУП, моделируем на ней будущий продукт и показываем заказчику. Он сразу видит, как будет работать решение, может прокликать его формы, оценить возможности и так далее.
Но когда разработка с нуля, ничего этого нет – моделировать нечего. В этом случае большинство разработчиков просто записывают со слов заказчика сухие требования, термины, определения, идеи. И здесь возникают риски, поскольку в разговоре об одном и том же все подразумевают разное.
-
Cложно оценить стоимость такого проекта – для интегратора и для инсорса – неважно. Для инсорса непонятно, за какое время это можно сделать – за неделю, за месяц, за два, за полгода. И для интегратора – то же самое, оценка стоимости проекта усложняется на порядок.
-
Нет примеров и нет опыта. Даже если есть похожий опыт, он вряд ли может помочь при разработке с нуля под конкретную уникальную бизнес-задачу.
-
Когда появляется первый прототип MVP, в конце начинается много хотелок: «А сделайте нам здесь бантик», «А передвиньте кнопку сюда» и так далее. Это все тоже увеличивает стоимость разработки и время доведения вашего продукта до потребителя, до рынка.
-
Кроме этого, возникает высокая зависимость от «вИдения прекрасного» конкретного исполнителя. Хорошо, если ваш программист имеет опыт разработки качественных продуктов. И было бы прекрасно, если бы они были выложены на Инфостарте – если их кто-то купил, значит они рабочие и привлекательные. Если это не так, возникают проблемы со скоростью внедрения, и стоимость продукта от всего этого растет.
Недавно у нас стояла задача разработать мобильное приложение с условным названием «Подработка возле дома».
Это мобильное приложение можно скачать себе на смартфон, зарегистрироваться, подгрузить паспорт, пройти верификацию службы безопасности, а дальше зайти в календарь и увидеть, в какое время можно выйти подработать в соседнее предприятие.
Заказчиком было конкретное предприятие, находящееся в сельской местности. У него периодически возникали простейшие сезонные работы, для которых не требовались специальные навыки. Сезонные работники нанимались через сторонние компании, но заказчик решил уйти от этой прослойки и напрямую выйти на исполнителей. Абсолютно уникальная задача, по сути, B2C-проект.
Работа пользователя с продуктом подразумевала следующие стадии:
-
Скачать приложение,
-
Подгрузить документы – СНИЛС, паспорт и реквизиты банковской карты.
-
Подписать договор-оферту и согласиться на обработку персональных данных.
-
Записаться в удобный для работы день.
-
Когда нужно, выйти на работу в добром здравии и уме.
-
Прекрасно отработать и получить деньги на карту.
Итого – нам поставили задачу разработать приложение на Android и разместить его на RuStore, при этом в срок 3 мес. от проектирования до запуска рабочей версии.
Казалось бы, все просто. Но что ответить генеральному директору, который рассказывает нам свою идею и спрашивает: «Сколько это будет стоить? Сможете за два дня оценить? Мне нужен договор на фиксе. Я не хочу ваши Time & Materials, я это вообще не понимаю».
Готовы ли вы ответить на вопрос – сколько вешать в граммах?
Если вы загуглите в Яндексе «Как разработать мобильное приложение», вы увидите, что при разработке нативных мобильных приложений на Android или iOS применяется примерно такой перечень этапов:
-
Изучение.
-
Документирование.
-
Прототип.
-
Дизайн.
-
Разработка.
-
Тестирование.
-
Запуск.
-
Поддержка.
Причем обратите внимание, что третий и четвертый блоки, к сожалению, пока в среде разработки на платформе 1С отсутствуют. Именно про них я сейчас и расскажу.
Как снизить риски с минимальными затратами
С чего начать, чтобы снизить риски? Как я говорил, мы находимся в кабинете генерального директора, и он хочет услышать цену. Мы не хотим перезакладываться, но и не хотим потерять. Какие варианты?
-
Первый, казалось бы, простой вариант – разбить на этапы. Мы разработаем ТЗ, вы за это заплатите, а если вам ТЗ не понравится – ну, извините.
-
Второй вариант – подписать договор с почасовой оплатой по принципу Time and materials. Будем программировать, пока все не запрограммируем.
-
Третий вариант – жестко обозначим границы, зафиксируем их в ТЗ. Но есть нюанс – элементарно на встречу придет директор юрслужбы и скажет: «Нам нужно будет еще персональные данные передавать – для этого галочка нужна. А еще нужна возможность договор согласовать…» Они же у себя внутри много чего не видят, начинают дискутировать, и мы сразу ощущаем высокие риски.
-
И четвертый вариант – можно просто заложить все риски в стоимость проекта и переложить их, по сути, на заказчика.
Во всех этих вариантах риски оказываются максимально смещены на заказчика (или переплатит; или получит не в срок; или получит, но недостаточную функциональность, минимально необходимую для эксплуатации решения; или и то и другое сразу), а это для сотрудничества крайне неэффективно и неправильно.
Вместо этого мы проводим этап некого пресейла. Даже если вы инсорс, это тоже, в общем-то, пресейл, потому что пользователи вашего предприятия – это ваши заказчики.
-
Мы тут же на рабочую встречу с генеральным директором зовем основных заинтересованных лиц и прописываем крупными мазками для них некую карту – Customer Journey Map: «Я, как пользователь, хочу зайти в мобильное приложение, нажать кнопку регистрации, открыть договор-оферту, подписать его…» Все это прописываем.
-
Дальше мы садимся на некий брейншторм и рисуем прототип. Некоторые это делают на листке бумаги, на доске. В чем мы делаем – я чуть позже расскажу. Это занимает четыре-шесть часов, не больше. Мы можем себе это позволить на этапе пресейла. Тем более, если заказчик – наш давний хороший партнер, и мы с ним работаем абсолютно честно и прозрачно. Мы рисуем прототип и показываем ему в технико-коммерческом предложении. Естественно, финальный результат будет отличаться от прототипа на 5-10%, но он не будет отличаться кардинально. По сути, мы на этом этапе сразу же отрисовываем основные формы мобильного приложения, решаем, какой будет цвет у кнопок, какие там будут формулировки; какая терминология будет использоваться. Может быть, юристам важно, чтобы было не «Согласовано», а «Я соглашаюсь с договором-офертой». Этот этап занимает буквально пару дней, но экономит месяцы.
-
И на основе полученного материала готовим ТКП с твердой ценой, потому что мы уже на 90% зафиксировали объем разработки: знаем количество форм, продумали функциональность, решили, каким будет бэкофис – центральная система, которая будет это все агрегировать, отрисовали для нее основные формы. Риски сводятся к границам 3-5%.
По сути, мы выстраиваем свою работу точно так же, как давным-давно работают все компании, которые разрабатывают дорогие нативные мобильные приложения.
Кто-нибудь пробовал заказывать нативное приложение для iOS? Там без ТЗ ни вправо, ни влево не шагнуть, зато этап прототипа и дизайна – обязателен.
А в 1С вопрос дизайна – это отдельный вопрос. У нас самый главный дизайнер, как я люблю шутить – это Борис Георгиевич Нуралиев. Точнее, его брат, который занимается развитием платформы. Платформа за нас все отрисовывает – цвета, расположение и так далее. Но некоторые заказывают и дизайнеров. Даже на конференциях Инфостарта потом рассказывают, как сделать свой индивидуальный дизайн.
В первую очередь дизайн важен в B2C. В B2B дизайн менее важен – в B2B важна стабильность, отказоустойчивость и так далее.
Возвращаемся к практике. На слайде – укрупненная, всем понятная «Карта этапов пути пользователя», приложенная к ТКП.
За дизайн не пинайте – мы эту карту делали для заказчика бесплатно и на коленке.
Теперь отрисовываем внешний вид будущего мобильного приложения. Опять-таки на слайде реальный прототип.
-
Первый слайд – это приветственный экран. Либо у пользователя уже есть логин, пароль, либо ему нужно зарегистрироваться.
-
Второй экран – пользователь регистрируется. Вводит ФИО, подпись (перещелкивает переключатель «Я согласен на обработку персональных данных»), читает текст, который согласован с юристами.
-
Третий экран – для загрузки сканов\фото.
-
Четвертый экран – основная форма приложения, где пользователь может: посмотреть соглашения, которые он подписал; записаться на работу в сад; увидеть акты выполненных работ и прочитать часто задаваемые вопросы. Ниже – контакты техподдержки и так далее.
Все. Трудозатраты на подобное ТКП – 8-12 часов вместе с интервьюированием и доработкой (отрисовкой) деталей. Но мы достигли желаемого – заказчик получил твердую цену и сроки, а мы снизили свои риски за счет того, что утвердили будущие формы.
В чем красота и прелесть визуальной картинки? С визуальной картинкой, которую даже и покликать можно, вряд ли кто-то будет спорить, а когда ТЗ только в виде текста, с вами будут спорить до победного, аргументируя: «Я это видел по-другому». «Это же очевидно (вот читайте между строк ? ), почему вы это не предусмотрели?» и т.д.
Наличие прототипа дает большой плюс, когда заказчик начинает внедрять, потому что, когда он видит, что пропустил, и в прототипе не было какой-то функции, у него уже не возникает вопросов, почему это следующий этап, следующий проект, а не включен в текущий. Мы ему сделали MVP – минимальный работающий продукт, который достиг минимально-рабочего результата за фиксированную цену. А дальше – развитие приложения в рамках следующего этапа за отдельную плату.
Бизнес-моделирование и прототипирование. Свести уровень неопределенности к минимуму
Когда вы рисуете прототип и согласовываете его с заказчиком, чтобы он на ранних стадиях мог внести какие-то визуальные правки – вы, по сути, влияете на три вещи (ВВП): Внедрение, Владение и Продвижение.
-
При внедрении – особенно на финальном этапе – вы сокращаете цикл повторов, если что-то не учли. Вы можете сразу поправить вправо-влево кнопку, поменять зеленое на синее, уточнить термины, дописать подсказки, сортировки, и т.д. Самое главное, вы сразу вовлекаете заказчика. Если человек сам согласовал этот визуальный концепт, ему потом сложно сказать: «Я с этим не согласен». У него уже есть некая ответственность. Вы его «садите в лодку», он уже не может сказать: «А я не программист». Вы говорите: «Не надо программировать. Возьми листочек бумаги и нарисуй». Попросите его на бумаге это сделать.
-
Во владении – важно, что вы отрисовали и сделали то, что заказчик хотел, как он это видел. Он с этим согласился, внес свои правки. Дальше у вас меньше тикетов летит на helpdesk, меньше ошибок. Обучение происходит «на ура» и так далее.
-
Продвижение тоже выигрывает. Если продукт тиражный – продвижение очень важно. А здесь вы поработали над юзабилити, над терминами. Ваш продукт, особенно если он тиражный, лучше воспримут в отрасли или в той нише, для которой он создан.
И основной вывод, который я хотел бы донести – не нужно кодить с нуля или строить большие системы, если нет прототипа в принципе. Лучше заранее все проговорите и отрисуйте.
В противном случае у вас в конце будет 85% актов подписано, договор уже на финальной стадии, а вы будете два месяца бороться с возражениями: «Это же очевидно было», «Мне важно, чтобы кнопка была справа», «Здесь должна быть справочка» и т.д.
Инструменты для первых этапов разработки, снижающие себестоимость сдачи проекта
Расскажу, какие инструменты дизайна и создания макетов на сегодняшний день есть у product owner-ов, бизнес-аналитиков, менеджеров по продажам и руководителей проектов:
-
Возьмите хотя бы банально Paint или Excel. В Excel прекрасно прототипируются будущий внешний вид и структура отчетов – это лучший инструмент для прототипирования отчетов.
-
Figma и Axure как вариант. Figma – это универсальный SaaS-сервис, который позволяет создать дизайн-макет любого приложения. С его помощью вы можете дизайнить сайты, нативные приложения и даже решения на 1С. Но учтите, что сейчас Figma доступна не во всех точках мира.
-
Некоторые успешно пользуются конфигуратором или EDT, даже есть какие-то обработки для прототипирования в режиме 1С:Предприятие.
-
В крайнем случае используйте ручку и бумагу.
-
А для нашего сообщества 1С мы сделали продукт MAKER. Это очень простой инструмент – там не надо ничего программировать, вы используете готовые элементы: 1С-овские кнопки «Провести и закрыть» или «Записать», табличные части, вкладочки. Вы просто перетаскиваете их на будущую программу и рисуете, что вам надо. Более того, ссылочку расшариваете, отправляете заказчику, он открывает в браузере и видит, что вы делаете. Вы можете менять у себя, а он без обновления страницы будет это все видеть. Можно прототипировать десктоп, мобильные формы, и скоро мы выпустим возможность делать там документацию и рисовать диаграммы BPMN. Также с недавнего времени можно спроектированные формы выгрузить в виде готового ТЗ с описанием форм и элементов. Пример такого ТЗ можно посмотреть во вложении к публикации.
Чем раньше вы этим начнете заниматься, тем быстрее вы доведете ваш продукт до потребителя, быстрее его внедрите, быстрее получите обратную связь без кодинга – по принципу Time to Market.
Себестоимость снижается, а дальше у вас либо выручка растет, либо вы просто экономите деньги предприятия и тратите их на что-то еще.
Резюмируем.
-
Проекты с разработкой с нуля характеризуются высоким уровнем неопределенности. Нет типового решения, нет какой-то базы для моделирования, и даже на Инфостарте нет наработок, которые можно взять за основу. Если эти критерии подходят под ваш проект или то, что вы делаете – мой доклад для вас.
-
Можно и нужно совмещать методики минимизации рисков. Поэтому разбивайте на этапы и делайте разумные ограничения. Для этого мобильного приложения сначала мы сделали первую версию, а дальше через месяц вышла вторая. Во второй версии мы реализовали повторное подписание актов и другие вещи, которые абсолютно никто не мог предусмотреть. Заказчик получил результат уже через месяц-полтора.
-
Третий шаг и третья важная вещь – пишите Customer Journey Map. Описывайте, кто что будет делать, какая его главная цель на том или ином этапе использования вашего приложения. Обязательно рисуйте прототипы – в чем угодно, как вам видится.
-
Чем раньше вы будете это делать, тем меньше рисков вы поймаете.
Вопросы
На чем сделан MAKER, что у него под капотом?
Node.js и Java. Это облачный сервис, работает полностью в браузере. Под капотом – не конфигуратор 1C, а открытые фреймворки. СУБД тоже облачная.
Есть ли какая-то граница трудозатрат, которые стоит тратить на предварительный макет?
Мы для себя определили 24 часа максимум, в зависимости от масштабов проекта. И в зависимости от того, знаем мы этого заказчика или нет. Почти всем на входе даем 8 часов. А если мы заказчика знаем и давно с ним работаем – там уже договорная вещь.
Так или иначе, мы для себя видим в этом большой плюс. У нас даже менеджеры по продажам начинают отрисовывать, потому что в этом нет ничего сложного. Продажник общается с представителем заказчика, тот ему говорит: «А давай тут пододвинем». И дальше они идут к ЛПРу, все это обсуждают и решают.
А кто участвует в этом брейнсторме? Какие роли – программисты, архитекторы?
Три человека: РП, бизнес-аналитик и программист. Либо архитектор – в зависимости от масштаба проекта. В основном архитектор.
P.S. Вы можете получить бесплатный базовый курс по использованию сервиса MAKER при создании форм и технических заданий для программ на базе 1С, а также применения его в качестве инструмента управления проектами и задачами.
***************
Статья написана по итогам доклада, прочитанного на конференции Анализ & Управление в ИТ-проектах.
