Проверка доступности ресурсов перед разработкой проекта: что оценить и как это сделать

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

Зачем проверять ресурсы до старта, а не по ходу работы

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

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

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

Шесть групп ресурсов, которые нужно проверить

Удобно оценивать ресурсы по шести группам. Пропуск любой из них — типичная причина внезапной остановки проекта.

• Люди и компетенции. Кто будет выполнять работу, сколько времени реально смогут уделять конкретные специалисты, есть ли редкие навыки, без которых проект не движется.
• Бюджет. Не только общая сумма, но и её распределение по периодам: деньги, которые придут через полгода, не помогут оплатить работу в первом месяце.
• Время. Реалистичность сроков с учётом отпусков, параллельных задач команды и неизбежных задержек согласований.
• Инфраструктура и инструменты. Серверы, лицензии, среды разработки, оборудование, доступы — всё, без чего работа физически не начинается.
• Данные и знания. Исходные данные, документация, доступ к системам заказчика, экспертиза предметной области.
• Организационная поддержка. Решения и согласования, которые должны принимать люди вне команды: руководство, смежные отделы, внешние подрядчики.

Люди: самая частая точка отказа

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

Корректная оценка выглядит иначе. Для каждого ключевого участника выясните:

• какой процент рабочего времени он сможет уделять именно этому проекту (часто это 30–50%, а не 100%);
• какие у него запланированные отсутствия: отпуска, командировки, дедлайны других проектов;
• есть ли у него нужные компетенции или их придётся добирать обучением, что тоже занимает время;
• кто его заменяет при болезни или увольнении — хотя бы на уровне «какую часть работы сможет подхватить другой человек».

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

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

Бюджет: проверяйте не сумму, а график платежей

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

Что проверить по бюджету:

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

Полезный приём — составить два сценария расхода: базовый и пессимистичный (сроки +30–50%, плюс пара незапланированных закупок). Если пессимистичный сценарий ломает финансирование, у вас не запас прочности, а иллюзия бюджета.

Время: отличайте календарный срок от трудоёмкости

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

При проверке временного ресурса пройдитесь по списку:

1. Разбейте проект на крупные этапы и для каждого укажите, кто его выполняет и какая у этого человека реальная доступность.
2. Отметьте этапы, которые нельзя распараллелить: пока не готова архитектура, бессмысленно нанимать больше разработчиков.
3. Добавьте буферы на согласования, отпуска и интеграцию — они занимают время всегда, вопрос лишь в том, заложили вы его или нет.
4. Сравните получившийся срок с требуемым. Расхождение — это не повод «ужать оценки», а сигнал пересматривать объём, состав команды или сроки.

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

Инфраструктура, инструменты и доступы

Эта группа ресурсов кажется очевидной, но именно она чаще всего тормозит первые недели проекта. Команда собрана, задачи поставлены — и все ждут доступа к репозиторию, тестовому стенду или учётной записи в системе заказчика.

Перед стартом убедитесь, что:

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

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

Данные и предметные знания

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

Минимальная проверка данных до старта включает:

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

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

Организационная поддержка и точки принятия решений

Проект останавливается не только из-за нехватки людей и денег, но и из-за того, что никто вовремя не принял решение. Перед стартом зафиксируйте:

• кто является спонсором проекта и какое решение он обязан принимать;
• каков предельный срок реакции на запрос команды (например, ответ на уточняющее требование — не дольше пяти рабочих дней);
• какие согласования нужны извне: юридическая служба, ИБ, смежные подразделения, регуляторы;
• что происходит, если согласование затягивается: эскалация, обходной путь, изменение плана.

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

Как оформить проверку: простой чек-лист

Результат проверки удобно фиксировать таблицей. Она заставляет формулировать выводы явно, а не «примерно нормально».

Ресурс	Что требуется проекту	Что есть фактически	Статус
Команда	Например: 3 разработчика, аналитик, дизайнер на 6 месяцев	Реальная доступность каждого участника в процентах	Достаточно / дефицит / критический дефицит
Бюджет	Помесячный план расходов	Помесячный график финансирования	Сходится / разрыв в месяцах
Время	Оценка сроков с буферами	Требуемый дедлайн	Реалистично / нужен пересмотр объёма
Инфраструктура	Перечень сред, лицензий, оборудования	Что готово к дате старта	Готово / в процессе / не начато
Данные	Перечень источников и требований к ним	Подтверждённый доступ и качество выборки	Подтверждено / под риском
Управление	Спонсор, порядок решений, сроки реакций	Фактические договорённости	Зафиксировано / не определено

Правило простое: статус «дефицит» — не запрет на проект, а повод изменить план. Статус «критический дефицит» по ресурсу, без которого работа невозможна, — основание перенести старт или переформатировать проект.

Типичные ошибки при оценке ресурсов

• Оптимистичная занятость. Планируют людей на 100% времени, забывая про совещания, поддержку текущих систем и другие проекты. Реалистичная загрузка на проект обычно заметно ниже полной.
• Игнорирование критического пути. Наращивают ресурсы там, где работы и так параллелятся, вместо усиления узкого места.
• Бюджет без резерва. Любая неожиданность сразу превращается в кризис финансирования.
• «Доступы сделаем потом». Первые недели проекта уходят на административные ожидания, мотивация команды падает.
• Данные принимаются на веру. О качестве и полноте данных судят по описанию, а не по фактической выборке.
• Отсутствие владельца решения. Вопросы зависают неделями, сроки съезжают без видимой причины.

Если ресурсов не хватает: варианты действий

Обнаруженный дефицит — это информация для принятия решения, а не приговор. Основные варианты:

• Сократить объём. Определить минимальную ценную версию результата и отложить остальное. Часто самый здоровый вариант.
• Изменить сроки. Если дедлайн мягкий, сдвиг дешевле, чем потеря качества или выгорание команды.
• Привлечь внешние ресурсы. Подрядчик закрывает дефицит компетенций быстрее найма, но требует управления и передачи знаний.
• Изменить технологию или подход. Иногда дорогой дефицит экспертизы снимается выбором более распространённого стека или готового решения.
• Перенести старт. Если критический ресурс появится через пару месяцев, честный перенос лучше запуска «на голодном пайке».

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

Когда проверку нужно повторять

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

С чего начать прямо сейчас

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

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