Comments 16
с чего вообще ИТ обязано было делать все хотелки кого-то там? даже если этот кто-то - акционер. Их много, ИТ один (ц) собственно что и произошло. А персональная ответственность здесь только гвоздь в крышку гроба конкретного проекта, который ИТ бы и так не сделал, только с кучей беспредметной вони вместо тыканья в конкретного обещанта. Ну и вообще хорошо ещё, что в данной конкретной компании оказалось можно посчитать эффект от каждого проекта отдельно, обычно там непрямые и нелинейные зависимости и иногда с отрицательным эффектом при сложении проектов. Потому что иначе спрашивать не о чем, и вопрос банально не может быть задан, не то что в воздухе повисает - вообще не возникает. И приехали.
Про «ИТ не обязано» - согласен полностью.
Именно это модель и показывает: при текущем ресурсе очередь на 10+ лет. Значит, вопрос не в том, почему ИТ не делает всё. Вопрос в том, за что бизнес реально готов платить ресурсом, деньгами и вниманием.
Про персональную ответственность - да, большинство проектов умерли именно на этом месте. Но это не баг, а фича. Проект без владельца эффекта - это не проект, а намерение. Те, что выжили, выжили уже с человеком, который отвечал не за «курирование», а за результат. На этапе сдачи разница очень заметна.
Про нелинейные зависимости - справедливое замечание. Если эффект нельзя изолировать, считать инициативы по одной как отдельный ROI действительно нельзя. Тогда это уже не отдельный проект, а пакет / программа / сценарий, и считать нужно эффект связки.
А если не получается ни изолировать эффект, ни собрать понятную связку, остаётся честно признать ограничение модели. Тогда решение принимается экспертно, но уже с осознанной стоимостью для акционера, а не под видом точного ROI.
Ох... уж этот взгляд "серьёзных людей" на никчемную айтишную возню... Ох уж это надменное невежество...
нашлись дубли — четыре проекта про один процесс, каждый с другим названием и другим спонсором
Вот, тут, вангую, вчетвером, 1-2 ещё и мог бы запустится, если бы параллельно пошли. Ибо, у заказчиков могут быть целостные понимания. А когда начнут сшивать, пойдёт бесконечная череда согласований и компромиссов, где надо будет согласовать франкенштейна, который не подрывает пуканы никого из 4х (пусть, при этом и решает проблему каждого на 50%).
Это превращало «мы рассчитываем» в конкретное обязательство с проверяемой точкой.
Разумеется. Все великие продукты так были сделаны. Вот, когда OpenAI создавали, то, к примеру, Сэм Альтман лично план роста юзеров до 2031года понедельно расписал, а Маск потом чуть уточнил, - пока в погрешность в 0.5% укладывается.
Ведь, это ж так мотивирует инновации внедрять, когда точно знаешь, как потом за язык притянут
Вообще, есть одна вещь, которая разделяет просто "серьёзных людей" и самых серьёзных людей мира (как FAANG, например).
Первые поведены на контроле. У них принято все ит в 1 департамент централизировать (ибо, надо ж один CIO, с которого спросить можно), проектный офис заводить (ибо кто ж ещё проекты дедуплицирует), руководителей за непопадание в прогноз бюджета наказывать.
Вторые контролировать, нагибать, и мешать с говном тоже умеют. Просто, делают это, понимая, как разработка работает
Про Франкенштейна - риск реальный, но не в этом случае.
Четыре проекта описывали один и тот же процесс с одной и той же целью. Разных подходов, разных гипотез и аргументов за каждую реализацию не было. Были четыре запроса об одном, которые никто не видел одновременно.
Выбор одной реализации вместо четырёх параллельных - не компромисс, а нормальное управленческое решение.
Про OpenAI и ROI - это разные классы задач.
Автоматизация складского учёта, интеграция магазинов, замена кассовых систем - операционные изменения с измеримыми входными и выходными параметрами.
Требовать baseline и метрику от задачи «сократить out-of-stock через пересчёт остатков» - не то же самое, что требовать понедельный план роста от стартапа. Смешивать эти два контекста - плохая методология.
Про контроль vs понимание разработки - разграничение верное. Но статья не про то, как ИТ «зарубило» проекты или не умело их делать.
Большинство проектов умерли потому, что у них не было владельца эффекта, baseline, метрики и точки проверки. Проект без владельца эффекта - это не проект, а намерение.
Это не проблема управления разработкой. Это проблема формулировки задачи.
Ничего, скоро иишечка будет формулировать задачи и нести ответственность. «Иишечка зуб дала, что большая зелёная кнопка повысит пропускную способность склада в 2 раза».
А то, что 70% айтишников заняты операционкой вас не смутило? 3 человека 3 месяца пишут, потом 2 на фуллтайм поддерживают? Удивительные времена.
В мире происходит полный сюр - простая карточка проекта с метриками и рассчётом ресурсов уже считается открытием.
Вы же понимаете, что это всё не «бизнес»-управленцы, а чайки? Ну помогли вы им не потратить на программистов, но если 117 руководителей не задумываются об ответственности, ресурсах и метриках, то сам бизнес помимо АйТи идёт у них с таким же качеством тупизма? И у подрядчиков также и у покупателей.
Про карточку - да. Это не методология, а санитарный минимум.
В этом и суть: иногда бизнесу не хватает не сложного PMO, а простой дисциплины. Кто инициатор, какой эффект, какой ресурс, кто владелец результата, когда проверяем.
Про «чаек» я бы сказал мягче: проблема не в отдельных людях, а в системе, где инициатива может попасть в очередь без цены, метрики и владельца эффекта. Такая система сама производит поток хотелок. А затем часто используется для бурной имитации деятельности - создавай 3-5 идей и вкидывай.
Про весь бизнес - да, это был сигнал, что проблема шире ИТ-портфеля. Но статья описывает только то, что было в зоне влияния CIO: портфель, ресурс ИТ и правила входа проектов в работу.
Очень хорошая статья для саморекламы. Думаю акционеры очень оценили на сколько они ничего не отдупляют в бизнесе и какие снизу ниочемные руководители отделов.
Акционеры в кейсе приняли вполне рациональные решения, когда увидели цифры: закрыли проекты с отрицательной экономикой, сняли с обсуждения нереалистичный найм. Это не «не отдупляют» - это нормальная реакция на нормально поданные данные.
Руководители отделов тоже не виноваты: система позволяла запускать инициативы без цены, метрики и владельца результата. Они и запускали. Кейс про правила входа, а не про качество людей.
По вашему описанию каждый отдел это бизнесюнит. Это точно так должно работать? В статье нет размеров пострадавших, у инициаторов в штате точно прям есть штатный бизнесаналитик. Есть еще такая штука развитие, и еще инвестиции - это не про одно место на кон поставлю.
Про бизнесюниты - модель не требует этого. Она требует одного: у инициативы есть конкретный человек, который назвал эффект и готов за него отвечать. Автономный P&L на каждый отдел - другая история. Здесь речь только о минимальном условии для запроса на ресурс.
Про развитие и инвестиции - согласен, другой класс задач. В статье это разобрано в разделе «Где метод не работает»: там, где эффект нельзя изолировать или решение стратегическое по природе, отдельный ROI не считается. Тогда акционер принимает стоимость осознанно - с открытой ценой, а не с цифрой окупаемости.
«я персонально отвечаю за этот эффект»
ЛПР за него отвечает лично
Что обычно входит в понятие "персональная ответственность" для руководителя? Что произойдет, если проект провалится? Его/ее уволят? Переведут на должность линейного персонала? Кратно понизят зарплату?
Спрашиваю потому что мне приходилось работать в компании, в которой персональная ответственность была средством манипуляции. То есть, если идея или человек не нравились руководителю, то под предлогом "я за это отвечаю" резалась любая инициатива. И наоброт - личные пет-хотелки брались в работу легко и уверенно "под мою ответственность" просто потому что на практике такой руководитель вообще ничем не рисковал.
Вопрос по делу, и честный ответ неудобный.
Формального механизма наказания за провал проекта в большинстве компаний нет - и в этом кейсе не было. Уволить за несбывшийся прогноз эффекта практически никто не готов.
Реальный механизм другой: если ты назвал цифру, подписался под baseline и точкой проверки, а эффект не наступил - следующий твой запрос на ресурс проходит с другим уровнем доверия. Это работает там, где память о прошлых обещаниях сохраняется. Там, где не сохраняется - не работает.
Риск, который вы описываете, реальный, и модель его не закрывает. Она фильтрует один конкретный случай: проекты, за которые вообще никто не готов назвать метрику и владельца. Таких оказалось большинство.
Когда ответственность служит для блокировки чужого и продвижения своего - это уже вопрос к культуре принятия решений, а не к инструменту. Инструмент здесь бессилен.
А как быть с инициативами, повышающими удобство функционала? Это формально влияет на отток, но каждая отдельная инициатива - ничтожно малый вклад, но делать надо потому что от отсутствия этих функций падает NPS. NPS тоже напрямую на выручку не влияет.
Здесь ROI по каждой отдельной фиче считать бессмысленно.
Одна задача может почти ничего не дать. Но если весь пакет изменений держит NPS и снижает отток - это уже не очередь мелких хотелок, а программа.
Тогда считать надо не задачу, а программу целиком: бюджет, NPS или retention, владельца и горизонт проверки.
вопрос тут уже - "Мы готовы потратить X, чтобы удерживать NPS выше Y?"
Если да - это отдельная корзина с общим бюджетом и общей метрикой.
117 ИТ-проектов и один вопрос, который убил большинство из них