[СММ-2024] Типы в голове

Вы удерживали в голове системность как многоуровневость и многоаспектность описания, но не требовали этого от коллег. В ходе разговора вы отслеживали, какие упоминались типы из мета-мета-модели, излагаемой в нашем курсе, но не называли эти типы вашим коллегам.

Второй или третий раз лид пытается запустить на общем синке с разработчиками одну задачку. И третий раз она не проходит. С самого начала непонятно, что надо сделать. Нам приносят некую потребность в “мониторинге состояния расчётного кластера”. Мониторинг хорошее слово, можно думать что угодно. Как разработчики мы пытаемся сузить спектр возможных решений. Первый вопрос - это технический мониторинг или бизнесовый? У нас же есть графана, графики, циферки. Т.е. мониторинг::доска с метриками есть. И добавить туда можно что угодно, вы скажите что. С бизнесовыми метриками вся сложность именно в том, чтобы вытащить из бизнеса, что они должны показывать. Какие выводы из них хотят делать? Начинаются разговоры, что как бы надо и то, и это. Формулировка в задаче примерно такая “мы хотим знать сколько и каких мероприятий рассчитывается в данный момент и какие ресурсы они потребляют”. Сколько и каких выглядит как список типов мероприятий с циферкой рядом. РЗП - 2, Отпуск - 4, Командировка - 12. Ресурсы уже интереснее. Память, проц? Тут уже будет хуже. Но я не буду сейчас моделировать технические проблемы. Там много вопросов. Расчёт мероприятия как событие, в расчётном кластере проходит через три сервиса, ресурсы у них разные. Но это мы делаем ход внутрь, а надо наружу. Целевая система какая, какая концепция использования? Просто информационное табло, как курсы валют. Вот тип, вот у него скачет цифра. Красиво? Красиво. Решение какое мы глядя на эти цифры принимаем? Никакое? Или мы такие “этот список с цифрами” показывает сколько наша система может одновременно переваривать мероприятий. Т.е. это пропускная способность, количество мероприятий в секунду/минуту? Но “в моменте” это нагрузка в моменте, сколько мы обработали (досчитали) можно посчитать на более длинном отрезке.

Ещё у табло бывает вторая функция: кажется всё перестало работать/замедлилось, объясните почему. Датчики показывают, что температура за окном близится к неприятным показателям (+42), пожалуй до 8ми вечера я туда выходить не буду. Ещё я краем уха слышала жалобы на “зависание”. Скорее всего интересует даже не “почему”, а “почините”. А доска с метриками это помощь в расследовании. Но мне кажется для расследования нужны какие-то совсем другие инструменты. Т.е. гипотеза “сейчас одновременно считается ЗП на большую фирму, и пачка командировок, поэтому всё медленно” не очень полезная. Во-первых, помимо расчётов в наши сервисы приходят за данными (интеграции, отчёты), и приходят загрузить данные. Это влияет на нагрузку “расчётного кластера”. Во-вторых, мы не в вакууме находимся, расчётный кластер::система взаимодействует с другими сервисами::системы в окружении (просит данные). Если на эти другие сервисы сейчас тоже идёт какая-то пиковая нагрузка, что будет с запросами? Они замедлятся, а в какой-то момент могут и отвалиться. Что это значит? Значит “мониторинг” должен быть и у соседей. Допустим, это понимают, решили с нас начать.

“Затык” с этой задачей сейчас для меня выглядит так. На просьбы пойти и выяснить “что нужно” лид не реагирует. Или забывает, или некогда, или не знаю что. Разработчики хотят “спецификацию”, что нужно, сколько вешать в граммах. Спецификацию не сделать пока нет концепции использования. Концепцию использования надо “выспросить” у внешних проектных ролей. Может они и не очень внешние, но у интересантов. Тех, кто страдает. Выяснить от чего они страдают и тогда уже думать про сигнальную панель или что-то другое (про аффордансы на решение проблемы). Где взять этих интересантов? Сходу у меня пара мыслей: 1) спросить у лида, кто принёс задачу, от кого “боль” 2) пофантазировать какие роли сталкиваются с проблемой “чот плохо работает, нам бы починить” и кого они видят в роли “ремонтной бригады”. Там наверно до ремонтной бригады, ещё “служба оповещения о проблемах” должна быть. Пользователи страдают → пошёл запрос в техподдержку → техподдержка передала в “службу слежения за приборами” → служба слежения определила где в пространстве предполагаемый источник проблем → служба вызывает ремонтные бригады ответственные за части, где вроде как находится проблема.

Главный вопрос: а мне это всё надо? Надо с точки зрения тренировки мышления. А так лид следующие две недели в отпуске. Пойти кого-то поискать я могу сама. Но не уверена, что хочу. Опять же разве что для тренировки.

2 лайка

:heart:

Интересно. Получается приходит задача “сделать графики”, а что почему и как - потерялось по пути от инициатора? “Сломанный телефон” какой-то.
Но кто-то же эту задачу поставил? Или просто какой-то топ как-то бросил, что “мониторинга не хватает”, а кто-то побежал этот самый мониторинг “делать”?

image

Тренировки да - точно нужны)) но сил и времени должно хватать сначала на порядок у себя, потом у всего что влияет на мои задачи (и далее по квалификациям)

2 лайка

“Испорченный телефон” – как раз детская игра, указывается как одна из причин, почему инженерию требований с аналитиками отменили. Прямо по учебнику )))

1 лайк

Вот это и есть “помочь окружающим” – оторвать задницу от стула и куда-то пойти (я обычно говорю, что системное мышление с этого начинается, “добыча недостающей информации”), а потом из режима практика (договорился, информацию добыл, свою работу сделал лучше) перейти в режим мастера – и подкахать процесс в той точке, которая как-то сбоит (скажем, воткнуть там в их issue tracker какой-то чеклист или изменить строчку в их регламенте, действуя неформальными уговорами), чтобы жизнь там стала чуть лучше и прилетало затем чуть поменьше. Прямо таки пойти и помочь. Собственно, мастер и отличается от практика, что практик всё время себе помогает, а мастер – помогает другим. Специалсит же никому не помогает, просто наблюдает – и всё-всё понимает! Вот ровно как в посте )))

1 лайк

Поход за информацией закончился неожиданно быстро. Попыталась выспросить концепцию использования в разговоре с архитектором::роль. Свои гипотезы предложила. Архитектор призвал руководителя разработки::должность. РР согласился, что информация о куске состояния системы, не покажет нам проблем по всей системе. И сам предположил, что нужно делать “платформенное решение”. После чего эпик уехал на ПМа (project manager) платформенной команды. Вроде как для дальнейшего размышления/обсуждения.

Не могу сказать, что это похоже на помощь окружающим. С одной стороны мы не стали делать “мутную” задачу, что неплохо. С другой стороны соседям я скорее подкинула работы.

2 лайка

Это помощь. Соседи вместо ожидания неосмысленной работы будут сами делать более осмысленную. Через некоторое время будет заметно, что появилась некоторая зона чуть большей осмысленности.

То, что все эти разговоры “заканчиваются неожиданно быстро” – это предусмотренный эффект. Все коммуникации резко (в разы и разы) ускоряются, а эффект более выраженный.

3 лайка