вотерфолл что это такое
Waterfall — итеративная методология разработки
Недавно открыл для себя интересный факт, что товарищ Винстон Ройс (Dr. Winston D. Royce), анонсируя свой знаменитый Waterfall говорил об итеративной модели разработки.
Наверняка, все, кто хоть как-то связаны с разработкой/тестированием ПО, знают о каскадной модели и об ее особенностях:
— высокий уровень формализации процессов;
— большое количество документации;
— и конечно же, жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Ознакомившись с выдержкой из трудов Ройса, оказалось, что он предусматривал обратные связи между этапами на одном уровне (к примеру, дизайн-кодирование, кодирование-тестирование и т.д.).
Насколько я понимаю разницу, во втором варианте, в отличии от первого, речь идет о параллельных работах по двум последовательным этапам, что дает возможность на более ранних стадиях выявить ошибки предыдущего этапа жизненного цикла и решает один из весомых недостатков «классического» водопада — невозможность возврата на предыдущий этап.
К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.
В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…
Waterfall или Agile: как выбрать методологию управления проектом?
Привет! Я — Алиса Корнева — менеджер проектов в компании Azoft. Занимаюсь управлением проектов больше 8 лет. По моему опыту, выбор методологии управления проектом часто лидирует в списке холиварных вопросов клиента и команды. В этой статье поделюсь с вами своими мыслями на эту тему, без купюр и фаворитизма.
Когда вы решаете разработать свой продукт, то рано или поздно возникает вопрос, как организовать процесс разработки. Стоит ли жестко распланировать все этапы и делать все шаг за шагом? Или лучше работать короткими итерациями, чтобы чаще отслеживать результат и быстрее вносить правки? Все это определяют методологии разработки продукта. Каждая из них имеет свои преимущества и недостатки. В этой статье рассмотрим наиболее популярные из них. Также я расскажу на что обратить внимание при выборе подходящей методологии и как комбинировать разные подходы.
Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:
Получается, план такой:
В Waterfall можно управлять изменениями требований и рисками, но это скорее исключительные ситуации, которые требуют дополнительных затрат времени и бюджета.
Agile (гибкие) – это семейство методологий, объединенных ценностями и принципами Agile-манифеста.
Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.
В основном это фреймворки, предполагающие итерационную работу над проектом, то есть когда основные фазы разработки циклично повторяются друг за другом. Самый распространенный фреймворк – это Scrum, схематично рабочий процесс по которому можно изобразить так:
Жизненный цикл проекта в этом случае – это набор итераций, каждая из которых включает в себя мини-версию разработки проекта командами по методу Waterfall.
Получается, что итерационные методологии отличаются тем, что результатом каждой итерации является законченный продукт, и каждая последующая итерация наращивает его функциональность.
Ещё одна особенность в том, что на этапе аналитики требуется прояснить и зафиксировать не все требования по проекту, а только часть – то, что планируется завершить в текущей итерации. Аналогично с разработкой дизайна – идет отрисовка не итоговых прототипов, а только требуемых для реализации текущего спринта.
Waterfall, Scrum и другие гибкие методологии управления проектами имеют преимущества и недостатки. Каждая из методологий хорошо подходит для решения определенных задач и сложнее адаптируется к другим.
Характеристики проектов, подходящих под разные методологии можно обозначить так:
Скоуп и требования-
Waterfall — похожая задача уже решалась заказчиком/исполнителем, продукт не инновационный;
Гибкие методологии — для заказчика/исполнителя это качественно новая задача, либо продукт инновационный;
В чем подвох — в новой для себя области гораздо проще упустить что-то важное. Для Waterfall будет сложнее вносить изменения в исходные требования.
Waterfall — требования к проекту в процессе работы не будут значительно меняться;
Гибкие методологии — планируется применять Customer development (тестирование идеи или прототипа будущего продукта на потенциальных потребителях), тестировать гипотезы на рынке, в процессе проекта управлять приоритетами, опираясь на фокус-группы;
В чем подвох — по аналогии с первыми пунктами – здесь все упирается в потребность гибко управлять требованиями. Если нет такой потребности – Waterfall ваш вариант.
Waterfall — жестко ограничен;
Гибкие методологии — можно варьировать в заданных рамках;
Waterfall — жестко ограничен и определен до этапа аналитики;
Гибкие методологии — может варьироваться;
В чем подвох — отличительная особенность гибких методологий – результат каждой итерации в виде работающего продукта. После завершения этапа аналитики можно достаточно точно оценить срок завершения Waterfall-проекта.
Если проект характеризуется признаками только из одной колонки – можно смело выбирать соответствующую методологию проекта и не греть голову. Но что, если все сложнее (как и бывает в большинстве случаев)? Тогда на помощь приходят гибридные методологии управления проектами! Мы уже писали про свой опыт работы с ними на примере разработки портала «Спасибо от Сбербанка. Путешествия». Советуем ознакомиться, чтобы узнать подробнее когда и зачем их применять.
Большинство проектов Azoft управляются с помощью гибридной, индивидуально подобранной под проект методологии.
Для нас важно, чтобы инструменты управления использовались не «для галочки», и не потому, что это декларировано в PMBook, а для того, чтобы решить задачи проекта.
Объясняем, когда и как внедрить практики из разных методологий, чтобы в результате собрать актуальный для вашего проекта «гибрид»:
Как сделать подходящий к проекту гибрид:
Каждый проект – это уникальный коктейль из требований, команды, заказчика и внешних условий. Подходящий к проекту фреймворк управления позволяет использовать ресурсы эффективно, сильно снижая риски ошибиться в процессе. Надеюсь, статья поможет вам настраивать на своих проектах такие системы управления, которые помогут достигать классных результатов! Если вы знаете другие способы добиться идеальной управляемости проекта – пишите в комментариях, будем рады новым инсайтам.
Agile или Waterfall? Сравнение методологий веб-разработки
При создании нового проекта, заказчик должен определиться не только с выбором подрядчика, но и подходящей методологией разработки проекта. На современном этапе развития технологий, нет универсального подхода в создании проекта, поэтому возникает логичный вопрос: какой подход выбрать и какие «подводные камни» существуют?
Waterfall – это четко запланированный и детализированный подход, где исполнитель придерживается плану. Agile – прямая противоположность, которая предполагает гибкость разработки с возможностью внесения изменений на каждом этапе проекта.
В этой статье постараемся определить, в чем особенности этих двух методологий, назовем положительные и отрицательные стороны, а также разберемся, какой способ реализации подойдет для выбранного вами проекта.
Гибкие методологии строятся на принципе итераций. Создание нового продукта делится на несколько циклов от одной недели до месяца. В зависимости от особенностей проекта, временные рамки оговариваются отдельно. Каждый цикл представляет собой завершенный мини-проект, в котором есть этапы анализа, планирования, тестирования и реализации. В итоге клиент получает продукт, который, при необходимости, корректируется.
Главные принципы Agile:
Наиболее популярные методики Agile:
Scrum – система гибкой разработки проектов, основанная на принципе спринта. От 1 недели до месяца должна быть готова рабочая версия продукта.
Экстремальное программирование (XP) – методика, при которой важно взаимодействие с клиентом на каждом этапе. Благодаря такому подходу, выявляются недостатки предыдущих этапов, определяется необходимый функционал продукта и другие параметры.
Lean – базируется на системе управления производством. Главное отличие – принцип постоянного совершенствования продукта на всех уровнях организации процесса.
Про гибкую модель управления можно сказать, что она универсальна, так как подойдет к любому проекту. Сложность выбора заключается только в ограничениях заказчика по времени и боязнью «дыр» в бюджете. Качество обратной связи при данном подходе поможет прийти к согласованному решению. Выбирая эту модель, заказчик может быть уверен, что его проект будет уникальным, интересным и проверенным до мелочей.
Waterfall (с англ. – «водопад») – предполагает последовательный переход к каждому этапу разработки и невозможностью вернуться на шаг назад. Внести какие-либо изменения будет возможно только после релиза проекта.
Выбирая данную модель для своего проекта, необходимо понимать, что конечный продукт будет иметь недочеты. Предусмотреть все на этапе анализа и планирования просто невозможно, в процессе разработки могут появится новые требования. Однако, в Waterfall сделать правки в течении проекта невозможно также, как и вернуться на шаг назад. Классический подход представляет из себя каскадную модель, которая базируется на последовательном создании проекта, разбитого на циклы.
Выделяют следующие стадии разработки в Waterfall:
Востребованные методики Waterfal:
Сашими – одна из самых популярных моделей Waterfal. Представляет собой наслаивающиеся друг на друга этапы, которые перекрываются по времени.
Waterfall с субпроектами – методика работы с тремя крупными стадиями: разработка концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет свои этапы разработки. По окончании работ в каждой стадии проводится их интеграция.
Модель снижения риска – проект разделяется на более мелкие проекты, которые направлены на выявление недочетов до релиза программного продукта.
Ключевая особенность Waterfall – невозможность сделать шаг назад или перепрыгнуть через итерацию, переход на следующую стадию возможен только после прекращения всех работ на предыдущей. Изменение функционала или исправление ошибок происходит только после релиза проекта. Работа по каскадной модели четко структурирована, определи точные сроки и конкретная стоимость разработки.
Waterfall подойдет, если:
Что из этого следует?
Каждая из моделей, рассмотренных нами выше, имеет определенный набор характеристик и подходит для реализации проектов разной направленности.
Как Agile, так и Waterfall помогут в создании практически любого продукта. Однако, в первую очередь выбирается та методология, которая может максимально эффективно и качественно реализовать проект. Быть может продукт универсален. Тогда необходимо отталкиваться от параметров, как время, бюджет, квалификация исполнителей и другие важные для вас критерии.
Гибкая модель требует высокого профессионализма от исполнителя и идеально подходит для стартапов и продвинутых нишах. Водопадная модель чаще всего используется в области строительства, инвестиций и т.д.
При выборе той или иной методологии заказчик должен внимательно изучить сильные и слабые стороны подходов, учесть советы специалистов, определить набор требований к проекту. И тогда выбор будет сделать гораздо легче. Некоторые разработчики считают, что в рамках одного проекта можно оптимально совместить Agile и Waterfall.
Помните, что, принимая решение в пользу того или иного метода, главной задачей является создание не только качественного продукта, но и возможность им решать поставленные задачи.
Ну вот какбэ да.
Выбирайте исполнителя, а с методологией уж пусть он сам пределяется. Если вы принципиально не хотите работать по предложенной методологии, а исполнитель не хочет ее менять, возможно, это не ваш исполнитель.
Ну и вопрос о месте работы автора.
Это ж каких размеров должна быть производственная махина, чтобы изменить продукт в процессе вотерфлоу было вот прям невозможно. Не дорого, не долго, не сложно, а вот прям невозможно?
Согласен, пожалуй «невозможно» слишком эмоциональное слово, по сути нет ничего не возможного, по этому да, правильней было бы сказать, что слишком дорого и не рационально.
** Преимущества Waterfall ** полный бред. Вы работали с реальными проектами?
Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик точно будет знать, когда проект завершится и какой бюджет требуется потратить.
Стоимость и сроки не понятны, они взяты из носа и размазаны по бумаге. По факту сроки и бюджеты всегда нарушаются.
Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.
Структура работ не понятно, а расписана из ПРЕДПОЛОЖЕНИЙ руководителя проекта или другого руководящего лица. Это мешает контактировать, мешает помогать, все заняты своим делом и не заботятся о благополучии команды.
Детально структурированный план работ и продуманная документация.
Документация, которую никто не читает. План работ, основанный на предположениях.
Благодаря удобной отчетности легко отследить потраченное время, возможные риски и используемые ресурсы в процессе работы над проектом.
Постфактум в любом случае можно всё это отследить, если фиксировать во время работы.
Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.
Для команды ясны, но в ходе проекта задачи меняются у заказчика и на выходе получается не жизнеспособный продукт, который не нужен заказчику.
Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.
А в Scrum и вообще в Agile продукт на последнем месте да?
С ** недостатками Agile ** тоже не согласен.
Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.
Требования могут меняться, но они не должны быть диаметрально противоположными. Требования могут дополняться, да. А чтобы вместо изначально запрошенного сарая, заказчик на выходе не требовал дворец, нужен грамотный Product Owner.
Agile требует большой вовлеченности в процесс и полному погружению в него, что бывает сложно, особенно для молодых подрядчиков.
Любая задача требует полного погружения и воволеченности, иначе это будет халтура, а не работа.
Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.
Опять таки, есть конечные требования, поставленные изначально, а чтобы губу клиент не раскатывал есть договор и Product Owner.
Вообще по Agile в статье много ошибок. Либо автор не до конца разобрался в вопросе, либо просто не смог правильно преподнести информацию.
А вообще советую прочитать книгу Scrum (Джефф Сазерленд). Там всё по полочкам.
Методологии управления проектами: водопад, эджайл
В предыдущей части мы разбирались, что такое проект и зачем нужен менеджер проектов. Сегодня углубимся в тему и поговорим о инструментах, которые менеджер использует в работе.
Методологией в управлении проектами называется стандартизация проведения проектов. Под стандартизацией здесь подразумевается описание шагов работы, чеклисты к проверке – эдакая канва, в которую можно закинуть проект, и он под присмотром менеджера приплывет к завершению и готовому продукту. Так как каждый проект в той или иной степени уникален, методология не панацея, думать все-таки придется.
Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).
В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.
Само собой, ничто ниоткуда не берется, и Петр Первый ничего не слышал про эджайл. Методологии придумываются всякими разными организациями и ассоциациями, где умные дядьки собирают свои проблемы в кучи, затем понимают, как их можно было избежать, и делятся после решениями с такими обывателями как я, например. Иногда продумывание методологий происходит на государственном уровне – там тоже решают проблемы и собирают best practices (в приличном обществе так не выражайся) в книги и руководства.
Речь сегодня пойдет в основном об этих двух зверятах. После прочтения этого раздела можешь смело идти и требовать себе самое классное место менеджера проектов в самой крупной подходящей организации города.
Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:
Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.
Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:
Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.
“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.
Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.
Этапы производства (представим, что каждый этап занимает ровно спринт):
Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.
Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.
Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.
Если ты работаешь со внешними клиентами, эджайл гораздо удобнее водопада в любых проектах – ты же знаешь, сколько комментариев клиент может выдать на каждом этапе проекта и как сложно объяснить клиенту, что его комментарии превышают заложенное время на разработку, а значит и бюджет проекта. Доплачивать-то он вряд ли будет – есть же смета, и ты вроде как профессионал, должен был сразу понять, что ему вообще нужно. Эджайл работает с понимающими клиентами, остальным будет крайне сложно объяснить, почему это окей.
Еще одна особенность методологии: в ней нет как такового менеджера проекта. Есть владелец продукта, скрам-мастер (в Scrum), члены команды. То есть, менеджер здесь выступает в роли владельца продукта и делает примерно то же самое, что делает при любой другой методологии. Внутри любой проектной команды продакт-оунером выступает менеджер проекта – он заказывает продукт у команды, а не тот человек, который брифует менеджера.
В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.
Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.
Преимущественно использую гибридную методологию (и водопад, и эджайл), где есть техническое задание, понятны этапы, но случаются отклонения по ходу проекта. Со стороны может казаться, что творится хаос, главное делать лицо с понтом всё идёт по плану. Часто отклонения уходят в отдельные проекта, но чаще остаются внутри текущего и тянут за собой увеличение времени (бюджета) проекта. Кажется, это плохо, но момент политики в работе с людьми (мы же работаем с людьми, а не с сайтами, помнишь?) исключать нельзя.
Эти организации, по большей мере, именно управляют развитием методологий – развивают их такие же менеджеры, каким однажды станешь ты. В мире их не так много, но все они дико важные – за деньги и время можно получить их дипломов и ходить на собеседования, поражая интервьюеров.
Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.
Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.
Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.
У PMI куча куч видов сертификаций, со ступенями и наворотами. Сертификаты PMI известны и популярны. Например, PMP – профессионал управления проектами – типа подтверждает, что ты можешь руководить проектами. Получить сертификаты организации не имея опыта нельзя, потому они больше как подтверждение, нежели как этот твой университетский диплом, который ты получил, пока учился учиться.
Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).
Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.
“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.
«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.
“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.
Ничто не панацея, но понимать принципы и брать из них лучшее можно и нужно. Пока писал статью, краем глаза наткнулся на статью о Стаханове – был такой чувак при Советах, его еще в советской пропаганде продуктивности использовали. Он тоже работал по методологии (уголь добывал), но однажды понял, что если чуток переставить людей и пустить некоторые процессы параллельно, можно работать лучше. Вот и заработал себе страницу в википедии. Так и здесь – тестируй, применяй и дорабатывай (потом делись). Все, с чем ты сталкиваешься, все советы – гипотеза, которую нужно проверить. Enjoy it!
В следующей части постараюсь рассказать про планирование задач и времени, включая собственный микроменеджмент. Статья должна помочь не только начинающим менеджерам, но и тем, кто с ними работает. Если хватит запала, то статья будет прям на этой неделе. Пишите письма.