Каждый, кто работал над проектами, знает, рано или поздно приходится наступать на одни и те же грабли. Ошибки повторяются, и, если их не анализировать, они будут снова и снова тормозить работу. Я руководитель проектов в компании «ЛАНИТ-Интеграция» с семнадцатилетним управленческим стажем. В моей практике были инфраструктурные проекты, проекты по аудиту и информационной безопасности, телекоммуникациям, а среди заказчиков, с которыми я работал, есть крупнейшие банк, авиакомпания, автомобилестроительный завод, предприятие атомной отрасли России.
Сегодня в блоге ЛАНИТ я расскажу про инструменты, которые помогают минимизировать риски в проектной работе.

Формирование команды
Любой проект — это прежде всего люди. Представьте лодку, которая плывет из точки А в точку Б. Гребцы — это команда: разработчики, аналитики, менеджеры. А на носу стоит человек с плеткой. Нет, это не ваш тимлид и не архитектор. Это заказчик. И вот тут начинается самое интересное.

Сколько раз я слышал от коллег вопрос: «Почему именно я? Почему назначили меня? У меня нет нужных компетенций!» Знакомо? Да, это классика. Человек смотрит на задачу, видит в ней китайскую грамоту и думает: «Ну всё. Я умер». Но выход есть.
Технология №1: «Глаза боятся, руки делают». Инструменты-помощники
Типичная ситуация: к сотруднику подходит руководитель и говорит: «Давай возьмешь ещё один проект» А он в ответ: «Ну как бы... да, но...», и всё равно соглашается.
Был у меня на проекте джуниор, которому нужно было поженить старое оборудование с новым так, чтобы старое завелось. Он никогда этого не делал. Но вместо паники он открыл ChatGPT, нашел там пару костылей, подкрутил — и вуаля! Всё заработало.

Конечно, бывает, что и ChatGPT не спасает. Тогда воспользуйтесь технологией №2.
Технология №2: Новая строчка в резюме. Возможность повысить компетенции
Нужно подойти к руководителю и честно сказать: «Передо мной стоит задача, с которой я не могу справиться. Мне нужна твоя помощь. Мне нужна твоя поддержка. Я хочу изучить задачу, разобраться в ней. Помоги». Руководитель не съест вас за это. Наоборот — поможет. А вы получите новую строчку в резюме: не «уволился», а «освоил новую технологию».
Сбор данных: заказчик — не враг
Когда вы приходите к заказчику за информацией, он часто видит вас вот так: «Сейчас эти айтишники всё у меня выпытают, а потом начальство меня уволит!» Как этого избежать? Если с самого начала показать, что вы здесь не как надзиратели, а как помощники, что вы решаете ту задачу, которая давно не решалась и сейчас вас привлекли как ресурс, который поможет с проблемой, всё меняется.
Вот пример из моей практики. Один IT-директор четыре года просил у руководства 30 миллионов на развитие. Ему отказывали. Мы пришли, сделали свою работу — и вдруг руководство говорит ему: «Держи миллиард». Мораль - ваша работа должна приносить пользу не только компании, но и конкретным людям на местах.
Что делать, если заказчик упрямится
Бывает, что сотрудник заказчика намеренно не даёт данные. Тут важно понять, почему. Может, он перегружен? Или боится последствий? Или просто не доверяет?
В этом случае можно использовать следующие инструменты.
Объяснить выгоду («Это поможет вам быстрее закрыть задачу»).
Дать гарантии («Эти данные не пойдут выше без вашего согласия»).
Просто поговорить (Часто люди идут на контакт, когда видят в вас союзника).
«Уникальный» сотрудник заказчика: когда знание — это власть
Представьте, есть человек, который единственный разбирается в системе. Без него — тишина. Он вечно занят, не читает письма, может встать и уйти с совещания, и никто даже бровью не поведет. Вы приходите к нему с вопросом, а он смотрит на вас, как на назойливую муху, и мысленно уже вернулся к «настоящей работе».
Вы знаете таких людей. Их называют незаменимыми. Они — хранители тайного знания, без них проект встает, а вопросы им приходится задавать, ловя между перекурами и вздохами. Как взаимодействовать с такими персонажами?
Технология №3: Ждун. Психологическое давление
Вы подходите, говорите: «Мне нужна помощь», и садитесь рядом. У него, конечно, уже есть очередь из таких же, как вы, но вы не уходите. Вы просто сидите. Смотрите. Ждёте. Он делает вид, что вас нет, печатает, листает документы. Но через 10 минут (максимум!) он не выдержит и спросит: «Ну что там у тебя? Давай быстрее, отвечу и отстанешь». И вот он — ваш шанс. Главное — не сдаваться раньше времени.

Молчание — не золото. Почему команда не задаёт вопросы
А теперь другая история. Первое техническое совещание. Архитектор объясняет задачу, спрашивает: «Всё понятно?» и получает в ответ:
Вариант 1. Гробовая тишина.
Вариант 2. Один смелый голос: «Да, понятно».
Проходит два дня, а проект не движется. Почему? Либо команда не подготовилась и даже не открыла ТЗ, либо все боятся выглядеть глупо и надеются разобраться сами.
Технология №4: Анонимный опрос. Быстрый срез текущего состояния
Пишете в рабочем чате: «Коллеги, есть вопросы по задаче? Да/нет». Если хотя бы один человек отвечает «Да» — собираете повторное совещание. И вот тут-то начинается магия. Те, кто молчал, вдруг начинают спрашивать. Оказывается, никому не было до конца понятна задача. Просто никто не хотел быть белой вороной.
Дедлайны и «Поле Чудес»: как не сгореть на проекте
Вы знаете это чувство, когда спрашиваешь команду: «Успеваем?» — и в ответ начинается настоящая игра в «Поле Чудес»:
- Этой задачи не было в ТЗ!
- Мы не учли нюансы на пресейле!
- Форс-мажор. Куда ж без него!
Крутишь барабан — выпадает новый «уважительный» повод сорвать сроки. Знакомо?
Технология 888: Баланс вместо выгорания. Формула равновесия
Главная причина срывов — не форс-мажоры, а усталость. Когда люди работают на износ, их KPI падает, ошибок становится больше, а дедлайны уплывают как песок сквозь пальцы.
Решение простое: правило трёх восьмёрок.
8 часов работы — максимальная концентрация.
8 часов отдыха и развития — спорт, хобби, семья, даже домашние дела.
8 часов сна — без компромиссов.
Если вы чувствуете, что сегодня вторник, а состояние как в пятницу — это тревожный звоночек. Переработки — зло. Они не помогают «догнать», а только глубже закапывают проект в проблемы.
Пацанские договорённости: как спасти дедлайн
Бывает, что честно не успеваем: заказчик просил «чуть-чуть не по ТЗ», а теперь сроки горят. Что делать?
Технология №5: Договариваемся как пацаны. Взаимные уступки
Признать проблему. «Мы сделали то, о чём вы просили, но это вышло за рамки изначального плана».
Предложить выход. «Давайте актируемся по текущим датам, а эту задачу либо вынесем в отдельный этап, либо обсудим допсоглашение».
Ключ — не отказываться, а перезаложить сроки. Если отношения с заказчиком выстроены нормально, он пойдёт навстречу.

Доработка результатов
50% замечаний на проекте возникают из-за того, что кто-то «имел в виду не то». Как такого избежать?
Технология №6: Рамки. Установка границ
Нужно ловить размытости в техническом задании.
Выявить все неоднозначности в ТЗ на старте.
Задать заказчику прямой вопрос: «Вот этот пункт — вы хотите 1000 строк кода или 20?»
Фиксировать ответ письменно.
Так вы сэкономите недели работы и нервы команды.
А самое главное, когда мы очерчиваем строгие рамки проекта, мы уже можем вспоминать пацанские договоренности. Когда заказчик говорит: «Ребята, а давайте вы еще что-нибудь сделаете», мы скажем: «Нет, подожди. Мы рамки очертили? Очертили! То, о чем ты говоришь, давай вынесем либо в допник за дополнительные деньги, либо вообще сделаем новый проект». Это уже позиция. Пацанские договоренности гораздо сильнее. Реестр замечаний и технологий, на мой взгляд, с одной стороны, очень банальная, простая история, а с другой стороны - она отлично работает в нашей сфере.
Долгий проект — это всегда смена людей у заказчика и противоречивые правки. Вот пример из моей практики. Один из заказчиков сначала просил систематизировать информацию в таблицах. Затем его коллега попросил заменить таблицы на текст. Мы поняли, что происходит конфликт интересов внутри команды заказчика и попросили прийти к окончательному решению, которое всех бы устроило.
Технология №7: Реестр замечаний. История взаимоотношений
Без него не обойтись. Фиксируйте, кто, когда и что попросил изменить. Когда приходит новый человек, он видит историю и не начинает «колесо сансары» заново.

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