Заказная разработка: 8 вопросов для старта проекта
Владимир Лавров, генеральный директор ГК Softline
Чтобы запустить крупный ИТ-проект и добиться поставленных целей, нужно грамотно выстроить коммуникацию с исполнителями. Рассказываю, о каких вещах следует заранее подумать отечественным компаниям, прежде чем начинать заказную разработку.
Рекомендации, о которых я сейчас расскажу, собраны на основе практики и обращений в одну из наших компаний – Девелонику. В направлении отечественной заказной разработки в 2023 году она стала лидером в рамках независимого исследования рынка. За 24 года коллеги накопили портфель из более 3700 реализованных гипотез заказчиков в разных сегментах экономики. И, когда на недавней встрече зашел разговор о готовности российского бизнеса к ИТ-изменениям, мы составили небольшой список, который мог бы помочь подготовиться к старту проекта, вне зависимости от вашей сферы деятельности.
1. Определяем проблему
Правильная формулировка проблемы – залог оптимального выбора инструментов и подходов к ее решению. Велико желание изменить и обновить всё и сразу. Но стоит выработать план, выбрать главные системы или элементы, которые в текущий момент времени необходимо решать. Определите, какую задачу вы считаете приоритетной – импортозамещение зарубежного софта в разрезе облачного хранения или разработка внутренней информационной системы для сотрудников. Подрядчик должен провести аналитику и глубоко изучить запрос, чтобы понять масштаб проекта, выявить ограничения и рамки, определить пул компетенций, который вам понадобится.
2. Фиксируем время на разработку и реализацию
Компания-разработчик должна понимать, сколько времени есть у экспертов, чтобы решить задачу. От этого зависит, например, будет ли это разработка с нуля и под ключ, или придется использовать готовое решение с элементами кастомизации. Также исполнитель поймет, какое количество сотрудников будет задействовано при реализации проекта. Обрате внимание на готовность подрядчика прозрачно обговаривать все детали и нюансы: вехи проекта, план действий, сроки выполнения задач, использование технологий. Как-то команда Девелоники из-за сжатых сроков заказчика всего за месяц успела разработать полный прототип требуемой системы, включая имитацию ее алгоритмов. Дополнительно был подготовлен один из возможных дизайнов решения (UI и UX интерфейсы). Это не массовая практика, проекты будут занимать в среднем от полугода. Но работать станет проще, если понимать дедлайны.
3. Просчитываем бюджет
Коллеги говорят: «Если у вас есть ограничения по бюджету, никогда не стесняйтесь их озвучивать». Если хотите что-то сделать хорошо, сделайте это у профессионалов. Это может требовать крупных финансовых вложений, но оправдает их. Одно упущенное компанией тестирование может привести к последующему откату системы и «переделкам». Бюджеты могут увеличиться в разы, хотя этого можно избежать, запланировав должное количество проверок. Не забывайте об этом, даже если в моменте это кажется накладным.
Также, в контексте разработки, нужно понимать, из чего складывается оплата за проект. Основные пункты: работа ИТ-специалистов, срок реализации, доп.расходы на лицензии. Последнее, кстати, может брать на себя компания-разработчик.
4. Объясняем характер задачи
Вы хотите начать всё с нуля или осуществляете внедрение в существующий контур? Проект может включать в себя все стадии заказной разработки, а может быть кастомизацией существующего внутри компании решения. Всегда стоит обозначать все технические детали, тем более, если у вас уже функционирует некое решение. Поймите, какие технологии вы используете и какой функционал необходим. Помимо этого, разработчикам важно знать, как в будущем вы хотели бы масштабировать систему. Расскажите с какими вендорами работает компания. Бывает полезно посмотреть, что делают конкуренты и лидеры рынка, а также изучить антипримеры, чтобы не совершать аналогичных ошибок.
Я обозначил 4 первых тезиса, которые нужно проработать перед запуском проекта. В следующий раз расскажу еще о 4-х важных задачах. Ждите продолжение.
5. Пересматриваем ресурсы
К этому пункту нужно подойти с нескольких сторон. Эксперты советуют провести проверку по трём вопросам.
1) Готовы ли вы технически?
Оцените инфраструктуру и реальные мощности ИТ-систем. Зафиксируйте проблемы, с которыми сталкиваетесь. Проследите за логикой организации бизнес–процессов.
2) Готовы ли ваши регламенты?
Проверьте, как налажены и подтверждены ли нормы соблюдения внутренних и внешних регуляторов, всё ли в порядке с внутренней документацией.
3)Готовы ли люди?
Действительно ли шаги, на которые вы решаетесь, принесут пользу и требуются вашему конечному потребителю? Партнёры, пользователи, сотрудники и клиенты должны быть морально готовы вместе с руководством бизнеса. К сожалению, случается, что недобросовестные подрядчики пользуются заказчиком, когда у него есть время и ресурсы, предлагая «что-то» да изменить. Относитесь к экспертизе внимательно и взвешивайте рациональность изменений.
6. Проверяем ограничения отрасли
Какие отраслевые или индивидуальные тезисы стоит учитывать разработчикам в ходе проекта? У каждой индустрии и направления свои особенности: где-то высокие требования к ИБ, для других компаний имеет первоочередное значение техническая специфика или возможные производственные риски. Схожие по задачам системы для госсектора и ритейла будут иметь разный конечный продукт. И можно сразу создавать решение под себя, если дать компании-разработчику понять вашу отраслевую специфику и ограничения.
7. Выбираем технологический стек
Отечественные компании по разным причинам больше не смотрят на импортный стек.
Одни столкнулись с невозможностью продления лицензий и сложностями оплаты. Другие с тем, что ряд функционала перестал работать после ухода западных вендоров. Если вам важно наличие используемых технологий в Реестре ПО – это необходимо проговорить. Компания-разработчик должна обсудить с вами и предложить варианты технологий, которые будут максимально удобны и приемлемы в вашем случае.
Сейчас, по ряду исследований, на рынке есть перевес в сторону использования свободного ПО. Бизнес пытается «подогнать» вендорское решение под свои бизнес-процессы. Важно понимать, облегчает ли участие вендора реализацию проекта? Сможет ли он поддерживать запросы компании в будущем? Открыт ли код, чтобы вы могли «подхватить» системы самостоятельно или передать поддержку новому партнёру.
8. Оцениваем необходимость сопровождения
Подумайте, сможете ли вы оказывать поддержку систем или отдадите это дело в руки профессионалам, когда проект закончится и софт буден введён в эксплуатацию. Есть три пути. Первый характерен для инхаус разработки, когда продукт остается внутри бизнеса и его ИТ-команда решает все задачи сопровождения. Следующий – это создание вместе с вашим партнёром по разработке отдельного центра компетенций, где сотрудники заказчика могут обучаться работе с софтом, а разработчики подключаются для решения новых вызовов, связанных с вашей системой. И третий вариант – передача поддержки и сопровождения на аутсорс.
Каждый из вариантов имеет свои преимущества, поэтому предупредите исполнителя проекта о своих планах, чтобы заранее решить вопрос поддержки ПО.
Остались вопросы? Мои коллеги из Девелоники с удовольствием проконсультируют вас https://www.develonica.ru/
#ЗаказнаяРазработка #ИТСоветы #БизнесРешения #Девелоника