[МиС] Глава 2. Что значит быть собранным?

Посты студентов Рациональная работа
,
1

photo_2024-01-08_14-22-59
photo_2024-01-08_14-22-591280×731 101 KB

Мышление письмом при самостоятельном прохождении курса Моделирование и Собранность. Изучаю вторую главу.

Быть собранным это навести внимание на какую-то деятельность и удерживать его необходимое время.

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

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

Считаю, что мастрерство в прикладной собранности в достаточной степени у меня поставлено. Задачи закрываются, курсы проходятся, дела решаются. А вот с мастерством фундаментальной собранности есть явные проблемы. Как только нарастает давление внешней среды, собранность разваливается. Например, возникает объёмная задача с горящим дедлайном. Срок назначается без планирования, как реализовывать задачу мы знаем только верхнеуровнево. При реализации задачи постоянно над головой висит топор дедлайна. Решения по реализации принимаются по ходу. Мыслей о том, чтобы сесть и внимательно подумать о реализации, не возникает. Надо делать как получается, а то не успеем. Полноценного описания, как должно работать по бизнесу тоже нет, некогда. Может быть есть в голове у методолога. Можно считать, что просела командная собранность?

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

Насколько хорошо я управляю вниманием при работе с важными объектами по своей роли? Роль - инженер (разработчик ПО). Управляю по-разному. Если объект конкретен или объектов немного, то справляюсь. По существующим объектам проще думать. По тем которые мы выдумываем под задачу гораздо сложнее. Наверное потому что они ещё нигде толком не зафиксированы, а только гуляют у нас между говорящими головами. Сложно по многим объектам и связям между ними держать фокус.

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

Из описанных мною примеров, делаю вывод держать курс на развитие мастерства фундаментальной собранности.

Updated 08.01.2024

Пошла на курс с инструктором. Проблемы вижу в работе те же. Но кажется и ответ “чего нам не хватает”, начинаю видеть. Моделирования не хватает. И зафиксированных объектов.

5 лайков
2

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

1 лайк
3

Спасибо за комментарий! Мне кажется всё-таки в среднем пилот собранее программиста. Из-за двух вещей: 1) у него поставлены некие вполне физические навыки управления самолётом 2) цена ошибки высокая. У программиста нет ни реального мира, в котором нужно за чем-то следить, ни реальной угрозы. Точнее угроза есть чаще всего, но всё-таки расплата наступает где-то в будущем.

Соглашусь с вами насчёт процедур и правил в других отраслях. Но опять же возникает вопрос, а что в программировании процедур и правил за последние 50 лет никто не придумал? Придумали. Но снова вмешивается фактор абстрактности работы и не физичности рисков. Читала книгу А. Гаванде “Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям”. Был пример внедрения чек-листов в больницах, и там внедрение какой-то простой гигиенической процедуры перед операцией позволило сократь смертность пациентов на 40%. Вы понимаете, что уменьшение на такой дикий процент само по себе заставит следовать чек-листу не отступая. Не говоря уже о том, сколько они денег сэкономили. Я пока не могу придумать, как померить такую же корреляцию внедрения процедур в программировании. Чтобы не знаю, повышение покрытия тестами на 10% процентов критичных для бизнеса мест, уронило процент багов на 30% и сэкономило сколько-то человеко-дней… Причём мне кажется самые эффективные процедуры находятся в ментальном (а значит абстрактном для заказчика) поле. Например, сколько я сэкономлю багов, если не буду впадать панику, когда ко мне приходит менеджер с горящей проблемой на проде? Если даже срочную задачу буду делать размеренно, требуя и от коллег полноценного обдумывания алгоритма на уровне бизнеса?

2 лайка
4

Вы же сами в крайнем абзаце назвали ключевое отличие разработки софта от авиации :slight_smile: Эффективные процедуры. Аналог описанной Вами “горящей проблемы на проде”, это, я не знаю, “Дельта 364, это Шереметьево Вышка, борт порядок? Отлично! Спешу обрадовать, вместо Лондона вы летите в Пекин!” )) Прилагается масса усилий к тому чтобы таких ситуаций НЕ происходило. Авиация любит шаблоны, и именно по этой причине :slight_smile: Вы спросите, что же делать чтобы не происходило горящих ситуаций на проде? Тут уже вопрос не к собранности пилотов, а к квалификации менеджеров и продакт овнеров. Скрам мастеров as is полно, а вот эффективные процедуры выстроить мало кто способен, тут масса других качеств надо, а не только фреймворк изучить - от стальных яиц до способности управлять людьми. Потому продолжаю придерживаться мнения о том, что пилот не собраннее в целом, а собраннее в нужные моменты. Посадите кодера в те же условия (ну ок, не в те же, но тождественные) - объясните ему, что за баг на стейджинге он лишается премии, а баг на проде означает “лишение пилотского” - и поверьте, он будет “следовать чеклистам”. Точно так же и пилот, заняв эшелон, может себе позволить поднять голову от FMS и выпить кофе, и самолет не упадет :slight_smile:

5

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

6

Наталья, спасибо за пост! Отлично получилось)
Интересные вопросы подняты в посте)

“На созвоны врываются люди со своими вопросами” – это однозначная проблема с командной собранностью. Фактически описана ситуация, когда аварийный канал связи задействуется в “нормальном” режиме. Такое, конечно, надо пресекать. На вопросы по заданию можно ответить асинхронно, или во время соответствующей встречи, или назначить “консультационный час”. Но никак не "прерывать чужие встречи для обычных вопросов (не адского форс-мажора, который не может подождать 2 ч).

Если часто возникают объемные задачи с горящим дедлайном, то это на 80-90% проблемы с планированием (в 10-20% случаев команда работает с госорганами, и “внезапные объемные задачи с горящими дедлайнами” в этом случае часть “операционной модели”, они неизбежны).
Но тут еще надо учитывать, что именно за “неучтенка” у вас. Если вы не учли не особенно критические граничные условия и потом дорабатываете, это одно. Если регулярно не учитываются граничные единичные, но важные случаи, то другое. Скажем, если возникло 10 не очень критичных багов на не критическом сценарии пользователя, то это можно списать на то, что все не предусмотришь. Но если баги регулярно вылезают на критических пользовательских сценариях и в количестве, то явно тут проблема.
Плюс надо учитывать, что вам тут важнее: “скорость” или “точность” – с точки зрения конечного результата для клиента. Если важнее “сделать хоть как-то” – значит, делаем без проработки / подготовки. Если важнее “уменьшить брак” – то добавляем подготовку.

На самом деле есть подход TameFlow (постголдраттовская теория ограничений для знаниевых проектов, причем демонстрируется на разработке). И там описывается возможность прогнозировать сроки завершения работ с 80% точностью. Но для этого требуется таки хорошая предварительная проработка задач / кейсов, которые берутся в работу.
А чтобы было время на предварительную проработку, нужно, чтобы самих задач, одновременно висящих, не было очень уж много. А проект на команде вообще желательно один чтобы висел)
И тогда у вас будет возможность сосредоточиться на качественном выполнении небольшого числа задач и проектов. А еще – на их стандартизацию. То есть у вас будет больше времени на аудит действий и решений команды, на выявление типовых ошибок на ранней стадии и на внедрение изменений для того, чтобы минимизировать ошибки.

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

Фокус на развитии фундаментальной собранности – это хорошо! На тренинге 3 еще поговорим о том, как фундаментальные принципы применять в работе.

3 лайка
7

Вообще собранность – характеристика агента, не роли. Так что вопрос про “кто собраннее – пилот или кодер” в принципе не имеет смысла обсуждать)

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

3 лайка
8

дошел до слов “дрессировка пилотов” - заплакал горько :slight_smile:
все так. на каждом этапе выполнения полета - в фокусе именно то что должно быть в фокусе именно в этот момент. если важных параметров несколько - дрессируют (зачеркнуто) учат распределять и переносить внимание между ними, чтобы не упустить ничего важного. получаются такие, забавные заклинания (“скольжение-вариометр-скорость, скольжение-вариометр-скорость-крен…”)

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

9

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

Спасибо))

10

(плачет еще сильнее) я знаю :slight_smile:

11

Я поняла))))))

Можно заменить на (полит)корректное “вышкаливают”))

12

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

1 лайк
13

Спасибо на комментарий!

Сейчас к чему-то подобному пришла. Смирилась с тем, что в начале цепочки постановки задач люди забывают/не успевают “остановиться и подумать”. Значит я уточняю описание, когда задача приходит ко мне. Лучше поздно, чем никогда)

1 лайк
14

“Моделирования не хватает. И зафиксированных объектов” – да, “если не знаешь, на чём остановить внимание, оно и не остановится”. Надо знать и ещё записать. Только лучше не “зафиксированные” объекты иметь, а документированные. Ибо “фиксирование” не подразумевает изменений, а изменения будут всегда. Документирование – это не фиксация, а описание. Если вдруг объект не тот, просто меняем модель, отражаем в документе. Не надо гвоздями прибивать )))

В последующих курсах будет подробно объясняться, что именно там моделировать, чтобы не изобретать каждый раз велосипед.

1 лайк