Как работать с заказчиком, когда он хочет невозможного: 5 историй

В мире IT каждый проект — это отдельная история с уникальными вызовами, неожиданными просьбами и иногда комичными ситуациями. Заказчики приходят с запросами, которые порой противоречат здравому смыслу, а специалисты делают все возможное, чтобы найти решения.

Расскажу про пять реальных случаев из практики, которые не только заставляют улыбнуться, но и дают ценные уроки о том, как не стоит подходить к реализации IT-проектов.

История первая: «Скупой платит дважды»

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

Мы долго убеждали его, что это плохая идея, приводили примеры компаний, столкнувшихся с катастрофическими последствиями из-за экономии на критических элементах IT-инфраструктуры. Но заказчик стоял на своем. Результат? Через полгода после завершения работ система «упала» вместе с платформой виртуализации, на которой она работала.

Заказчик вернулся с просьбой переделать все в рамках гарантийной поддержки. Увы, такие доработки в гарантию не входят. Пришлось закладывать новый бюджет, перерабатывать проект и тратить дополнительные ресурсы. Итог? Проект обошелся вдвое дороже, чем мог бы с самого начала.

Экономия на важных компонентах всегда бьет по бюджету. Проектирование решения — это не просто этап переговоров, а шанс предотвратить подобные ситуации. Учитесь аргументировать и объяснять, почему «дешево» и «надежно» редко идут рука об руку.

История вторая: «Хотим облако, но без интернета»

Один из заказчиков заявил, что хочет перейти на облачную инфраструктуру, но с важным условием — без доступа в интернет. В первый момент я был озадачен: как можно использовать публичное облако без доступа?

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

Важно не только то, что хотят заказчики, но и как они это формулируют. В моей практике не раз встречались ситуации, когда неточности в ТЗ превращали технически выполнимый проект в головоломку. Навыки коммуникации и правильное документирование требований — залог успеха.

История третья: «Сделайте как в Microsoft!»

На первой встрече заказчик с энтузиазмом заявил: «Мы хотим систему, как у Microsoft!» Но на этапе оценки выяснилось: бюджет в 100 раз меньше, а серверная комната — всего 5 квадратных метров.

Объяснять такие вещи — отдельное искусство. Важно не задеть клиента, но при этом донести реальность. После долгого обсуждения заказчик вздохнул и сказал: «Ну тогда сделайте хоть как-нибудь». Эта история напоминает мне о необходимости не только гибкости, но и умения управлять ожиданиями заказчика.

Ожидания должны быть реалистичными и соразмерными ресурсам. Умение разбирать сложные проекты и адаптировать их под реальные возможности заказчика — ключевая компетенция для IT-экспертов. В таких ситуациях я всегда использую аналоги и сравнения, чтобы заказчик мог лучше понять ограничения.

История четвертая: «Срочно меняем концепцию за день до подписания!»

После двух месяцев согласования технического задания заказчик внезапно позвонил накануне подписания договора: «Забудьте все, теперь мы переходим на гибридную инфраструктуру. Перепишите ТЗ до завтра».

Причина? «Коллега сказал, что это модно». В результате проект пришлось пересматривать, затягивать сроки и увеличивать бюджет. Этот случай научил меня, что важно закладывать в проект соглашения о фиксировании требований на определенном этапе, иначе изменения могут бесконечно откладывать завершение работ.

Следовать трендам — это хорошо, но важно тщательно обдумывать последствия изменений. IT-тренды быстро устаревают, и важно ориентироваться на долгосрочные цели, а не на краткосрочную моду.

История пятая: «Быстро и дешево, но с запасом на 10 лет!»

Заказчик заявил, что ему нужно бюджетное решение. Через неделю добавил: «Система должна быть масштабируемой и работать без модернизации 10 лет».

На уточняющий вопрос, как это совместить, он ответил: «Вы же IT-специалисты, придумайте!» Несмотря на весь профессионализм команды, выполнить эти запросы в полной мере оказалось невозможно. Мы предложили гибридное решение, которое соответствовало бюджету и давало возможность масштабирования через несколько лет, но заказчик с трудом принял компромисс.

Сделать «дешево, надежно и надолго» — мечта, которая редко становится реальностью. Здесь я вспоминаю важность работы с ожиданиями. Как эксперт, я всегда оцениваю проект с точки зрения эволюционного подхода, предлагая сначала решение, которое удовлетворяет текущие потребности, с возможностью масштабирования в будущем.

Вывод

Эти истории — не просто забавные случаи, но и ценные уроки для всех участников IT-проектов:

  • Заказчикам важно понимать ограничения и возможности технологий.
  • Специалистам — проявлять терпение, креативность и умение объяснять даже самые очевидные вещи.

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

Читайте также:

Расскажите коллегам:
Комментарии
Независимый директор, Москва

С большим удовольствием прочитал эту "повесть без конца"  Особенно вдохновляюще читалась часть про: 

На первой встрече заказчик с энтузиазмом заявил: «Мы хотим систему, как у Microsoft!» Но на этапе оценки выяснилось: бюджет в 100 раз меньше, а серверная комната — всего 5 квадратных метров.

Совет такой:

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

 

Технический директор, Москва
Александр Сейнов пишет:

С большим удовольствием прочитал эту "повесть без конца"  Особенно вдохновляюще читалась часть про: 

На первой встрече заказчик с энтузиазмом заявил: «Мы хотим систему, как у Microsoft!» Но на этапе оценки выяснилось: бюджет в 100 раз меньше, а серверная комната — всего 5 квадратных метров.

Совет такой:

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

 

Спасибо за совет! У нас в компании эта методика активно используется на уровне продаж, но, признаюсь, иногда случаются и промахи. 

Директор по маркетингу, Санкт-Петербург

Мы вам сделаем 1) быстро, 2) качественно, 3) недорого. Выберите любые 2 составляющие ))

Аналитик, Ульяновск

«Вы же IT-специалисты, придумайте!»

Мы же IT-специалисты, и мы  придумываем !

Researcher, Москва

На самом деле проблема в том, что IT разработчки в большинстве своём крайне не ориентированы на клиента, плохо считают чужие деньги, крайне непукнтуальны по срокам (Agile -- вот это вот всё). Часто решают какие-то свои задачи, а не те, которые нужно решить клиенту. 

А назвать клинта чудаком на букву М много ума не надо.

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

Не надо убеждать клиента, что у него плохие идеи, и он недостаточно хорош для вашей IT компании. Надо продавать. А чтобы продать, надо говорить с клиентом на его языке или по меньшей мере понимать его. А не стебаться над ним(и) в публичном пространстве.

И добавлю -- многие (не все, конечно) IT разрабы, с которыми я сталкивался -- обычные разводилы вроде докторов, которые прописывают и подсаживают клиентов на дорогие лекарства (или лечение), когда ту же болячку можно вылечить аналогичным дженериком в разы дешевле без всяких рюш и свистелок, бессовестно пользуясь его доверчивостью.

Поставил бы дизлайк.

Инженер-конструктор, Санкт-Петербург

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

Есть четкие критерии когда необходимо применять отказоустойчивую архитектуру, для 2 тыс. пользователей это необходимо, а, например, для 1 тыс. пользователей не обязательно?

А что было причиной того, что через полгода после завершения работ система «упала»?

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Эрнст Мальцев
  На это просто напрашивается цитата из повести Хольма ван Зайчика "Дело жадного варвара" (комм...
Все дискуссии
HR-новости
Исследование: что доводит сотрудников до выгорания

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

Большинство россиян считают работу в креативной индустрии привлекательной

76% хотели бы попробовать себя в роли креативного продюсера, при этом у половины из них нет четкого представления, чем занимается этот специалист.

Средние зарплаты в отрасли туризма и гостеприимства выросли на 52% за год

Рост внутреннего туризма стимулирует спрос на кадры, а конкуренция за них меняет подходы работодателей.