Комментарии 31
Спасибо за хорошую статью!
Статья еще раз показала, что очень важно учитывать все предложенные принципы в любом начинании)
Статья еще раз показала, что очень важно учитывать все предложенные принципы в любом начинании)
Хоть и довольно общая статья, но все же полезная.
Спасибо!
Спасибо!
По моему Вы вкратце изложили суть руководства PMBOK (Руководство к своду знаний по управлению проектами) которая изложена на 400 страницах )
Заинтересованность есть! Обязательно продолжайте.
Спасибо — утащил в закладки.
Спасибо, это очень полезная информация. Но я думал что на Хабре выкладываю что свое… эдакое, а это же просто скан книги, хорошо, что книга очень не плохая.
Детально не знаком с подходом такой авторитетной организации в области управления проектами, как БШ МИМ ЛИНК, но вижу по этой заметке, что PMI PMBoK накроет ее методику как петух курицу.
С т.з. менеджера проектов (МП), инициация и планирование проекта (т.е. то, о чем заявлена заметка) — это примерно половина всего объема работ МП в проекте. У Вас же очень обще описана дай бог четвертая часть работ МП на этих этапах.
Примерно представляя себе, как стряпаются материалы по курсам (в данном случае, явно непрофильным для ЛИНК), рекомендую Вам все-таки черпать информацию и подходы в серьезных источниках.
Методология управления проектами, описанная в PMI PMBoK, представляет собой комплексный системный подход (рамочную методологию) к управлению крупными распределенными проектами с большими бюджетами и большими полномочиями/ответственностью менеджеров проектов. Предлагаемый там состав, содержание и последовательность процессов/активностей (а также устоявшаяся общепризнанная терминология) является своего рода лучшей практикой в управлении проектами, т.е. «большинство опытных менеджеров проектов считают их полезными в большинстве случаев для большинства проектов».
Вместе с тем, есть много хороших, достойных и интересных книг по управлению проектами, но в них описан частный субъективный взгляд автора на управление проектами особых типов (напр., айтишных или строительных, в зависимости от бэкграунда автора), и даются рекомендации применительно к конкретному контексту. В PMBoK же каждый шаг, этап, activity, структуры, показатели… обсасываются огромным количеством практикующих профессионалов из разных областей до тех пор, пока они не придут к консенсусу. По поводу концептуальных вещей проводятся огромные семинары и конференции.
Теперь конкретно о том, что Вы написали, несколько замечаний. По финансовым деталям. Менеджер проекта (по меньшей мере, в понимании PMI) НЕ ОТВЕЧАЕТ ЗА ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ПРОЕКТА (NPV, IRR, срок окупаемости и т.д.). За это отвечают люди, находящиеся выше МП и ставящие/инициирующие проектные задачи МП. МП, естественно, должен быть в курсе этих задач для правильной подготовки (НЕ ПРИНЯТИЯ) соотв. решений, но он отвечает ТОЛЬКО за сроки, бюджет, качество (удовлетворенность) и ряд других. Соответствующие метрики проекта (у Вас отсутствуют) — earned value, SPI (schedule performance index), CPI (cost performance index), соответствующие planned, actual, earned, variance, forecast/estimation и т.д. Либо тогда надо говорить, что МП выполняет в компании, так уж повелось, функции, связанные с инвестиционным и бизнес-планированием.
Поскольку в российских реалиях чаще всего МП не управляет бюджетом проекта (а, скажем так, является распорядителем некоей его части и готовит соотв. отчетность), имеет смысл осветить эти моменты — расчет костов (себестоимости для компании), соглашение о костах внутри компании (с сейлзом, если проект выполняется по закл. договору), работа с подрядчиками и т.д.
Т.к. это Ваша первая общая обзорная статья в цикле статей, особо дальше придираться не буду, хотя поводов огромное количество. Спасибо.
С т.з. менеджера проектов (МП), инициация и планирование проекта (т.е. то, о чем заявлена заметка) — это примерно половина всего объема работ МП в проекте. У Вас же очень обще описана дай бог четвертая часть работ МП на этих этапах.
Примерно представляя себе, как стряпаются материалы по курсам (в данном случае, явно непрофильным для ЛИНК), рекомендую Вам все-таки черпать информацию и подходы в серьезных источниках.
Методология управления проектами, описанная в PMI PMBoK, представляет собой комплексный системный подход (рамочную методологию) к управлению крупными распределенными проектами с большими бюджетами и большими полномочиями/ответственностью менеджеров проектов. Предлагаемый там состав, содержание и последовательность процессов/активностей (а также устоявшаяся общепризнанная терминология) является своего рода лучшей практикой в управлении проектами, т.е. «большинство опытных менеджеров проектов считают их полезными в большинстве случаев для большинства проектов».
Вместе с тем, есть много хороших, достойных и интересных книг по управлению проектами, но в них описан частный субъективный взгляд автора на управление проектами особых типов (напр., айтишных или строительных, в зависимости от бэкграунда автора), и даются рекомендации применительно к конкретному контексту. В PMBoK же каждый шаг, этап, activity, структуры, показатели… обсасываются огромным количеством практикующих профессионалов из разных областей до тех пор, пока они не придут к консенсусу. По поводу концептуальных вещей проводятся огромные семинары и конференции.
Теперь конкретно о том, что Вы написали, несколько замечаний. По финансовым деталям. Менеджер проекта (по меньшей мере, в понимании PMI) НЕ ОТВЕЧАЕТ ЗА ЭКОНОМИЧЕСКИЙ ЭФФЕКТ ПРОЕКТА (NPV, IRR, срок окупаемости и т.д.). За это отвечают люди, находящиеся выше МП и ставящие/инициирующие проектные задачи МП. МП, естественно, должен быть в курсе этих задач для правильной подготовки (НЕ ПРИНЯТИЯ) соотв. решений, но он отвечает ТОЛЬКО за сроки, бюджет, качество (удовлетворенность) и ряд других. Соответствующие метрики проекта (у Вас отсутствуют) — earned value, SPI (schedule performance index), CPI (cost performance index), соответствующие planned, actual, earned, variance, forecast/estimation и т.д. Либо тогда надо говорить, что МП выполняет в компании, так уж повелось, функции, связанные с инвестиционным и бизнес-планированием.
Поскольку в российских реалиях чаще всего МП не управляет бюджетом проекта (а, скажем так, является распорядителем некоей его части и готовит соотв. отчетность), имеет смысл осветить эти моменты — расчет костов (себестоимости для компании), соглашение о костах внутри компании (с сейлзом, если проект выполняется по закл. договору), работа с подрядчиками и т.д.
Т.к. это Ваша первая общая обзорная статья в цикле статей, особо дальше придираться не буду, хотя поводов огромное количество. Спасибо.
По правде говоря, когда я начал читать PMBoK, то перед тем имел опыт изучения более кратких методик и был очень изумлен тем, что в PMBoK жуется буквально каждая мелочь. По входам и выходам каждого процесса имеется полное объяснение, которое дает полнейшее понимание происходящего. Это мне сильно понравилось, настолько что не мог пропустить ни одной страницы книги по диагонали.
Планировал написать, да забыл — где WBS и вообще schedule? Без этого вообще говорить не о чем на этапе планирования проекта. Где HR management — а это основная российская проблема и важная причина провала проектов (упомянуто вскользь).
За что важное на этапе планирования проекта ни хватись, этого в заметке либо нет, либо совсем уж только упомянуто.
Ну и наконец, что должно быть результатом работы МП? Какие документы и с какой структурой? Хороший, кстати, способ объяснения, что должен сделать МП — набор шаблонов документов по управлению проектами, и чтобы их правильно заполнить, МП вынужден будет ответить на все важные вопросы и провести соотв. работы.
Пример PMBoK4-aligned шаблонов:
www.oregon.gov/DHS/admin/bpm/pmo/PPO_Tools_Templates.shtml
За что важное на этапе планирования проекта ни хватись, этого в заметке либо нет, либо совсем уж только упомянуто.
Ну и наконец, что должно быть результатом работы МП? Какие документы и с какой структурой? Хороший, кстати, способ объяснения, что должен сделать МП — набор шаблонов документов по управлению проектами, и чтобы их правильно заполнить, МП вынужден будет ответить на все важные вопросы и провести соотв. работы.
Пример PMBoK4-aligned шаблонов:
www.oregon.gov/DHS/admin/bpm/pmo/PPO_Tools_Templates.shtml
этап планирования только впереди, поэтому здесь о нем упомянуто вскользь.
еще раз повторюсь, это не PMBoK, а другой, более простой и менее детализированный подход
ну а результатом работы МП на этом этапе должно быть резюме проекта
за шаблоны PMBoK спасибо!
еще раз повторюсь, это не PMBoK, а другой, более простой и менее детализированный подход
ну а результатом работы МП на этом этапе должно быть резюме проекта
за шаблоны PMBoK спасибо!
Резюме проекта.
Во-первых, что это за название? Резюме — это краткая сводка. Т.е. я делаю вывод, что это приблизительный аналог Project Charter в PMI PMBoK. Подробное описание — это Устав Проекта (в российской практике) или Project Management Plan в PMI PMBoK. Судя по структуре документа, резюме у Вас это что-то среднее — первая половина — Project Charter, все вместе — фрагменты PM Plan'а.
Во-вторых, пункт в резюме «масштаб и границы проекта» и все что ниже (особенно, график проекта) — Вы готовы подписать у спонсора (покровителя в Вашей терминологии) все это без этапа планирования? Коли у Вас еще до планирования дело не дошло. Финализация и утверждение PM Plan'a и Project Schedule (графика проекта) — это самый последний шаг этапа планирования, непосредственно перед началом исполнения проекта.
Мой совет — возьмите PMBoK, хорошие книги типа Kerzner H. Project Management. A Systems Approach to Planning, Scheduling, and Controlling, 10e, изучите, получите опыт хороший в управлении проектом в позиции менеджера проекта (а не снизу-сбоку) с тем, чтобы описанные там вещи наполнились для Вас конкретным смыслом — и тогда Вашим размышлениям об управлении проектами цены не будет. Пока же это бессистемная обрывочная плохо затеоретизированная каша, ЛИНКу жирный минус. Вам спасибо за старания и интерес к теме.
Во-первых, что это за название? Резюме — это краткая сводка. Т.е. я делаю вывод, что это приблизительный аналог Project Charter в PMI PMBoK. Подробное описание — это Устав Проекта (в российской практике) или Project Management Plan в PMI PMBoK. Судя по структуре документа, резюме у Вас это что-то среднее — первая половина — Project Charter, все вместе — фрагменты PM Plan'а.
Во-вторых, пункт в резюме «масштаб и границы проекта» и все что ниже (особенно, график проекта) — Вы готовы подписать у спонсора (покровителя в Вашей терминологии) все это без этапа планирования? Коли у Вас еще до планирования дело не дошло. Финализация и утверждение PM Plan'a и Project Schedule (графика проекта) — это самый последний шаг этапа планирования, непосредственно перед началом исполнения проекта.
Мой совет — возьмите PMBoK, хорошие книги типа Kerzner H. Project Management. A Systems Approach to Planning, Scheduling, and Controlling, 10e, изучите, получите опыт хороший в управлении проектом в позиции менеджера проекта (а не снизу-сбоку) с тем, чтобы описанные там вещи наполнились для Вас конкретным смыслом — и тогда Вашим размышлениям об управлении проектами цены не будет. Пока же это бессистемная обрывочная плохо затеоретизированная каша, ЛИНКу жирный минус. Вам спасибо за старания и интерес к теме.
во-первых, здесь речь идет только о подготовке (инициации) проекта — чтобы понять, а нужен ли вообще тот или иной проект? Поэтому планирование проекта будет только следующим этапом.
во-вторых, здесь описана не столько работа МП, сколько просто общие принципы подготовки — на что обратить внимание, что посчитать, с кем обсудить и т.д. А уж кто это будет делать — решать вам.
В учебном курсе ЛИНКа в плане управления проектами изучается 6-ти этапная модель — и конечно же объемы не такие, как в PMBoK. Согласен, что эта одна из самых подробных и цельных методологий, но так как я с ней не знаком, то писал о том, что мне известно более-менее. Если кто-то решится написать серию статей по PMBoK, то сам с удовольствием почитаю
во-вторых, здесь описана не столько работа МП, сколько просто общие принципы подготовки — на что обратить внимание, что посчитать, с кем обсудить и т.д. А уж кто это будет делать — решать вам.
В учебном курсе ЛИНКа в плане управления проектами изучается 6-ти этапная модель — и конечно же объемы не такие, как в PMBoK. Согласен, что эта одна из самых подробных и цельных методологий, но так как я с ней не знаком, то писал о том, что мне известно более-менее. Если кто-то решится написать серию статей по PMBoK, то сам с удовольствием почитаю
Вы уж извините, но я от Вас не отцеплюсь )).
«В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки.»
«здесь речь идет только о подготовке (инициации) проекта — чтобы понять, а нужен ли вообще тот или иной проект».
Подготовка и инициация — это не одно и то же.
Результат подготовки проекта — как ни странно, подготовленный проект )) Подготовленный к чему? Два варианта:
1) Проект подготовлен к непосредственному исполнению (execution в PMBoK), т.е. понятно, что подготовка в этом случае включает в себя планирование (initiation + planning);
2) Проект подготовлен к старту. Т.е. предварительные работы проделаны — инициатива экономически просчитана (ТЭО либо бизнес-план), предпроектный анализ проведен, либо договор с клиентом заключен — проекту можно давать зеленый свет. Сразу же после этого первый шаг — инициация (формальное объявление о существовании проекта в компании, например, это приказ/распоряжение по компании, в котором как правило сразу менеджера проекта назначают). И дальше МП, махая этой бумажкой, начинает: разбирается с переданным ему business case (описанием деловой ситуации, проблемы, из-за которой/для решения которой затеян проект), собирает первичные требования и первичные (высокоуровневые) риски, формирует измеряемые цели и задачи, идентифицирует стейкхолдеров и работает с ними, пишет и утверждает очень высокоуровневое описание базовых параметров проекта — Project Charter. Потом фаза Planning…
Иными словами, в первом случае подготовка — это initiation + planning, во втором случае — предпроектный этап до initiation (и до planning, естественно).
Насколько я понял, Вы имели в виду какой-то третий вариант. И вообще, у Вас и методология другая (ЛИНКовская), и под терминами вы что-то другое понимаете. Тогда подискутировать в формате хабра у нас не получится, т.к. нужно будет на конкретных примерах брать и смотреть, чем чреват пропуск тех или иных этапов в управлении проектом.
В этом-то как раз и заключается одна из сильных сторон PMBoK — все люди во всем мире одинаково понимают, о чем идет речь. Плюс к этому терминология очень аккуратная и увязанная, сам фреймворк очень системный. Естественно, под каждый проект МП его каждый раз плющит под себя, но в качестве основы, повторюсь, PMBoK — лучший вариант.
«В данной статье рассмотрены теоретические основы важнейшего этапа в управлении проектами – именно его подготовки.»
«здесь речь идет только о подготовке (инициации) проекта — чтобы понять, а нужен ли вообще тот или иной проект».
Подготовка и инициация — это не одно и то же.
Результат подготовки проекта — как ни странно, подготовленный проект )) Подготовленный к чему? Два варианта:
1) Проект подготовлен к непосредственному исполнению (execution в PMBoK), т.е. понятно, что подготовка в этом случае включает в себя планирование (initiation + planning);
2) Проект подготовлен к старту. Т.е. предварительные работы проделаны — инициатива экономически просчитана (ТЭО либо бизнес-план), предпроектный анализ проведен, либо договор с клиентом заключен — проекту можно давать зеленый свет. Сразу же после этого первый шаг — инициация (формальное объявление о существовании проекта в компании, например, это приказ/распоряжение по компании, в котором как правило сразу менеджера проекта назначают). И дальше МП, махая этой бумажкой, начинает: разбирается с переданным ему business case (описанием деловой ситуации, проблемы, из-за которой/для решения которой затеян проект), собирает первичные требования и первичные (высокоуровневые) риски, формирует измеряемые цели и задачи, идентифицирует стейкхолдеров и работает с ними, пишет и утверждает очень высокоуровневое описание базовых параметров проекта — Project Charter. Потом фаза Planning…
Иными словами, в первом случае подготовка — это initiation + planning, во втором случае — предпроектный этап до initiation (и до planning, естественно).
Насколько я понял, Вы имели в виду какой-то третий вариант. И вообще, у Вас и методология другая (ЛИНКовская), и под терминами вы что-то другое понимаете. Тогда подискутировать в формате хабра у нас не получится, т.к. нужно будет на конкретных примерах брать и смотреть, чем чреват пропуск тех или иных этапов в управлении проектом.
В этом-то как раз и заключается одна из сильных сторон PMBoK — все люди во всем мире одинаково понимают, о чем идет речь. Плюс к этому терминология очень аккуратная и увязанная, сам фреймворк очень системный. Естественно, под каждый проект МП его каждый раз плющит под себя, но в качестве основы, повторюсь, PMBoK — лучший вариант.
постараюсь кратко
мы с вами на разных языках разговариваем, хотя пишем на одном! не нужно критиковать только потому, что в PMBoK не так. Он ведь тоже не есть истина…
Цель этой заметки состоит НЕ в предложении лучшей практики, а в том, чтобы натолкнуть людей на мысль (особенно новичков), что просто одной хорошей (или гениальной идеи) мало — для того, чтобы проект запустить, необходимо помнить о таких вещах как:
1. цели
2. ЗС, их требования и ожидания
3. возможности и угрозы
и начать следует именно с этого анализа. А с помощью каких практик и методологий — вопрос второй.
И про резюме вопрос не принципиальный, просто как его не назови, нужно помнить, что такой документ необходим для успешной реализации проекта, а не является просто объемной ненужной бумажкой
если говорить в ваших терминах, то здесь описан «предпроектный этап до initiation (и до planning, естественно)».
мы с вами на разных языках разговариваем, хотя пишем на одном! не нужно критиковать только потому, что в PMBoK не так. Он ведь тоже не есть истина…
Цель этой заметки состоит НЕ в предложении лучшей практики, а в том, чтобы натолкнуть людей на мысль (особенно новичков), что просто одной хорошей (или гениальной идеи) мало — для того, чтобы проект запустить, необходимо помнить о таких вещах как:
1. цели
2. ЗС, их требования и ожидания
3. возможности и угрозы
и начать следует именно с этого анализа. А с помощью каких практик и методологий — вопрос второй.
И про резюме вопрос не принципиальный, просто как его не назови, нужно помнить, что такой документ необходим для успешной реализации проекта, а не является просто объемной ненужной бумажкой
если говорить в ваших терминах, то здесь описан «предпроектный этап до initiation (и до planning, естественно)».
Я Вас понял. До момента, когда менеджер проекта приступает к проекту (т.е. до, собственно, управления проектами) мы еще не добрались. Пока описываются предпроектные активности, связанные с инвестиционным и бизнес-планированием, частично активности бизнес-аналитика (не айтишного, а в понимании The International Business Analysis Institute, theiiba.org), organizational/business development, business transition management и прочие процессы, в которых могут порождаться и оцениваться проектные инициативы.
Ох, сколько же здесь воды, почти каждое преложение просто кричит своей вопиющей бесполезной академичностью.
Почему нельзя всё живенько на примере описать? Или еще лучше, как у Купера, – свести всё в одну табличку?
И последнее, вы сами как-нибудь это используете в своей деятельности? Если да, то как? Ну, например, каждый раз проходитесь по всем пунктам и проверяете их наличие.
Почему нельзя всё живенько на примере описать? Или еще лучше, как у Купера, – свести всё в одну табличку?
И последнее, вы сами как-нибудь это используете в своей деятельности? Если да, то как? Ну, например, каждый раз проходитесь по всем пунктам и проверяете их наличие.
по-моему, любая академичность на первый взгляд кажется бесполезной. Но вот когда начинаешь наступать на одни и те же грабли — берешь книжки в руки и понимаешь, не так уж она и бесполезна!
Конечно, описать реальный пример — это лучшее учебное пособие, но под рукой примера «правильной» подготовки проекта, увы, нет — а вот обратных примеров — куча!
Досконально по всем пунктам не прохожусь (да может это быть и нужно в различных контекстах), но анализ требований ЗС делаю, NPV считал, в составлении журнала рисков учавствовал. А также объяснял своему руководству, что важно чувствовать себя именно покровителем проекта, а не просто его контролёром.
Конечно, описать реальный пример — это лучшее учебное пособие, но под рукой примера «правильной» подготовки проекта, увы, нет — а вот обратных примеров — куча!
Досконально по всем пунктам не прохожусь (да может это быть и нужно в различных контекстах), но анализ требований ЗС делаю, NPV считал, в составлении журнала рисков учавствовал. А также объяснял своему руководству, что важно чувствовать себя именно покровителем проекта, а не просто его контролёром.
Не знаю как автор, но, например, я аналогичную методику давно использую в своей практике. И такой подход, — академичный, как вы его назвали, — всегда помогал делать мне успешные проекты.
Не отрицаю, что может и я тормоз, и не встретил применимого для себя академ. подхода к проектированию. Всё больше использую простые и внятные целеориентированные подходы из того же «Проектирования взаимодействия» Купера.
А как вы используете методику?
А как вы используете методику?
«Как» или «какую»? Ответ на второй вопрос — синкретическую, основанную на положениях ГОСТов, MSF, PMBoK, OnTarget и собственной многолетней практике работы. Ответ на первый вопрос — достаточно успешно, судя по имеющимся результатам, но предела совершенству нет :)
Вообще, тема интересная и весьма обширная, в ближайшем будущем постараюсь написать по ней несколько топиков.
Вообще, тема интересная и весьма обширная, в ближайшем будущем постараюсь написать по ней несколько топиков.
Статья, конечно, очень круто написана, но излишне академично. Описанный подход скорее душу начальникам греет, чем как-то влияет на эффективность в общем случае. Для начала бы неплохо определить, что же такое проект и вообще где такой подход применяется. А то в итоге (проверено на практике) то, что в умной книжке описывается одним абзацем, в жизни занимает 50% времени.
А подобные методы работают только на типичных конвеерных проектах. Либо на тех, где предметная область изучена досконально и в наличии большой штат экспертов по ней.
А подобные методы работают только на типичных конвеерных проектах. Либо на тех, где предметная область изучена досконально и в наличии большой штат экспертов по ней.
не соглашусь, работает не только «на типичных конвеерных проектах»
это же в принципе общие правила, применимые к любому проекту и деятельности вообще: сначала поставь четкие цели, затем обсуди с ЗС, выяви риски, проверь осуществимость… И если решение принято, что ЭТО нам нужно, то дальше запускаем проект
и вот отсюда можно идти разными путями: Scrum, PMBoK, 6-ти этапная модель, и т.д.
это же в принципе общие правила, применимые к любому проекту и деятельности вообще: сначала поставь четкие цели, затем обсуди с ЗС, выяви риски, проверь осуществимость… И если решение принято, что ЭТО нам нужно, то дальше запускаем проект
и вот отсюда можно идти разными путями: Scrum, PMBoK, 6-ти этапная модель, и т.д.
Хочется спросить у BegeMode: а реальными проектами по методике ЛИНК вы управляли? Насколько они были успешными? Могу точно сказать, что на практике указанные Магнусом нюансы имеют большую ценность, так как помогают найти выход в тумане. PMBOK — хоть и теория, но без лишнего. И еще большую практическую ценность имеют, на мой взгляд, ее «трактовки» вроде книжки Rita Mulcahy.
да, у меня есть и такая практика, и обратная (когда все делалось наобум)
однажды проект сильно тормозил… просто из-за сопротивления одной из влиятельных ЗС — с ней-то на этапе обумывания проекта никто и не посоветовался!
и это вылилось в такие палки в колеса! а «всего-то» нужно было — уделить ему внимание и слегка изменить требования к будущей системе…
Постановка СМАРТ-целей тоже помогает в работе, но является большим искусством, ибо многие не особо различают сами цели от решаемых задач
однажды проект сильно тормозил… просто из-за сопротивления одной из влиятельных ЗС — с ней-то на этапе обумывания проекта никто и не посоветовался!
и это вылилось в такие палки в колеса! а «всего-то» нужно было — уделить ему внимание и слегка изменить требования к будущей системе…
Постановка СМАРТ-целей тоже помогает в работе, но является большим искусством, ибо многие не особо различают сами цели от решаемых задач
вот так и губят интересные идеи!
При чтении раздела о рисках удивился тому, что в понятие риска заложено только «возможность неблагоприятного воздействия на проект...» в отличие от того же PMBoK, уже упоминавшемся в комментариях.
А есть ли место в изложенной модели для возможности благоприятного воздействия на проект?
А есть ли место в изложенной модели для возможности благоприятного воздействия на проект?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Этап подготовки проекта в теории