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