Как минимизировать риски с помощью внешнего проектного ИТ-департамента и регулярного SLA

11.08.2021Автор Кирилл Владимиров
Как минимизировать риски с помощью внешнего проектного ИТ-департамента и регулярного SLA
Поиск опытных и квалифицированных разработчиков ПО – одна из наиболее сложных проблем, с которыми приходится сталкиваться небольшим, средним, а также крупным компаниям.

Задача усложняется, когда нужно найти не только одного или двух разработчиков, тестировщиков, а набрать целый отдел разработки ПО, включающий в себя весь необходимый штат специалистов. Хорошо, если удается “схантить” целую команду, члены которой уже хорошо знают друг друга и успешно работали вместе над целым рядом проектов. Но такая удача случается очень редко. И, конечно, поиск руководителя подразделения разработки – это особая история.

Высокопрофессиональных и грамотных CIO, имеющих экспертизу в разработке продуктов и находящихся в “свободном полете”, на рынке нет, особенно если речь идет о тех, кто уже достиг определенных высот и ищет место с новыми, интересными и ранее неизведанными задачами. Даже если и удается привлечь такого руководителя, ему необходимо время, чтобы набрать свою команду специалистов, либо сработаться и настроиться на одну волну с уже имеющимися сотрудниками и вникнуть в специфику бизнеса. Одним словом, задача непростая. Но как быть, если проект нужно реализовывать в сжатые сроки, а результат был нужен буквально “вчера”?

В этом случае можно привлечь аутсорсингового подрядчика. Услуги ИТ-аутсорсинга появились на рынке несколько десятилетий назад. Принцип “отдай все, что не является твоим core-бизнесом”, успешно применяется по сей день. Вместе с тем, классический ИТ-аутсорсинг влечет за собой целый шлейф возможных рисков, таких как невысокая компетентность сотрудников подрядчика, недостаточный опыт работы заказчика с ИТ-аутсорсером, а также сложность управления реализацией выполняемых задач. Особенно важен поэтапный контроль, который позволяет вовремя внести коррективы в проект, направить его в нужное русло, расставить правильные приоритеты для всех задач и т.д.

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

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

Гарантом отношений между заказчиком и ИТ-партнером служит соглашение об уровне сервиса (SLA), которое сопровождает большинство договоров о предоставлении услуг, о реализации какого-либо проекта и т.д. Как правило, SLA регламентирует параметры качественной реализации проекта в его конечной точке, то есть то, что в итоге должен получить заказчик. Так было до пандемии, но сейчас мир стремительно меняется. Удаленная работа, трансграничные команды, возросшая текучесть кадров, широкое распространение гибких методологий управления проектами (Agile, Scrum, Kanban), а также сокращение сроков реализации задач постепенно меняют и подходы к SLA. Речь идет о том, что соглашение об уровне сервиса должно регламентировать не только заключительные или промежуточные этапы реализации проекта, но и регулярные шаги в его выполнении. Например, это могут быть определенные отрезки времени, за которые должен быть выполнен заранее намеченный перечень задач, для каждой из которых назначается ответственный (постановщик задачи), один или несколько исполнителей, а также наблюдающие. Таким образом, вся работа по проекту разбивается на микроэтапы (спринты); каждый из них занимает пять рабочих дней. По окончании этого периода проводится «Демо», где презентуется результат, и заказчик принимает работу. При этом оценивается не только сам факт выполнения задачи, но и соответствие сделанной работы соглашению об уровне сервиса. Параллельно с этим, каждую неделю проводится планирование, в рамках которого определяются временные затраты и конкретные задачи на следующий спринт. В итоге, заказчик и исполнитель организуют надежный коммуникационный канал. Фактически, для клиента такое общение выглядит так же, как если бы он взаимодействовал со своими же штатными специалистами, которые находятся в другом офисе и, по необходимости, приезжают для личных встреч.

Чтобы такой подход к SLA стал возможен, необходимо максимально глубокое вовлечение внешней команды подрядчика в проект заказчика. На этапе постановки задачи формируется стратегия реализации будущего проекта, обозначаются ключевые бизнес-процессы, зоны ответственности как подрядчика, так и клиента. В результате аутсорсер должен сформировать полноценную продуктовую команду, включающую в себя всех необходимых специалистов – от продакт-менеджеров, бизнес- и системных аналитиков до бэк- и фронт разработчиков, креативных дизайнеров, QA инженеров и тестировщиков. Такой подход называется “Внешний проектный ИТ-департамент”. Его можно и нужно использовать не только для реализации разовых проектов, таких как разработка или внедрение информационной системы, но и для полноценной поддержки ИТ предприятия, в том числе и цифровизации бизнес- и производственных процессов. Именно в случае грамотно построенного “Внешнего проектного ИТ-департамента”, в качестве работы которого заинтересованы обе стороны, поэтапный SLA и гибкий подход к решению задач будет максимально эффективными. Хроническое несоблюдение сроков, качество, не соответствующее ожиданиям и выход за рамки бюджета останутся в прошлом.

 

 

Похожие статьи