Честно говоря, никакой копипасты из Жипыты здесь нет — я сам пишу ответы, просто стараюсь всегда делать это структурированно и аргументированно. Но если это выглядит как иишечка, я даже не пойму - мне стоит обидеться или, наоборот, гордиться? :D
А если серьёзно — за моими плечами 7 лет работы в СМИ, было это давно, в 2013 году, но с тех пор привычка осталась так доносить мысли. Люблю в дискуссиях раскладывать всё по полочкам. И опять же не с целью нахвалить себя, но всё же добавлю: параллельно я веду (вёл, пока была ещё такая возможность в различных публичных сервисах) блог, где много писал текстов, вел дискуссии с читателями. Плюс сейчас я пишу художественную книгу, и думаю в течении квартала она выйдет в свет. Возможно даже напишу про это статью на Хабр, о том “Как я до этого дошел” :)
Если говорить про моё искренее чувство - то мне действительно жаль, что это показалось на ИИшку :(
Вы абсолютно правы: любая метрика, введённая без контекста и без наказания за злоупотребление, превращается в игру в одни ворота. “Частота деплоя” сама по себе - зелёная, а прод - красный. Поэтому ни один вменяемый руководитель не использует одну метрику. Есть три слоя, которые работают только в связке.
Метрика: Количество багов (не просто число, а динамика) Мы заводим копилку багов. Каждый баг, обнаруженный на проде (или, кстати, на стейдже), попадает туда с пометкой: критичность, сценарий воспроизведения, автор, причина (недопонимание требований, невнимательность, плохой тест-кейс, спешка и т.д.).
Но баги бывают разными. Опечатка в комментарии - это баг? Скорее, шум. А вот “после деплоя упала оплата” - это уже серьёзно. Поэтому:
Критичные баги (падение сервиса, потеря данных, уязвимость) - красная зона. Один такой баг в спринте - сигнал к разбору. Средние баги (неправильно работает фича, но есть обход) - жёлтая зона.
Мелкие баги (опечатки, кривые CSS, не тот текст) - зелёная зона, но если их много - тоже сигнал.
Важно не просто считать, а смотреть на тренд. Если спринт назад было 5 багов, а теперь 15 - метрика краснеет, даже если частота деплоя выросла в 3 раза.
Метрика: Реализованные бизнес-стори (а не просто задачи) Комментатор пишет про “коммитить опечатки” - это пример пустой активности. Вот почему важно мерить не коммиты, а бизнес-стори, доставленные до пользователя без регресса.
Определение: стори считается реализованной, если:
Она прошла код-ревью.
Прошла автоматические тесты (юнит, интеграционные, и прочее надругательство над системой).
Прошла ручное приёмочное тестирование (хотя бы смоук).
Не породила новых критичных багов в течение 3 дней после релиза.
То есть если вы закоммитили опечатку - стори не засчитается, потому что баг. А если вы за день 10 раз сфиксили одну опечатку - это одна стори с пометкой “исправление опечатки”, а не 10 коммитов.
Метрика: Отношение “баги / стори” - плотность дефектов Формула простая: количество багов (критичных и средних) за спринт, делённое на количество реализованных стори за тот же спринт. Цель - меньше 0.1 (то есть не более одного бага на 10 стори). Если плотность растёт - это триггер для разбора.
Пример: команда сделала 20 стори, но поймали 5 багов - плотность 0.25. Красный флаг. А если сделали 5 стори и 5 багов - плотность 1.0, это катастрофа.
Что происходит, когда копилка багов переполняется? Вы пишете: “щас начнем разбираться, кто тут косяк”. Я бы сказал мягче, но принцип тот же: без последствий метрики не работают.
Воообще в здравом IT-управлении должно быть заведено правило:
Разбор полётов - не для того, чтобы наказать, а чтобы понять коренную причину. Но если причина - систематическая халатность, а не объективная сложность, то:
Первый случай: предупреждение команде/разработчику.
Второй случай за короткий период: выговор (можно наложить каике-нибудь последствия в виде откусывания частички премии и всё такое).
Третий случай: персональная ответственность с чёткими последствиями (вплоть до перевода в другой проект или пересмотр профпригодности).
Я не сторонник “бить разработчиков”, но я сторонник культуры ответственности. Если баги не имеют последствий, команда перестаёт их замечать, и прод действительно ложится.
Как избежать игр с метриками (чтобы не коммитили опечатки) Чтобы разработчики не начали накручивать частоту деплоя мелкими бесполезными коммитами, мы делаем три вещи:
Считаем только деплои, которые содержат бизнес-стори. Чистые фиксы опечаток или правки комментариев не идут в зачёт частоты деплоя для метрики эффективности. Можно сделать отдельный счётчик “технические деплои”, но они не влияют на KPI команды.
Вводим понятие “цена релиза”. Если релиз состоял из 30 коммитов, из которых 28 - это переименование переменных и исправление опечаток, а реальных фич - 2, то эффективность этого релиза низкая, и бизнес это видит.
Используем автоматический анализ коммитов. Есть инструменты, которые определяют: коммит меняет бизнес-логику или только комментарии/форматирование. Вторые просто не учитываются в метриках “доставки ценности”.
Итог: метрики должны быть сбалансированы и подкреплены санкциями Частота деплоя зелёная, но прод лежит? Значит, вы забыли про частоту откатов (Change Failure Rate - одна из DORA-метрик, кстати). И забыли про плотность багов. И не ввели копилку с последствиями.
Поэтому ответ на ваш комментарий такой: да, если метрика одна и она тупая - будет беда. Но если вы измеряете и количество багов, и реализованные стори, и проводите разборы с выговорами за систематический брак - разработчики быстро поймут, что опечатки в комментариях им не помогут, а навредят.
А то, что “опечатки будут вскрываться и наказываться” - это не тирания, это единственный способ заставить команду уважать качество. Иначе уважать будут только зеленые дашборды, а пользователи постояно видеть падающий прод.
Спасибо за комментарий, он очень точный и дополняет тему, которуя не раскрыл в основном тексте.
Главное чтобы не случился немного другой кейс, когда джунов оставят - ведь, они-то справятся чтобы промпт написать, а дорогих синьоров отправить на улицу. В ожидании лучшей жизни ))
Расскажу немного присказку :)) Чуть больше 2х лет назад я присоединился к Лукоморью. И тогда для меня все названия наших продуктов (Яга, Ëжка (от уменьшительно ласкательного Баба Яга), Сирин, и т.д.) звучали именно примерно с такой же мыслью "Ага! Как тебе такое суверенное, нашенское!" :)
Сейчас же это уже вошло в привычку, и действительно, мне бы стоило чуть подробнее описать что такое Лукоморье, без фанатизма и пиара, чтобы ввести читателя в курс дела. Но до сих пор эти названия такое тепло в душе и хранят.
Есть такое да) Надо взять за идею как стартап для компании - сделать ругугл-таблицы и назвать это универсальным инструментом для управления всей компании и всеми процессами! :D
Спасибо за такое детальное возражение - вы бьёте в самую больную точку многих статей про управление: где обещанные бизнес-обоснования? Давайте разбираться.
Где обоснования “зачем это нужно” в каждом пункте?
Вы пишете, что кроме фразы “оптимизировали на 30%” (кстати, в статье такое встречается ровно один раз - в разделе про Cloud Native: “сэкономить до 30% на облаках”) ничего нет. Позволю себе не согласиться. Обоснования есть, наверное, я недостаточно ярко их выделил, потому что они разбросаны по тексту, а не собраны в одну таблицу. Предлагаю пробежаться по пунктам, которые вы, возможно, пропустили или сочли недостаточными:
STAR - обоснование прямо в тексте: “STAR структурирует мысль. А структурированную мысль легче оценить, проверить и сопоставить с целями бизнеса. Для бизнеса это язык ясности, а ясность почти всегда конвертируется в доверие”. И сразу пример: после внедрения CI/CD “частота релизов выросла с одного раза в месяц до 20 в неделю, а время деплоя сократилось до 15 минут”. Разве это не обоснование пользы?
Security as Code - обоснование: “безопасность нельзя “добавить” в конце… потом разгребать последствия: долго, больно, дорого”. И дальше: “Security as Code снижает зависимость от человеческого фактора и превращает безопасность из субъективной экспертизы в повторяемую, прозрачную и проверяемую практику”. Для разработчика плюс: “вместо гадания появляется понятный набор правил и автоматических проверок”. То есть обоснование “зачем” — меньше сюрпризов и пожаров.
DevSecOps - прямая цитата: “гораздо дороже и дольше чинить уязвимость на проде, чем найти её на этапе разработки, тестирования или сборки”. И далее перечислены этапы с конкретными инструментами. Это и есть бизнес-обоснование: раннее обнаружение дешевле.
Метрики (DORA) - обоснование дано через проблему: “Velocity измеряет количество работы, но не ценность… достижение плана спринта прямо не означает достижения бизнес-цели”. А затем показано, как DORA-метрики (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) позволяют “оценивать эффективность разработки и находить узкие места”. Например: “Lead Time for Changes меньше часа — вы Джон Уик… больше месяца — вы живёте в релизном аду”. Разве не понятно, зачем это нужно?
Так что обоснования есть. Просто они не вынесены в отдельный столбец с жирными KPI. И это осознанное решение - иначе статья раздулась бы до размеров книги.
Про ИИ и финансового директора Вы совершенно правы: бизнесу нужны сокращение издержек или рост прибыли.
И в статье это прямо сказано. Цитата из раздела #3:
“Для команды ИИ - это способ снять часть рутины. Генерация шаблонного кода, автоматическое создание юнит-тестов, рефакторинг, анализ уязвимостей… Для руководителя ценность другая: ИИ помогает автоматизировать отчетность, быстрее собирать текст по метрикам, анализировать большие массивы обратной связи”.
И дальше пример: вместо недели рыться в логах, инженер задаёт вопрос ИИ-ассистенту и через несколько минут получает анализ. Результат: “экономию времени и нормальную отправную точку для дальнейшей работы”.
Так вот, экономия времени разработчика = экономия денег компании. Это база. Если финансовый директор этого не понимает, то проблема не в статье. И нигде не сказано, что ИИ нужен “чтобы потроллить финдира”. Наоборот - это инструмент ускорения, а не замена людей.
Почему нет детальной раскладки по каждому пункту с цифрами?
Как я сказал чуть ранее статья и так получилась лонгридом - больше 10 000 знаков. Если бы я по каждому из 9 пунктов расписывал не только “зачем”, но и “на сколько процентов” с выкладками ROI, то вышла бы действительно полноценная книга. Именно поэтому в конце некоторых разделов я оставил ссылки на другие источники (например, в разделе про STAR, про Cloud Native, про DevSecOps). Тот, кого тема реально зацепила, может нырнуть глубже.
Ну и в ответ - тот самый тонкий троллинг (без злобы, честно, с уважением к вашему вопросу)
Честно говоря, когда я перечитал ваш комментарий, а потом ещё раз пробежался по своей статье, у меня возник вопрос: а вы точно читали её внимательно? Потому что обоснования — не спрятаны, не зашифрованы. Они буквально лежат в каждом разделе. Например, про язык бизнеса прямым текстом: Мы внедрили кеширование" - почти ничего не значит. Гораздо полезнее сказать: “Уменьшили время отклика на 70%, что может увеличить конверсию на 5%”. Про Cloud Native три развёрнутых сценария с выгодой для бизнеса: вместо 2-3 дней простоя - 2-3 минуты, экономия на ресурсах, единая платформа.
Может быть, вы ожидали, что после каждого заголовка будет табличка “Выгода для бизнеса: N рублей”? Не дождались - потому что это был бы консалтинговый отчёт, а не живая статья для Хабра.
Тем не менее, ваш комментарий бесценен. В следующих публикациях я обязательно буду жирным шрифтом выделять фразы вроде “А вот конкретная бизнес-выгода здесь: …”
В целом звучит логично. Скорее всего тут сыграло роль то, что для нас "Лукоморье" уже на слуху, и через эту призму видится что все уже это знают. Конечно это ошибочное мнение. Спасибо! Записал себе в блокнотик "на заметку" так сказать.
Какое интересное слово "чухня" :)) Понимаю реакцию на непривычное и где-то издалека знакомое "Лукоморье". Я крайне негативно отношусь когда статья - это пиар. Поэтому не стал расписывать многими абзацами что это такое, эдакое. И вот сюда посмотрите и сюда. В общем таки про "что это" - https://lukit.ru/
Делаем ИТ-экосистему по управлению бизнес-процессами. Это если ответить "по-методичке".
Спасибо за замечание (значит вы прочитали статью, и мне вдвойне приятно :) ) Сначала я хотел показать всю картину: список задач, растянутые по таймлайнам «колбаски» и так далее. Но изображение получилось слишком большим, и в формат статьи оно не уместилось. Пришлось выбирать: показать список или таймлайны.
Что же имелось в виду под Гантом при таком подходе, как раз вот это самое планирование зависимых, последовательных и параллельных релизов. На том самом таймлайне отображается информация по требуемым ресурсам для выхода зависимых и связанных задач. Как раз если «развернуть» это всё в Ганте, будет видно, какие ресурсы требуются и в какие даты, а зависимости внутри карточки будут подсвечивать такие моменты.
Хм... ну по поводу того хорошо или плохо что задачи идут без анализа я бы сказал что - плохо. Объясню почему.
Я считаю что разработчик, хороший разработчик, должен сам уметь разобраться с задачей и сделать её качественно даже если будет отсутствовать системный аналитик. Так же разработчик не должен 100% расчитывать что тестировщик отловит баги. Разработчик должен понимать что он пишет и как это аффектит на систему. И тут, казалось бы, почему же я считаю плохой ситуацию когда задача выполнялась без системного аналитика? Тут всё просто - отсутствует важный артефакт, отсутсвует документация! Т.е. после системного аналитика остаётся хоть какой-то след, прочитав который можно быстро погрузиться в детали реализации самой задачи. Команда меняется, люди меняются, и вновь прибывшим коллегам на проект очень хотелось бы иметь какую-то информацию по функционалу и т.д.
Если попробовать разобрать вопрос когда фронт и бэк остаются один на один - ну что тут сказать. Ситуация хоть и неприемлемая, но допустимая, такое бывает. В данном случае тут надо идти по пути данных, т.е. от инициатора до исполнителя.
В данном случае инициатором будет фронт разработчик, т.к. он отправляет данные в бэк. И вот на каждом этапе взаимодействия между фронтом и беком от инициатора к исполнителю должно придти предложение как будет выглядеть формат взаимодействия. Далее оба участника либо соглашаются на такое взаимодействие, либо обсуждают и приходят к какому-то совместному решению. Т.е. проще говоря не должно быть ситуации когда данные переходят от фронта к беку или наоборот, а вот формат передачи и перехода данных остался без обсуждения. Это важная составляющая взаимодействия фронта и бека без системного аналитика. Но опять, в данном случаем мы хоть и получим реализацию, но потеряем в документации :(
Да, вот эти все ошибки и боли мы проходили. И продакт оунеры должны быть на груминге и тестировщики. Всё верно :) Изначально я и хотел описать полностью как выглядит этот всё дело, но в процессе написания статья получилась оооооооочень длинная. Решил что это будет издевательство на читателями ) Кстати, пока от всех не будет получен апрув - действительно не стоит брать в разработку ТЗ. Это золотое правило! Могут быть ограничения, но это крайне редкие случаи, и они обсуждаются индивидуально к каждой задаче.
По поводу "Вотерфлоу" надеюсь это был вопрос с сарказмом про "Вотерфолл" :)
Кстати, интересная тема про "А как же быть без аналитика?" ? Надо будет попробовать написать про это ) Такой опыт тоже имеется в бардачке. А вот кровавое рубилово мы как раз исключили - об этом и повествует статья ;)
Хм... мне кажется я понял вашу мысль. В целом если бы назвать статью "Почему ТЗ и ныне там?" то выглядело бы гуд. Тогда можно было бы оперировать только тем, что речь идёт именно о техническом задании.
Я немного в растерянности, но "здравый смысл" - это полезная вещь, как бы это странно не звучало :) Возможно я не совсем понял ваш посыл. Расскажите подробнее?
Что касается по принятому формату, я об этом отдельно писал https://habr.com/ru/company/otkritie/blog/648155/ тут всё по полочкам... хотя этих "полочек" я бы добавил побольше, но боюсь что большие тексты тяжело читать.
US в этой статье и есть некий "воз" из басни Крылова. Она тут образно выражаясь так сказать.
Угу, всё верно. И аналитик плохо заТЗшил и разрабы ушли в самоволку ) Я бы немного похоливарил на тему джуны они или нет ;) Как я вижу градацию от джуна до синьора: Джун - не знает что делать и не знает как делать Мидл - не знает что делать, но знает как делать Синьор - знает что делать и знает как делать
Тут все трое а-ля "молодцы" сами сделали задание :) Это что-то типа около Middle. Так же я хотел показать что это специалисты характера - "Ой, я сам знаю как лучше". Поэтому они ни с кем не обсуждали своё решение (которое, согласен с вами, упустил аналитик).
Но суть не в этом, мне понравилось ваше замечание про то, что они прокачают других до такого же уровня (делай тяп-ляп). Подскажите пожалуйста где я оставил брешь в системе? Её нужно срочно залатать :D Очень не хотелось бы чтобы экспертиза участников тянулась вниз. Т.е. как по вашему мнению используя груминги и совместную работу над задачей они потянут за собой остальных?
А что касается про тестирование требований - я и так уже переживал что получился слишком лонгрид, надо было сокращать )
Справедливое замечание по поводу того что стиль изложения слегка, назовем это так, необычный :) Возьму на заметку - нужно будет упростить. Понимая это я и завершил статью подведением итогов. Но в любом случае я премного благодарен за двойное чтение. Так же буду рад если что-то из этого пригодится на практике.
Хорошая картинка, и, главное - жизненная.
Только это работает в случае заказной разработки )
Честно говоря, никакой копипасты из Жипыты здесь нет — я сам пишу ответы, просто стараюсь всегда делать это структурированно и аргументированно. Но если это выглядит как иишечка, я даже не пойму - мне стоит обидеться или, наоборот, гордиться? :D
А если серьёзно — за моими плечами 7 лет работы в СМИ, было это давно, в 2013 году, но с тех пор привычка осталась так доносить мысли. Люблю в дискуссиях раскладывать всё по полочкам. И опять же не с целью нахвалить себя, но всё же добавлю: параллельно я веду (вёл, пока была ещё такая возможность в различных публичных сервисах) блог, где много писал текстов, вел дискуссии с читателями. Плюс сейчас я пишу художественную книгу, и думаю в течении квартала она выйдет в свет. Возможно даже напишу про это статью на Хабр, о том “Как я до этого дошел” :)
Если говорить про моё искренее чувство - то мне действительно жаль, что это показалось на ИИшку :(
Вы абсолютно правы: любая метрика, введённая без контекста и без наказания за злоупотребление, превращается в игру в одни ворота. “Частота деплоя” сама по себе - зелёная, а прод - красный. Поэтому ни один вменяемый руководитель не использует одну метрику. Есть три слоя, которые работают только в связке.
Метрика: Количество багов (не просто число, а динамика) Мы заводим копилку багов. Каждый баг, обнаруженный на проде (или, кстати, на стейдже), попадает туда с пометкой: критичность, сценарий воспроизведения, автор, причина (недопонимание требований, невнимательность, плохой тест-кейс, спешка и т.д.).
Но баги бывают разными. Опечатка в комментарии - это баг? Скорее, шум. А вот “после деплоя упала оплата” - это уже серьёзно. Поэтому:
Критичные баги (падение сервиса, потеря данных, уязвимость) - красная зона. Один такой баг в спринте - сигнал к разбору.
Средние баги (неправильно работает фича, но есть обход) - жёлтая зона.
Мелкие баги (опечатки, кривые CSS, не тот текст) - зелёная зона, но если их много - тоже сигнал.
Важно не просто считать, а смотреть на тренд. Если спринт назад было 5 багов, а теперь 15 - метрика краснеет, даже если частота деплоя выросла в 3 раза.
Метрика: Реализованные бизнес-стори (а не просто задачи) Комментатор пишет про “коммитить опечатки” - это пример пустой активности. Вот почему важно мерить не коммиты, а бизнес-стори, доставленные до пользователя без регресса.
Определение: стори считается реализованной, если:
Она прошла код-ревью.
Прошла автоматические тесты (юнит, интеграционные, и прочее надругательство над системой).
Прошла ручное приёмочное тестирование (хотя бы смоук).
Не породила новых критичных багов в течение 3 дней после релиза.
То есть если вы закоммитили опечатку - стори не засчитается, потому что баг. А если вы за день 10 раз сфиксили одну опечатку - это одна стори с пометкой “исправление опечатки”, а не 10 коммитов.
Метрика: Отношение “баги / стори” - плотность дефектов Формула простая: количество багов (критичных и средних) за спринт, делённое на количество реализованных стори за тот же спринт. Цель - меньше 0.1 (то есть не более одного бага на 10 стори). Если плотность растёт - это триггер для разбора.
Пример: команда сделала 20 стори, но поймали 5 багов - плотность 0.25. Красный флаг. А если сделали 5 стори и 5 багов - плотность 1.0, это катастрофа.
Что происходит, когда копилка багов переполняется? Вы пишете: “щас начнем разбираться, кто тут косяк”. Я бы сказал мягче, но принцип тот же: без последствий метрики не работают.
Воообще в здравом IT-управлении должно быть заведено правило:
Разбор полётов - не для того, чтобы наказать, а чтобы понять коренную причину. Но если причина - систематическая халатность, а не объективная сложность, то:
Первый случай: предупреждение команде/разработчику.
Второй случай за короткий период: выговор (можно наложить каике-нибудь последствия в виде откусывания частички премии и всё такое).
Третий случай: персональная ответственность с чёткими последствиями (вплоть до перевода в другой проект или пересмотр профпригодности).
Я не сторонник “бить разработчиков”, но я сторонник культуры ответственности. Если баги не имеют последствий, команда перестаёт их замечать, и прод действительно ложится.
Как избежать игр с метриками (чтобы не коммитили опечатки) Чтобы разработчики не начали накручивать частоту деплоя мелкими бесполезными коммитами, мы делаем три вещи:
Считаем только деплои, которые содержат бизнес-стори. Чистые фиксы опечаток или правки комментариев не идут в зачёт частоты деплоя для метрики эффективности. Можно сделать отдельный счётчик “технические деплои”, но они не влияют на KPI команды.
Вводим понятие “цена релиза”. Если релиз состоял из 30 коммитов, из которых 28 - это переименование переменных и исправление опечаток, а реальных фич - 2, то эффективность этого релиза низкая, и бизнес это видит.
Используем автоматический анализ коммитов. Есть инструменты, которые определяют: коммит меняет бизнес-логику или только комментарии/форматирование. Вторые просто не учитываются в метриках “доставки ценности”.
Итог: метрики должны быть сбалансированы и подкреплены санкциями Частота деплоя зелёная, но прод лежит? Значит, вы забыли про частоту откатов (Change Failure Rate - одна из DORA-метрик, кстати). И забыли про плотность багов. И не ввели копилку с последствиями.
Поэтому ответ на ваш комментарий такой: да, если метрика одна и она тупая - будет беда. Но если вы измеряете и количество багов, и реализованные стори, и проводите разборы с выговорами за систематический брак - разработчики быстро поймут, что опечатки в комментариях им не помогут, а навредят.
А то, что “опечатки будут вскрываться и наказываться” - это не тирания, это единственный способ заставить команду уважать качество. Иначе уважать будут только зеленые дашборды, а пользователи постояно видеть падающий прод.
Спасибо за комментарий, он очень точный и дополняет тему, которуя не раскрыл в основном тексте.
Главное чтобы не случился немного другой кейс, когда джунов оставят - ведь, они-то справятся чтобы промпт написать, а дорогих синьоров отправить на улицу. В ожидании лучшей жизни ))
Расскажу немного присказку :)) Чуть больше 2х лет назад я присоединился к Лукоморью. И тогда для меня все названия наших продуктов (Яга, Ëжка (от уменьшительно ласкательного Баба Яга), Сирин, и т.д.) звучали именно примерно с такой же мыслью "Ага! Как тебе такое суверенное, нашенское!" :)
Сейчас же это уже вошло в привычку, и действительно, мне бы стоило чуть подробнее описать что такое Лукоморье, без фанатизма и пиара, чтобы ввести читателя в курс дела. Но до сих пор эти названия такое тепло в душе и хранят.
Есть такое да) Надо взять за идею как стартап для компании - сделать ругугл-таблицы и назвать это универсальным инструментом для управления всей компании и всеми процессами! :D
Спасибо за такое детальное возражение - вы бьёте в самую больную точку многих статей про управление: где обещанные бизнес-обоснования? Давайте разбираться.
Где обоснования “зачем это нужно” в каждом пункте?
Вы пишете, что кроме фразы “оптимизировали на 30%” (кстати, в статье такое встречается ровно один раз - в разделе про Cloud Native: “сэкономить до 30% на облаках”) ничего нет. Позволю себе не согласиться. Обоснования есть, наверное, я недостаточно ярко их выделил, потому что они разбросаны по тексту, а не собраны в одну таблицу. Предлагаю пробежаться по пунктам, которые вы, возможно, пропустили или сочли недостаточными:
STAR - обоснование прямо в тексте: “STAR структурирует мысль. А структурированную мысль легче оценить, проверить и сопоставить с целями бизнеса. Для бизнеса это язык ясности, а ясность почти всегда конвертируется в доверие”. И сразу пример: после внедрения CI/CD “частота релизов выросла с одного раза в месяц до 20 в неделю, а время деплоя сократилось до 15 минут”. Разве это не обоснование пользы?
Security as Code - обоснование: “безопасность нельзя “добавить” в конце… потом разгребать последствия: долго, больно, дорого”. И дальше: “Security as Code снижает зависимость от человеческого фактора и превращает безопасность из субъективной экспертизы в повторяемую, прозрачную и проверяемую практику”. Для разработчика плюс: “вместо гадания появляется понятный набор правил и автоматических проверок”. То есть обоснование “зачем” — меньше сюрпризов и пожаров.
DevSecOps - прямая цитата: “гораздо дороже и дольше чинить уязвимость на проде, чем найти её на этапе разработки, тестирования или сборки”. И далее перечислены этапы с конкретными инструментами. Это и есть бизнес-обоснование: раннее обнаружение дешевле.
Метрики (DORA) - обоснование дано через проблему: “Velocity измеряет количество работы, но не ценность… достижение плана спринта прямо не означает достижения бизнес-цели”. А затем показано, как DORA-метрики (Deployment Frequency, Lead Time, Change Failure Rate, MTTR) позволяют “оценивать эффективность разработки и находить узкие места”. Например: “Lead Time for Changes меньше часа — вы Джон Уик… больше месяца — вы живёте в релизном аду”. Разве не понятно, зачем это нужно?
Так что обоснования есть. Просто они не вынесены в отдельный столбец с жирными KPI. И это осознанное решение - иначе статья раздулась бы до размеров книги.
Про ИИ и финансового директора Вы совершенно правы: бизнесу нужны сокращение издержек или рост прибыли.
И в статье это прямо сказано. Цитата из раздела #3:
“Для команды ИИ - это способ снять часть рутины. Генерация шаблонного кода, автоматическое создание юнит-тестов, рефакторинг, анализ уязвимостей… Для руководителя ценность другая: ИИ помогает автоматизировать отчетность, быстрее собирать текст по метрикам, анализировать большие массивы обратной связи”.
И дальше пример: вместо недели рыться в логах, инженер задаёт вопрос ИИ-ассистенту и через несколько минут получает анализ. Результат: “экономию времени и нормальную отправную точку для дальнейшей работы”.
Так вот, экономия времени разработчика = экономия денег компании. Это база. Если финансовый директор этого не понимает, то проблема не в статье. И нигде не сказано, что ИИ нужен “чтобы потроллить финдира”. Наоборот - это инструмент ускорения, а не замена людей.
Почему нет детальной раскладки по каждому пункту с цифрами?
Как я сказал чуть ранее статья и так получилась лонгридом - больше 10 000 знаков. Если бы я по каждому из 9 пунктов расписывал не только “зачем”, но и “на сколько процентов” с выкладками ROI, то вышла бы действительно полноценная книга. Именно поэтому в конце некоторых разделов я оставил ссылки на другие источники (например, в разделе про STAR, про Cloud Native, про DevSecOps). Тот, кого тема реально зацепила, может нырнуть глубже.
Ну и в ответ - тот самый тонкий троллинг (без злобы, честно, с уважением к вашему вопросу)
Честно говоря, когда я перечитал ваш комментарий, а потом ещё раз пробежался по своей статье, у меня возник вопрос: а вы точно читали её внимательно? Потому что обоснования — не спрятаны, не зашифрованы. Они буквально лежат в каждом разделе. Например, про язык бизнеса прямым текстом: Мы внедрили кеширование" - почти ничего не значит. Гораздо полезнее сказать: “Уменьшили время отклика на 70%, что может увеличить конверсию на 5%”. Про Cloud Native три развёрнутых сценария с выгодой для бизнеса: вместо 2-3 дней простоя - 2-3 минуты, экономия на ресурсах, единая платформа.
Может быть, вы ожидали, что после каждого заголовка будет табличка “Выгода для бизнеса: N рублей”? Не дождались - потому что это был бы консалтинговый отчёт, а не живая статья для Хабра.
Тем не менее, ваш комментарий бесценен. В следующих публикациях я обязательно буду жирным шрифтом выделять фразы вроде “А вот конкретная бизнес-выгода здесь: …”
“Обещаю” ;)
Я бы и рад, но там моих нет. Могу только присоединиться к просьбе:
Граждане, хейта никакого нет, человек просто попросил разъяснить что такое "Лукоморье".
В целом звучит логично. Скорее всего тут сыграло роль то, что для нас "Лукоморье" уже на слуху, и через эту призму видится что все уже это знают. Конечно это ошибочное мнение. Спасибо! Записал себе в блокнотик "на заметку" так сказать.
Какое интересное слово "чухня" :)) Понимаю реакцию на непривычное и где-то издалека знакомое "Лукоморье". Я крайне негативно отношусь когда статья - это пиар. Поэтому не стал расписывать многими абзацами что это такое, эдакое. И вот сюда посмотрите и сюда. В общем таки про "что это" - https://lukit.ru/
Делаем ИТ-экосистему по управлению бизнес-процессами. Это если ответить "по-методичке".
Если вы ещё для себя откроете составные индексы - вы откроете Америку! И обязательно напишите об этом статью! Поржем хоть ещё раз )
Добрый день!
Спасибо за замечание (значит вы прочитали статью, и мне вдвойне приятно :) )
Сначала я хотел показать всю картину: список задач, растянутые по таймлайнам «колбаски» и так далее. Но изображение получилось слишком большим, и в формат статьи оно не уместилось. Пришлось выбирать: показать список или таймлайны.
Что же имелось в виду под Гантом при таком подходе, как раз вот это самое планирование зависимых, последовательных и параллельных релизов. На том самом таймлайне отображается информация по требуемым ресурсам для выхода зависимых и связанных задач. Как раз если «развернуть» это всё в Ганте, будет видно, какие ресурсы требуются и в какие даты, а зависимости внутри карточки будут подсвечивать такие моменты.
Хм... ну по поводу того хорошо или плохо что задачи идут без анализа я бы сказал что - плохо. Объясню почему.
Я считаю что разработчик, хороший разработчик, должен сам уметь разобраться с задачей и сделать её качественно даже если будет отсутствовать системный аналитик. Так же разработчик не должен 100% расчитывать что тестировщик отловит баги. Разработчик должен понимать что он пишет и как это аффектит на систему. И тут, казалось бы, почему же я считаю плохой ситуацию когда задача выполнялась без системного аналитика? Тут всё просто - отсутствует важный артефакт, отсутсвует документация! Т.е. после системного аналитика остаётся хоть какой-то след, прочитав который можно быстро погрузиться в детали реализации самой задачи. Команда меняется, люди меняются, и вновь прибывшим коллегам на проект очень хотелось бы иметь какую-то информацию по функционалу и т.д.
Если попробовать разобрать вопрос когда фронт и бэк остаются один на один - ну что тут сказать. Ситуация хоть и неприемлемая, но допустимая, такое бывает. В данном случае тут надо идти по пути данных, т.е. от инициатора до исполнителя.
В данном случае инициатором будет фронт разработчик, т.к. он отправляет данные в бэк. И вот на каждом этапе взаимодействия между фронтом и беком от инициатора к исполнителю должно придти предложение как будет выглядеть формат взаимодействия. Далее оба участника либо соглашаются на такое взаимодействие, либо обсуждают и приходят к какому-то совместному решению. Т.е. проще говоря не должно быть ситуации когда данные переходят от фронта к беку или наоборот, а вот формат передачи и перехода данных остался без обсуждения. Это важная составляющая взаимодействия фронта и бека без системного аналитика.
Но опять, в данном случаем мы хоть и получим реализацию, но потеряем в документации :(
Да, вот эти все ошибки и боли мы проходили. И продакт оунеры должны быть на груминге и тестировщики. Всё верно :) Изначально я и хотел описать полностью как выглядит этот всё дело, но в процессе написания статья получилась оооооооочень длинная. Решил что это будет издевательство на читателями )
Кстати, пока от всех не будет получен апрув - действительно не стоит брать в разработку ТЗ. Это золотое правило! Могут быть ограничения, но это крайне редкие случаи, и они обсуждаются индивидуально к каждой задаче.
Мир всегда делится на два типа "А" и "Б". Так и тут, кому-то понятно, кому-то сложнее будет. Рад слышать что текст понравился!
По поводу "Вотерфлоу" надеюсь это был вопрос с сарказмом про "Вотерфолл" :)
Кстати, интересная тема про "А как же быть без аналитика?" ? Надо будет попробовать написать про это ) Такой опыт тоже имеется в бардачке. А вот кровавое рубилово мы как раз исключили - об этом и повествует статья ;)
Хм... мне кажется я понял вашу мысль. В целом если бы назвать статью "Почему ТЗ и ныне там?" то выглядело бы гуд. Тогда можно было бы оперировать только тем, что речь идёт именно о техническом задании.
Я немного в растерянности, но "здравый смысл" - это полезная вещь, как бы это странно не звучало :) Возможно я не совсем понял ваш посыл. Расскажите подробнее?
Что касается по принятому формату, я об этом отдельно писал https://habr.com/ru/company/otkritie/blog/648155/ тут всё по полочкам... хотя этих "полочек" я бы добавил побольше, но боюсь что большие тексты тяжело читать.
US в этой статье и есть некий "воз" из басни Крылова. Она тут образно выражаясь так сказать.
Угу, всё верно. И аналитик плохо заТЗшил и разрабы ушли в самоволку )
Я бы немного похоливарил на тему джуны они или нет ;) Как я вижу градацию от джуна до синьора:
Джун - не знает что делать и не знает как делать
Мидл - не знает что делать, но знает как делать
Синьор - знает что делать и знает как делать
Тут все трое а-ля "молодцы" сами сделали задание :) Это что-то типа около Middle.
Так же я хотел показать что это специалисты характера - "Ой, я сам знаю как лучше". Поэтому они ни с кем не обсуждали своё решение (которое, согласен с вами, упустил аналитик).
Но суть не в этом, мне понравилось ваше замечание про то, что они прокачают других до такого же уровня (делай тяп-ляп). Подскажите пожалуйста где я оставил брешь в системе? Её нужно срочно залатать :D Очень не хотелось бы чтобы экспертиза участников тянулась вниз. Т.е. как по вашему мнению используя груминги и совместную работу над задачей они потянут за собой остальных?
А что касается про тестирование требований - я и так уже переживал что получился слишком лонгрид, надо было сокращать )
Справедливое замечание по поводу того что стиль изложения слегка, назовем это так, необычный :) Возьму на заметку - нужно будет упростить. Понимая это я и завершил статью подведением итогов. Но в любом случае я премного благодарен за двойное чтение. Так же буду рад если что-то из этого пригодится на практике.