GK
мне кажется в данном случае нужно напирать на TTM (его снижение), снижение числа ошибок, уменьшение времени простоя, TCO, в том числе снижения стоимости регрессионного тестирования
Size: a a a
2021 April 08
KG
Похоже надо сделать 10x более эффективное решение через использования облаков. Походу работа продавана
П
Я бы все же предложил начать с анализа существующих проблем и способов их решения при помоши менее революционных изменений, чем смена всей архитектуры.
GK
Что мы можем сделать как айтишники, в то числе за счёт редизайна:
- уменьшить TTM
- снизить TCO
- повысить надёжность и т.п.
Первые два пункта про время/деньги, остальное - про показатели назначения
- уменьшить TTM
- снизить TCO
- повысить надёжность и т.п.
Первые два пункта про время/деньги, остальное - про показатели назначения
VA
Смена «не всей» архитектуры :)
GK
вот точно
AK
сначала надо спроектировать в 10х раз более эфективное решение. В этом и заключается работа
П
именно
VA
А расчёт стоимости регрессионного тестирования — это как про секс на выпускном? Все говорят, что считают?)
GK
я не говорил про "рассчитать", можно качественную оценку сделать
GK
Если у вас макароны и нужно полный регресс делать каждый раз перед релизом, то на этом фоне могут быть видны изменения, если хоть какая-то модульность появится
GK
Иными словами, вместо того чтобы предлагать расчёт, сколько бизнес сможет заработать/сэкономить за счёт изменений архитектуры/процессов (в айтишной кухне) и пр., имеет смысл говорить (обещать) про то, что действительно скорее всего возможно при таких изменениях. При этом стараться всё же давать качественные оценки.
Тогда из вас труднее будет сделать козлов отпущения.
Тогда из вас труднее будет сделать козлов отпущения.
GK
Экономия тоже спорный вопрос. Вы уменьшите скоуп регрессионного тестирования, а кто-то наймёт подрядчика, который тестировать будет медленее и дороже, чем предыдущий.
GK
Иными словами, зароботок/экономия, то есть финансовые показатели, не совсем ответственность инженеров. При этом, инженеры могут качественно повлиять на финасовые показатели.
Также стоит учесть, что инженеры почти всегда "слаблее" в политических играх, чем менеджеры и бизнес. Не вступайте на их "поляну").
Также стоит учесть, что инженеры почти всегда "слаблее" в политических играх, чем менеджеры и бизнес. Не вступайте на их "поляну").
D
Хм, но при этом разработчикам приходится кренделя выписывать перед заказчиками, чтобы они снизошли до кривозубых крестьян и позволили выделить ресурсы на рефакторинги и прочее
D
так получается?
GK
Не понял сути вопроса.
D
Менеджеры/бизнес хочет больше зарабатывать, но чтобы больше заработать нужно уменьшить ТТМ наример, а уменьшить его может разработчик, предлагая идеи и улучшения. Однако бизнесу нужны "реальные цифры" и как тогда разработчик их может представить , если "финансовые показатели, не совсем ответственность инженеров"?
D
>Также стоит учесть, что инженеры почти всегда "слаблее" в политических играх, чем менеджеры и бизнес. Не вступайте на их "поляну"
Вот тут согласен
Вот тут согласен
GK
Посчитать косты на рефакторинг. Это сделать реально.
Сколько они сэкономят или заработают в итоге посчитать нереально.
Назвать порядок времени на которое сократится TTM тоже реально. Были месяцы, будут недели.
Сколько они сэкономят или заработают в итоге посчитать нереально.
Назвать порядок времени на которое сократится TTM тоже реально. Были месяцы, будут недели.