Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Вводная
Всем привет!
Меня зовут Дмитрий, и я системный аналитик в отделе прототипирования в Первой грузовой компании. Наша команда помогает создавать новые цифровые продукты в компании и оптимизировать бизнес‑процессы. Для этого мы разрабатываем прототипы/PoC‑продукты для быстрого тестирования гипотез. Чем я занимаюсь: общение с заказчиком, анализ и описание требований к продукту, сопровождение процесса создания прототипа, разбор кейсов. Сегодня я поделюсь лайфхаками гибкой разработки прототипа.
Во время тестирования продукта заказчик сообщает, что в 98% случаях все работает корректно, а 2% ошибок он даже не встречал. Кнопку лучше расположить справа, а не слева и, вообще, если добавить туда еще пару источников, то отчет выйдет совершенно на другой уровень, дополнительно и бизнес‑логику нужно изменить. Знакомо?
На момент формирования требований заказчик был уверен, что логика верна и проработана. На этапе тестирования начинаются сюрпризы.
К чему это приводит? Разработка начинает вырастать в цене, а сроки сдвигаться.
Как поступить? Можно серьезно поговорить с заказчиком, объяснять разницу между фронтендом и бэкендом, акцентировать внимание на тщательной проработке требований. Однако заказчик — это представитель бизнеса, он не всегда понимает, как устроен процесс разработки и какие технические возможности по созданию продуктов есть у разработчиков. Из‑за этого он порой не может до конца определиться чего хочет, и как продукт или сервис должен работать по итогу.
Если на этапе работы над бизнес‑требованиями аналитик подозревает, что заказчик не понимает, как должна складываться бизнес‑логика, начинает путаться в деталях и «плавать», то почему бы не отправить такой проект в отдел прототипирования?
Desktop приложение на python вместо web
Рассмотрим наиболее часто встречающийся запрос. Появилась потребность автоматизировать отчет или расчет. Предполагаю, что такой тип запросов одинаков для большинства компаний. Как правило, информацию для ручной сборки подготавливают в Excel: справочники, выгрузки из разных систем.
Отчет всегда собирается с небольшими допущениями и исключениями, инициатор сам до конца не уверен в своем алгоритме. Аналитик при общении с заказчиком и в процессе написания технического задания понимает, что возможно будет несколько итераций, в которых изменится логика. Нам важно разработать простое и удобное решение, которое поможет заказчику и при этом не будет затратным по времени разработки.
Задача — набросать приложение и отдать на тестирование, мы намеренно берем за скобки вопросы архитектуры. В данном контексте цель все‑таки помочь бизнесу и только после того, как мы поймем, что предложенное решение работает, возьмемся за его разработку по всем канонам.
Вместо тандема бэк+фронт в качестве GUI мы присмотрелись к библиотеке tkinter, можно смело заменить ее на библиотеку c более приятным интерфейсом PyQt5. Дополнительно мы высвобождаем ресурс фронтенд разработчика.
Для примера можно взять код из этой статьи. Logging to a Tkinter ScrolledText Widget | Tchut‑Tchut Blog (beenje.github.io)
Так выглядит наш пример до преобразований:
Вполне подходит под наши цели. Логирование можно вывести в консоль, добавить кнопки, выпадающие списки и чекбоксы. Если заказчик захочет изменить кнопку или функционал, это не займет много времени. Одна из наших целей — помочь заказчику определиться с его требованиями через тестирование прототипа.
Справочники и промежуточные таблицы
Во время реализации стоит обратить внимание на справочники. При формировании требований интересуемся, что может изменяться? И постараться сделать гибкие справочники, которыми будет управлять сам заказчик. Мне кажется, справочники лучше оставлять в Excel — это удобный и понятный инструмент для бизнеса.
Если мы говорим про отчеты, как правило, из 100 столбцов с источниками данных используют 15–30. В процессе тестирования может выясниться, что требуется вывести 2–3 столбца или наоборот удалить их. Зачем это делать путем исправления кода? Пусть заказчик сам управляет набором столбцов через справочники.
Если вы понимаете, что заказчик будет настраивать один из параметров, то выводите его в справочник, если это возможно.
Пример справочника:
В данном справочнике заказчик сможет изменять набор выводимых столбцов для двух отчетов.
Какой столбец и за какие функции отвечает расписал ниже в таблице:
Название столбца | Функция |
Отчет | Название отчета |
Столбцы | Настройка вывода столбцов |
Источник данных | Настройка заливки столбца цветом в соответствие с источником |
Формат отображения в отчете | Настройка вывода значений в заданном формате strftime – дата (ДД.ММ.ГГГГ) в формате текста, str – текст. |
Ширина столбца | Настройка ширины столбца |
Нередко тестирование занимает несколько недель, и инициатор, возвращаясь к тесту, забывает детали бизнес‑логики. Промежуточные таблицы помогут заказчику вспомнить и не тратить время на уточнения. Дополнительные таблицы с результатами вычислений лучше сохранять в отдельном файле.
GUI
Рисуем GUI предварительно уточнив у заказчика, что необходимо отобразить. Даже если заказчик что‑то забыл или у него изменяться требования, внести корректировки будет не так трудно. Из нашего источника собрали пример абстрактного отчета.
Вы можете даже добавить проверку на обязательные атрибуты заполнения. В нашем примере, когда пользователь нажимает кнопку «Запустить» срабатывают два сценария:
Если обязательные аналитики не заполнены, то на консоль будут выводиться подсказки.
Если обязательные аналитики заполнены, то проводится валидация на корректность ввода дат.
Свои контакты можно выводить при нажатии кнопки «Разработчики». Так любой пользователь прототипа будет понимать к кому конкретно следует обратиться, если возникнет необходимость.
После разработки преобразуем исполняемый файл.EXE при помощи PyInstaller.
Заключение
Реализация прототипа — решение, которое помогает сформировать более детальный образ результата целевого продукта. Его разработка требует меньше временных и денежных ресурсов, чем работа над целевым решением с постоянно изменяющимися на старте требованиями и неопределенностью заказчика. Вносить изменения в прототип или в уже реализованный продукт — это две огромные разницы с точки зрения затрат. Поэтому в условиях, когда нет четкого понимания, как именно должен быть реализован продукт, возможность разработки гибкого решения — оптимальный вариант.
Еще один важный момент — не нужно забывать актуализировать документацию по ходу работы над прототипом. Ведь в случае его успешной разработки, документация будет необходима для реализации в целевом решении.
А какие варианты гибкой работы над прототипами используете вы и как решаете аналогичные задачи? Напишите в комментариях.
