Действительно открытие, что от степени вовлеченности руководителя в процессы компании зависит ее результат. И про боязнь ошибаться никогда никто не писал и вот опять.
Попробую немного поспорить.
Есть такое понятие в психологии, как "личностный конструкт" - это, если грубо, способность человека оценить ситуацию. У более развитых личностей конструкт более разносторонний, но при этом страдает способность принимать решение. Тут важно, что руководитель не берет на себя вот эту оценку "Что в худшем случае может произойти, если это не сработает?", а делегирует это подчиненному (плохое слово - в этой ситуации происходит смена лидерства, но сейчас не про это). Обязательным условием при этом должно являться наличие в команде руководителя более разносторонних, более компетентных специалистов, чем он сам. Конечно, то, что руководитель не задушил их, а способствовал формированию среды, в которой он, обладая способностью принять решение, окружен не менее, а более компетентными специалистами - это заслуга руководителя. Не побоялся - более компетентный, чем руководитель, специалист по своей природе потом придет с идеей к принимающему решение, потому, что он умный и может отличить такого руководителя от других, как и свои ограничения в способности принять решение. К сожалению, в отличие от руководителя, рассматривающего специалиста как объект управления и играющего в доверие.
Сам спор же в том, что посыл «Все ты можешь» - не верен. Человек живет в обществе и без него он не может ничего. Считать, что это руководитель сам всё смог, рассматривать команду как объект, выделяя себя из нее, не понимая, что руководитель как раз менее субъектен, чем его окружение - очень опасное заблуждение руководителя. Поэтому, по моему мнению, этот успех - случайность, как и большинство успешных успехов. Но такому руководителю - уважение и пожелание процветания.
Правильно было бы включить критическое мышление и работать над ошибками.
С часовыми поясами - явная ошибка работы с таймзонами. Понятно, что в условиях срочного переезда не время исправлять выявленные ошибки и пришлось костылить - вероятно, не было других вариантов. Но как перенесли, накостылили, нужно вынести в бэклог анализ проблемы, доработку и разбор решения проблемы с командой, чтобы впредь корректно работать с таймзонами (ака оформить техдолг). А архитектору сделать зарубку, что команды не умеют пока в таймзоны и их нужно подтянуть (ака скорректировать оценку зрелости). Дело житейское, но работа над ошибками - это прежде всего работа.
В деле с басфактором и Васей Архитектор, при ревью, должен был учитывать существующие возможности компании (которые, вероятно, фиксирует при оценке зрелости) и убедиться, что постановка задачи понятна не только ее автору, вполне исполнима и поддерживаема - он же подключился только на тушение пожара. Нужно сделать вывод и поставить еще один чек-бокс для ревью.
Это коротко про несоблюдение архитектурных фреймворков в компании.
Про ADR - это отдельный холивар. Я считаю, что ADR адресуется разработчикам и аналитикам для дальнейшего развития программы, а не для сопровождения и решения проблем. Я считаю, что не нужно формализовать контекст, как это сделали в конце статьи - и без этого полно фреймворков по ADR. Для сопровождения должно быть описание разработчиком решения в базе знаний (confluence-like) - при решении проблем никто не лезет в исходники в ожидании встретить там ADR, что произошло в вашем случае и будет постоянно случаться. Но проблема не в этом, а в процессе доставки изменений в продакшен. Он дикий и неконтролируемый, если не сказать "неадекватный". Раньше и за меньшее расстреливали через подвешивание.
Правильный путь, направленье не то. Делать вывод, что костыли не только вредны, но и полезны на основании того, что в условиях невыплаченного техдолга с косячным шедулером нет других вариантов, кроме дальнейшего накостыливания и того, что архитектор незнаком со своим фреймворком и аппрувит незнакомые никому, кроме, может быть (но это не точно) Васи, решения (см.TOGAF фазу Е), из-за чего крит висит две недели и надо-таки сделать как надо было сразу – ну так себе.
Оправдывать свои ошибки вместо работы над ними – это путь к деградации.
"Даже слабоумный паренек может стать премьер-министром" (шутка об эстонском Кристене Михале, не имеющая ничего общего с правдой или да), многими воспринимается как свидетельство равенства возможностей. Идиократия - это реальность. Факт. Хорошо, что у нас всё не так и управляют люди, обладающие экспертизой в предметной области, и никогда не поставят руководить госконторой историка-заочника, журналиста-международника, гинеколога или просто "слабоумного паренька", да?
Эти условия среды можно пытаться менять. Но что-то мне подсказывает, что Центры борьбы с фейками в обществе, где основная скрепа - это ROI, носят не совсем просветительский характер и не очень эффективны (если вообще имеют положительный эффект для искоренения идиократии).
Может быть это проблема общественной формации? Может быть в основе лежат экономические отношения, которые нужно изменить, чтобы не было этой проблемы? Да ну, приснится же такое!...
Договоритесь в команде: как только долг выходит за лимит — ставим фичи на паузу, идём чистить.
Не работает. Сегодня всегда все согласны, а завтра - некогда.
Единственный способ - еще на стадии mvp оценить риски этого техдолга (да, ИСО 31000, COSO и пр. в помощь). То есть все сразу должны понимать как должно быть (BDUP. Проектирование на порядок дешевле реализации и исправления) и как делаем сейчас (MVP), в чем разница (ограничения), сколько она стоит (хоть в попугаях), когда (зависимости) и для кого именно - долг он всегда персонален. Если при долге отсутствует конкретный должник, то вас кинули. То есть, да, "выплата" техдолга должна сразу иметь подробный план, а целевое решение запроектировано еще до MVP.
час на тесты сегодня = неделя экономии завтра
CapEx (час на тесты сегодня, до запуска в прод) часто гораздо дороже Opex-a (неделя завтра, во время работы в проде), а "свой" час всегда дороже "чужого". Завтра (сопровождение, развитие) - это уже "чужие" для РП (для "внедряев") время и деньги, даже если это один и тот же человек, не говоря о той же команде. Ценить чужое время - это культура. Культура - это правила (в т.ч. неписанные). Если ваши правила, паттерны и фреймворки не соблюдаются, то вы неправильно оценили степень зрелости команды. Глупо ожидать, что племя попуасов, если их заставить выучить фреймворки и регламенты, построят космическую ракету.
Архитектура - это совокупность объектов. Если задача решается без контекста- без учета окружения, условий, взаимодействий, то в ней просто нет архитектуры и места для роли архитектора с его принципами. А значит, заявление, что учет контекста - это какой-то архитектурный принцип – это тавтология.
Очевидно, что при проектировании архитектуры необходимо придерживаться общих принципов проектирования - KISS и YAGNI. Но не менее важным является BDUF, при котором необходимо отделять основное от второстепенного с разделением на этапы (планированием) и проектировать не только с учетом контекста, но и с определенными заранее границами. Есть еще принцип DRY, по которому, если говорить об архитекторе, не нужно повторять одну и ту же логику в разных местах, а выносить в библиотеки и модули или, еще лучше, в отдельную функцию. Эти принципы куда более специфичны для архитектуры, чем более общие KISS и YAGNI.
Ситуативный подход в управлении - это не когда всегда лидируют условные Лёша с Димой и в зависимости от ситуации присылают в группу разные дикпики мотиваторы, а когда управление берет в свои руки наиболее подходящий к данной ситуации лидер. Это как в цивилизованном обществе - в бане главный банщик, в парикмахерской - цирюльник, и в тех конкретных ситуациях командуют именно они. Это тот подход, когда директор не ходит по вымытому, потому, что в такой ситуации и он может справедливо получить шваброй от уборщицы тёти Клавы, а релиз идет на прод когда кивнул тестировщик, а не РП и не биг-босс. Это как в стае собак - есть сильный вожак, но при переходе дороги вожак сменяется на лидера, более опытного именно в переходе дороги, и все более сильные и свирепые псы принимают пинки от этого более опытного в переходе дороги лидера. Такой подход очень эффективен, но возможен только в команде мотивированных профессионалов с лидерскими качествами и чувством локтя, а не описанных (в статье) бедолаг, дрожащих при каждом повышении ключевой ставки.
Если воспринимать это не как "мои правила", а "как мне удобно кодить", то нормально, но не интересно. Иначе, эти "правила" должны кишеть ифэлсами - если просто так грохать базу, интеграционные тесты и метрики, плодить мелкие релизы, приводящие к релизному спагетти с миллионом мерджей (но "стараться" как-то при этом спрямлять историю - это не мерджить чужие изменения что ли?), то можно от смежных команд получить больно по голове.
Аналогия ошибочная. Тут речь не про капитана, а скорее про морское министерство, которое на паруснике не нужно и даже вредно. Если даже адмирал будет лезть в управление каждым парусником, принимая вздорные решения, то вашему флоту для того, чтобы пойти ко дну и враг будет не нужен.
Давно не читал такой выверенной статьи, полезной для повышения общей культуры разработки. Тема всегда актуальная.
Но есть над чем поспорить )).
Техдолг - это качественное отклонение от целевого решения. Модель этого целевого решения (представление как должно быть, vision) в каком-то приближении есть всегда, при любом подходе - гибком или не очень. C vision всё всегда и начинается.
Поэтому тезис
В сравнении с долгом на уровне кода, архитектурный долг чаще является преднамеренным.
неверен. Преднамеренный техдолг на уровне архитектуры - это уже не техдолг, а стадии реализации проекта. Поэтому, архитектурный долг всегда непреднамеренный - не предусмотрели определенное ограничение или вообще не задумались над архитектурой чего-л. и ее соответствием архитектуре бизнеса, то есть допущена ошибка в модели целевого решения. Именно поэтому архитектурный техдолг необходимо выявить и оценить как можно раньше - он самый дорогой. Именно поэтому качество архитектора, знания и умение его в паттерны и фреймворки - это очень важно для проекта. Этим тезисом вы преуменьшаете свое значение.
В целом ваша статья лично для меня очень полезна. Она позволяет сделать вывод о необходимости определения критериев оценки и учета техдолга с первого дня проекта, ведь очень часто проблема техдолга поднимается в самом конце проекта, когда уже поздно что-то с ним делать. Это всегда приводит к печальным последствиям, неудовлетворенности заказчика и исполнителя друг другом и непредусмотренным затратам с обеих сторон.
Автор совсем запутался. Пишет, что меры безопасности не про безопасность, а потом, что безопасность и не нужна, а нужна какая-то свобода. Нужно искать причину.
Большинству привлекательнее видимость безопасности, а не реальная безопасность - иррациональные ощущения, а не расчет рисков. Идеалисты называют это постмодерном, когда личное мнение важнее, чем исследование и анализ, материалисты - буржуазной демократией, когда всё определяет индивидуальная платежеспособность – кому как нравится. Но пока безопасность – это товар на продажу, видимость безопасности с маркетинговым буллшитом будет продаваться гораздо лучше, чем сама безопасность с исследованиями и анализом, а безопасники будут оцениваться по красивым графикам, а не по рискам. Приспосабливайтесь, господа, или изменяйте среду, товарищи.
Ну, конечно. Использование Archimate вместо "громоздких" UML и BPMN сразу же сделает коммуникации чёткими, а преимущества (перед чем?) TOGAF для всех ясными. Вы серьезно?
В манифесте мотивированная команда профессионалов должна оцениваться по результатам, а не по отчетам. Подразумевается, что ИТ - это авангард, за которым бизнес должен пытаться успеть, стремиться быстрее осваивать новые продукты ИТ и определять стратегию, а не заниматься микроменеджментом ИТ. Эджайл - это про самоорганизацию ИТ, а не про микроменеджмент со стороны боссов. Отчетность и митинги с боссами - это настоящий апокриф эджайл, разрушающий мотивацию команд профессионалов и уничтожающий сверхпродуктивность. Если отчетность и воздействия со стороны бизнеса повышает производительность ИТ относительно взаимного контроля членов команды, которые действительно разбираются в трудоемкости задач, а не мнимо, как боссы, то сверхпроизводительности в ИТ не было и в компании зафейлили гибкую разработку, в чем и расписались. Победила реакция, а не революция в управлении проектами. И да, если анализ заменить орангутаном руководителем, случайно принимающим решения (он не может быть погружен в проблему больше команды), то аналитический паралич невозможен – нет анализа, нет и паралича - нет мотивации проводить анализ, если решение всегда принимается почти наугад. Если есть вот такой RNG-руководитель, принимающий решения в том, в чем не смыслит, то и RnD не нужен - он сам напринимает решений сколько не надо.
RnD могут позволить себе не только лишь все. Даже аналитика становится роскошью. В этом плане статья про будущее скрам полностью корректна - красивая отчетность во главе угла, а что сделают разрабы, так оно и будет, главное - предложить биг-боссу на митапе результаты их жизнедеятельности на выбор в красивой обертке и отчетность о том, что все работают в поте лица параллельно и без перерывов. Правда, это приведет к разрастанию бэк-лога по инцам и увеличению трудозатрат еще в 3 раза (см. график), но это не важно - там или шах или ишак - важно, что отчетность удовлетворила биг-босса. "Будущее скрам" (тайп си) не про эффективность. "Будущее скрам" - про видимость, ой, простите, прозрачность.
И не важно как предпочли бы работать именно вы, важно как предпочитает работать ваш босс и босс вашего босса. Скажет, отчитываться по каждому дню и докладывать еженедельно на митапах - и придется, как доктор Сазерленд, объяснять командам, что именно это прогрессивно и приведет к повышению эффективности, а не эти вот ваши все устаревшие исследования, анализ и манифест.
Забавно читать статью двадцатилетней давности с попыткой оправдания РП для инвесторов куда делись все их венчурные деньги. Мне, почему-то, кажется, что создание системы на пять больниц (три в Бостоне, одна в Балтиморе и одна в Сев. Каролине) за 5 лет и 50мегабаксов 2000-го года - это не очень эффективно. Возможно, им тоже так казалось? Возможно, поэтому еженедельные митапы во главе с биг-боссом и ежедневная отчетность каждого уборщика разработчика, а не потому, что скрам-тайп-си - это прогрессивно?
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.
Действительно открытие, что от степени вовлеченности руководителя в процессы компании зависит ее результат. И про боязнь ошибаться никогда никто не писал и вот опять.
Попробую немного поспорить.
Есть такое понятие в психологии, как "личностный конструкт" - это, если грубо, способность человека оценить ситуацию. У более развитых личностей конструкт более разносторонний, но при этом страдает способность принимать решение. Тут важно, что руководитель не берет на себя вот эту оценку "Что в худшем случае может произойти, если это не сработает?", а делегирует это подчиненному (плохое слово - в этой ситуации происходит смена лидерства, но сейчас не про это). Обязательным условием при этом должно являться наличие в команде руководителя более разносторонних, более компетентных специалистов, чем он сам. Конечно, то, что руководитель не задушил их, а способствовал формированию среды, в которой он, обладая способностью принять решение, окружен не менее, а более компетентными специалистами - это заслуга руководителя. Не побоялся - более компетентный, чем руководитель, специалист по своей природе потом придет с идеей к принимающему решение, потому, что он умный и может отличить такого руководителя от других, как и свои ограничения в способности принять решение. К сожалению, в отличие от руководителя, рассматривающего специалиста как объект управления и играющего в доверие.
Сам спор же в том, что посыл «Все ты можешь» - не верен. Человек живет в обществе и без него он не может ничего. Считать, что это руководитель сам всё смог, рассматривать команду как объект, выделяя себя из нее, не понимая, что руководитель как раз менее субъектен, чем его окружение - очень опасное заблуждение руководителя. Поэтому, по моему мнению, этот успех - случайность, как и большинство успешных успехов. Но такому руководителю - уважение и пожелание процветания.
Правильно было бы включить критическое мышление и работать над ошибками.
С часовыми поясами - явная ошибка работы с таймзонами. Понятно, что в условиях срочного переезда не время исправлять выявленные ошибки и пришлось костылить - вероятно, не было других вариантов. Но как перенесли, накостылили, нужно вынести в бэклог анализ проблемы, доработку и разбор решения проблемы с командой, чтобы впредь корректно работать с таймзонами (ака оформить техдолг). А архитектору сделать зарубку, что команды не умеют пока в таймзоны и их нужно подтянуть (ака скорректировать оценку зрелости). Дело житейское, но работа над ошибками - это прежде всего работа.
В деле с басфактором и Васей Архитектор, при ревью, должен был учитывать существующие возможности компании (которые, вероятно, фиксирует при оценке зрелости) и убедиться, что постановка задачи понятна не только ее автору, вполне исполнима и поддерживаема - он же подключился только на тушение пожара. Нужно сделать вывод и поставить еще один чек-бокс для ревью.
Это коротко про несоблюдение архитектурных фреймворков в компании.
Про ADR - это отдельный холивар. Я считаю, что ADR адресуется разработчикам и аналитикам для дальнейшего развития программы, а не для сопровождения и решения проблем. Я считаю, что не нужно формализовать контекст, как это сделали в конце статьи - и без этого полно фреймворков по ADR. Для сопровождения должно быть описание разработчиком решения в базе знаний (confluence-like) - при решении проблем никто не лезет в исходники в ожидании встретить там ADR, что произошло в вашем случае и будет постоянно случаться. Но проблема не в этом, а в процессе доставки изменений в продакшен. Он дикий и неконтролируемый, если не сказать "неадекватный". Раньше и за меньшее расстреливали через подвешивание.
Правильный путь, направленье не то. Делать вывод, что костыли не только вредны, но и полезны на основании того, что в условиях невыплаченного техдолга с косячным шедулером нет других вариантов, кроме дальнейшего накостыливания и того, что архитектор незнаком со своим фреймворком и аппрувит незнакомые никому, кроме, может быть (но это не точно) Васи, решения (см.TOGAF фазу Е), из-за чего крит висит две недели и надо-таки сделать как надо было сразу – ну так себе.
Оправдывать свои ошибки вместо работы над ними – это путь к деградации.
"Даже слабоумный паренек может стать премьер-министром" (шутка об эстонском Кристене Михале, не имеющая ничего общего с правдой или да), многими воспринимается как свидетельство равенства возможностей. Идиократия - это реальность. Факт. Хорошо, что у нас всё не так и управляют люди, обладающие экспертизой в предметной области, и никогда не поставят руководить госконторой историка-заочника, журналиста-международника, гинеколога или просто "слабоумного паренька", да?
Эти условия среды можно пытаться менять. Но что-то мне подсказывает, что Центры борьбы с фейками в обществе, где основная скрепа - это ROI, носят не совсем просветительский характер и не очень эффективны (если вообще имеют положительный эффект для искоренения идиократии).
Может быть это проблема общественной формации? Может быть в основе лежат экономические отношения, которые нужно изменить, чтобы не было этой проблемы? Да ну, приснится же такое!...
Не работает. Сегодня всегда все согласны, а завтра - некогда.
Единственный способ - еще на стадии mvp оценить риски этого техдолга (да, ИСО 31000, COSO и пр. в помощь). То есть все сразу должны понимать как должно быть (BDUP. Проектирование на порядок дешевле реализации и исправления) и как делаем сейчас (MVP), в чем разница (ограничения), сколько она стоит (хоть в попугаях), когда (зависимости) и для кого именно - долг он всегда персонален. Если при долге отсутствует конкретный должник, то вас кинули. То есть, да, "выплата" техдолга должна сразу иметь подробный план, а целевое решение запроектировано еще до MVP.
CapEx (час на тесты сегодня, до запуска в прод) часто гораздо дороже Opex-a (неделя завтра, во время работы в проде), а "свой" час всегда дороже "чужого". Завтра (сопровождение, развитие) - это уже "чужие" для РП (для "внедряев") время и деньги, даже если это один и тот же человек, не говоря о той же команде. Ценить чужое время - это культура. Культура - это правила (в т.ч. неписанные). Если ваши правила, паттерны и фреймворки не соблюдаются, то вы неправильно оценили степень зрелости команды. Глупо ожидать, что племя попуасов, если их заставить выучить фреймворки и регламенты, построят космическую ракету.
Архитектура - это совокупность объектов. Если задача решается без контекста- без учета окружения, условий, взаимодействий, то в ней просто нет архитектуры и места для роли архитектора с его принципами. А значит, заявление, что учет контекста - это какой-то архитектурный принцип – это тавтология.
Очевидно, что при проектировании архитектуры необходимо придерживаться общих принципов проектирования - KISS и YAGNI. Но не менее важным является BDUF, при котором необходимо отделять основное от второстепенного с разделением на этапы (планированием) и проектировать не только с учетом контекста, но и с определенными заранее границами. Есть еще принцип DRY, по которому, если говорить об архитекторе, не нужно повторять одну и ту же логику в разных местах, а выносить в библиотеки и модули или, еще лучше, в отдельную функцию. Эти принципы куда более специфичны для архитектуры, чем более общие KISS и YAGNI.
Демонстрация того, что в упрощенном, вульгарном, представлении и методологии, и традиции выглядят одинаково.
Ситуативный подход в управлении - это не когда всегда лидируют условные Лёша с Димой и в зависимости от ситуации присылают в группу разные
дикпикимотиваторы, а когда управление берет в свои руки наиболее подходящий к данной ситуации лидер. Это как в цивилизованном обществе - в бане главный банщик, в парикмахерской - цирюльник, и в тех конкретных ситуациях командуют именно они. Это тот подход, когда директор не ходит по вымытому, потому, что в такой ситуации и он может справедливо получить шваброй от уборщицы тёти Клавы, а релиз идет на прод когда кивнул тестировщик, а не РП и не биг-босс. Это как в стае собак - есть сильный вожак, но при переходе дороги вожак сменяется на лидера, более опытного именно в переходе дороги, и все более сильные и свирепые псы принимают пинки от этого более опытного в переходе дороги лидера. Такой подход очень эффективен, но возможен только в команде мотивированных профессионалов с лидерскими качествами и чувством локтя, а не описанных (в статье) бедолаг, дрожащих при каждом повышении ключевой ставки.Если воспринимать это не как "мои правила", а "как мне удобно кодить", то нормально, но не интересно. Иначе, эти "правила" должны кишеть ифэлсами - если просто так грохать базу, интеграционные тесты и метрики, плодить мелкие релизы, приводящие к релизному спагетти с миллионом мерджей (но "стараться" как-то при этом спрямлять историю - это не мерджить чужие изменения что ли?), то можно от смежных команд получить больно по голове.
Не нужОн этот Интернет ваш.
Аналогия ошибочная. Тут речь не про капитана, а скорее про морское министерство, которое на паруснике не нужно и даже вредно. Если даже адмирал будет лезть в управление каждым парусником, принимая вздорные решения, то вашему флоту для того, чтобы пойти ко дну и враг будет не нужен.
Давно не читал такой выверенной статьи, полезной для повышения общей культуры разработки. Тема всегда актуальная.
Но есть над чем поспорить )).
Техдолг - это качественное отклонение от целевого решения. Модель этого целевого решения (представление как должно быть, vision) в каком-то приближении есть всегда, при любом подходе - гибком или не очень. C vision всё всегда и начинается.
Поэтому тезис
неверен. Преднамеренный техдолг на уровне архитектуры - это уже не техдолг, а стадии реализации проекта. Поэтому, архитектурный долг всегда непреднамеренный - не предусмотрели определенное ограничение или вообще не задумались над архитектурой чего-л. и ее соответствием архитектуре бизнеса, то есть допущена ошибка в модели целевого решения. Именно поэтому архитектурный техдолг необходимо выявить и оценить как можно раньше - он самый дорогой. Именно поэтому качество архитектора, знания и умение его в паттерны и фреймворки - это очень важно для проекта. Этим тезисом вы преуменьшаете свое значение.
В целом ваша статья лично для меня очень полезна. Она позволяет сделать вывод о необходимости определения критериев оценки и учета техдолга с первого дня проекта, ведь очень часто проблема техдолга поднимается в самом конце проекта, когда уже поздно что-то с ним делать. Это всегда приводит к печальным последствиям, неудовлетворенности заказчика и исполнителя друг другом и непредусмотренным затратам с обеих сторон.
Спасибо за проделанную работу.
Прячьте в железобетонных руинах. Я всегда так делаю и никто не нашел, даже я сам.
Автор совсем запутался. Пишет, что меры безопасности не про безопасность, а потом, что безопасность и не нужна, а нужна какая-то свобода. Нужно искать причину.
Большинству привлекательнее видимость безопасности, а не реальная безопасность - иррациональные ощущения, а не расчет рисков. Идеалисты называют это постмодерном, когда личное мнение важнее, чем исследование и анализ, материалисты - буржуазной демократией, когда всё определяет индивидуальная платежеспособность – кому как нравится. Но пока безопасность – это товар на продажу, видимость безопасности с маркетинговым буллшитом будет продаваться гораздо лучше, чем сама безопасность с исследованиями и анализом, а безопасники будут оцениваться по красивым графикам, а не по рискам. Приспосабливайтесь, господа, или изменяйте среду, товарищи.
Ну, конечно. Использование Archimate вместо "громоздких" UML и BPMN сразу же сделает коммуникации чёткими, а преимущества (перед чем?) TOGAF для всех ясными. Вы серьезно?
В манифесте мотивированная команда профессионалов должна оцениваться по результатам, а не по отчетам. Подразумевается, что ИТ - это авангард, за которым бизнес должен пытаться успеть, стремиться быстрее осваивать новые продукты ИТ и определять стратегию, а не заниматься микроменеджментом ИТ. Эджайл - это про самоорганизацию ИТ, а не про микроменеджмент со стороны боссов. Отчетность и митинги с боссами - это настоящий апокриф эджайл, разрушающий мотивацию команд профессионалов и уничтожающий сверхпродуктивность. Если отчетность и воздействия со стороны бизнеса повышает производительность ИТ относительно взаимного контроля членов команды, которые действительно разбираются в трудоемкости задач, а не мнимо, как боссы, то сверхпроизводительности в ИТ не было и в компании зафейлили гибкую разработку, в чем и расписались. Победила реакция, а не революция в управлении проектами. И да, если анализ заменить
орангутаномруководителем, случайно принимающим решения (он не может быть погружен в проблему больше команды), то аналитический паралич невозможен – нет анализа, нет и паралича - нет мотивации проводить анализ, если решение всегда принимается почти наугад. Если есть вот такой RNG-руководитель, принимающий решения в том, в чем не смыслит, то и RnD не нужен - он сам напринимает решений сколько не надо.RnD могут позволить себе не только лишь все. Даже аналитика становится роскошью. В этом плане статья про будущее скрам полностью корректна - красивая отчетность во главе угла, а что сделают разрабы, так оно и будет, главное - предложить биг-боссу на митапе результаты их жизнедеятельности на выбор в красивой обертке и отчетность о том, что все работают в поте лица параллельно и без перерывов. Правда, это приведет к разрастанию бэк-лога по инцам и увеличению трудозатрат еще в 3 раза (см. график), но это не важно - там или шах или ишак - важно, что отчетность удовлетворила биг-босса. "Будущее скрам" (тайп си) не про эффективность. "Будущее скрам" - про видимость, ой, простите, прозрачность.
И не важно как предпочли бы работать именно вы, важно как предпочитает работать ваш босс и босс вашего босса. Скажет, отчитываться по каждому дню и докладывать еженедельно на митапах - и придется, как доктор Сазерленд, объяснять командам, что именно это прогрессивно и приведет к повышению эффективности, а не эти вот ваши все устаревшие исследования, анализ и манифест.
Забавно читать статью двадцатилетней давности с попыткой оправдания РП для инвесторов куда делись все их венчурные деньги. Мне, почему-то, кажется, что создание системы на пять больниц (три в Бостоне, одна в Балтиморе и одна в Сев. Каролине) за 5 лет и 50мегабаксов 2000-го года - это не очень эффективно. Возможно, им тоже так казалось? Возможно, поэтому еженедельные митапы во главе с биг-боссом и ежедневная отчетность каждого
уборщикаразработчика, а не потому, что скрам-тайп-си - это прогрессивно?Ниоткуда не следует дороговизна гибкой разработки или ее преимущество в ttm.
В условиях неопределенности нет ничего, кроме гибкой разработки, но это не цена методологии, а цена неопределенности и цена ошибки в требованиях.
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.