[МиС-2024] Глава 6. Описания

Посты студентов Моделирование и Собранность
,
1

photo_2024-02-16_14-33-45
photo_2024-02-16_14-33-451280×731 131 KB

Понаблюдайте за своими коммуникациями на работе — где вам не хватает инструкций по интерпретации или разделенного с коллегами мета-языка?

Как я написала в комменте к посту с коммуникацями на работе происходит следущее:

Раньше у меня было по умолчанию доверие к словам собеседника. А сейчас скорее недоверие. В том смысле, что я приняла, что по умолчанию люди не очень думают разделяет ли собеседник с ними контекст и язык. А значит любое описание в 90% случаев нужно уточнять. И когда сама пишу для другого человека или говорю, пытаюсь заранее подумать, а будет ли это ему понятно.

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

С багами свежая проблема. У бага есть шаблон описания: предусловия, сценарий воспроизведения, текущее поведение, ожидаемое поведение. Как будто достаточно понятный шаблон. Заполни вот так, сделай такие действия, получи неправильный результат, а мы хотим правильный, почините пожалуйста. Всё по делу, толку никакого. Почему здесь нужна инструкция по интерпретации? Или возможно язык “общих фраз” мало подходит для решения коммуникативной задачи передать баг так, чтобы его разработчик смог починить. В простом текстовом описании недостаточно данных для разработчика.

Тут спрятана техническая проблема: среды эксплуатации не идентичны. Т.е. если у меня есть дев стенд, где мы ведём разработку и тестируем фичи в первую очередь. На нём тестовые данные, на нём слабее железо, на нём данных в разы меньше. И есть прод, на котором данные реальные, нагрузка совсем другая. Но доступа к проду и к чувствительным данным у нас нет. Получается, что человек заводящий баг и человек, которому этот баг назначат находятся в разных контекстах. Инструкция по интерпретации сводится к тому, чтобы дополнить описание “данными из контекста”: найти ошибку в логах, приложить логи, посмотреть графики долгих ответов, приложить картинку с этих графиков (потому что завтра график уже уедет от проблемной ситуации, он же в 4D) и т.д.

Обсудила с лидом тестировщиков, как так получается. Сказал, что доносил это до тестировщиков, но ещё с конкретными людьми поговорит дополнительно. Я видела что-то в багах, сам переоформил. С задачами похожие истории, но “недоверие по умолчанию” нормально работает. Попросила завести для задач состояние “Ready for development”, которое будет означать, что аналитик подготовил достаточное описание. Если он считает, что подготовил, а по факту описание так себе, задачу можно будет ему вернуть на доработку описания. Сейчас статуса подходящего для доработки именно описания нет и путаница возникает.

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

Временами не хватает инструкции по интерпретации сообщий от коллег в мессенджерах. Эти расхожие “есть 5 минут”. Задаём уточняющие вопросы. Постепенно люди учатся. Либо просто принимают, что я зануда, буду выяснять сначала, что надо. Только потом делать.

3 лайка
2

Всегда удивлялся, почему цикл “написал-прочитал” считается полным/обрывается для информационного обмена как вот тут в “баг-репортах” или например в тех же “постановках задач”.

И каждый раз третьим шагом цикла - “война”, “наказания”, “жесткость дисциплины”.

Третий шаг это же “подтверждение” - никого не надо убивать и наказывать. Нужно вежливо пройти цикл “а правильно ли я вас понял, пожалуйста уточните”. Тут конечно проблема, чтоб не на отшибись, не через cntrl c/v чтоб банально широту пропускания понимания повысить, иначе никакая емкость “мета-языка” не спасет.

“Там оно не этосамое, я же скриншот прислал” (с) из любимого.

3

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

В случае описания задач можно сказать: да и пофигу. Т.е. окей, я принимаю, что валидация на моей стороне, я не могу верить аналитику. Опять же было бы попроще тогда, проводить эту валидацию сразу после написания. Потому что та же самая петля. Человек написал и ушёл делать дальше другие свои задачи. Я взяла это описание и прочитала его на другой день, не поняла. Вытаскиваю человека из его текущих задач, он сидит восстанавливает контекст в голове, потом пытается мне объяснить. Если я найду какой-то косяк, на который он с ходу не сможет ответить. Мы уйдём ещё на подумать. Я тоже выброшу из головы контекст, пойду делать другие задачи. Это очень всё медленно и грустно. В этом смысле проще “заготовку” писать одному, а на уточнение сразу звать заинтересованных и собирать вопросы/косяки сразу. И расходиться.

Я же с кодом, который тоже описание, не пропускаю валидацию. Я понимаю, что прежде чем отдать свою писанину на валидацию тестировщику, мне нужно проверить её самой. Т.е. мне надо написать тесты, мне надо показать это таким же как я, разработчикам (потому что вполне возможно глаз замылился), мне надо пойти и запустить это самой. Только когда все эти этапы валидации я провела, я могу отдать это другому человека на “подтверждение”. Т.е. понятие о том, что если тебе возвращают задачу в correcting много раз подряд, то ты так себе сделал свою работу, для разработчиков есть. А для других поставщиков описаний почему-то нет.

3 лайка
4

Спасибо за развернутый ответ.

Я предлагаю посмотреть на это именно через свойства “мета-языка” - это то что вы назвали “недоверием к собеседнику”.

Меня учили в “баг-репорты” и в “постановку задач в график ганта” :slight_smile:
Однако ДО этого меня учили в “журнал вызовов”, “журнал неисправностей”, “наряд на работы”.

Цикл “описал баг - прочитал баг” - конечно не окончен, но как вы верно отмечаете после него начинается “немножко война”.

Вы предлагаете для исправления ситуации неможко вернуться и повысить квалификацию генератора первого шага, чтобы он лучше владел языком и этим языком донес больше-лучше. А давайте на это посмотрим попристальней - а можем ли мы вообще так ставить вопрос? Насколько высокой должна быть квалификация этого самого первого, что бы он смог не просто “показать пальцем”, а вот прямо взять и написать такое, что бы “валидация” с “интерпретацией” были ненужны больше?

Мне с “журналом вызовов” значительно более понятно было - вызов это простой малоинформационный сигнал, иногда вообще тупо триггер - “на обьекте сработал датчик задымления/протечки, код датчика 34572, время срабатывания 18.26 - вызов приняла Маша Сидорова - вызов передан Иванову пожарная часть 2234 (для датчика задымления)/ сантехнику Петрову ДЭЗ-17 (для датчика протечки)” - и всё!!! - триггер не включая мозг - обозначил 4-Д обьект с проблемой - рабочий продукт этапа “написал/сообщил” не требует суперквалификации - указание на объект в реальном мире и возможный (sic!) характер проблемы/неисправности. Да, “недоверие” заложено прямо в процесс и должно идти по процессу. Ни о какой “валидации”, “интерпретации” речи не идет на этапе “написал/сообщил” - естественное требование к этапу “написал/сообщил” скорость, но не “валидированность”. Повышение требований в сторону “первоначальный сигнал должен включать валидацию” - рубанет скорость, построение системы реагирования неможко разваливается, задержки на валидацию/интерпретацию могут быть огромны, по сравнению со временем не очень обученного (но и не идиота) триггера/датчика. Посадить вместо дешевого датчика двух супер экспертов по пожарам и водопроводным системам мы не можем, это нам еще повезло, если у нас такой есть хоть один в поле зрения вообще. Я к тому, что лид-тестировщиков сколько бы не говорил со своими тестировщиками (которые по большей части “мне научрук диплом выдал - я инженер” извините-больное место тут), проведения валиадции/интерпретации для “указать на проблему” получить не сможет, а то чего нет никаким языком выразить ну не получится.

Итак на второй этап “прочитал” приходит триггерный сигнал с указанием на 4-Д объект (который кстати для случая с кодом вообще не объект) и намеком на квалификацию требуемую для превращения простого сигнала с задачу. Вот тут да уже можно поговорить о том какому академику мы можем позвонить - как раз для валидации/интерпретации проблемы и возможных (sic! - опять “недоверие” оно с нами оно заложено в систему реагирования) вариантов путей решения проблемы. И да, если академику придется ехать на объект, просить фото/видео, выдергивать Машу Сидорову для спросить “какого цвета лампочка и как моргала” - то да поскольку только здесь у нас есть доступ к квалификации которая понимает что спросить - мы решим что быстрее-понятнее-дешевле Машу отвезти к академику или академика везти на объект, который уже не обьект, потому что лампочка уже не мигает. Рабочий продукт этапа “прочитал” - как раз и есть квалифицированно описанная верифицированная/интепретированная проблема, но еще не решение проблемы. А еще может случится, что даже академик не сможет понять почему “лампочка моргала”, т.е. верификация с интерпретацией могут тупо вообще не произойти, никогда в отношении данного вызова или произойти не от академика, а случайно по классике “уборщица штепсель вынула”.

Дальше этап “подтверждение” - подтверждаться должна задача по устранению, т.е. “горит - тушим одним ведром или вызываем все пожарные расчеты на 100 км вокруг”. Для случая с кодом обычно выбор между - сносим все накатываем рабочий бекап или инженерам, пусть переписывают кривую функцию/реализацию. Рабочий продукт “подтверждения” - выбор инженерного решения для решения проблемы и тут может быть понадобится включение даже не одного академика, а даже нескольких и из разных сфер - чтобы заплатку на крышу здания прилепить нужен крышолог, а вот чтоб перестать лепить заплатки и перейти к заменам крыш вообще нужен экономист в плюс к крышологу.

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

Так :slight_smile: о сути процессов мне очень интересно, но то “что сказать” это не про мета-язык. Мета язык, это про то, что бы и Маша Сидорова (для свой квалификации), сантехник, академик и инженер - не спрашивали “а что такое датчик 34572”? что бы время не перевод терминологии операционных объектов, имен технологий и выясненение является академик по китам спецом еще и по котам не терялось.

Если интересно то про влияние реагирующих-контрольных систем на работу системы в целом и поиски багов есть рассказ Станислава Лема “Ананке” - он не большой, программное чтение я считаю для понимания реализации контрольных-реагирующих систем :slight_smile:

1 лайк
5

Я вот сразу как-то не отдал должное этой мысли, но покрутив ее несколько дней в голове прям проникся. Одно из проявлений этого проникновения - мне в общих чатах(где много людей, а не узкие ламповые, где мы на своей волне) стало еще меньше хотеться что-то писать/комментировать.
Цепочка такая: с большой долей вероятности у нас оочень разные контексты, раньше я бы тут кинул одну-две фразы, но одной-двух фраз почти наверняка будет недостаточно ибо я или подожгу человеку или потом потрачу пол-часа на прояснение, да ну нафиг, не стоит оно того.

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

Offtop

Вспомнил просто шикарный недавний диалог с одним челом. Сижу я значит на oncall-е, не тужу, собираюсь спать идти. И тут прилетает на пейджер P1-тикет(priority-1 - самое срочное, критически важный функционал не работает, брось все и почини. Т.е. если ты спишь - ты просыпаешься и чинишь, если не можешь сам починить - будишь остальных людей которые тебе могу помочь, если не выходит - эскалируешь вплоть до директора подразделения). И в тикете расписано, что такая-то фича не работает. Я перечитал несколько раз, офигеваю с каждым прочитанным разом ибо У НАС НЕТ ЭТОЙ ФУНКЦИИ!!!. Закрываю тикет с комментом, я написал вежливо но суть такова: “бла бла, такой функции у нас нет, это не P1 от слова вообще, почитайте инструкцию как пользоваться нашим продуктом, вот ссылка, бла бла”.

Его ответ: “ну, если я не могу для кастомера сделать то, что ему нужно, имхо, это P1”

Мое лицо в этот момент:
image

И вот когда я остыл, я прям подумал: “а ведь в его картине мира, все отлично, он вообще не видит проблемы”.

Насколько в тот момент мы двое на совершенно разных языках говорили. Тогда у меня знатно пригорело от этой ситуации. Сейчас, смотря сквозь призму частично-пройденного курса МиС я смотрю совершенно по-другому

1 лайк
6

Хаха. Это уже можно в мемы про типичные будни айтишника писать. Classic)

Мы точно так же с бизнес-аналитиками общаемся. Тебе говорят “не работает”, ты им “но мы же этого не делали”, а тебе - “но для клиента же это не работает”. И трудно поспорить. В этой истории самое забавное, у меня подозрение, что когда клиенту продают программное решение, которое мы делаем, ему никто не пишет инструкцию на 500 листов о том, чего у нас нет. Но в то же время, чтобы меньше про это плакать/смеяться я держу в голове идею “вечной бета-версии”. Сейчас нету, со временем будет. Наврали мы таким образом? Не знаю. Довольно часто оказывается, что потребность в какой-то штуке возникает только тогда, когда об неё конкретный человек споткнётся.

Я когда-то работала на интеграциях коробочной версии CRM. И там история такая: может отдел интеграций напильником на стороне клиента допилить - хорошо. Не может - тогда собираем хотелки клиента. Если эти хотелки есть ещё у каких-то клиентов и эти клиенты достаточно большие - будут допиливать коробку. Если это мало кто хочет или они не очень большие - sorry, допиливать не будут.

Я тебя понимаю. Но если перепрыгнуть в роль маркетинга/продажника, то “несите деньги, всё сделаем”. С приоритетами тоже много весёлого. Как раз про эпистимический статус. А когда там написано “критичный приоритет” насколько я этому верю? А должна ли вообще верить? Обработать скорее всего должна. Но очень часто это “волки, волки, спасайся кто может”. А волков-то и нет. Они нарисованные в голове, у того кто заводил баг.

1 лайк
7

Хорошее замечание. Я с какой-то грустью стала смотреть на километровые переписки в айтишных чатах в стиле “ты меня не понял, нет, это ты меня не понял”. И не смотря на все попытки “прояснить термины” заканчивается взаимным неудовольствием.

1 лайк