Текст книги "Scrum без ошибок"
Автор книги: Илан Голдштейн
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +16
сообщить о неприемлемом содержимом
Текущая страница: 4 (всего у книги 15 страниц) [доступный отрывок для чтения: 4 страниц]
Например, в одной из команд, с которой я работал, у нас был набор «домашних правил» (см. рис. 2.7), которым мы все следовали.
Рис. 2.7. Визуализация правил совместной работы напоминает участникам команды, как они должны относиться друг к другу
ВСЕ ЗА ОДНОГО И ОДИН ЗА ВСЕХ!
Я всегда подмечаю тот волшебный момент, когда понимаю, что я больше не среди группы индивидуальностей, а в единой, сплоченной команде. Момент, когда этот «пазл» складывается, порой возникает во время интенсивной, но дружелюбной дискуссии. Однако чаще это случается, когда все веселятся, наслаждаясь шуткой или двумя. Видеть, как пазл складывается, – мой любимый момент. Именно тогда возникает братство мушкетеров и все участники команды чувствуют, что они в одной лодке, знают и верят, что победят или проиграют вместе как команда.
Заключение
Три лайфхака этой главы посвящены выбору тактики, инструментам и советам, которые помогут вам и вашей организации оценить базовые компетенции и способности, необходимые команде для эффективной работы даже в экстремальных ситуациях. Давайте вспомним, какие вопросы мы рассмотрели.
Лайфхак 4. Искусный scrum-мастер
• что значит быть настоящим лидером-слугой;
• ключевые навыки, необходимые выдающемуся scrum-мастеру;
• врожденные установки, которые демонстрирует настоящий scrum-мастер.
Лайфхак 5. Рок-звезды или студийные музыканты?
• потенциальные проблемы ярких разработчиков-одиночек (рок-звезд);
• почему мы хотим, чтобы наши разработчики думали и вели себя как студийные музыканты;
• набор ценностей, которые должны сформировать профессиональный тип вашей команды.
Лайфхак 6. Выстраиваем команду
• рекомендуемый размер команды и соотношение групп разработчиков в ней;
• проблема частичной занятости и как ею управлять;
• факторы, которые важно учитывать, принимая решение, может ли scrum-мастер работать более чем с одной командой.
Глава 3. Защищаем команду и планируем спринт
Итак, ваша компания готова применить Scrum и вы собрали команду, обладающую всеми необходимыми компетенциями и демонстрирующую приверженность работе. Настало время двигаться дальше.
Три следующих лайфхака не только помогут задать команде правильный курс, но и дадут несколько советов и рекомендаций, как удержать проект на плаву.
Лайфхак 7 «Закладываем фундамент для Scrum» содержит несколько рекомендаций, как заложить прочный фундамент, который обеспечит эффективность вашей scrum-команды.
Лайфхак 8 «Планируем спринт и двигаемся по плану» дает конкретные практические советы, как эффективно спланировать спринт.
В лайфхаке 9 «Разоблачаем препятствия» я привожу рекомендации, с помощью которых вы сможете контролировать те трудности, которые возникают во время спринта и мешают достичь целей.
Лайфхак 7. Закладываем фундамент для Scrum
Работа со scrum-командами чем-то похожа на химию: так же как в научной лаборатории, успешные «химические реакции» намного легче запустить, если у вас есть все необходимые реактивы и условия для работы. Как проницательно отмечает Майк Кон: «Чтобы пожинать плоды Agile, нужны глубокие изменения. Эти изменения требуют многого не только от разработчиков, но и от всей компании».
Давайте рассмотрим некоторые ключевые организационные предпосылки и особенности рабочей среды, которые станут частью вашего плана по применению Scrum.
ПОДДЕРЖИВАЙТЕ СТАБИЛЬНОСТЬ КОМАНДЫ
Том Демарко и Тимоти Листер заклинают любую организацию, которая хочет создавать сплоченные команды: «Оберегайте и защищайте успешные команды».
Признаю, я работал со scrum-командами, проекты которых считаю не слишком успешными. Я легко могу назвать причину неудовлетворительного результата: это моя неспособность как scrum-мастера поддерживать сплоченность команды в течение всего проекта. Такая проблема часто возникает, когда ключевых разработчиков перебрасывают с текущего проекта на более срочный (см. рис. 3.1). Иногда эту ситуацию может усугублять затянувшаяся реорганизация компании (которую все чаще и чаще можно наблюдать во время мирового финансового кризиса). Совокупность этих двух факторов становится настоящим вызовом для тех, кто призван оберегать и сохранять сильные команды.
Рис. 3.1. Остерегайтесь «более срочных» проектов, которые пытаются утащить участников вашей команды
Демарко и Листер так оценивают потери от ротации сотрудников: «Объективно в нового участника команды вы будете вкладываться приблизительно три месяца, которые вы потратите на обучение и адаптацию новичка». И эта оценка не учитывает такие мало поддающиеся измерению издержки, как снижение скорости работы, демотивация участников команды или потеря ценных, но не задокументированных знаний.
ОБУСТРАИВАЙТЕ РАБОЧУЮ СРЕДУ
Без сомнения, многими моими самыми успешными scrum-проектами становились те, в которых я смог физически отделить scrum-команды от остальной организации.
Демарко и Листер разъясняют, почему это правильно:
Почти всегда имеет смысл вывести команду проекта… из общего корпоративного пространства. Работа в своем особом пространстве позволяет сохранить больше энергии и, соответственно, демонстрировать более высокие результаты. Люди меньше страдают от шума, меньше отвлекаются и меньше страдают от фрустраций.
Я работал со scrum-командами, которые были вынуждены взаимодействовать в большом open space – рядом с отделом продаж, сотрудники которого висели на телефонах целый день, – и так каждый день. У меня также были команды, пострадавшие от отдела снабжения, который не позволил им перенести несчастный маленький круглый стол для встреч к себе. Я мог бы и далее приводить примеры, но суть в том, что отделение и независимость своего рабочего пространства внутри офиса – это святой Грааль.
Независимо от того, сможете ли вы достичь этой высокой цели, вы должны сделать все от вас зависящее, чтобы scrum-команда находилась в одном помещении и все ее участники сидели рядом. Scrum, безусловно, может работать и для распределенных команд, которые не собрать в едином пространстве, однако это не оптимальный вариант.
Помимо очевидных преимуществ работы в общей среде, когда вы находитесь в непосредственной близости друг от друга, Джеймс Шор и Шейн Уорден приводят еще более вескую причину, почему команда должна сидеть вместе:
В лайфхаке 3 более детально рассмотрены другие ключевые моменты организации пространства, благоприятного для Scrum.
ОЦЕНКА – ЭТО НЕ ГАРАНТИЯ
Как выглядит неудачный сценарий? Заказчик проекта подходит к случайно выбранному участнику команды и спрашивает, сколько времени займет разработка фичи XYZ. Тот снимает наушники; отрывается от того, над чем работает; поднимает взгляд к потолку и выдает очень приблизительную оценку – чтобы хоть как-то успокоить заказчика. И – подумать только! – оценка оказывается неточной. А заказчик начинает давить на всю команду, чтобы та – в соответствии с этой оценкой – выполнила взятые на себя «обязательства». Но пошло оно к чертям, если цена таких «обязательств» – переработки и пропущенный выпускной вашего ребенка!
Экстренное сообщение: оценка ничего не гарантирует. В противном случае не было бы необходимости в самом слове «оценка». Оценка – это только прогноз, основанный на доступной информации и вводных данных в заданный момент времени. Это должно быть четко понято стейкхолдерами проекта, прежде чем он будет запущен.
РАБОТА ПО ЛЮБВИ
Мэри и Том Поппендик, авторы Leading Lean Software Development, выделяют два типа компаний: компании, где работают за деньги, и компании, где работают по любви (по взаимности).
В компаниях, где работают исключительно за материальное вознаграждение, сотрудники считают так: «Я прихожу на работу, и вы мне платите за мое время. Если вы хотите от меня большего, платите больше». В компаниях, где работают «по любви», совершенно другие стандарты: «Я буду относиться к вам так же, как вы ко мне. Я ожидаю справедливой компенсации за свою работу. Однако, если вы хотите от меня внимания и лояльности, тогда и компании следует проявлять заботу и поддержку по отношению ко мне, помогая полностью раскрыть мой потенциал[32]32
Poppendieck M., Poppendieck T. Leading Lean Software Development: Results Are not the Point. Boston: Addison Wesley, 2009.
[Закрыть].
Лучшие scrum-команды состоят из преданных и внимательных людей. Очевидно, что компании, использующие модель «работы по любви», в отличие от тех, где люди работают исключительно за деньги, более успешны при использовании Scrum, особенно в долгосрочной перспективе.
ПОДДЕРЖИВАЙТЕ УСТОЙЧИВОЕ РАЗВИТИЕ
В лайфхаке 1 я рассказывал, что один из ведущих принципов Scrum – работа в устойчивом темпе.
Это же отмечает Роман Пихлер в книге «Управление продуктом в Scrum»:
Разработка продукта похожа на марафон. Если вы хотите прийти к финишу, вы должны набрать устойчивый темп. Многие владельцы продукта совершают ошибку и давят на команду, чтобы она взяла больше работы[33]33
Пихлер Р. Управление продуктом в Scrum. Agile-методы для вашего бизнеса. М.: Манн, Иванов и Фербер, 2016.
[Закрыть].
Любая компания, которая поддерживает культуру сверхурочной работы и не просто поощряет ее, а еще и оплачивает в смехотворном размере, нарушает один из принципов Scrum (или, если уж на то пошло, любого другого agile-фреймворка). Сверхурочная работа должна быть исключением, а не правилом, и, как признает Кент Бек в книге «Экстремальное программирование», это «симптом серьезной проблемы в проекте»[34]34
Бек К. Экстремальное программирование. Разработка через тестирование. М.: Питер, 2017.
[Закрыть], а не обычное дело.
ЗАПУСКАЕМ ПИЛОТНЫЙ ПРОЕКТ
Я не сторонник резкого внедрения Scrum (одним махом), хотя и у него есть свои преимущества. Вместо этого я предпочитаю запустить пилотный проект. Рекомендую такой подход даже в тех случаях, когда руководство рвется в бой и хочет сразу перевести всю компанию на работу по Scrum. Почему я советую инвестировать дополнительное время в пилотный проект? Потому что это отличный способ подтвердить, что Scrum работает, и убедить руководство «купить» эту идею. Майк Кон прекрасно объясняет:
Пилотный проект запускается для того, чтобы «проторить путь» следующим проектам; он становится проводником изменений и показывает, как делать что-то новое… В рамках отрасли в целом у нас достаточно доказательств, что Scrum работает; но что действительно нужно узнать компаниям – как Scrum будет работать именно у них[35]35
Кон М. Scrum. Гибкая разработка ПО. Описание процесса успешной гибкой разработки программного обеспечения с использованием Scrum. М.: Вильямс, 2016.
[Закрыть].
Я всегда запускаю пилотные проекты, прежде чем переходить к работе с большим количеством команд. Собственно говоря, без свободы экспериментировать, которую открывает пилотный проект, я не уверен, что эта книга вышла бы в свет.
Заманчиво выбрать в качестве пилотного проект, который не имеет большой ценности для компании и, следовательно, не несет с собой практически никаких рисков. Но это иллюзия. Шор и Уорден не советуют так делать:
Избегайте делать пилотным проект, имеющий низкое значение для компании. Вам будет сложно привлекать заказчиков и эффективно настраивать процессы. И даже если вы с методологической точки зрения достигнете успеха, компания может посчитать проект провальным.
Возвращаясь к обсуждению стабильности команд и неуспешных проектов, в которых я участвовал, могу сказать, что причину, по которой я не смог сплотить команды, следует искать именно в пилотных проектах. Те пилотные проекты, над которыми мы работали, не имели ни высокого приоритета, ни большой ценности для компании. Когда наступил критически важный момент распределения ресурсов и пришлось выбирать между пилотным и «более важными» проектами, догадайтесь, кто вынужден был уступить.
Как долго должен продолжаться пилотный проект? Если вы внимательно читаете эту главу, то уже знаете, что пилотный проект не должен отличаться от любого другого значимого проекта. Как утверждает Роман Пихлер: «В Scrum нет правила, которое определяло бы длительность проекта. Но, как правило, он длится от 3 до 6 месяцев»[36]36
Пихлер Р. Управление продуктом в Scrum. Agile-методы для вашего бизнеса. М.: Манн, Иванов и Фербер, 2016.
[Закрыть].
СФОРМИРУЙТЕ РЕАЛИСТИЧНЫЕ ОЖИДАНИЯ
Изменения требуют времени, и часто приходится делать шаг назад, чтобы потом продвинуться на два вперед. Применение Scrum требует значительных изменений в мышлении и отказа от давно укоренившихся привычек. А это не происходит в одночасье.
Должно пройти время, прежде чем разработчики начнут чувствовать себя комфортно в кросс-функциональных командах, а старый командно-административный подход исчезнет. Вот почему компаниям следует отбросить наивность и не рассчитывать, что в ближайшем будущем они увидят невероятные результаты.
Быть терпеливыми и пестовать ваши изменения и команду – таковы правила игры. И те компании, которые умеют оказывать поддержку и создавать благоприятную среду, пожнут плоды своих усилий в ближайшем будущем.
Лайфхак 8. Планируем спринт и двигаемся по плану
Вспоминая аналогию с химической лабораторией, Демарко и Листер рекомендуют следующий «химический элемент» для создания процветающей организации – чувство выполненной работы. Я полностью согласен с их советом и предлагаю еще один, дополняющий элемент – старт с чистого листа.
К счастью, формат спринта позволяет как перезагружаться и каждый раз делать новый старт, так и чувствовать удовлетворение от завершения работы в конце спринта. В этом лайфхаке мы рассмотрим один из процессов Scrum, который позволяет делать такие регулярные перезагрузки, – планирование спринта.
Благодаря совместному перепланированию целей для нового спринта каждые несколько недель команда может каждый раз начинать заново – вместо того, чтобы застревать в кажущейся бесконечной и однообразной текущей работе. Более того, отсутствие регулярных и ожидаемых встреч по планированию спринта приводит к полной неразберихе – участники команды начинают собираться спонтанно для планирования и проектирования.
УТОЧНЕНИЕ БЭКЛОГА ПРОДУКТА
Прежде чем команда соберется для планирования, рекомендую убедиться, что бэклог продукта должным образом уточнен. Во-первых, удостоверьтесь, что владелец продукта (с соответствующей помощью) не только определил приоритетные задачи для предстоящего спринта, но и расписал их достаточно подробно. Настолько подробно, чтобы разработчики могли сразу приступить к их реализации. Например, включил более подробные критерии приемки, а также макеты и схемы, если это в принципе возможно (см. лайфхак 11). Во-вторых, мотивируйте владельца продукта вместе с тестировщиком написать несколько начальных тест-кейсов (основанных на критериях приемки). Они помогут наиболее полно описать основную работу требуемого функционала.
ЦЕЛИ – ЭТО ХОРОШО
Большинству из нас нравится работать, имея четкие цели, вот почему так важно определить основную цель спринта, которая будет лейтмотивом проходить через весь спринт. Она задает тему текущего спринта. Например, цель спринта – улучшить механизм обмена сообщениями. Это не значит, что задачи, не связанные с этой целью, не включаются в спринт. Это значит, что большая часть работы должна быть направлена на улучшение механизма обмена сообщениями. Цель спринта также помогает в принятии решений, ведь каждый участник спринта остается сфокусированным на цели, не отвлекается и не отклоняется от нее.
СКОЛЬКО ДОЛЖЕН ДЛИТЬСЯ СПРИНТ?
Раньше считалось, что продолжительность спринта должна быть 30 дней – не больше и не меньше. Теперь все намного гибче: почти везде признают, что длина спринта может варьироваться от команды к команде. Поговорите с любой scrum-командой, и увидите, что подавляющее большинство спринтов длятся от одной до четырех недель. Я пробовал все четыре варианта. По моему мнению, неделя – это слишком мало, а четыре недели – чересчур много, так что я выбираю между двумя и тремя неделями. Для нового проекта я принимаю решение на основе двух факторов:
• предпочтения команды. Некоторые команды предпочитают более долгий спринт, чтобы успеть набрать темп, в то время как другие выбирают более простое планирование, которое как раз достижимо при более коротком спринте;
• изменчивость требований. Если владелец продукта достаточно часто меняет требования из-за специфики продукта или рыночных условий, я бы рекомендовал более короткий спринт (см. рис. 3.2).
Рис. 3.2. Факторы, которые нужно учитывать при определении длины спринта
Очень важный момент: когда предпочтительная длина спринта выбрана (поначалу придется немного поэкспериментировать), ее нужно зафиксировать и больше не менять (за редким исключением). Есть несколько причин избегать эпизодического изменения длины спринта:
• Определенный ритм помогает команде лучше понимать, как самостоятельно набрать необходимую скорость для фокусировки на цели.
• Метрику скорости (см. лайфхак 13) работы команды можно рассчитать только при одинаковой длительности спринта. В противном случае эта метрика становится менее показательной и ее труднее вычислить.
• Если вы меняете продолжительность спринтов, то обзор спринта, ретроспектива и планирование каждый раз будут приходиться на разные дни недели. Такая нерегулярность может стать головной болью для команды, особенно если вы делите переговорные с другими отделами компании.
ПЛАНИРУЕМ ЕМКОСТЬ СПРИНТА
Перед тем как погрузиться в процесс планирования, команда должна определить емкость спринта. Помните: не все участники команды смогут работать на полную каждый спринт. Некоторые вынуждены одновременно трудиться над несколькими проектами – это неидеальная ситуация, но она встречается достаточно часто (см. лайфхак 6). Если это ваш случай, убедитесь, что разработчики, задействованные в нескольких проектах, не перегружены. И не забудьте учесть государственные праздники, обучение и отпуска сотрудников.
Не попадитесь в ловушку иллюзии, будто те, кто работает только над вашим проектом, потратят весь рабочий день на задачи спринта.
Например, в команде, с которой я недавно работал (с использованием двухнедельных спринтов), емкость спринта на одного штатного разработчика рассчитывалась так: 9 дней × 6 часов в день = 54 часа.
Мы отталкивались от девяти дней, потому что время, затрачиваемое на планирование спринта, обзор спринта и ретроспективу, суммарно составляет один рабочий день. Цифра 6 часов появилась, поскольку в течение 8-часового рабочего дня сотрудник сфокусированно работает над задачами спринта только 6 часов. Оставшееся время, как правило, уходит на другую активность, не связанную с текущим спринтом, – уточнение бэклога продукта (для подготовки к следующему спринту) или более общие задачи, связанные с работой в компании (например, ответы на электронную почту или помощь коллегам не из scrum-команды). Обратите, пожалуйста, внимание, что емкость спринта на одного разработчика в день будет варьироваться в зависимости от команды и процессов в организации. Иными словами, не следует считать емкость 6 часов в день универсальным стандартом. Чтобы определить, какая именно емкость спринта подходит вашей команде, я рекомендую использовать статистику прошлых спринтов (см. лайфхак 19).
Теперь давайте рассмотрим непосредственно сам процесс проведения встречи по планированию спринта. Я бы разделил его на две части: «что» и «как».
ЧАСТЬ 1. ЧТО
Эта часть включает все, что связано с презентацией владельцем продукта наиболее приоритетных элементов бэклога и ответом на любые уточняющие вопросы команды. Презентация выполняется для каждого из элементов бэклога, которые необходимо завершить в предстоящем спринте. Я рекомендую использовать метрику скорости работы команды (см. лайфхак 13) для того, чтобы определить, сколько элементов бэклога владелец продукта должен подготовить для рассмотрения на планировании.
ЧАСТЬ 2. КАК
Затем наступает черед команды разработчиков разделить элементы бэклога на детализированные технические задачи и оценить каждую с точностью до часа. Хотя эти оценки иногда могут быть не точны, они помогают команде принимать более обоснованные решения и обретать большую уверенность в том, что будет сделано к концу спринта. Как поясняет Майк Кон:
Задача не в том, чтобы определить часы, однако именно часы часто становятся гарантией того, что мы обсудили все технические и продуктовые детали задач. Обсудили на таком уровне, который позволит начать спринт с ощущением, что мы сможем закончить всю запланированную работу[37]37
Cohn M. Introduction to Scrum Methodology. A downloadable presentation from the Scrum Alliance website. 2007, April 12. http://scrumalliance.org/resources/47.
[Закрыть].
Я не ожидаю, что владельцы продукта будут присутствовать на второй части (если только сами не захотят). Как я говорил ранее, я не считаю необходимым, чтобы владельцы продукта обязательно находились вместе с командой, однако они всегда должны быть на связи – на случай, если команде потребуется уточнить какие-то детали. Ничто так не стопорит планирование спринта, как недоступность владельца продукта.
Хотя мне нравится использовать планирование на основе метрики скорости работы команды для части 1, также я ценю планирование на основе обязательств – чтобы определить количество задач, которые могут быть включены в бэклог спринта. Команде разработки предстоит выполнить следующие шаги:
1. Начните с максимально приоритетных элементов бэклога.
2. Разбейте элементы бэклога на задачи с оценкой в часах.
3. Выявите зависимости в задачах.
4. Продолжайте этот цикл, пока совокупная оценка задач не достигнет размера емкости спринта команды.
5. Если результат планирования, полученный при использовании подхода на основе скорости команды, не совпал с результатом планирования на основе обязательств, позовите обратно владельца продукта (если он уже покинул помещение) для того, чтобы:
• добавить дополнительный элемент бэклога, если в спринте еще осталась свободная емкость;
• объяснить владельцу продукта, почему в бэклог спринта попало меньше элементов, чем изначально планировалось, если емкость спринта заполнилась быстрее, чем изначально рассчитывалось.
ЧТО ТАКОЕ ЗАДАЧИ?
Обычно я использую несколько критериев для создания задач:
• Каждая отдельно взятая задача должна быть небольшой, самостоятельно тестируемой частью элемента бэклога (см. лайфхак 10). И каждая задача должна пройти через все этапы, чтобы получить статус критерия готовности – и соответствовать всем критериям, согласно которым задача будет считаться закрытой.
• Каждая задача должна занимать не более 8 часов (чем короче, тем лучше).
• Хотя несколько разработчиков могут работать над одним и тем же элементом бэклога, только один разработчик или пара[38]38
Имеется в виду при парном программировании. Прим. ред.
[Закрыть] могут работать над одной задачей (см. рис. 3.3).
• Учитывайте задачи при подготовке обзора спринта (см. лайфхак 22), например при сборе информации для демо.
Рис. 3.3. Хотя над одним элементом бэклога могут работать разные разработчики, над одной задачей может работать только один разработчик
Теперь, после планирования, у вас сформирован бэклог спринта, включающий задачи и их оценки. Суммировав все оценки задач, вы получите оставшееся время в спринте. Это время может пересчитываться каждый день, исходя из завершенных задач, и отслеживаться на диаграмме сгорания задач (см. лайфхак 19). Ежедневно перед уходом домой каждый в команде разработки должен обновлять время, исходя из завершенных и оставшихся задач, чтобы поддерживать диаграмму сгорания в актуальном состоянии.
ПРАВИЛЬНОЕ КОЛИЧЕСТВО ТРЕБОВАНИЙ
В идеальном мире после планирования спринта – когда все детали уже обговорены – у вас есть набор ясных и понятных элементов бэклога, которые ожидаемо будут выполнены командой в текущем спринте. Периодически вы будете обнаруживать, что после планирования осталась небольшая незаполненная емкость спринта, которой недостаточно, чтобы выполнить полноценный элемент бэклога. Это нормально. Просто дайте знать команде, что в оставшееся время можно будет начать следующий по приоритетности элемент бэклога. Однако не ожидайте, что он будет завершен в этом спринте. Я предпочитаю именно такой подход – вместо того, чтобы искать маленький элемент бэклога, который займет ровно столько времени, сколько осталось в емкости спринта, и обнаружится при этом где-нибудь в самом низу бэклога продукта. Я считаю, важнее фокусироваться на самых приоритетных элементах бэклога с наибольшей ценностью для бизнеса.
5 «П»
Как говорят в британской армии, «правильное планирование и подготовка предотвращают поражение». Тщательное и хорошо проведенное планирование спринта важно для того, чтобы спрогнозировать работы настолько точно, насколько это возможно.
Спринт не всегда идет по плану, и порой приходится вносить коррективы. Однако, если планирование спринта проведено грамотно, цели команды будут понятны всем, и это упростит координацию и повысит точность результатов.
Внимание! Это не конец книги.
Если начало книги вам понравилось, то полную версию можно приобрести у нашего партнёра - распространителя легального контента. Поддержите автора!Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
