Текст книги "Гибкое управление. Как перевести всю компанию на скрам"
Автор книги: Кен Швабер
Жанр: Зарубежная деловая литература, Бизнес-Книги
Возрастные ограничения: +12
сообщить о неприемлемом содержимом
Текущая страница: 2 (всего у книги 13 страниц) [доступный отрывок для чтения: 4 страниц]
Глава 2
Скрам для скрама
Итак, вы решились. Отлично! Вначале я расскажу о процессе внедрения. Потом – о стартовой встрече, с которой он начинается.
Во внедрении скрама участвуют скрам-команды трех типов. Первый тип – это единая скрам-команда, отвечающая за управление внедрением. Она называется командой перехода компании[4]4
В современных компаниях обычно говорят «команда изменения», а не «команда перехода», но в данной книге автор использует термины «команда перехода», «продукт перехода», «бэклог переходного продукта». Важно понимать, что значение, которое автор вкладывает в понятие «переход», полностью соответствует тому, что сейчас называют трансформацией компании. Далее в тексте и переход, и трансформация используются как взаимозаменяемые понятия. – Прим. науч. ред.
[Закрыть] (Enterprise Transition team, или ETC). Команды второго типа отвечают за выполнение работ по внедрению и за перемены в компании. Их называют командами внедрения скрама (Scrum rollout teams). Скрам-команды третьего типа создают продукты для компании. Это скрам-команды разработки (Scrum development teams). Команды этих типов исчерпывающе описаны в литературе по скраму. Все они используют для достижения своих целей скрам-процесс. В этой главе мы подробно остановимся на командах первых двух типов.
Высшее руководство компании – это скрам-команда ETC. Самого старшего руководителя называют владельцем продукта. Владелец продукта в скраме отвечает за управление работой скрам-команды. Управление осуществляется через перечень задач, бэклог продукта, который помогает команде каждый раз выбирать для исполнения задачу с максимальной ценностью. Владелец продукта должен уметь разрешать конфликты на общекорпоративном уровне, на уровне подразделений и на уровне сотрудников ради блага всей компании. Стейкхолдерами владельца продукта выступают все сотрудники компании. Скрам-мастер команды ETC поддерживает сплоченность команды и обеспечивает ее бесперебойную работу с помощью скрама. Он отвечает за правильную реализацию скрам-процесса. Это должен быть штатный, всеми уважаемый и толковый работник – человек, который знает о компании все. Он должен иметь твердое намерение внедрить скрам и уметь работать с людьми. Кроме него в команду ETC входят руководители подразделений: отделов разработки, кадров, администрирования и финансов. Если компания разрабатывает продукты и продает их внешним потребителям, в команду включаются руководители подразделений по управлению продуктами, маркетингу и продажам. Если продукты предназначены для внутреннего потребления, в команду включаются руководители бизнес-подразделений, которые используют эти продукты или инициируют их создание.
Команда ETC определяет цель для каждой итерации, или спринта, а потом все члены команды совместно работают над достижением этой цели. Общекомандная цель важнее индивидуальных целей членов команды. Если личные цели топ-менеджеров ставятся выше достижений команды, то преобразование компании может провалиться. Команда ETC способна добиться успеха, только если все ее члены совместно работают над достижением целей проекта. Перемены невозможны без сплоченной работы скрам-команд на всех уровнях, начиная с самого верхнего. Чтобы добиться перемен, члены команды должны доверять друг другу и в то же время быть готовыми пойти на открытый конфликт ради отстаивания наилучшего решения. Прекрасным пособием по такому типу командной работы служит книга «Пять пороков команды» Патрика Ленсиони[5]5
Ленсиони П. Пять пороков команды. – М.: Манн, Иванов и Фербер, 2021.
[Закрыть]. Эту простую в чтении книгу я рекомендую членам любой скрам-команды, но в первую очередь команды ETC.
Внедрение скрама происходит в соответствии с приоритизированным списком необходимых работ, который называют бэклогом переходного продукта[6]6
Он же бэклог трансформации, или бэклог изменений. – Прим. науч. ред.
[Закрыть] (Transition Product Backlog, TPB). TPB – это разновидность бэклога продукта, только в данном случае под продуктом понимается преобразование компании. Команда ETC определяет пункты TPB и пополняет их по мере того, как у скрам-команд разработки возникают трудности. Самый приоритетный пункт TPB – это запуск проектов разработки продуктов с применением скрама. Запустите их немедленно, не откладывая на потом. Остальная часть TPB касается работы, необходимой для внедрения скрама. Одни виды работ связаны с распространением скрама на все проекты и программы. Другие касаются организационных и технических новшеств, а также изменений в управлении продуктами. Третьи требуются для устранения препятствий, разрешения конфликтов и внесения изменений.
Команда ETC создает команды внедрения скрама: они выполняют задачи, связанные с преобразованием компании, самым приоритетным пунктом TPB. Команда внедрения может формироваться из руководителей или других сотрудников. Ее члены не обязательно посвящают работе в команде внедрения полный рабочий день, однако их доступность и компетентность определяют темпы внедрения скрама и скорость преобразования компании. Каждая команда назначает своего скрам-мастера. Роль владельца продукта для каждой команды на время каждого спринта берет на себя один из членов команды ETC.
Рис. 2.1. Организация переходного проекта компании
Спринт ETC длится две недели. В начале спринта команда внедрения выбирает для себя элементы TPB, обладающие высокой ценностью. Цель спринта в том, чтобы устранить препятствия[7]7
Речь идет о том, что значительную часть бэклога TPB могут составлять именно организационные препятствия, которые должна устранить команда ETC. – Прим. науч. ред.
[Закрыть] и внести в работу компании изменения, оптимизирующие производительность и эффективность. Эти спринты короче тех, что характерны для команд разработки и обычно занимают месяц[8]8
Со времени написания книги скорость разработки значительно выросла, и сейчас многие команды используют спринты продолжительностью две недели, а в особо быстро меняющейся среде и в случае очень коротких циклов обратной связи еще менее продолжительные. – Прим. науч. ред.
[Закрыть]. Краткосрочность спринта помогает команде ETC тщательнее следить за изменениями и их воздействием на работу компании. Команды внедрения скрама проводят ежедневный скрам (короткое собрание, формат и цели которого определены в «Руководстве по скраму»). Команда ETC тоже проводит ежедневный скрам, в ходе которого дает указания и помогает командам внедрения. Скрам-мастера команд разработки могут посещать ежедневные скрамы ETC, чтобы попросить помощи в устранении серьезных препятствий в работе.
Команды внедрения скрама могут быть постоянными или формируемыми ETC перед совещанием по планированию спринта. На совещании команды внедрения встречаются с командой ETC и обсуждают TPB внедрения, после чего начинается спринт. Высокоприоритетные пункты TPB иногда приходится разбивать на части, которые можно выполнить за один спринт. Все спринты по внедрению начинаются и заканчиваются в один и тот же день, чтобы работа была синхронизирована.
В конце каждого спринта проводится обзор, во время которого демонстрируются самые заметные изменения. Иногда команде внедрения нечем похвастаться. Это может означать, что в спринте были задействованы неподходящие сотрудники или что решению проблемы уделялось недостаточно времени. Бывает, что проблема в существующей формулировке или в текущих условиях оказывается слишком сложной. В таком случае команда ETC должна реструктурировать TPB, команду внедрения или то и другое, после чего повторить попытку.
Формально процесс внедрения скрама начинается с совещания по запуску скрама.
Совещание по запуску скрама
Совещание по запуску служит началом реализации проекта ETC, который должен обусловить успех внедрения. Оно длится три часа; участвуют в нем потенциальные члены команды ETC из числа перечисленных выше. Повестка дня включает в себя следующие пункты.
■ Обзор скрама. Обеспечивает понимание сути скрама всеми присутствующими.
■ Описание процесса внедрения. Информирование руководства о том, как работает команда ETC и каким образом она обеспечивает внедрение скрама.
■ Принятие решения. На совещании руководство принимает решение о продолжении процесса внедрения скрама.
■ Формирование команды ETC. Официальное определение состава команды ETC, а также времени и места встреч команды.
■ Запуск первых скрам-проектов. Отбор первых скрам-проектов для внедрения. Их должно быть много, они должны задействовать все подразделения, требовать интеграции и быть ориентированными на интересы компании. В этих проектах продукт начинает создаваться немедленно, а препятствия выявляются в процессе разработки.
■ Определение начальных пунктов бэклога переходного продукта (бэклога трансформации компании). Идентификация наиболее приоритетных видов работ. Эти пункты обычно предусматривают разработку бэклога продукта для всей компании, разработку и использование механизмов интеграции, а также отбор и обучение скрам-мастеров.
■ Формирование команд внедрения скрама. Определение состава сотрудников, которые войдут в команды внедрения скрама на первом этапе, и назначение члена команды ETC, ответственного за уведомление отобранных об их участии и о графике встреч.
■ Назначение первой встречи по планированию спринта. Выбор даты проведения совещания по планированию спринта, которое дает начало первому спринту. Лучше раньше, чем позже.
■ Закрытие совещания.
Более подробная повестка такого совещания приводится в приложении В: «Пример повестки совещания по запуску скрама».
Глава 3
Первый год
Мы разобрались, зачем и как внедрять скрам в компании. В этой главе рассматривается примерный график работ на первый год после внедрения скрама. Самым сумбурным вам покажется первый месяц, когда больше всего на свете хочется подождать, пока все будет более тщательно спланировано. Не ждите. Ведь проблемы, которые препятствуют повышению производительности и эффективности, никуда не уходят и делают свое черное дело. Внедрение может идти неидеально, но это самокорректирующийся процесс. По мере его самосовершенствования решаются и проблемы.
Первый месяц
Пришла пора провести первую встречу ETC по планированию спринта. Дата и время встречи были назначены на совещании по запуску скрама, описанном в главе 2. После проведения этого совещания члены команды ETC должны были сформировать команды внедрения скрама. Именно они вместе с командой ETC в полном составе участвуют во встрече по планированию спринта.
Бэклог переходного продукта (TPB), представляемый на первой встрече по планированию спринта, где определяются для выполнения первые виды работы, обычно содержит как минимум некоторые из следующих пунктов.
■ Довести до сведения всех сотрудников компании, почему осуществляется переход на скрам и как будет проходить его внедрение. Об этом нужно говорить как можно чаще и использовать все возможные способы информирования (раздаточный материал, совещания на уровне компании и подразделений, видеоконференции).
■ Разъяснить всем, как скрам повлияет на компанию в целом и на ее персонал.
■ Организовать для всех сотрудников компании обучение скраму и разъяснить им причины внедрения, планы и требования. Необходимо подчеркивать, что скрам – это не новая методика работы, а рабочий процесс, необходимый для улучшения компании.
■ Предоставить сотрудникам возможность задавать вопросы и решать проблемы, касающиеся скрама и его последствий.
■ Установить условия, которым должен удовлетворять проект, чтобы допускать использование скрама. Эти условия можно разделить на минимальные, средние и оптимальные, чтобы проект можно было начать до того, как абсолютно все будет готово для запуска. Включите в TPB пункты, касающиеся выполнения этих предварительных условий.
■ Определить первые проекты, в которых будет использоваться скрам.
■ Назначить для этих проектов владельца продукта, скрам-мастера и членов команды. (Все проекты начинаются с одной команды.)
■ Определить метрики скрама, механизмы сбора показателей и управления ими.
■ Начать создание бэклога продукта для компании[9]9
Речь идет именно о бэклоге трансформации (TPB), а не отдельно взятого скрам-проекта. – Прим. науч. ред.
[Закрыть].
■ Наметить кандидатуры скрам-мастеров.
■ Выработать политику вознаграждения для поощрения командной работы.
■ Разработать требования к отчетности по скрам-проектам.
■ Создать скрам-центр.
Некоторые из этих пунктов подробно описаны в приложении Г.
Встреча по планированию спринта занимает не весь рабочий день. Она завершается, когда, согласно правилам скрама, команды внедрения встретятся с владельцем продукта ETC, выберут и возьмут на себя обязательства по бэклогу первого спринта, а также разработают план выполнения этих обязательств (бэклог спринта). На рис. 3.1 показан процесс применения скрама.
Рис. 3.1. Процесс внедрения скрама
Процесс, изображенный на этом рисунке, используется из спринта в спринт для внедрения скрама во всей компании. TPB пополняется по мере того, как сотрудники больше узнают о работе, необходимой для внедрения скрама, а также по мере выявления препятствий и изменений. В зависимости от решимости компании и качества осуществляемого командой ETC руководства внедрение идет быстрее или медленнее и вызывает больше или меньше проблем. Внедрение скрама – это проект по преобразованию рабочих процессов организации, перевоспитанию людей, задействованных в этих процессах, и изменению культуры.
Примером может послужить Ford Motor Company, которая пытается изменить процесс планирования производства автомобилей. Руководит проектом Марк Филдс, который понимает, насколько трудно осуществить изменения. Марк нарисовал и повесил в штабе программы «Путь вперед» плакат, на котором написано: «Культура ест стратегию на завтрак»[10]10
Wall Street Journal, January 23 2006.
[Закрыть].
Итак, внедрение началось. На очереди первые спринты внедрения.
Второй месяц
К началу второго месяца проектов разработки с использованием скрама должно быть уже много. Смертный грех – откладывать проекты до тех пор, пока не будет полностью подобран персонал, готовы планы и составлены бэклоги продуктов. Немедленно запускайте первый спринт для проектов, которые наиболее важны для компании. Вы удивитесь, но продуктовые инкременты так и посыпятся из скрам-команд. В то же время причины, мешающие начать проект, можно определить как препятствия. Поместите эти препятствия в бэклог переходного продукта команды ETC и устраняйте их. А команды разработки будут заниматься созданием программного обеспечения. Не ждите, пока ситуация станет идеальной; она может быть всего лишь удовлетворительной, но все равно пригодной для использования скрама. Необязательно иметь все наготове, это нормально – вы не знаете, что встретится на пути и куда он приведет, но используете скрам как навигатор.
Скрам-мастер отвечает за устранение или исправление всего, что делает команду менее продуктивной. Кое-что он может исправить сам. Остальное скрам-мастер выносит на ежедневный скрам команды ETC. Там препятствия либо быстро устраняются, либо вносятся в бэклог переходного продукта (TPB) для приоритизации и последующего поиска решения. Помимо препятствий, отмеченных скрам-мастером, в TPB вносятся препятствия, обнаруженные командой ETC, как показано на рис. 3.2. В то время как команды разработки применяют скрам, команда ETC делает все, чтобы они стали более продуктивными.
Рис. 3.2. Внедрение скрама
По мере того как компания создает продукты с использованием скрама, текущая практика вступает в конфликт с принципами скрама. Скрам – это высоко оптимизированный процесс разработки продуктов, имеющий одно побочное преимущество: все, что мешает работе, выходит на поверхность. Скрам делает видимыми проблемные ситуации. Как правило, это давно существующие недостатки, о которых все знают и с которыми мирятся. Теперь они так бросаются в глаза, что не избавиться от них невозможно. Подобные моменты включаются в TPB.
В TPB часто вносятся изменения, поскольку то и дело возникают новые проблемы и неожиданные виды работ. Команда ETC постоянно пересматривает и приоритизирует TPB, чтобы отразить изменения. С каждым спринтом она формирует и реформирует команды внедрения, чтобы выполнить следующий приоритетный пункт TPB – так выглядит процесс внедрения.
Источники препятствий, попадающих в бэклог переходного продукта
Многие компании используют при создании продукта «водопадную» модель. Она предполагает тщательный сбор требований в начале проекта. Эти требования разделяют на относящиеся к архитектуре, проектированию, коду, тестированию и документации. Каждой из этих частей занимаются специалисты в соответствующей области. Результаты работы передаются в виде документации и артефактов. Может показаться, что «водопадные привычки» существуют только у разработчиков. На самом деле они формируются во всей компании. Клиенты привыкают к «водопадной» модели разработки. Отдел кадров привыкает формировать лестницы карьерного роста и расписывать должностные обязанности, соответствующие «водопадной» модели. Финансовый отдел привыкает к финансированию и мониторингу «водопадных» проектов. С внедрением скрама его принципы, практика и привычки вступают в конфликт с «водопадным» подходом. Все это требует изменения представлений сотрудников о работе и подхода к ее выполнению.
Такие препятствия возникают непрерывно. Едва устраняются «высокоприоритетные» помехи, на поверхность выплывают новые. С приходом и уходом персонала из компании появляются новые препятствия. С изменением рыночных требований или с возникновением другой стрессовой ситуации становятся видимыми очередные препятствия, снижающие производительность.
В приведенном ниже списке перечислены некоторые способы выявления препятствий.
■ Мозговой штурм. Соберите в одной комнате группу людей. Они легко назовут текущие проблемы. Это касается и руководителей высшего и среднего звена, и менеджеров проектов, и разработчиков. То, что делалось неправильно до внедрения скрама, будет неправильным и после. Разница в том, что перекосы будут выявляться чаще, приносить больше вреда и труднее поддаваться исправлению. Например, если действующих проектов больше, чем разработчиков, сформировать полноценные скрам-команды будет очень трудно. Чтобы решить эту проблему, запускайте только те скрам-проекты, в которых сотрудники могут быть заняты полный рабочий день.
■ Скрам-проект разработки. В процессе реализации скрам-проекта разработки команда и владелец продукта сталкиваются с препятствиями, о которых скрам-мастер должен сообщать не реже раза в день в ходе скрам-планерки (ежедневного скрама). Проблемы, которые скрам-мастер или команда не могут решить самостоятельно, включаются в TPB.
■ Конфликт. При запуске скрам-проектов часто возникают конфликты, так как сотрудники и подразделения расходятся во мнениях о том, как лучше выполнять работу. Если эти конфликты не гасить сразу, они разрастаются и снижают производительность. Например, аналитик привык к тому, что он пишет спецификацию и отдает ее на кодирование программисту, но при работе в одной команде это становится бессмысленным и непродуктивным.
А что, если?..
Проект внедрения скрама, возглавляемый командой ETC, может столкнуться с препятствиями, и тогда команды внедрения могут не справиться с изменениями, за которые взяли на себя ответственность. Иногда причина в том, что в команды внедрения набраны неподходящие сотрудники. В этих случаях следует пересмотреть их состав. Обладает ли команда надлежащим опытом и знаниями в соответствующей области? Знают ли вообще сотрудники, как нужно выполнять работу? Иногда члены команд внедрения перепоручают работу подчиненным или вообще самоустраняются. Они полагают, что перемены – это проблема, их не касающаяся. Однако в обязательства команд внедрения скрама входит именно осуществление перемен. Внесение изменений – их обязанность, они не имеют права перепоручать эту работу другим и обвинять кого-то еще в невыполнении обязательств. Если команды внедрения не готовы делать это сами, значит, они не годятся для такой работы. Распустите их и сформируйте команды из подходящих людей.
Может случиться, что изменение, обозначенное как цель спринта, слишком масштабно. Если так, предложите команде внедрения разделить ее на выполнимые части. Пусть команда выберет какой-либо из пунктов TPB и приступит к новому спринту.
Бывает и так, что запланированных изменений слишком много. С такой проблемой сталкиваются многие владельцы продукта: слишком много работы и слишком мало возможностей. В этом случае начните с приоритизации. Действительно ли в первую очередь выполняются самые важные задачи? Затем оцените состав команд. Можно ли включить в них новых продуктивных сотрудников? А потом сосредоточьтесь на прогрессе. Пусть многое еще оставляет желать лучшего, оглянитесь назад и порадуйтесь тому, сколько уже сделано. Не забывайте о терпении и выдержке. Все эти препятствия, вредные привычки и перекосы формировались годами. Безусловно, на избавление от них нужно время.
Какие бы препятствия ни оказывались на пути, теребите команды внедрения, требуя от них результата. Развесьте TPB по всей компании в местах, где его будет видно, – это может помочь. Под растущим давлением команды реорганизуют свою работу и станут более производительными[11]11
В современных аджайл-подходах к управлению командами слово «давление» является чуть ли не табуированным. Во время написания книги пуш-механизмы управления все еще превалировали над пулл-механизмами. Здесь автор имеет в виду, что необходимы точечные воздействия, которые могут подтолкнуть команды внедрения к верным решениям и действиям. Не стоит пугаться: это не давление на команду в авторитарном смысле. – Прим. науч. ред.
[Закрыть].
Третий месяц и далее
Отступите назад и посмотрите на все, что идет не так, на проблемы, с которыми сражаетесь вы и ваша компания. Распределите эти проблемы по двум столбцам: трудности, вызванные скрамом, и трудности, которые были всегда, а скрам только высветил их. Чаще всего на этапе внедрения почти все проблемы, с которыми вы боретесь, оказываются во втором столбце.
Скрам обеспечивает полную прозрачность. Все видно как на ладони. У вас есть полное представление о том, где производительность, продвижение к цели, компетентность сотрудников, готовность работать в команде ради целей компании или проекта, а также способность инженеров в срок выпускать готовый продукт ниже желаемых или ожидаемых. До внедрения скрама вы могли лишь подозревать, какие именно проблемы подрывают эти нематериальные активы компании, а теперь ясно видно, что снижает способность компании создавать и развертывать конкурентоспособную продукцию.
На этой стадии цикла внедрения многим кажется, что в скрам нужно внести изменения, что его нужно подстроить под особенности компании. Мой совет: не делайте этого. Правила, роли и тайм-боксы скрама немногочисленны и просты. Благодаря практике и структуре скрама выявляются проблемы, иногда весьма неприятные и трудно решаемые. Стремление изменить те аспекты скрама, благодаря которым тайные проблемы становятся явными, вполне естественно. Тогда все успокоятся и продолжат работать по старинке. Но, увы, если внести в скрам изменения, сама причина, по которой снижается продуктивность работы, снова скроется из виду. Всякий раз, посещая компанию, внедряющую скрам, я ищу отклонения от стандартной практики скрама и всегда нахожу ту самую проблему, которую компания предпочитает игнорировать.
По мере того как команда ETC вносит изменения, нередко идут на компромиссы между старыми и новыми способами ведения дел. Например, кое-где по-прежнему используют «водопадную» модель, хотя другие уже перешли на скрам. Однако важно, чтобы такие компромиссы были временной мерой и не превращались в привычный способ ведения дел.
Некоторые компании изменяют даже терминологию скрама, чтобы она лучше сочеталась с текущей практикой. Так они надеются смягчить слишком резкое воздействие перемен. К сожалению, обычно это воспринимается как знак того, что тенденция к переменам несерьезна. Например, если скрам-мастеров по-прежнему называть менеджерами проектов, они, как правило, продолжают считать, что отвечают за успех проекта и вправе указывать сотрудникам, что делать. Тем, кто привык к стандартной терминологии, лексикон скрама режет слух; он настолько необычен, что дает понять: изменения необратимы, и все теперь будет не так.
Возможно, чтобы решить некоторые проблемы, потребуется изменить способ ведения дел. Например, отдел продаж привычно просит инженеров быстренько слепить прототип, чтобы помочь закрыть сделку. Вроде бы это всегда работало и никому не мешало. Но скрам помогает увидеть влияние этого подхода на продвижение проекта во время первого же обзора спринта. Из-за того что команда тратит дополнительное время и силы на выполнение нестандартных запросов, она, скорее всего, не успеет выполнить взятые обязательства. Не исключено, что для удовлетворения запросов отдела продаж вам придется придумать другой механизм. Теперь, когда можно дать количественную оценку затрат компании на такие отвлекающие от работы моменты, вы, возможно, даже попросите отдел продаж обосновать создание прототипов с точки зрения затрат, ожидаемых выгод и вероятностей.
Некоторые из проблем не решаются с одной попытки. Если решение не идеально или же проблема видоизменилась и решение нужно пересмотреть, скрам тут же это выявит. Не пытайтесь сразу найти идеальное решение; «достаточно хорошее решение» действительно достаточно хорошо, чтобы заставить компанию двигаться к совершенству.
Вам и вашей команде менеджеров придется строить планы и схемы, чтобы найти лучшую тактику. Нередко полезны упражнения, помогающие людям понять, почему их повседневная работа так изменилась и что в этом хорошего. Пользу также приносит общение с другими, посещение организаций, которые успешно внедрили скрам. Возможно, потребуется разработать и утвердить метрики для поощрения и отслеживания изменений. Однако здесь следует проявлять осторожность: показатели могут иметь непредвиденные последствия для других областей. Ваша тактика не всегда будет действенной. Готовьтесь к тому, что одной попытки будет недостаточно и решение найдется не сразу.
В оставшейся части книги вы найдете идеи, варианты тактики и дополнительную информацию по внедрению скрама. Как вы уже поняли, внедрение скрама действительно оптимизирует работу компании – раз и навсегда.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?