Непонятная Мантра элегантности в работе

Опять скатился в какой-то аврал бесконечной работы на этой неделе.
Пишу, чтобы мантра стала применяться мной, а значит стала понятной.
Разбираюсь что происходит со мной по пунктам:

  1. Прекратили делать ненужное
    Что делаю ненужное?
    Заметил, что за неделю три раза не контролировал то, как я проваливаюсь в обсуждение или споры по какой-то теме на встречах, потом стыдно за то, что забрал у людей время.
    Веду себя как суетливая обезьянка, которая считает себя очень умной. самому смешно щас))
    Почему: Я перегружаю мозг многозадачностью, устаю за день сильно.
    Я впринципе часто сильно увлекаюсь каким-то обсуждением или задачей, даже если это на самом деле можно сделать позже или делегировать или не делать.
    И вот это вроде нужное, но можно было бы не вовлекаться и подумать потом, но я это не контролирую.
    А что реально было ненужное из этого? непонятно.
    И отследить все это в моменте, записать все это и оттрекать по времени в тасктрекер я забываю.

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

  1. Начали отслеживать все задачи и проекты в экзокортексе
    Я почти все успеваю заносить по рабочим проектам, что не занесли другие люди.
    При этом не успеваю понять по всем задачам, а что надо сделать в этой задаче в действительности.
    Потому что чтобы понять и приоритезировать сложные штуки в работе надо провести шаги анализа: а что там за проблема, а какая метрика за этим стоит, как проблема на неё влияет, а решение вообще решит проблему или нет и на сколько. А если надо другое решение, то какое? И часть информации надо получать через коммуникацию, это долго.
    И задач в списках десятки, и списка у меня три (и рыба еще эта мем): мой таск менеджер, джира, фичаприемник в гугл таблице для стейков. Всё засунуть в один список не могу, т.к. не получится поддерживать там актуальность для всего: разделять личные и рабочие задачи, разделять задачи на команду разработки и фичаприемник для стейкхолдеров без джиры. Хотя очень хочется засунуть стейкхолдеров в джиру, чтобы списка стала хотя бы два, но непонятно как.
    И непонятно как выстроить приоритезацию и свою работу на ее основе, чтобы за короткое время все это хорошо распределить на ближайшие 2 или 4 недели. А потом еще принимать хорошие решения о смене приоритетов, а не хаотичные плохие решения.
    Сейчас я быстро прикидываю есть ли за этим хоть какое-то влияние на ключевую метрику доли заказов, но это очень грубо и не закрывает другие риски и узкие горлышки, которые непонятно как оценить и надо считать.
    Получается, что проблема в том, что нет времени на то, чтобы считать нормально, потому что проблема пункта 1.

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

  1. Уменьшили время ожидания (выполнения работ). Львиную долю времени начатые, но не законченные задачи и проекты не «выполняются», а «ждут выполнения». Если вы хотите ускориться, надо сокращать в первую очередь время ожидания/Wait Time, а не время касания/непосредственной работы над задачей или проектом/Touch Time. Достигается за счёт уменьшения количества выполняемых работ и за счёт увеличения количества периодов времени/слотов времени на непрерывную работу.
    Тут со своим расфокусом бы разобраться, это та же проблема пункта 1 что меня выдергивает разная активность в течение дня.

Или вторая проблема: начатое слишком объемное, чтобы сделать это за один присест.
У меня вызывает эмоции идея из главы 5 как ускорить свою работу, что ее надо выполнить за 1 присест и как-то поделить работу одна задача – один рабочий продукт – в один присест.
Как написать фичу за 1 присест? Допустим, один рабочий продукт будет черновиком описания.
А что в нем должно быть за этот один раз? полностью описанного процесса там может не быть, т.к. я не успею за 1,5 часа.
Принятое решение “как делать?” тоже может не быть за один присест, т.к. надо достать информацию из других людей.
Второй присест может будет измененным черновиком тоже непонятного содержания.
Там может появиться дизайн на 2-3 присест.
А может быть окажется, что надо проводить встречу с аналитиком или разработчиком по ходу того, как я буду разбираться что надо сделать.
А может быть надо сделать схему бизнес процесса.
Когда долго не могу сесть за написание фичи, то я по привычке из курса Дорофеева пишу себе первый шаг, чтобы обезьянке было понятно, но видимо не всегда получается прокинуть до реального рабочего продукта, раз есть отторжение от этой идеи.

3 лайка

Аналогично)

Забавно, что людям при этом не стыдно. “Давай созвонимся на 10 минут”. У меня в целом слишком много синхронной коммуникации. И она само собой не очень чёткая.

Я вот задаю себе вопрос, а когда включается многозадачность? Правильно, когда кажется всё “важное и при этом срочное”. Хотя оно скорее всего “срочное”, а насчёт важности вообще надо разбираться.

Но главный вопрос: как в моменте с этим входящим потоком работать, чтобы не кидать делать что-то сразу?

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

Писать аналитики умеют? Пусть свои вопросы в задачу и пишут, указывая контекст. И опять не “скажи как мне сделать”, а “вот такая ситуация, вот я подумал и вот наверно есть такие варианты и вот такие вопросы”. И не надо с ними созваниваться вообще. Читаете текст спокойно и там оставляйте комментарии. Если что с разработкой и тестированием они сами могут обсудить, никто идеальное описание от аналитиков не ждёт, как раз получат порцию вопросов на подумать. Или вместе подумают, расскажите им про мышление проговариванием.

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

Разделить описания. Понять что вообще такое описанная фича и чего это вдруг вы один её описываете целиком, когда у вас все есть (аналитики, разработчики, тестировщики).
Я так понимаю, что вы представиль “от бизнеса”. И пишите user story. Можно сначала более верхнеуровнево, что такое эта фича даёт пользователю. Кто на какие кнопки нажимает и прочую детализацию в следующий заход напишите. Техническое решение (схемы баз данных, апишки и прочие контракты) аналитики пишут, лучше бы вместе с разработкой, чтобы меньше фантазий было. Решения по алгоритмам технические разработка принимает сама. Тест кейсы на вашу user story и DOD пишут тестировщики. Дизайн ещё визуальный остался. Вот вроде и все описания. Ваше как будто только первое. А внутрянку пусть они друг с другом уточняют, там всё равно по ходу пьесы нюансы вылезут. Но на эти нюансы уже тесты можно написать и проверить, там и дошлифуется. Через вашу голову проверять все возможные корнер кейсы дорого и неэффективно.

2 лайка

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

Для выполнения операционной мантры неплохо бы разобраться:

  1. В создании какой “(конечной) вещи”/целевой системы участвует ваше предприятие;
  2. Какова “ваша вещь”/наша система/вещь предприятия для вашего предприятия (в простых случаях совпадает с целевой, допустим, у автозавода целевая и их вещь – эксплуатируемый автомобиль);
  3. Какой объект, связанный с вещью предприятия, выпускает предприятие (и какого этот объект типа – вспомните сегодняшнее обсуждение нефтеразведчиков) (в простых случаях объект, связанный с вещью предприятия, будет совпадать с вещью предприятия);
  4. Как ваша команда как рабочая станция (черный ящик) участвует в выпуске объекта предприятия;
  5. Как устроена ваша команда как производственная линия/конвейер/набор рабочих станций (прозрачный ящик), какие объекты путешествуют через неё, какие объекты выпускает эта производственная линия и как эти объекты связаны с объектом, выпускаемым предприятием, какова скорость выпуска команды.
  6. И тогда можно будет полноценно поговорить о том, как оптимизировать работу производственной линии.

Но у вас прямо сейчас не аврал, а настоящая аварийная ситуация – оочень большие проблемы со скоростью прохода/выпуска. Фича была разработана 4 месяца назад, но тестировщики приходят только сейчас?! Она еще не выпущена?! Это какое у нее потоковое время/время цикла/Flow Time/Cycle Time, если фича считается “взятой в работу” с момента, когда её аналитики начали прорабатывать? 6 месяцев?
Конечно, у вас проблемы. Требуется дернуть аварийный стоп-кран:

Срочно остановить поток новых фич “на вход” и заниматься их “выходом/выпуском”.
Временно полностью забаньте взятие в работу новых фич аналитиками (“вход”), вместо этого сфокусируйтесь на “выходе” фич в составе релизов.

Составьте список фич, которые взяты в работу, но еще не выпущены (“незавершенка”). Далее отсортируйте по следующим критериям (именно в таком порядке):

  1. Фича в состоянии, максимально близком к “готово к выпуску”;
  2. Фича важная/приоритетная;
  3. Фичу будет удобно выпустить в составе ближайших релизов.

После чего с командой определите состав ближайших релизов. Уменьшите размер каждого релиза и попробуйте выпускать релизы чаще. Допустим, у вас сейчас релиз раз в три недели. Как можно выпускать (для начала) релиз каждые 2 недели? Каков тогда должен быть состав релиза? Прикиньте с командой, как соблюсти принцип “много поставок мелкими партиями” или ‘release early, release often’.

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

Фокус (общий для команды/производственной линии!) на ускорение выпуска релизов. И ваш как операционного менеджера в частности, вам придётся отслеживать скорость выпуска релизов / Throughput Rate чуть ли не ежедневно.

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

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

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

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

Какие проблемы будут:

  • Можете столкнуться с неготовностью отдельных аналитиков переходить в разработчики (должность может при этом называться product manager, без проблем) – могут потребоваться замены;
  • надо будет прикинуть, в какой момент повышать з/п (скорее всего, это придется сделать) – и отслеживать по результатам работ, когда можно будет говорить о повышении;
  • поскольку у ваших будущих инженеров нет пререквизитов в виде “Рациональной работы”, “Системного мышления” и “Методологии”, описания методов будут просто насквозь кривые и косые. И вам тоже будет сложно, тк править описания придётся вам (и вы пока тоже не все можете поправить).

Выдыхаем, учитываем это и фокусируемся на следующих плюсах – что вы:

  • начнете устранять хаос – аналитики перестанут генерировать поток ненужных работ
  • начнете двигаться в сторону более правильного устройства вашей команды/производственной линии/набора рабочих станций.

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

Далее я бы порекомендовала попробовать определить причины, по которым ваша команда такая медленная (помимо того, что вы раздуваете WIP, что приводит к увеличению Flow Time/Cycle Time). Не хватает разработчиков (в том числе LLM-ок в роли разработчиков)? Можем нанять? Проблемы с методами? Можем поменять? И так далее.
Если выяснится, что проблемы в том числе в мастерстве сотрудников, рекомендую подумать над вариантами “заменить сотрудника” и “отправить сотрудника на обучение” (конечно, тех, на которых вы делаете ставку).

3 лайка

Что касается присестов – фичу в один присест вы даже близко не сделаете. И даже описание тоже вряд ли.
Но у вас могут быть промежуточные рабочие продукты каких-то версий. Например, “модель фичи версии 1.0”. И вам надо понять:

  • какой рабочий продукт вы должны передать следующей рабочей станции;
  • как можно разделить этот большой рабочий продукт/предмет работ/work item на рабочие продукты/work items поменьше (и версии можно указывать). Например, “описание метода описания фичи”, “модель фичи”, итоговый рабочий продукт – описание фичи.
    Вот как у вашей команды релиз состоит из какого-то числа work items/предметов работ/рабочих продуктов (фичей? багов? сторей?), так и у вас как рабочей станции тоже может быть “большой рабочий продукт как набор рабочих продуктов поменьше”.
2 лайка