Написан пост о представлениях метода работы по материалу первого раздела. Что так и осталось непонятным? Что оказалось контринтуитивным?
Мышление письмом по первому разделу курса “Методология”.
На данный момент, я примирилась со знанием “если вы что-то делаете, то вы это делаете по какому-то методу”. Даже если вы про этот метод не думали никогда и кажется что это что-то простое. Когда проходили СМ было некоторое сопротивление, в голове я как-то “метод” воспринимала более серьёзно что ли. Мне казалось, что да это проявление цивилизации. И у мальчика из джунглей, у него какие могут быть методы? Он просто живёт. Как-то добывает еду, ходит, бегает и т.д. Но на самом деле за любым привычным действием стоят какие-то знания. Эти знания нам чаще всего кто-то передал через обучение. Реже этот кто-то это мы сами. И мальчик из джунглей бегает вполне определённым методом, мальчик в школе на физкультуре в 5м классе бегает другим методом, а выросший мальчик на соревнованиях по бегу мирового уровня бегает третьим методом. И это удивительно логично. Как это можно было отрицать)
А дальше всё плохо. Потому что я ещё в начале СМ заметила, что особо никто не думает, как делать. И получила на это подтверждение.
А пару дней назад подумала, а как мы способы решения выбираем коллективно. Например, у нас возникла потребность уменьшить объем хранимых данных. Во многих таблицах в БД перемешаны актуальные и неактуальные данные. Неактуальные данные бывают двух типов: expired (это некие прошлые попытки) и deleted (помеченные как удалённые). Изначально с бизнесом была договорённость ничего не удалять физически. И вот теперь задумались о необходимости механизма удаления/архивирования неактуальных данных. Это техническое решение на уровне команды. Каким способом оно принимается? Собирается вся команда в созвон, вслух предлагаются конструктивы решения. В этих конструктивах возникают новые вопросы. Например, можно делать механизм на уровне кода, а можно на уровне БД. Где этот механизм будет располагаться во времени. Мы сразу после бизнес события пытаемся пачку неактуальных данных спрятать/переместить, или делаем это фоном время от времени. И тут же вопрос размещения, а куда и каким именно образом эта пачка должна деться? В другую таблицу, в другую партицию таблицы, или просто пометки надо проставить, а физически перемещать потом. Вот мы общими усилиями нагенерировали конструктивы решения на уровне кода. На уровне БД застопорились тем, что это надо же к девопсам или ДБА сходить проконсультироваться. “За” и “против” у каждого варианта решения все примерно представляют. И дальше голосование с небольшим обоснованием.
Что в таком методе плохо? Да много всего. И форме и по содержанию. По форме - варианты решений вполне можно подготовить заранее. Потому что какими бы мы ни были классными разработчиками, получается что источник данных это 10 человек, с их личным опытом (которого по этой теме может просто не быть) и информацией уровня “слышал где-то, читал где-то, что-то помню”. Хотя одна удивительно простая мысль “всё уже придумано до нас” позволяет очень сильно расширить выбор способов решения проблемы. Для меня первый этап захода на такой выбор, это “провести поиск/исследование”. Собрать данные: варианты, направления, обоснования. И потом можно совместно покритиковать варианты, выбрать направление, сходить уточнить. Но когда я предлагала это в виде “давайте сделаем задачу на R&D”, в ответ получила критику. Что задачу будет делать один человек и так мы проигнорируем опыт и экспертизу команды. А ещё этот человек может застрять с исследованием, потратить кучу времени и принести непонятно что. А если мы сначала обсудим все вместе, выберем “направление” то потом можно будет и задачу на исследование дать. Но так как выбираем мы по итогу на глаз, человеку прилетает плохо описанная задача, из которой вообще непонятно что делать: реализацию или всё-таки исследование. И время он точно так же тратит, а результата нет.
Что вам удалось уже применить в рабочих проектах?
Было продолжение попыток починки интерфейса на этой неделе. Я дописала чеклист и забрала инструкцию к нам в раздел документации. На общем созвоне рассказала почему соседи хорошие, но занятые парни и какой у нас с ними интерфейс взаимодействия. Действия все показала, но это не “прошла по чеклисту за ручку”. Пойдут они в итоге сами. Обращаться ко мне с вопросами предложила. Но следить за всеми явно не смогу. Забавно, что инструкция со сроками и прочими предупреждениями лежит в корне в их (соседском) разделе таск-трекера. Но на глаза она мне попалась только когда я пошла свою задачу проталкивать. Наверно надо на очередном синке ещё раз показать инструкцию и у них, и у нас, вдруг визуально хоть как-то отпечатается.
Много вопросов по методам подготовки задач/работ. Набор людей в цепочке передачи информации до разработчика разный и везде свои грабли. Не покидает меня наблюдение, что очень часто “людей не научили”. Работа получается не рациональная. Непонятно пока что с этим делать. Т.е. в цепочках где работа идёт до меня, я могу встать в начало. Мы про это тоже вроде уже сто раз говорили с ребятами. Нужна приёмка на уровне описания работы. Но сейчас я подумала, что описание работы это тоже кусочек. Нужно ещё понимание “а что же мы делаем целиком всем этим эпиком”, концепция использования опять. Проблематика не уровня задачи, а уровнем выше. Потому что описание задачи можно докрутить, а итоговый результат всё равно провалится. Рационально работать сложно, нужно искать важные объекты и связи, а потом их по всем этапам не терять. И как-то нет человека, на которого можно положиться, что он эти объекты выделит и не забудет про них. И тут у меня сейчас ощущение перевернутой лестницы. На прошлом созвоне обсуждали, что смысл СМ в том, чтобы не пытаться прыгнуть через ступеньку. Сначала целевая система. А тут у нас по ролям информация спускается сверху, а решение/изобретение должно быть сделано в самом низу (инженером). Проблема аналитики и испорченного телефона перед глазами становится всё более выпуклой. Ждём третий семестр. Мне кажется мы на своей лестнице ещё менеджеров куда-то потеряли или они спрятались, а я не вижу. Нет обеспечения прохождения работ, всё время пороги какие-то горные. Там споткнулся, тут застрял, стой там, иди сюда.
