Заказная разработка ПО: как методология помогает повысить качество проектов

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

Опыт в заказной разработке

На ИТ-рынке компания IBS работает более 30 лет, из них около 15 лет занимается заказной разработкой. Сейчас команда по этому направлению насчитывает свыше 600 специалистов, а офисы компании присутствуют в 15 городах России.

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

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

Зачем нужна методология заказной разработки?

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

• при реализации проектов применяются разные подходы к выстраиванию процессов производства;

• методики и технологии плохо переиспользуются между проектами;

• структура команды и распределение обязанностей между ролями могут сильно отличаться от проекта к проекту;

• высокий порог входа новых сотрудников в проекты – переключение между проектами практически равно смене места работы и требуется большой адаптационный период;

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

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

 Что за методология?

 Методология ведения заказной разработки — это свод знаний и лучших практик по всем проектным областям знаний: управлению, аналитике, архитектуре, разработке, дизайну, DevOps и тестированию. Ее цель — сформировать общий стандарт работы, опираясь на опыт собственных специалистов и проверенные подходы рынка. При этом не ставилась задача заменить, например, PMBoK. Необходимо было спуститься к описанию принципов работы специалистов в проекте по ролям. 

При создании методологии мы ставили перед собой следующие задачи:

• выстроить единообразный процесс разработки на всех проектах;

• обеспечить непрерывный цикл работы — от описания требований до выпуска релиза для заказчика;

• организовать контроль «здоровья проектов» и подсветить потенциальные риски;

• снизить порог входа в проекты для новых участников и сократить сроки замены специалистов;

• реализовать обязательное централизованное обучение всех сотрудников, которые будут работать на проектах заказной разработки;

• упростить контроль качества со стороны проектного и линейного управления.

Что есть в методологии?

Методология, разработанная IBS, основана на сочетании гибких подходов (Agile) и традиционной каскадной модели (Waterfall). В ней затронуты все ключевые этапы проекта. Для каждого из них подробно описаны процессы, а также применяемые инструменты и методы.

1.    Управление проектами

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

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

Раньше в командах возникал вопрос: «Кто отвечает за актуальный состав бэклога?». Для ответа мы составили матрицу RACI, где закрепили зоны ответственности руководителя проекта, тимлида, ведущего аналитика и архитектора. Так как методология всегда развивается, эта матрица пополняется при выявлении разногласий на проектах. Выявить их помогает анализ итогов проекта — общий формат, где команда фиксирует достижения и уроки, чтобы накапливать проектный опыт.

Как отмечают руководители проектов, использование методологии значительно упрощает управление и улучшает взаимопонимание внутри команды.

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

К примеру, один из разработчиков одновременно работает на двух проектах. После оценки общего объема задач по нему выясняется, что через месяц процент его привлечения возрастет. Значит, требуются дополнительные ресурсы, чтобы исключить риск срыва сроков.

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

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

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

2.    Архитектура, проектирование и дизайн

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

Для качественного проектирования системы важную роль в проекте играют технический архитектор, аналитик (бизнес- и системный) и UX/UI-дизайнер.

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

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

Также приводится перечень методов и инструментов для их выполнения:

• лучшие практики сбора и формирования требований;

• инструменты моделирования бизнес-процессов;

• методики бизнес- и системного анализа;

• методика формирования общего бэклога работ;

• правила и подход применения инструментов искусственного интеллекта;

• единые шаблоны проектной документации.

Как показывает проектный опыт, помимо технологического и функционального проектирования важно уделять внимание проектированию пользовательского интерфейса. В методологии процессы UX/UI-дизайна проходят через все этапы проекта и отражаются в следующих процессах:

• исследование и анализ требований, выбор фреймворка дизайна;

• дизайн-концепт и проектирование будущей системы;

• разработка макетов и сопровождение на этапе реализации.

В инструментах отражены подсказки по созданию UI-kit, построению MindMap, User Flow и многое другое.

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

3.    Разработка, тестирование и доставка

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

Например, для backend- и frontend-разработчиков имеется набор преднастроенных компонентов, который позволяет быстро определить техническую реализацию для ряда бизнес-задач, например:

• импорт/экспорт данных;

• логирование;

• сервисы уведомлений;

• работа с электронной подписью;

• визуализация элементов интерфейса и т.д.

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

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

Кроме того, в методологии имеется описание правил по применению инструментов DevOps и DevSecOps, а также методик по тестированию — от функционального до нагрузочного.

Почему это — гибкий инструмент?

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

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

В чем преимущества для заказчиков?

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

Для заказчиков это означает более доступную, быструю и качественную разработку за счет:

• выстроенных процессов и непрерывного цикла работы;

• применения современных технологий и подходов;

• накопленного опыта в решении сложных задач в различных отраслях;

• возможности оперативного усиления команды специалистами с нужными компетенциями;

• строгого контроля за качеством проекта и ответственности за результат.

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

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