Правда или миф: почему в разработке не все так быстро, как кажется

Клиент заказал разработку сайта.
Ожидание: все готово еще вчера.
Реальность: составление ТЗ, прототипирование, доработки, конфликты, снова доработки, и только потом результат.

Когда клиент заказывает разработку сайта, часто кажется, что всё должно быть просто и быстро: есть идея и иногда техническое задание. Осталось найти команду профессионалов и все ‒ дело в шляпе!

Но реальность разработки сложнее, чем кажется на первый взгляд.

Ситуация №1: «Хороший специалист сделает всё быстро»

У клиента складывается представление: вся команда состоит из опытных специалистов, которые все делают быстро.

Такое мнение может возникнуть, если:

был успешный опыт сотрудничества;
специалисты шли навстречу и выполняли задачи сверхурочно.

Тогда клиент начинает думать, что подобная скорость и гибкость ‒ это стандарт, и рассчитывает, что так будет всегда, вне зависимости от сложности или объема новых задач.

Кем на самом деле является «хороший» специалист? Это человек, который обладает:

Хард-скилами (техническими навыками), то есть:
- владеет языками программирования, фреймворками или инструментами (например, PHP, JavaScript, Figma) на высоком уровне;
- понимает принципы UX/UI (для дизайнеров) или чистого и поддерживаемого кода (для разработчиков);
- умеет работать с базами данных, API или интеграциями сложных систем.

Софт-скилами (гибкими навыками):
- умеет объяснять сложные технические вещи простыми словами;
- владеет тайм-менеджментом;
- замечает даже мелкие недочеты, которые могут стать критичными на проекте;
- адаптируется к изменениям или новым задачам.

Дополнительно упомянем об опыте работы. Обычно «хороший» специалист – это человек с 3-5+ годами опыта в своей области. Этот опыт помогает быстрее ориентироваться в проблемах, выбирать оптимальные решения и избегать типичных ошибок.

Почему опыт и навыки не гарантируют быстроты?

Хороший специалист ≠ сверхчеловек. Даже с идеальным набором навыков и многолетним опытом, скорость работы ограничивается следующими факторами:

Уровень сложности задачи.

Сложность зависит от функционала сайта. Например, интеграция с системой оплаты требует внимания к деталям и согласования с требованиями безопасности. На скрине ниже можно увидеть количество интеграций с внешними сервисами, которое мы произвели.

Скриншот части макета сайта, на котором отображено количество возможных интеграций.

Тесты и доработки.

Даже идеальный код или макет требует проверки. Иногда доработки занимают столько же времени, сколько и создание.

Например, бывают ситуации, когда клиент на этапе дизайна понимает, что того функционала, который он изначально требовал от команды, ‒ недостаточно. Тогда появляется необходимость в доработке. Это значит, что и другие сроки будут сдвинуты.

На скрине ниже отображены комментарии, в т. ч. те, что повлекут за собой изменения в дизайне.

Скриншот с figma, после созвона с заказчиком, в котором определили новые изменения.

Командная работа.

Успех на проекте зависит от командной работы, а не от отдельного спеца:: программисты ждут дизайнеров, тестировщики – программистов и т. д.

Выход из ситуации: перед запуском мы внутри команды, а затем с клиентом обсуждаем сроки. При этом мы обговариваем моменты, при которых период выполняемых работ может быть увеличен. Также мы дополнительно закладываем время на непредвиденные ситуации.

Если сделаем быстрее ‒ будет хорошо. Если сделаем в оговоренный срок, при этом предусмотрев все ЧС, ‒ тоже будет хорошо.

Ситуация № 2: «Уже есть готовые решения»

Некоторые клиенты считают, что разработка = конструктор, из которого собирают сайт. Отчасти это так: в интернете много шаблонов (от Bitrix или WordPress) , библиотек кода, плагинов, инструментов и т. д.

Поэтому создается впечатление, что вместо долгих этапов проектирования и программирования достаточно просто «вставить готовый модуль» ‒ и работа выполнена.

Но шаблон ≠ панацея, поскольку любой сайт ‒ индивидуальный заказ с разными целями. Кто-то хочет интернет-магазин, кто-то корпоративный сайт, кто-то хочет добавить / убрать / переместить и т. д. Шаблоны в данном случае «связывают» руки специалистам.

Например, клиент говорит: «возьмите шаблон (скрин ниже) и уберите / перенесите блок с преимуществами».

Мы этого сделать не можем, поскольку шаблон не подразумевает «смещения» блока, он един.

Это касается не только дизайна, но и функционала. Например, могут возникнуть трудности в реализации умного поиска, потому что в шаблоне его может не быть или он слишком простой: умнее его просто не сделать.

Также шаблоны нередко содержат обширный код, который сложно адаптировать. Внесение изменений может вызвать конфликты, например:

некорректное отображение смежных элементов;.
поломка адаптивного дизайна;
снижение производительности сайта и т. д.

Иногда изменения вносятся на уровне кода, который в будущем может быть перезаписан обновлением шаблона. Это требует создания «обходных путей» или отдельной системы контроля версии, что увеличивает время работы.

Каждое изменение в шаблоне может повлиять на весь сайт. Даже небольшая корректировка требует тестирования, чтобы убедиться: остальные части сайта работают корректно. Это особенно актуально для сложных шаблонов с большим количеством стилей и скриптов.

Вот и получается, что клиент хочет изменить несколько деталей в шаблоне, а это занимает еще больше времени, чем создание сайта с нуля.

Выход: чтобы эффективно решить эту ситуацию, нужно донести клиенту важность индивидуальной разработки. Для этого можно предложить следующие подходы:

Продемонстрировать ограничения на примерах (визуальные решения, функциональные решения).
Рассказать о дополнительных рисках шаблонного подхода.

Например, касательно безопасности: шаблоны часто содержат уязвимости, т.к. их код публичен и известен злоумышленникам. Или касательно бренда: шаблонный сайт может выглядеть менее профессионально, поскольку похожие решения могут использовать конкуренты.

Если клиент говорит о бюджете, объяснить, что долгосрочная экономия важнее краткосрочной. Если говорит о сроках, рассказать, как индивидуальное решение предотвращает будущие задержки, связанные с адаптацией шаблона.

Выходом является грамотная коммуникация, разъяснение плюсов и минусов каждого подхода и демонстрация, что индивидуальная разработка не только решает текущие задачи, но и закладывает основу для успешного развития проекта в будущем.

Ситуация № 3: «Проблемы решаются сами собой»

Мнение: команда со стороны подрядчика, которая работает над проектом, устраняет любые сложности «по умолчанию», без участия заказчика.

Реальность: отсутствие вовлеченности со стороны заказчика может привести к накоплению проблем, которые замедлят выполнение проекта.

Что означает выражение «без вовлеченности»?

Нет ответственного за контроль процессов. Проектный менеджер отсутствует или его роль формальна. Это приводит к хаотичному выполнению задач.

Например, кто-то со стороны клиента резко понял, что надо делать не эту задачу, а другую, и еще цвет поменять и кнопку переместить. Тогда команда хватается за все и сразу, в итоге никто ничего не успевает.

Отсутствуют договоренности и детальное описание в договоре.

Если в проекте не прописаны этапы, дедлайны, точки согласования и ответственные лица, то возникает «эффект снежного кома», когда одна нерешенная проблема тянет за собой другую.

Коммуникация организована некорректно.

Нет системы для взаимодействия между командой исполнителя и заказчиком. Например, переписка ведется в разных мессенджерах, задачи ставятся устно или через неформальные каналы, информация теряется.

Чтобы структурировать коммуникацию, мы используем Bitrix:

Подпись: Пример постановки задач на проекте.

Несколько ЛПР со стороны заказчика.

Например, заказчик прописал, что коммуникацию будет вести маркетолог компании. Маркетолог не всегда является ЛПР, и часто ему нужно согласовать действия с вышестоящим лицом. Так, процесс согласования увеличивает сроки.

Поэтому проектный менеджер со стороны Исполнителя и ЛПР со стороны Заказчика важен. Тогда подрядчик играет не в одни ворота, а в полноценный равный «футбол».

Советы по выстраиванию коммуникации между проектным менеджером и ЛПР заказчика

1. Установите четкие роли и распределите зону ответственности

Проектный менеджер (ПМ):
- Контролирует сроки и выполнение задач.
- Ведет документацию и согласует требования.
- Информирует о текущем статусе проекта.
- Прогнозирует возможные риски.
ЛПР заказчика:
- Принимает ключевые решения.
- Утверждает этапы работ.
- Предоставляет обратную связь.

2. Выберите удобные каналы связи

Продуктивная коммуникация требует структуры:

Основной инструмент для задач: обычно это Trello, Jira, в нашем случае Bitrix24 (фиксируются задачи, сроки, статусы).
Для общения: мессенджер.
Для встреч: Zoom, Google Meet.
Документы: Google Doc.

3. Регламентируйте коммуникацию

Создайте понятные правила:

Регулярные встречи:
- Еженедельные отчеты о проделанной работе за неделю и планы на следующую неделю.
- Дополнительные встречи при необходимости.
Оперативная связь:
- ПМ может задавать вопросы через мессенджер или почту в течение рабочего дня.
- ЛПР отвечает в оговоренные сроки (например, в течение 24 часов)

4. Фиксируйте договоренности

После каждой встречи или обсуждения фиксируйте итоги:

Протокол встречи: что обсудили, что решили, кто за что отвечает, сроки.
Письменное подтверждение: отправляйте краткое резюме в мессенджере или письмом, чтобы исключить недоразумения.

Дополнительные факторы, которые могут задерживать проект

Размытое техническое задание (ТЗ). То есть в документе отсутствуют важные детали или указания по проекту. Из-за этого команда исполнителя может интерпретировать задачи по-своему. Это приводит к несоответствию ожиданий заказчика и конечного результата.

Пример из практики:

Формулировка от заказчика: «Создать современный сайт с удобной навигацией».
Вопросы исполнителя: Что подразумевается под «современным»? Какие элементы навигации необходимы? Есть ли примеры сайтов, которые нравятся?

Как нужно: «Создать сайт в минималистичном стиле с меню в шапке и всплывающим боковым меню для мобильных устройств. Пример сайта: беббебе.com».

Изменения в ходе работы.

Иногда клиент хочет изменить концепцию или добавить новые задачи. Это требует пересмотра сроков.

Чтобы избежать путаницы, задержек и конфликтов, важно иметь четкие регламенты, которые помогут эффективно управлять изменениями, например:

Заранее оговаривать условия, при которых команда берется за срочные или новые задачи.
Прописывать условия в договоре.
Приоритизировать задачи.
Формировать дополнительное соглашение, в котором описана задача, сроки и бюджеты на задачу.

Технические сложности.

Интеграция с внешними сервисами или создание сложной функциональности может занять больше времени, чем планировалось.

Сложности с документацией: Не всегда документы внешнего сервиса актуальны. Это может привести к трудности в интеграции, т.к. необходимо разбираться в новых функциях или ограничениях.
Сбои в работе сервисов: Внешние сервисы могут быть временно недоступны или работать нестабильно.
Процесс тестирования: Каждую интеграцию нужно тщательно тестировать, чтобы убедиться, что все работает правильно.

Как мы предотвращаем задержки

Тщательное планирование.

Каждый проект начинается с детального анализа и составления плана. Мы разбиваем задачи на этапы и устанавливаем реальные сроки.

Скриншот календарного графика проекта с ценами и графиком этапов, который составляется на этапе планирования.

Прозрачная коммуникация.

Регулярные встречи с клиентом позволяют нам обсуждать прогресс, согласовывать изменения и вовремя решать проблемы. Например, при завершении этапа дизайна мы организуем встречу с презентацией для клиента.

Также регулярные отчеты о проделанной работе помогают держать руку на пульсе, и не теряться во времени.

Гибкость в работе.

Мы учитываем, что изменения неизбежны, и стараемся внедрять их без ущерба для сроков. Предотвратить задержку помогает закладывание дополнительного времени на проекте.

Тестирование на каждом этапе.

Это помогает выявить ошибки на ранних стадиях и избежать доработок в последний момент.

Оптимизация процессов.

Мы используем современные инструменты и практики, например:

Bitrix24. Он является и трекером задач, и канбан-доской, а также позволяет визуализировать рабочие процессы и управлять приоритетами.
Scrum. Эта методология управления проектами активно используются нами для гибкой разработки. Scrum помогает команде быстро реагировать на изменения, улучшать коммуникацию и поставлять результат на каждом спринте. Scrum предполагает использование коротких итераций (спринтов), а также ежедневных встреч для синхронизации действий команды.
Waterfall (Каскадная модель) предполагает выполнение работы поэтапно, где каждый этап зависит от завершения предыдущего. Хотя этот подход не такой гибкий, он полезен в проектах с четкими требованиями и сроками.
Телеграм-чаты, Zoom / Google Meet и др.

Иными словами, чтобы минимизировать срыв сроков, нужно:

сформировать план работ, включая время на непредвиденные доработки;
выстроить грамотную коммуникацию с указанием зон ответственности с каждой стороны;
внедрить этапы тестирования;
научиться оптимизировать процессы.

ссылка на оригинал статьи https://habr.com/ru/articles/865306/