Комментарии 5
Однако фактически, отказавшись от важных этапов разработки [тесты и CI/CD], мы начинаем плодить технический долг
Отказавшись от тестов, CI/CD вы не технический долг плодите, а ущерб бизнесу
оптимальное решение — это конвертация технических задач в бизнес-задачи
Конвертация тасок в таски, которая поможет менеджерам работать с тасками как с тасками, и объяснить бизнесу, почему ему нужно платить за таски, как за таски? Звучит оптимально! :)
Вы не сможете говорить с бизнесом на одном языке о техническом долге, бизнес нанимает вас, специалистов, потому что этого языка не знает, и знать не хочет.
Проблема сильно проще по своей сути, если правильно её сформулировать, только более решаемой она от этого не становится.
Технический долг глазами заказчика (бизнеса) — проблемы, которые возможно будут завтра, но оплачивать их решение заказчику нужно сегодня.
"Продажа технического долга" — это продажа вероятной угрозы.
Возможно ли заказчику доказать пользу работы над техническим долгом? Теоретически, возможно. Если а) она есть б) вы сможете её измерить
Как заставить заказчика платить за то, что он не может понять и оценить? Никак. Можно страшно запугать (см маркетинг антивирусных/инфосек решений), можно страшно налгать (усилиями харизматичных менеджеров, которые умножат сроки выполнения), и надеяться что вам поверят.
UPD: не разумнее ли "продавать" свой профессионализм, вместо технического долга?
Отказавшись от тестов, CI/CD вы не технический долг плодите, а ущерб бизнесу
Не всегда так, если мы говорим про запуск нового проекта есть кейсы, когда эти задачи могут быть отложены на более поздние этапы. И тут важно, что если мы откладываем это на следующие этапы, что это процесс не станет бесконечным.
«Продажа технического долга» — это продажа вероятной угрозы.
Далеко не всегда так, зачастую технический долг начинает приносит реальный ущерб и это один из поводов задуматься о том, что долги пора вернуть.
UPD: не разумнее ли «продавать» свой профессионализм, вместо технического долга?
Умение общаться с бизнесом на понятном языке, на мой взгляд, тоже относится к одной из граней профессионализма.
Я думаю, главная причина непонимания — в том как мы, инженеры и разработчики, пытаемся объяснять бизнесу, почему важно избавляться от техдолга.
Бесполезно объяснять.
Есть два типа менеджеров: которые лично наблюдали смерть проекта под грузом техдолга, и те, которые такого опыта не имеют.
Объяснять вторым, что заниматься техдолгом важно — тоже самое, что объяснять человеку о необходимости чистить зубы, когда зубы у него никогда не болели — бесполезно. Вот заболят — поймет.
Вы в алгоритме анализа данных post mortem не перепутали в последнем ветвлении true и false ветки? У вас нарисовано "Нужно много времени на диагностику и устранение" ? "баг/задача" : "отправляем в техдолг". Как-то контринтуитивно звучит. Если можно просто решить -- отложим-ка в техдолг, а если это сложно -- надо взяться и обязательно сделать. Обычно происходит наоборот. :)
Как [не] продать технический долг (обзор и видео доклада)