Истории из IT: когда заказчик хочет невозможного
Заказчики приходят с запросами, которые порой противоречат здравому смыслу, а специалисты делают всё возможное, чтобы найти решения. Делимся пятью реальными случаями из практики, которые не только заставляют улыбнуться, но и дают ценные уроки о том, как не стоит подходить к реализации IT-проектов.
История №1: «Скупой платит дважды»
Однажды заказчик решил внедрить почтовую систему для компании с более чем 2000 пользователей. Однако считал что отказоустойчивая архитектура для него избыточна. а ведь отказоустойчивость важна для непрерывной работы бизнеса и высокой доступности приложений и систем, независимо от неполадок. Без почты любой бизнес если не просто может остановится то явно будет испытывать сложности.
Мы долго убеждали его, что это плохая идея, приводили примеры компаний, столкнувшихся с катастрофическими последствиями из-за экономии на критических элементах IT-инфраструктуры. Но заказчик стоял на своём. Результат? Через полгода после завершения работ система «упала» вместе с платформой виртуализации на которой она работала.
Заказчик вернулся с просьбой переделать всё в рамках гарантийной поддержки. Увы, такие доработки в гарантию не входят. Пришлось закладывать новый бюджет, перерабатывать проект и тратить дополнительные ресурсы. Итог? Проект обошелся вдвое дороже, чем мог бы с самого начала.
Экономия на важных компонентах всегда бьет по бюджету. На основе собственного опыта могу сказать, что проектирование решения — это не просто этап переговоров, а шанс предотвратить подобные ситуации. Учитесь аргументировать и объяснять, почему «дёшево» и «надёжно» редко идут рука об руку.
История №2: «Хотим облако, но без интернета»
Один из заказчиков заявил, что хочет перейти на облачную инфраструктуру, но с важным условием — без доступа в интернет. В первый момент я и моя команда были озадачены: как можно использовать публичное облако без доступа?
После уточнений выяснилось, что речь идёт о локальном частном облаке. Однако формулировка в техническом задании осталась: «публичное облако». Переговоры грозили зайти в тупик, но чувство юмора и умение задавать правильные вопросы спасли ситуацию. Мы помогли заказчику пересмотреть формулировки, чтобы в дальнейшем избежать путаницы.
Важно не только то, что хотят заказчики, но и как они это формулируют. В моей практике не раз встречались ситуации, когда неточности в ТЗ превращали технически выполнимый проект в головоломку. Навыки коммуникации и правильное документирование требований — залог успеха.
История №3: «Сделайте как в Microsoft!»
На первой встрече заказчик с энтузиазмом заявил: «Мы хотим систему, как у Microsoft!» Но на этапе оценки выяснилось, что бюджет в 100 раз меньше, а серверная комната — всего 5 квадратных метров.
Объяснять такие вещи — отдельное искусство. Важно не задеть клиента, но при этом донести реальность. После долгого обсуждения клиент вздохнул и сказал: «Ну тогда сделайте хоть как-нибудь». Эта история напоминает мне о необходимости не только гибкости, но и умения управлять ожиданиями заказчика.
Ожидания должны быть реалистичными и соразмерными ресурсам. Умение разбирать сложные проекты и адаптировать их под реальные возможности заказчика — ключевая компетенция для IT-экспертов. В таких ситуациях я всегда использую аналоги и сравнения, чтобы заказчик мог лучше понять ограничения.
История №4: «Срочно меняем концепцию за день до подписания!»
После двух месяцев согласования технического задания заказчик внезапно позвонил накануне подписания договора: «Забудьте всё, теперь мы переходим на гибридную инфраструктуру. Перепишите ТЗ до завтра.»
Причина? «Коллега сказал, что это модно.» В результате проект пришлось пересматривать, затягивать сроки и увеличивать бюджет. Этот случай научил меня, что важно закладывать в проект соглашения о фиксировании требований на определённом этапе, иначе изменения могут бесконечно откладывать завершение работ.
Следовать трендам — это хорошо, но важно тщательно обдумывать последствия изменений. В своей практике я всегда стараюсь объяснять заказчикам, что IT-тренды быстро устаревают, и важно ориентироваться на долгосрочные цели, а не на краткосрочную моду.
История №5: «Срочно и дёшево... но с запасом на 10 лет!»
Заказчик заявил, что ему нужно бюджетное решение. Через неделю добавил: «Система должна быть масштабируемой и работать без модернизации 10 лет.»
На уточняющий вопрос, как это совместить, он ответил: «Вы же IT-специалисты, придумайте!» Несмотря на весь профессионализм команды, выполнить эти запросы в полной мере оказалось невозможно. Мы предложили гибридное решение, которое соответствовало бюджету и давало возможность масштабирования через несколько лет, но заказчик с трудом принял компромисс.
Сделать «дёшево, надёжно и надолго» — мечта, которая редко становится реальностью. Здесь я вспоминаю важность работы с ожиданиями. Как эксперт, я всегда оцениваю проект с точки зрения эволюционного подхода, предлагая сначала решение, которое удовлетворяет текущие потребности, с возможностью масштабирования в будущем.
Общий урок
Эти истории — не просто забавные случаи, но и ценные уроки для всех участников IT-проектов. Заказчикам важно понимать ограничения и возможности технологий, а специалистам — проявлять терпение, креативность и умение объяснять даже самые очевидные вещи.
Каждый проект — это вызов не только технической, но и коммуникативной экспертизы. Умение находить компромиссы, управлять ожиданиями и правильно документировать требования — ключевые навыки, которые помогают мне и моей команде успешно завершать проекты, даже когда всё кажется невозможным.
Какой самый необычный запрос заказчика был в вашей практике?