Как не стоит экономить на ИТ-проекте
Когда на разработку не хватает средств или хочется сэкономить, заказчики часто выбирают не те пути. Такие решения не только не помогают сэкономить, но и могут привести к потерям — денег, времени и нервов.
Мы подготовили несколько примеров того, как НЕ стоит сокращать расходы на разработку ИТ-проекта (все они основаны на нашем личном опыте).
О том, как можно сократить расходы, читайте здесь
Убрать тестирование
Тестирование, возможно, является самым важным этапом в разработке ИТ-проекта. Без него любая система, даже с самым идеальным кодом, не сможет долго работать.
Мы сталкивались с ситуациями, когда заказчики просили сократить объём тестирования, чтобы сэкономить ресурсы. Однако результат был негативным: из-за нехватки времени тестировщики не успевали находить некоторые баги, и те попадали к заказчику, а иногда — и к конечным пользователям. Поэтому мы настоятельно не рекомендуем экономить на тестировании.
Вместо этого можно пересмотреть подход к контролю качества на проекте: автоматизировать управление тест-кейсами и запуск тестов, внедрить автотесты и так далее.
Больше о нашем подходе к тестированию можно узнать здесь
Убрать менеджера проекта
То, что проект может обойтись без менеджера проекта, — распространённое заблуждение.
Менеджер проекта играет ключевую роль в координации и руководстве работой команды. Он отвечает за общение с клиентом, определение приоритетов и управление командой: распределение задач, контроль их выполнения и мотивацию разработчиков.
Если убрать менеджера проекта, другим участникам команды придётся взять на себя его обязанности — это потребует дополнительных ресурсов и может снизить эффективность работы.
Вместо этого можно заменить менеджера проекта на специалиста с опытом управления ИТ-проектами. Подробнее об этом — здесь
Сократить расходы на самих разработчиков
Сократить расходы на разработчиков можно двумя способами: нанять более дешёвых специалистов или заставить текущую команду работать быстрее.
Можно нанять более дешёвых разработчиков и надеяться на хороший результат. Однако отличить по-настоящему квалифицированных, но недорогих специалистов от посредственных бывает непросто. В большинстве случаев выбор самого дешёвого варианта приводит к плохому качеству. Исправлять такие ошибки в итоге обходится дороже, чем сразу разработать систему качественно с опытными, пусть и более дорогими разработчиками.
Требовать от команды работать быстрее тоже можно. То, что разработчик оценил в восемь часов, можно попросить сделать за два. Однако если команда согласится ускорить работу, это почти наверняка скажется на качестве. В итоге качество проекта постепенно упадёт до совершенно неудовлетворительного уровня.
Важно найти баланс между экономией и качеством. Кроме того, стоит учитывать культурные особенности и менталитет разработчиков, с которыми вы работаете. В некоторых культурах, например в арабской или китайской, торговаться может быть не только допустимым, но и полезным при переговорах. Однако в других, например в европейской, торг может вызвать дискомфорт и даже навредить деловым отношениям.
Чтобы сократить расходы, не прибегая к найму более дешёвых разработчиков, мы рекомендуем сосредоточиться на разработке только самых необходимых функций для запуска первой версии продукта.
Подводим итоги
На собственном опыте мы неоднократно сталкивались с каждым из описанных примеров. Важно сохранять баланс между снижением затрат и качеством работы.
И как мы уже рассказывали здесь, лучший способ сократить расходы на разработку – это оптимизировать процессы на проекте, а не жертвовать тестированием, грамотным менеджером проекта или опытными разработчиками.
Если вам нужна помощь в улучшении и настройке процессов — мы предлагаем бесплатный аудит системы. Найдем слабые места в проекте и подготовим отчёт с рекомендациями по решению проблем.
