[МиС-2024] Глава 1. Онтологическая работа

Мышление письмом по работе с первой главой.

Запишите для себя время, которое вам потребовалось, чтобы описать простейшим образом вашу предметную область. Запишите свои впечатления, что было трудно, что легко?

Потребовалось 1 час 30 минут. Описывала не очень подробно. Я по роли разработчик ПО. Наш отдел отвечает за разработку блока расчётов заработной платы. И чаще всего я работаю с объектами выделенными кем-то другим. Кем-то с постфиксом “аналитик”. Описывала объекты и отношения предметной области, так как я их сейчас понимаю. Попыталась расписать объекты и отношения из новой большой задачи.

Работать с чужими моделями особенно новыми и более сложными, чем привычные - трудно.

В прошлом посте выяснили, что на работе у меня много проблем в коммуникации. Делаю предположение, что эти проблемы решаются в том числе мастерством моделирования.

Когда мы говорим про моделирование как дисциплину, мы имеем в виду вместе онтологию и логику (поэтому иногда можем вместо «моделирование» говорить «онтологика»). Онтология — это область знания про то, какие в мире есть объекты и отношения, а логика — про то, какие можно с ними делать операции и как осуществлять вывод, проводить рассуждения.

Стали ещё сильнее раздражать чужие описания (задач, багов). Пытаюсь внимательнее смотреть на объекты, отношения и операции. И всё больше убеждаюсь, что шутка, не такая уж и шутка.

Точнее мы говорим то, об одном и том же. Но договариваемся так себе.

У меня есть одна старая неудовлетворённость. Вот у нас есть две роли: разработчик и аналитик. Мы разрабатываем (изменяем) систему и всплывает очередная “недоработка”. Какова природа этой недоработки? Мы непрерывно делаем новый функционал, у нас “гибкие технологии”, т.е. очередная версия едет не будучи идеально сделанной. Достаточно часто, ради поставки некий функционал урезается. Вот это сделали, катим, а это - доделаем в следующий раз. Мне кажется, что мы все в курсе “парадигмы” ведения работ. Так вот, недоработка - это то, о чём мы скорее всего в прошлый раз договорились “пока не делать” или даже просто забыли спроектировать. Но когда у нас был методолог или когда с чем-то горящим приходит продукт овнер, работает история “сейчас делаем кусок и достаточно”. А когда через длительное время находит недоделанное бизнес-аналитик нашей команды, начинается. Недоработка объявляется багом (дефектом). Хотя на мой взгляд это как раз должно превратиться в задачу (доработку). И даже когда объясняешь, почему это не баг, тебя не хотят слушать. “Ну не работает же”. Ну чайник по небу тоже не летает, и что, это тоже баг? Обычно я устаю про это разговаривать и сдаюсь. Сейчас дребезг возобновился с новой силой.

Но это больше организационные разборки. А есть вполне прагматичные ошибки в описаниях. Написано “запрос” там где должен быть “ответ”. Попытки указать на то, что “по задаче параметр deleted_at должен передаваться”. Хотя я написала, что не передаются “записи с параметром deleted_at=null”. Параметр итак передаётся. Т.е. по-человечески в отчёте попросили добавить вывод атрибута deleted_at (это дата удаления записи). Я написала, что сейчас в отчёт не попадают удаленные записи (deleted_at != null). Мне отвечают про параметр, а не про записи. Поплыла модель? Ещё раз объяснила. Нет, баг принесли с такой же формулировкой “в отчёт с бэка не передаётся параметр deleted_at”. Можно было отклонить задачу с комментарием “параметр передаётся, (глаза протрите), а описание не отражает суть проблемы”. Но не стала. Поправила описание сама. Надо было его править? Мне для понимания оно не нужно. Но подумала, что если когда-то кто-то к ней вернётся, суть он не поймёт. По коду поймёт, а по задаче нет. Пусть будет везде нормально. Мало нам нечетких описаний от аналитиков.

Есть ещё с другого уровня ошибка. Непонимание за какую часть какие разработчики отвечают. Например, у нас задача поправить отображение в пользовательском интерфейсе. Задача на фронтенд. Но если там поломана логика, как в примере выше. То должна быть задача и на бекенд. Или наоборот “не работает” бекенд, а в описании до кучи написаны проблемы с запросами с фронтенда. Модели нету в голове, как работает. Мне странно в этом случае одно. Если ты не понимаешь, приди спроси. Это так сложно, спросить? Или сложно признать, что не понимаешь?

1 лайк

Иногда бывает что кто-то хочет свою задницу прикрыть объявляя это багом и спихивает на разработку типа «они недоработали»(

По идее у кого-то неверная модель? Они ожидают что null параметры тоже будут выведены?

Так же возможно, что человек не. понимает, что он не понимает. Не раз встречал такое «понимание» со стороны продактов. Для них есть фронтенд и все, в их картине мира все происходло на фронтенде.

1 лайк

Да. Но почему такие ожидания возникли. Потому что в голове какая-то своя модель. Мы делали этот отчёт с другим человеком, и договорённость не выводить удалённые записи была устной. Но тут тоже вопрос, надо было описание в задаче переписать (в той старой). Но все задачи не перепишешь. Эта правка могла же и отдельно заехать.

Вот поэтому часто проще забить на попытки объяснять(

1 лайк

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

1 лайк

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

1 лайк

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

Вы уже умеете осознанно собирать себя - выделять роль, объекты, практики. Постарайтесь заметить, а собран ли собеседник? В какой он роли? Какие у него объекты? Как он их называет? (“Моделирование, привет!”)

Вот вы и заметили главное… Здесь мы уже переходим к коммуникативной части, это материал другого семестра. Модель там в голове есть, иначе бы вообще ничего не было, ни фронта, ни бека =) Попробуйте разведать, какая же там все-таки модель =)

1 лайк