О роли качества в ИТ-проектах.

Метод (Pulse Management) определяет что качество должно быть превосходным или максимально превосходным. Однако повышение качества это инвестиции. Как определить когда нужно начинать инвестировать в качество?

Одним из популярных в последнее время подхода является: "Давай сделаем кое-как выгрузим в рынок , протестируем гипотезу." потому что "Так завещал Аgile"

Однако, у приверженцев такого подхода потом не хватает смелости выбросить этот прототип.

Как результат:
1. Не выполняется правило XP (eXtreme Programming) "Прототип на выброс"
2. Не выполняется ценность XP "Смелость" - нужна смелость чтобы выбросить сделанное.
3. Прототип на самом деле не настоящий Прототип который за 2 для делается.
4. Архитектура в прототипе не адаптирована под изменения.

Дальше это идёт как снежный ком обрастая дефектами, хотя нужно остановиться, и пересмотреть всю систему.

Из личной практики: Я руководствуюсь правилом: поднимаем автоматические модульные тесты если больше 3 человеко-недель объема работы.

При этом во времени это выглядит так:

1 неделя - модель/прототип
2 неделя - отладка с реальными данными
3 неделя - определение новых сценариев
4. неделя - пора писать тесты и переходить к полному циклу, а то начинает отваливаться ранее написанное.

Если на проекте 2 инженера, то контрольное время сокращается. А больше 2 инженеров на прототипе не нужно.

#метод #agile

Практика применения алгоритма планирования и инструментов ТОС из первых уст. В заметке ниже:

В воскресенье обсуждали с коллегами этап планирования проектов и дерево предпосылок.

Во время обсуждения, нам вспомнилось одно практическое наблюдение: если при планировании проекта, вы слышите фразу "Да тут всё понятно, что тут обсуждать!", то это признак того, что надо насторожиться, и глубже копнуть в этот вопрос.

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

Возможно это происходит по той причине, что мозг человеческий думать не любит — экономит ресурсы. А неопределенность без думания не прояснить. Поэтому для экономии ресурсов, мозг выдаёт первый, самый простой автоматический ответ - "да тут всё просто, нужно взять и сделать". Чем больше мы торопимся, тем выше вероятность пропустить этот автоматический ответ мимо сознания.

Поэтому делайте планирование со свежей головой в спокойной обстановке. А если встретите что-то, что кажется простым — насторожитесь. Возможно стоит уделить этому "простому" чуть больше внимания и подумать о препятствиях, которые могут возникнуть на вашем пути.

Картинка к предыдущей заметке

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

== 5.2 Дао программирования

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

''Мне кажется что вы несколько оторваны от действительности'', сказал Начальник, ''все же, сколько это займет?''.

Программист на миг задумался. ''У меня есть несколько идей, которые я хотел бы вставить в программу. Это займет по меньшей мере две недели'', сказал он наконец.

''Даже такой срок не кажется мне достаточно реалистичным'', настаивал Начальник. ''Я буду доволен, если вы просто сообщите мне, когда программа будет готова''.

Программист согласился.

Спустя несколько лет Начальник уходил на пенсию. По дороге к праздничному столу, накрытому в честь его ухода, он обнаружил, что Программист спит у терминала. Он программировал всю ночь.
==
Источник: http://www.karasik.eu.org/dao.html

Задание на выходные: посмотрите мультфильм "Пёс в сапогах"
https://premier.one/show/pes-v-sapogah

и ответьте на вопросы на картинке.

Обсуждая с Иваном Абашкиным (https://t.me/ivan_abashkin) аспекты применения POOGI относительно диалектики, я могу теперь ответить на два вышеназванных вопроса:

= Ритм технологий =

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

Однако ссылка на это Ритм есть в главе "Правила непрерывного
проектирования".

Ритм проектирования Изделия, а именно "ПРИНЯТИЕ РЕШЕНИЙ о том КАК ДЕЛАТЬ" должен иметь свою периодичность - это период пересмотра и анализа предлагаемых решений относительно архитектуры Изделия. Если ритм не задать, то есть риск уйти в паралич анализа. И Ритм помогает сфокусироваться и сделать процесс управляемым.

Инструменты ритма:

Подготовка:
1. Мыслительный процесс ТОС "Дерево перехода" в отношении целевых функций системы но с другими вопросами:
а) Какой нужен целевой результат?
б) Что мешает получить целевой результат?
в) Какая должна быть характеристика системы для преодоления этого препятствия?


Мероприятие ритма:

последовательный анализ решения командой проекта с применением инструментов:

а) Мыслительный процесс ТОС "Дерево будущей реальности"
б). Алгоритм "Снижение архитектурных рисков" https://vimeo.com/240325104

#метод #метод_пульса

Я начал ссылаться на Метод управления проектным бизнесом "Pulse Management" однако в чате закреплена только ссылка на печатную книгу (за деньги). Но на самом деле, эта книга есть и в бесплатной авторской редакции на сайте Метода:

https://pulsemanagement.org/

#метод #метод_пульса

Результаты исследования 2021 года.

Было всего 7 ответов. Интересные выводы: несмотря на полученный положительный эффект, только 30% (2/7) компаний продолжили применение CCPM.

Препятствия к применению:
- трудности синхронизация задач между командами и компаниями
- срыв сроков не по нашей вине
- "нам еще рано"
- слишком высокое давление на команду (50% оценка задач).

#ccpm

= Ритм качества =

Вершина качества связана со всеми другими вершинами, и за неё отвечает инструмент Метода "Качество" .

Частота этого ритма определяется исключительно скоростью изменения организации и скоростью выпуска новых изделий на рынок. Для некоторых это 3 месяца, а для других год.

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

Таким образом мероприятия Ритма "Качество" - это регулярные стратегические сессии по пересмотру состояния компании относительно ситуации и рынков и выработка новых целевых показателей относительно которых нужно развивать вершины Цель,Технологии и "Процессы и правила".

Такая сессия должна охватывать:
а) Анализ изменений внешней среды
б) Анализ трендов изменений внешней среды
в) Анализ положения компании в рынке
г) Проектирование будущего положения компании в рынке.
д) Анализ текущих процессов и правил относительно будущего положения компании и выявление нежелательных явлений и препятствий которые не позволяют достигнуть цели.

Запись семинара 29 марта 2012 года о применении CCPM в строительстве.

Открытый семинар: Леонид Казинец (Председатель совета директоров и основатель корпорации «Баркли»)
"Почему в России так строят? Чего не хватает для управления проектами? Современные теории управления бизнес-процессами в строительстве: концепции Just in Time, Lean manufacturing, практика Kaizen"

https://www.youtube.com/watch?v=roolQKH8-fc&feature=youtu.be

#ccpm

Из недавней дискуссии об аспектах планирования и выявления Угроз.

В Методе управления проектным бизнесом "Pulse Management" есть скрытая посылка которая следует из границ применения:

1. Метод применим для ИТ-проектов и НИОКР.

Это значит, что (срытая посылка):

2. Большая часть работ в проектах ИТ и НИОКР имеет примерно одинаковую длительность.

Следствие посылки 2:

3. Отклонения в оценках длительности работ (значительно) выбивающиеся из средних диапазонов значений содержат угрозы.

4. Следствие из п. 3: нам не нужно выявлять угрозы для КАЖДОЙ цели в плане проекта, нам нужно их выявлять ТОЛЬКО для тех целей оценка длительности достижения которых выбивается из средних значений.

Однако, пункт 4 верен ТОЛЬКО при выполнении посылки 2.

Возникает вопрос: А что делать с такими целями которые не имеют большого разброса, но разница между оценками стабильно в 2 раза? Если мы будем учитывать их в адаптивном буфере, то буфер проекта будет равен длительности проекта, что что же не хорошо.

С подачи Ивана Абашкина (https://t.me/ivan_abashkin), тут следует задавать вопросы:
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МАЛО времени?
- А почему ты считаешь, что достижение цели МОЖЕТ занять СТОЛЬКО МНОГО времени?

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

#метод #метод_пульса

При найме разработчиков программного обеспечения в ИТ-проектах действует неявное правило:

----------------
Необходимый стаж для достижения уровня "Архитектор по разработке программного обеспечения" обратно пропорционален времени компиляции исходного кода (времени сборки).
----------------

То есть в языках программирования в которых время сборки программы долгое, таких как C++, C#, Java до архитектора дорастают быстрее. по сравнению с теми языками программирования где "результат мгновенный".

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

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

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

#ит #ответы_на_вопросы #разработка_по

Когда есть большой разброс в оценках длительности работ в наукоёмких и сложных проектах, то это повод задавать вопросы. Но какие вопросы нужно задавать? Если задать неправильный вопрос, то получишь неправильный ответ. Но если задать правильный вопрос, то можно и кружкой в голову получить.

О том, какие вопросы задавать читайте в новой статье Ивана Абашкина: https://t.me/ivan_abashkin/39

#метод_пульса #метод

в PMBoK есть термин "Project Charter" который в русский язык перевели как "Устав проекта", однако

"Уста́в — свод правил, регулирующих организацию и порядок деятельности в какой-либо определённой сфере отношений или какого-либо государственного органа, организаций, предприятия, учреждения и так далее." (С) википедия

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

#метод #метод_пульса #pmbok