Основы управления проектами для МСБ

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

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

1Объём2План3Ответственность4Выполнение5Контроль6Закрытие и выводы

Что считать проектом

У проекта есть начало и конец, он не повторяет один в один то, что вы уже делали, и оставляет после себя уникальный результат. Ежемесячное выставление счетов — рутина, переход на новый учётный контур — проект. Сборка заказов — рутина, открытие второй точки — проект. Разница практическая: рутиной управляют процессом, проектом — планом. Рутине нужен описанный порядок действий и чек-лист, об этом мы пишем в материале про документацию процессов и SOP. Проекту нужны объём, календарь и ответственность.

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

Какие проекты бывают у небольшой компании

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

Опишите объём на одной странице

Первая строка плана — не дата, а объём. Хорошее описание отвечает на три вопроса. Что именно у нас будет, когда работа закончится? Чего мы сознательно не делаем? Как мы поймём, что получилось? Третий вопрос пропускают чаще всего: «сайт обновлён» — не критерий успеха, а «посетитель, заполнивший новую форму, попадает в CRM и получает ответ в тот же день» — критерий.

Полезно сразу привязать проект к более крупной цели компании. Если вы работаете квартальными целями, логика из материала про OKR и управление по целям не даст проекту превратиться в размытое «улучшение». А если проект — часть запуска нового направления, шаги из статьи о том, как составить бизнес-план, дадут готовую рамку.

Как справляться с расползанием объёма

Расползание объёма (scope creep) приходит не как саботаж, а как хорошие идеи. На середине проекта по сайту кто-то говорит: «раз уж мы здесь, переделаем и блог» — и три недели растворяются. Лекарство не запрет, а запись. Правило одно: для всего, что добавляется позже, фиксируйте три вещи — кто попросил, какую дату это сдвигает, что вместо этого не делается. Тот, кому приходится это писать, половину просьб отсеивает сам, а остальные становятся решением, а не случайностью.

Дорого в проекте обходится не задержка, а нерешённый вопрос о том, кто принимает решение; задержка — лишь счёт за него.

Разбейте работу и держите задачи мелкими

Когда объём ясен, результат делят на управляемые части. В этом и состоит декомпозиция: крупные блоки, а внутри каждого — задачи, которые один человек закрывает за разумный срок. Для переезда блоки такие: помещение и договор, стеллажи и оборудование, инвентаризация и перевозка, документы и адреса, инструктаж команды. Под каждым блоком пять-десять задач.

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

У каждой работы — один владелец

Самая частая фраза в небольшой команде: «я думал, это делаешь ты». Лечится она только одним именем напротив каждой задачи. Два имени означают ноль имён. Владелец не обязан делать работу руками — он отвечает за то, что она сделана.

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

Календарь: вехи, зависимости и один буфер

Планировать время — не значит проставить дату у каждой задачи. Нужно определить три вещи. Первое — вехи, точки невозврата: «договор подписан», «стеллажи смонтированы», «товар перевезён». Четырёх-шести вех достаточно, чтобы одним взглядом понять состояние проекта.

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

Нужна ли вам диаграмма Гантта?

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

Водопад или гибкий подход? Гибрид для небольшой команды

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

Ситуация	Что подходит	Почему
Дата задана извне (выставка, аудит)	Водопад	Идёт обратный отсчёт, важна последовательность
Результат неясен (новая услуга)	Гибкий	Ранняя обратная связь удешевляет разворот
Переход на новую систему	Гибрид	Каркас по плану, настройка итерациями
Индивидуальная поставка клиенту	Гибрид	Вехи по договору, промежуточные сдачи циклами

Рабочий рецепт: вехи и зависимости спланируйте заранее, а саму работу ведите двухнедельными отрезками и в конце каждого показывайте то, что действительно готово. Для перехода на новую систему такой подход разобран в материале план внедрения CRM на 30/60/90 дней.

Ресурсы и загрузка: считайте в человеко-днях

Тихий убийца проектов в небольшой компании — отсутствие расчёта загрузки. Команда уже ведёт текущую работу, а проект ложится сверху. Планируйте в человеко-днях, а не в часах: кто и сколько дней в неделю может дать проекту? Если руководитель продаж выделяет один день в неделю, то «трёхдневная» задача в календаре занимает три недели. Один этот пересчёт снимает большую часть ошибок в оценках.

Когда мощности не хватает, вариантов ровно три: сократить объём, сдвинуть дату или привлечь подрядчика. Четвёртого нет — фраза «команда немного поднапряжётся» означает тайный выбор одного из трёх, обычно даты. Решая про подряд, задайте один вопрос: это наша отличительная компетенция или разовая техническая работа? Во втором случае брать снаружи почти всегда правильно. И зафиксируйте объём до разговора о цифрах: предложения на размытый объём несравнимы.

Список рисков и простой план действий

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

• Задержка поставки: Опоздавшие материалы сдвигают всю цепочку, поэтому заказывайте с запасом до вехи и заранее наметьте запасного поставщика.
• Зависимость от одного человека: Если ключевой шаг знает только один сотрудник, отпуск останавливает проект, поэтому опишите шаг и проведите по нему второго.
• Узкое место в согласовании: Когда решения копятся на одном столе, откройте фиксированное еженедельное окно решений и переносите туда всё ожидающее.
• Потеря данных при переходе: Не начинайте перенос без резервной копии старых данных и сначала прогоните пробную загрузку на небольшой выборке.
• Текучка съедает проект: Если сезон останавливает движение, выделите постоянный проектный блок в неделе и не отдавайте его под встречи.

Ритм общения: короткий статус, одна доска, журнал решений

Цель проектного общения — не говорить больше, а смотреть на одну картину. Хватает трёх вещей. Еженедельная встреча не длиннее пятнадцати минут: что закрыто, что закроем, что мешает. Единый источник правды: одно место, где лежат задачи, сроки и файлы, потому что если один факт живёт в двух местах, одно из них неверное. И журнал решений: что решили, кто решил и почему — по строке на решение. Через три месяца именно эта строка отвечает на вопрос «почему мы сделали так?». Как превращать сказанное в работу, мы разбираем в материале про заметки встреч и отслеживание задач.

Хватит ли таблицы?

Один активный проект, меньше пяти человек и полсотни задач — аккуратная таблица действительно справляется: задача, владелец, срок, статус, комментарий. Переходить на доску стоит при одном из трёх признаков: проектов стало несколько, статусы обновляет больше людей, либо сроки в таблице никто уже не читает. Визуальный поток принимают охотнее, чем список: логика Kanban-доски, знакомая по сделкам, так же ясно показывает, где застряла проектная работа.

Свяжите клиентские проекты со сделкой и отчитывайтесь честно

Если проекты — это то, что вы сдаёте клиентам, отрыв проектной доски от продаж обходится дорого. Цепочка должна быть непрерывной: сделка выиграна, из выигранной сделки открывается проект, проект сдаётся по вехам, сдача запускает счёт, дальше — контроль оплаты. В CRM вроде Rocketly задачи, которые открываются автоматически при выигрыше сделки, держат эту цепочку на той же карточке клиента, где идёт переписка.

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

Закрытие, выводы и шесть частых ошибок

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

• Объём не записан: Каждый держит в голове свой проект, и одностраничное описание объёма выявляет расхождение в первый же день.
• Дата названа первой: Срок, данный до декомпозиции, — это пожелание, поэтому сначала разложите работу, а потом называйте день.
• Задачи без владельца: Каждая строка со словами «команда сделает» срывается, потому что не делает никто.
• Загрузка не учтена: План, не учитывающий текущую работу, рушится в первую же горячую неделю.
• Молчаливый срыв: Плохая новость, пришедшая поздно, стоит дороже самой плохой новости.
• Нет закрытия: Незаписанные выводы означают ту же ошибку по той же цене в следующем проекте.

Шаблон проекта на одну страницу

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

Быстрее всего порядок окупается, когда проекты живут рядом с клиентами и сделками: задачи, напоминания, предложения и счета в одном потоке — и доска остаётся актуальной сама. Создайте бесплатный аккаунт Rocketly и соберите первый проект уже сегодня — с объёмом, владельцами и настоящими вехами.