Проект водопад

Проект «Водопад»

уважаемые посетители Нашего сайта.

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

Предлагаем Вашему вниманию информацию к размышлению на предмет наших начинаний по восстановлению такого произведения искусства, как водопад на территории усадьбы Горенки в Балашихинском районе Московской области.

Более исчерпывающую информацию Вы можете получить разделах «История Балашихи», «История усадьбы», «Пыль веков» и «Краеведы».

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

Проект. Как «поток» идей превратить в «водопад» действий?Тест.

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

Слово «проект» по частоте употребления и в СМИ, и на бытовом уровне сегодня занимает одну из первых строчек в рейтинге. Сказал «проект» и все видят, что человек занят серьезным делом.

Однако, мне кажется, что настала та критическая точка в понимании смысла и значения этого слова, после которой может наступить невосполнимая потеря. Кажется,еще немного и понятие «проект», прописавшись в обыденной речи, навсегда уйдет из лексикона современных менеджеров. И это печально. Печально потому, что именно для них на слове «проект» базируется особенная современная концепция управления. И называется она проектно- ориентированным подходом к ведению бизнеса.Классический проектный подход создается на основе «водопадного» (Waterfall) цикла.Суть его проста:основная цель и задача проекта передается последовательно по этапам, напоминающим каскад.

Тест: Можете ли Вы считать себя проектным менеджером?

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

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

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

Эффективность проектного подхода не случайна.Он, как и водопад, начинается с маленького «источника», а затем, пройдя через рельефы и препятствия , перетекает в полноводное озеро, создавая его,как результат ваших действий.

Проект – это то, что всегда направлено на достижение конкретной цели. Он обязательно состоит из «каскада» взаимосвязанных действий, всегда уникален и имеет ряд ограничений (по времени, средствам, ресурсам и т.п.). Обычно выделяют 5 этапов классического проектного управления, но можно добавлять и дополнительные этапы, если того требует проект.

Ценность проектного управления, в отличие от традиционного менеджмента в том, что проектный менеджмент основан на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором цель и задача передаётся последовательно по этапам, напоминающим поток. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены, ожидаемые результаты прописаны и согласованы

Схема классического проектного подхода на основе «водопадного» (Waterfall) цикла: задача проекта передается последовательно по этапам, напоминающим каскад

Проект – уникальный процесс, состоящий из набора взаимосвязанных и контролируемых работ с датами начала и окончания и предпринятый, чтобы достичь цели соответствия конкретным требованиям, включая ограничения по времени, затратам и ресурсам (А.Клочков).

Проектом можно называть идею и действия по ее реализации с целью создания продукта, услуги или другого полезного продукта (В.Заренков). Это может быть некоторая задача с определенными исходными данными и требуемыми результатами (целями), обуславливающими ее решение (И.Мазуро, В. Шапиро, Н. Ольдерогге). Можно привести и другие мнения научного сообщества, они различаются в нюансах, но сходятся в одном.

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

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

Читайте так же:  Какой самый высокий водопад на земле
Проект – это переход от традиционного менеджмента (управление процессом) к проектному (управление по результатам) . Обеспечивает конкурентное преимущество гибкое поведение в неустойчивой внешней среде, экономию временных и иных ресурсов.

Мне часто приходилось бывать на мероприятиях, которые организаторы называли проектами. Здесь, как правило, всегда присутствовали выступающие, которых почему-то сейчас называют спикерами. Ручки и блокнотики, шарики и баннеры – поток фантазий организаторов ограничен только ресурсами.Все действия и атрибуты «заточены» только на организацию мероприятия как самоцели. Поговорили, повстречались и.. разошлись. Результата для публики — «там побывали», для организаторов — «провели». А зачем, для чего? Каковы качественные или количественные параметры эффекта или эффективности? Может, какого-то результата «проектировщики и хотели добиться. Но…

Может ли любое мероприятие стать проектом? Да, может, если обладает всеми его признаками и комплексом взаимосвязанных действий, направленных на достижение уникальных результатов в условиях временных и ресурсных ограничений. Ручки и блокнотики – хороши не сами по себе, а если «работают» на поставленную цель мероприятия/проекта. Цель может быть любой.Да,хоть, повышение узнаваемости торговой марки фирмы, продукта или самого организатора. Шарики тоже хорошо, если они способствуют атмосфере, необходимой для достижения поставленной цели. Я бы сказала, что любая фантазия допустима и даже необходима, но только в рамках проекта, где каждое действие связано единой «цепью» с проектом, а результат виден таким, каким был запланирован изначально.

Каскадная модель (англ. waterfall model , иногда переводят как модель «Водопад») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.

Содержание

  • 1 Содержание модели
  • 2 Критика каскадной модели и гибридные методологические решения
  • 3 См. также
  • 4 Примечания
  • 5 Ссылки

В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

В исходной каскадной модели следующие фазы шли в таком порядке:

  1. Определение требований
  2. Проектирование
  3. Конструирование (также «реализация» либо «кодирование»)
  4. Воплощение
  5. Тестирование и отладка (также «верификация»)
  6. Инсталляция
  7. Поддержка

Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того, как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того, как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.

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

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

Методику «Каскадная модель» довольно часто критикуют за недостаточную гибкость и объявление самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным. Поэтому даже в PMBOK 3-й версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов.

Начиная с PMBOK 4-й версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

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

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

Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа 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!

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *