Кто виноват и что делать?
Эти 2 вопроса из классики очень часто возникают в неудачных проектах.
Виноваты бывают и айтишники, и сам заказчик.
Поэтому сегодня поговорим, что делать заказчику, чтобы не завалить проект со своей стороны. А как выбрать “хороших” айтишников мы подготовим отдельный материал.
Давайте все рассмотрим на анонимном примере
Дистрибутор оборудования "Супермашины" решил разработать партнерский портал для упрощения взаимодействия с дистрибьюторами и улучшения логистических процессов. Директор "Супермашины", Александр, нанял IT-компанию "TechSolve" для реализации этого амбициозного проекта.
Ошибка 1: Недооценка важности технических требований
Александр представлял портал как веб-сайт со списком товаров. Что-то вроде интернет-магазина. Он не предоставил более подробных требований, считая, что разработчикам будет достаточно общего описания.
Это привело к тому, что команда "TechSolve" подготовили техническое задание на основании скудной информации. А директор Александр подписал его, не читая.
Мина была заложена уже на этом этапе и дальше ситуация только усугублялась.
Ошибка 2: Нереалистичные сроки и ожидания
Александр требовал запустить портал в течение двух месяцев для участия в крупной отраслевой выставке. Это создавало дополнительное давление на команду "TechSolve", что негативно сказывалось на детализации и тестировании портала.
Ошибка 3: Недостаточное вовлечение в процесс
После передачи задания команде разработчиков, Александр решила, что его участие в проекте больше не требуется. Он не участвовал в обсуждениях и не отвечал на вопросы команды, что приводило к несоответствиям и недопониманию его первоначального видения.
Александр столкнется с уже готовым результатам и будет сравнивать его с нечеткой первоначальной картинкой в голове.
Ошибка 4: Непонимание специфики IT-сектора
Александр не обладал минимальными знаниями в области IT, что затрудняло его коммуникацию с "TechSolve". Он не могла адекватно оценить сложности, связанные с интеграцией различных систем и безопасностью данных.
Ошибка 5: Игнорирование обратной связи от IT-специалистов
Когда разработчики пытались обсудить проблемы и предложить альтернативные решения, Александр игнорировал их предложения, настаивая на своем видении проекта без учета первоначально оговоренного объема работ, технических ограничений, сроков, бюджета и прочей проектной “ерунды”.
Заключение
К моменту запуска Партнерский Портал столкнулся с рядом проблем: недостаточной функциональностью, проблемами безопасности и пользовательским интерфейсом, не соответствующим ожиданиям дистрибьюторов.
Этот проект является ярким примером того, как важно для предпринимателей глубоко погружаться в детали проекта, адекватно оценивать его сложность и активно сотрудничать с IT-командами для достижения лучших результатов.