Основные функции — бесплатно и навсегда
Сервис для совещаний
и онлайн-встреч
- До 30 участников на встрече
- Видеозвонки до 60 минут
- Шумоподавление и замена фона
- Стабильная связь
- Техподдержка 24/7
- ИИ-функции
Ничего не найдено. Попробуйте еще
Почему в ИТ-проектах срываются сроки: 5 ошибок в коммуникации заказчика и команды разработки
-
АвторЕвгений ГарбарHR-эксперт и сооснователь компании «МояКоманда» -
ЭкспертАнастасия ШевчукПродуктовый маркетолог унифицированных коммуникаций МТС Линк
- Стабильная связь
- Техподдержка 24/7
- ИИ-функции
Когда сроки проекта сдвигаются, в первую очередь обычно винят технические проблемы: сложную архитектуру, нехватку разработчиков, неожиданные баги. При разборе таких проектов часто обнаруживаются расхождения в требованиях и договорённостях, которые стороны не заметили вовремя. По отдельности такие недопонимания кажутся незначительными, но постепенно накапливаются и в какой-то момент превращаются в «мы не успеваем».
Вместе с HR-экспертом и сооснователем компании «МояКоманда» Евгением Гарбар и продуктовым маркетологом унифицированных коммуникаций МТС Линк Анастасией Шевчук разобрали пять типичных ситуаций, где теряется время, и выяснили, как этого избежать.
Ошибка 1. Требования сформулированы «по смыслу», а не по результату
Фраза «нужен удобный личный кабинет» для заказчика означает одно, для аналитика другое, а для разработчика третье. Каждый понимает «удобство» по-своему, и расхождение обнаруживается во время демонстрации результата, когда переделывать уже дорого.
Как это выглядит на практике
Заказчик просит «простую отчётность». Команда делает три стандартных отчёта с выгрузкой в Excel. На приёмке выясняется, что руководителю нужен дашборд с фильтрами по регионам и обновлением в реальном времени. Две недели работы уходят на переделку, дедлайн сдвигается.
Что делать
- описывать требования через проверяемый результат: кто пользователь, какое действие совершает, как понять, что задача выполнена
- для каждой задачи формулировать критерии приёмки: например, «менеджер за три клика находит заказ по номеру», а не «поиск работает удобно»
- показывать промежуточный результат рано, пусть даже в виде прототипа или макета, чтобы расхождения вскрывались на старте
- фиксировать договорённости письменно сразу после обсуждения, пока детали свежи
Ошибка 2. Нет единого «владельца решений» на стороне заказчика
Разработчики получают правки от маркетинга, юристов, руководителя направления и службы безопасности. Часть правок противоречит друг другу. Команда вынуждена разбирать внутренние споры заказчика, а время при этом идёт.
Как это выглядит на практике
Маркетинг просит убрать с главной страницы форму заявки, потому что она «перегружает экран». Через три дня отдел продаж требует вернуть её на видное место. Разработчики переделывают один и тот же блок трижды. Каждая отмена предыдущей правки отнимает ещё день.
Что делать
- назначить одного человека, который принимает решения и отвечает за приоритеты
- договориться, что остальные участники со стороны заказчика передают пожелания только через него
- заранее определить, какие решения он принимает единолично, а какие требуют согласования, и в какие сроки это согласование происходит
Срыв сроков часто начинается задолго до разработки, на этапе, когда не определено, кто в команде за что отвечает. В «МояКоманда» мы видим это при подборе специалистов: сильный разработчик, попавший в проект без понятных ролей и точки принятия решений, теряет темп уже в первые недели. С точки зрения HR это ещё и риск выгорания: люди переделывают одно и то же и перестают видеть смысл в своей работе. Поэтому я советую в начале проекта прописать не только роли, но и зоны ответственности за принятие решений: кто утверждает, кто консультирует, кто просто информируется. Это занимает час, а экономит недели.
Роли и зоны ответственности удобно зафиксировать в небольшой матрице ролей и показать её всей команде, включая новичков. В ней прописано, к кому идти с вопросом и кто принимает решение. Такая матрица помогает и при ротации: если в проект приходит новый человек, ему не нужно выяснять неформальные правила методом проб и ошибок.
Чтобы матрица не превратилась в файл, который через месяц никто не открывает, её стоит хранить там же, где находится остальная информация о команде. Если в компании есть HRM-система, роли можно закрепить в оргструктуре и профилях сотрудников, а знакомство с матрицей включить в план адаптации. Например, в «МояКоманда» новичку, который приходит в проект, назначают наставника, и одной из первых задач может быть обсуждение ролей и зон ответственности. Тогда правила проекта человек узнает в первый день, а во время первых конфликтов.
Ошибка 3. О ходе работы сообщают редко, а плохие новости откладывают
Команда видит риск, но надеется наверстать отставание и молчит до следующего отчёта. Заказчик узнаёт о проблеме, когда исправить её уже нельзя без переноса сроков. Парадокс в том, что откладывание плохих новостей чаще всего вызвано не недобросовестностью, а желанием не расстраивать заказчика и избежать резкой критики.
Как это выглядит на практике
Интеграция со сторонним сервисом задерживается из-за проблем на стороне партнёра. Разработчик в первую неделю понимает, что срок под угрозой, но рассчитывает решить вопрос сам. Заказчик узнаёт об этом за три дня до релиза. Если бы он знал на неделю раньше, можно было бы подключить второго специалиста или перенести часть функций на следующий этап.
Что делать
- договориться о коротком регулярном ритме: еженедельная синхронизация и краткий список рисков с пометками «что это, чем грозит, что предлагаем»
- использовать простую светофорную систему статусов: зелёный, жёлтый, красный, где жёлтый значит «есть риск, нужно обсудить»
- сделать так, чтобы создать атмосферу, в которой сотрудники могут открыто сообщать о проблемах: если за плохую новость ругают, о следующей узнают ещё позже
- отделять разговор о проблеме от разговора о виноватых: сначала решение, потом разбор причин
Ошибка 4. Решения принимаются на встречах, но не фиксируются
На созвоне все согласились, но через две недели каждый помнит договорённость по-своему. Те, кто не присутствовал, вообще не в курсе. Типичная фраза в таком проекте: «но мы же это обсуждали».
Как это выглядит на практике
На встрече решили, что экспорт данных будет только в формате csv. Заказчик помнит, что обсуждали ещё и pdf . Разработчик, который был в отпуске, планирует разработку полноценного отчёта с вёрсткой. Выясняется всё на приёмке.
Что делать
- после каждой встречи отправлять итоги: что решили, кто отвечает, к какому сроку
- записывать ключевые созвоны, чтобы к записям можно было вернуться, а участникам, пропустившим встречи, не приходилось выяснять детали в переписке
- рисовать схемы процессов и визуализировать их логику во время обсуждения, а не после: визуализация сразу показывает, что стороны понимают по-разному
- хранить итоги там, где их найдёт любой участник, а не в личных заметках
Чтобы договорённости не потерялись после созвона, в МТС Линк можно сохранить запись встречи, материалы доски и переписку в чате. Тот, кто пропустил созвон, посмотрит запись, а не будет выяснять детали у коллег. Особенно это заметно в проектах, где часть команды работает удалённо или в разных часовых поясах.
Ошибка 5. Коммуникация распадается на десять каналов
Часть задач обсуждается в мессенджере, часть – в почте, часть – на звонках, часть – в трекере. Целостной картины нет, и ключевое решение теряется среди сотен сообщений в чате. Новый участник не понимает, где искать актуальную информацию, и тратит несколько дней, чтобы разобраться в проекте.
Как это выглядит на практике
Аналитик согласовал изменение логики в личной переписке с заказчиком. Тестировщик об этом не знает и создаёт отчёт об ошибке из-за поведения системы, которое считает неправильным. Разработчик пытается воспроизвести проблему и тратит на это полдня.
Что делать
- определить правила: где ставятся задачи, где обсуждаются вопросы, где проводятся созвоны и как итоги попадают в общее хранилище
- договориться, что решение, принятое в личной переписке, дублируется в общем канале
- сократить число каналов до минимально необходимого: чем их меньше, тем ниже риск потерять важное
- при подключении нового человека давать ему «карту коммуникаций»: куда писать, где смотреть статусы, где лежат записи встреч и документы
В распределённых командах мы видим одну и ту же картину: чем больше участников проекта и чем дальше друг от друга они находятся, тем выше цена неформальных договорённостей. Когда встречи, чат и материалы собраны в одной среде, например на платформе МТС Линк, проще сохранить контекст: участник подключается к проекту и сразу видит историю обсуждений и записи прошлых встреч. Это снижает порог входа для новых людей и сокращает число уточнений.
Что общего у всех пяти ошибок
Все пять ошибок объединяет одно: информация существует, но не доходит до нужного человека в нужный момент или понимается по-разному. Поэтому исправляется это не дорогими решениями, а договорённостями и дисциплиной. Команды, которые сдают проекты в срок, редко отличаются своей квалификацией от остальных. Они отличаются тем, что заранее договариваются, как будут разговаривать друг с другом.
Чек-лист для старта проекта
☐ Требования описаны через результат, у каждой задачи есть критерии приёмки
☐ Договорённости фиксируются письменно в день обсуждения
☐ Есть один ответственный за решения со стороны заказчика
☐ Роли и зоны принятия решений прописаны и известны всей команде
☐ Установлен ритм статусов, и о рисках можно говорить без страха
☐ Ключевые встречи записываются, итоги рассылаются всем участникам
☐ Каналы коммуникации определены и ограничены, новичку выдаётся «карта»
Эти пункты не требуют бюджета, только дисциплины. Проверять соблюдение этих правил стоит на протяжении всего проекта. Иначе даже согласованные на старте процессы постепенно перестают работать.
Другие статьи про работу в команде
Мечтай, планируй, критикуй: как метод Диснея помогает принимать взвешенные решения в бизнесе
Не просто общение: 5 навыков, необходимых для продуктивного взаимодействия в команде
Как преодолеть сопротивление команды к переменам в рабочих процессах: инструкции и лайфхаки
Подпишитесь на рассылку МТС Линк Медиа
Каждую пятницу присылаем самые интересные статьи об эффективной работе и коммуникациях в онлайне на почту