Что делать, если моделировать нечего, разработка с "0"

17.04.24

Программная инженерия - Работа с требованиями

Расскажем о том, как снизить риски при разработке мобильных приложений, новых конфигураций или целых подсистем «с нуля». Материал будет актуальным и для компаний-интеграторов, и для сотрудников внутренних ИТ-отделов в производственных или торговых компаниях.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?]
Сгенерированный с помощью MAKER пример ТЗ с описанием форм
.pdf 828,39Kb
16
16 Скачать бесплатно

Разработка «с нуля» может возникнуть в любой компании. В докладе расскажу:

  • Об особенностях таких проектов разработки приложений.

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

  • Поговорим про бизнес-моделирование и прототипирование.

  • А также про инструменты для этого всего.

Итак, поехали.

 

Особенности проектов разработки приложений. Заказная vs Тиражная

 

 

Классический проект внедрения подразумевает, что мы берем за основу ERP, УТ, Бухгалтерию или ЗУП, моделируем на ней будущий продукт и показываем заказчику. Он сразу видит, как будет работать решение, может прокликать его формы, оценить возможности и так далее.

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

  • Cложно оценить стоимость такого проекта – для интегратора и для инсорса – неважно. Для инсорса непонятно, за какое время это можно сделать – за неделю, за месяц, за два, за полгода. И для интегратора – то же самое, оценка стоимости проекта усложняется на порядок.

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

  • Когда появляется первый прототип MVP, в конце начинается много хотелок: «А сделайте нам здесь бантик», «А передвиньте кнопку сюда» и так далее. Это все тоже увеличивает стоимость разработки и время доведения вашего продукта до потребителя, до рынка.

  • Кроме этого, возникает высокая зависимость от «вИдения прекрасного» конкретного исполнителя. Хорошо, если ваш программист имеет опыт разработки качественных продуктов. И было бы прекрасно, если бы они были выложены на Инфостарте – если их кто-то купил, значит они рабочие и привлекательные. Если это не так, возникают проблемы со скоростью внедрения, и стоимость продукта от всего этого растет.

 

 

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

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

Заказчиком было конкретное предприятие, находящееся в сельской местности. У него периодически возникали простейшие сезонные работы, для которых не требовались специальные навыки. Сезонные работники нанимались через сторонние компании, но заказчик решил уйти от этой прослойки и напрямую выйти на исполнителей. Абсолютно уникальная задача, по сути, B2C-проект.

Работа пользователя с продуктом подразумевала следующие стадии:

  • Скачать приложение,

  • Подгрузить документы – СНИЛС, паспорт и реквизиты банковской карты.

  • Подписать договор-оферту и согласиться на обработку персональных данных.

  • Записаться в удобный для работы день.

  • Когда нужно, выйти на работу в добром здравии и уме.

  • Прекрасно отработать и получить деньги на карту.

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

Казалось бы, все просто. Но что ответить генеральному директору, который рассказывает нам свою идею и спрашивает: «Сколько это будет стоить? Сможете за два дня оценить? Мне нужен договор на фиксе. Я не хочу ваши Time & Materials, я это вообще не понимаю».

Готовы ли вы ответить на вопрос – сколько вешать в граммах?

 

 

Если вы загуглите в Яндексе «Как разработать мобильное приложение», вы увидите, что при разработке нативных мобильных приложений на Android или iOS применяется примерно такой перечень этапов:

  1. Изучение.

  2. Документирование.

  3. Прототип.

  4. Дизайн.

  5. Разработка.

  6. Тестирование.

  7. Запуск.

  8. Поддержка.

Причем обратите внимание, что третий и четвертый блоки, к сожалению, пока в среде разработки на платформе 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.

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

Подробнее о сервисе MAKER

 

 

Резюмируем.

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

  • Можно и нужно совмещать методики минимизации рисков. Поэтому разбивайте на этапы и делайте разумные ограничения. Для этого мобильного приложения сначала мы сделали первую версию, а дальше через месяц вышла вторая. Во второй версии мы реализовали повторное подписание актов и другие вещи, которые абсолютно никто не мог предусмотреть. Заказчик получил результат уже через месяц-полтора.

  • Третий шаг и третья важная вещь – пишите Customer Journey Map. Описывайте, кто что будет делать, какая его главная цель на том или ином этапе использования вашего приложения. Обязательно рисуйте прототипы – в чем угодно, как вам видится.

  • Чем раньше вы будете это делать, тем меньше рисков вы поймаете.

 

Вопросы

 

На чем сделан MAKER, что у него под капотом?

Node.js и Java. Это облачный сервис, работает полностью в браузере. Под капотом – не конфигуратор 1C, а открытые фреймворки. СУБД тоже облачная.

Есть ли какая-то граница трудозатрат, которые стоит тратить на предварительный макет?

Мы для себя определили 24 часа максимум, в зависимости от масштабов проекта. И в зависимости от того, знаем мы этого заказчика или нет. Почти всем на входе даем 8 часов. А если мы заказчика знаем и давно с ним работаем – там уже договорная вещь.

Так или иначе, мы для себя видим в этом большой плюс. У нас даже менеджеры по продажам начинают отрисовывать, потому что в этом нет ничего сложного. Продажник общается с представителем заказчика, тот ему говорит: «А давай тут пододвинем». И дальше они идут к ЛПРу, все это обсуждают и решают.

А кто участвует в этом брейнсторме? Какие роли – программисты, архитекторы?

Три человека: РП, бизнес-аналитик и программист. Либо архитектор – в зависимости от масштаба проекта. В основном архитектор.

 

P.S. Вы можете получить бесплатный базовый курс по использованию сервиса MAKER при создании форм и технических заданий для программ на базе 1С, а также применения его в качестве инструмента управления проектами и задачами.
 

 

***************

Статья написана по итогам доклада, прочитанного на конференции Анализ & Управление в ИТ-проектах.

 

Приглашаем на конференции Инфостарта 2025 года

INFOSTART TEAMLEAD EVENT

Не только для разработчиков, но и для руководителей отделов разработки, тимлидов и ИТ-директоров.
Место: Москва
Даты: 24-25 февраля 2025 г.

Подробнее

INFOSTART A&PM EVENT (Анализ & Управление проектами)

Практическая конференция для аналитиков и руководителей проектов 1С.
Место: Санкт-Петербург
Даты: 29-31 мая 2025 г.

Подробнее


См. также

Проектирование Бесплатно (free)

Управлять ресурсами на проектах сложно – их то не хватает, то они простаивают. Эта ситуация известна многим как «Проектные качели». О том, как типизировать поток входящих задач и сбалансировать те самые «Проектные качели» от годовых планов по организации до оперативных проектных совещаний, на конференции Infostart Event 2022 Saint Petersburg рассказал Сергей Лебедев, ITLand.

09.08.2024    523    0    Лебедев Сергей    0    

5

Работа с требованиями Бесплатно (free)

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

29.07.2024    3501    0    user1145928    2    

6

Проектирование Анализ предметной области Бесплатно (free)

В девятнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, как и для чего применяют DDD, и почему аналитиком важно знать об этом подходе.

13.05.2024    664    0    Radio_Analyst    0    

3

Удобство использования (UX) Бесплатно (free)

В среде 1С есть уникальная возможность быстро собрать интерфейс и сразу сделать работающее приложение. Но при разработке комплексного продукта или автоматизированного рабочего места имеет смысл выделить прототипирование в отдельный этап. О том, как выбрать инструмент прототипирования для 1С и встроить прототипы в рабочий процесс, пойдет речь далее.

11.03.2024    1851    0    gntk    1    

10

Проектирование Проектирование бизнес-процессов Управление конфликтами Кейсы продуктов Бесплатно (free)

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

05.02.2024    779    0    Radio_Analyst    0    

1

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    2624    0    otkalo    1    

13

Удобство использования (UX) Бесплатно (free)

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

23.01.2024    1930    0    user1944852    8    

13

Проектирование Архитектура данных Проектирование бизнес-процессов Бесплатно (free)

В одиннадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что такое архитектура в IT и в бизнесе, какие задачи, связанные с разными архитектурными слоями, решают архитекторы и аналитики, что такое TOGAF и нужно ли изучать подход «всё как код», Process Mining и Jobs to Be Done.

22.01.2024    1081    0    Radio_Analyst    1    

8
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. booksfill 18.04.24 10:02 Сейчас в теме
Спасибо. Статья полезная и интересная. Даже реклама своего продукта тут уместна.

Я только одного не понял: "почему самолет летает, а крыльями не машет".
мы уже на 90% зафиксировали наш объем разработки
.

Откуда взялось столь ошеломительное снижение неопределенности за счет прототипирования?
Может это работает только в приложениях с минимальным backend?
И, нет, даже, если это не B2B, а В2С - далеко не всегда это значит простой функционал, тем более, что одна "B" никуда не девается. И продажа условного йогурта может вылиться в неслабую цепочку, включая всякие крайне непростые обмены с госорганами.

Идя по вашей картинке, можно, вообще не напрягаясь, раздуть трудозатраты в 100 раз.

Даже на вашем примере максимально простого приложения.
ФИО - а если у клиента полное имя звучит как Gabriel José de la Concordia García Márquez (куда это вообще писать), а если "продвинутый" пользователь введет вместо имени нечто, за что потом прилетит от органов. А может ли имя состоять из одной буквы, если да, то не стоит ли все равно переспросить. А информацию следует предавать по https, как там с сертификатами. А как эти данные хранить у себя. А должно ли имя проверяться по данным паспорта, а надо ли проверять ИНН и как.
И так по каждому пункту: "подписание оферты". Как? Кликаем на кнопку или электронной подписью?
Надо еще раз переспросить согласен ли, или и так сойдет.
И т.д. и т.п.

Может я имел дела с какими-то не такими приложениями, но иногда за одной кнопкой на форме обработки скрывался месяц разработки.
artbear; amiralnar; +2 Ответить
Оставьте свое сообщение