![\"\"](\"https://pashlyandia.online/media/posts/8//Snimok-ekrana-2026-03-07-v-18.17.07.png\")
\nЧасть моего еженедельного расписания составляют регулярные встречи с моими сотрудниками. Сейчас таких встреч немного - 4 по 30 минут. Однако не спешите расслабляться, ведь они не такие простые, как может показаться на первый взгляд.
\nДля меня каждая из этих встреч состоит из трёх этапов:
\nИ чтобы немного упростить себе жизнь, я попробовал их автоматизировать с помощью связки моей базы знаний в Obsidian и n8n. Как это было — под катом.
\n", "content_html": "Часть моего еженедельного расписания составляют регулярные встречи с моими сотрудниками. Сейчас таких встреч немного - 4 по 30 минут. Однако не спешите расслабляться, ведь они не такие простые, как может показаться на первый взгляд.
\nДля меня каждая из этих встреч состоит из трёх этапов:
\nИ чтобы немного упростить себе жизнь, я попробовал их автоматизировать с помощью связки моей базы знаний в Obsidian и n8n. Как это было — под катом.
\nКакую проблему я хотел решить? В контексте one-to-one я бы хотел меньше времени тратить на всё, что не связано с самим разговором.
\nНапример, подготовка встречи. Сейчас для меня это выглядит так: я открываю все заметки по конкретному сотруднику и смотрю самые свежие (в пределах прошедшей недели), т.к. они могут составить основной контекст встречи. Также смотрю заметки предыдущих встреч и проверяю, о чём мы договорились. Что-то добавляю от себя — потому что физически всё записывать невозможно.
\nДалее создаю новую заметку со встречей и записываю туда темы, которые хотел бы обсудить. Для некоторых добавляю чуть больше контекста, чтобы проще сориентироваться во время разговора.
\nИ я бы не сказал, что на это уходит какое-то невероятное количество времени, но всё-таки я вижу здесь место для оптимизации, которую и решил осуществить.
\nСтоит отдельно рассказать о том, как я веду заметки. В моём рабочем Obsidian на момент написания этого поста почти 400 заметок разной направленности. Визуально такой объём можно оценить на графе:
\n\nКак можно заметить, он ещё и цветной. Разными цветами я выделяю заметки, связанные с определёнными сотрудниками - по отдельному цвету на каждого. И таких заметок у меня большинство.
\nНа каждого сотрудника есть тег вида #сотрудники/<фио>/<тема>, где тема - это направленность заметки. Это может быть обычная заметка (помечаю её как дневник), заметка по проектам сотрудника (помечается как проекты) и так далее. Это позволяет мне при желании уточнить поиск информации.
\nАвтоматизировать я решил через n8n, который развёрнут на VPS.
\nНе будем останавливаться на том, как локальные заметки из Obsidian попадают на VPS, потому что это тема для отдельного поста. Просто держите в голове: у меня развёрнут PostgreSQL, в котором хранятся нормализованные заметки, разбитые по тегам.
\nАрхитектурно это решение представляет из себя два воркфлоу:
\nПервое запускается по расписанию в 10:00 по Москве каждый день. Определяет, с какими из сотрудников у меня сегодня есть встреча и делегирует генерацию брифинга второму воркфлоу.
\nБлагодаря этому у меня есть чёткое деление ответственности: первый воркфлоу управляет расписанием и знает, когда и с кем у меня встреча, а второй - \"глупый\", который просто генерирует брифинг.
\nПосмотрим на эти воркфлоу детальнее.
\nОн состоит буквально из трёх простых нод:
\n![\"\"](\"https://pashlyandia.online/media/posts/8//Snimok-ekrana-2026-03-07-v-23.03.52.png\")
\n0 0 10 * * *\n
Обратите внимание, что здесь не обычный crontab, он ещё и включает секунды:
\n0 0 10 * * *\n
│ │ │ │ │ └─ любой день недели
│ │ │ │ └──── любой месяц
│ │ │ └─────── любой день месяца
│ │ └─────────── 10 часов
│ └─────────────── 0 минут
└────────────────── 0 секунд
Дальше - конфигурация в виде Code-ноды. И в ней же определяется, с кем у меня сегодня будет встреча:
\n![\"\"](\"https://pashlyandia.online/media/posts/8//Snimok_ekrana_2026-03-07_v_23_06_48.png\")
\nПо текущей дате с помощью простого JS-кода определяю, с кем из них у меня сегодня встреча, и в результате получаю коллекцию объектов.
\nНу и завершающий этап - вызов другого воркфлоу.
\n![\"\"](\"https://pashlyandia.online/media/posts/8/Snimok-ekrana-2026-03-08-v-12.21.39.png\")
\nОбратите внимание на режим (Mode): запускается один раз для каждого элемента на входе. Если у меня за день будет несколько встреч - выполнится для каждой, а не только для первой.
\nДальше мы попадаем в воркфлоу генерации брифинга:
\n![\"\"](\"https://pashlyandia.online/media/posts/8//Snimok-ekrana-2026-03-07-v-23.02.33.png\")
Сначала по тегу, который нам передали, находим заметки, созданные в пределах 7 дней от текущей даты. Если заметок нет - отправлю себе в Telegram сообщение, что так и так, подготовиться не получится.
\nЕсли есть - я формирую пользовательский промпт, в котором указываю содержимое найденных заметок. И затем отправляю это всё в ИИ через интеграцию с OpenRouter (модель openai/gpt-5.2-chat), прося его составить две вещи:
\nПолучив ответ в нужном формате, подготавливаю сообщение и отправляю его себе в Telegram.
\nУже несколько недель я пользуюсь этой автоматизацией, и по собственным наблюдениям - это полезно.
\nСаммари недели
\nМне нравится, что у меня в одном месте сразу всё, что я обычно искал вручную. Не нужно залезать в заметки, открывать несколько штук и перечитывать все полотна, которые в них написаны (да, я люблю развёрнуто писать).
\nВ плане подготовки саммари меня работа ИИ полностью устраивает. Бывают, правда, ситуации, когда он прописывает мне то, что мы уже обсуждали. Но это связано зачастую с ситуациями, когда у меня несколько регулярных встреч с сотрудником за неделю.
\nНо в теории и это можно вылечить изменением конфигурации и указанием в ней количества дней, за которые нужно получить заметки. Но поскольку сейчас это не сильно мешает, я не стал заморачиваться.
\nТемы для обсуждения
\nА вот с темами для обсуждения немного интереснее. Во-первых, ИИ поначалу предлагал мне что-то с сильным отрывом от реальности и я пользовался только его саммаризацией.
\nОднако недавно я обновил системный промпт и стало получше: теперь темы он формирует получше. И научился указывать ссылки на задачи сразу в сообщении, чтобы я мог в один клик посмотреть, что там за задача была.
\nДумаю, дальше уже дело экспериментов. Если что-то меня не будет устраивать, я просто попробую улучшить промпт.
\nИзменения в подходе к заметкам
\nСпустя некоторое время использования этой автоматизации, я заметил за собой, что начал чуть иначе вести заметки. Чтобы ИИ смог дать мне грамотные рекомендации ко встрече, у него должно быть максимально много контекста. Как у меня в голове, грубо говоря.
\nДля этого я начал фиксировать больше информации. Например, раньше я хранил у себя только то, что записывал на встречах (не только one-to-one, но и различных синков по проектам и прочего), а теперь я стал фиксировать ещё и заметки других участников процесса.
\nНапример, менеджеры после каждой встречи пишут саммари с договорённостями, к которым мы пришли по ходу обсуждения. Я переношу этот текст себе, размечаю тегами - и вот у меня уже больше контекста, связанного с проектом и/или сотрудником.
\nА ещё у нас бывают интересные обсуждения в тредах, где мы тоже приходим к каким-либо договорённостям или техническим решениям. Самые важные, на мой взгляд, я тоже начал фиксировать, используя встроенный в корпоративный мессенджер ИИ-помощник, который в пару кликов может обобщить тред на 100 сообщений.
\nИ это реально влияет на результаты генерации ИИ. Он находит темы, о которых я в моменте мог бы и не подумать.
\nПример одной из последних генераций
\nНемного сократил его для наглядности:
\n🗓 Брифинг: one‑to‑one с разработчиком
📋 Саммари недели
— закрыты несколько задач по текущему сервису, одна находится на этапе тестирования;
— начали погружение в новый сервис через несколько рабочих задач;
— обсуждалась новая задача, сейчас готовится проектирование;
— из прошлой встречи: договорились уделять больше внимания самопроверке изменений перед релизом.
💬 Темы для обсуждения
• как прошло тестирование последней задачи и всё ли готово к передаче дальше?
• когда планируется приступить к следующим задачам и нет ли риска задержек?
• какие первые впечатления от нового сервиса и какие вопросы уже появились?
• получается ли применять договорённость о дополнительной самопроверке перед релизами?
Пока что я автоматизировал только первый этап one-to-one - подготовку к нему. По ходу самой встречи я самостоятельно выписываю тезисы, а после - добавляю подробную информацию к каждому из них, в результате чего получается структурированная заметка со всеми важными моментами.
\nНо и это на самом деле можно автоматизировать. Например, вести запись встреч, а затем превращать это в текстовую расшифровку (конспект), как умеет делать тот же Яндекс Телемост. И из этого конспекта уже можно подготовить структурированное саммари того, что мы обсуждали.
\nНо пока что я стесняюсь вести запись, чтобы никого из ребят не смущать (хотя все прекрасно понимают, что я веду текстовые записи).
\n", "author": { "name": "Павел Скляр" }, "tags": [ "база знаний", "автоматизация", "one-to-one", "obsidian", "n8n" ], "date_published": "2026-03-08T14:03:00+03:00", "date_modified": "2026-03-08T14:47:45+03:00" }, { "id": "https://pashlyandia.online/kak-ya-ponyal-chego-hochu-ot-raboty/", "url": "https://pashlyandia.online/kak-ya-ponyal-chego-hochu-ot-raboty/", "title": "Как я понял, чего хочу от работы", "summary": "
Когда я был простым разработчиком, с моим развитием и нагрузкой было всё довольно просто. Мне нужно было постоянно изучать свежие подходы, повышать надёжность и качество своего кода, прокачиваться в архитектуре и многое другое.
\nВ апреле 2024 года меня сделали руководителем группы разработки и я задался вопросом, а чем я бы вообще хотел заниматься и чего от меня вообще ждёт компания. Быстро найти ответ на второй вопрос я не смог, поэтому сосредоточился на первом.
\n", "content_html": "Когда я был простым разработчиком, с моим развитием и нагрузкой было всё довольно просто. Мне нужно было постоянно изучать свежие подходы, повышать надёжность и качество своего кода, прокачиваться в архитектуре и многое другое.
\nВ апреле 2024 года меня сделали руководителем группы разработки и я задался вопросом, а чем я бы вообще хотел заниматься и чего от меня вообще ждёт компания. Быстро найти ответ на второй вопрос я не смог, поэтому сосредоточился на первом.
\n\nВ конце июня я приобрёл первую версию курса Стать Тимлидом от Школы сильных программистов. В первом уроке рассматривалась роль тимлида, а как раз с ней я и хотел определиться.
\nАвторы курса вводят три роли тимлида:
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Frame-2.jpg\")
В зависимости от компании, твоего положения и желания можно распределять ответственность между этими тремя ролями. Например, быть техлидом и отдавать роли инженера 80% своего времени и ответственности.
\nДалее авторы рассказывали о том, как узнать ожидания окружающих от позиции тимлида, а по итогу составить артефакт - так называемый паук ответственности. Паук из-за количества ответвлений, но я предпочитаю называть это картой ответственности. И приводят вот такой пример на основе трёх ролей, чтобы было на что опираться.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Frame-1.jpg\")
Изучив этот материал, я пришёл к выводу, что это как раз то, что мне нужно. Составив такую карту ответственности, я смогу не только прогнозировать своё развитие так, как мне хотелось бы, но и синхронизировать его с ожиданиями бизнеса и руководства.
\nПерейдём к тому, что у меня в итоге получилось. Я покажу только конечную карту, потому что первые несколько версий получились сумбурными и некрасивыми.
\nНа конец июня 2024 года я уже 3 месяца официально был руководителем, а на деле и того больше, потому что заниматься обязанностями тимлида я начал задолго до официального вступления в должность. Я решил начать с карты as-is, т.е. фактического состояния на момент составления этой карты.
\nЯ точно так же выделил 3 роли, но немного изменил их. Теперь это Технический лидер, Управление людьми и Процессы команды.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q2-2024-1.jpg\")
Далее я решил отразить на этой карте то, чем я уже занимаюсь на своей должности.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q2-2024-2.jpg\")
Со стороны выглядит совсем немного, но это только промежуточный вариант. Некоторые из этих пунктов меня не устраивали и я решил ввести новый цвет стикеров, чтобы отразить те моменты, которые я бы хотел убрать.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q2-2024-3.jpg\")
Я сторонник того, что тимлиды не должны писать код. Они могут помочь местами, но это должно быть скорее исключением, чем правилом. Поэтому первое, что я захотел выкинуть - это написание кода. Невозможно резко перестать писать код после того, как ты был ведущим разработчиком и на тебе была завязана определённая часть ответственности.
\nТакже я хотел бы перестать делать детальное проектирование, ограничившись верхнеуровневым. На мой взгляд, тимлид должен понимать, как работает система в целом, чтобы ориентировать бизнес в плане сроков и возможности реализации его хотелок, а вот детали реализации уже отдавать на откуп разработчикам. Всё-таки детали - это уже их зона ответственности.
\nСледующий шаг - понять, а чем я бы вообще хотел заниматься. Под это я ввёл ещё один цвет стикеров.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q2-2024-4.jpg\")
Участвуя в собеседованиях я пришёл к тому, что нам не хватает предварительной работы перед непосредственным открытием вакансии. Это работа заключается в составлении профиля кандидата, которого мы хотим видеть в нашей команде. С ним гораздо проще проверять, насколько человек вообще соотносится с тем, кого ищем.
\nПосле собеседования и оффера идёт онбординг. Я начал заниматься этим с декабря прошлого года и у меня даже были некоторые наброски, которые в определённой степени работали. В свой первый проведённый онбординг я словил жуткую нехватку времени, потому что приходилось самому всё писать с нуля и рассказывать. Это тяжело, поэтому я хотел бы начать привлекать для этого других специалистов. Например, чтобы менеджер рассказал о том, как у нас устроены процессы работы с задачами, а архитектор рассказал про архитектуру наших приложений. И туда же добавить контроль прохождения, т.к. первый опыт в этом плане был крайне неудачный.
\nТакже я хотел бы уделять внимание офбордингу, про который все почему-то забывают. Нужно рассказывать людям, как у нас проходит этот процесс и, если мы всё-таки решили прощаться, организовать передачу дел уходящего сотрудника.
\nС развитием тоже интересно. Как я уже писал в предыдущих публикациях, мне важно наличие регулярных one to one между сотрудником и руководителем. Было бы странно, если бы я не хотел это внедрить в своей команде. Также мне была интересна тема проведения performance review и составления индивидуальных планов развития. На тот момент я уже организовал первый прогон по придуманному процессу, но пометил зелёным, так как он был довольно сырой.
\nСчастье и вовлечённость - тоже важный аспект в нашей повседневной работе. Нужно развивать отношения между разными отделами, между коллегами и в целом работать над повышением удовлетворённости сотрудников.
\nВ процессы команды я решил добавить System Design - это то самое проектирование задачи. В тот момент процесс у нас был, прямо скажем, ужасный и неудобный. Нужно было что-то с этим делать.
\nВот с таким планом я ушёл в следующий квартал. По правде говоря, поначалу я составил план аж на полгода, но спустя квартал понял, что это слишком огромный промежуток и приоритеты могут 100 раз поменяться.
\nНедавно я составлял свежую карту ответственности по итогу третьего квартала. И вот что там получилось.
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q3-2024-1.jpg\")
Практически все пункты, которые я хотел добавить, были добавлены! Не получилось только с составлением профиля кандидата (т.к. сейчас у нас нет потребности в найме) и развитием отношений между отделами. Честно сказать, я не успел уделить этому достаточно времени.
\nТакже из Технического лидера ушёл пункт с полной реализацией фич. За третий квартал я занимался только частичной реализацией и это действительно круто. Однако не удалось избавиться от детального проектирования, но это пока что.
\nЧто делать дальше? То же самое, что мы делали ранее - добавлять и перекрашивать стикеры!
\n![\"\"](\"https://pashlyandia.online/media/posts/6/Team-Lead-Q3-2024-2-2.jpg\")
В Управлении людьми я хочу уделить время управлению конфликтами и продвижению корпоративной культуры. В развитии мне интересно внедрить квартальные ревью с каждым участником команды. Такое небольшое ретро с обсуждением и предварительным заполнением небольшой анкеты по самооценке.
\nТакже хотелось бы найти время на составление карты компетенций - предыдущая показала себя нежизнеспособной. А в счастье и вовлечённости мне хотелось бы заняться материальными и нематериальными компенсациями.
\nВ Процессах команды я вспомнил про управление техническим долгом, которым я так или иначе занимался. Добавил туда зелёный стикер с организацией процесса формирования и актуализации техдолга, потому что сейчас он, на мой взгляд, не совсем оптимален.
\nТакже очень хочу приучить себя к мониторингу задач команды. Хочется внедрить небольшой ежедневный ритуал для проверки доски с задачами.
\nА ещё я решил добавить четвёртое ответвление - Владелец продукта. Как руководитель группы я отвечаю за жизненный цикл продуктов, которые проходят через мою команду. Соответственно мне было бы здорово контролировать их запуск совместно с менеджерами.
\nПосмотрим, что из этого выйдет при подведении итогов в 4 квартале. Но когда я составил карту за 3 квартал, я увидел свой прогресс, что добавило мне мотивации продолжать. Я не сидел без дела весь квартал, я действительно работал.
\nНа мой взгляд, карта ответственности - очень универсальная вещь. Её можно составлять даже не ограничиваясь IT направлениями. Она здорово помогает понять, насколько много (или мало) работы вы на самом деле выполняете. С помощью неё можно спланировать план развития и согласовать его с руководством.
\nЯ в рамках зелёного стикера с квартальным ревью как раз хочу внедрить эту карту ответственности в жизнь обычных разработчиков. Скорее всего, она будет выглядеть совершенно иначе, но позволит в том числе составить портреты участников команды, на основе которых можно будет быстро формировать портрет кандидата. И рыбку съесть, как говорится.
\nПодписывайтесь на мой Telegram и оставляйте комментарии к публикации с этой статьёй - я буду рад услышать ваше мнение.
\n", "image": "https://pashlyandia.online/media/posts/6/IMG_3279-2.jpg", "author": { "name": "Павел Скляр" }, "tags": [ "Развитие" ], "date_published": "2024-10-10T15:37:30+03:00", "date_modified": "2024-10-10T16:54:00+03:00" }, { "id": "https://pashlyandia.online/pyat-porokov-komandy/", "url": "https://pashlyandia.online/pyat-porokov-komandy/", "title": "Пять пороков команды", "summary": "Как вы думаете, что влияет на производительность команды? Какие ошибки можно совершить, работая с другими людьми и какие могут быть последствия?
\nНа днях я прочитал книгу Патрика Ленсиони «Пять пороков команды», в которой как раз поднимается эта тема. Зачастую для бизнес литерутары я стараюсь вести конспекты, чтобы в случае необходимости не пришлось перечитывать всю книгу, а только краткую выжимку с основными моментами. С этой книги я решил начать публиковать их, может кому-то и пригодится.
\n", "content_html": "Как вы думаете, что влияет на производительность команды? Какие ошибки можно совершить, работая с другими людьми и какие могут быть последствия?
\nНа днях я прочитал книгу Патрика Ленсиони «Пять пороков команды», в которой как раз поднимается эта тема. Зачастую для бизнес литерутары я стараюсь вести конспекты, чтобы в случае необходимости не пришлось перечитывать всю книгу, а только краткую выжимку с основными моментами. С этой книги я решил начать публиковать их, может кому-то и пригодится.
\n\nВ книге «Пять пороков команды» Патрик Ленсиони в формате бизнес-романда рассказывает о том, как сделать команду эффективной и повысить её ценность для компании. Нам рассказывают о вымышленной компании DecisionTech, которая всего два года назад была одной из самых известных, стабильных и многообещающих в Кремниевой долине.
\nГлавная героиня - Кэтрин - только что заняла должность СЕО. Ей предстоит наладить работу команды топ-менеджеров, чтобы компания не ушла в историю обанкротившись.
\nЯ настоятельно рекомендую прочитать книгу полностью, благо её вполне можно прочитать за день. Тем не менее, в этой статье мы рассмотрим пять пороков, с которыми столкнулась команда топ-менеджеров DecisionTech.
\nСначала бегло пройдём по всем порокам, потом детально по каждому. По мере прочтения постарайтесь наложить то, о чём здесь говорится, на вашу команду, а в конце вас будет ждать анкета, которая позволит выявить восприимчивость вашей команды к каждому из пяти пороков.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/5-porokov-komandy-2.webp\")
Первый порок - взаимное недоверие.
\nКак правило, оно возникает из боязни продемонстрировать перед всеми свою уязвимость, слабость. Если члены команды опасаются открыто признаться в своих ошибках и недостатках и скрывают их любой ценой, создается атмосфера взаимного недоверия и подозрительности.
\nВзаимное недоверие в коллективе создает почву для развития второго порока - ухода от конфликтов.
\nЛюди, не доверяющие друг другу, неспособны к искренней, открытой дискуссии, боятся задеть кого-либо или оказаться задетыми. Вместо этого они ведут обмен нейтральными замечаниями, осторожными комментариями, порой переходя к колкостям, и в результате принимают единогласное решение, которое никого не устраивает и ни к чему не ведет.
\nУход от здоровых конфликтов порождает третий порок команды - необязательность.
\nПоскольку в команде царит атмосфера недоверия, никто не говорит то, что думает, не поддерживает принятых решений, и работа движется очень медленно.
\nИз-за собственной необязательности члены команды не считают, что могут чего-то требовать от других. Нетребовательность к другим - четвертый порок команды. Даже понимая, что какие-то действия (или, наоборот, бездеятельность) вредны для компании, сотрудники часто исходят из принципа «это не мое дело».
\nСобственная необязательность и нетребовательность к другим создают почву для развития пятого порока. Безразличие к общему результату возникает, когда члены команды ставят свои личные интересы (карьеру, признание) или потребности своих отделов выше общих целей команды или компании.
\nПодобно цепочке, которая рвется, если хотя бы одно звено оказалось слабым, команда может погибнуть из-за одного-единственного порока. Чтобы лучше понять модель пяти пороков, можно рассмотреть ее противоположность - модель пяти добродетелей команды, и представить, как ведут себя члены сплоченного коллектива.
\nВсе очень просто, скажете вы. Так и есть, во всяком случае теоретически. На практике, однако, все оказывается гораздо сложнее - хотя бы потому, что от каждого члена команды требуются железная дисциплина, самоотдача и настойчивость, которыми наделен далеко не каждый.
\nРассмотрим каждый порок более детально.
\nДоверие - основа эффективной и сплоченной команды. Без него работа команды невозможна вообще.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/nedoverie-5.webp\")
Есть несколько толкований этого термина. В контексте построения команды доверие - это убеждённость членов команды в том, что от действий коллег не нужно будет защищаться. Иными словами, сотрудники не должны ждать удара в спину от своих коллег.
\nВ контексте командной работы доверие толкуется как способность сделать предположения о поведении человека на основе предыдущего опыта. Например, можно быть уверенным в том, что сотрудник, который всегда выполнял определённого рода задачи снова справится с ними.
\nМне больше по душе первое толкование, потому что оно больше раскрывает аспект, необходимый для избежания порока взаимного недоверия. Недостаточно не ждать удара в спину, важно не опасаться показывать свою уязвимость. Под уязвимостью я понимаю демонстрацию слабостей, отсутствия каких-то навыков, проблем в общении, ошибок, а также открытое высказывание просьб о помощи.
\nНеумение создать доверительную атмосферу обходится дорого. Команды, лишенные этого качества, тратят массу времени на выяснение отношений и сведение счетов. Сотрудники боятся высказывать своё мнение, неохотно обращаются за помощью и не предлагают помощи другим. Неудивительно, что атмосфера в таких коллективах тяжелая, а текучесть персонала высокая.
\nВ командах, поражённых пороком недоверия, люди:
\nВ командах, где царит атмосфера доверия, люди:
\nКак же создать атмосферу доверия?
\nК сожалению, подлинное доверие, основанное на уязвимости, не появится за один день. Требуется длительная совместная деятельность, многочисленные примеры полезности взаимоуважения и взаимовыручки, разъяснение особенностей командной работы. Если усиленно работать в этом направлении, можно достичь доверия за сравнительно короткое время.
\nВот несколько полезных упражнений, которые предлагает автор.
\n📌 Упражнение «Немного о себе»
За каких-то полчаса команда может сделать огромный шаг в создании атмосферы доверия. Всё, что требуется от руководителя, - это задать каждому из участников собрания несколько вопросов о его жизни. Вопросы не должны носить чересчур личный характер. Вот несколько тем: братья и сестры, место рождения, проблемы в детстве, хобби, первое место работы, самая плохая работа. Отвечая на эти безобидные вопросы, члены команды лучше узнают друг друга, начинают душевнее относиться друг к другу и видеть в коллегах не конкурентов, а просто людей. Появляются сочувствие и понимание, члены команды начинают более позитивно оценивать действия коллег.
Просто удивительно, как плохо люди в современном обществе знают друг друга и как мало надо, чтобы разрушить стену непонимания.
Минимальное время - 30 минут.
📌 Упражнение «Эффективность команды».
Это упражнение более рискованное и сложное и в то же время более действенное для создания команды. Каждый присутствующий должен определить, какой вклад в общее дело внес каждый из его коллег, и назвать сферу деятельности, в которой тот должен либо активизировать свои действия, либо прекратить их. Каждого члена команды обсуждают по очереди, начинают обычно с руководителя; очень важно, чтобы высказались все.
На первый взгляд такое обсуждение может показаться бестактным и даже опасным, однако при правильном подходе оно дает массу конструктивной и позитивной информации за удивительно малое количество времени - всего за час. Несмотря на то что это упражнение приносит плоды только при наличии определенного уровня доверия, его способна выполнить практически любая команда.
Минимальное время - 60 минут.
📌 Составление описаний личности и поведения
Один из самых эффективных методов создания доверия в команде - построение профилей личностных и поведенческих предпочтений членов команды. Этот метод помогает людям лучше понять друг друга, что создает основу для возникновения взаимных симпатий.
Автор книги чаще всего пользуется опросником Майерс-Бриггс, однако существуют и другие, достаточно популярные и эффективные. Назначение большинства этих тестов - дать практическое и научно обоснованное описание поведения разных членов команды, создаваемое на основе их манеры говорить, думать и действовать. Главные преимущества подобных тестов - беспристрастность (все личности разные, но ни один тип не лучше другого), научность (они базируются на достижениях психологии, а не астрологии или, допустим, сайентологии), активное участие исследуемых в определении своего типа.
Применение подобных методов требует привлечения квалифицированных специалистов, которые способны грамотно провести тестирование и корректно интерпретировать полученные данные.
Минимальное время - 4 часа.
📌 Обратная связь
За последние несколько лет этот метод приобрел популярность и может оказать огромное воздействие на команду. Он весьма рискован по сравнению с описанными выше упражнениями, так как требует, чтобы коллеги дали четкую оценку действий друг друга и высказали критические замечания. По мнению автора, главное в обратной связи - объективность и неформальный характер.
Кроме того, эту методику можно использовать для развития навыков командной работы, когда работники имеют возможность поговорить о сильных и слабых сторонах друг друга без негативных последствий для себя. Однако если обратная связь носит субъективный характер, то становится опасной, поскольку превращается в инструмент интриг и манипуляций.
📌 Командные спортивные упражнения
Перетягивание каната и прочие спортивные состязания, призванные выработать командный дух, уходят в прошлое, и туда им и дорога. Однако многие команды все еще пытаются воскресить их в надежде усилить взаимное доверие. Хотя спортивные состязания и совместные пикники, разумеется, имеют целый ряд достоинств, однако эти достоинства далеко не всегда проявляются в рабочей обстановке.
Подобные упражнения можно рекомендовать для развития командного духа в том случае, если они служат дополнением к более серьезным и фундаментальным процессам создания команды.
Поскольку каждое из этих упражнений оказывает значительное, но кратковременное воздействие на способность членов команды к взаимному доверию, их можно выполнять регулярно (ежедневно после или во время работы). Следует периодически проверять достижения каждого члена команды в обретении доверия. Даже в сильных командах - и, возможно, в них в первую очередь - утрата доверия может привести к катастрофическим результатам.
\nГлавное, что может и должен сделать лидер для создания атмосферы доверия в команде - первым продемонстрировать свою уязвимость. Иногда для этого потребуется пойти на риск потерять лицо в глазах команды, чтобы побудить подчинённых к аналогичному риску.
\nКроме того, очень важно, чтобы лидер создал такую атмосферу, в которой никто не боится быть уязвимым. Даже в эффективных командах сотрудники сами неосознанно мешают возникновению доверия, резко критикуя друг друга за слабости или допущенные ошибки.
\nНаконец, очень важно, чтобы уязвимость лидера была подлинной, а не игрой на публику. Один из самых быстрых способов утратить доверие - изображать беззащитность и уязвимость, чтобы манипулировать эмоциями окружающих.
\nКак всё это связано со следующим пороком? Доверяя друг другу, члены команды создают возможности для конфликтов, потому что не боятся вступать в открытую дискуссию, зачастую излишне эмоциональную. Ведь они знают, что не будут наказаны за слова, которые в другой команде сочли бы деструктивными или обидными.
\nЛюбые длительные взаимоотношения для своего развития требуют конструктивного конфликта. Это относится не только к бизнесу, но и к браку, дружбе, партнёрству.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/porok21.webp\")
К сожалению, в обществе конфликт зачастую считается недопустимым во многих ситуациях, в числе которых присутствует работа. Необходимо отличать продуктивный, конструктивный конфликт от деструктивного соперничества и интриг. В конфликте, который мы считаем конструктивным, обсуждаются только концепции и идеи, и ни в коем случае - личные качества участников. Однако такому конфликту тоже могут быть свойственны накал страстей, эмоции, повышенный тон, взаимные упреки; сторонний наблюдатель вполне может принять конструктивный конфликт за банальную ссору.
\nЯ даже могу привести пример из моего недавнего опыта. Одним вечером мы собрались обсуждать KPI сотрудников с продакт-менеджером (назовём её Оксаной) и руководителем отдела разработки (назовём его Ильёй). В процессе разговора у меня с Оксаной возникли оживлённые споры, которые, как мне показалось, сильно удивили Илью. Однако для нас обсуждение в таком ярком формате - обычное дело. Мы часто расходимся во мнениях и за счёт продуктивного спора приходим к решениям, которые устроят всех.
\nОчень часто члены команды, в которой не приняты конфликты, избегают их, потому что боятся обидеть кого-нибудь, что в итоге приводит к возникновению напряженной обстановки. Если работники не обсуждают важные вопросы открыто и не высказывают напрямую свою позицию, то у них появляется склонность действовать за спиной друг у друга и интриговать, что намного опаснее и вреднее, чем жаркий обмен мнениями.
\nСтранно, но очень многие, избегая конфликта, объясняют это стремлением к эффективности, хотя как раз конфликт способен по-настоящему сэкономить время. Противники конфликта считают, что спор - пустая трата времени, а на самом деле именно из-за такой страусиной позиции приходится по многу раз возвращаться к одним и тем же вопросам, особенно если мнения работников разделились. Руководители - противники конфликтов обычно просят подчиненных высказывать свои мнения в частном порядке и не выносят проблему на общее обсуждение, в результате принятие важных решений откладывается, а проблема не решается.
\nКак выработать у команды способность и желание участвовать в здоровом, продуктивном конфликте? Первым шагом должно стать признание того, что конфликт полезен, хотя многие команды пытаются избежать его. Пока в команде есть люди, которые считают конфликт ненужным, мало шансов, что он произойдет.
\nВ командах, которые боятся конфликтов:
\nВ командах, которые не боятся конфликтов:
\nЕсть несколько методик, позволяющих сделать конфликт более конструктивным и приемлемым для команды.
\n📌 «Подрывник»
В команде, члены которой стремятся научиться вести конструктивный конфликт, выбирают (случайным образом) «подрывника», задача которого - извлечь на свет скрытые разногласия внутри команды и инициировать их обсуждение.
«Подрывник» должен обладать мужеством и пользоваться уважением коллег, чтобы суметь затронуть больные темы и заставить членов команды открыто обсудить их. Для этого требуются объективность и твердость, ведь важно не прекратить обсуждение, пока не будет внесена полная ясность. В некоторых командах предпочитают «подрывника» не выбирать, а назначать.
📌 Модерирование
В процессе конфликта члены команды должны учить друг друга не избегать открытой здоровой дискуссии. Для этого можно применить простой, но эффективный метод: дождаться момента, когда участники спора почувствуют дискомфорт от невозможности прийти к согласию, прервать их и напомнить, что спор необходим.
Несмотря на простоту, этот способ отлично действует, когда требуется снять напряжение и помочь участникам продолжить обсуждение. Когда дискуссия подойдет к концу, полезно напомнить собравшимся, что конфликт, в котором они приняли участие, полезен для команды и его не следует избегать в дальнейшем.
📌 Другие методики
Как уже упоминалось выше, существует множество методик определения типа личности, позволяющих членам команды лучше узнать друг друга. Многие из них содержат описание модели поведения разных типов личности в конфликте, поэтому их можно использовать для того, чтобы подготовить членов команды к реакциям друг друга.
Можно рекомендовать также так называемую модель Томаса-Килманна, разработанную специально для конфликтных ситуаций. Она позволяет понять естественные реакции разных людей на конфликт и выбрать модели поведения, оптимально подходящие для той или иной ситуации.
Одна из самых трудных задач, стоящих перед лидером, который пытается инициировать в команде здоровый конфликт, - это преодоление естественного желания уберечь членов команды от стресса. Уступая этому желанию, лидер искусственно устраняет любые разногласия, из-за чего члены команды не могут приобрести навыки самостоятельного решения конфликтов. При этом лидер напоминает чересчур заботливого родителя, который всеми силами оберегает детей от ссор и столкновений со сверстниками. В результате ребенок вырастает, не научившись ни постоять за себя, ни выходить из конфликтных ситуаций. Кроме того, неразрешенные конфликты порождают напряжение и отвлекают членов команды от решения насущных проблем.
\nПоэтому очень важно, чтобы лидер в конфликтной ситуации продемонстрировал самообладание и позволил членам команды самостоятельно прийти к решению, каким бы тяжелым ни был этот путь. Для многих руководителей это сложная задача, так как им кажется, что если в команде возник конфликт, то они, лидеры, не справились со своими обязанностями.
\nИ наконец, как ни банально это звучит, очень важна способность лидера лично продемонстрировать достойное поведение во время конфликта. Избегая конфликта, когда он необходим и продуктивен, - а этим часто грешат успешные руководители, - лидер команды сам способствует развитию второго порока.
\nКак фальшивое согласие связано со следующим пороком - необязательностью?
\nКонструктивный конфликт обладает тем бесспорным преимуществом, что позволяет всем членам команды узнать мнения и идеи своих коллег и выработать решение, максимально устраивающее всех. В результате каждый член команды чувствует ответственность за его выполнение.
\nС точки зрения команды, обязательность - это продукт двух составляющих: определенности и безоговорочной поддержки принятых решений. Сильные команды вырабатывают четкие и своевременные решения и исполняют их с одобрения всех участников, включая даже тех, кто сначала был против. Они уверены, что никто не будет саботировать принятые решения.
\nДве главные причины необязательности - стремление к полному единогласию и желание абсолютной определенности.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/porok3.webp\")
Единогласие
\nЭффективные команды понимают опасности, которые таит в себе длительный поиск согласия, и находят способы для принятия решения в условиях, когда полное совпадение мнений недостижимо. Члены эффективных команд понимают, что разумный человек не станет добиваться, чтобы приняли непременно его предложение, ему достаточно, чтобы его выслушали и поняли.
\nВ такой команде каждый чувствует, что его мнение значимо, и готов искать решение, приемлемое для всей группы. А если это невозможно, лидер команды должен лично принять решение.
\nОпределенность
\nСильные команды также гордятся своим умением добиваться слаженного исполнения принятых решений, даже когда нет уверенности, что решение правильное.
\nСтарая армейская аксиома: любое действие лучше его отсутствия. Лучше принять смелое решение, ошибиться и столь же смело изменить его, чем упускать возможности.
\nСравните такой подход с действиями плохой команды, которая бесконечно взвешивает все «за» и «против» и тянет с принятием неотложных решений, рассчитывая получить дополнительную информацию. Конечно, такое поведение можно счесть благоразумным, однако на самом деле оно просто опасно, поскольку парализует команду и порождает сомнения в собственных силах.
\nВажно помнить, что конфликт порождает желание действовать и в отсутствие исчерпывающей информации. Чаще всего команда и так обладает всей полнотой информации, нужно только побудить сотрудников поделиться ею, извлечь ее на свет. Самый простой и эффективный способ сделать это - конфликт. Только после того, как все выскажут свои мнения и предложения, команда сможет принять решение, основанное на коллективном разуме группы.
\nЧто нужно делать команде для повышения ответственности? Она должна добиваться определенности и принятия решения, вместо того чтобы поддакивать друг другу и дожидаться лучших времен.
\nБезответственная команда:
\nОтветственная команда:
\nВот какие активности рекомендует автор.
\n📌 Подведение итогов
Одно из самых полезных упражнений для любой команды занимает всего несколько минут и не требует дополнительных затрат. В конце совещания или выездного заседания предложите команде подвести итог: в кратком виде сформулировать основные решения и договориться, что нужно довести до сведения сотрудников, клиентов и иных заинтересованных лиц.
Во время этой процедуры нередко оказывается, что не все члены команды одинаково понимают принятые решения и их нужно еще раз уточнить, прежде чем реализовывать на практике. Кроме того, нужно однозначно договориться о том, какие из принятых решений нужно быстро и исчерпывающе донести до подчиненных, а какие должны остаться конфиденциальными. Наконец, после совещания руководители передают своим подчиненным полностью согласованные распоряжения.
Минимальное время - 10 минут.
📌 Дедлайн
Установление четкого срока для выработки решения с последующим поощрением тех, кто помог всем уложиться в этот срок, остается одним из самых действенных упражнений для развития командных навыков, несмотря на кажущуюся простоту. Злейший враг команды, подверженной этому пороку, - неопределенность, поэтому команда должна четко осознать необходимость уложиться в отведенное время.
Кроме того, важно установление промежуточных дедлайнов, которые заставляют членов команды вовремя выявить и устранить любую несогласованность.
📌 Анализ вероятных и плохих прогнозов
Команде, которая борется с необязательностью, поможет рассмотрение вероятных последствий решений, которые находятся в процессе обсуждения.
Еще более эффективным будет анализ худшего сценария развития событий. Он помогает понять, что любые последствия принятого решения можно пережить и они не так страшны, как может показаться.
📌 Приучение к риску
Ещё одним полезным упражнением является демонстрация решительности в сравнительно безопасных ситуациях. Когда после длительного обсуждения команда заставляет себя принять решение без тщательного анализа и дополнительного сбора информации, оказывается, что оно гораздо лучше, чем можно было ожидать.
Более того, это решение не хуже того, которое они приняли бы после длительного и всестороннего исследования. Однако это вовсе не означает, что анализ и исследования не важны, просто опасливая команда склонна переоценивать их значение.
Как никакой другой член команды, лидер должен отдавать себе отчет в том, что команда может принять решение, которое окажется неправильным. К тому же лидер должен постоянно подталкивать группу к окончанию обсуждения и принятию решения, задавать нужный темп и следить за соблюдением дедлайна.
\nЧего лидер ни в коем случае не должен делать, так это поощрять фальшивое согласие и откладывание решений.
\nКак все это связано со следующим пороком - нетребовательностью к другим?
\nДля того чтобы члены команды требовали друг от друга определенного поведения и действий, им нужно четко понимать, чего от них ждут. Даже самые ответственные члены команды, несомненно, не станут требовать ответственности за то, что не было четко сформулировано.
\nВ рамках команды «требовательность» означает стремление членов команды добиваться от коллег определённых моделей поведения или действий и порицать те, которые могут нанести урон команде.
\nНетребовательность к другим объясняется стремлением членов команды избежать дискомфорта, который возникает при попытках указывать коллегам на их недочеты, а в более широком смысле - нежеланием попадать в непростые ситуации. Члены сильных команд преодолевают это естественное желание, предпочитая открытое, хоть и чреватое конфликтами общение друг с другом.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/porok4.webp\")
Конечно, это легче сказать, чем сделать - даже в сплочённых командах с хорошими межличностными отношениями. Более того, именно члены дружелюбных команд, особенно близкие друг другу, меньше всего стремятся к требовательности, поскольку не хотят испортить добрые взаимоотношения. К сожалению, это приводит к обратному результату, потому что в итоге все начинают упрекать друг друга за то, что не оправдали надежд и утратили высокие стандарты. Члены сильных команд способствуют улучшению морального климата, проявляя взаимную требовательность. Так они демонстрируют уважение друг к другу и поддерживают высокую эффективность.
\nКак можно повысить уровень требовательности в команде? Для начала, давайте сравним две команды между собой.
\nНетребовательная команда:
\nТребовательная команда:
\nВ книге приводятся три методики, которые помогут преодолеть этот порок.
\n📌 Информирование о целях и стандартах
Хороший способ сделать членов команды более требовательными друг к другу - это поставить перед командой ясные цели, четко распределить обязанности и установить стандарты поведения. Для требовательности нет ничего хуже неопределенности, и даже когда команда с самого начала придерживается графика и поддерживает заданные стандарты поведения, лидер должен постоянно напоминать о них.
📌 Регулярный анализ ситуации
Небольшие структуры наподобие команд имеют возможность мотивировать людей на действия, от которых те обычно стараются уклониться. В частности, это касается обратной связи по вопросам поведения и производительности труда коллег. Членов команды надо обязать регулярно оценивать выполнение каждым обязательств и стандартов (в устной или письменной форме). Надо добиться того, чтобы работники делали это самостоятельно и добровольно, тогда проблем с поддержанием высокого уровня требовательности в команде не будет.
📌 Вознаграждение
Следует отказаться от вознаграждения за личные достижения и поощрять командные достижения. Это поможет создать особую культуру взаимной требовательности: членам команды будет невыгодно молча сносить низкую эффективность кого-то из коллег, так как это может привести к лишению всей команды премии.
Самое трудное для лидера - решиться на передачу полномочий взаимного контроля собственно членам команды. Иногда сильные лидеры создают, сами того не замечая, вакуум ответственности внутри команды, выступая единственными борцами за дисциплину. В такой ситуации члены команды самоустраняются от борьбы за дисциплину и спокойно закрывают глаза на случаи ее нарушения.
\nОднако если лидеру удастся создать в команде культуру взаимной требовательности, он оставит себе только роль высшего арбитра в ситуациях, когда команда не сможет прийти к какому-либо решению. И такие ситуации должны быть крайне редки - исключение из правил, но не правило. Всем членам команды должно быть ясно, что требовательность - это коллективная ответственность, а лидер команды всегда начеку и готов вмешаться, если возникнет необходимость.
\nКак все это связано со следующим пороком?
\nЕсли члены команды не радеют за общее дело, то они больше внимания уделяют собственным делам, своей карьере. Именно с нетребовательности и отсутствия взаимного контроля начинается безразличие к общему результату.
\nЕще один порок команды - склонность работников ставить свои личные цели выше командных.
\n![\"\"](\"https://pashlyandia.online/media/posts/5/porok5.webp\")
Чтобы отслеживать свою эффективность, команда должна знать свои цели, критерии оценки и конечный результат. Говоря о результате, мы не имеем в виду только прибыль или доходы акционеров. В капиталистическом обществе многие организации оценивают свое положение в первую очередь по этим показателям, однако мы говорим о результате в более широком смысле.
\nКаждая хорошая организация планирует, чего хочет достичь за определенный период, и достижение этих целей имеет большее значение, нежели достижение конкретных финансовых показателей. Поэтому если для корпорации конечным мерилом деятельности будет прибыль, то для команды таким мерилом будет достижение целей и решение задач, которые ставят перед ней лидеры. В конечном счете достижение этих целей и означает достижение прибыли.
\nНо на чем команда должна концентрировать внимание больше, чем на прибыли? В первую очередь на собственном статусе и на статусе каждого сотрудника.
\nСтатус команды
\nЧленам некоторых команд достаточно просто ощущать свою принадлежность к некой группе. Для них достижение результатов желательно, но без особых жертв и напряжения.
\nЭто может показаться смешным и даже опасным, однако множество команд становятся жертвой именно своего поклонения статусу. Прежде всего это относится к некоммерческим организациям, которые считают, что их миссия достаточно благородна сама по себе, а результаты не так важны. Политические движения, академические учреждения и престижные компании также подвержены пороку безразличия к общему результату, поскольку они зачастую процветают исключительно за счет принадлежности к числу особых организаций.
\nЛичный статус
\nВ некоторых командах люди стремятся улучшить свое собственное материальное положение и добиться продвижения по карьерной лестнице в ущерб общим целям. Хотя в обществе каждому свойственно бороться в первую очередь за себя, хорошая команда способна добиться того, чтобы коллективный результат группы стал для каждого ее члена важнее, чем достижение личных целей.
\nПорок безразличия к общему результату представляется самым очевидным, как и опасность, которую он несет, однако стоит отметить, что очень многие команды не обращают внимания на результат. Они живут и работают просто для того, чтобы жить и работать. К сожалению, ни высокий уровень доверия в этих командах, ни конструктивные конфликты, ни высокая требовательность не могут компенсировать отсутствие желания победить.
\nСравним две команды.
\nКоманда, которой безразличен общий результат:
\nКоманда, которая заботится об общем результате:
\nЧто нужно сделать команде, чтобы оставаться нацеленной на результат? Ясно представлять себе этот результат и поощрять только то поведение, которое обеспечивает его достижение.
\n📌 Широкое информирование о желательных результатах
Когда речь идет о футбольной или волейбольной команде, самое плохое, что может сделать игрок, - это публично заявить о том, что его команда победит в предстоящей игре: подобные заявления провоцируют соперника, а это опасно. Однако для большинства команд в бизнесе полезно как раз широкое оповещение о предполагаемом успехе.
Команды, которые публично берут на себя обязательство достичь поставленных целей, приложат все усилия, чтобы не опозориться в глазах коллег. Команды, которые невнятно обещают сделать все от них зависящее, подсознательно обрекают себя на поражение.
📌 Поощрение за достигнутый результат
Очень эффективный метод поощрения заинтересованности в результате - увязать поощрения, особенно денежные, с достижением определенных целей. Однако этого мало, поскольку тогда главным мотивом становится финансовый. К тому же премирование «за приложенные усилия» при отсутствии результатов дает понять команде, что результат, в общем-то, не слишком важен.
Для преодоления порока безразличия к общему результату особенно важна роль лидера. Если члены команды поймут, что для лидера есть что-то более важное, чем результат, то воспримут это как разрешение поступать так же. Лидеры команды должны быть бескорыстны и объективны, должны поощрять и награждать только тех, кто внес реальный вклад в достижение общих целей команды.
\nКак я и обещал, прикладываю анкету, которую увидел в книге. Это самый простой диагностический инструмент для оценки восприимчивости команды к пяти порокам, которые мы только что разобрали. В конце вы найдёте краткое объяснение, как свести полученные результаты в таблицу и как работать с этими данными.
\nПо трёхбалльной шкале оцените, насколько каждое утверждение подходит вашей команде. Отвечайте откровенно и быстро.
\n3 - всегда;2 - иногда;1 - редко.Скомбинируйте ответы на вопросы как показано ниже.
\nПорок 1. Взаимное недоверие
\nВсего: __
\nПорок 2. Уход от конфликтов
\nВсего: __
\nПорок 3. Необязательность
\nВсего: __
\nПорок 4. Нетребовательность к другим
\nВсего: __
\nПорок 5. Безразличие к общему результату
\nВсего: __
\nНезависимо от ваших показателей помните, что с каждой командой необходимо постоянно работать, потому что даже лучшие коллективы неизбежно подвержены характерным порокам команды.
\nМожно много говорить о пороках и достоинствах команд, однако на деле вся командная работа сводится к нескольким основным принципам. Секрет успеха кроется не в овладении обширной теоретической базой, а в сочетании здравого смысла с высочайшим уровнем дисциплинированности и настойчивости.
\nЭто может показаться странным, но побед добиваются те команды, в которых существуют обычные человеческие взаимоотношения. Они помогают членам сильных команд преодолевать привычные обществу установки, препятствующие взаимному доверию, способности к конструктивным конфликтам, повышению требовательности и стремлению к достижению коллективного результата.
\n", "image": "https://pashlyandia.online/media/posts/5/5-porokov-komandy-3.webp", "author": { "name": "Павел Скляр" }, "tags": [ "Конспекты" ], "date_published": "2024-08-01T18:30:00+03:00", "date_modified": "2024-08-01T18:46:13+03:00" }, { "id": "https://pashlyandia.online/kak-ya-organizoval-timliderskuyu-bazu-znaniy/", "url": "https://pashlyandia.online/kak-ya-organizoval-timliderskuyu-bazu-znaniy/", "title": "Как я организовал тимлидерскую базу знаний", "summary": "Я давно хотел начать писать что-то о своей работе, но всегда ощущал себя недостойным, ведь вокруг меня находятся куда более умные люди. Однако сейчас я, наконец, взглянул на свой опыт иначе и решился: я готов попробовать блог.
\nНачать я решил с интересной, на мой взгляд, темы - как можно вести личную базу знаний всего, что происходит вокруг. Как собрать в одном месте управление командой, рабочие процессы и, самое главное, сделать это масштабируемым.
\n", "content_html": "Я давно хотел начать писать что-то о своей работе, но всегда ощущал себя недостойным, ведь вокруг меня находятся куда более умные люди. Однако сейчас я, наконец, взглянул на свой опыт иначе и решился: я готов попробовать блог.
\nНачать я решил с интересной, на мой взгляд, темы - как можно вести личную базу знаний всего, что происходит вокруг. Как собрать в одном месте управление командой, рабочие процессы и, самое главное, сделать это масштабируемым.
\n\nЯ люблю всё планировать, и статьи - не исключения. Что мы сегодня обсудим:
\nЯ пробовал множество различных инструментов для работы с текстом и хранения информации, начиная с бумажных блокнотов и Заметок Apple, и заканчивая Ulysses и несколькими другими менее известными редакторами. Однако ни один из них не смог удовлетворить мои потребности так, как это сделал Notion.
\nЧто же делает Notion таким особенным? Прежде всего, это целый конструктор. В нём всё создаётся с помощью блоков, каждый из которых может иметь свою собственную стилистику. Можно создавать заголовки, списки, разделители, цитаты, спойлеры и многое другое. Есть возможность загружать фотографии, видео и файлы, а также встраивать ссылки. Notion умеет интегрироваться с другими сервисами. Например, с Miro, благодаря чему можно встроить в свой документ целую интерактивную доску.
\nОднако самый мощный интрумент в Notion, на мой взгляд - это базы данных. Эта привычная для разработчика вещь представлена здесь совершенно иначе. Можно создавать таблицу из колонок различных типов, включая формулы для автоматического заполнения данными. Однако ключевая особенность заключается в том, что каждая запись - это отдельная страница, которую можно наполнять любыми другими блоками. Хоть создать новую базу данных внутри. Есть и различные представления этих данных, но об этом я расскажу подробнее в третьем разделе статьи, когда мы перейдём к примерам.
\nЕсли вам интересно узнать больше, рекомендую ознакомиться с руководством по работе с базами данных от NotionBox. В нём всё разложено по полочкам, ещё и картинки для наглядности есть.
\n\n\nТеперь, когда мы разобрались с инструментом, перейдем к критериям, на которые я опирался при создании рабочей базы знаний. Вот список того, что мне важно отслеживать как тимлиду:
\nРассмотрим каждый пункт подробнее.
\n\nКогда я был разработчиком, все мои задачи находились в YouTrack (как Jira, только от JetBrains). Однако, когда я перешёл на позицию лида, часть моих задач пропала с командной доски. Я начал заниматься работой с людьми, составлением планов, подготовкой ко встречам и многим другим, о чём важно не забывать и отслеживать прогресс. Также порой у меня появляются идеи, которые необходимо где-то записывать для последующей проработки.
\nДля этого мне нужен инструмент, позволяющий не держать всё в голове. В ней и так много информации.
\nЕсть у меня одна особенность - мне интересно наблюдать за людьми со стороны и записывать свои наблюдения. “Ты что, сталкер?” - зададите вы резонный вопрос. Не поверите, но это очень полезный навык! Я использую сохранённую таким образом информацию при подготовке к one-to-one встречам, при составлении планов обучения, да и в целом для анализа особенностей каждого сотрудника и нахождения верного подхода к взаимодействию.
\nПорой ко мне за обратной связью обращаются руководители других команд и подразделений, а наличие таких заметок позволит мне предоставить более полную информацию.
\nКогда мне, как сотруднику, ввели KPI, я столкнулся с одной неочевидной проблемой. KPI мы формируем в начале квартала, но у бизнеса есть свойство менять свои приоритеты. Из-за этого на сотрудников сваливается много новых побочных задач, на которые приходится отвлекаться. В этом хаосе легко позабыть о своих квартальных задачах, а когда подходит период отчётов - начинается нервотрёпка.
\nСамый простой способ избежать этого - записывать все приоритеты и регулярно проверять их. Можно фиксировать не только формулировку задачи, но и запросить Definition of Done - требуемый результат. Наличие этой информации позволит исключить двойное трактование задачи.
\nДля меня важно постоянно понимать потребности моей команды. Когда я был разработчиком, я остро ощутил на себе отсутствие регулярных встреч один на один с руководителям. Мне приходилось самостоятельно инициировать такое общение и сильно ограничивать список тем, чтобы обсудить только самое важное.
\nТолько став руководителем, я понял, почему встречи были такими редкими. Организовать их не так-то просто. Недостаточно просто добавить звонок в календарь, к нему нужно основательно подготовиться, не забыв поднять перед этим все свои заметки. Не менее важно во время разговора вести протокол, чтобы в будущем на свежую голову проанализировать встречу и подсветить для себя упущенные моменты. Наличие протокола, кстати, может пригодиться при планировании следующей встречи.
\n\nЯ всегда хотел развиваться, но часто не видел заинтересованности в этом со стороны моих работодателей. Меня выручала моя инициативность и я первый начинал разговоры об обучении, но ведь не все разработчики такие. Опыт подсказывает, что большинство из них крайне замкнутые люди, которые стесняются подойти и попросить помощи.
\nПервое, что я начал делать, перейдя на позицию лида - начал активно заниматься составлением индивидуальных планов развития для сотрудников из моей команды. Для этого мне пришлось продумывать схему проведения Performance Review, задача которого как раз понять, что интересно сотруднику и компании и как это взаимовыгодно развить. Это объёмная и трудозатратная работа, которую невозможно удержать в голове и лучше фиксировать текстом.
\n\nПереработки - тема интересная и щекотливая. Если вы уже готовите тапки со словами “ага, у них тут перерабатывают!”, то подождите, сейчас всё расскажу.
\nВ нашей компании никто не требует переработок, но так уж сложилось, что у нас работают задроты (в хорошем смысле этого слова). Некоторые любят потратить свой выходной на получение дофамина от выполнения рабочих задач, и я, к сожалению, не исключение. Благо, все согласованные переработки оплачиваются.
\nУ нас заведено правило - если хочешь поработать в выходные, сначала согласуй это со своим руководителем. Во-первых, руководство будет знать, что ты не валял дурака и тебе заплатили за результат. Во-вторых, это позволяет вносить корректировки в планирование. Мы определяем список задач, которые сотрудник собирается выполнить в выходной, после чего в понедельник происходит проверка, всё ли пошло по плану.
\nЧтобы не держать в голове задачи сотрудников на выходные, логично будет их куда-нибудь записать.
Помните, я говорил о том, что часть моих задач ушла с командной доски?
\nЗачастую это или анализ чего-либо или проработка какой-то идеи. Тематические странички позволят иметь для каждой такой задачи отдельное место, куда можно заносить все мысли и в целом вести своего рода документацию.
\nПереходим к самому интересному - примерам. Стоит признаться, что я веду свою базу знаний уже больше года и актуальная её версия - уже третья по счёту. Сначала это были простые странички, собранные в одном месте, а сейчас… посмотрите сами.
\nГлавная страница базы знаний выглядит так:
![\"Дашборд](\"https://pashlyandia.online/media/posts/3/2.-Dashbord.jpg\")
Я организовал эту страницу в виде нескольких баз данных. Быстрые действия - это кнопки, при нажатии которых создаётся запись в нужной таблице с нужным шаблоном. Под ними - список баз данных, нажав на которые можно перейти ко всем записям.
\nВ основной области находится список задач - те самые задачки-напоминания из первого критерия предыдущей главы. Под ними идут разделы с командой и внешними сотрудниками. Это тоже базы данных, только их представление сделано в виде небольших прямоугольных блоков.
\nЗавершает дашборд раздел с тематическими страницами. Это тоже отдельная база данных, в которой я веду львиную долю своих работ. Например, в этом квартале у меня в KPI заложена разработка системы обучения сотрудников и написание обучающих курсов. Для этого я создал страницу Система обучения, добавив к ней теги: Команда, Компания и Нужно сделать. Последний мне нужен для того, чтобы не потерять в общей массе страницы, над которыми я работаю.
Обратите внимание на наличие вкладок в каждом разделе. Фактически это фильтрация записей для удобного поиска нужных. Есть и обычный текстовый поиск, но за полтора года работы в Notion я им ни разу не пользовался.
\n\nПерейдём к страницам сотрудников. Все они оформляются по такому шаблону:
\n![\"Страница](\"https://pashlyandia.online/media/posts/3/3.-Stranica-sotrudnika.jpg\")
Слева я вывел оглавление для быстрого перехода к нужному разделу и такие же кнопки для быстрого добавления записей, которые вы видели ранее на дашборде.
\nДальше я разместил раздел с историей, в который делаю пометки о прошлом сотрудника до того, как он попал в нашу компанию или в мою команду. Это может быть его резюме с моими заметками, страница с онбордингом и другие интересные факты. После него идёт раздел с рабочими моментами, который сейчас состоит только из заполненных командных ролей Белбина.
\nДалее разделы идут уже в порядке важности и частоты наполнения. Первый - это KPI. Я задумал проводить регулярное их обсуждение, чтобы и я, и сотрудник понимали, что нам нужно сделать, чтобы успеть завершить каждую задачу. Внутри каждого пункта из KPI указан Definition of Done - на что будут смотреть при оценке выполнения этой задачи.
\nСледующий раздел - те самые наблюдения. Каждое из них привязано к конкретной дате и имеет свою окраску: позитивную, нейтральную или негативную. Следом идёт раздел с one to one встречами. Каждая запись содержит всю информацию: и подготовку к разговору, и план этого разговора, и протокол, и обработанные мною итоги (саммари из протокола). Возможно, я выпущу отдельную статью про то, как этот процесс происходит от и до, настолько там много нюансов.
Самый малочисленный пока что раздел - это Performance Review. Он проводится раз в полгода, поэтому и записей здесь много не будет. О его наполнении я тоже расскажу в отдельной статье.
\nИ, наконец, последний раздел - переработки. Внутри довольно простая структура из разделов Планы и Фактический результат. В первом я перечисляю договорённости с сотрудником по поводу задач, которые он хочет завершить за выходной, а во втором - что он фактически сделал.
Теперь давайте рассмотрим, что я подразумеваю под тематическими страницами. Это ещё одна база данных.
\n![\"Страница](\"https://pashlyandia.online/media/posts/3/4.-Moi-KPI-2.jpg\")
У меня, само собой, тоже есть KPI. Но так как я не веду свою отдельную страницу в разделе Команда (не буду же я о себе наблюдения записывать и проводить Performance Review?), мне нужно их как-то отслеживать. Я сделал отдельную запись и организовал там базу данных со своими KPI. Они привязаны к кварталу, имеют приоритет и статус. В целом, всё то же самое, что было на странице сотрудников.
Когда у меня запрашивают отчёт по своим задачам, я открываю эту страницу, вывожу всё в PDF и отправляю на проверку.
\n\n![\"Страница](\"https://pashlyandia.online/media/posts/3/5.-Kopilka-uspehov-2.jpg\")
Любой руководитель сталкивается с проблемой удовлетворённости от своей работы. Когда ты разработчик, всё просто - сделал задачу, её задеплоили на прод и ты увидел свою рабочую функциональность. У руководителей почти все задачи делаются на долгосрочную перспективу, поэтому и первые результаты мы можем получить через несколько месяцев, а то и через полгода.
\nЯ давно вынашивал идею, что нужно записывать свои маленькие победы и обращаться к ним в трудную минуту. Реализовал я это, как видите по датам, совсем недавно. Я записываю сюда как свои собственные победы, так и небольшие победы своих сотрудников, на которые я смог повлиять.
\n\n![\"Страница](\"https://pashlyandia.online/media/posts/3/6.-Idei-2.jpg\")
Довольно часто мою голову посещают умные мысли. Чтобы их не упустить и подумать над ними позже, я создал отдельную страницу, чтобы их записывать.
\nУ каждой идеи есть теги и статус. По умолчанию идея ждёт своего часа, чтобы я нашёл на неё время и проработал. После проработки она либо завершается успешно, либо завершается по ненадобности, когда я отказываюсь от идеи по тем или иным причинам.
\n\nВ этой статье я рассмотрел только мою рабочую базу знаний, которая относится к компании, в которой я сейчас работаю - к Читай Технологиям. Но на самом деле, создавать её можно для любой области вашей жизни.
\nНапример, у меня есть отдельная база знаний общих тимлидерских компетенций. Я записываю туда общие моменты, которые не ограничиваются какой-то конкретной компанией. Например, как проводить Performance Review или One to one, веду там конспекты разных тематических митапов и конференций, которые посещаю.
\nЕсть у меня и третья база знаний - с моей личной жизнью. В ней я храню книги, которые читал или хочу прочитать, и заметки о них. Фильмы и сериалы с аналогичной структурой, путешествия, напоминания и многое другое. Благо Notion даёт возможность организовать что угодно и масштабировать это как мне нравится.
\nЭта статья - первый шаг, поэтому я решил поделиться своим основным инструментом, который использую каждый день. Так или иначе, почти вся моя рабочая жизнь перетекла в Notion. Надеюсь, вам была полезна эта статья, а я буду очень рад обратной связи.
\n![\"\"](\"https://pashlyandia.online/media/posts/3/7.-Itogi.jpg\")