tag:blogger.com,1999:blog-3704723600302758629.post4946181359341774663..comments2022-03-24T21:46:21.583+02:00Comments on Блог Сергея Бородавкина: Project Management Plan HellSergey Borodavkinhttp://www.blogger.com/profile/06154243184694262346noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-3704723600302758629.post-37160059695217284032011-02-20T10:00:45.689+02:002011-02-20T10:00:45.689+02:00Документ апрувал и контроль (managerial или скорее...Документ апрувал и контроль (managerial или скорее supporting process) не является частью разработки (engineering process). Можно ли от него отказаться? В маленьких организациях/проектах - да, в больших - нет. Скорее, можно думать над тем, как бы оптимизировать эту унылую цепь, тянущуюся от создания до утверждения документа.Sergey Borodavkinhttps://www.blogger.com/profile/06154243184694262346noreply@blogger.comtag:blogger.com,1999:blog-3704723600302758629.post-78138315626851843092011-02-15T15:47:18.170+02:002011-02-15T15:47:18.170+02:00Сережа, я несколько раз перечитывал твой ответ и п...Сережа, я несколько раз перечитывал твой ответ и пытался осмыслить все это в контексте решения проблемы. И я вижу несколько несостыковок. Во-первых, "Пока писал, придумал такое описание проблемы: от нас не требуют водопадный процесс разработки, но при этом требуют водопадный Document Approval and Control."<br />Но ведь и Document Approval and Control являются частью разработки, не так ли? А является ли этот этап жизненно-необходимым для выпуска качественного продукта? Или же его создание отнимает время у тебя, команды (пересчитываем в $), вынуждает лгать о реально положении дел (которые не стоят на месте и постоянно изменяются и зависят от сотни факторов), усложняют и без того уже сложный процесс создания продукта. На мой взгляд, все это пахнет бюррократией и самообманом. Кстати, такое часто случается, когда штат компании слишком раздут и высокие начальники создают видимость работы и своей нужности (не подумай, что камень в твой огород - напротив).<br />И вот прямо в конце поста ты сделал правильный вывод, который и я предложил, просто более завуалированно - переход к более гибким agile процессам, в которых по определению отсутствует такая волокита - на нее попросту нет ресурсов в рамках спринтов: "- отказ от РМР.". Просто если ты заявишь заказчику: "А давайте откажемся от PMP", тебя могут неправильно понять. А предложив усовершенствовать процесс разработки, при этом не акцентируя внимания на отказе от всякой требухи, больше шансов. :)<br /><br />P.S. Я не сторонник ни Scrum, ни XP, ни RUP, ни . Я сторонник здравого смысла и простоты.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3704723600302758629.post-13257916163937804312011-02-06T15:22:24.975+02:002011-02-06T15:22:24.975+02:00Артем, как мне кажется, здесь проблема не в процес...Артем, как мне кажется, здесь проблема не в процессной модели разработки. У нас никто не настаивает на водопаде - можно использовать гибкие методологии, итеративные подходы и пр. Дело в другом. К примеру, завтра я решаю перевести проект на тот же SCRUM. Первое, что я должен сделать - обновить РМР, расписав в нем то, как мы будем реализовывать все практики SCRUM. Очень может быть, что в таком РМР больше не будет фигурировать план-график, однако даже в самых гибких процессах наличествуют проектная команда, метрики, стейкхолдеры, да тот же scope. Поэтому, спустя неделю после того, как я закончу его переделывать, понадобится снова провести командное ревью, утвердить документ внутри компании и у ПМ-а со стороны заказчика, на что уйдет еще месяц. А спустя этот месяц обязательно появится какая-то новая метрика, которую нужно собирать, под нее - quality goal, в общем - "все опять повторится сначала". <br /><br />Пока писал, придумал такое описание проблемы: от нас не требуют водопадный процесс разработки, но при этом требуют водопадный Document Approval and Control.Sergey Borodavkinhttps://www.blogger.com/profile/06154243184694262346noreply@blogger.comtag:blogger.com,1999:blog-3704723600302758629.post-79153266083806200512011-02-04T03:11:09.373+02:002011-02-04T03:11:09.373+02:00"Пути решения могут быть, например, такими:&q..."Пути решения могут быть, например, такими:"...<br /><br />... Как переход к более "легковесным" процессам управления, использование agile практик. Например, SCRUM. Будет больше толку и меньше бюрократии.<br /><br />Водопадная модель явно не подходит для современных проектов с постоянно меняющимися требованиями. Либо, если уж на то пошло и клиент настаивает на использовании текущего процесса, то одним из пунктов плана проекта в обязательном порядке должно фигурировать "Requirements and spec freeze".Anonymousnoreply@blogger.com