Мышление письмом при самостоятельном прохождении курса Моделирование и Собранность. Изучаю вторую главу.
Быть собранным это навести внимание на какую-то деятельность и удерживать его необходимое время.
Например, коллега просит поревьювить его код. Я сначала навожу внимание на суть задачи, потом на реализацию. Во время ревью моя задача понять как решена конкретная задача, будет ли это работать, подумать какие могут быть подводные камни и проследить за стилем кода, который не покрывают автоматические проверки в пайплане.
Собранность это когда внимание чётко направлено и не отвлекаешься. В случае ревью, у нас созвон на двух человек: автор и ревьювер. На такие созвоны периодически врываются какие-то люди со своими вопросами. Лучше прятаться в комнату, куда больше двух человек не может зайти. Либо учить коллег получать ответы на свои вопросы асинхронно.
Считаю, что мастрерство в прикладной собранности в достаточной степени у меня поставлено. Задачи закрываются, курсы проходятся, дела решаются. А вот с мастерством фундаментальной собранности есть явные проблемы. Как только нарастает давление внешней среды, собранность разваливается. Например, возникает объёмная задача с горящим дедлайном. Срок назначается без планирования, как реализовывать задачу мы знаем только верхнеуровнево. При реализации задачи постоянно над головой висит топор дедлайна. Решения по реализации принимаются по ходу. Мыслей о том, чтобы сесть и внимательно подумать о реализации, не возникает. Надо делать как получается, а то не успеем. Полноценного описания, как должно работать по бизнесу тоже нет, некогда. Может быть есть в голове у методолога. Можно считать, что просела командная собранность?
В таких условиях задача реализуется и часто даже в срок. Но через время выясняется, что некие граничные условия не были учтены. И по ним наше решение работает неправильно. Я если честно, сейчас не понимаю является ли такая неучтёнка следствием исключительно работы в формате загнанных лошадей. Если бы у всех членов команды, было прокачано мастерство фундаментальной собранности, мы бы ничего не потеряли по дороге? Или дело не только в собранности, а нам ещё не хватает мастерства мышления, чтобы понимать на ранних этапах какие возможны ошибки?
Насколько хорошо я управляю вниманием при работе с важными объектами по своей роли? Роль - инженер (разработчик ПО). Управляю по-разному. Если объект конкретен или объектов немного, то справляюсь. По существующим объектам проще думать. По тем которые мы выдумываем под задачу гораздо сложнее. Наверное потому что они ещё нигде толком не зафиксированы, а только гуляют у нас между говорящими головами. Сложно по многим объектам и связям между ними держать фокус.
О том, что собранность может быть развита лучше, я делаю вывод, исходя из факта существования сложных систем. Как-то самолёты летают и не так часто падают. Не разрушаются высотные здания сразу после постройки и ещё довольно долго. Т.е. количество ошибок, которые совершаются при проектировании и реализации проекта могут быть сведены к минимуму. В ИТ часто это кажется почти не достижимой мечтой.
Из описанных мною примеров, делаю вывод держать курс на развитие мастерства фундаментальной собранности.
Updated 08.01.2024
Пошла на курс с инструктором. Проблемы вижу в работе те же. Но кажется и ответ “чего нам не хватает”, начинаю видеть. Моделирования не хватает. И зафиксированных объектов.
Эффективные процедуры. Аналог описанной Вами “горящей проблемы на проде”, это, я не знаю, “Дельта 364, это Шереметьево Вышка, борт порядок? Отлично! Спешу обрадовать, вместо Лондона вы летите в Пекин!” )) Прилагается масса усилий к тому чтобы таких ситуаций НЕ происходило. Авиация любит шаблоны, и именно по этой причине