Не выстроен процесс решения проблем с производительностью. Много времени тратится на “ручное” управление\решение рутинных задач. ТЛ при этом - узкое место со стороны разработки. Начиная с этой недели, на ближайшие 3 недели это станет моей головной болью, поэтому я заинтересован “порешать” вопрос. Кейсы для оптимизации
Когда разработчики запрашивают уточнение информации от постановщика задачи, ответ часто затягивается, и это затрудняет\сильно тормозит работу. Нужно минимизировать временной лаг, получать все нужные ответы в тот же день. Что делаю: собрать статистику ответов\временного лага\описать проблему и написать письмо на РП. для решения проблемы.
След узкое место (внешние по отношению к команде разработки роли): постановка задача\формирование карточек для передачи в работу, приемка результатов и возврат обратной связи. Т.е. на границах зоны ответственности.
Добавить измерение производительности команды\продемонстрировать видимые результаты. Как вариант: число закрытых дефектов, суммарное время (сек) и\или дельта %, на которые ( суммарно\или в разрезе каждой программы) улучшена производительность
Цель: команды должна работать полностью асинхронно и не требовать более 1.5 - 2 часов в день на управление со стороны ТЛ. Явный критерий уменьшения
1.Время потраченное на управление командой. - оценить по задачам Outlook.
2.Количество отвлечений (писем потребовавших ответа\сообщений в чат) за день
Кому и как станет лучше: Приоритет 1
ТЛ команды (уменьшится нагрузка) - на этой неделе моя роль\зона ответственности
Руководителю разработки (увечиться проход\мощность команды Фоновый
РП проекта (Появится измеримый количественный индикатор для демонстрации заказчику)
Рабочий продукт
1.Недостающие права доступа в тестовой системе\к VDI получены. Описать в виде доп. пункта в инструкции алгоритма получения прав в тестовой системе (перечислить требуемые роли), ознакомить разработчиков для которых получить их централизовано не получится.
2.Описать алгоритм выбора задач в работу из общего списка в виде инструкции на wiki Ознакомить команду. Передать право “выбора задач” на разработчиков (выборочно, для теста, на 2-x человек).
3.Письменный дейли по вт. и чт.
4.Статистика по результатам работы команды за неделю:
4.1 часы\число задач(в очереди\работе\на согласовании\завершено) в разрезе разработчиков на начало недели
4.2 число задач в (в очереди\работе\на согласовании\завершено) - суммарное по команде на утро каждого дня?
Xарактеристики\рекомендации по разработчикам(обновленные на пн.)
5.Статистика задержек на запросы разработчиков со стороны постановщика задачи за последнюю неделю собрана от разработчиков (не менее 10 кейсов) + Письмо с описанием проблемы и предложениями по решению на РП
Слоты
Выделил по 2 ч в день в Outlook. 1 ч утром, 1 час ближе к концу дня.
Формат публичной демонстрации и внешней проверки:
Статус команды разработки - по пятницам.
Обзор\review результатов недели в блоге МИМ
Пока писал обзор за прошлую неделю\актуализировал заметку Мастерская по практикам саморазвития.Системная карьера.Неделя 2025-09-01 , и накидывал планы на следующую неделю, понял что потратил 3 помидорки на обдумывание\планирование работ, но не приблизился к описанию личного контракта\стратегии развития. Поэтому в конце решил исправится, и немного развернуть приоритеты по ролям на текущий момент.
Приоритеты по деятельностным ролям на текущий момент:
Инженер целевой системы
Роль: Архитектор\Тех.Лид
Что буду делать: завершить обучение на роль архитектора в ближайшие 6 мес\ до конца февраля 2026. В том числе пройти три запланированных курса, вести обучающие заметки, и в итоге написать статью по каждому курсу.
Выделять по 4 ч в недели на обучение(слоты на проф обучение запланированы) )
Операционный менеджер
Роль: Роль ТимЛид
Что буду делать:
На сентябрь - выстроить процесс обработки дефектов\проблем производительности макс эффективно.
Слоты выделены: по 2 ч в день (10 ч в неделию)
Визионер целевой системы
Что буду делать: поучаствовать в проведении пресейлов\получить понимание процесса\cобрать информация по возможным болям участников рынка. Описать собранную информацию в заметках.
Выделено слотов: по 1 ч в неделю. Мало, но задача пока в фоне, как раз на подумать.
По идее результат работы команды это мы в пн как команда каждый запланировали N задач (определили, что считать достаточным статусом приёмки - у нас например это Ready for test) и в конце недели команда попала в план на 80-90%. Если не попала, собираем обратную связь. Конечно люди плохо планируют исходно, поэтому можно свериться в середине недели. Каждый день как будто излишне, люди разве на дейли не рассказывают какое текущее состояние по задачам?
Привет, Жень! Спасибо что поделился заготовкой.
Есть описание неудовлетворённости, есть описание кейсов
Задачи ставит кто-то один в команде или задачи/задания могут формулировать участники команды друг другу?
Сторона постановщик задачи делает это как-то описанием текстом по шаблону или когда как?
В задачах есть описание что является результатом?
У постановщика есть понимание какие рабочие продукты у разработчика на входе?
И как описанную проблему абзаца можно описать одним предложением в виде Ограничения?
В чем “узость” места? В чем конкретно Ограничение/бутылочное горло?
Это не одно и то же что в первом ограничении?: Методы Постановки задач и Приёмки результатов работ.
А вот тут интересно. Тоже является одним из объектов моего ролевого интереса.
В чем конкретно измерять эту самую производительность?
Как и чем делать измерения?
А потом как увеличить ее?
Это все сильно, конечно, привязано к предметной профессионально области.
Но думаю, что сегодня полюс минус один подход:
Необходимо всю создаваемую систему (целевую систему) как функциональный физический объект разбить на функциональные под системы. Тут без предметной области никак, и каждый сам играет роль Продукта/Инженера Целевой системы.
Потом начиная с самых нижних по функциональному разбиению уровней сделать синтез конструктивный: какие конкретно Модули/Конструктивы/Рабочие продукты/Артефакты будут играть Роль каждой подфункции.
А далее разбивать все модули на инкрименты по спринтам: то есть что за рабочие продукты создают кусочки команд, - с выпуском и демонстрацией во вне разработки - заказчику, например.
При этом создание каждого рабочего продукта на спринт имеет свою стоимость/мощность в помидоро-часах/человеко-часах. И у тебя на бэклог спринта появляется суммарно плановое время работ на старте спринта. Вот буквально как предусмотрено в личной сессии Стратегирования и планирования, но только на команду.
Дальше у тебя и команды идёт график “Выгорания” запланированных работ команды. И в конце спринта можно оценивать два параметра: а) количество инкриментов рабочих продуктов из запланированного и б) точность предсказания в оценках временного бюджета, то есть планирования (что сильно может удивлять, меня например как плохо мы умеем предсказывать).
Но вопрос с точки зрения измерения и увеличения производительности Производственного конвейера в задачах, созданием которых занимаются не для выпуска автомобиля или обуви в цеху, а в работе с проектами где много неопределённостей и все по сути часто уникально, где нельзя подвести какие-то нормативы по выработке, создать стандарты и тыкать в них пальцами при отклонении, для меня сегодняшнего это какое-то самозаблуждение.
На что я сейчас обращаю внимание так это:
Контроль события “Скорое начало работы” специалистов над своим рабочим продуктом. И сюда вот все, что ты описал про асинхронность, про уточнение и получение по исходным данным, про работу.
Понимание что такое “Результат работ”::“рабочий продукт + учет потребностей принимающей стороны”. С этим у меня прям боль больная: в этой обойме с…ка все вот эти “в ТЗ этого не было написано, дальше это уже не моя проблема”. Важно специалисту точно понимать кто “клиент” результатов его работ. И будет не лишним прямая коммуникация между ними для уточнения самого результата работ. Здоровое рабочее взаимодействие как добрая воля тут уместны, но так не всегда и не везде люди работают …
Контроль события “Скорого окончание работ” специалиста по созданию инкриментов рабочих продуктов на выходе его работ, которые будут как исходных данные на входе для следующего. Тут нужна глубина знания предметной области Инженера/Продакта и Менеджера.
Оправдание ожиданий Клиента/Заказчика/Пользователя от поставляемых кусочков или целых рабочих продуктов. Что это действительно учитывает интересы как минимум самых важных заинтересованных ролей.
Расходная часть бюджета на разработку всегда ниже Доходной части (потока) в рамках финансовой модели бюджета проекта и предприятия в целом.
Вот просто как измерить и что измерить в рамках задачи Увеличение производительности в проектах где планирование не состоит на 80% из водопада я не знаю.
Спасибо ещё раз за заготовку, мне теперь как-то и самому больше прояснилось.
В текущем виде это выглядит так:
Несколько раз в неделю (в ночь на неделе, или на выходные) запускается Нагрузочный профиль (пул программ в тестовой системе)
Потом команда отвечающая за тестирование разбирает результаты/создаёт задачи на оптимизацию, и они падают в очередь
/на вход команде разработки.
Если по конкретному кейсу/программе уже проводилась оптимизация, но она оказалась недостаточна для достижения целевых показателей, задача возвращается на разработку.
Команда разработки проводит анализ/оптимизацию и перенос изменений в тестовую систему.
И цикл повторяется.
Там нет планирования и ограничений, как такового, есть поток задач на оптимизацию которые нужно прожевать.
Цель приседаний - заставить весь Нагрузочный профиль выполниться за конкретное время не завалив систему. Есть жёсткие ограничения по конфигурации АПК.
Процесс только раскручивается, поэтому число задач на входе заведомо больше чем мощность(количество обработанных за цикл) задач команды разработки
Зачем там вся команда? Нет, в основном менеджмент и ряд тех.экспертов
Во первых - смысла нет, во вторых - 1 час * X разработчиков и несколько человекодней улетели в мусорку за время одного статуса
