Как масштабировать бизнес по разработке программного обеспечения

21.01.2020


Благодаря тренду на цифровизацию количество и масштаб проектов по разработке программного обеспечения (ПО) будут расти. Командам разработчиков придется наращивать ресурсы. Какие нюансы стоит учесть, рассказывает Леонид Головатый, вице-президент ГК ЛАНИТ

 Леонид Головатый

Привлекайте подрядчиков

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

Выберите модель работы с подрядчиком

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

При оплате человеко-часов (модель Time & Material, T&M) надо очень четко и скрупулезно контролировать эффективность работы, иначе вы рискуете получить не очень хороший результат за большие деньги. Модель Fixed Price, когда оплачивается конкретный результат согласно техническому заданию, требует, чтобы у подрядчика был полный цикл разработки с управлением, архитектурой,8 аналитикой, разработкой и тестированием.

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

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

Меняя структуру свой команды, налаживайте коммуникации между сотрудниками

Масштабировать бизнес по разработке ПО можно двумя способами: 

1. увеличение количества однотипных проектов 

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

2. реализация крупных проектов 

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

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

Выращивайте профессионалов из стажеров

В Москве и Санкт-Петербурге все ИТ-специалисты с высокой квалификацией, как правило, хорошо устроены, привлечь их для работы в своем проекте сложно. Проблему дефицита кадров можно попробовать решить, открывая региональные центры разработки или обучая стажеров. Так, например, специалиста по функциональному тестированию ПО можно «воспитать» за год-полтора (интенсив от двух недель до месяца, затем работа в проекте на позиции стажера), а в разработке все сложнее: чтобы обучаться в реальном проекте, требуется более серьезная начальная подготовка и тщательный отбор. Аналитиков, как правило, сразу включают в работу на проекте и натаскивают в процессе — для руководителя группы это кропотливая работа, требующая максимального погружения в процесс. 

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

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

Считайте бюджет на протяжении всего проекта

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

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

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

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

Автор: Леонид Головатый
Источник: РБК Pro, 21.01.2020