Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы, поиск оптимальных решений, принятие компромиссных решений, все это значительно усложняет проект или вообще может завести вас в тупик.
Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).
Статья которую вы читаете в данный момент, описывает начальное положение в проекте, когда есть только идея и большое желание создать программный продукт. Именно в этот момент принимается большинство решений ограничивающих наш выбор в дальнейшем. Чтобы исправить это, помочь разработчикам принимать более взвешенные решения и начат текущий цикл статей. Вообще-то в статье не описаны какие-то уникальные знания. Все приемы известны давно и упоминаются в различной литературе. Просто в статьи будут включены те, которые принесли максимальную пользу при практической работе над различными проектами. Стоит упомянуть, что большинство завершенных проектов выполнялись по заказу от бизнес партнеров, но и те которые делались для свободного использования не выходят за рамки описываемого.
Итак, в качестве сквозного примера, для всего цикла статей, будет идея создать библиотеку электронных книг для обучения и научной работы.
Привычные действия при работе с электронной книгой сводятся к загрузке книги на локальный носитель и дальнейшая работа с ней в специализированной программе. Однако, если вы работаете с такой программой, и желаете создать конспект книги, вы столкнетесь с множеством ограничений.
Для работы с текстом, как источником знаний необходимо учитывать переходы по библиографическим и внутритекстовым ссылкам. Уметь создавать подстрочные и за текстовые комментарии. Выделять цитаты, которые бы отображались в конспекте, и много чего еще, что затрудняло полноценную работу с электронным текстом.
На данном этапе мы определили нашу идею в виде цели проекта, которая является начальным этапом в составлении технико-экономического обоснования или бизнес-плана.
Такой документ описывает весть проект в целом и проектирование программного обеспечения напрямую от него не зависит, однако и технико-экономическое обоснование, и бизнес-план, содержит раздел связанный с маркетингом. Вот он, может оказать значительную помощь при проектировании.
При технической реализации важно использовать портрет покупателя описываемый в разделе маркетинга. Портрет покупателя составляют, чтобы описать образ типичного пользователя продукта или услуги. Вот перечень вопросов на которые отвечают при написании этого раздела:
- определить уникальные характеристики товара,
- выбрать каналы продвижения продукта,
- персонализировать коммуникацию с клиентами.
Каждый из этих пунктов не только непосредственно связан с проектированием, но и является основой для принятия технических решений.
Для того, чтобы пояснить тесную связь маркетинговых исследований с разрабатываемым проектом, давайте рассмотрим перечень типичных ошибок разработчиков.
- Недостаточный анализ требований.
- Неправильный выбор архитектуры.
- Пренебрежение тестированием.
- Недооценка безопасности.
- Проблемы с управлением временем и ресурсами.
- Игнорирование обратной связи.
- Проблемы с документацией.
- Недооценка UX/UI-дизайна.
- Технический долг.
- Недооценка командной работы.
- Недооценка инфраструктуры.
- Отсутствие плана на будущее
Мы не будем рассматривать все пункты под подряд, так как половина из них связана с управлением проектами и достойна отдельного рассмотрения. Остановимся только на тех пунктах которые влияют на проектирование в самом начале, мешая его успешному завершению.
Недостаточный анализ требований.
Связь этого пункта с первым пунктом из маркетингового портрета покупателя и без дополнительных пояснений очевидна, но именно этот пункт, наверное, чаще всего приводит к проблемам. По крайней мере по моим наблюдениям.
При составлении функционала существует две заинтересованные стороны, представители заказчика, в виде квалифицированных специалистов. С другой стороны квалифицированные специалисты разработчика. Каждая из сторон, исходя из своих соображений и опыта, наполняет перечень требований к будущей программе, и в этот момент часто теряются реальные потребности простого пользователя.
Возьмем всем известный пример Windows Phone, и его плиточный интерфейс Metro UI. Отзывы экспертов были положительны, однако простые пользователи посчитали интерфейс излишне сложным, и отдали предпочтение более простому iPhone и Android, где интерфейс придерживается хоть и той же плиточной структуре, но имеет боле привычный вид иконок.
Или более близкий пример. Руководство компании решило внедрить сквозную систему учета на производственном предприятии, дабы снизить управленческие затраты. Однако проект столкнулся с непониманием, а порой и с не желанием простых сотрудников вести единый учет. Возражений было множество, но их суть была одна, в самом начале, руководство заказывало продукт под себя, а разработчики предлагали эффективные решения их задач, еще более усложняя работу с данными. Но никто не поинтересовался возможностями и мнением простых сотрудников. Если говорить языком маркетинга не верно были определены уникальные характеристики товара.
Неправильный выбор архитектуры.
Эта ошибка встречается ничуть не меньше чем предыдущая. Дело в том, что разработчики имеют скверную привычку ориентироваться на собственные предпочтения игнорируя потребности пользователей программного продукта. Не единожды приходилось сталкиваться с ситуациями, когда разработчики, даже не до конца определившись с потребностями заказчика предлагали определенную архитектуру. С первых шагов ограничивали себя и заказчика в выборе. При этом ориентировались на собственные возможности, предпочтения и слишком часто, на модные решения.
В качестве примера. На предприятии создается система ведения учета с MongoDB, ультра модной тогда системе управления базами данных. Уже к концу проекта начали наблюдаться задержки при извлечении данных, которые были списаны на аппаратную часть. Дальнейшая эксплуатация показала замедление производительности с увеличением объема данных. Документно - ориентированная система не обеспечивала должного уровня доступа у данным, их извлечение становилось все более дорогой процедурой. В результате, каждое обращение к сводным данным стало приводить к заметным задержкам. И подобных примеров слишком много.
Хотя разбор чужих ошибок чрезвычайно поучителен, пропустим пункты не входящие в рамки текущей статьи. Пренебрежение тестированием. Недооценка безопасности. Проблемы с управлением временем и ресурсами. Игнорирование обратной связи. Проблемы с документацией.
Недооценка UX/UI-дизайна.
Ошибки при организации дизайна приложения не слишком очевидны. Чаще всего даже не видны на общем фоне проекта. Однако их влияние сказывается по окончании проекта, и выражается это по разному. Все зависит от точки приложения, если это электронная коммерция, то кнопка находящаяся в не подходящем месте заметно снижает конверсию. Об этом много написано и нет необходимости повторяться в рамках статьи. Помимо этого при разработке бизнес-приложений бывают довольно сложные ситуации, когда влияние дизайна, хоть и не на прямую, но влияет на успешность проекта.
Один из примеров. В уже используемых на предприятии программах, в формах ввода информации были поля, заполнение которых влияло на учет и пользователи при приеме на работу специально обучались их заполнять. При разработке нового программного продукта, удалось применить определенные алгоритмы, которые заполняли эти поля автоматически на основании ранее введенной информации. Дизайнеры по согласованию с заказчиком исключили их из форм ввода.
В начале внедрения это не вызвало проблем, так как тестировали функционал люди знакомые с принятыми решениями. Однако после запуска в работу посыпались вопросы по удаленным полям. Именно тогда были сказаны слова, которые повлияли на взгляды команды разработчиков и мое видение проектирования программных продуктов.
В ходе фокус-группы, руководитель заказчика сказал, что для него важнее спокойная обстановка в коллективе, чем внедрение даже самых продвинутых технологий.
При проектировании конечно важно использование многослойной архитектуры, модульный подход, шаблоны проектирования и другие технические решения, но удовлетворенность конкретных пользователей важнее.
Отсутствие плана на будущее.
В списке типовых ошибок, это последний пункт, но ошибки попадающие в него, не менее распространены. В большинстве проектов, разработчики и специалисты занимающиеся технической поддержкой, это разные команды. Как правило эти команды различаются по многим параметрам, да и к тому же, у них разные цели и задачи. Задача поддержки обеспечить бесперебойную работу, а цель разработчиков завершить проект и переключиться на другой.
Несколько примеров. Разработанный продукт был успешно внедрен и эксплуатировался. Однако через полтора года выявился и стал усугубляться большой недостаток. База данных разрослась до огромных размеров, и стала все больше замедлять работу программы в целом. Заказчику пришлось раз в год проводить сложные мероприятия по «обрезке» базы. Каждый раз создавая новую базу и архивируя не актуальную. Можно только представить, как сложно было получать сводную информацию за несколько лет.
Еще один пример, на прямую не относящийся к программированию, но очень показательный по своим последствиям. Владельцы крупного торгового центра, который объединял группу предприятий торговли, управляемых как единое целое и находящихся в комплексе зданий. Обратились к опытному администратору, с целью решить проблемы с IT инфраструктурой. Проблем было много, но мы остановимся только на серверной части. На сервере одновременно работало с десяток программ от различных производителей, которые явно мешали друг другу, и приводили к частым аварийным остановкам. Пока администраторы разбирались с проблемами, предприятия торговли были парализованы.
Нанятый опытный специалист, принял решение изолировать конфликтующие программы в различных виртуальных средах. Автоматизировал решение часто возникающих проблем, таких как, перезапуск после сбоя, архивирование и аварийное восстановление. Однако заказчик не учел, что поддерживать эту инфраструктуру может только администратор с подобным уровнем подготовки. В результате, через пол года все вернулось к изначальному состоянию.
Все приведенные примеры объединяет один фактор, проблемы возникшие в конце проекта были вызваны ошибками, которые были допущены еще до начала проектирования. Конечно, в большинстве случаев у этих ошибок нет одного «автора». В каждом из примеров можно найти виноватого, но это не изменит одного, репутация разработчика пострадает, даже если вы абсолютно не виноваты.
Из книги по маркетингу: «В среднем, один довольный клиент может привести 3–10 новых клиентов через сарафанное радио, отзывы и социальные сети».
Теперь, когда с вводной частью покончено, давайте попробуем создать портрет пользователя нашей электронной библиотеки. На данном этапе хотелось бы заметить, что составлять портрет пользователя лучше поручить профессионалу. Ведь в начале проекта еще ни одна из сторон не понесла финансовых расходов, а это поле договоренностей с заказчиком.
Настоящая статья не преследует целей разобраться в маркетинговых приемах, поэтому дальше будем просто следовать пунктам руководства по составлению портрета покупателя.
1. Соберите данные о вашей аудитории.
Так как мы с самого начала ограничились, создавая электронную библиотеку для обучения и научной работы, предположим, что ей будут пользоваться студенты и профессорско - преподавательский состав различных учебных заведений.
2. Определите демографические характеристики.
Мужчины и женщины. Возраст пользователей группируется вокруг двух диапазонов, в 18 - 25 и 30 - 50 лет. Образование выше среднего. Навыки работы с компьютером, опытный пользователь.
3. Изучите психографические характеристики.
В нашем случае, этот пункт пропустим, так как его раскрытие не даст нам существенной информации.
4. Определите цели и задачи клиента.
Поскольку научную литературу, никто не читает для развлечения. Основной целью является работа с книгой. Цитирование, комментирование, конспектирование.
Цитирование. Получение участка текста с указанием его расположения в книге, автор, наименование, издание, глава, абзац и так далее.
Комментирование. Вставка в текст книги собственных записей.
Конспектирование. Сочетание двух предыдущих задач.
Остановимся на трех перечисленных задачах, так как это учебный пример, а не реальный проект. Впрочем каждый может расширить его до необходимых размеров и попрактиковаться в проектировании.
5. Проанализируйте поведенческие характеристики.
В данном случае, в отличии от реального портрета покупателя, опишем предполагаемою последовательность действий пользователя от начала работы с системой до завершения. По возможности во всех очевидных вариантах.
- Читатель может получить доступ к материалам библиотеки с любого устройства подключенного к интернету. После идентификации открывается рабочее место пользователя, которое содержит позицию из книги на котором остановился читатель, с привязкой конспекта актуального для этой книги.
- Рабочих мест может быть несколько, так как читатель может работать с несколькими книгами одновременно.
- Необходима возможность открывать каталог книг, для выбора новой книги для чтения.
- Помимо этого необходим библиотекарь, который бы распределял книги по разделам каталога и помогал с выбором книг и др.
- Администратор библиотеки, который бы загружал новые книги и решал возникающие технические вопросы связанные с работой библиотеки. Не связанных с администрированием системных программ (операционная система, базы данных и др.).
6. Создайте сегменты аудитории.
Во многом, пользователи электронной библиотеки были разделены в предыдущем разделе.
- Читатель;
- Библиотекарь;
- Администратор библиотеки.
Они довольно очевидны, но в реальных, сложных проектах, это разделение должно быть тщательно проанализировано. Описывать особенности пользователей, необходимо более детально. Представим среднее производственное предприятие, с делением на различные цеха. Пусть это будет фабрика напитков, квас, лимонад и подобное. Очевидны различия между рабочим в цеху, когда он отмечает материалы помещенные в конвейер, кладовщиком и начальником цеха.
7. Добавьте детали и "оживите" портрет. 8. Проверьте портрет на реалистичность.
Расписывать пункты 7 и 8, в данном примере, не имеет особого смысла. Они уточняют портрет и корректируют его выборочно опрашивая лиц из составленных групп.
9. Используйте портрет в маркетинге
Напомню, эти пункты взяты из материалов по маркетингу и являются своеобразной методичкой, для составления портрета покупателя. Но для разработчиков они важны не меньше.
Составленный по такой методичке портрет является отправной точкой в проектировании. Сегментация аудитории позволяет определить будущие роли пользователей, и здесь определение роли используется не как набор галочек для ограничения доступа. Под ролью пользователя понимается функциональные возможности рабочего пространства.
Для иллюстрации используем пример с фабрикой напитков. Рабочему на конвейере достаточно вывести поле куда вводить количество материала загруженного в конвейер и кнопки подтверждения, а вот начальник цеха может иметь совсем другой функционал.
Все выше описанное показывает, как от технико-экономического обоснования или бизнес-плана, мы перешли к проектированию. Фактически, в самом начале у нас есть большой объем информации. Портрет пользователя показывает кто и как будет пользоваться нашей программой, и в каком объеме.
Уже сейчас, пока мы будем продолжать проектировать, можно передать дизайнерам данные для создания UX/UI-дизайна. На данном этапе не сильно важно сколько и каких полей будет в каждом интерфейсе. Важно, что мы не только сможем визуально представлять готовый результат, но и что более важно согласовывать его заказчиком, на самых ранних этапах.
Такой подход соответствует идеологии MVP (англ. Minimal Viable Product) — минимально жизнеспособный продукт. После утверждения дизайна можно выделить незначительное время и запустить дизайн в эксплуатацию, а пока представители заказчика согласовывают наклон букв или цвет фона, разработчики сосредотачиваются на базовом функционале. Постепенно оживляя интерфейс, заменяя рисунки полей на реальные поля и дополняя ее новым функционалом.
Еще одной важной особенностью такого подхода является отказ от стремительно устаревающего подхода управления безопасностью через ограничения. Когда администратор установив систему начинает определять роли доступа и расставлять галочки на доступ к информации. Намного целесообразнее создавать интерфейсы пользователей таким образом, чтобы они и не знали о других возможностях. Визуально, каждый пользователь работает в своей программе.
Подводя итог описанному. Эта статья была бы не нужна, если бы в каждом проекте можно было бы написать техническое задание, составленное по всем правилам. Утвердить его на всех уровнях и спокойно разрабатывать программное обеспечение. Однако в жизни, требования заказчика часто меняются по мере развития проекта, и ошибки допущенные в самом начале, в конце проекта сильно затрудняют его завершение.
Вот список рекомендаций способных сократить их количество в начале проектирования.
- Начинайте проектирование не с предположений, а с выверенных знаний о пользователях и сфере применения будущего продукта. Основой для таких знаний могут быть материалы из технико-экономического обоснования или бизнес-плана. Если таковых нет, лучше обговорить это с заказчиком или привлечь стороннего специалиста. К сожалению, из разработчиков получаются неважные маркетологи, слишком разные навыки.
- Выполняйте сегментацию пользователей в начале проектирования. Группы пользователей необходимо объединить в роли которые станут основой для разделения функционала и дизайна. При этом, для каждой роли у вас будет свой портрет пользователя.
- С самого начала, откажитесь от поспешного выбора технических деталей. Язык программирования, framework, библиотеки, готовые модули, будут неосознанно ограничивать вас в выборе вариантов. Когда проектирование подойдет к завершающей стадии, параметры выбора станут простыми и очевидными, а количество различных элементов на рынке сделают его оптимальным. Вы должны руководить выбором, а не выбор вами.
Автор: Юрий Е. - 2025 г.