Какая польза от планирования проекта

Agile: оценка и планирование проектовМайк Кон, «Agile: оценка и планирование проектов». – М.: «Альпина Паблишер», 2018.

Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. На помощь приходит Agile-подход, который применяют как стартапы, так и компании-гиганты вроде Yahoo! и Siemens. Благодаря Agile вы научитесь создавать реалистичные планы, которые сможете корректировать по ходу работы, при этом выполняя проекты в срок и в рамках бюджета. Майк Кон, гуру в области Agile, дает инструменты, необходимые для оценки, планирования и управления agile-проектами любого масштаба. В книге нет теоретических рассуждений, она полна конкретных примеров, методов, графиков, рецептов, а главное – аргументированных рекомендаций.

Цель планирования

Оценка и планирование критически важны для успеха проекта по разработке программного обеспечения любого размера и значимости. Планы определяют наши инвестиционные решения: мы можем взяться за проект, на выполнение которого, по нашим оценкам, потребуется полгода и $1 млн, и отказаться от этого же проекта, если на него потребуется два года и $4 млн. Планы помогают нам понять, кого нужно привлечь к работам по проекту в течение определенного периода. Планы помогают нам понять, как продвигается создание функциональности, которая нужна пользователям и получения которой они ожидают. Без планов мы открываем ворота для целого ряда проблем.

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

Тот факт, что оценка и планирование — дело непростое, не является открытием. Это известно давным-давно. В 1981 году Барри Боэм построил первую версию того, что Стив Макконнелл (Steve McConnell, 1998) позднее назвал «конус неопределенности».

На рис. 1.1 показаны первоначальные диапазоны неопределенности Боэма в разных точках в процессе последовательного развития («каскадный процесс»).

Конус неопределенности говорит о том, что на этапе оценки осуществимости проекта оценка обычно отклоняется от истины на 60-160%. Иначе говоря, на проект, который, как ожидается, должен занять 20 недель, может потребоваться от 12 до 32 недель. После формулирования требований в письменном виде оценка может отклоняться на 15% в любом направлении. То есть, плановый срок 20 недель может сократиться до 17 недель или вырасти до 23 недель.

Конус неопределенности сужается по мере выполнения проекта

выполнение проекта

Институт управления проектами (Project Management Institute — PMI) имеет сходную точку зрения на постепенное повышение точности оценок, однако он считает, что конус неопределенности должен быть асимметричным. PMI предлагает принимать начальный уровень отклонений оценки в диапазоне от +75% до –25%.

Следующий этап — бюджетные предположения — предполагает диапазон отклонений от +25% до –10%, за ним следует этап окончательной бюджетной оценки с диапазоном отклонений от +10% до –5%.

Зачем это нужно

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

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

Для ответа на этот вопрос команда анализирует функциональность, ресурсы и сроки. Ответ на данный вопрос нельзя найти одномоментно. Его ищут итерационно, шаг за шагом. В начале проекта мы, например, можем решить, что продукт должен иметь определенный набор функций, а его выпуск должен состояться 31 августа. Однако в июне оказывается, что лучше выпустить продукт немного позднее, но с более полным набором функций. А может наоборот: лучше сократить набор функций, но выпустить продукт чуть раньше.

Хороший процесс планирования поддерживает такой подход, обеспечивая:

  • Сокращение риска.
  • Снижение неопределенности.
  • Создание условий для принятия более качественных решений.
  • Формирование доверия.
  • Распространение информации.

Сокращение риска

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

На обсуждениях, происходящих в процессе оценки, поднимаются вопросы, которые позволяют выявить подводные камни проекта. Допустим, вас просят оценить, сколько времени потребуется на интеграцию нового проекта со старой, построенной на основе мейнфрейма системой, о которой вы ничего не знаете. Это заставляет смотреть на функцию интеграции как на потенциальный риск.

Проектная команда может устранить этот риск сразу, потратив определенное время на знакомство со старой системой. Альтернативно риск можно идентифицировать и учесть его в работе как отдельную величину или в виде диапазона и включить в общую неопределенность и риск.

Снижение неопределенности

В процессе реализации проекта команда создает новые функциональные возможности продукта, а также генерирует новые знания о продукте, используемых технологиях и своих собственных квалификациях. Крайне важно идентифицировать эти знания и учитывать их при итеративном планировании, которое должно помогать команде улучшать ее представления о продукте. Самым серьезным риском большинства проектов является риск создания несоответствующего продукта. Этот риск, однако, чаще всего полностью игнорируется. Agile-подход к планированию позволяет кардинально уменьшить (а в идеале устранить) такой риск.

Нередко цитируемые исследования Chaos Report (Standish Group, 2001) определяют успешный проект как такой, который выполнен в срок и в рамках бюджета и имеет все изначально предусмотренные функциональности. Это опасное определение, поскольку оно не учитывает того, что функциональность, казавшаяся хорошей до начала проекта, может оказаться не стоящей вложений, когда команда реально возьмется за дело. Если бы меня попросили дать определение неудачному проекту, то в числе прочего я бы назвал «Проект, в котором никто не высказал более удачных идей, чем включенные в исходный перечень требований».

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

Условия для принятия более качественных решений

Оценки и планы помогают нам принимать решения. Как организации определить, стоит ли браться за тот или иной проект, не имея оценки стоимости и затрат по проекту? Помимо поддержки решений относительно принятия проектов оценки позволяют гарантировать, что мы работаем над самыми ценными проектами.

Предположим, что организация рассматривает два проекта, один из которых оценивается в $1 млн, а другой в $2 млн. Во-первых, календарные графики и оценки затрат нужны организации для того, чтобы определить, есть ли смысл заниматься этими проектами; не окажутся ли они настолько продолжительными, что не уложатся в рыночное окно? Не окажутся ли они настолько затратными, что потеряют смысл? Во-вторых, оценки и план нужны организации, чтобы решить, за какой проект взяться. Может оказаться, что у организации есть возможности реализовать один проект, оба проекта или ни один из них, если затраты слишком высоки. Оценки необходимы организации для принятия и других решений, помимо решения о том, браться за проект или нет.

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

Многие решения, принимаемые в процессе планирования проекта, являются компромиссными. Например, в любом проекте неизбежно приходится искать компромисс между временем разработки и затратами. Нередко наименее затратный путь разработки системы — это нанять одного хорошего программиста и позволить ему работать над созданием продукта 10 или 20 лет с возможностью отвлекаться на освоение соответствующей профессиональной сферы, совершенствование в области администрирования баз данных... Очевидно, однако, что возможность ждать появления готового продукта 20 лет редко когда выпадает, поэтому мы поручаем работу команде. Команде из 30 человек, возможно, потребуется год (30 человеко-лет) на разработку, с которой один программист мог бы справиться за 20 лет. Стоимость разработки при этом возрастает, однако стоимость, создаваемая при получении продукта на 19 лет раньше, покрывает увеличение затрат.

Нам постоянно приходится принимать компромиссные решения в отношении функциональности, трудозатрат, издержек и времени. Стоит ли из-за той или иной функции откладывать выпуск версии продукта? Следует ли нам привлечь к проекту еще одного разработчика, чтобы включить конкретную функцию в ближайший релиз? Следует ли выпустить версию в июне или стоит отложить выпуск до августа и включить в нее дополнительную функцию? Следует ли нам купить данное средство разработки? Для принятия решений нам необходимы оценки как затрат, так и выгод.

Доверие

Частая надежная поставка обещанной функциональности рождает доверие между разработчиками и заказчиками продукта. Достоверные оценки обеспечивают надежность поставки. Оценки нужны клиенту для распределения приоритетов и принятия компромиссных решений. Оценки также помогают клиенту решить, сколько функций разрабатывать. Вместо того чтобы потратить 20 дней и получить все, может быть, лучше ограничиться 10 днями и получить 80% выгод. Клиенты с неохотой идут на принятие подобных компромиссных решений на начальной стадии осуществления проекта, если оценки разработчиков не внушают доверия.

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

Распространение информации

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

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

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

Что делает план хорошим

Хорошим считается такой план, который, по мнению заинтересованных сторон, является достаточно надежным, чтобы на его основе принимать решения. На начальном этапе осуществления проекта это может быть указание на то, что продукт будет выпущен скорее в третьем квартале, а не во втором и что он будет иметь примерно обрисованный набор функций. На более позднем этапе работ этот план, чтобы оставаться по-прежнему полезным для принятия решений, должен быть более точным.

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

Другие сотрудники компании могут использовать этот план для принятия решений. Они могут готовить маркетинговые материалы, планировать рекламную кампанию, выделять ресурсы на переобучение ключевых клиентов... Этот план полезен до тех пор, пока он реально предсказывает, что будет происходить в процессе работы над проектом. Если разработка займет 12 месяцев вместо запланированных шести, то план нельзя назвать хорошим.

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

Эта книга посвящена agile-подходу к планированию, а не гибким планам. Планы — это документы и цифры, статическое описание наших представлений о развитии проекта в неопределенном будущем. Планирование — это вид деятельности. Agile-подход предполагает перенос акцента с планов на процесс планирования.

Agile-подход позволяет сбалансировать вкладываемые в планирование усилия и трудозатраты с учетом того, что план будет пересматриваться в процессе осуществления проекта. Никто не собирается менять план ради изменений, изменения вносятся потому, что мы получаем новую информацию или исправляем ошибки. Мы можем получить информацию, например, о том, что пользователи хотят расширить конкретную функцию или, наоборот, урезать ее, или узнать, что простота использования продукта значительно важнее, чем казалось вначале, или обнаружить, что программирование на новом языке занимает больше времени, чем ожидалось. Финансовые последствия каждого такого изменения можно оценить и, если это целесообразно, изменить план и календарный график.

Вновь выясненные обстоятельства влияют на наши планы. Это означает, что нам нужны такие планы, которые можно легко изменять. Именно поэтому процесс планирования становится более важным, чем сам план. Знания и представления, которые мы получаем в процессе планирования, продолжают существовать и после того, как от старого плана отказываются и заменяют его новым. Таким образом, под гибким понимают такой план, который легко поддается изменениям.

Изменение плана само по себе не означает изменение дат. Мы можем сделать это, а можем и не делать. Однако, если оказывается, что мы заблуждались в отношении определенного аспекта целевого продукта и нужно устранить ошибку, в план необходимо внести изменения. Существуют разные способы корректировки плана без изменения даты. Можно отказаться от функции, можно сократить ее объем, можно увеличить численность работников, занятых в проекте...

Поскольку мы признаем, что не можем с абсолютной точностью определить все аспекты проекта с самого начала, нам не нужно пытаться запланировать все и вся на начальном этапе. При agile-подходе планирование осуществляется более или менее равномерно на протяжении всего срока реализации проекта. Вслед за планированием релиза, закладывающим фундамент, выполняется серия раундов планирования, и весь процесс многократно повторяется по мере осуществления проекта.

Итак, при определении agile-подхода к планированию мы установили, что он:

  • Фокусируется на планировании, а не на плане.
  • Поощряет изменения.
  • Приводит к составлению планов, легко поддающихся изменению.
  • Распределяет процесс планирования по всему сроку осуществление проекта.

Резюме

Оценка и планирование критически важны, однако сложны и подвержены ошибкам. Так или иначе, отказываться от них просто из-за трудности нельзя. Оценки, данные в начале проекта, значительно менее точны, чем оценки, полученные позднее. Графическое представление процесса постепенного повышения точности оценок называют конусом неопределенности.

Цель планирования — получение оптимального ответа на глобальный вопрос разработки продукта — вопрос о том, что именно создавать. Ответ включает в себя описание функций, ресурсов, а также календарный график. Ответ на этот вопрос, подкрепленный снижающим риск процессом планирования, сокращает неопределенность, дает основу для объективного принятия решений, устанавливает доверие и обеспечивает распространение информации.

Хорошим является такой план, который достаточно надежен, чтобы на его основе принимать решения относительно продукта и проекта. Agile-подход к планированию сфокусирован больше на планировании, а не на создании плана, поощряет изменения, приводит к составлению планов, легко поддающихся изменению, и распределяет процесс планирования по всему сроку осуществления проекта.

Фото: mountaingoatsoftware.com

Расскажите коллегам:
Комментарии
Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Что за люди? Сами встряют в серьёзный разговор, а потом истерят от хихиканья до оскорблённости.

С чего всё началось? – С моего утверждения, что реально проекты планируются отнюдь не чудодейственным Agile. И PMBoK со всякими проджектами, примевами и т.п – не помощники. А планируются проекты так, как описано в моей Е-хе-статье. В ней прямо указано, что её новизна – методическая. Я всего лишь показал как методику, существовавшую (наверное) лет сто, применять в среде программы Excel. Статья написана в простом-очевидном стиле – в стиле «прочти и применяй».

Если я неправ, то адепты эджайлов с пмбуками и прочая могли бы привести хотя бы один пример применения своей грамоты. И все бы признали их правоту. Так нет же, они постоянно отвечают одним и тем же – сначала пытаются обсмеивать; а потом изображают истерику оскорблённости. Но, это же поведение мошеников. Вот сейчас опять забьются в истерике. Да -- успокойтесь и приведите, наконец, хотя бы один пример применения своих знаний, которые вы так подло защищаете.

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Да, я считаю, что "методология" Agile основана на подлости. Сначала утверждается, что проектировщики работают «детерминировано». А затем делается подлог: обычный итерационный процесс в проектировании, представляется как нечто совершенно новое.

Представим, к примеру, «работу технолога в стиле Agile». Вместо того, чтобы спланировать процесс изготовления, путём разработки технологических карт и приложения их к чертежам, он приходит в цех и провозглашает там лозунги-манифесты-принципы.

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Михаил Ободовский пишет Людмиле Апраксиной (08 мая 2018, 12:29):

Уважаемая Людмила, вот в этой дискуссии 04 марта сего года в 22:42 г-н Зонзов сделал так называемое заявление о невменяемости. После этого я прекратил реагировать на его слова. Рекомендую Вам сделать то же самое. Сожалею, но я не могу защитить Вас от потока оскорблений, извините.

.====================================================.

Вот моё сообщение от 04 марта 2018, 22:42:

Андрей Семеркин пишет:
Уважаемые участники дискуссии, не кажется ли вам, что вы отвлеклись от темы и перешли к обсуждению друг друга?

Андрей Геннадиевич,

Конечно, Вы правы. Но, я почти 4 года живу в условиях, в которых трудно аплодировать политике США. И мне не по себе, когда авторы обезличенных скептических откликов на такую политику получают вполне личные негативные ярлыки.

.==================================.

Также и Л.Апраксина «умело» цитирует мой комментарий о поведении Меланьи Трамп на протокольном мероприятии.

Партнер, Красноярск
Людмила Апраксина пишет: Сорри, гибкие подходы не применяются для строительных проектов ) Строительные проекты имеют точный результат строительства - объект должен быть построен в соответствии с какой - либо ПСД или аналога ПСД (проектно - сметной документации). Так что там не может быть "Agile-подрядчиков"

Вы наверное никогда не участвовали в строительных проектах российских компаний? ))) Любой, кто участвовал, так уверенно не говорит, "и в цирке не смеётся".

И да, PMBoK штука хорошая, но неполная для практического применения (хоть и движутся вроде куда надо). И при выборе между двумя орлами с сертификатами я как-то выбрал не того, кто лучше знал текст, а того, кто был смышлённей по жизни (да, я читал сей документ, дважды ))) )

Владимир Зонзов пишет:
реальная работа (в том числе и планирование) выполняются по цепочке:
  • исходные данные;
  • техническое задание;
  • проект (эскизный, рабочий);
  • смета;
  • графики производства и обеспечения работ

И для выполнения работ по этой цепочке сертификаты-буки-проджекты-скрамы-эджайлы – бесполезны.

Ну, передергивать тоже неправильно. Учиться - надо постоянно, главное потом переосмыслить узнанное, а не тупо заучить и навесить себе шоры.

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина
Олег Севодин пишет:
Ну, передергивать тоже неправильно. ...

Олег, Вас не затруднит указать конкретно, что "передёрнуто"?

И насчет "Учиться - надо постоянно, главное потом переосмыслить узнанное, а не тупо заучить и навесить себе шоры" ---- кто бы возражал.

.======================================.

А что касается участия в строительных проектах российских компаний ---- думаю, что Вас понимаю. Я не встречал строек, которые выполнялись бы по готовому рабочему проекту. ...

Партнер, Красноярск
Владимир Зонзов пишет:
Олег, Вас не затруднит указать конкретно, что "передёрнуто"?

А что касается участия в строительных проектах российских компаний ---- думаю, что Вас понимаю. Я не встречал строек, которые выполнялись бы по готовому рабочему проекту. ...

Я пока тоже, хотя попыток не оставляю )))

А насчёт "передёрнуло" - слово "бесполезны". Ибо не читавшие книг типа PMBoK-а, вааще не умеют управлять проектами. Ага, читавшие (как правило) не умеют управлять ими правильно, если ещё кой-чего не прочитали, но хоть что-то.

Даже если технологии фуфло (каким мне, например, пока представляется agile, обратного никто смог доказать) - изучать их стОит, надо же знать, как "не надо".

Руководитель проекта
Олег Севодин пишет:
Вы наверное никогда не участвовали в строительных проектах российских компаний? )))

Участвовала ) знаю)

Да, в принципе, уже не смешно обсуждать тему когда пилят молотком и сверлят лопатой. Потом говорят - плохой молоток (лопата) не пилит (не сверлит).

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

Вот приблизительно что наблюдаю при трактовке применения практик управления проектами.

Зачем в цирк? в цирк ходить не надо ...

Руководитель проекта
Владимир Зонзов пишет:
Также и Л.Апраксина «умело» цитирует мой комментарий о поведении Меланьи Трамп на протокольном мероприятии.

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

Ссылка на диалог с кошечками, оскорбительными высказываниями относительно личной жизни публичных официальных лиц и участников обсуждения и призывами сексисткого плана https://www.e-xecutive.ru/career/lichnaya-effektiv... https://www.e-xecutive.ru/career/lichnaya-effektiv...

+242Людмила Апраксина Руководитель проекта

Владимир Зонзов Директор по производству, Украина пишет:
... что позволила себе жена Трампа перед всем миром ... она показала свою глупость.

Что сделал бы царь Иван IV (Грозный) после таких взбрыков женушки? Он приказал бы своей свите пинками загнать её обратно в карету, засунуть под лавку, привезти обратно в палаты, посадить на цепь в монастыре, кормить хлебом и водой. И пусть до конца дней своих думает о своём поведении на чужом (мужнином) празднике жизни.

И это правильно. Ибо, «всяк сверчок должон знать свой шесток». :)

Специально посмотрела видео о жене Трампа. Она не увидела поданную руку, может, устала после перелета. Даже если она, по Вашему мнению, "показала свою глупость" - это ее личное дело. А личное дело Трампа - как к этому относится, его это не задевает ни как мужа, ни как президента.

Для "подумывания над поведением" и о "сверчках на шестках":

"пинками загнать" -

УК РФ, Статья 116. Побои

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

наказываются ... лишением свободы на срок до двух лет.

"посадить на цепь" -

УК РФ, Статья 127. Незаконное лишение свободы

1. Незаконное лишение человека свободы, не связанное с его похищением, -

наказывается ... лишением свободы на срок до двух лет.

"засунуть под лавку" -

УК РФ, Статья 282. Возбуждение ненависти либо вражды, а равно унижение человеческого достоинства

1. Действия, направленные на возбуждение ненависти либо вражды, а также на унижение достоинства человека либо группы лиц по признакам пола...совершенные публично или с использованием средств массовой информации либо информационно-телекоммуникационных сетей, в том числе сети "Интернет", -

наказываются ... лишением свободы на срок от двух до пяти лет.

Можно продолжить коллекционирование сроков по остальным пунктам комента.

Вы действительно с этим согласны и к этому публично призываете?

1


Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Олег Севодин пишет (08 мая 2018, 19:33):
А насчёт "передёрнуло" - слово "бесполезны". Ибо не читавшие книг типа PMBoK-а, вааще не умеют управлять проектами. Ага, читавшие (как правило) не умеют управлять ими правильно, если ещё кой-чего не прочитали, но хоть что-то.

Надеюсь, что понимаю сказанное Вами.

Что необходимо для управления проектами, я кратко описал в статье "Руководители инвестпроектов -- кто они?". К сожалению Е-хе-редакция заменила это адекватное название на пошлое "Царь и бог проекта". Содержание статьи – это не мои выдумки, а описание того, как фактически обстояло дело в советские времена и в начале 2000-х гг.

Владимир Зонзов +10253 Владимир Зонзов Директор по производству, Украина

Людмила Апраксина,

Вы же сами процитировали мои слова в своём комментарии от 08 мая 2018, 21:32. Ими я высказал мнение, что бы сделал Иван Грозный с женушкой за подобное нарушение протокола. Тем более, что это поведение Меланьи Трамп спровоцировало унижение Трампа и в следующих протокольных встречах; унижение типа «не подай руку Трампу».

А чуть ранее (08 мая 2018, 12:03) вышеупомянутое моё мнение Вы изложили так: … Вы публично, на этом сайте призывали Меланию Трамп, за то что она не взяла мужа за руку "избить, истаскать за волосы и пинкам загнать под лавку".

Вам что, деньги платят за то, чтобы спровоцировать на скандал любого, кто скажет что-то против ПМБуК-ов, Эджайлов, проджектов?

.===========================================.

Я не раз высказывался, что ПМБуК-и, Эджайлы, проджекты – полезные средства. Но, их польза весьма локальна-узкопрофессиональна. Поэтому, ими нельзя заменять изучение-применение традиционных средств работы по проектам. И тем более нельзя ими разрушать сложившуюся в советские времена систему подготовки кадров для работы по проектам. Но – разрушили. Затоптали-замолчали сделали необязательным применение советских ГОСТ-тов. Исключили разработку новых ГОСТ-тов. Навязали в порядке послевузовской подготовки дорогостоящую процедуру получения «международных сертификатов». И организовывают скандалы со всеми, кто запросит примеры, подтверждающие обещания, которыми сопровождается реклама ПМБуК-ов, Эджайлов, проджектов.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Новости образования
В МИРБИС отметили 305-й выпуск по программам MBA

В бизнес-школе состоялось юбилейное 305-е торжественное вручение дипломов по программам МВА и Executive МВА.

НИУ ВШЭ и НовГУ запустят совместный бакалавриат

В данный момент завершился первый модуль по обучению для преподавателей и сотрудников Новгородского государственного университета имени Ярослава Мудрого.

«Иннопрактика» и РВК запустили отбор быстро растущих компаний совместно с ВШБ НИУ ВШЭ

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

МИРБИС остается в числе 2% бизнес-школ мира, обладающих аккредитацией АМВА

МИРБИС сохранил престижную аккредитацию, которая выдается сроком на 5 лет.

Дискуссии
Все дискуссии
HR-новости
В российских IТ-компаниях не хватает специалистов по кибербезопасности

Также компании отмечают высокую потребность в системных аналитиках.

 

Опубликован рейтинг лучших работодателей 2022 года по версии HeadHunte

За год список HeadHunter увеличился на 28%, финалистами рейтинга стали 1082 организации.

Россияне стали чаще конфликтовать на работе

По сравнению с 2019 годом, вдвое увеличилось число респондентов, когда-либо ссорившихся с коллегами и начальством начальством.

Две трети россиян думают о смене места работы в 2023 году

Больше всего хотят сменить работу респонденты из таких сфер, как маркетинг и управление персоналом.