23 апреля Sympace провела мастермайнд о выборе ИТ-решений: участники обсудили, как снизить риск ошибки при сыром ТЗ
23 апреля компания Sympace провела мастермайнд-сессию с ИТ-руководителями. Одной из тем встречи стал выбор ИТ-решения в ситуации, когда техническое задание еще не готово к реализации: в нем есть общее пожелание, но не раскрыты бизнес-цель, ограничения, критерии результата и условия будущей эксплуатации.
Участники обсуждения отметили, что сырое ТЗ часто описывает не задачу, а желаемый продукт, модную технологию или первое представление заказчика о решении. В такой ситуации преждевременный переход к закупке или внедрению повышает риск ошибки: компания может выбрать формально подходящий инструмент, который не решит реальную проблему бизнеса.
Главный вывод встречи — начинать нужно не с поиска продукта, а с прояснения цели. ИТ-руководителю важно понять, зачем решение нужно сейчас, какой эффект ожидает бизнес, какие ограничения уже заданы и по каким признакам результат будет считаться успешным. Только после этого можно сравнивать готовые продукты, услуги, подрядчиков или рассматривать разработку с нуля.
В ходе мастермайнда участники зафиксировали 15 подходов к работе с неясным техническим заданием. Среди них:
- Использование чек-листов для интервью с заказчиком
- Проверка задачи через сроки
- Стоимость и содержание работ
- Поиск готовых решений и аналогов
- Демонстрации
- Пилоты
- MVP
- Отдельный исследовательский этап, если в проекте много неизвестного
Отдельное внимание уделили так называемым «якорям» проекта. Это параметры, которые нельзя свободно менять: срок, бюджет, обязательная технология, состав работ или нормативное требование. Если такой якорь определен заранее, команде проще обсуждать компромиссы. Например, при фиксированной дате запуска может потребоваться изменить объем работ, состав команды, стоимость или уровень результата.
Участники также обсудили роль финансово-экономического обоснования. Для руководителей бизнеса важны не только технические характеристики решения, но и ответы на управленческие вопросы: какую проблему снимает проект, почему его нужно запускать сейчас, сколько он будет стоить и какие риски останутся после внедрения. Такая логика помогает отделять действительно нужные инициативы от идей, которые выглядят современно, но не дают понятного эффекта.
Еще один практический инструмент — пилот или MVP. Если команда не уверена, что решение сработает в реальном процессе, его стоит проверить на малом масштабе до крупной закупки. Пилот позволяет увидеть, приносит ли идея пользу, где возникают ограничения и стоит ли переходить к промышленному внедрению.
В обсуждении также прозвучала мысль, что иногда нужно менять не только решение, но и саму постановку задачи. Бизнес может просить внедрить крупную систему, хотя на самом деле ему нужны прозрачность, управляемость или автоматизация отдельного процесса. В этом случае работа с ТЗ может привести не к уточнению исходной заявки, а к выбору другого продукта, другого подхода или меньшего объема работ.
По итогам встречи участники пришли к выводу, что сырое техническое задание нельзя принимать как готовую основу для закупки или внедрения. Его нужно довести до состояния, где понятны цель, ограничения, ответственность, сроки, стоимость и критерии приемки. Такой подход помогает компаниям выбирать ИТ-решения не по формулировке заявки, а по тому, насколько они действительно решают задачу бизнеса.
Выбор редакции
Публикации, которые получают больше внимания и попадают в Сюжеты РБК
Рекомендации партнеров: