Приветствую! Я Тимур Драгунов. Уже более 10 лет работаю в сфере IT. Карьеру начинал как разработчик интернет-проектов. Позже присоединился к команде российского редактора PDF Commander. В последние годы мы с коллегами сфокусировались на корпоративном сегменте. Эта часть рынка традиционно считается более доходной, чем выполнение проектов для обычных пользователей. К тому же у значительной части потенциальных заказчиков появился спрос на альтернативы решениям от крупных международных компаний.

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

0 этап: что нужно знать про жизненный цикл корпоративного ПО

Жизненный цикл ПО (SDLC — Software Development Lifecycle) — это период времени, который начинается в тот момент, когда вы решаете создать какой-либо софт, а заканчивается, когда разработка, поддержка и реализация приложения или сервиса полностью прекращаются.

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

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

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

• Каскадная модель (waterfall, модель водопада). Весь процесс делится на несколько жестких стадий. Переход к следующей фазе происходит только тогда, когда будут полностью выполнены все работы на предыдущем этапе.
  
  На практике в чистом виде метод подходит только для относительно небольших и простых проектов. Запросы клиентов периодически меняются, как и вся ситуация на рынке. Поэтому крайне сложно быстро и за приемлемый бюджет создать софт, который раз и навсегда закроет какую-то часть потребностей (например, работу с PDF-файлами) и не понадобятся существенные модернизации.
• V-образная модель (V-Model, VEE модель). Параллельно проводятся этапы разработки и тестирования. При этом данные, полученные на одной из двух ветвей, влияют на другую. Например, предложенная базовая модель анализируется и проверяется на соответствие отраслевым стандартам. По результатам — дорабатывается и усложняется. То же самое происходит с архитектурой, прототипом, дополнительными компонентами финального продукта.
  
  Подход требует много ресурсов, но обеспечивает надежный контроль качества. К методу прибегают в отраслях, где даже незначительные ошибки приводят к фатальным последствиям (космос, авиация, атомная энергетика и т.п.).
• Итеративная модель. Работы ведутся параллельно, полученные результаты, включая промежуточные, непрерывно анализируются, и на основе этой информации корректируются текущие и будущие задачи. Этот подход сейчас преобладает. На его основе возникло множество других методологий — Agile, SCRUM, Канбан и другие.
  
  Модель позволяет быстро адаптироваться к меняющимся условиям. Однако возможны проблемы с правильным подсчетом бюджета и сроков реализации проекта. Также при последующих изменениях иногда приходится серьезно переделывать изначальную архитектуру.
• Спиральная модель. Сочетает в себе удачные элементы итеративного и каскадного подходов. Разработка и внедрение программного обеспечения ведется циклами. В начале каждого оцениваются доступные ресурсы, риски и потенциальные возможности. На основе этих данных составляется список работ, которые реально выполнить к назначенной дате.
  
  Основной недостаток модели заключаются в том, что не всегда удается правильно определить момент перехода на следующий цикл. Также иногда команда слишком увлекается и проводит избыточную оптимизацию продукта.

1 этап: работа над концепцией и идеей

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

Исследование рынка и конкурентов

Существует как минимум несколько компаний или разработчиков-одиночек, которые предлагают софт с похожей функциональностью. Например, операции с PDF-файлами можно выполнять в нашем PDF Commander, Adobe Acrobat, решениях от Foxit, пакете Microsoft Office или в его аналоге LibreOffice.

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

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

Составление портрета пользователя

Определите категории клиентов, которым может пригодиться ваше ПО. Общие, абстрактные формулировки («все, кто…», «все пользователи, которым…») ошибочны и бесполезны для вас.

Более удачный пример: организации со штатной численностью до 50 человек, в сфере торговли непродовольственными товарами, используют приложения А, В и С.

Определение уникального торгового предложения (USP)

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

Благодаря этому вы вряд ли создадите абсолютно уникальный товар. Однако сможете предложить продукт, который не только решает основной (для этого сегмента) набор задач, но и устраняет наболевшие проблемы.

2 этап: планирование и проектирование

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

Составление пользовательских сценариев

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

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

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

Более удачный: клиент получил проект договора в PDF от контрагента. Это предполагает следующие действия:

1. Файл документа открывается в программе. Лучше совместить редактор и просмотрщик, чтобы материал не пришлось по несколько раз переимпортировать в разном софте. Значит, приложение должно быть достаточно легковесным, чтобы загрузка не происходила слишком долго.
2. Документ просматривается. Нужны опции для скроллинга и масштабирования. Желательно добавить функцию комментариев и пометок — если при чтении появятся мысли и замечания, их можно сразу же добавить.
3. В документ вносятся правки. Требуются функции редактирования — удаление фрагментов, вставка нового текста. Если содержание не распознано, нужен инструмент для OCR (оптического распознавания символов).
4. Финальный вариант сохраняется. Необходим корректный экспорт в PDF с соблюдением всех требований стандарта. Возможно, клиенту нужно сохранить документ в другой формат. Вероятнее всего, это DOCX, RTF, JPEG и PNG.
5. Клиент согласен с предложением контрагента и готов подписать договор. Нужна функция печати на принтере. Деловая практика может допускать такой вариант, когда в электронный документ добавляется факсимиле и изображение печати. Также часто используются электронные подписи.

При помощи подобных сценариев проще понять реальные потребности заказчиков и на основе этого предлагать удобные и функциональные решения.

Разработка ТЗ: структура, требования, ограничения

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

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

Следующий документ детализирует функционал. Если ПО относительно простое, можно вести и постепенно дополнять один файл. В остальных случаях желательно под каждую функцию (группу схожих функций) вести отдельный документ. Здесь подробно описывают архитектуру, принцип работы каждого инструмента. Для лучшего понимания добавляют схемы, таблицы, инфографику, мокапы пользовательских интерфейсов. Открыв эту документацию, каждый член команды должен быстро понять, как работает продукт и что именно нужно делать по задаче.

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

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

Также желательно составлять относительно долгосрочные планы развития (дорожные карты, или roadmap). В них отражают будущий функционал с привязкой к определенным датам. Например, март — добавление таблиц, апрель — расширенное форматирование, поддержка сканеров, май — OCR, и т.д.

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

Создание прототипов или мокапов

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

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

3 этап: разработка интерфейса и пользовательского опыта (UI/UX)

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

Создание визуальных концепций

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

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

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

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

Тестирование прототипов с участием пользователей

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

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

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

4 этап: разработка и код

В процессе разработки документация и все идеи обрастают кодом и постепенно превращаются в ту или иную версию продукта.

Работа программистов: фронтенд, бэкенд, интеграция

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

• Бэкенд. Серверная часть (при клиент-серверной архитектуре) и внутренняя логика ПО. Бэкенд-разработчики занимаются программированием структуры данных, их хранения и обработки по определенным алгоритмам.
• Фронтенд. Клиентская часть (при клиент-серверной архитектуре) и интерфейс программы. Фронтенд-разработчики делают так, чтобы все кнопки-списки-меню правильно функционировали, корректно отправляли исходные данные во внутреннюю логику и возвращали пользователю конечный результат.
• Интеграция. Взаимодействие приложения с другим ПО. Это могут быть плагины, определенные программные интерфейсы (API), сторонние библиотеки, импортируемый контент и т.п.

Методологии

Они идентичны подходам к организации SDLC. Методологию желательно выбирать на самых ранних стадиях разработки или еще при формировании команды и не менять без крайней необходимости.

Переход на другие подходы на достаточно долгое время парализует всю деятельность. Кто-то из коллег не захочет адаптироваться и покинет компанию. Существует вероятность, что вам даже придется заново проектировать архитектуру приложения. То есть фактически заново пересоздавать все проделанное ранее.

Проведение первых модульных тестов

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

Для инструментов разработки программного обеспечения есть готовые библиотеки юнит-тестирования. Например, NUnit для C# или JUnit для Java.

5 этап: проверка работоспособности, безопасности, производительности

Тестирование и отладка программы не ограничиваются ранними прототипами. Оно регулярно проводятся на каждом этапе жизненного цикла.

Юнит-тестирование

Я уже упоминал его выше. Это первая фаза в иерархии тестов. Почти всегда современное ПО состоит из множества относительно мелких модулей. Необходимо своевременно проверять работоспособность каждого из них. Это не дает полной гарантии, что вся программа будет функционировать, как задумано. Однако вы сможете заранее избавиться от некоторых багов и повторно использовать часть кода (конечно, если она успешно пройдет юнит-тесты).

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

Интеграционное тестирование

Разработчики проверяют, способны ли разные модули в принципе взаимодействовать друг с другом и насколько корректно происходит этот процесс. Для этого задействуются системы непрерывной интеграции (CIS). Они отслеживают изменения в системах контроля версий. Затем запускают проверки отдельных компонентов. Если эта фаза пройдена успешно, выполняется компиляция и тестируется взаимодействие модулей между собой. По результатам генерируется отчет.

Этот этап не стоит путать с системным тестированием, на котором проверяется весь продукт.

Тестирование интерфейса и UX

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

Удобство и общие ощущения (или UX) оценивает фокус-группа пользователей. Это тестирование может быть открытым (присоединяются все желающие) или закрытым (участвуют индивидуально отобранные люди и организации).

QA и UX-тестирование можно поручать подрядчикам. Это особенно оправдано, когда требуются масштабные проверки во множестве сценариев.

Этап 6: финальный релиз продукта

При успешном завершении тестирования приложение готово к выходу на рынок.

Загрузка приложения в магазины (App Store, Google Play)

Мобильные приложения в большинстве случаев распространяется через встроенные магазины соответствующих платформ. Для iOS и iPad OS это единственный возможный вариант (взлом прошивки и разные достаточно сложные схемы не рассматриваем). В Android приложения можно устанавливать из APK-файлов. Однако этот способ подходит только для специфических случаев. Например, программа распространяется только по индивидуальным контрактам с заказчиками.

Чтобы размещать софт в сторах, нужно зарегистрировать аккаунт разработчика (App Store, Google Play). В процессе придется заполнить анкету и внести небольшую плату.

Создание сайта десктопного продукта

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

Презентация и маркетинговые кампании

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

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

Эффект от контент-маркетинга проявляется не сразу. Обычно — не ранее чем через полгода-год. Параллельно нужно задействовать приемы SEO и SMM при продвижении на сайтах и в соцсетях соответственно.

Мониторинг первых дней работы

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

7 этап: сбор обратной связи, исправление багов, добавление нового функционала

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

Мониторинг отзывов

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

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

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

Выпуск обновлений

Исправления критических ошибок и уязвимостей предоставляют в максимально сжатые сроки. График плановых обновлений определяют соглашения с ключевыми клиентами и выбранная методология разработки. Обычно — каждые 3-4 недели или реже.

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

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

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

Оценка пользовательских данных для улучшений

Информация, полученная в процессе поддержки пользователей, может прямо указывать на определенные недостатки. Однако данные нужно оценивать комплексно и перепроверять дополнительными тестами. 

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

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

Резюмирую

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

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