Комментарии 16
Мы действуем по накатанным рельсам и четко знаем каждый следующий шаг. В таком проекте нет смысла проводить какие-то изменения: даже на начальном этапе все достаточно просто распланировать, выдать оценку и посчитать стоимость, так как подобное делали раньше. Думаю, вы поняли о чем идет речь.
Я не понял. Где вы видели такие проекты? Вообще ваше изложение про Waterfall весьма поверхностное.
Главный минус метода – приходится переделывать все с самого начала, так как нельзя внести изменения в какой-то конкретный этап.
Почему с самого начала? В Waterfall есть процедура управления изменениями (описанная в PMBoK), специально предназначенная для внесения изменений. Вносите изменения оперативно и гибко - затраты на изменения будут минимальны. И почти никогда изменения не требуют переделывать с самого начала. Обычно это запрос каких то фич, которые изначально не планировались. Я вообще ни разу не видел, чтобы проект (Waterfall или нет) переделывали с самого начала, а изменений в любом проекте десятки и сотни. Просто в эджайле они приветствуются, а в каскадном ограничиваются.
да, есть такая процедура, но бывает и такое, когда мы начинаем переделывать или добавлять какую-то фичу (по требованию заказчика), то одна фича цепляется за другую и они получается связаны между собой таким образом, что одну без другой нельзя будет выполнить (а ведь такая сцепка предположительно может быть и с несколькими фичами). Особенно процесс может затруднить момент, если мы находимся уже в самом конце - на этапе тестирования. Таким образом, мы откатимся назад. В любом случае придется заново посчитать бюджет по проекту и снова пройти этапы жизненного цикла, потому что мы работает по фиксированной оплате.
Тут уже стоит уделять внимание риск-менеджменту и заранее закладывать больше бюджета на случай таких ситуаций. Либо доработки выносить в рамки отдельного проекта
Вы сейчас всего лишь сказали, что бывают изменения простые, а бывают сложные. Бывают. Мало того, они и в эджайл и в каскадном одинаково бывают. Стоят практически одинаково. Разница лишь в том, что в эджайл вы расстаётесь с бюджетом легко и непринуждённо при каждом новом изменении, а в каскадном будете мучительно согласовывать, обсчитывать и доказывать. Но суть изменения и объём работ и переделок от этого не поменяются.
Тут уже стоит ... и заранее закладывать больше бюджета на случай таких ситуаций.
Конечно стоит. А в Эджайл изначально заложен бесконечный объём изменений.
И ещё я не понял, вы противопоставляете Waterfall и PMBoK? Но PMBoK покрывает в том числе и Waterfall.
С Kanban путаница уже давно. Что конечно немного усложняет жизнь вчерашним студентам, которые топят за чистоту методолгии. на третий месяц месяц привык
ничего нового
Если Вы посмотрите на определение проекта ( Проект (в управленческой деятельности) — Википедия (wikipedia.org) ), то поймёте, что проект ВСЕГДА создаёт уникальный продукт или услугу (иначе это уже не проект, а операционная деятельность). Поэтому все рассуждения про накатанные рельсы - это немного не то.
Еще было бы хорошо, чтобы Вы определились с терминологией: методология и фреймворк - это очень разные понятия. А по заглавию вы вообще ищете "модель".
В общем, как обзорная статья - слабовато. Рекомендуется продолжить и усилить.
Безусловно, проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата. Так и написано и в PMBok.
Про накатанные рельсы и используемую терминологию хочу сказать, что статья проходит процедуру форматирования и некоторые обороты речи и выражения могут быть изменены/удалены и отличаться от изначального варианта.
В оборот речи "накатанные рельсы" закладывался следующий смысл: методология Waterfall - это не какое-то готовое клише, которое можно подгонять под любые проекты с типом среды "Простая упорядоченная", так как нет уникальности; а это какие-либо уже наработанные решения на которые можно опираться на страте проекта, позволяя осуществить качественное планирование и анализ, чтобы минимизировать последующие возникшие негативные риски.
Я приводила пример из своего личного опыта - внедрение CRM системы. Безусловно, каждый проект по внедрению CRM является уникальным, так как присутствуют свои технические особенности и пожелания заказчика, но тем не менее прослеживается определенная общая логическая нить последовательности действий, если сравнивать такие проекты между собой. Поэтому, можно заранее определенные вещи спрогнозировать на этапе инициации.
На мой взгляд Waterfall отлично ложиться на такую ситуацию.
Всё уже придумано, до вас)) Почему вы так по скотски относитесь к нашей, отечественной практике?? Слово ПРОФЕССИЯ потеряло, похоже, вообще всякий смысл...
А junior до senior - это вообще звучит, как клички мексиканских наркоторговцев))
Профстандарт: 06.016 "Руководитель проектов в области информационных технологий"
https://habr.com/ru/post/715256/ "Проектный Менеджер в IT. Обязанности без полномочий"
В первую очередь, это опыт, который можно консолидировать и проанализировать с помощью известного инструмента «PMBOK» — руководство к своду знаний по управлению проектами. Это стандарт проектного управления.
Противоречивые "параграфы"! (как минимум, дважды).
Разницу между "методология" и "методика" автор, imho, не понимает. "скоуп методологий" -- кайф :-)!
Не секрет, что в США IT‑технологии развиваются быстрее, чем в России
Вы сами ответили на свой вопрос. Нафига изобретать "велосипед", когда все уже давно придумано до нас? Неумение ездить на велосипеде ещё не говорит о том, что он не подходит. И менталитет тут совершенно не при чем
Россиянам привычнее выполнять работу коллективно...
В статье очень не хватает аргументов, которые обосновали бы тезисы автора о пресловутом "российском менталитете". Хабр — это, конечно, не научный журнал, до ссылки на результаты каких-нибудь серьёзных исследований в дополнение к личному опыту автора явно не помешали бы.
Проблема в том, что результаты исследований как раз свидетельствуют об обратном: по данным Kelly Services, например, российские сотрудники в основном предпочитают командной работе более индивидуалистическую модель с четким разделением зон ответственности. Я не утверждаю, что это исследование на 100% точное (выборочные исследования никогда таковыми не бывают), но даже если его выводы ошибочны, хотелось бы ознакомиться с подтверждением противоположной точки зрения.
Делать выводы о преобладании в обществе индивидуализма ил коллективизма на основе отдельны фактов à la американские школьники хотят быть популярными, а в российских компаниях открытые офисы, не вполне верно, ведь на каждый подобный аргумент можно подобрать контраргумент: в Америке, к слову, очень важную роль в общественной жизни играют довольно интегрированные локальные сообщества соседей, но мы же не будем только поэтому утверждать, будто американцы — неисправимые коллективисты
Проектное управление в IT: эффективные модели в российских реалиях