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