Итак, напишите (на стикере или в формате короткой заметки в клубе МИМ), что для вас лично означает «быть собранным».
быть собранным - как я начал это ощущать прямо вот в последнее время - ты и задача - 1 на 1. Когда вопрос касается исследования новой предметной области (а у меня сейчас такой период, когда надо расширять зону работы, так как команда неконтролируемо сжимается, а задачи неконтролируемо расширяются).
появилось ощущение течения времени которое затрачивается на решение задачи.
Стараюсь доводить решение вопроса до какого-то чек-поинта (так назовем, по игровому) когда можно переключиться без ущерба для промежуточного результата.
То что можно закрыть на рефлексах/мышечной памяти, не включая голову - делаю на рефлексах.
В переписке с коллегами дополнительно явно оформляю свой запрос - что я ожидаю от коллег по тем или иным вопросам.
Того же прошу от них, чтобы они явно артикулировали, что ожидают от меня в ответ на свой запрос.
Когда вы в последний раз демонстрировали собранность?
если прям взять из жизни - утром было еженедельное совещания по статусу проекта. мы быстро с представителями подрядчика пробежались по основным альфам проекта. согласовали свое видение по тому, как двигается проект. при этом коллеги находились судя по звукам внешнего окружения, в аэропорту. но это не помешало нам проговорить статус.
Как вы поняли, что это собранность, а не что-то иное?
я точно представлял себе весь проект как пространственную фигуру с связями. настроился на эту встречу и достаточно четко все детали обсудил. мы конечно пользовались таблицами с дашбордами по проекту в качестве опоры.
Можете ли привести пример, когда она помогла вам решить сложную задачу или, напротив, не сработала?
в настоящий момент я разбирался как устроена цепочка документов в ЕРП отвечающая за построение плана производства. за 3 часа накидал модель того как я ее себе представляю, разобрал структуру отчета по которому закупки должны обеспечивать производство, обсудил мои наработки с консультантом, который отвечает за сопровождение блока производства, предъявил промежуточный результат внутреннему заказчику, который и придумал такой отчет.
что интересно, что в процессе общения с этим заказчиком начал ему подбрасывать мысли про то что ИТ и разработка тоже работает по своей логике и есть процесс производства и что не все так просто как изначально заказчик себе это воображал. наши позиции в процессе такого общения сблизились и мы стали меньше конфликтовать и вышли на конструктив. перестали ругаться другие мои коллеги с этим заказчиком. тоже стали сотрудничать и напряжение снизилось.
upd
Теперь опишите собранность ваших сотрудников или вашей команды в целом.
Какова она по вашей оценке сейчас, до начала работы по руководству?
Тут в этой части замеров не производил. в отделе разные специалисты работают с разной степенью собранности.
Каждый специалист отвечает за свой сектор, и там разная входящая нагрузка и свой домен. сложно судить со стороны.
Как это помогает или мешает вам?
мне это не мешает. мы в одной команде, но каждый из нас достаточно автономен, так как домены не пересекаются между собой в явной форме (например, блок Бюджетирования и блок Производство).
А как ваша собранность влияет на коллег?
мне так же сложно судить мое ли влияние отразилось в поведении коллег или так было всегда, я не присутствовал на больших совещаниях, но когда меня начали звать, то в ситуациях когда заказчики начинали “мочить” ИТ за какие-то сложности в своей работе (утверждение “ваша система не правильно посчитала Х”), я начал парировать такие атаки переключая внимание на методы проверки корректности работы системы, на каких данных (за какой период, какой ролью, из какого источника, какая надежность источника) получены результаты с которыми идет сравнение.
В ходе таких дискуссий мы обнаружили массу пробелов в регламентах, от чего внезапно пришло понимание что не в системе дело, а в действиях пользователей, которые не знаю как в системе работать и вносят в систему ошибки которые потом расползаются по процессам.
Коллеги так же начали в обсуждениях запрашивать источники данных, запрашивать описания способов получения результатов. не стану утверждать что это я им показал примеры как можно общаться с бизнесом, когда он по инерции катит бочку на ИТ и путает берега. Эту же позицию начал занимать и ДИТ, что не может не радовать, тк предыдущий ДИТ занимал позицию, когда он не говорил бизнесу что тот не прав даже когда бизнес явно был не прав. Но это все мои наблюдения.
udp
- спеваете ли вы сделать важные задачи в течение рабочего времени – или вам регулярно приходится задерживаться после его окончания?
Не получается пока одолеть входящий поток, так как одновременно у меня проходят несколько процессов: расширение зоны ответственности, 2 больших проекта, и под эти проекты я осваиваю новый формат управления проектом. Но фоновая текучка, от которой я не могу отказаться, ломает собранность. но я с этим работаю. нужно время на привыкание и адаптацию.
- Загляните в ваш трекер/планировщик задач и ответьте на вопрос: сколько задач у вас сейчас не завершено? Сколько дней (недель, месяцев) выполняется самая старая задача?
в момент написания ответа на вопрос нет под рукой трекера. все задачи которые я решаю не являются шаблонными изза того что ситуация постоянно меняется и старые способы решения задач перестают работать. + сейчас много новых задач которые выполняю в первый раз и тут изначально время решения задачи может быть не определено до момента решения задачи. что в этом добавляет сложности, так это то, что похожая задача может прилететь через год, и тогда придется снова пере изобретать решение задачи по-новой.
- Посмотрите в командный трекер задач. Сколько у вашей команды незавершённых задач или user stories, или иных объектов работ? Сколько дней (недель, месяцев) выполняется самая старая задача?
Мы не пользуемся командным трекером. нет такой практики.
по моим замерам, решение небольшой задачи (автоматизация какого-то процесса) занимает до 1/2 года от момента согласования технического задания, до выпуска решения на массового пользователя, и количество промежуточных релизов получается от 4-х версий внутри до показа заказчику, и еще 4+ релиза до момента когда решение готово к выпуску на всех пользователей. После такого в задаче остаются небольшие шероховатости, которые устраняются в рабочем порядке.
- Какие важные проблемы вы не решаете уже давно? Какие важные проблемы не решает ваша команда?
о таких проблемах не известно. все что возникает - решается, но не с той скоростью с которой хотелось бы изза ограниченности наших ресурсов.