Цифровой проект редко проваливается из-за технологий. Гораздо чаще причина в организации: задача поставлена расплывчато, решения принимаются в переписке и теряются, платформу выбрали по привычке, а половина команды узнаёт об изменениях последней. Мы делаем сайты и системы много лет, работаем распределённой командой и берём проекты на сопровождение после других подрядчиков. В этой статье собрали то, что определяет ход работы: процессы, инструменты, выбор платформы и устройство команды.
Из чего состоит работа над проектом
Порядок этапов почти не зависит от размера проекта — меняется только их глубина. Пропуск любого из них не экономит время, а переносит его на более поздний и более дорогой этап.
- Разбор задачи. Что должно измениться в бизнесе, кто пользователи, какие сценарии обязательны, какие ограничения есть по срокам, бюджету и существующим системам.
- Структура и сценарии. Разделы, связи между ними, путь пользователя от входа до целевого действия.
- Прототип. Схематичное устройство ключевых страниц без оформления. Обсуждать логику на прототипе дешевле, чем на готовом макете.
- Дизайн. Оформление на основе прототипа, состояния элементов, поведение на разных экранах.
- Разработка. Вёрстка, серверная часть, интеграции, административная часть.
- Наполнение и проверка. Реальные тексты и изображения вместо заглушек, тестирование сценариев.
- Запуск. Перенос на боевую площадку, проверка форм и переадресаций, подключение аналитики.
- Сопровождение. Наблюдение, доработки, развитие по данным.
Самая дорогая ошибка происходит на первом этапе. Изменение логики на прототипе стоит часа обсуждения, то же изменение на этапе разработки — переделки нескольких экранов и интеграции, а после запуска ещё и переноса данных. Поэтому структуру и прототипы мы выносим в отдельный этап — проектирование интерфейсов.
Кто за что отвечает
В небольших проектах роли совмещаются, но сами зоны ответственности остаются. Проблемы начинаются, когда какая-то из них не закреплена ни за кем.
| Роль | За что отвечает | Что ломается без неё |
|---|---|---|
| Менеджер проекта | Сроки, состав работ, связь с заказчиком, приоритеты | Задачи расползаются, никто не видит картину целиком |
| Аналитик или проектировщик | Требования, сценарии, структура | Разработка начинается по устным договорённостям |
| Дизайнер | Интерфейс, состояния, адаптация под экраны | Каждый экран решается заново, единого языка нет |
| Разработчик | Реализация, качество кода, интеграции | Решения принимаются на ходу и не документируются |
| Тестировщик | Проверка сценариев, регресс после изменений | Ошибки находит заказчик после запуска |
| Владелец продукта на стороне заказчика | Решения, приоритеты, приёмка | Правки приходят от разных людей и противоречат друг другу |
Последняя строка касается заказчика, и на неё стоит обратить особое внимание. Когда со стороны компании нет одного человека, принимающего решения, проект получает противоречивые правки от разных отделов, а сроки растут без видимых причин.
Как ставится задача
Формулировка «сделайте покрасивее и чтобы работало быстро» гарантирует несколько кругов переделок. Задача, которую можно взять в работу и потом принять, содержит несколько обязательных частей.
- Контекст. Зачем это нужно и какую проблему решает.
- Ожидаемый результат. Что должно происходить после выполнения.
- Границы. Что в задачу не входит — это экономит время не меньше, чем описание того, что входит.
- Критерии приёмки. Проверяемые условия: страница открывается по такому адресу, форма отправляет письмо на такой ящик, отчёт выгружается в таком формате.
- Ссылки и вложения. Макет, пример, текст ошибки, скриншот, шаги воспроизведения.
Отдельная тема — сообщения об ошибках. «Не работает» не задача. Нужны адрес страницы, устройство и браузер, последовательность действий, что ожидалось и что произошло. Это не бюрократия: половина времени на исправление обычно уходит на воспроизведение проблемы, а не на саму правку.
Инструменты по назначению
Инструменты не заменяют договорённостей, но плохо подобранный набор мешает работать. Общий принцип: у каждого типа информации одно место, и все знают, какое.
| Что нужно | Класс инструментов | Главное требование |
|---|---|---|
| Задачи и сроки | Трекер задач или доски | Одно место для всех задач, видимый статус |
| Требования и решения | База знаний, вики, документы | Актуальность: устаревший документ хуже отсутствующего |
| Дизайн | Редактор интерфейсов с общим доступом | Одна актуальная версия макета, комментарии рядом с элементом |
| Код | Система контроля версий | История изменений, ветки, обзор кода перед слиянием |
| Обсуждение | Мессенджер или корпоративный чат | Каналы по темам, а не одна общая переписка |
| Встречи | Видеосвязь с записью | Итоги письменно после встречи, иначе они теряются |
Главное правило, которое мы соблюдаем: решение, принятое в чате или на встрече, переносится в задачу или в документ. Иначе через месяц никто не вспомнит, почему сделано именно так, и обсуждение начнётся заново.
Распределённая команда
Удалённая работа перестала быть исключением, но она требует того, что в офисе получается само собой. Когда люди сидят рядом, контекст передаётся в разговорах; на расстоянии он передаётся только тем, что записано.
- Письменно по умолчанию. Договорённость, которой нет в тексте, не существует.
- Понятные ожидания по времени ответа. Не «отвечаем сразу», а «в рабочие часы в течение дня». Иначе люди дежурят у чата.
- Пересечение по времени. При разных часовых поясах нужно несколько общих часов в день на обсуждения.
- Короткая ежедневная сводка. Что сделано, что дальше, что мешает. Три строки от каждого заменяют получасовую встречу.
- Меньше встреч, больше повесток. Встреча без повестки и без итогов — самый дорогой способ обсудить что-нибудь.
Отдельно про доступы: в распределённой команде их особенно легко раздать и забыть. Список того, у кого есть доступ к серверам, панелям и учётным записям, стоит пересматривать хотя бы раз в квартал.
Сосредоточенная работа
Переключение между задачами стоит дороже, чем кажется. Дело не в минуте, потраченной на уведомление, а в том, что после переключения контекст задачи приходится поднимать заново. Для вёрстки, кода или текста это заметный кусок времени на каждое переключение.
Отвлечения бывают трёх видов, и лечатся они по-разному. Внешние — уведомления, чаты, звонки, вопрос коллеги «на две минуты». Внутренние — усталость, тревога из-за незакрытых дел, привычка проверять почту. Организационные — расплывчатая задача: когда непонятно, с чего начать, находится занятие попроще.
- Блоки времени в календаре защищают часть дня от встреч — под задачи, требующие погружения.
- Отключённые уведомления убирают внешние прерывания на любой работе длиннее получаса.
- Разбиение задачи на шаги снимает вопрос «с чего начать».
- Собранные вместе встречи оставляют цельные промежутки для работы.
- Записанные на потом посторонние мысли не уводят из задачи.
Оценка сроков
Сроки срываются почти всегда по одним и тем же причинам, и большая часть из них не про скорость работы.
- Оценивалась только разработка, без обсуждений, приёмки, правок и наполнения.
- Задача не была разобрана: срок называли по описанию в одну строку.
- Зависимость от третьей стороны — доступы, данные, ответ смежной системы, согласование.
- Состав работ рос по ходу: каждое «а давайте ещё» само по себе небольшое.
- Контент приходит в последний момент, а без него нельзя проверить, как всё выглядит на реальных данных.
Помогают три вещи. Дробить: задача на неделю оценивается плохо, задача на день — заметно точнее. Отделять оценку от обещания: оценка касается работы, обещание — календаря, где есть другие проекты и выходные. Фиксировать изменения состава работ письменно, вместе с влиянием на срок, — не ради формальности, а чтобы через месяц не выяснять, откуда взялось отставание.
Выбор платформы
Вопрос «на чём делать» лучше решать по сценариям развития, а не по популярности. От платформы зависит, сколько будет стоить развитие и насколько компания будет зависеть от одного подрядчика. С конструкторов уезжают именно по этой причине: так появился интернет-магазин на собственной платформе взамен сайта-конструктора.
| Решение | Кому подходит | Что учесть |
|---|---|---|
| Готовая коробочная система управления | Корпоративные сайты, типовые магазины | Много готовых модулей и специалистов на рынке; лишний функционал приходится нести с собой |
| Конструктор | Простые страницы, быстрые запуски, проверка спроса | Ограничения по логике и переносу, зависимость от площадки |
| Разработка на фреймворке | Проекты со своей бизнес-логикой и интеграциями | Гибкость, но всё нужно делать и обслуживать самим |
| Headless-подход | Контент используется сразу в нескольких каналах | Отдельная витрина и отдельное хранилище контента — это две системы вместо одной |
Про headless-подход скажем отдельно, потому что вокруг него много ожиданий. Разделение хранилища контента и витрины действительно даёт гибкость: один материал показывается на сайте, в приложении, в личном кабинете. Но за гибкость платят сложностью: редактор не видит результат сразу, а команда обслуживает две части вместо одной. Если контент используется в одном канале, обычная система управления решает задачу дешевле.
Независимо от выбора мы смотрим на одно и то же: сможет ли владелец сам менять тексты и создавать страницы по шаблону, есть ли управление мета-тегами, разграничиваются ли права редактора и администратора, как делаются резервные копии и легко ли найти на рынке специалиста по этой платформе.
Сайт или мобильное приложение
Выбор между сайтом и приложением сводится к тому, как часто человек будет возвращаться и нужны ли ему возможности устройства.
Сайт находят через поиск, он не требует установки и обновляется одним разом для всех. Приложение живёт на экране телефона, работает с уведомлениями, камерой, датчиками и офлайн-режимом, но его нужно установить — а это отдельный барьер, который берут только при регулярной потребности. Если задача сводится к тому, чтобы рассказать о компании, показать каталог и принять заявку, приложение обычно избыточно.
Когда приложение действительно нужно, встаёт второй вопрос: нативная разработка под каждую платформу даёт максимум возможностей, но это две кодовые базы; общий код экономит время, хотя часть функций всё равно дописывается отдельно.
Своя команда, фрилансеры или подрядчик
| Вариант | Когда оправдан | Слабое место |
|---|---|---|
| Штатная команда | Продукт развивается постоянно, задачи не кончаются | Найм, удержание, простои между этапами |
| Отдельные исполнители | Разовые узкие задачи | Никто не отвечает за результат целиком |
| Агентство или студия | Проект с началом и концом, нужен весь набор ролей | Требуется владелец задачи на стороне заказчика |
| Выделенная команда в аренду | Нужны руки и компетенции на несколько месяцев | Нужно время на погружение в проект |
Комбинация встречается чаще, чем чистые варианты: внутри компании остаётся владелец продукта и часть разработки, внешняя команда закрывает пиковые нагрузки и специализированные компетенции, которые нет смысла держать в штате постоянно. В таком режиме мы семь лет ведём сайт производителя оборудования для переработки отходов: переезд, восстановление после взлома и текущие доработки.
Что смотреть при найме разработчика
Собеседование, состоящее из вопросов на память, плохо предсказывает работу. Полезнее разбирать реальную задачу и смотреть, как человек рассуждает.
- Как объясняет свои прошлые решения: почему выбрал такой подход и что бы изменил сейчас.
- Что делает, когда задача сформулирована неполно: уточняет или додумывает молча.
- Как относится к чужому коду: готов ли разбираться в существующем проекте, а не переписывать всё заново.
- Как читает ошибку и ищет причину: этот навык важнее знания конкретной библиотеки.
- Как пишет: в распределённой команде текст — основной способ общения.
Со стороны кандидата работает то же самое: вопросы о процессах — как ставятся задачи, есть ли обзор кода, как выкатываются изменения — говорят о человеке больше, чем список технологий в резюме.
Передача проекта
Проект рано или поздно меняет руки: приходит новый подрядчик, уходит сотрудник, задачи переходят на сопровождение. Мы регулярно принимаем чужие проекты и по опыту знаем, что передавать нужно не только код. Такие проекты мы берём на техническую поддержку и развитие.
- Доступы: хостинг, домен, панель управления, репозиторий, почта, аналитика, рекламные кабинеты.
- Исходники: код целиком, макеты в редакторе, исходные файлы изображений.
- Описание того, как проект собирается и разворачивается, включая настройки окружения.
- Схема данных и описание интеграций со сторонними системами.
- Список известных ограничений и мест, которые трогать опасно.
Самый частый пробел — исходники внешней части. Когда есть только результат сборки, любая правка вёрстки превращается в раскопки, поэтому наличие исходников проверяют до окончания работ, а не через год.
Коротко
Процессы в цифровом проекте нужны не ради процессов. Разобранная задача снимает переделки, критерии приёмки снимают споры, письменные решения снимают повторные обсуждения, а осознанный выбор платформы снимает зависимость от одного человека. Всё это скучные вещи, но именно они определяют, уложится ли проект в срок и можно ли будет его развивать.
Мы работаем и целыми проектами, и в формате команды, подключённой к задачам заказчика: менеджер, разработчики, дизайнер и тестировщик встраиваются в ваши процессы и инструменты. Если нужны компетенции на несколько месяцев без расширения штата, посмотрите, как устроена выделенная IT-команда в аренду, или напишите нам — обсудим задачи и предложим состав команды.
