Что тут скажешь? Если хотите понять, стОит ли откладывать самому на пенсию, просто спросите у своих бабушек и дедушек, сколько они сейчас получают от государства?
Так это не отвечает на вопрос "Сколько денег?". Сколько разрабов убежит? Сколько согласится ехать дальше на дохлой лошади за повышение зарплаты? А сколько человеко-часов (и считай денег) мы сэкономим в короткой перспективе за счёт того, что НЕ будем что-то переписывать?
Тут довольно много переменных. И оценить их "точно, в граммах" сложно. Можно использовать примерный и сравнительные оценки. Но сумма многих допущений даёт не точную оценку, а одно огромное допущение с ошеломляющей разницей значений.
Я бы предложил техдолг оценить не только деньгами, но и нематериально. Как корпоративную культуру, что ли.
Как мне кажется, сравнительно стабильной характеристикой техдолга является обмен отложенных проблем на быструю выгоду. С т.з. бизнеса, т.е. денег, нужно понимать, что мы быстрее получим деньги сейчас, но потом нужно будет часть этих денег потратить на закрытие техдолга. И тут мы видим, в каком случае техдолг имеет право на жизнь: когда бизнес сейчас заработает заметно больше денег, чем мы потом потратим на закрытие техдолга.
Выполнение этого условия работает по-разному в разных компаниях. Скромная контора в начале своего пути может нести затраты на разработку, сопоставимые с выручкой. Компания-гигант может иметь огромную выручку, но исправление легаси может стать для неё не просто сложной, а нерешаемой разумными средствами задачей. Но может быть и более общий и кмк частый случай, когда всё действительно складывается удачно: мы сейчас выкатим вот это вот чудо, а потом наведём порядки.
Я выступаю за то, чтобы техдолг лежал в одном бэклоге с бизнес-задачами. Грамотно оценивался, приоритезировался и регулярно брался в работу. Техдолгом нужно управлять и эта ответственность должна лежать на плечах архитектора/техлида и владельца продукта.
Я извиняюсь, а как вы переведёте в деньги техдолг "Перейти на актуальную технологию"? Не как-то пальцем в небо, а data driven, так сказать. Это сравнительно легко сделать, когда закрытие техдолга решает какие-то конкретные оцененные задачи. Чем абстрактнее техдолг, тем сложнее выразить его значимость в денежках.
А ведь после закрытия техдолга могут ещё и попросить сверить эффект с предварительной оценкой. И как быть тогда?
Печаль в том, что казалось бы самый оптимальный вариант - гибрид - на деле самый малоэффективный. Когда ты то общаешься вживую, то онлайн, это разрывает пространство коммуникации. Самые неудачные митинги, когда кто-то собирается в переговорке, а кто-то подключается по видео. И при этом кто как участвует меняется от встрече к встрече.
На самом деле, могут быть нюансы. Точнее даже они бывают достаточно часто. По своим коллегам, которые вернулись в офис, могу сказать, то в целом даже на онлайн митингах они более собранные. У них слышно меньше шума, они реже отвлекаются.
Не такой уж и частный слушай. На начало пандемии я работал в международной компании и наш проект был размазан на три страны и, навскидку, шесть разных городов. Затем я работал в крупной компании с распределённой сетью офисов в пределах одной страны. Сейчас я снова в "крупной международной". Как-то очень часто для частного)
В любых процессах важно не перемудрить, не закрутить эти самые гайки до скрипа. И уж тем более это важно в коммуникации, т.к. это софт скилл и прежде всего про людей. Одно дело, когда кто-то "приносит" тебе шаблоны хард скиллов, например, по написанию кода, другое дело, когда кто-то начинает учить тебя общаться. "Я что, не умею ОБЩАТЬСЯ? Да я всю жизнь общаюсь!" - это частая реакция)
Из полезных советов я докину два момента. Первый касается собственно агентов изменений, будь то один человек или команда. Начинать надо с себя. Простая истина, но стОящая упоминания. Предлагаешь всем писать фоллоу-апы? Начни это делать первым, может даже ещё до внедрения во всей компании. Топишь за шаблоны? Составь их для своей команды и показывай своим как реальный образец, а не что-то из книжек. Ты не будешь выглядеть как сапожник без сапог.
Второй момент касается того, что как правило к моменту начала внедрения изменений есть некий накопленный негатив. Часто он мешает изменениям, хотя направлен не против них - это всё против текущих порядков. Именно поэтому полезно описывать состояние AS IS. А ещё полезно провести некую разрядку. Будь то толковая ретроспектива или тимбилдинг.
Проблема с утверждением про вечный успех связана с тем, что это попытка выдать самому себе индульгенцию. Что бы ты не делал - ты молодец. Если компании нужно отправить спутник на орбиту и ты просто скинул с крышы офиса миксер - окей, ты выяснил, что миксеры не летают. Успех? Успех.
Исследование должно создавать ценность, которая неким значимым образом приближает компанию к решению бизнес-задач. В примере с миксером реальная польза максимально близка к нулю.
И это нас приводит ещё к одной интересной мысли. У исследования есть заказчик? Кто-то извне команды исследования. Если так, то получается это он решает, успешно завершилось исследование или нет. Заказчик решает, а не сама команда.
С тем, что исследование всегда успешное, я не соглашусь. Сам автор выше говорит, что исследование должно быть направлено на решение какой-либо бизнес-задачи. Если исследование не закончилось успехом, например, решено такую-то технологию/инструмент не внедрять, то разве бизнес-задача решена? Не-а. Отмести один из N вариантов - это не решение.
Я бы в целом чуть отодвинул R&D от решения конкретных задач. Как по мне, такие проекты существуют на более концептуальном уровне.
Каким образом частное облако обыграло публичное по скорости предоставления ресурсов утилизации?
Алсо, есть некоторые манипуляции. Тот факт, что предоставление ресурсов с т.з. согласований и закупок занимало времени - это прежде всего проблема процессов. Процессов запросов и согласований, процессов планирования.
Инфраструктура нуждается в защите от атак в любом случае, облачная она или онпрем. Если защита в облаке настроена правильно, почку за ресурсы продавать не придётся. А если этого не делать, то да, возможно эта неосмотрительность дорого обойдётся.
Как-то очень сладко получилось. Затрат меньше, хлопот меньше, людей меньше. Риски? За них тоже не переживайте.
Про то, что парой сделанных или несделанных кликов в облаке можно грохнуть годовой бюджет за месяц/неделю, думаю в 2023 году уже никому не надо рассказывать.
По поводу рисков/ответственности - надо понимать, что все облачные тулы по логированию, инспектированию, фильтрации тоже стоят денег.
Принципиальное отличие облака от онпрема заключается в скорости изменений и... территориальной доступности. Поставить сервачок в уютненькой серверной и показать фигу облакам - это сработает при сравнительно локализованном бизнесе. Когда вы глобальная корпорация с кучерявыми сервисами, а не просто страничной на Тильде, без облака обеспечить достойную скорость работы будет трудно.
Хотелось бы услышать какие-то более сложные примеры, чем "посмотрел статистику, сравнил цифры". Кмк финопс может иметь функции подбора тарифов, проектирования автоматизаций, чтобы они не съели ваще все деньги мира при первом же автоматическом масштабировании.
Купит ли заказчик внедрение личного кабинета у этой компании будет во многом зависеть от того, как он оценит те изменения, которые ему предложили внести на сайте сперва. Почему во многом? Разве может быть вариант, когда трансформация прошла успешно, но дальше решили не двигаться? Да, может.
Нужно фокусироваться на ценности. Если не уходить в совсем высокие материи, то заказчика интересует улучшение взаимодействия посетителей с клиникой. Кабинет - это одна из фичей на пути к этому, не более. Команда путём исследования индентифицировала другие фичи с более высоким приоритетом. Заказчик согласился, фичи ушли в работу.
Всё стоит денег и эффект внедрения фичи должен иметь и денежную метрику. Сколько новых клиентов привлечём, столько старых удержим, насколько увеличим средний чек? Может быть так, что клиентам УЖЕ стало гораздо удобнее пользоваться сайтом. И дальнейшая финансовая выгода от личного кабинета будет минимальной. Зачем тогда тратить бабки на разработку плюс закладывать бОльшие бабки на поддержку? Может и не надо.
Поэтому продать личный кабинет на самом-то деле может быть ещё сложнее, чем переубедить заказчика и сделать сперва навигацию.
Детские крики на созвонах - кошмар. Да и любые другие посторонние шумы вроде собак, ремонта, машин. Сложно поверить, что работающий в таких условиях человек концентрируется на работе и эффективен.
Про пальмы, море и другую красоту - это скорее зависить, надо признать. Когда ты сидишь дождливым осенним утром в квартирке где-то на окраине города N, а кто-то на солнечном пляже... Но, положа руку на сердце, море за спиной - вполне рабочая обстановка. Надо учиться радоваться за коллег)
Могу поделиться своей историей. После удалёнки был гибрид, сейчас целиком работаю из офиса. И больше всего меня раздражают... Онлайн-митинги. Потому что разве не ради живого взаимодействия нас возвращали в офис?
Чем крупнее компания, тем больше уровней иерархии. Если кто-то может привести пример компании крупнее 3к работников со всего парой уровней по вертикали - было бы интересно узнать. И разделение как раз происходит на уровне права принимать решение.
Кмк, в статье несколько идеализируется возможность инжерена в "компании в стиле КД" принимать серьёзные решение. Пожалуй, в более реалистичном сценарии инженер может дать обратную связь или предложение - и это послание будет эффективно услышано и рассмотрено.
>>Инструменты ITSM дают возможность быстро и эффективно телепортироваться из одного организационного состояния в другое.
М-да. Реклама курсов из разряда финансовых пирамид. Ни один человек, который оть немного сталкивался с трансформацией процессов и внедрением сервисного подхода, не поверить вот в эту сказу про "быструю телепортацию".
Что тут скажешь? Если хотите понять, стОит ли откладывать самому на пенсию, просто спросите у своих бабушек и дедушек, сколько они сейчас получают от государства?
Так это не отвечает на вопрос "Сколько денег?". Сколько разрабов убежит? Сколько согласится ехать дальше на дохлой лошади за повышение зарплаты? А сколько человеко-часов (и считай денег) мы сэкономим в короткой перспективе за счёт того, что НЕ будем что-то переписывать?
Тут довольно много переменных. И оценить их "точно, в граммах" сложно. Можно использовать примерный и сравнительные оценки. Но сумма многих допущений даёт не точную оценку, а одно огромное допущение с ошеломляющей разницей значений.
Я бы предложил техдолг оценить не только деньгами, но и нематериально. Как корпоративную культуру, что ли.
Как мне кажется, сравнительно стабильной характеристикой техдолга является обмен отложенных проблем на быструю выгоду. С т.з. бизнеса, т.е. денег, нужно понимать, что мы быстрее получим деньги сейчас, но потом нужно будет часть этих денег потратить на закрытие техдолга. И тут мы видим, в каком случае техдолг имеет право на жизнь: когда бизнес сейчас заработает заметно больше денег, чем мы потом потратим на закрытие техдолга.
Выполнение этого условия работает по-разному в разных компаниях. Скромная контора в начале своего пути может нести затраты на разработку, сопоставимые с выручкой. Компания-гигант может иметь огромную выручку, но исправление легаси может стать для неё не просто сложной, а нерешаемой разумными средствами задачей. Но может быть и более общий и кмк частый случай, когда всё действительно складывается удачно: мы сейчас выкатим вот это вот чудо, а потом наведём порядки.
Я выступаю за то, чтобы техдолг лежал в одном бэклоге с бизнес-задачами. Грамотно оценивался, приоритезировался и регулярно брался в работу. Техдолгом нужно управлять и эта ответственность должна лежать на плечах архитектора/техлида и владельца продукта.
Я извиняюсь, а как вы переведёте в деньги техдолг "Перейти на актуальную технологию"? Не как-то пальцем в небо, а data driven, так сказать. Это сравнительно легко сделать, когда закрытие техдолга решает какие-то конкретные оцененные задачи. Чем абстрактнее техдолг, тем сложнее выразить его значимость в денежках.
А ведь после закрытия техдолга могут ещё и попросить сверить эффект с предварительной оценкой. И как быть тогда?
Печаль в том, что казалось бы самый оптимальный вариант - гибрид - на деле самый малоэффективный. Когда ты то общаешься вживую, то онлайн, это разрывает пространство коммуникации. Самые неудачные митинги, когда кто-то собирается в переговорке, а кто-то подключается по видео. И при этом кто как участвует меняется от встрече к встрече.
На самом деле, могут быть нюансы. Точнее даже они бывают достаточно часто. По своим коллегам, которые вернулись в офис, могу сказать, то в целом даже на онлайн митингах они более собранные. У них слышно меньше шума, они реже отвлекаются.
Не такой уж и частный слушай. На начало пандемии я работал в международной компании и наш проект был размазан на три страны и, навскидку, шесть разных городов. Затем я работал в крупной компании с распределённой сетью офисов в пределах одной страны. Сейчас я снова в "крупной международной". Как-то очень часто для частного)
В любых процессах важно не перемудрить, не закрутить эти самые гайки до скрипа. И уж тем более это важно в коммуникации, т.к. это софт скилл и прежде всего про людей. Одно дело, когда кто-то "приносит" тебе шаблоны хард скиллов, например, по написанию кода, другое дело, когда кто-то начинает учить тебя общаться. "Я что, не умею ОБЩАТЬСЯ? Да я всю жизнь общаюсь!" - это частая реакция)
Из полезных советов я докину два момента. Первый касается собственно агентов изменений, будь то один человек или команда. Начинать надо с себя. Простая истина, но стОящая упоминания. Предлагаешь всем писать фоллоу-апы? Начни это делать первым, может даже ещё до внедрения во всей компании. Топишь за шаблоны? Составь их для своей команды и показывай своим как реальный образец, а не что-то из книжек. Ты не будешь выглядеть как сапожник без сапог.
Второй момент касается того, что как правило к моменту начала внедрения изменений есть некий накопленный негатив. Часто он мешает изменениям, хотя направлен не против них - это всё против текущих порядков. Именно поэтому полезно описывать состояние AS IS. А ещё полезно провести некую разрядку. Будь то толковая ретроспектива или тимбилдинг.
Проблема с утверждением про вечный успех связана с тем, что это попытка выдать самому себе индульгенцию. Что бы ты не делал - ты молодец. Если компании нужно отправить спутник на орбиту и ты просто скинул с крышы офиса миксер - окей, ты выяснил, что миксеры не летают. Успех? Успех.
Исследование должно создавать ценность, которая неким значимым образом приближает компанию к решению бизнес-задач. В примере с миксером реальная польза максимально близка к нулю.
И это нас приводит ещё к одной интересной мысли. У исследования есть заказчик? Кто-то извне команды исследования. Если так, то получается это он решает, успешно завершилось исследование или нет. Заказчик решает, а не сама команда.
С тем, что исследование всегда успешное, я не соглашусь. Сам автор выше говорит, что исследование должно быть направлено на решение какой-либо бизнес-задачи. Если исследование не закончилось успехом, например, решено такую-то технологию/инструмент не внедрять, то разве бизнес-задача решена? Не-а. Отмести один из N вариантов - это не решение.
Я бы в целом чуть отодвинул R&D от решения конкретных задач. Как по мне, такие проекты существуют на более концептуальном уровне.
А что в таком случае в дружной скиловой команде мешало получать хорошие результаты до этого? 0_о
Каким образом частное облако обыграло публичное по скорости предоставления ресурсов утилизации?
Алсо, есть некоторые манипуляции. Тот факт, что предоставление ресурсов с т.з. согласований и закупок занимало времени - это прежде всего проблема процессов. Процессов запросов и согласований, процессов планирования.
А авторвы научно-популярной литературы заплатили бабки учёным, на основе открытий которых писали свои произведения?
Я бы поправил вас в примере с атакой.
Инфраструктура нуждается в защите от атак в любом случае, облачная она или онпрем. Если защита в облаке настроена правильно, почку за ресурсы продавать не придётся. А если этого не делать, то да, возможно эта неосмотрительность дорого обойдётся.
Как-то очень сладко получилось. Затрат меньше, хлопот меньше, людей меньше. Риски? За них тоже не переживайте.
Про то, что парой сделанных или несделанных кликов в облаке можно грохнуть годовой бюджет за месяц/неделю, думаю в 2023 году уже никому не надо рассказывать.
По поводу рисков/ответственности - надо понимать, что все облачные тулы по логированию, инспектированию, фильтрации тоже стоят денег.
Принципиальное отличие облака от онпрема заключается в скорости изменений и... территориальной доступности. Поставить сервачок в уютненькой серверной и показать фигу облакам - это сработает при сравнительно локализованном бизнесе. Когда вы глобальная корпорация с кучерявыми сервисами, а не просто страничной на Тильде, без облака обеспечить достойную скорость работы будет трудно.
Хотелось бы услышать какие-то более сложные примеры, чем "посмотрел статистику, сравнил цифры". Кмк финопс может иметь функции подбора тарифов, проектирования автоматизаций, чтобы они не съели ваще все деньги мира при первом же автоматическом масштабировании.
Купит ли заказчик внедрение личного кабинета у этой компании будет во многом зависеть от того, как он оценит те изменения, которые ему предложили внести на сайте сперва. Почему во многом? Разве может быть вариант, когда трансформация прошла успешно, но дальше решили не двигаться? Да, может.
Нужно фокусироваться на ценности. Если не уходить в совсем высокие материи, то заказчика интересует улучшение взаимодействия посетителей с клиникой. Кабинет - это одна из фичей на пути к этому, не более. Команда путём исследования индентифицировала другие фичи с более высоким приоритетом. Заказчик согласился, фичи ушли в работу.
Всё стоит денег и эффект внедрения фичи должен иметь и денежную метрику. Сколько новых клиентов привлечём, столько старых удержим, насколько увеличим средний чек? Может быть так, что клиентам УЖЕ стало гораздо удобнее пользоваться сайтом. И дальнейшая финансовая выгода от личного кабинета будет минимальной. Зачем тогда тратить бабки на разработку плюс закладывать бОльшие бабки на поддержку? Может и не надо.
Поэтому продать личный кабинет на самом-то деле может быть ещё сложнее, чем переубедить заказчика и сделать сперва навигацию.
Детские крики на созвонах - кошмар. Да и любые другие посторонние шумы вроде собак, ремонта, машин. Сложно поверить, что работающий в таких условиях человек концентрируется на работе и эффективен.
Про пальмы, море и другую красоту - это скорее зависить, надо признать. Когда ты сидишь дождливым осенним утром в квартирке где-то на окраине города N, а кто-то на солнечном пляже... Но, положа руку на сердце, море за спиной - вполне рабочая обстановка. Надо учиться радоваться за коллег)
Могу поделиться своей историей. После удалёнки был гибрид, сейчас целиком работаю из офиса. И больше всего меня раздражают... Онлайн-митинги. Потому что разве не ради живого взаимодействия нас возвращали в офис?
Чем крупнее компания, тем больше уровней иерархии. Если кто-то может привести пример компании крупнее 3к работников со всего парой уровней по вертикали - было бы интересно узнать. И разделение как раз происходит на уровне права принимать решение.
Кмк, в статье несколько идеализируется возможность инжерена в "компании в стиле КД" принимать серьёзные решение. Пожалуй, в более реалистичном сценарии инженер может дать обратную связь или предложение - и это послание будет эффективно услышано и рассмотрено.
>>Инструменты ITSM дают возможность быстро и эффективно телепортироваться из одного организационного состояния в другое.
М-да. Реклама курсов из разряда финансовых пирамид. Ни один человек, который оть немного сталкивался с трансформацией процессов и внедрением сервисного подхода, не поверить вот в эту сказу про "быструю телепортацию".