Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий

Владимир Завертайлов, 2022

Максимально полный путеводитель по профессии российского project-менеджера. В нем Владимир Завертайлов, основатель и руководитель scrum-студии «Сибирикс», которая входит в Топ-10 лучших веб-студий страны, рассказывает, как управлять собственным digital-производством и грамотно руководить проектом, заказывая digital-услуги на стороне. А еще – как расти в этой профессии, опираясь на знания о продуктовых техниках и понимая потребности бизнеса. Из книги вы узнаете: – чем kanban отличается от scrum и при чем тут agile; – как управлять неуправляемым – дизайнерами; – что лучше: собственная команда или аутсорс и как быть с техподдержкой; – откуда берутся оценки времени и как понять, что исполнитель их завышает; – что такое декомпозиция, зачем она нужна на проекте; – как планировать экономику проекта, рассчитывать операционные затраты и анализировать P&L продукта. В карточку подгружен издательский PDF макет.

Часть 3

Пятиминутный scrum

Настало время кратко посмотреть на Scrum — фреймворк разработки проектов. «Фреймворк» означает, что в чистом виде, по книге, у вас это вряд ли заработает. Ладно-ладно, заработает, но не с первого раза. Его нужно будет настраивать и сращивать с вашими текущими процессами.

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

3.1. Схема scrum. Артефакты. Роли. Процедуры

Итак, продукт выпускается поэтапно. Сначала минимальная версия. Затем постепенно наращиваем функциональность.

Каждый цикл разработки называется Спринтом. Рекомендованная продолжительность спринтов — от 1 до 4 недель, подбирается экспериментально. Нужен ритм «рывок-отдых». В итоге каждого спринта должна получиться новая версия продукта с приростом функций — инкрементом.

Product Owner (Владелец Продукта) отвечает башкой за стратегию и приоритеты разработки. К нему поступают «хотелки» пользователей, метрики, жалобы, баги, идеи стейкхолдеров. Коллективная ответственность в расстановке приоритетов не работает. Но рутину вроде сбора обратной связи можно делегировать.

В Scrum-е нет нудного толстого технического задания, которое выполняется от корки до корки. Нет попытки предусмотреть все и сразу. Вместо ТЗ хотелки складываются в специальную табличку — Product Backlog — и сортируются по приоритетам с точки зрения бизнеса. Можно по ходу работы менять, выкидывать и добавлять функции.

Примерно так это выглядит:

Простой бэклог в Google Docs

Минимальный состав бэклога: хотелка и приоритет. Можно добавлять свои поля. Например, описание и предварительная трудоемкость. Чаще всего, в условных единицах — Story Point. Берем за 1 балл самую простую хотелку, все остальные оцениваем относительно нее. Бэклоги удобно хранить в Google-таблицах. Можно дать доступ команде и синхронизировать с таск-трекером типа Jira.

Приоритет — чем больше число, тем выше. При ручной расстановке приоритетов удобно делать между ними зазоры (100, 200, 500). Так проще будет вставлять хотелку между двумя другими. Одинаковых приоритетов, по классике, быть не должно.

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

Все заинтересованные лица могут добавлять что-то в бэклог. Но только Product Owner определяет приоритеты. Для этого нужно периодически просматривать бэклог, выкидывать оттуда мусор, обновлять приоритеты и улучшать формулировки.

Есть специальные методики приоритизации, снижающие субъективное мнение (галлюцинации) Product Owner о важности той или иной хотелки. Подробнее о техниках поговорим в главе 4.

RoadMap — предварительный календарный график выпуска релизов. Этого нет в Scrum, но без него картинка проекта теряется.

Как выглядит Roadmap

Команда разработки. По умолчанию имеются в виду программисты. Команда забирает верхнюю часть бэклога в работу, дербанит каждую хотелку на технические тикеты и оценивает. Мы используем Planning Poker, о нем чуточку позже. Так формируется бэклог спринта (Sprint Backlog) — то, что команда считает реальным сделать за следующий Спринт.

Задачи, попавшие в Sprint Backlog, менять нельзя. В отличие от задач из Product Backlog, в котором можно менять все что угодно до тех пор, пока команда разработки не заберет и не запланирует верхние хотелки.

Обычно Sprint Backlog у нас попадает на канбан-доску в тикет-системе. Это привычный многим инструмент, где есть карточки с задачами и колонки, соответствующие статусам работы. Как минимум это Plan, In Progress, Check, Done. Чертовски напоминает цикл Деминга.

Можно придумывать свои колонки, добавлять критерии готовности, чек-листы, ограничения одновременно выполняемой работы (WIP, work in progress) — тут все гибко.

Канбан-доска спринта в Jira

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

Команда — такой мини-спецназ в тылу врага. Компактная: рекомендуется не более семи человек. Кросс-функциональная: есть все компетенции, чтобы сделать проект. Самоорганизующаяся (упс!), самообучаемая и ответственная. Большие проекты дробятся на компоненты и распределяются по своим командам.

Ежедневно, в одно и то же время и в одном и том же месте, команда собирается на Стендап (Daily Scrum), где каждый по очереди отвечает на три вопроса:

1. Что было сделано вчера (для достижения целей спринта)?

2. Что будет сделано сегодня?

3. Какие есть проблемы?

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

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

Как проходят стендапы в «Сибирикс»

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

Тоскливо, когда на вопрос: «Что было сделано вчера», вам отвечают что-то вроде: «Я размышлял об архитектуре», перечисляют номера тикетов или закидывают техническими деталями. Пальцем, дружок, на экране покажи, что там нового напрограммировалось!

На стендапах удобно повесить перед глазами сформулированную кратко цель спринта — помогает сфокусировать команду не на микро-тикетах, а на цели.

И Burndown Chart (диаграмму сгорания), по которой видно, успеваем ли мы, или все пошло «через плохо». Эти и другие метрики полезны, но нос держим по ветру и чутко реагируем на то, что говорит команда. Управлять только через метрики не получится.

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

Намылить, смыть, повторить.

3.2. Внедряем!

Мы внедряли у себя Scrum в начале 2000-х, когда это еще не было мейнстримом, а про Agile не говорил Греф из телевизора. Наломали, конечно, дров, но быстро все исправили. Первое, что внедрили — итерации и стендапы с тремя каверзными вопросами. Скорость и управляемость сначала выросли, а потом упали. Команды начали либо грустить, либо бунтовать. В воздухе витало «ща долбанет». И долбануло бы!

А что не так? Не было ретроспектив. У команд копились вопросы «а зачем все это» и ощущение, что с них выдаивают результат. Этакая вечная сессия.

Начали проводить ретроспективы, объяснять, как устроен Scrum. Реально собирать обратную связь от команд. Решать их проблемы. Дали почитать литературу. Обучили Scrum-мастеров внутри команд и сказали, что теперь менеджеру можно говорить слово из трех букв («Цыц!»), если он нахальничает. И начало получаться.

Примерный план действий при внедрении:

1. Дать команде почитать про Scrum, какие есть роли и артефакты, и какие плюсы он дает.

2. Нулевая ретроспектива. Собрать команду. Обсудить ее проблемы. Посмотреть, сможет ли Scrum улучшить ситуацию, обсудить, как именно. Рассказать еще раз весь процесс. Ответить на вопросы. Распределить роли.

3. Организовать итеративную работу (спринты) и стендапы. Запретить менять постановки внутри спринтов. Для начала выбрать недельные циклы. Потом — откорректировать.

4. Приучиться расставлять приоритет, создать бэклог и регулярно его пересматривать. За основу можно взять ТЗ (если оно было) или смету, или просто собрать все хотелки проекта из головы в один файлик.

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

Я бы вообще начал внедрение Scrum-а с ретроспектив. Раз в неделю-две собирал бы команду, обсуждал проблемы и решал их, улучшая рабочий процесс. Глядишь, через месяц весь Scrum нормально заработает.

3.3. Подготовка и планирование спринта

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

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

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

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

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

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

Опытным путем мы пришли к тому, что нужно дать команде за час-два до планирования прочитать постановки и сформулировать вопросы. Ребята делать этого не любят и читают уклончиво. Логика такая: зачем напрягаться-читать, если на планинге все равно голосом проговорим. Мозг экономит энергию. Но если этого не проделать — планирование спринта может превратиться в многочасовой склочный базар. Приходится заставлять читать и думать. Как тренер в спортзале заставляет сделать пару дополнительных приседаний.

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

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

Размер задач зависит от опыта команды. Мне нравится, когда каждый день можно глазами посмотреть, что поменялось в проекте. Постарайтесь делать декомпозицию, чтобы задачи было просто проверить, а трудоемкость была от 1 до 8 часов (если вы оцениваете в часах, а не в Story Points). Опять же, не всегда получается, да и опытная команда будет сопротивляться такой мелкой разбивке. Опытным нужны крупные куски. Но для молодых и дерзких управляемость сильно возрастает.

Сугубо технические задачи, типа «Удали поле id из таблицы Users» — дрянь. Формулировки лучше делать на уровне фич: «Форма обратной связи» или «Отправка письма о восстановлении пароля».

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

Не старайтесь забить время спринта под завязку. Например, в двухнедельный спринт команды из трех человек засунуть задач на 240 часов. Лучше иметь небольшую подстраховку на код-ревью, рефакторинг, отладку и закон Мерфи. Про него известно, что он точно случится. Сколько взять подстраховки — зависит от опыта команды и задач. Нужно подбирать эмпирически. Начните с 20 %: не 240 часов, а 190. Через пару спринтов нащупаете свою реальную производительность.

Такая подстраховка не нужна, если вы работаете в Story Point. Она зашита внутри оценки.

Кроме разработчиков, на планирование я приглашаю тестировщика. Так он будет в контексте и меньше рисков, что под видом «багов» он насыплет команде отсебятины.

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

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

Карточки задач в канбан-доске спринта

Внутри каждой карточки уже развернутое описание.

Карточка задачи с детальным описанием

Очевидно, что процедура планирования занимает кучу времени. Поэтому я не люблю короткие спринты. Две недели, на мой взгляд, — в самый раз.

3.4. Planning Poker

Planning Poker — инструмент для оценки задач. Карты удобны тем, что участники команд не могут ориентироваться на мнение своих коллег — так оценки получаются максимально очищенными от субъективизма и влияния «авторитетов».

В колоде 4 разноцветных набора для 4 участников. Если участников больше — добавляем колоду.

Достоинства карт: 0 (значит задача готова или слишком мелкая), 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. Бывают карты с числами Фибоначчи или другой развесовкой, но мне нравятся эти.

Цифры — это либо часы, либо Story Point, в зависимости от того, как вы привыкли. Нам не нужно пытаться сделать сверхточную оценку. Это невозможно, скоро будут доказательства. Нам нужна адекватная оценка.

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

Карты Planning Poker (planningpoker.ru)

Далее карты вскрываются. Если оценки плюс-минус совпали — фиксируем их в задаче спринта. Если нет — надо обсудить дополнительно.

Например, кто-то выкидывает оценку гораздо большую, чем остальные. Он либо про эту задачу что-то знает-замышляет. Например, был хреновый опыт в прошлый раз или там в коде ТАКООООЕ! И надо его расспросить. Либо спит (разбудим). После обсуждений — уточняем нюансы и переигрываем кон.

Еще две специальные карты: Coffee/beer — если все затянулось, и надо сделать перерыв, и WTF — для джуниоров, которые вообще ни в чем не уверены.

При планировании спринта я предпочитаю физические карты. С удаленными — online-сервис или простой видеочат, куда на «раз-два-три» все скидывают свои оценки задач.

3.5. Стендапы. Burn Down Chart

Это простая диаграмма «сгорания» спринта. Ее удобно держать под рукой на стендапах.

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

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

3.6. Стратегии тестирования

Две крайности: отложить тестирование на конец спринта или тестировать каждую закрытую свежевыполенную задачу. Как говорил товарищ Сталин — обе хуже.

Откладывать на потом — плохая идея, однозначно! Вы можете забуксовать в самом конце, и у вас получится сырой спринт. Сдавать стыдно, выбросить жалко. Product Owner будет недоволен. А баги все равно придется фиксить.

Тестировать каждую мелочь сразу — тоже не круто. Во-первых, проверенную задачу могут поломать, когда будут делать какую-то другую. Это называется регрессией (regression bugs). Брукс в «Мифическом человеко-месяце» писал, что это фундаментальная (значит, толком нерешаемая) проблема — исправление одной ошибки с вероятностью 20–50 % влечет появление новой. Полное покрытие автотестами стоит неоправданно дорого, да и никто не даст на него времени. Надо дело делать, а не абстракциями заниматься.

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

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

Вы помните, мы добавили к задачам критерии приемки. Этакий чек-лист. Пусть его один раз прочекает разработчик при переносе задачи на проверку. Для самоконтроля. А затем еще раз проверит тестировщик.

Если команда зрелая, а бюджеты позволяют (для сайтов это почти всегда не так — всем дорого), покрывайте рутинные проверки автотестами. Или, как минимум, формализуйте тест-план для критических маршрутов проведением смоук-тестов на продуктиве. Например, в интернет-магазинах покрываем тестами маршрут Каталог → Карточка товара → Добавление в корзину → Корзина → Чекаут. Критических тестов не должно быть много, и они не должны занимать много времени. Но должны вселять уверенность, что ключевые функции в порядке.

В заказной разработке редко, но встречается клиент, который не видит ценности в тестировании. Речь идет не о манипулятивном приеме, попытках отжать скидки или загнать разработчика под плинтус («Я что, должен за ваши косяки платить?!»). А об искреннем непонимании, как возможно, что после тестирования, тест-кейсов и всех этих довольно дорогих процедур — я, как заказчик, нахожу ошибки. Причем такие, которые кажутся мне очевидными. Они меня бесят! Я не понимаю, на что тратятся время и деньги.

Совет

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

3.7. Демонстрация продукта. Завершение спринта

Говорят, в Царской России при испытании нового железнодорожного моста под него ставили всех строителей. А сверху пускали паровоз. Мосты век стояли. А разработчик — либо герой, либо — труп.

Нужно демонстрировать результат работы лично, ставить шкуру на кон! Это бодрит. Подстегивает ответственность и рост качества продукта. Боли, правда, будет больше. Но это полезная боль.

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

Со стороны бизнеса присутствует как минимум Product Owner. Пользователи и другие сочувствующие — допускаются. Со стороны разработки — вся команда. Понятно, что бывают исключения, но стремимся к этому.

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

Ради чего все это затевается: обратная связь в режиме реального времени. Пусть жесткая, но честная. По сути, обсуждается только первое впечатление, но оно не врет. WYSIWYG — What You See Is What You Get, или «если тебе кажется, что что-то не так, — скорее всего, тебе не кажется».

По опыту большая часть обратной связи будет конструктивной и позитивной. Особенно с англоговорящими заказчиками. Бояться демонстраций не надо. Надо готовиться. Продумайте чуть заранее:

▶ По каким путям проведете зрителей в продукте.

▶ Какие кейсы покажете.

▶ Какие могут понадобиться данные для демонстрации: контент, тестовые пользователи и так далее.

▶ Какие вопросы скорее всего возникнут. И как на них отвечать.

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

Мы же зафиксируем обратную связь и пойдем с ней на ретроспективу.

Аварийное завершение спринта

Редко, но гадко. Бывает, приходится останавливать спринт. Дело идет медленно и не туда. Команда упарывается, нужных доступов нет, кризис у клиента или еще какая-нибудь гадость. Дергаем стоп-кран, останавливаем спринт. Проводим ретроспективу, решаем проблемы. Делаем рескоупинг (перепланируем спринт). Едем дальше. Таких форс-мажоров допустимо не больше 5 %. Ибо нефиг.

3.8. Ретроспективы. Бородачи тоже плачут

Допустим, на демонстрации Product Owner разнес вашу работу в пух и прах. Справедливо, методично. Или просто очень эмоционально: он оказался злобным, неуязвимым говнюком. Команда сидит подавленная. Кто-то курит прямо в опенспейсе. Провал. Полный капут. «Что я тут делаю?» — читается в глазах бородатых программистов. Пятница, вечереет. Ваши действия?

Рохля разведет руками. Распустит команду по домам. Ага, щас! Мы пойдем в ближайший бар. И будем всякую фигню думать. Про процессы. Технологии. И ме-е-неджера. Рано его руководить поставили.

Люди будут смаковать неудачу, искать причины провала. На минуточку, не в себе, а в руководителе продукта, менеджере, проекте или процессах. Сами выберут такую позицию, когда они — Д’Артаньяны, а остальные — нет. И будут ныть. Пару-тройку раз повторятся такие ситуации, и дело разладится.

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

В скраме есть специальная активность, где мы с командой подводим и обсуждаем итоги спринта. Ретроспектива. Цель ретроспективы — не поныть (хотя иногда хочется), не выпить (хотя кому-то иногда необходимо), не байки потравить. А улучшить рабочие процессы.

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

Все не так. Им может не хватать ресурсов: времени, мотивации, энергии. В том числе квалификации, чтобы сделать на должном уровне. Вот с этим уже можно работать.

Итак, намеренно никто не гадит. На основе этой идеи вы должны гарантировать безопасность команде на ретроспективах. У людей должна быть уверенность, что:

▶ по итогам ретроспективы никого не накажут;

▶ на ретроспективе ни на кого не наорут, не затроллят и морально не опустят;

▶ за обсуждение проблем не посчитают слабаком (но только на ретроспективе — ежедневных нытиков отправим к мамочке);

▶ и так далее.

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

3.8.1. Формат ретроспективы

1. Подготовка

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

На 2-х недельный спринт и команду в 3–4 человека планируем минут 40–60. На месячные спринты или большие команды может уйти часа полтора. Я бы не советовал делать ретроспективы еще длиннее — это контрпродуктивно.

Иногда уместна пицца: задушевные разговоры за едой сплачивают команду и снижают уровень агрессии.

Один человек будет ведущим. Как правило — скрам-мастер или менеджер, если он совмещает эти роли.

2. Настройка

Первые пару минут включаем команду в групповой транс работу.

Здороваемся, налаживаем контакт. Например, задайте простой вопрос, типа «Как дела?». И получите хоть какую-то реакцию. Кивок головы или угрюмое: «Расскажи, дружок мой, Вова, отчего мне так хреново», это окей.

Альтернативные техники, которые мне нравятся:

1. 10-пальцевый опрос. Попросите всех выбросить на пальцах, насколько довольны текущим спринтом.

2. Happiness radar. Чертим матрицу 3×3. По вертикали — смайлики настроения. По горизонтали — Технологии, Люди, Процесс. Каждый ставит палочку, насколько удовлетворен каждым из аспектов. Стикеры нужны для фиксации предложений по ходу.

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

Напоминаем цель ретроспективы. Если есть новые участники, не привыкшие к ретроспективам — рассказываем про формат и гарантируем безопасность. Рассказываем про «намеренно никто не гадит».

3. Накидывание на вентилятор

Далее просим по кругу рассказать о плюсах (хорошем) и минусах (плохом) на спринте. Начинайте не с новичков. Идеи приветствуются и фиксируются, но не критикуются.

Знаю пару ребят, которые ведут блокнотики и записывают туда всю бяку по ходу спринта. А потом зачитывают по пунктам. Боюсь, что если прочитать вслух блокнотик от корки до корки, — явится ноющий дьявол. Но раз им так проще — пусть пишут.

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

Модерируем глупые споры, является ли озвученная проблема проблемой. Или про важность проблем. Вместо споров — просто фиксируем. Может, человеку это важно.

4. Подрывай!

Это не каноническая техника ретроспектив. Но иногда я так делаю.

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

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

Одна из интересных задач модератора — по косвенным признакам найти такой конфликт и вскрыть (взорвать) его. Еще дядька Макаренко завещал.

Впрочем, на ровном месте накалять не надо. И так, знаете ли, хватает!

5. Идеи. Генератор добра

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

Тут важно выделить две фазы, как в брейншторме:

1. обсуждение проблем и генерация идей по устранению проблем;

2. выбор среди тех идей, которые будем реализовывать.

В идеале, на каждый наш минус придумываем две-три идеи по его устранению. Собираем, аккуратно записываем. Могут помочь техники из главы 11 по работе с факапами.

6. Хороший план! Плохой план

Далее из идей выбираем несколько (5±2) конкретных улучшений, которые команда готова сделать. Устройте голосование, если идей целая куча. Желательно успеть за следующий спринт.

Некоторые типы идей я отсеиваю. Или прошу переформулировать.

1. «Мы работали плохо, теперь давайте работать лучше».

Спасибо за лозунги. Но я не знаю, как это реализовать.

2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».

Богатая идейка! Больше похожа на правило.

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

Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.

3. «Давайте будем закладывать больше времени на подготовку и архитектуру».

Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.

На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай — будет мало.

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

4. «Давайте проверять после тестировщика — другим тестировщиком».

Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.

Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!

5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».

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

С одной стороны, решение проблем команды и правда потребует менеджерского ресурса. С другой стороны, если после ретроспективы вы выходите с ворохом задач чисто для себя — тут явно какой-то косяк.

Надо помогать команде самостоятельно справляться с проблемами, а не быть еврейской мамочкой. Следите за тенденциями.

6. «Давайте все к черту перепишем».

Вот это происходит у меня прямо сейчас, в работающем проекте аптечной сети, где 5000 аптек, первая в стране доставка лекарств online, тысячи пользователей. Просто проекту 4 года, и там нет реактивного фреймворка. А это не так весело и круто. Программисту скучно.

То есть, идея предложена как бы во благо проекта, но чувствуется сильный личный мотив. Почесать ЧСВ, поиграть с технологиями, стать незаменимым и так далее. Словом, почувствовать себя крутым! Я не вижу ничего дурного в таких личных мотивах — они полезны. И без их удовлетворения не будет кайфа на работе.

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

7. «Пусть дизайнеры всегда теперь делают по-другому».

Это когда проблемы пытаются решить за счет отсутствующих на ретроспективе людей. Иногда — оправданно. Но! Естественно, отсутствующие будут не согласны.

Или придумываем правила, которые нужно распространить на всю компанию, а не только на одну команду.

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

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

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

8. «Не хочу я быть римскою папой,

А хочу быть владычицей морскою».

Ну, сорян:)

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

7. Заключительная часть Марлезонского кордебалета

Подводим итоги. Кратко зачитываем план. Спасибо, все свободны.

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

Можно спросить обратную связь на ретроспективу.

Если все недовольны решениями, ретроспективой — вы в беде. Очень жаль. Надо чинить ретроспективу.

3.8.2. Форматы фиксации

Мы используем три формата ретроспектив.

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

2) Формат с доской 2×2: плюсы-минусы, идеи, план. И стикеры.

Самое муторное потом — перенабрать писанину со стикеров и завести реальные задачи в тикет-системе. Но вы взросленькие, как-нибудь справитесь.

3) Электронные шаблоны.

Грамотный шаблон фиксации доступен в Confluence. Мы используем чуть попроще. Главное — вывести его на большой экран, чтобы все видели, как идет фиксация, и что ничего не забыто и не переврано.

3.9. Канбан. Когда лучше, чем scrum

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

Канбан-доска технической поддержки. Фрагмент.

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

3.10. Куда дели менеджера

В теории нет разницы между теорией и практикой. А на практике есть.

Йоги Берра

Допустим, мы создаем продукт in-house. Собрали разработчиков в одной комнате, сказали работать по Скраму. Самоорганизуйтесь там как-нибудь. Получится? Маловероятно. На хакатон дня в три, может, и хватит, а на полноценный продукт уже нет. И канонический скрам-мастер тут вряд ли поможет.

Самоорганизующейся команде нужен самоорганизатор.

Другой пример. Вот идет разработка. Ни шатко ни валко, по ТЗ. Скорость медленная, баги, Product Owner ругается, команда грустит. Решают попробовать Scrum, а вдруг поможет. Опять нужен кто-то, кто сможет все самоорганизовать, сшить старые процессы с новыми, перевести работу на новые рельсы. Это искусство, тут много дел.

Или, допустим, заказная разработка. Product Owner на стороне клиента есть. Как-то на одной из встреч представитель клиента сказал на полном серьезе: «Да, у нас есть Product Owner, их целых 5» (ой!).

Что ожидается со стороны подрядчика? Что будет кто-то ответственный за проект, с кем можно вопросы порешать. А то и вовсе Proxy-Product-Owner нужен, который за заказчика все порешает, всю обратную связь со всех этих пяти Product Owner (корректнее называть их стейкхолдерами) соберет, решит противоречия и в случае чего — по башке получит. П — перспективы…

Менеджер делает все то, что нужно делать, но что не делает никто другой.

Или, как минимум, организует и делегирует, чтобы делалось все то, что почему-то никто не делает.

Но вот команда взрослеет, Scrum уже отлажен, все привыкли друг к другу и процессу, есть внутрикомандный scrum-мастер. В этом случае роль менеджера действительно уменьшается. И во что он трансформируется — вопрос на вырост. Может, в скрам-мастера. А может, в продуктового менеджера, или аналитика, или помощника Product Owner.

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

Можно ли совмещать в себе несколько ролей сразу? Быть и скрам-мастером и Product Owner? Технически — да, я такое видел в молодых командах. Но это антагонистические роли. В них специально зашит конфликт. Product Owner хочет больше и быстрее от команды, и менять все в любой момент. Scrum Master хочет, чтобы команда спокойно работала, и процесс не ломался. Сможете вы такое в своей голове удержать (быть и добрым, и злым), или начнет шизофрения развиваться? Хорошего-то мало. Я бы начал выращивать scrum-мастера внутри команды. Благо — это несложно, дня за три можно справиться.

3.11. Аналитика, дизайн, разработка — параллельно

Обычно нужно несколько спринтов, чтобы получился MVP (minimum viable product) — минимальный жизнеспособный продукт. MVP должен быть клевенький.

Цепкий, энергичный менеджер может организовать параллельную работу над аналитикой, дизайном и кодом. В Scrum-е спринт по аналитике запускаем чуть заранее. За ним — дизайн. И далее уже код. Примерно по такой схеме (правда не факт, что у вас будет так много дизайна и аналитики, но вдруг?).

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

3.12. Документация

Agile-манифест (которому сто лет в обед) — набор правильных лозунгов, которые как-то надо адаптировать к практике:

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

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

Agile-манифест разработки программного обеспечения. 2001 год.

В зрелом продукте документация нужна, Agile это не отрицает. В небольших web-проектах и приложениях — можно и без нее. Степень замороченности прямо пропорциональна объему проекта, педантизму заказчика и ресурсам. Правда, документация всегда немного отстает от реальности, и это окей.

Работая над SingularityApp, например, я беру какую-то крупную хотелку из бэклога и расписываю, как бы я хотел, чтобы она работала с точки зрения пользователя. Это просто схемки интерфейсов на iPad, скриншоты похожих реализаций и немного текста. Если нужно докрутить формальности — отдаю аналитикам (с проверкой, чтобы не исказили идею). Там уже могут появляться прототипы, описание граничных случаев, интеграционные протоколы и так далее, если мне нужна такая степень проработки и формализма. Такие штуки удобно хранить в Confluence или википедии проекта. Подойдет и Google Docs.

Уже эти постановки дербанятся на технические тикеты (sprint backlog), и по ним рисуются интерфейсы. Confluence позволяет отправлять задачи в бэклог прямо из текста документов (правда, довольно коряво, но все же). Мелкие хотелки из бэклога можно так детально не разжевывать.

Кодерская и техническая документация, в основном, лежит либо в самом коде (the code speaks), либо в вики проекта.

Общее правило — положи документацию как можно ближе к месту ее использования.

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

Документацию важно увязать с тест-планами, чтобы QA не плодил свои постановки и хотелки.

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

На заказных web-проектах и мобильных приложениях такой контур слишком затратен, тут документацией должен стать сам код, бэклог, ТЗ или описания в Swagger. Хотя время от времени сложные, интеграционные моменты приходится документировать. Особенно, если реализуется API, с которым будут работать сторонние разработчики.

Документация требует времени, ресурсов, отдельного контура управления и внимания. Ну а хорошего технического писателя — днем с огнем.

Нужна ли документация на вашем проекте? Будете ли вы ее писать по ГОСТ 19 или ГОСТ 34, или стандартам ISO? Будете ли использовать UML или BDD-подход (Behavior-driven development, дословно «разработка через поведение»), язык описания сценариев Gherkin? Вопрос, на который не надо торопиться отвечать. Делайте минимально необходимое и дополняйте по мере необходимости. Не старайтесь заранее все предусмотреть.

ЧЕЛОВЕК, КОТОРЫЙ ВСЕ ПРЕДУСМОТРЕЛ

Однажды человек решил предусмотреть на сайте ВСЕ. ВСЕ тренды, вау-эффекты, поисковые рекомендации… да мало ли. Короче, все. Ну что б потом не переделывать. Это был очень предусмотрительный человек.

И на встречу со студией он решил прийти лично. Надел костюм. Пальто. Шляпу. Взял зонтик. Подумал и на всякий случай захватил солнцезащитные очки. Перчатки. Сотовый телефон. Две запасных батарейки. Это был очень предусмотрительный человек.

Взял пару бутербродов. Бутылку коньяка. Пачку презервативов. Хлоргексидин. Перочинный ножик. Вареных яиц. Ножовку по металлу. Бумажную карту Свердловской области. Аккуратно разложил это по карманам своей жилетки. И не надо думать, что это был какой-то уникум, типа Онотолия. Просто обычный человек, который всегда все предусматривал.

Аптечку. Лыжи. Акваланг. Ласты. Бинокль.

Вышел из дому. Стоит посреди лужи. И думает: «Блин, а все ли я предусмотрел на сайте?»

3.13. Метод красной рамки

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

Чтобы не возникало вопросов, что уже готово, а что — нет, рекомендую использовать метод красной рамки. Суть в том, что прописывается специальный стиль (например. todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса — кнопкам, полям, формам и т. д. — которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что — нет.

Этот метод работает и в заказной итеративной разработке. Заказчику не нужно будет постоянно объяснять, куда можно тыкать, а куда — нет. Если что-то не работает — мы четко разграничиваем ситуации «сломалось, баг» или «все под контролем, еще не реализовано».

Одна из первых итераций портала Северсталь. Поиск, вход, регистрация и переключение языков еще не реализованы.

Итак, плюсы:

1. Заказчик сразу видит, что готово, а что нет — не тратим время на объяснения, почему не работают некоторые поля.

2. Тестировщик понимает, какие блоки еще сырые, и не тестирует их.

3. У разработчиков не остается шанса промотать задачу.

3.14. Потому что карго-культ!

Во время 2-й мировой войны США строили свои военные базы по всяким разным диким островам в Тихом океане. Продовольствие и шмотки возились самолетами, причем часть груза просто сбрасывалась вниз. Ну, и кое-чего перепадало диким человекам, живущим на этих островах. Причем, иногда перепадало столько, что аборигены полностью забивали на свою хозяйственную деятельность, выращивание бананов и скотоводство. Туземцы быстро уловили, что американцы сами ништяки не производят, а все им достается с неба, за верность духам предков.

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

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

Не тем ли мы занимаемся, когда выполняем ритуалы, вроде стояния у канбан-доски по утрам или планирования с помощью карт Planning Poker, абсолютно не понимая смысла происходящего? Понимаете ли вы, какие выгоды дает каждый компонент?

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

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

3.15. Для тренировки

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

Задание — иди и внедряй!

Попробуйте это внедрить у себя. Посмотрите, что заработает сразу, а что — ни в какую. Проведите несколько спринтов и ретроспектив.

И постарайтесь не скатываться в СКРАМНО («у нас Скрам, НО без итераций») и Карго-культ.

Успехов!

Литература

▶ Джефф Сазерленд, «Scrum: Революционный метод управления проектами».

▶ Фредерик Брукс, «Мифический человеко-месяц».

▶ Антон Макаренко, «Педагогическая поэма».

▶ Скрамгайд в доступном переводе от Сибирикс (QR-код слева).

https://blog.sibirix.ru/2018/10/31/scrumguide-all/

Пояснения

Канбан-доска — инструмент метода разработки «Канбан», представляет собой доску, разделенную на этапы работ, с задачами в виде карточек, которые перемещают по доске по мере их продвижения по этапам.

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

Закон Мерфи — шутливый философский принцип, который звучит как: «Все, что может пойти не так, пойдет не так».

Story Point — метод оценки сложности задач, когда за 1 балл принимается самая простая задача, а все остальные оцениваются относительно нее.

Автотест (автоматизированный тест) — это скрипт, имитирующий взаимодействия пользователя с приложением, для локализации ошибок в работе сайта, приложения или ПО.

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

Продуктив — уже запущенный сайт, живущий на сервере заказчика.

Коммит — в системах управления версиями коммит добавляет последние изменения в часть исходного кода в хранилище, делая эти изменения частью основной версии хранилища.

Confluence — софт для для командной работы, удобный для распределенных команд за счет опций совместной работы.

SingularityApp — мощный хаос-менеджмент планировщик, разработанный в студии «Сибирикс». Существует в виде онлайн-версии для ПК и приложения для смартфонов на Android и iOS.

Википедия проекта — база знаний, где хранятся подробные руководства функционала продукта.

Консистентность документации — цельность документации и согласованность документов друг с другом.

Swagger — язык описания интерфейсов для описания RESTful API, который используется для проектирования, создания, документирования и использования веб-сервисов RESTful.

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

Язык описания сценариев Gherkin — человеко-читаемый язык для описания поведения системы, который использует отступы для задания структуры документа (пробелы или символы табуляции). Каждая строчка начинается с одного из ключевых слов и описывает один из шагов. Обработчик разбивает файл с тестами на функции, сценарии и входящие в них шаги.