Ситуативный подход в управлении - это не когда всегда лидируют условные Лёша с Димой и в зависимости от ситуации присылают в группу разные дикпики мотиваторы, а когда управление берет в свои руки наиболее подходящий к данной ситуации лидер. Это как в цивилизованном обществе - в бане главный банщик, в парикмахерской - цирюльник, и в тех конкретных ситуациях командуют именно они. Это тот подход, когда директор не ходит по вымытому, потому, что в такой ситуации и он может справедливо получить шваброй от уборщицы тёти Клавы, а релиз идет на прод когда кивнул тестировщик, а не РП и не биг-босс. Это как в стае собак - есть сильный вожак, но при переходе дороги вожак сменяется на лидера, более опытного именно в переходе дороги, и все более сильные и свирепые псы принимают пинки от этого более опытного в переходе дороги лидера. Такой подход очень эффективен, но возможен только в команде мотивированных профессионалов с лидерскими качествами и чувством локтя, а не описанных (в статье) бедолаг, дрожащих при каждом повышении ключевой ставки.
Если воспринимать это не как "мои правила", а "как мне удобно кодить", то нормально, но не интересно. Иначе, эти "правила" должны кишеть ифэлсами - если просто так грохать базу, интеграционные тесты и метрики, плодить мелкие релизы, приводящие к релизному спагетти с миллионом мерджей (но "стараться" как-то при этом спрямлять историю - это не мерджить чужие изменения что ли?), то можно от смежных команд получить больно по голове.
Аналогия ошибочная. Тут речь не про капитана, а скорее про морское министерство, которое на паруснике не нужно и даже вредно. Если даже адмирал будет лезть в управление каждым парусником, принимая вздорные решения, то вашему флоту для того, чтобы пойти ко дну и враг будет не нужен.
Давно не читал такой выверенной статьи, полезной для повышения общей культуры разработки. Тема всегда актуальная.
Но есть над чем поспорить )).
Техдолг - это качественное отклонение от целевого решения. Модель этого целевого решения (представление как должно быть, vision) в каком-то приближении есть всегда, при любом подходе - гибком или не очень. C vision всё всегда и начинается.
Поэтому тезис
В сравнении с долгом на уровне кода, архитектурный долг чаще является преднамеренным.
неверен. Преднамеренный техдолг на уровне архитектуры - это уже не техдолг, а стадии реализации проекта. Поэтому, архитектурный долг всегда непреднамеренный - не предусмотрели определенное ограничение или вообще не задумались над архитектурой чего-л. и ее соответствием архитектуре бизнеса, то есть допущена ошибка в модели целевого решения. Именно поэтому архитектурный техдолг необходимо выявить и оценить как можно раньше - он самый дорогой. Именно поэтому качество архитектора, знания и умение его в паттерны и фреймворки - это очень важно для проекта. Этим тезисом вы преуменьшаете свое значение.
В целом ваша статья лично для меня очень полезна. Она позволяет сделать вывод о необходимости определения критериев оценки и учета техдолга с первого дня проекта, ведь очень часто проблема техдолга поднимается в самом конце проекта, когда уже поздно что-то с ним делать. Это всегда приводит к печальным последствиям, неудовлетворенности заказчика и исполнителя друг другом и непредусмотренным затратам с обеих сторон.
Автор совсем запутался. Пишет, что меры безопасности не про безопасность, а потом, что безопасность и не нужна, а нужна какая-то свобода. Нужно искать причину.
Большинству привлекательнее видимость безопасности, а не реальная безопасность - иррациональные ощущения, а не расчет рисков. Идеалисты называют это постмодерном, когда личное мнение важнее, чем исследование и анализ, материалисты - буржуазной демократией, когда всё определяет индивидуальная платежеспособность – кому как нравится. Но пока безопасность – это товар на продажу, видимость безопасности с маркетинговым буллшитом будет продаваться гораздо лучше, чем сама безопасность с исследованиями и анализом, а безопасники будут оцениваться по красивым графикам, а не по рискам. Приспосабливайтесь, господа, или изменяйте среду, товарищи.
Ну, конечно. Использование Archimate вместо "громоздких" UML и BPMN сразу же сделает коммуникации чёткими, а преимущества (перед чем?) TOGAF для всех ясными. Вы серьезно?
В манифесте мотивированная команда профессионалов должна оцениваться по результатам, а не по отчетам. Подразумевается, что ИТ - это авангард, за которым бизнес должен пытаться успеть, стремиться быстрее осваивать новые продукты ИТ и определять стратегию, а не заниматься микроменеджментом ИТ. Эджайл - это про самоорганизацию ИТ, а не про микроменеджмент со стороны боссов. Отчетность и митинги с боссами - это настоящий апокриф эджайл, разрушающий мотивацию команд профессионалов и уничтожающий сверхпродуктивность. Если отчетность и воздействия со стороны бизнеса повышает производительность ИТ относительно взаимного контроля членов команды, которые действительно разбираются в трудоемкости задач, а не мнимо, как боссы, то сверхпроизводительности в ИТ не было и в компании зафейлили гибкую разработку, в чем и расписались. Победила реакция, а не революция в управлении проектами. И да, если анализ заменить орангутаном руководителем, случайно принимающим решения (он не может быть погружен в проблему больше команды), то аналитический паралич невозможен – нет анализа, нет и паралича - нет мотивации проводить анализ, если решение всегда принимается почти наугад. Если есть вот такой RNG-руководитель, принимающий решения в том, в чем не смыслит, то и RnD не нужен - он сам напринимает решений сколько не надо.
RnD могут позволить себе не только лишь все. Даже аналитика становится роскошью. В этом плане статья про будущее скрам полностью корректна - красивая отчетность во главе угла, а что сделают разрабы, так оно и будет, главное - предложить биг-боссу на митапе результаты их жизнедеятельности на выбор в красивой обертке и отчетность о том, что все работают в поте лица параллельно и без перерывов. Правда, это приведет к разрастанию бэк-лога по инцам и увеличению трудозатрат еще в 3 раза (см. график), но это не важно - там или шах или ишак - важно, что отчетность удовлетворила биг-босса. "Будущее скрам" (тайп си) не про эффективность. "Будущее скрам" - про видимость, ой, простите, прозрачность.
И не важно как предпочли бы работать именно вы, важно как предпочитает работать ваш босс и босс вашего босса. Скажет, отчитываться по каждому дню и докладывать еженедельно на митапах - и придется, как доктор Сазерленд, объяснять командам, что именно это прогрессивно и приведет к повышению эффективности, а не эти вот ваши все устаревшие исследования, анализ и манифест.
Забавно читать статью двадцатилетней давности с попыткой оправдания РП для инвесторов куда делись все их венчурные деньги. Мне, почему-то, кажется, что создание системы на пять больниц (три в Бостоне, одна в Балтиморе и одна в Сев. Каролине) за 5 лет и 50мегабаксов 2000-го года - это не очень эффективно. Возможно, им тоже так казалось? Возможно, поэтому еженедельные митапы во главе с биг-боссом и ежедневная отчетность каждого уборщика разработчика, а не потому, что скрам-тайп-си - это прогрессивно?
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.
Менеджеру нужно знание родного языка? «Правильность» ответа существенным образом зависит от контекста. Чтобы устроиться на работу достаточно надувать щеки на собеседовании и можно обойтись жестами и мычанием. Если же менеджер стремится повышать свою квалификацию, то ему нужно копать глубже. Но преподавание родного языка – отвратительно. Это какое-то самолюбование! Оно дистанцируется от реального мира! Нужно преподавать «конструктивный язык».
Не умоляя ценности вашей статьи, я бы рассматривал ее как претензию на туториал не для проведения совещаний, а для диагностики управления в организации (проекте) по культуре проведения совещаний в ней. Если на совещаниях всех этих шагов нет (независимо от их порядка и сочетаний), то в управлении огромные проблемы. Если же совещания проводятся только в крайних случаях и с целью никогда больше не проводить подобных совещаний, то сами собой рождаются и повестка, по которой быстро составляется протокол, и критическое осмысление состава участников.
Для донесения информации до заинтересованных лиц, для управления ими, не нужно никаких совещаний. Наоборот, существуют такие роли как РП, архитектор, бизнес-аналитик, которые занимаются переводами на языки заинтересованных лиц. Это как раз камень против совещаний, на которых многие говорят на разных языках и не очень пытаются, в отличие от тет-а-тетов, понять друг друга.
В любом диалоге, в любой момент времени говорит кто-то один. Чем больше участников диалога, тем меньше их вовлеченность в этот диалог, а значит и выше число ошибок решений именно на совещаниях. Диалог не параллелится. Поэтому совещания - это наихудшая форма взаимодействия, хуже которой только полное его отсутствие.
Почему же совещание самый не продуктивный способ решения?
Совещание – это один говорит, а остальные слушают. Чем больше участников, тем менее продуктивное совещание - больше совокупная потеря времени и информации (отсутствуют ack-и), что бы вы не предпринимали. Сложно придумать еще менее продуктивный способ решения проблем, чем совещание. Самое эффективное взаимодействие – это точка-точка и в фулл-дуплексе (одновременно, адресно и письменно). Частые и широкие совещания - это свидетельство полного отсутствия управления, непонимания зон ответственности и причина для инвестора обязательно принять решение относительно руководителей, своеобразный cheсk engine - нужно выяснить и устранить причину, пока организация не "отъездилась".
Основная проблема не в том, что совещания назначаются бездумно и на кого попало (это не проблема - это следствие), а в том, что бездумно назначаются именно совещания вместо выстраивания процесса работы, его мониторинга и конкретных своевременных управляющих воздействий.
До сих пор профессора психо-жульнических наук не понимают, что такое нуль, но думают, что понимают. Например, многие считают, что существует нулевой час, нулевой год новой эры, при десятеричном счете ошибочно считают до 10, а не до 9, учитывая нуль (пальцев же десять! нет же нулевого пальца!) и т.д.
Нуль - такой же особенный, как остальные абстрактные математические понятия, невыражаемые на пальцах и бананах (в рациональных величинах), а потому недоступные для понимания профессорами нейро-психо-чтототамии. Не говорите им про комплексные числа и про бесконечность иррациональных величин.
Забавно как цели и проблемы формулируются после обоснования самого непродуктивного способа их решения - совещания. К сожалению, теперь это уже обычная проблема целеполагания. Вероятно, и повестка дается без контекста, непосредственно перед совещанием, чтобы никто не подготовился к встрече, и протокол высылается через несколько дней, чтобы никто ничего уже не вспомнил. Главное - назначить ответственного за решение всех проблем, да?
Демонстрация того, что в упрощенном, вульгарном, представлении и методологии, и традиции выглядят одинаково.
Ситуативный подход в управлении - это не когда всегда лидируют условные Лёша с Димой и в зависимости от ситуации присылают в группу разные
дикпикимотиваторы, а когда управление берет в свои руки наиболее подходящий к данной ситуации лидер. Это как в цивилизованном обществе - в бане главный банщик, в парикмахерской - цирюльник, и в тех конкретных ситуациях командуют именно они. Это тот подход, когда директор не ходит по вымытому, потому, что в такой ситуации и он может справедливо получить шваброй от уборщицы тёти Клавы, а релиз идет на прод когда кивнул тестировщик, а не РП и не биг-босс. Это как в стае собак - есть сильный вожак, но при переходе дороги вожак сменяется на лидера, более опытного именно в переходе дороги, и все более сильные и свирепые псы принимают пинки от этого более опытного в переходе дороги лидера. Такой подход очень эффективен, но возможен только в команде мотивированных профессионалов с лидерскими качествами и чувством локтя, а не описанных (в статье) бедолаг, дрожащих при каждом повышении ключевой ставки.Если воспринимать это не как "мои правила", а "как мне удобно кодить", то нормально, но не интересно. Иначе, эти "правила" должны кишеть ифэлсами - если просто так грохать базу, интеграционные тесты и метрики, плодить мелкие релизы, приводящие к релизному спагетти с миллионом мерджей (но "стараться" как-то при этом спрямлять историю - это не мерджить чужие изменения что ли?), то можно от смежных команд получить больно по голове.
Не нужОн этот Интернет ваш.
Аналогия ошибочная. Тут речь не про капитана, а скорее про морское министерство, которое на паруснике не нужно и даже вредно. Если даже адмирал будет лезть в управление каждым парусником, принимая вздорные решения, то вашему флоту для того, чтобы пойти ко дну и враг будет не нужен.
Давно не читал такой выверенной статьи, полезной для повышения общей культуры разработки. Тема всегда актуальная.
Но есть над чем поспорить )).
Техдолг - это качественное отклонение от целевого решения. Модель этого целевого решения (представление как должно быть, vision) в каком-то приближении есть всегда, при любом подходе - гибком или не очень. C vision всё всегда и начинается.
Поэтому тезис
неверен. Преднамеренный техдолг на уровне архитектуры - это уже не техдолг, а стадии реализации проекта. Поэтому, архитектурный долг всегда непреднамеренный - не предусмотрели определенное ограничение или вообще не задумались над архитектурой чего-л. и ее соответствием архитектуре бизнеса, то есть допущена ошибка в модели целевого решения. Именно поэтому архитектурный техдолг необходимо выявить и оценить как можно раньше - он самый дорогой. Именно поэтому качество архитектора, знания и умение его в паттерны и фреймворки - это очень важно для проекта. Этим тезисом вы преуменьшаете свое значение.
В целом ваша статья лично для меня очень полезна. Она позволяет сделать вывод о необходимости определения критериев оценки и учета техдолга с первого дня проекта, ведь очень часто проблема техдолга поднимается в самом конце проекта, когда уже поздно что-то с ним делать. Это всегда приводит к печальным последствиям, неудовлетворенности заказчика и исполнителя друг другом и непредусмотренным затратам с обеих сторон.
Спасибо за проделанную работу.
Прячьте в железобетонных руинах. Я всегда так делаю и никто не нашел, даже я сам.
Автор совсем запутался. Пишет, что меры безопасности не про безопасность, а потом, что безопасность и не нужна, а нужна какая-то свобода. Нужно искать причину.
Большинству привлекательнее видимость безопасности, а не реальная безопасность - иррациональные ощущения, а не расчет рисков. Идеалисты называют это постмодерном, когда личное мнение важнее, чем исследование и анализ, материалисты - буржуазной демократией, когда всё определяет индивидуальная платежеспособность – кому как нравится. Но пока безопасность – это товар на продажу, видимость безопасности с маркетинговым буллшитом будет продаваться гораздо лучше, чем сама безопасность с исследованиями и анализом, а безопасники будут оцениваться по красивым графикам, а не по рискам. Приспосабливайтесь, господа, или изменяйте среду, товарищи.
Ну, конечно. Использование Archimate вместо "громоздких" UML и BPMN сразу же сделает коммуникации чёткими, а преимущества (перед чем?) TOGAF для всех ясными. Вы серьезно?
В манифесте мотивированная команда профессионалов должна оцениваться по результатам, а не по отчетам. Подразумевается, что ИТ - это авангард, за которым бизнес должен пытаться успеть, стремиться быстрее осваивать новые продукты ИТ и определять стратегию, а не заниматься микроменеджментом ИТ. Эджайл - это про самоорганизацию ИТ, а не про микроменеджмент со стороны боссов. Отчетность и митинги с боссами - это настоящий апокриф эджайл, разрушающий мотивацию команд профессионалов и уничтожающий сверхпродуктивность. Если отчетность и воздействия со стороны бизнеса повышает производительность ИТ относительно взаимного контроля членов команды, которые действительно разбираются в трудоемкости задач, а не мнимо, как боссы, то сверхпроизводительности в ИТ не было и в компании зафейлили гибкую разработку, в чем и расписались. Победила реакция, а не революция в управлении проектами. И да, если анализ заменить
орангутаномруководителем, случайно принимающим решения (он не может быть погружен в проблему больше команды), то аналитический паралич невозможен – нет анализа, нет и паралича - нет мотивации проводить анализ, если решение всегда принимается почти наугад. Если есть вот такой RNG-руководитель, принимающий решения в том, в чем не смыслит, то и RnD не нужен - он сам напринимает решений сколько не надо.RnD могут позволить себе не только лишь все. Даже аналитика становится роскошью. В этом плане статья про будущее скрам полностью корректна - красивая отчетность во главе угла, а что сделают разрабы, так оно и будет, главное - предложить биг-боссу на митапе результаты их жизнедеятельности на выбор в красивой обертке и отчетность о том, что все работают в поте лица параллельно и без перерывов. Правда, это приведет к разрастанию бэк-лога по инцам и увеличению трудозатрат еще в 3 раза (см. график), но это не важно - там или шах или ишак - важно, что отчетность удовлетворила биг-босса. "Будущее скрам" (тайп си) не про эффективность. "Будущее скрам" - про видимость, ой, простите, прозрачность.
И не важно как предпочли бы работать именно вы, важно как предпочитает работать ваш босс и босс вашего босса. Скажет, отчитываться по каждому дню и докладывать еженедельно на митапах - и придется, как доктор Сазерленд, объяснять командам, что именно это прогрессивно и приведет к повышению эффективности, а не эти вот ваши все устаревшие исследования, анализ и манифест.
Забавно читать статью двадцатилетней давности с попыткой оправдания РП для инвесторов куда делись все их венчурные деньги. Мне, почему-то, кажется, что создание системы на пять больниц (три в Бостоне, одна в Балтиморе и одна в Сев. Каролине) за 5 лет и 50мегабаксов 2000-го года - это не очень эффективно. Возможно, им тоже так казалось? Возможно, поэтому еженедельные митапы во главе с биг-боссом и ежедневная отчетность каждого
уборщикаразработчика, а не потому, что скрам-тайп-си - это прогрессивно?Ниоткуда не следует дороговизна гибкой разработки или ее преимущество в ttm.
В условиях неопределенности нет ничего, кроме гибкой разработки, но это не цена методологии, а цена неопределенности и цена ошибки в требованиях.
Это комментарий как раз про оценку скиллов РП по его умению оценки "бюджета/качества/сроков", а не про саму оценку. Про "раскрытие" темы в статье - другая часть комментария.
Менеджеру нужно знание родного языка? «Правильность» ответа существенным образом зависит от контекста. Чтобы устроиться на работу достаточно надувать щеки на собеседовании и можно обойтись жестами и мычанием. Если же менеджер стремится повышать свою квалификацию, то ему нужно копать глубже. Но преподавание родного языка – отвратительно. Это какое-то самолюбование! Оно дистанцируется от реального мира! Нужно преподавать «конструктивный язык».
Умаляя. Стыдобища какая.((
Не умоляя ценности вашей статьи, я бы рассматривал ее как претензию на туториал не для проведения совещаний, а для диагностики управления в организации (проекте) по культуре проведения совещаний в ней. Если на совещаниях всех этих шагов нет (независимо от их порядка и сочетаний), то в управлении огромные проблемы. Если же совещания проводятся только в крайних случаях и с целью никогда больше не проводить подобных совещаний, то сами собой рождаются и повестка, по которой быстро составляется протокол, и критическое осмысление состава участников.
Для донесения информации до заинтересованных лиц, для управления ими, не нужно никаких совещаний. Наоборот, существуют такие роли как РП, архитектор, бизнес-аналитик, которые занимаются переводами на языки заинтересованных лиц. Это как раз камень против совещаний, на которых многие говорят на разных языках и не очень пытаются, в отличие от тет-а-тетов, понять друг друга.
В любом диалоге, в любой момент времени говорит кто-то один. Чем больше участников диалога, тем меньше их вовлеченность в этот диалог, а значит и выше число ошибок решений именно на совещаниях. Диалог не параллелится. Поэтому совещания - это наихудшая форма взаимодействия, хуже которой только полное его отсутствие.
Совещание – это один говорит, а остальные слушают. Чем больше участников, тем менее продуктивное совещание - больше совокупная потеря времени и информации (отсутствуют ack-и), что бы вы не предпринимали. Сложно придумать еще менее продуктивный способ решения проблем, чем совещание. Самое эффективное взаимодействие – это точка-точка и в фулл-дуплексе (одновременно, адресно и письменно). Частые и широкие совещания - это свидетельство полного отсутствия управления, непонимания зон ответственности и причина для инвестора обязательно принять решение относительно руководителей, своеобразный cheсk engine - нужно выяснить и устранить причину, пока организация не "отъездилась".
Основная проблема не в том, что совещания назначаются бездумно и на кого попало (это не проблема - это следствие), а в том, что бездумно назначаются именно совещания вместо выстраивания процесса работы, его мониторинга и конкретных своевременных управляющих воздействий.
До сих пор профессора психо-жульнических наук не понимают, что такое нуль, но думают, что понимают. Например, многие считают, что существует нулевой час, нулевой год новой эры, при десятеричном счете ошибочно считают до 10, а не до 9, учитывая нуль (пальцев же десять! нет же нулевого пальца!) и т.д.
Нуль - такой же особенный, как остальные абстрактные математические понятия, невыражаемые на пальцах и бананах (в рациональных величинах), а потому недоступные для понимания профессорами нейро-психо-чтототамии. Не говорите им про комплексные числа и про бесконечность иррациональных величин.
Забавно как цели и проблемы формулируются после обоснования самого непродуктивного способа их решения - совещания. К сожалению, теперь это уже обычная проблема целеполагания. Вероятно, и повестка дается без контекста, непосредственно перед совещанием, чтобы никто не подготовился к встрече, и протокол высылается через несколько дней, чтобы никто ничего уже не вспомнил. Главное - назначить ответственного за решение всех проблем, да?