bromium, конструктивный разбор - отвечу по существу.
“База, которая не делалась” - согласен и не спорю. Именно это и есть кейс. Если бы база делалась - статьи не было бы. Но такое вижу почти везде, где ИТ прикладное.
По методике.
Оценка аналитиком и архитектором - не трудоёмкость разработчика, а два дополнительных угла: полнота задачи и архитектурные зависимости. Расхождение в оценке = стороны по-разному понимают задачу. Сначала договариваются, потом считают часы. Это снимало переделки.
“Оценочные часы дошли до пользователей” - суммарная оценка задач, закрытых в релиз. Velocity по плановым часам, не по факту потраченного времени.
Три вице-президента “срочно” - ИТ не арбитр. По принятым правилам - комитет. С записью: вот что вытесняет вот что и почему.
300 часов багов - capacity под новое пересчитывается, заказчиков не просто уведомляют о сроках, а фактически согласовывают их с ними. Прозрачность лучше, чем тихий перенос.
По директору разработки - 50 на 50 с “гнать в шею”. Система без правил воспроизводит ровно такое поведение у компетентных людей. Это адаптация к стимулам, не к несуществующим правилам. Персональный вердикт здесь неточный. Да и не все умеют объяснить ситуацию на языке бизнеса.
По CEO - вы правы в основном. Нормальная модель не “защищается” от CEO, а даёт ему прозрачность. В статье сформулировал неточно. Разрушает не исключение само по себе, а ситуация, когда CEO ставит задачу в обход системы и не видит, что вытесняет. Если видит и сознательно выбирает - это приоритет, не поломка.
Формального механизма наказания за провал проекта в большинстве компаний нет - и в этом кейсе не было. Уволить за несбывшийся прогноз эффекта практически никто не готов.
Реальный механизм другой: если ты назвал цифру, подписался под baseline и точкой проверки, а эффект не наступил - следующий твой запрос на ресурс проходит с другим уровнем доверия. Это работает там, где память о прошлых обещаниях сохраняется. Там, где не сохраняется - не работает.
Риск, который вы описываете, реальный, и модель его не закрывает. Она фильтрует один конкретный случай: проекты, за которые вообще никто не готов назвать метрику и владельца. Таких оказалось большинство.
Когда ответственность служит для блокировки чужого и продвижения своего - это уже вопрос к культуре принятия решений, а не к инструменту. Инструмент здесь бессилен.
Про бизнесюниты - модель не требует этого. Она требует одного: у инициативы есть конкретный человек, который назвал эффект и готов за него отвечать. Автономный P&L на каждый отдел - другая история. Здесь речь только о минимальном условии для запроса на ресурс.
Про развитие и инвестиции - согласен, другой класс задач. В статье это разобрано в разделе «Где метод не работает»: там, где эффект нельзя изолировать или решение стратегическое по природе, отдельный ROI не считается. Тогда акционер принимает стоимость осознанно - с открытой ценой, а не с цифрой окупаемости.
Провал обычно начинается не с отрасли, а с переноса старой модели управления в новый контур.
Человек привык защищать стабильность - и начинает душить продукт регламентами. Человек привык гнать гипотезы - и недооценивает compliance, audit trail и стоимость сбоя.
В одной компании эти контуры могут жить рядом: касса, ERP, WMS, лояльность, отчетность, мобильное приложение, CRM, омниканал.
Поэтому сильный вопрос на собеседовании не “вы корпоративный или продуктовый CIO”.
Сильный вопрос: какую бизнес-метрику вы здесь будете защищать - непрерывность операций, compliance, TCO или рост цифрового канала?
Если на все задачи один язык управления - риск высокий.
Акционеры в кейсе приняли вполне рациональные решения, когда увидели цифры: закрыли проекты с отрицательной экономикой, сняли с обсуждения нереалистичный найм. Это не «не отдупляют» - это нормальная реакция на нормально поданные данные.
Руководители отделов тоже не виноваты: система позволяла запускать инициативы без цены, метрики и владельца результата. Они и запускали. Кейс про правила входа, а не про качество людей.
Про карточку - да. Это не методология, а санитарный минимум.
В этом и суть: иногда бизнесу не хватает не сложного PMO, а простой дисциплины. Кто инициатор, какой эффект, какой ресурс, кто владелец результата, когда проверяем.
Про «чаек» я бы сказал мягче: проблема не в отдельных людях, а в системе, где инициатива может попасть в очередь без цены, метрики и владельца эффекта. Такая система сама производит поток хотелок. А затем часто используется для бурной имитации деятельности - создавай 3-5 идей и вкидывай.
Про весь бизнес - да, это был сигнал, что проблема шире ИТ-портфеля. Но статья описывает только то, что было в зоне влияния CIO: портфель, ресурс ИТ и правила входа проектов в работу.
Про Франкенштейна - риск реальный, но не в этом случае.
Четыре проекта описывали один и тот же процесс с одной и той же целью. Разных подходов, разных гипотез и аргументов за каждую реализацию не было. Были четыре запроса об одном, которые никто не видел одновременно.
Выбор одной реализации вместо четырёх параллельных - не компромисс, а нормальное управленческое решение.
Про OpenAI и ROI - это разные классы задач.
Автоматизация складского учёта, интеграция магазинов, замена кассовых систем - операционные изменения с измеримыми входными и выходными параметрами.
Требовать baseline и метрику от задачи «сократить out-of-stock через пересчёт остатков» - не то же самое, что требовать понедельный план роста от стартапа. Смешивать эти два контекста - плохая методология.
Про контроль vs понимание разработки - разграничение верное. Но статья не про то, как ИТ «зарубило» проекты или не умело их делать.
Большинство проектов умерли потому, что у них не было владельца эффекта, baseline, метрики и точки проверки. Проект без владельца эффекта - это не проект, а намерение.
Это не проблема управления разработкой. Это проблема формулировки задачи.
Именно это модель и показывает: при текущем ресурсе очередь на 10+ лет. Значит, вопрос не в том, почему ИТ не делает всё. Вопрос в том, за что бизнес реально готов платить ресурсом, деньгами и вниманием.
Про персональную ответственность - да, большинство проектов умерли именно на этом месте. Но это не баг, а фича. Проект без владельца эффекта - это не проект, а намерение. Те, что выжили, выжили уже с человеком, который отвечал не за «курирование», а за результат. На этапе сдачи разница очень заметна.
Про нелинейные зависимости - справедливое замечание. Если эффект нельзя изолировать, считать инициативы по одной как отдельный ROI действительно нельзя. Тогда это уже не отдельный проект, а пакет / программа / сценарий, и считать нужно эффект связки.
А если не получается ни изолировать эффект, ни собрать понятную связку, остаётся честно признать ограничение модели. Тогда решение принимается экспертно, но уже с осознанной стоимостью для акционера, а не под видом точного ROI.
Several users have recently reported a website pretending to offer an official macOS version of Notepad++: notepad-plus-plus-mac.org
Let me be blunt: This site has absolutely nothing to do with Notepad++. It’s not authorized, not endorsed, and not affiliated with the project in any way.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность
Специализация
Технический директор, Директор по информационным технологиям
bromium, конструктивный разбор - отвечу по существу.
“База, которая не делалась” - согласен и не спорю. Именно это и есть кейс. Если бы база делалась - статьи не было бы. Но такое вижу почти везде, где ИТ прикладное.
По методике.
Оценка аналитиком и архитектором - не трудоёмкость разработчика, а два дополнительных угла: полнота задачи и архитектурные зависимости. Расхождение в оценке = стороны по-разному понимают задачу. Сначала договариваются, потом считают часы. Это снимало переделки.
“Оценочные часы дошли до пользователей” - суммарная оценка задач, закрытых в релиз. Velocity по плановым часам, не по факту потраченного времени.
Три вице-президента “срочно” - ИТ не арбитр. По принятым правилам - комитет. С записью: вот что вытесняет вот что и почему.
300 часов багов - capacity под новое пересчитывается, заказчиков не просто уведомляют о сроках, а фактически согласовывают их с ними. Прозрачность лучше, чем тихий перенос.
По директору разработки - 50 на 50 с “гнать в шею”. Система без правил воспроизводит ровно такое поведение у компетентных людей. Это адаптация к стимулам, не к несуществующим правилам. Персональный вердикт здесь неточный. Да и не все умеют объяснить ситуацию на языке бизнеса.
По CEO - вы правы в основном. Нормальная модель не “защищается” от CEO, а даёт ему прозрачность. В статье сформулировал неточно. Разрушает не исключение само по себе, а ситуация, когда CEO ставит задачу в обход системы и не видит, что вытесняет. Если видит и сознательно выбирает - это приоритет, не поломка.
Здесь ROI по каждой отдельной фиче считать бессмысленно.
Одна задача может почти ничего не дать. Но если весь пакет изменений держит NPS и снижает отток - это уже не очередь мелких хотелок, а программа.
Тогда считать надо не задачу, а программу целиком: бюджет, NPS или retention, владельца и горизонт проверки.
вопрос тут уже - "Мы готовы потратить X, чтобы удерживать NPS выше Y?"
Если да - это отдельная корзина с общим бюджетом и общей метрикой.
Вопрос по делу, и честный ответ неудобный.
Формального механизма наказания за провал проекта в большинстве компаний нет - и в этом кейсе не было. Уволить за несбывшийся прогноз эффекта практически никто не готов.
Реальный механизм другой: если ты назвал цифру, подписался под baseline и точкой проверки, а эффект не наступил - следующий твой запрос на ресурс проходит с другим уровнем доверия. Это работает там, где память о прошлых обещаниях сохраняется. Там, где не сохраняется - не работает.
Риск, который вы описываете, реальный, и модель его не закрывает. Она фильтрует один конкретный случай: проекты, за которые вообще никто не готов назвать метрику и владельца. Таких оказалось большинство.
Когда ответственность служит для блокировки чужого и продвижения своего - это уже вопрос к культуре принятия решений, а не к инструменту. Инструмент здесь бессилен.
Про бизнесюниты - модель не требует этого. Она требует одного: у инициативы есть конкретный человек, который назвал эффект и готов за него отвечать. Автономный P&L на каждый отдел - другая история. Здесь речь только о минимальном условии для запроса на ресурс.
Про развитие и инвестиции - согласен, другой класс задач. В статье это разобрано в разделе «Где метод не работает»: там, где эффект нельзя изолировать или решение стратегическое по природе, отдельный ROI не считается. Тогда акционер принимает стоимость осознанно - с открытой ценой, а не с цифрой окупаемости.
Я бы не сводил это к двум типам CIO.
Провал обычно начинается не с отрасли, а с переноса старой модели управления в новый контур.
Человек привык защищать стабильность - и начинает душить продукт регламентами. Человек привык гнать гипотезы - и недооценивает compliance, audit trail и стоимость сбоя.
В одной компании эти контуры могут жить рядом: касса, ERP, WMS, лояльность, отчетность, мобильное приложение, CRM, омниканал.
Поэтому сильный вопрос на собеседовании не “вы корпоративный или продуктовый CIO”.
Сильный вопрос: какую бизнес-метрику вы здесь будете защищать - непрерывность операций, compliance, TCO или рост цифрового канала?
Если на все задачи один язык управления - риск высокий.
Акционеры в кейсе приняли вполне рациональные решения, когда увидели цифры: закрыли проекты с отрицательной экономикой, сняли с обсуждения нереалистичный найм. Это не «не отдупляют» - это нормальная реакция на нормально поданные данные.
Руководители отделов тоже не виноваты: система позволяла запускать инициативы без цены, метрики и владельца результата. Они и запускали. Кейс про правила входа, а не про качество людей.
Про карточку - да. Это не методология, а санитарный минимум.
В этом и суть: иногда бизнесу не хватает не сложного PMO, а простой дисциплины. Кто инициатор, какой эффект, какой ресурс, кто владелец результата, когда проверяем.
Про «чаек» я бы сказал мягче: проблема не в отдельных людях, а в системе, где инициатива может попасть в очередь без цены, метрики и владельца эффекта. Такая система сама производит поток хотелок. А затем часто используется для бурной имитации деятельности - создавай 3-5 идей и вкидывай.
Про весь бизнес - да, это был сигнал, что проблема шире ИТ-портфеля. Но статья описывает только то, что было в зоне влияния CIO: портфель, ресурс ИТ и правила входа проектов в работу.
Про Франкенштейна - риск реальный, но не в этом случае.
Четыре проекта описывали один и тот же процесс с одной и той же целью. Разных подходов, разных гипотез и аргументов за каждую реализацию не было. Были четыре запроса об одном, которые никто не видел одновременно.
Выбор одной реализации вместо четырёх параллельных - не компромисс, а нормальное управленческое решение.
Про OpenAI и ROI - это разные классы задач.
Автоматизация складского учёта, интеграция магазинов, замена кассовых систем - операционные изменения с измеримыми входными и выходными параметрами.
Требовать baseline и метрику от задачи «сократить out-of-stock через пересчёт остатков» - не то же самое, что требовать понедельный план роста от стартапа. Смешивать эти два контекста - плохая методология.
Про контроль vs понимание разработки - разграничение верное. Но статья не про то, как ИТ «зарубило» проекты или не умело их делать.
Большинство проектов умерли потому, что у них не было владельца эффекта, baseline, метрики и точки проверки. Проект без владельца эффекта - это не проект, а намерение.
Это не проблема управления разработкой. Это проблема формулировки задачи.
Про «ИТ не обязано» - согласен полностью.
Именно это модель и показывает: при текущем ресурсе очередь на 10+ лет. Значит, вопрос не в том, почему ИТ не делает всё. Вопрос в том, за что бизнес реально готов платить ресурсом, деньгами и вниманием.
Про персональную ответственность - да, большинство проектов умерли именно на этом месте. Но это не баг, а фича. Проект без владельца эффекта - это не проект, а намерение. Те, что выжили, выжили уже с человеком, который отвечал не за «курирование», а за результат. На этапе сдачи разница очень заметна.
Про нелинейные зависимости - справедливое замечание. Если эффект нельзя изолировать, считать инициативы по одной как отдельный ROI действительно нельзя. Тогда это уже не отдельный проект, а пакет / программа / сценарий, и считать нужно эффект связки.
А если не получается ни изолировать эффект, ни собрать понятную связку, остаётся честно признать ограничение модели. Тогда решение принимается экспертно, но уже с осознанной стоимостью для акционера, а не под видом точного ROI.
На официальном сайте написали что они не имею отношение к этому сайту https://notepad-plus-plus-mac.org/ (https://notepad-plus-plus.org/news/npp-trademark-infringement/)
Several users have recently reported a website pretending to offer an official macOS version of Notepad++:
notepad-plus-plus-mac.orgLet me be blunt:
This site has absolutely nothing to do with Notepad++. It’s not authorized, not endorsed, and not affiliated with the project in any way.