Как не стоит экономить на ИТ-проекте

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

Мы подготовили несколько примеров того, как НЕ стоит сокращать расходы на разработку ИТ-проекта (все они основаны на нашем личном опыте).

О том, как можно сократить расходы, читайте здесь

Убрать тестирование

Тестирование, возможно, является самым важным этапом в разработке ИТ-проекта. Без него любая система, даже с самым идеальным кодом, не сможет долго работать.

Мы сталкивались с ситуациями, когда заказчики просили сократить объём тестирования, чтобы сэкономить ресурсы. Однако результат был негативным: из-за нехватки времени тестировщики не успевали находить некоторые баги, и те попадали к заказчику, а иногда — и к конечным пользователям. Поэтому мы настоятельно не рекомендуем экономить на тестировании.

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

Больше о нашем подходе к тестированию можно узнать здесь

Убрать менеджера проекта

То, что проект может обойтись без менеджера проекта, — распространённое заблуждение.

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

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

Вместо этого можно заменить менеджера проекта на специалиста с опытом управления ИТ-проектами. Подробнее об этом — здесь

Сократить расходы на самих разработчиков

Сократить расходы на разработчиков можно двумя способами: нанять более дешёвых специалистов или заставить текущую команду работать быстрее.

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

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

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

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

Подводим итоги

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

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

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

Забронируйте звонок или напишите нам