Проект в бюджете, вовремя, качественно – выбери два из трех или «Заверните всё, пожалуйста»

Немного обо мне: Меня зовут Клавдия Макарова, я возглавляю консалтинговое направление ИТ-коллаборации «Гроуверест». В проектной деятельности с 2006 года.

Уже в 2007 году, параллельно очному обучению в двух вузах, я занимала позицию руководителя отдела маркетинга в московской франчайзинговой компании и одновременно строила карьеру в «1С-Учебном центре №3». С теплотой вспоминаю это время и передаю привет всем, кто меня помнит – «1С-Учебный центр №3» навсегда в моем сердце.

С 2020 года я развиваю собственную Школу Бизнес-архитектора – сейчас заканчивается уже шестой поток, выпускники получают дипломы государственного образца (прим. ред. доклад от 27 мая 2023 года). И буквально накануне я получила патент на товарный знак онлайн-университета для детей от 6 лет – Growverest.

Все это искренне люблю, я действительно фанат своего дела, да и вообще фанат эволюции человечества – верю в постоянное развитие руководителей, аналитиков и функциональных архитекторов. Мне всегда хочется везде успевать. Поэтому и доклад мой называется: «Проект в бюджете, вовремя, качественно – можно ли выбрать только два? Или: "Заверните всё, пожалуйста"»

Многие из вас читали PMBOK, кто-то даже проходил по нему сертификацию. Но как начать применять эти знания в реальных ситуациях на проекте? Как справляться с тем огромным объемом ответственности, который ложится на руководителя проекта? Управлять временем, сроками, бюджетом, ресурсами, рисками, ожиданиями – кажется, что для этого нужно быть буквально «многоруким Шивой». Сколько времени нужно, чтобы осознать это и запомнить? К какому возрасту мы вообще к этому придем?

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

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

В жизненном цикле проекта четыре фазы: фаза инициации; фаза планирования; фаза реализации и фаза завершения. Фазы состоят из этапов – они могут называться по-разному, но вне зависимости от используемой методики (Agile, Waterfall или их гибрид) структура жизненного цикла сохраняется, и мы будем на нее опираться.

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

Обращу внимание, что мы сейчас будем рассматривать в основном ситуацию на проектах среднего класса – тех задачах, которые составляют основу у большинства: для кого-то это 80%, для кого-то 100% портфеля. Я расскажу про свой опыт – что помогало моей команде при прохождении различных этапов таких проектов.

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

• ТКВ – 1С:Технология корпоративного внедрения

• ТКС – 1С:Технология корпоративного сопровождения

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

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

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

Жизненный цикл проекта. Пресейл

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

Начнем с пресейла – посмотрим, на что вы обращаете внимание при первом контакте с заказчиком.

Итого, цель заказчика:

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

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

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

• Предотвращение кассовых разрывов.

Давайте подумаем, каким будет первый этап работ, стоимость этого этапа и его сроки? Варианты предложений:

• Аудит доработанной конфигурации и интеграций между системами – откуда и как нужно собирать информацию. Планируемый бюджет – 700 тысяч.

• Предпроектное обследование. Выездное интервью – неделя, 3 недели на написание отчёта, 3 дня на защиту. Команда 3 аналитика + РП. Итого: 4.5 недели, 2 миллиона.

• Обследование. Результат: реестр процессов, схема ИС, стоимость этапа моделирование и проектирование, определение границ проекта. Два аналитика и один разработчик. 2 месяца, 1.5 миллиона.

• Предпроектное обследование – 1,5 месяца, 2 миллиона.

• Обследование: проведение интервью и анализ базы (конфигурация и состояние с/с – считается после изменений или нет). Результат: схема как есть, как надо, дорожная карта. 4 человека (3 аналитика + РП). 2 месяца с выездами. 4,5 миллиона.

• Кто-то готов провести предпроектное обследование бесплатно, чтобы продемонстрировать клиенту свою экспертизу, «засветить» мозги. Считает, что может позволить себе эту инвестицию – пообщаться в экспресс-формате за три дня: познакомиться с заказчиком, понять текущую ситуацию и в итоге предложить не просто оценку «с потолка», а обоснованное КП с концепцией проекта, ресурсным планом и первым понимание объемов.

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

• Кто-то начинает с бесплатного этапа, чтобы проявить экспертизу и лучше понять ситуацию до вступления в платные обязательства.

• Кто-то сразу идет с ценником, не рассматривая «бесплатные пробы».

• Кто-то называет это предпроектным обследованием, кто-то аудитом – названия разные, суть похожа.

Каждый исходит из собственного опыта и интересов: кому-то важно портфолио, кто-то автоматизировал похожие производства, кто-то только набирается опыта. И это нормально – у всех свой путь, и именно это разнообразие подходов особенно ценно.

Расскажу свою точку зрения – то, как мы зашли в этот проект. Несмотря на то, что моей команде уже не нужно нарабатывать портфолио, я по-прежнему погружаюсь в пресейл, начиная с небольшого экспресс-анализа. Это может быть даже неформализованное обследование – несколько встреч, чтобы разобраться в текущем положении дел и понять, как заказчик дошел до текущей точки. На этих встречах мы просим заказчика показать систему, по возможности – дать доступ, хотя бы ограниченный. Если нет, просим открыть конкретные разделы – статьи расходов, настройки, отчеты по себестоимости. Уже на этом этапе задаем уточняющие вопросы, демонстрируем экспертизу и оцениваем осведомленность клиента. Это помогает обеим сторонам понять, готовы ли они двигаться дальше – уже на платной основе. И в этот проект я тоже зашла через трехдневный бесплатный этап.

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

Важно понимать: когда мы приходим дорабатывать уже действующую, проблемную систему – это требует особого подхода. Часто проект начинался с идеей «внедрить ERP из коробки», но мы с вами знаем, как это бывает. Такие ситуации – не показатель того, что у заказчика все плохо. Но они отражают его ожидания – например, когда он переходил с УПП, там эта функциональность была разработана хорошо. Нам важно найти путь, как с этим работать, потому что разбираться с уже существующим всегда сложнее и дороже, чем строить с нуля.

Что поможет на старте проекта?

• Вне зависимости от того, на каком этапе вы подключаетесь к проекту – на старте или в процессе – нужен договор.

• Кроме этого, нужен устав проекта, где прописаны роли участников со стороны заказчика – спонсор, куратор, РП, тех. лид, бизнес-архитектор, администратор проекта. Важно прописать рабочие группы и закрепить за ними конкретных людей – указать не просто должности, но и конкретные зоны ответственности для каждого участника. Если этого не сделать, возникнет риск недопонимания и конфликтов. Например, если вы видите, что один человек обозначен сразу как РП, бизнес-архитектор и тех. лид – это серьезный повод задуматься. Такие совмещения несут риски, потому что между этими ролями есть серьезные внутренние противоречия, и непонятно, как человек будет их самостоятельно разруливать. Например, бизнес-архитектор (или функциональный архитектор) отвечает за качество проектных решений, а руководитель проекта – за соблюдение бюджета и сроков. Если человек, будучи архитектором, понимает, что задача требует 20 часов, но как РП заложил в план только 10, что дальше – перерабатывать бесплатно, урезать качество или пересматривать сроки и бюджет? Такие вопросы нужно проговаривать заранее. Безусловно, если специалист обладает высокой квалификацией и способен гибко совмещать несколько ролей – это плюс. Но практика показывает, что разделение ролей помогает избежать непрозрачности и рисков. Это особенно важно в проектах, где ставки высоки.

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

• Полезный инструмент – соглашение о моделировании. Это не доп. соглашение к договору, а отдельное рабочее соглашение, которое фиксирует «правила игры»: в какой нотации описывать модели, что именно считается результатом, как будет проходить согласование. Фирма «1С» недавно включила соглашение о моделировании в состав ТКВ, и мы стали одними из первых, кто прошел авторский надзор с этим документом. Сначала казалось, что это лишняя бюрократия, но на практике подобное соглашение очень облегчает этап концептуального моделирования и упрощает пресейл. Сейчас мы сразу отправляем заказчику не только договор и устав проекта, но и соглашение о моделировании, чтобы все стороны понимали, по каким правилам будем работать.

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

• И критически важна установочная встреча, которой, к сожалению, многие пренебрегают. Часто на нее приходит только руководитель проекта, но я считаю, что на установочной встрече должны присутствовать все ответственные лица, указанные в уставе рабочей группы. Именно там мы фиксируем, кто за что отвечает. Со стороны исполнителя, кроме РП, должны обязательно участвовать (или подключаться онлайн) функциональный архитектор и тех. лид – важно, чтобы они были ознакомлены с уставом и соглашением о моделировании, потому что эти документы касаются не только РП. В идеале – получить от всех подтверждение об ознакомлении, вплоть до подписи. Это позволяет всем участникам быть на одной волне и понимать, как будет организована работа. Мы доносим до заказчика: вот зона нашей ответственности, вот ваша, и подчеркиваем, что наша цель – совместная, и идти к ней нужно слаженно. Часто на местах просто не хватает времени или ресурса, чтобы донести это всем участникам – именно поэтому установочная встреча особенно важна.

Что еще поможет?

• Важный момент – система учета задач. Лучше сразу на берегу договориться, в какой системе будет вестись управление задачами. Иначе возникает хаос: кто-то использует Битрикс, кто-то Google-таблицы, и в итоге подрядчик внутри одной компании работает в пяти разных системах – это приводит к потере времени и контроля.

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

• Заказчику и подрядчику имеет смысл обменяться графиками отпусков.

• Заранее проговорить сквозной пример для прототипирования – как раз таки в шаблоне соглашения о моделировании есть ключевые моменты описания этого сквозного примера.

• Наладить работу с заинтересованной сторонами на старте (например, через матрицу «власть/интерес»).

• И сразу начать активно прорабатывать риски – не просто указать их в уставе и забыть об этом, а обсудить реальные кейсы и заранее договориться, как действовать, если возникнет тот или иной риск.

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

Иногда заказчик показывает мне готовые отчеты по обследованию, я его спрашиваю: «А почему вы не продолжили работу с этой командой? Они хорошо поработали, отчет достойный, специалисты сильные». А мне отвечают: «Не сошлись, поссорились». И все – работа остановилась, из-за уязвленной гордости возвращать команду не хочется, хотя специалисты были хорошими. И чаще всего, причина разрыва – разное понимание ожидаемого результата. Заказчик заплатил за одно, а подрядчик сделал другое – и всё, конфликт.

Поэтому в соглашении об обследовании и моделировании должны быть прописаны:

• Периметр обследования и моделирования.

• Среда процессного моделирования – это тоже очень важно.

• Общий подход к подготовке моделей, требования к системе.

• Порядок сдачи протоколов – если в уставе у вас этого нет, можете добавить в соглашение.

Что еще должно быть прописано в соглашении об обследовании и моделировании:

• Обзор уровней моделирования. Я знаю компании, которые описывали уровни моделирования в едином уставе-договоре – там документ на 150 листов, где схлопнуты и устав, и соглашение о моделировании. И попробуй это прочитать и разобраться. Лучше выделять эту информацию в отдельный документ.

• Концепция ролей и полномочий. Люди не понимают, что такое концепция ролей, поэтому раскрывайте эту информацию подробнее – не просто словами, а примерами и схемами. Тогда они начнут понимать, что вы им дадите на выходе.

• Правила построения моделей автоматизируемых процессов исполнителем.

• Организационная структура.

• Бизнес-процессы.

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

В соглашение о моделировании также входит:

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

• Результат обследования/моделирования.

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

Жизненный цикл проекта. Этап обследования

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

Что должен делать РП в такой ситуации? Варианты ответов от участников воркшопа:

• Писать стейкхолдерам о возможном срыве сроков проекта.

• Организовывать встречу с рабочей группой, оговаривать доп. соглашения.

• Обсуждать с заказчиком ситуацию, проговаривать риски.

• Предлагать совместную читку протоколов с принятием решения.

• Кто-то даже предлагает сразу писать официальные письма о необходимости встречного исполнения от Заказчика, сдвигах сроков, приостановке работ.

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

Особенно это важно, если у заказчика еще нет зрелой практики работы с документацией. И тут на передний план выходит навык РП – быть в постоянном контакте, доносить риски, не теряя доверия.

Есть простая статистика: устная информация запоминается примерно на 20%, а письменная – на 30%. Вот и представьте себе – даже если вы как РП провели встречу, проговорили все ключевые моменты и мысленно «поставили галочку», заказчик мог воспринять и запомнить только 20% – то, что показалось ему наиболее понятным и близким. Он не нарушает договор злонамеренно – просто не успел вникнуть в детали.

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

Поэтому первично – если аналитики сигнализируют: «мы не можем моделировать – нет согласования по ключевым точкам», руководителю проекта нужно не затягивать, а инициировать встречу. Не сразу останавливать работы, а мягко донести: «У нас есть блокирующие вопросы. Без их согласования мы рискуем потратить время и ресурсы впустую». Да, официальное письмо можно держать в запасе – но использовать его стоит лишь тогда, когда все другие способы договориться уже исчерпаны.

Спросите у аналитиков: что именно не дает им двигаться дальше? Приведите конкретный пример на встрече с заказчиком. Например: «Мы до сих пор не знаем, будут ли ваши подразделения обособленными – это критически влияет на архитектуру решения».

Одна такая конкретика может дать больше, чем десяток абстрактных формулировок.

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

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

Что я рекомендую?

• Регулярные статус-встречи с согласованием отчетов. Хотя бы раз в неделю, на 15-30 минут, в зависимости от сложности проекта и бюджета. Это дешевле, чем разбираться с последствиями неурегулированных моментов задним числом. Также полезно фиксировать ключевые договоренности письменно – пусть это будет краткое резюме по почте, если проект небольшой. Такие резюме сэкономят массу времени, когда нужно будет восстановить логику решений.

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

• Риски сразу переводим в стоимость – через коэффициенты. Не стоит воспринимать управление рисками как подготовку к конфликту или суду. Риски – это часть взрослой и честной коммуникации. Прописывайте риски как со стороны команды, так и со стороны заказчика. Это поможет всем понимать зону ответственности. В устав проекта можно заложить коэффициенты, показывающие влияние рисков на сроки и бюджет. Например: риск задержки согласования увеличивает срок на X%, а нарушение определенного условия требует увеличения затрат на переделку на Y%. Фиксируйте на статус-встречах момент срабатывания риска, последствия и шаги по его снижению. Это позволяет перевести риск в конкретные деньги и обсудить возможные действия – до того, как ситуация станет критической.

• Обозначаем по рискам сроки, ответственность и последствия. В более зрелых проектах возможна практика «денежного выражения» рисков: если одна из сторон нарушает обязательства, это фиксируется в деньгах (штраф, компенсация и т.д.). В Европе это считается нормой. В России пока не всегда так, но если вы начинаете эту практику, объясняя и обосновывая – постепенно и заказчик, и команда начнут привыкать. Главное – фиксировать такие вещи письменно и честно: и со своей стороны, и со стороны клиента. И, конечно, чем дольше проект – тем выше риски «размывания» цели. Снижение интенсивности управления рисками часто ведет к увеличению срока реализации и потере фокуса. Поэтому лучше закладывать культуру управления рисками и регулярной коммуникации с самого начала. Это инвестиция в успешное завершение проекта

Что делать? Предложения участников воркшопа:

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

• Договориться о принятии протокола, а орфографию причесать в процессе.

• Провести в Zoom или очную встречу с заказчиком и править на ней.

• Устроить публичную читку протокола.

• Править орфографию совместно – почему бы и нет, если мы не продвигаемся. Когда вы как руководитель проекта приходите на встречу, берите документ с собой – чтобы можно было сказать: «Покажите мне, на что это влияет. Я согласен, что у меня аналитик может не быть абсолютно грамотным. Но разве это делает его плохим специалистом? Чем нам это мешает в работе? Можем ли мы зафиксировать какое-то резюме о принятии результата?» Решите этот вопрос на месте, покажите на примере, что слова переставлены: первично было так, а сейчас по-другому.

• Прописать в соглашение о моделировании количество итераций на исправление документов. Причем в шаблоне соглашения, который выложен в ТКВ, этот пункт есть – и там не просто рекомендации, там куски примеров – и для заказчиков, и для исполнителей. Берите это в работу. Можно даже прописать, что в документах, которые вы отдаете на согласование, вы правите только замечания заказчика. А все остальное после того, как замечания пришли, считается согласованным. И пропишите, что количество исправлений – два раза, а все последующие – либо платно, либо по отдельному согласованию. Фирма «1С» сама рекомендует так делать.

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

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

Иногда чрезмерное внимание к орфографии – способ самоутверждения, особенно со стороны некоторых юристов. Парадокс, но благодарность за такие «жалобы» может разрядить обстановку. Публичная похвала за внимательность – это не слабость, а инструмент управления отношениями.

Как можно исправить ситуацию:

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

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

• Организовать переговоры по соотношению приращения качества от исправления протоколов. Сесть с заказчиком и проговорить, на что влияет эта орфография. Напомнить ему, что он выбрал нас именно из-за сроков. Спросить, действительно ли это критично? Предложить варианты. Например, можно нанять технического чтеца – есть целые компании с услугами редактуры и корректуры. Это недорого, и иногда можно взять за свои средства. Но тут не забудьте про NDA – потому что когда мы привлекаем третье лицо, которое будет вычитывать, мы нарушаем NDA. Чтобы этого избежать, можно предложить заказчику: «Хорошо, давайте введем технического чтеца, но нам тогда нужен трехсторонний договор». На моей практике никто не соглашался на третью сторону, и в этой точке начинали проговаривать, что мы можем сделать.

Я, конечно, проверяю, чтобы специалисты, которых я нанимаю, умели писать – смотрю, как они работают. Но если там по грамотности двойка или тройка, ему будет тяжело работать с документами. И если он аналитик от Бога, то он, скорее всего, пойдет на сопровождение, а не на документацию – т.е. я как руководитель должна к нему отнестись по-другому.

Это, кстати, и вопрос к руководителю проекта: «А туда ли поставили человека?» Потому что он может быть очень крутым специалистом по интеграциям, но если он не умеет писать – это что теперь, увольнять человека, который действительно шикарен?

Жизненный цикл проекта. Прототип

Проект идет по плану: обследование завершено, мы переходим к демонстрации прототипа системы.

Это очень частая проблема: при демонстрации системы в производственной компании они ожидают увидеть, как будут работать их АРМ, и какие у них будут отчеты по управленческому учету. Их не устраивают только схемы и описания – им важно понять «живой» результат их планируемой работы с системой – хотя бы частично реализованный.

В результате, даже если РП со стороны заказчика все устраивает, функциональный заказчик не принимает модель. Да, сейчас можно закрыть этапы моделирования и прототипирования, но как с этим жить дальше?

Варианты от участников воркшопа:

• Нарисовать мокапы интерфейсов.

• Обсудить и показать этапность и объем работ на этих этапах. Составить доп. соглашение, если требуется.

• Показать работу прототипа визуально.

• Объяснить, что это разные этапы, разговаривать.

• Обговорить заказчику, что на этапе разработки будет ТЗ с детальным описанием АРМ.

Мнение участника, выступающего в качестве руководителя проекта со стороны заказчика:

«Работаем непосредственно со всеми функциональными заказчиками, кто не поддается. Если не можем самостоятельно согласовать с ними прототип, привлекается внутренний эксперт. Например, внутренний функциональный архитектор, который может аргументированно со своей позиции объяснить, что мы это принимаем. Или наоборот, что мы это не принимаем, и что нам нужно доработать, чтобы принять такую модель. Но заказчики, конечно, разные. У нас тоже есть вредные функциональные заказчики, с которыми бывает сложно договориться. Это удается только в коммуникациях – если дополнительно привлечь стороннего или внутреннего эксперта и попытаться прийти к какому-то варианту».

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

Опыт еще одного участника воркшопа:

«У нас был проект перехода с УПП на ERP, где производственники не увидели в модели, как им работать. Мы придумали для них этап “Функциональное тестирование” и разработали сквозной контрольный пример, чтобы участники рабочей группы заказчика самостоятельно под контролем наших аналитиков отразили этот сквозной пример в ERP. После этого они, во-первых, увидели себя в системе, во-вторых, выявили дополнительные функциональные разрывы – обратили внимание на то, что аналитик замоделировал не так или не так услышал. Этот дополнительный этап значительно снизил риск непринятия работ по прототипированию. Да, он потребовал дополнительных затрат, но оно того стоило».

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

Какие варианты можно предложить на этапе прототипирования:

• Один из наших любимых инструментов для отрисовки интерфейса – MAKER. Мы даже закрепили его использование в соглашении о моделировании. Прикладываем скриншоты интерфейсов, чтобы заказчик сразу понимал, как будет выглядеть его будущий АРМ. А при демонстрации прототипа показываем интерактивность – имитируем переключение вкладок, объясняем, что при нажатии на определенную кнопку открывается нужный раздел, а результатом будет конкретный документ. И хотя система еще «не живая», заказчику этого достаточно – его же не интересует, что там происходит с регистрами и логикой. Ему важно видеть наглядный результат работы. Если все это дополнительно увязать с BPMN-схемой, результат прототипирования выходит на качественно новый уровень.

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

• Бронирование страховых сумм до сдачи разработок. Такое в основном характерно для крупных проектов – когда заказчик соглашается подписать этап моделирования с условием, что 10% от стоимости этапа будут оплачены уже после реализации интерфейса в системе. В этом случае мы оформляем доп. соглашение о бронировании 10% от этапа моделирования. И когда на этапе разработки мы показываем заказчику интерфейс этого АРМ (еще не всю разработку, а только интерфейс), он выплачивает нам эти забронированные 10%.

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

Жизненный цикл проекта. Разработка

Прошли этап прототипирования, переходим к разработке.

Как мы пишем техническое задание? Кто как, да? Кто-то – больше на программистском уровне, кто-то – больше под требования. Хорошая практика – ориентироваться на рекомендации фирмы «1С», приведенные в ТКВ. Там, несмотря на бюрократию, полезные примеры, которые можно адаптировать.

Опять-таки, руководитель проекта на стороне заказчика – адекватный, конструктивный человек, но ему, возможно, не хватает навыков вести более жесткие переговоры внутри своей структуры – он просто упирается в корпоративную иерархию, которую не может преодолеть. Он просит функционального заказчика подписать ТЗ, а тот отказывается.

Все это осложняется тем, что в ТЗ обычно добавляется формулировка: «Все дополнительные разработки сверх указанного – за дополнительную плату». А у заказчика внутри компании – свои KPI, и все, что выходит за рамки ТЗ, автоматически ложится на затраты конкретного подразделения. Реакция функционального заказчика предсказуема: «Я не понимаю этот документ. Мне вообще эта система не нужна».

Что делать? Варианты ответов от участников воркшопа:

• Добавить в ТЗ раздел с функциональным описанием для заказчика.

• Сделать маппинг функциональных требований с ТЗ.

• Добавить в ТЗ для программиста описание юзер стори для руководителей.

• Сесть вместе с функциональным заказчиком и разобрать те моменты, которые необходимо переформулировать.

• Писать ТЗ понятным для заказчика языком.

• Разбить каждый раздел ТЗ на две части: «Шапка», где описаны бизнесовые требования: для кого решается задача, и какой результат хотим получить. И «Предлагаемое решение», где уже описана техническая часть для разработчиков

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

Единственное – я только частично могу согласиться с тем, что ТЗ нужно писать языком, понятным для заказчика. Потому что ТЗ мы пишем для программистов. И если опираться на судебную практику, то эксперт будет смотреть, насколько однозначно в системе реализовано то, что описано в ТЗ. А если вы будете писать ТЗ только на уровне пользователя, вы, скорее всего, эту экспертизу не пройдете. Поэтому я считаю, что техническое задание должно быть написано так, чтобы быть понятным и заказчику, и программисту.

Какие еще компромиссы можно предложить на этом этапе:

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

• Добавляйте в ТЗ сценарии тестирования. Мы, например, вносим тест-кейсы в тестовую базу, указываем в ТЗ конкретные ссылки, симулируя ожидаемый результат. Это помогает заказчику понять, что он получит на выходе, и упростить процесс приемки. Да, такое ТЗ требует больше времени и ресурсов, но оно действительно снижает риск недопонимания.

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

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

Жизненный цикл проекта. Опытно-промышленная эксплуатация

Итак, переходим к финальной стадии – опытной эксплуатации.

Что делать в такой ситуации? Варианты от участников воркшопа:

• Напомнить условия договора.

• Ссылаться на утверждённые документы.

• Согласовать реестр доработок, оценить, согласовать, работать. Активно поддерживать пользователей.

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

Конечно, еще можно договориться. Но уже максимально письменно – не просто на словах.

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

С одной стороны: проект уже запущен, пользователи начали работу. Но с другой стороны – именно в этот момент возникает кризис. И здесь уже, как говорится: «Поздно готовить три конверта». Помните старый анекдот?

Руководитель с командой уходит с проекта и оставляет преемнику три конверта со словами: «Когда дела пойдут плохо – открой первый конверт. Когда очень плохо – открой второй конверт. А когда совсем плохо – открой третий конверт». Преемник его спрашивает: «А что дальше?» – «Ты сначала пройди этот путь, а там поговорим».
Проходит несколько месяцев, у команды ничего не получается, пользователи недовольны, руководитель вспоминает о первом конверте. Открывает его, а там записка: «Вали всё на предыдущую команду». Пользователи поверили, успокоились.
Проходит еще несколько месяцев, система работает еще хуже, руководитель вспоминает о втором конверте. Там записка: «Вали все на фирму “1С” и кривые обновления». Пользователи опять поверили, пытаются работать дальше.
Проходит год – работа встала, система не запускается, руководитель вспоминает о третьем конверте. А там записка: «Пора писать три конверта».

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

Что делать на этом этапе?

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

• Оценивайте скорость реализации.

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

• Если вы проработали над проектом год (я сейчас говорю про средние проекты), и функциональность уже проработана и реализована на 80-85% – нужно запускаться. А дальше говорите заказчику: «Если вы не запускаетесь, вы попадете на обновления, вам придется оплатить следующий круг доработок и так далее. И, возможно, будет юридическое разбирательство на два года для обеих сторон. Давайте в этой точке будем взрослыми людьми и постараемся решить, что с этим сделать».

Таким образом мы с вами прошли весь жизненный цикл проекта и рассмотрели наиболее актуальные особенности каждого этапа.

Возможно ли на протяжении всего проекта оставаться в сроках, обозначенном бюджете и заявленном качестве?

На мой взгляд, положительный ответ на вопрос, озвученный в заголовке раздела, возможен, если опираться на следующие ключевые факторы:

• Четко определенные роли на проекте, закрепленные в уставе.

• Умение договариваться и находить компромиссы.

• Документация – как бы я к ней ни относилась, она действительно помогает.

• Регулярная актуализация статусов этапа и задач.

• И руководство проектом как образ жизни.

Конечно, еще важна ответственность, но мы же с вами все-таки не хирургией занимаемся, и от нашей работы не зависит чья-то жизнь. А если взрослые люди готовы учиться договариваться, понимать друг друга и делиться результатами – вы не только получаете удовольствие от внедрения, но и видите, как проект приносит реальную пользу.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.