Я видел требования с разных сторон: и как разработчик, который говорил «лучше без ТЗ, чем с таким», и как руководитель проектов, который тушил пожары, когда отчет по прибылям внезапно показывает еще и убытки, и как заказчик, который просил сделать «как в Excel», но чтобы это был не Excel.
В этой статье я расскажу о том, как не превратить проект в квест «Угадай, чего я хочу».
На изображении – цифры, от которых хочется плакать. Это исследование PMI о причинах провалов проектов. Респондентам нужно было выбрать не более трех причин, по которым проект «загнулся». Причин, конечно, много, про них можно говорить месяцами, но мы сосредоточимся на второй по популярности – сбор нечетких требований.
Это не единственное исследование. По разным данным, от 39% до 47% провалившихся проектов проваливаются в том числе из-за плохо собранных требований. Отчеты PMI, пусть и не новые – например, за 2017 год – до сих пор актуальны. Более свежие отчеты подтверждают ту же тенденцию: цифры немного меняются, но суть остается.
Во многих книгах по управлению проектами, аналитике и разработке также ссылаются на закрытое исследование IBM и Standish Group: стоимость исправления ошибки на этапе реализации может быть примерно в сто раз выше, чем на этапе проектирования и сбора требований. На мой взгляд, это некоторое преувеличение, но сама идея верная – исправлять ошибки на поздних этапах очень дорого.
Про полный набор навыков аналитика подробно рассказывать не буду. У меня есть карта навыков – куда идти, что читать, как развиваться. Но сразу предупреждаю: первый взгляд на эту карту обычно вызывает легкий ужас.
Управление участниками проекта: матрицы RACI и DASCI
Навыков у аналитика действительно много. При этом огромное количество материалов, книг и статей по теме почему-то не приводит к появлению большого числа сильных аналитиков. В своей работе я регулярно сталкиваюсь и с новичками, и с опытными специалистами – и проблемы у них часто очень похожие.
Я хочу сосредоточиться на небольшом, но важном блоке. Базу вроде «пять почему», ролевых игр, воркшопов разбирать не буду – это отлично описано у Карла Вигерса в книге «Разработка требований к программному обеспечению». К моему удивлению, ее легко найти – первая ссылка в Google ведет на полный текст.
Хочу поговорить о вещах, которые часто упускаются в проектах – из-за того, что кажутся ненужными, сложными или непонятными в применении. И первое – это матрица RACI.
Матрица RACI нужна не столько для фиксации ответственности, сколько для анализа: уровней ответственности, блоков задач, ролей и конкретных людей. Работая с ней, мы должны выявить несколько важных вещей:
-
Формальных и неформальных лидеров. Кто поможет нам на совещании, а кого лучше «вербовать» в неформальной обстановке.
-
Владельцев знаний и их заместителей. Увольнение или отключение ключевых сотрудников в процессе проекта – это не редкость. И если мы это не учитываем, часть требований может просто исчезнуть вместе с человеком.
-
Структуру управленческого влияния. Мы должны четко понимать, кто кому подчиняется и по каким вопросам. В сложных компаниях это неочевидно: формальный руководитель не всегда управляет сотрудником во всех аспектах.
-
И после этого мы должны найти слепые зоны в составе участников проекта. Очень часто вопросы есть, а отвечать на них некому – ни со стороны команды внедрения, ни со стороны заказчика.
После работы с матрицей RACI у нас получается примерно такая схема. Здесь она маленькая – всего несколько ролей, но в реальных проектах такие матрицы занимают целые стены.
Главное – определить процессы, их владельцев, исполнителей и участников.
Кроме RACI, в проектах часто полезна матрица DACI.
Матрица DACI отвечает на другой вопрос: кто и какие решения принимает в проекте. Часто бывает, что ключевой источник требований – не тот человек, который может их утвердить.
Вы собираете требования, приходите на согласование – а вам говорят: «Это вообще не мои требования. Я их просто собрал от других». И вам приходится идти к этим людям заново, проводить новые встречи. А если уже написано ТЗ – почти гарантирована переработка.
В DACI мы фиксируем: кто информируется, кто ответственен, кто является источником, а кто согласует. Это критически важно.
Кстати, альтернативой DACI может быть матрица коммуникаций – тоже полезный инструмент.
И важный момент: работая с этими матрицами, мы должны постоянно соотносить с ними требования. Если появляется требование с непонятным источником или непонятной схемой согласования – значит, матрицы нужно обновить и пройти этот этап заново.
Качество и актуальность требований
Когда мы собрали матрицы, насобирали требования, провели опросы, исследования, заполнили реестры – нам нужно избавиться от лишнего.
Первое, о чем стоит сказать, – формализация требований по чек-листам. С его помощью мы должны, во-первых, понять, соответствуют ли требования хотя бы базовым критериям (например, SMART). Но сам чек-лист может быть гораздо шире. У каждого он свой. Возьмите мой за основу, что-то уберите, что-то добавьте под свои задачи. И от проекта к проекту он будет становиться только лучше.
Наша задача – оценить качество требований. Не обязательно сразу их исправлять. Нам важно понять, какие они: плохие, хорошие, несогласованные, неподтвержденные. Потому что, понимая это, вы как аналитик или ваш руководитель проекта сможете принимать более объективные решения. Если требования не согласованы или не подтверждены нужными участниками – это критично.
Следующий момент – приоритизация по методу MoSCoW. Способов приоритизации много, я привожу этот как пример. Это такой аналог GTD из мира управления проектами.
Он состоит из четырех категорий:
-
M – Must have. Требования, без которых проект не взлетит.
-
S – Should have. Необязательные, но полезные вещи.
-
C – Could have. Разного рода «хотелки» – условно розовый интерфейс для бухгалтера.
-
W – Won’t have. Требования, которые все хотят, но не сейчас. Как корпоратив на Бали – идея хорошая, но не в этом квартале.
Дальше – прослеживаемость. Этого очень не хватает во многих проектах, где я работал.
Требования могут быть собраны, хорошо описаны, с изображениями и диаграммами. Но часто теряется история: откуда они появились, кто их предложил и почему.
Поэтому каждое требование должно иметь идентификатор – номер или код. Мы должны фиксировать его в разрезе ролей: какая роль его инициировала, кто конкретно (ФИО), когда оно было получено.
Проекты длятся по полгода, по году. Требование, собранное в начале, может стать неактуальным – изменилось законодательство, человек уволился, поменялись приоритеты. Это нужно учитывать.
Также важно фиксировать источник появления требования (например, конкретную встречу), чтобы в любой момент можно было вернуться и понять, что с этим требованием делать дальше.
И отсюда логично переходим к актуальности. До выхода в опытно-промышленную эксплуатацию мы должны регулярно пересматривать список требований и проверять, все ли еще актуально. Потому что если мы доходим до ОП, то любые изменения и доработки становятся очень дорогими.
И, конечно, на всем протяжении работы мы должны сверять требования с матрицами ответственности.
Практический кейс: оптимизация требований внедрения 1С
Я участвовал во внедрении 1С в федеральной сети аптек. Мы подключились к проекту в момент, когда требования уже были собраны. Начали погружаться, анализировать – их оказалось больше пятисот.
Дальше мы начали их приоритизировать, перепроверять, досогласовывать – и в какой-то момент выяснилось, что реально актуальных требований – около 150.
Возникает вопрос: как так получилось?
Очень просто. В проектах, особенно тех, которые перезапускаются, часто остаются «мертвые души» – люди, которые уволились или вышли из проекта. И часть требований просто некому стало подтверждать или принимать.
Другая часть требований оказалась фантазиями отдельных участников. Кто-то что-то набросал в Excel: «А давайте сделаем вот так». Но по факту это больше никому не было нужно.
В итоге значительную часть требований мы либо убрали, либо отложили на вторую-третью очередь внедрения. За счет этого удалось сэкономить существенную сумму – примерно треть стоимости проекта. В абсолютных цифрах это были миллионы. Если упростить – это как купить iPhone и получить второй в подарок.
Заказчик, конечно, был крайне доволен. При этом мы не потеряли требования окончательно – мы оставили возможность вернуться к ним позже, уже на этапе сопровождения и развития системы.
Инструменты аналитика
Хочу рассказать о четырех инструментах, которые помогают превращать требования в золото.
Первый – это карта пользовательских историй, или user story mapping.
Этот инструмент пришел ко мне из веб-разработки. В 1С он используется редко, и для меня это странно, потому что в вебе это практически базовый подход.
Карта пользовательских историй нужна для того, чтобы выстроить путь пользователя в системе через его действия. Если системы еще нет – значит, смотрим, как он работает сейчас. Например, в Excel: куда нажимает, что делает, что ему помогает, а что мешает.
На изображении показан пример процесса поиска товара и добавления его в корзину. Красным выделен основной путь, зеленым и голубым – улучшения, которые можно добавить.
Классический кейс – работа менеджера с РМК (рабочим местом кассира). Пользователь тратит до трех часов в день на поиск и подбор товара. Через user story mapping мы разбираем, почему это происходит. Иногда дело в обучении, а иногда – в системе. В одном из проектов мы добавили более умный поиск на основе статистики продаж, чтобы нужные позиции поднимались выше. В результате сэкономили время: человек стал успевать на обед и даже иногда пить кофе. Это уже хороший результат.
Следующий инструмент – прототипирование.
Почему прототипы важны? Приведу кейс. Мы внедряли HR-систему. Аналитик подготовил отличное ТЗ: таблицы, поля, диаграммы процессов – все подробно описано. Но заказчик и HR-отдел не смогли это согласовать. Они просто не понимали, как это будет выглядеть в реальности.
Мы перенесли этап дизайна системы на более ранний срок и сделали простейшие прототипы. Как только текст превратился в изображение, все резко стало понятнее. У пользователей сразу появляется реакция: они начинают спорить, предлагать, что-то убирать и добавлять. И это сильно ускоряет проект. Потому что большинство участников проекта – не технические специалисты. Им сложно представить, как таблица превращается в интерфейс. Поэтому прототипы нужно делать обязательно.
В 1С это даже проще, чем в веб-разработке. Можно брать внешние референсы: нашли похожую систему, сделали скриншот, показали.
Если есть возможность – быстро накидываем формы. Берем программиста и делаем простейший интерфейс без логики и кода. Это занимает немного времени, но сильно экономит ресурсы на этапе согласования.
Если программиста нет – используем 1С:Maker. Это отличный инструмент: можно и документацию писать, и процессы описывать, и формы собирать.
Если и его нет, рисуем как можем: в Paint, Excel – неважно. Да, это выглядит просто, но работает.
У меня был заказчик, бывший программист, который прислал техническое задание в Excel. В нем через ячейки была нарисована полноценная форма – очень детально. Мы всей командой аплодировали. Это реально помогло.
Третий инструмент – шаблоны схем бизнес-процессов.
Рисовать диаграммы с нуля на каждом проекте – это боль. Заказчик не понимает нотации, мы сами не всегда уверены, какую выбрать. Согласование превращается в мучение.
Поэтому важно накапливать свои наработки. Хранить их в базе знаний: Obsidian или любой другой системе – не принципиально. Если вы работаете в одной предметной области, процессы в проектах очень похожи. Диаграммы можно и нужно переиспользовать.
Если опыта пока нет – идем в интернет. Например, в Business Studio есть большое количество типовых схем процессов. На изображении – пример процесса заключения договора оттуда.
Такие схемы удобно брать за основу: когда у вас есть заготовка, мышление работает быстрее. Вы что-то убираете, что-то добавляете – и получаете нужный результат.
Там же есть модели процессов для производственных компаний, описание работы 1С ERP и более детализированные платные схемы. Они стоят недорого по меркам проекта, но экономят большое количество человеко-часов и сильно упрощают работу аналитика.
Четвертый инструмент – искусственный интеллект.
Многие уже пытались с ним работать, но сталкивались с тем, что результат нестабильный: один раз из десяти получается что-то полезное, остальное – нет. Возникает ощущение, что это какая-то магия, которая не дает повторяемого результата. Поэтому здесь нужен навык.
В своей работе мы активно используем ИИ. Часто я вижу, как его используют ученики: они присылают решения задач, сгенерированные ИИ. И это, как правило, слабый результат. Неэксперт не может с помощью ИИ качественно решить экспертную задачу – он не способен проверить итог. Поэтому такие попытки не проходят, но люди все равно продолжают пробовать.
Для распознавания аудио- и видеовстреч можно использовать бесплатный Whisper: немного настроить – и он уже работает. Дальше подключаем ChatGPT для создания резюме. Либо используем специализированные сервисы вроде Timelist.
Это экономит огромное количество времени. Раньше на встрече обязательно нужен был человек, который ведет протокол. Сейчас эту роль можно убрать и направить ресурсы на более полезные задачи.
Но основной кейс – это личный ассистент по проекту. В ChatGPT есть функциональность «проекты», куда можно загружать документацию, переписку, материалы. Все это становится единым контекстом, с которым можно работать. Не нужно каждый раз заново загружать информацию – это сильно упрощает жизнь.
Я сейчас участвую в проекте внедрения базы знаний с ИИ и это полностью меняет подход к работе с информацией. В базе лежат документы, статьи, файлы, и можно не пользоваться полнотекстовым поиском. Вы задаете вопрос – и получаете ответ со ссылками на источники. Если информации нет – система честно об этом говорит и почти не галлюцинирует.
Если такой базы нет – можно собрать ее самостоятельно. Загружаем в ИИ документацию, переписки, почту, расшифровки встреч. В мессенджерах обычно есть экспорт истории – этим тоже можно пользоваться.
Чтобы повысить качество ответов, важно добавлять в контекст профильную литературу. Например, если вы работаете с ERP, добавьте соответствующие книги. Если область широкая – ту же книгу Карла Вигерса. Тогда ответы становятся гораздо точнее.
Также ИИ можно использовать для проверки документации. Загружаем чек-лист требований и прогоняем через него новые документы.
Подведем итоги
-
Трекер задач и Wiki. Каждое обследование – это задача со своими подзадачами и артефактами. Артефакты сохраняем в базе знаний и связываем с задачами. Это позволяет легко понять, откуда появилось требование, когда и в каком контексте.
-
ИИ. Постоянно дополняем контекст и используем его как помощника.
-
Шаблоны процессов. Без них вы каждый раз будете начинать с нуля.
-
Прототипы. Лучше один раз показать, чем долго объяснять.
-
Чек-листы самопроверки.
-
Формализация на любой вздох. Если вы формализуете требования, все остальные инструменты начинают работать в связке. Без этого эффекта не будет.
Если коротко:
-
Копайте глубже. За формулировкой «хочу как в Excel» может скрываться «я ненавижу вводить данные вручную». И это уже совсем другая задача.
-
Визуализируйте. Изображения сильно упрощают коммуникацию.
-
Документируйте. Требование без идентификатора – как обещание на Новый год: через неделю никто не помнит.
-
И главное: ИИ не заменит вас как специалиста. Но вас заменят специалисты, которые умеют им пользоваться. Поэтому изучайте его. В начале будет сложно, результат будет нестабильным. Но если разобраться, это становится очень удобным инструментом.
И в завершение. Требования – это не строки в ТЗ. Это чья-то боль. Ваша задача – не просто написать документ, а сделать так, чтобы бухгалтер больше не матерился.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.