"Даже слабоумный паренек может стать премьер-министром" (шутка об эстонском Кристене Михале, не имеющая ничего общего с правдой или да), многими воспринимается как свидетельство равенства возможностей. Идиократия - это реальность. Факт. Хорошо, что у нас всё не так и управляют люди, обладающие экспертизой в предметной области, и никогда не поставят руководить госконторой историка-заочника, журналиста-международника, гинеколога или просто "слабоумного паренька", да?
Эти условия среды можно пытаться менять. Но что-то мне подсказывает, что Центры борьбы с фейками в обществе, где основная скрепа - это 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-го года - это не очень эффективно. Возможно, им тоже так казалось? Возможно, поэтому еженедельные митапы во главе с биг-боссом и ежедневная отчетность каждого уборщика разработчика, а не потому, что скрам-тайп-си - это прогрессивно?
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.
Менеджеру нужно знание родного языка? «Правильность» ответа существенным образом зависит от контекста. Чтобы устроиться на работу достаточно надувать щеки на собеседовании и можно обойтись жестами и мычанием. Если же менеджер стремится повышать свою квалификацию, то ему нужно копать глубже. Но преподавание родного языка – отвратительно. Это какое-то самолюбование! Оно дистанцируется от реального мира! Нужно преподавать «конструктивный язык».
Не умоляя ценности вашей статьи, я бы рассматривал ее как претензию на туториал не для проведения совещаний, а для диагностики управления в организации (проекте) по культуре проведения совещаний в ней. Если на совещаниях всех этих шагов нет (независимо от их порядка и сочетаний), то в управлении огромные проблемы. Если же совещания проводятся только в крайних случаях и с целью никогда больше не проводить подобных совещаний, то сами собой рождаются и повестка, по которой быстро составляется протокол, и критическое осмысление состава участников.
Для донесения информации до заинтересованных лиц, для управления ими, не нужно никаких совещаний. Наоборот, существуют такие роли как РП, архитектор, бизнес-аналитик, которые занимаются переводами на языки заинтересованных лиц. Это как раз камень против совещаний, на которых многие говорят на разных языках и не очень пытаются, в отличие от тет-а-тетов, понять друг друга.
В любом диалоге, в любой момент времени говорит кто-то один. Чем больше участников диалога, тем меньше их вовлеченность в этот диалог, а значит и выше число ошибок решений именно на совещаниях. Диалог не параллелится. Поэтому совещания - это наихудшая форма взаимодействия, хуже которой только полное его отсутствие.
"Даже слабоумный паренек может стать премьер-министром" (шутка об эстонском Кристене Михале, не имеющая ничего общего с правдой или да), многими воспринимается как свидетельство равенства возможностей. Идиократия - это реальность. Факт. Хорошо, что у нас всё не так и управляют люди, обладающие экспертизой в предметной области, и никогда не поставят руководить госконторой историка-заочника, журналиста-международника, гинеколога или просто "слабоумного паренька", да?
Эти условия среды можно пытаться менять. Но что-то мне подсказывает, что Центры борьбы с фейками в обществе, где основная скрепа - это 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.
В условиях неопределенности нет ничего, кроме гибкой разработки, но это не цена методологии, а цена неопределенности и цена ошибки в требованиях.
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.
Менеджеру нужно знание родного языка? «Правильность» ответа существенным образом зависит от контекста. Чтобы устроиться на работу достаточно надувать щеки на собеседовании и можно обойтись жестами и мычанием. Если же менеджер стремится повышать свою квалификацию, то ему нужно копать глубже. Но преподавание родного языка – отвратительно. Это какое-то самолюбование! Оно дистанцируется от реального мира! Нужно преподавать «конструктивный язык».
Умаляя. Стыдобища какая.((
Не умоляя ценности вашей статьи, я бы рассматривал ее как претензию на туториал не для проведения совещаний, а для диагностики управления в организации (проекте) по культуре проведения совещаний в ней. Если на совещаниях всех этих шагов нет (независимо от их порядка и сочетаний), то в управлении огромные проблемы. Если же совещания проводятся только в крайних случаях и с целью никогда больше не проводить подобных совещаний, то сами собой рождаются и повестка, по которой быстро составляется протокол, и критическое осмысление состава участников.
Для донесения информации до заинтересованных лиц, для управления ими, не нужно никаких совещаний. Наоборот, существуют такие роли как РП, архитектор, бизнес-аналитик, которые занимаются переводами на языки заинтересованных лиц. Это как раз камень против совещаний, на которых многие говорят на разных языках и не очень пытаются, в отличие от тет-а-тетов, понять друг друга.
В любом диалоге, в любой момент времени говорит кто-то один. Чем больше участников диалога, тем меньше их вовлеченность в этот диалог, а значит и выше число ошибок решений именно на совещаниях. Диалог не параллелится. Поэтому совещания - это наихудшая форма взаимодействия, хуже которой только полное его отсутствие.