Несколько способов сократить затраты на разработку: часть 1

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

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

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

Любая оптимизация расходов должна начинаться с понимания структуры бюджета. Я обычно предпочитаю начинать анализ с наиболее значительных статей затрат, постепенно двигаясь к менее крупным. Экономия 10% от 1 млн рублей будет больше, чем 50% от 100 тыс. рублей.

Рассмотрим несколько примеров.

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

В первой части обсудим варианты оптимизации фонда оплаты труда, во второй — все остальное.

Фонд оплаты труда

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

Набирать команду минимально необходимой квалификации

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

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

Плюсы:

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

Минусы:

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

Переводить разработки в регионы

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

Тем не менее в рамках России в силу неравномерного экономического развития регионов еще остается большое пространство для маневра. Например, даже между Москвой и Санкт-Петербургом разница в медианной зарплате разработчика составляет около 20%. 

Плюсы:

• потенциальная экономия до 40% от фонда оплаты труда;
• открываются дополнительные рынки для поиска сотрудников.

Минусы:

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

Аутсорсинг

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

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

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

Мы в этом вопросе придерживаемся следующих принципов:

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

Плюсы:

• неплохая экономия при небольших или нестабильных объемах работы;
• возможное увеличение качества продукции за счет реализации преимуществ от разделения труда.

Минусы:

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

Оптимизация состава команды

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

Мне приходилось наблюдать команду, в которой было три аналитика, два тестировщика, представитель заказчика, Scrum-мастер и всего один middle-разработчик! Все было красиво и по Scrum, но только не было непосредственно работы.

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

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

Плюсы:

• потенциально значительная экономия бюджета;
• повышение производительности команды.

Минусы:

• нет.

Выбор правильной методологии разработки

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

Плюсы:

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

Минусы:

• не всегда удается подобрать правильные методологии с первого раза.

Обучение молодых специалистов

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

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

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

Плюсы:

• можно вырастить именно тех специалистов, какие нужны;
• экономия 10-20% от фонда оплаты труда.

Минусы:

• трудоемкий процесс;
• долго и без гарантий результата.

Фото на обложке: whiteMocca/shutterstock.com