Потому что в ИТ-проектах самая большая проблема — не баги, не сроки и даже не бюджет. Самая большая проблема — это когда вы с заказчиком используете одни и те же слова, но вкладываете в них разный смысл. И никто из вас этого не замечает, пока не становится слишком поздно.
Я работаю в этой сфере давно. Участвовал в десятках проектов, от простых настроек до сложных корпоративных систем. И сколько бы ни было встреч, сколько бы ни писали ТЗ, всё равно регулярно возникает ситуация: заказчик говорит «нужно быстро», а под этим понимает «вчера», а вы — «в течение недели». Или он говорит «интуитивный интерфейс», вы думаете про минимализм, а он про кнопки везде и подсказки поверх всего. Это не недобросовестность. Это просто нарушение закона тождества.
Закон этот прост: если вы назвали что-то «А», то дальше в разговоре это должно оставаться «А», а не превращаться в «Б» или «почти А». В логике это база. В коммуникации — спасение.
Хотите научиться договариваться с заказчиком и командой — приходите на курс «Школа проектного специалиста». Теория, реальные кейсы и тренировка soft skills. Подробнее на сайте.
На практике же всё иначе. Заказчик приходит с идеей. Вы её фиксируете. Потом начинается обсуждение, и с каждым раундом смысл смещается. Иногда потому что заказчик сам не до конца понимает, чего хочет. Иногда — потому что вы устали и начинаете подстраивать формулировки под то, что легче реализовать. А иногда просто из вежливости: не хочется спорить, не хочется уточнять в десятый раз, не хочется выглядеть занудой.
Но именно в этих «не хочется» и кроется провал.
Я помню один проект. Заказчик сказал: «Нам нужна система для учёта задач». Мы уточнили: какие задачи, кто их создаёт, как отслеживается прогресс. Он ответил: «Ну как в Трелло». Мы сделали в 1С упрощённую доску с колонками. Через две недели он пришёл и сказал: «А где отчёты по загрузке сотрудников? Где интеграция с календарём? Где уведомления по почте и в мессенджеры?» Оказалось, под «учётом задач» он понимал полноценную систему управления проектами с аналитикой, а не просто доску. Мы оба использовали одно и то же словосочетание. Но смысл был разный. И никто не проверил его в самом начале.
С тех пор я стал жёстче в уточнениях. Не из вредности. Просто научился: если не зафиксировать значение, то потеряешь время, нервы и доверие.
Как это делать? Просто. Не бойтесь переспрашивать, записывать, говорить: «Давайте убедимся, что мы понимаем это одинаково». Лучше потратить лишние 15 минут на уточнение, чем неделю на переделку.
Иногда помогает простой приём: переформулировать своими словами то, что сказал заказчик, и спросить: «Правильно ли я понял?» Это не показывает слабость. Наоборот — демонстрирует внимание и профессионализм.
Ещё один момент: письменная фиксация. Даже если вы всё обсудили устно, всё равно кратко запишите ключевые термины и договорённости. Не обязательно в виде официального документа. Достаточно короткого письма или сообщения в чате.
Это работает. Потому что устная речь легко искажается. А письменное — остаётся. И если через месяц возникнет спор, вы сможете просто сослаться на эту запись.
Конечно, бывают заказчики, которые сами путаются в своих желаниях. Они говорят одно сегодня, другое — завтра. Тут важно не винить их, а мягко возвращать к исходной точке: «Раньше вы говорили, что приоритет — скорость. Сейчас вы просите добавить функцию, которая замедлит работу. Давайте решим, что важнее».
Закон тождества — не про идеальную ясность. Он про честность в коммуникации. Про то, чтобы не делать вид, что всё понятно, когда это не так. Про уважение к собеседнику и к своему времени.
В ИТ-проектах много неопределённости. Но хотя бы в терминах и договорённостях можно и нужно быть точным. Потому что если «А» сегодня — это кнопка, а завтра — целый модуль, то проект обречён.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте