Что для вас лично значит «быть собранным». Когда вы в последний раз демонстрировали собранность? Как вы поняли, что это собранность, а не что-то иное? Можете ли вы привести пример, когда собранность помогла вам решить сложную задачу или, напротив, не сработала?
Для меня это означает одновременно “знание, что надо делать, чтобы дойти до нужного результата” и некую решимость применять это знание на практике. Мне до недавнего времени вторая часть давалась очень тяжело, скучно уже доводить, когда всё известно и придумано.
В последний раз ровно перед отпуском мне нужно было за часов 8-12 набросать концепт для взаимодействия с другим программным компонентом, уже на уровне сообщений и типов сервисов, детальный дизайн. И многие вопросы упирались в то, что документации немного, другая команда медленно взаимодействует, и ответы выдаёт больше на уровне слухов. Тут и пригодились отточенные скиллы анализа кода – будучи натравленной на тесты, модель с хорошо поставленным “зрением” и запросами в мелких деталях “онтологии” предметной области, за минуты выдала все ответы и подтвердила часть предположений (а для других выдала детали ровно на том уровне, на котором нужно было). Запросы “просто так” у других коллег не привели к таким результатам, и из изначальной роли “наблюдателя за написанием концепта” меня переквалифицировали в “оформителя концепта”.
Примера не сработавшей собранности я навскидку не предложу, но часты ситуации, когда инженерное решение наталкивается на закон Конвея (другой отдел не видит выигрыша, т.к. нужный результат – не его KPI), – и здесь нужно расширять понятие собранности до организационных, а не чисто технических знаний.
Собранность сотрудников и команды
Моя тим-лид, мне кажется, весьма собранная, – она иногда перегибает с микроменеджментом, но часто чует, где нужно немного подтолкнуть или связать с другими нужными людьми, чтобы “ей нужная” работа была сделана и “уже визуализированный” результат был получен. Увы, она не успевает делиться своим видением, и остальная команда оптимизирует лишь относительно “её озвученных ожиданий”, – часто этого хватает, но иногда нужны неочевидные изначально циклы обратной связи. Нет практик общего refinement или подготовки задач, и остальная команда действует в рамках “кто что видит”. Это помогает – можно поговорить с кем-то и увидеть отдельные части системы лучше “чужими глазами”, но мешает вот это размытие экспертизы – review изменения, которое не касается “их” частей обычно “водяные” и формальные.
Очень надеюсь, что в рамках резидентуры смогу повысить свою собранность до уровня диалога с тим-лидом и PO на равных, и смогу своим примером увлечь других на сторону “большого контекста”.
Новая информация
-
Успеваете ли вы сделать важные задачи в течение рабочего времени – или вам регулярно приходится задерживаться после его окончания?
- Да, успеваю. Не задерживаюсь, иногда отвечаю на сообщения с телефона – там, где важна координация и время критично.
-
Загляните в ваш трекер/планировщик задач и ответьте на вопрос: сколько задач у вас сейчас не завершено? Сколько дней (недель, месяцев) выполняется самая старая задача?
- Сейчас не могу, в отпуске. Порядка 15-20, из них наверняка 5 просто забыты в состоянии “создана” – и либо уже решены, либо уже не нужны.
-
Посмотрите в командный трекер задач. Сколько у вашей команды незавершённых задач или user stories, или иных объектов работ? Сколько дней (недель, месяцев) выполняется самая старая задача?
- Командный трекер это долгий бэклог с обзором примерно на полгода, о самой старой задаче не сказать, но регулярно всплывают отложенные 2-3 месячной давности “тогда срочные”, но потерявшие срочность/приоритет задачи.
-
Какие важные проблемы вы не решаете уже давно? Какие важные проблемы не решает ваша команда?
- Я не улучшаю “большую картину” из-за малого обзора, – я недавно в этой команде. Чего команда не делает важного, сложно сказать. Выглядит так, будто важные проблемы находят отклик в текущих задачах и решаются.