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