Скрининговые макропоказатели на канбан-доске

Слова-то какие, а? Внушительные.

Но в общем это довольно простая вещь.

➖Скрининговые - это позволяющие поверхностно судить о ситуации
➖Макропоказатели - значит отражающие общую картину
➖Ну а канбан-доска - это сгруппированные не завершенные задачи определенной команды

Короче, я просто не люблю называть любой объективный показатель "метриками".

Такая штука нужна, чтобы не углубляясь в детали иметь возможность оценить хорошо или плохо идут дела в организации работы или отдельных ее аспектах. Это в общем как техосмотр машины: если всё ок, то едем дальше, если что-то не так - надо заняться ремонтом. Так и глядя на доску - довольно быстро можно определить, что что-то барахлит.

Давайте представим, что у нас есть какая-то обычная кросс-функциональная команда разработки, человек 10, работаем по классике в потоковом режиме, в Jira, есть канбан-доска. На что можно обратить внимание в первую очередь (числа даю условно, но чтобы было примерно понятно):

➖Слишком много задач в работе
➖Слишком мало задач в работе
➖У конкретных людей нет задач в работе
➖Много задач с "красными кружочками" (застряли на много дней, в том числе 30+)
➖Больше 10 задач в ревью
➖На ревью задачи с "красными кружочками"
➖Больше 10-20 задач в очереди на QA
➖Больше 15-20 задач в очереди на деплой
➖Задач в очереди больше, чем пропускная способность на несколько месяцев вперед
➖Много (двузначные числа, а не единицы) блокеров
➖Слишком много (большинство или даже почти все) задач высокого приоритета

Это статические показатели.

Вот динамические, простые:
➖Очередь задач большая (на несколько месяцев вперед) и она дальше растет
➖Растет, а не стремится к нулю очередь на QA
➖Стабильно растет вообще любая очередь ожидания (деплой, ревью и т.п.)
➖Растет (стабильно или резко) количество багов по отношению к реализованным задачам

Для остальных показателей (cycle time, lead time, эффективность потока и т.п.), скорее всего уже надо будет настраивать метрики и это решение надо принимать отдельно и осознанно, просто так это не нужно. Это отдельная тема.

Соответственно, каждый показатель может быть признаком, что что-то идет не так. Расписывать, что может скрываться за каждым поста не хватит (пишите в комменты, если есть конкретные вопросы), но в общем логика должна быть такая:

Мы смотрим макропоказатели, если видим аномалии - это не причина делать конкретные выводы, а повод провести углубленный анализ и разобраться. Если аномалий нет - значит health check прошел успешно и занимаемся другими делами дальше. В идеале это делается раз в 1-2 недели.

Если у вас доска проходит этот health check, вы красавчики )

P.S. этот пост - эксперимент поделиться максимально конкретными практическими вещами, любой инфе как это заходит буду благодарен.

Как я использую схемы для планирования модернизации

Поделюсь одним из способов (их несколько), которые я применяю для размышления над тем, что стоит улучшить в работе команды разработки.

Итак, я сел думать: какая текущая ситуация и что нам нужно улучшить?

Сначала я набрасываю список критериев, которые хочу оценить - описание задач, работа с багами, какие-то конкретные частые блокеры и т.п.

Потом я делю этот список на 3 группы:
1. Работает хорошо (здесь внимание нужно минимально)
2. Работает плохо (основное внимание требуется сюда)
3. Работает средне, можно улучшить (сюда по остаточному принципу)

Эти группы - области на схеме, в них я размещаю критерии из списка.

Далее я провожу еще одну классификацию, и делю по следующему принципу:
1. Это мы можем решить своими силами
2. Это зона ответственности продакта (тут может быть любая ближайшая смежная роль или подразделение)
3. Это частично решаемо
4. Это заблокировано внешними обстоятельствами

Эти группы я размечаю цветом блоков

Далее я прикрепляю к каждому критерию свою субъективную оценку (хорошо, плохо, нормально, отлично и т.п.)

И, наконец, в секциях "работает плохо" или "средне" я набрасываю какие-то блоки, которыми можно это решить.

Получается результат как на картинке.

Если у меня есть партнер, с которым можно это обсудить - я выношу это на обсуждение и мы разбираем и критикуем эту схему, оценки и план решения. По результатам обсуждения вношу правки.

После этого можно на основании этой схемы составить перечень действий и взять их в работу. А после модернизации - сравнить как было, и как стало.

Управленческий рак

Когда я только перешел из разработки в менеджмент - я впервые пошел на совещание топ-менеджеров. Это была пятница, на совещании было 11 человек, включая гендира, директора по безопасности, Head of Product, несколько продактов и т.д. Как-либо имеющих отношение к разработке было 2 человека - я и мой руководитель (Коля, привет!) - директор по разработке.

Как обычно, когда я попадаю в какую-то новую для себя среду - я сидел тихо, наблюдал и делал заметки. И в какой-то момент я поймал себя на мысли, что 11 человек на совещании 20 минут обсуждают, что должны в следующем "спринте" делать 2 бэкенд разработчика %)

Есть такое явление - управленческий рак. Это разрастание неэффективного аппарата управления, который в итоге начинает уничтожать организацию.

Допустим, в компании есть какие-то проблемы (например, слишком много задач в очереди разработки и срочные задачи начинают копиться), и для их решения нанимается менеджер. Потом проходит время, эти проблемы не решаются, и нанимается более опытный менеджер в руководство предыдущему.

Проходит еще какое-то время, и новый руководитель продвигает найм себе в команду еще 1-2 менеджеров. Теперь начинают расти издержки на взаимодействие их между собой - открыв их календарь, вы видите много встреч по "синхронизации", где они встречаются между собой и с другими людьми чтобы все были в курсе происходящего.

Они начинают "роиться", ходить на созвоны все вместе, и их общение между собой начинает занимать от трети до половины всего их времени. При этом они всё больше и больше начинают мешать другим, так как им становится объективно нечего делать, и это свободное время они заполняют "статус чеками" и знаменитым "пингованием" (когда будет готово?), сбором информации от исполнителей, отрывая тех от выполнения работы.

А потом внезапно оказывается, что у вас уже менеджеров больше, чем людей, которые выполняют работу "руками" - то есть в данном примере разработчиков.

В приведенном выше примере в команде было 2 бэкенд разработчика, 1 фронтэнд, 1 тимлид (тоже фронт), 1-2 QA и 2-3 продакта (!) + Head of Product (!!).

И при этом еще продакты не могли нормально ставить задачи, что закончилось "костыльным" решением ввести роль системного аналитика, чтобы нивелировать неспособность продактов написать вменяемые задачи.

Причем выбраться из этой ситуации очень сложно, потому что если руководство изначально не догоняет, что это проблема, то потом это только усугубляется, так как картину мира владелец компании получает по инфе от того же Head of Product.

Это представление, что чтобы решить проблему, надо нанять менеджера, который "всё исправит" - имеет не столько рациональную, сколько идеологическую подоплеку. В данном примере ситуация была очень простая - не хватало рабочих рук. Всё, что нужно было сделать - согласовать открытие нескольких ставок разработчиков и QA, чтобы закрыть нужный фронт работ.

В итоге этот управленческий рак начинает поедать ресурсы компании, заражать здоровые клетки (демотивируя и нагружая бесполезной работой), и дальше уже зависит от силы организма (метафорически) - если у компании достаточно прибыли, чтобы терпеть эти издержки и все равно оставаться в плюсе - она будет дальше развиваться, просто медленнее, чем могла бы. Если нет - компания уходит с рынка, успешно завершив свой жизненный цикл.

"Надо сделать" - о навыке коммуникации на примере одного антипаттерна.

Помню, в детстве мне мама говорила - "надо сходить за хлебом" или, скажем, "надо попылесосить". Мне уже тогда не нравилась эта фраза (хотелось ответить что-то типа - "мне не надо"). Не только потому, что я сидел играл во что-то, и не хотел отвлекаться )

Я эту обезличенную форму обращения к мирозданию встречаю на протяжении всей своей коммерческой работы. Что с ней не так?

Допустим, вы работаете в команде. Вы разбираете застрявшую задачу. И какой-то человек говорит или пишет "надо уточнить требования по задаче". И вот что он хочет этим сказать?

Варианты:
1. В этой задаче нужно было уточнить требования, но я забыл это сделать. Сделаю (решили блокер)
2. Можешь уточнить у продакта требования по этой задаче? (просьба к другому человеку)
3. Я собираюсь уточнить требования, просто еще не успел (статус)
4. Нужно уточнить требования, но я не знаю, кто и как должен это сделать (постановка проблемы)
5. Нужно уточнить требования, но мне это не интересно/меня не касается (слив с темы)

Вы будете снова и снова сталкиваться с тем, что такая постановка задачи (а "надо" - это задача) приводит к тому, что задача не делается, или делается несвоевременно.

Проблема в общем-то не в самой фразе, а в подходе. Часто мы собираемся и обсуждаем - надо сделать это, надо сделать то, поговорили. Посуетились и довольные разошлись ) Это норм, если цель была просто получить удовольствие от общения. Если цель - достижение результатов, то это уже не очень.

Хорошая коммуникация о том, что что-то нужно сделать должна содержать следующее:
1. Действия, которые нужно совершить
2. Ответственного, который их должен сделать
(Если это что-то важное/срочное - в идеале еще временные рамки.)

То есть отвечать на вопросы - кто и что должен сделать.

Есть море причин почему используется именно такая форма - кому-то психология мешает высказывать просьбу другому человеку, кто-то не умеет в ясные коммуникации, кто-то использует это, чтобы избежать ответственности/технично слиться.

Бывает, что это норм форма - если сидят два человека, один из которых руководитель, и перечисляет другому, что нужно сделать - тут, пожалуй, однозначно подразумевается, кто. Такая форма становится болью именно в качестве коммуникации в коллективе.

Может показаться - мелочь. Скилл коммуникации складывается из таких мелочей - говорить прямо, однозначно, предоставлять достаточно информации. Потери информации при коммуникации всегда ненулевые, как бы качественно вы ни говорили. Но процент этих потерь определяет успех деятельности в куда большей мере, чем обычно принято считать.

Оценка времени на разработку

Отношение к оценке времени разработки варьируется - для кого-то это неприятная и тревожная обязанность, для кого-то привычная рутина, а для кого-то (например, для некоторых ПМов без технического бэкграунда) - основной признак хорошего разработчика.

В любом случае, это скилл, который используется повсеместно (как менеджерами, так и исполнителями) и сильно влияет на то, как ваш профессионализм оценивают окружающие.

Этот пост - краткое введение в тему: какие оценки бывают, чем отличаются, как применяются.

Во-первых, есть оценки трудозатрат и оценки сроков. Второе часто вытекает из первого.

Оценки трудозатрат - это когда мы пытаемся заранее понять необходимый объем работы.
Например: "такую задачу делать неделю".
Область применения - например, при расстановке приоритетов надо понимать сравнительный размер разных задач/проектов, чтобы с учетом размера определить, что стоит делать первее.

Оценки сроков - это когда мы пытаемся заранее угадать, когда задача будет завершена (например, поставлена в продакшен).
Например: "это задача будет на проде через 2 недели - в понедельник".
Область применения - от согласования деятельности разных отделов до анонса багфикса клиентам.

Во-вторых, бывают оченки в единицах времени и в "попугаях" (условных единицах).

Оценка во времени - это в часах/днях и т.п. Это также делится, например, это могут быть идеальные человеко-дни (условные трудозатраты) или реальные (с учетом реальной загрузки, для оценки сроков).

Оценку в условных единицах используют с различными целями, в которые я тут не буду углубляться. Частый пример - сторипоинты, которые обозначают условную сложность задачи, и в последующем конвертируются в представление об объеме работы (а тот - в сроки).

Кроме условных оценок в числовых единицах еще есть упрощенные условные оценки - например, система "маек" - XL, L, M, S, XS - это отражает примерный размер задачи (допустим L - до недели разработки).

В-третьих, оценки делятся на прогностические и эмпирические.

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

Второй вариант - эмпирический - это когда мы используем данные в объективном виде. Например, мы имеем 3 месяца данных о сроках выпуска задач, и знаем, что задача примерно такого типа с таким приоритетом выпускалась через 2 недели от старта разработки, максимум через 3. Значит, из предыдущего опыта, мы можем сказать, что и с этой будет так же. Тут мы не пытаемся делать прогнозы, а просто смотрим, что получается, и экстраполируем это в будущее. Остается тогда вместо времени оценивать относительный размер или сложность задач.

В-четвертых, оценки делятся на индивидуальные и групповые.

Индивидуальные - организационно просты, по сути просто кто-то пользуясь своими методами выдает оценку.

Групповые могут понадобиться в двух случаях:

1. Работает команда, и надо учитывать и согласовывать работу разных людей
2. Есть цель сделать оценку менее зависимой от мнения 1 человека, поэтому несколько людей дают оценку одной и той же работе, а потом группа обсуждает эти мнения (например - в формате planning poker, об этом можно почитать отдельно).

Наконец, в-пятых, оценку можно давать своей работе или чужой.

Оценка своей работы в целом предпочтительна, так как она соединяет собственно оценку и ответственность за результат. Это тема отдельного поста, но в общем в большинстве случаев можно подсуетиться и постараться попасть в оценку. Соответственно, человек более склонен стараться соответствовать своим собственным словам.

Оценка чужой работы - инструмент, который может использоваться для контроля или проверки (в том числе постфактум). Например, тимлид сам делает оценку задач для своей команды или менеджер анализирует объем работы, выполненный за квартал кем-то из лоу-перформеров.

Резюмируя, есть оценки:
➖объема работы и даты завершения
➖в единицах реального времени и в условных
➖в форме прогноза или использующие предыдущие данные
➖индивидуальные и групповые
➖своей работы или чужой

У каждого варианта своя область применения, и в рамках работы одной команды могут использоваться сразу почти все.

P.S. если вам нравится контент, вы можете поддержать канал, переслав пост людям, которым он тоже может быть интересен и/или полезен, а также поделиться своими мыслями или задать вопрос в комментариях 🤝

Точность оценки

Давайте теперь углубимся в один аспект оценки сроков - точность прогноза.

Точность - это не только качество (типа: хорошо оценили - это точно, а плохо оценили - значит, неточно).

Так как оценка - достаточно трудоемкий процесс (бывает сделать быстрее, чем точно оценить), то управление степенью точности - это рабочий инструмент менеджера.

Есть три основных подхода к точности оценки в зависимости от применения:

1. Грубая оценка - это обычно интуитивное оценочное суждение, "из головы", без расчетов. Может быть выдана за минуты, на основании задачи в общих чертах, на опыте.

Назначение - например, для принятия решения делать/не делать (сравнивается ценность и стоимость - "это слишком долго/дорого, не стоит того"). Или для решения о приоритете ("раз это долго - отложим, а вот эту маленькую возьмем первой").

2. Расчет планового срока - это уже требует трудозатрат на анализ - расчетов, углубления в детали задачи, возможно декомпозиции, рисования схем. Может занимать от десятков минут до часов (это зависит от объема анализируемого). Оценка дается таким образом, что есть высокая вероятность (скажем, 80%) попасть в срок, и если сроки едут - это терпимо.

Назначение - когда действительно важно знать ориентировочную дату выпуска (например, чтобы согласовывать действия разных команд или планировать что-то, что зависит от завершения).

Альтернативное назначение (которое я считаю довольно токсичным и не конструктивным) - попытка таким образом подгонять разработку. Существует достаточно распространенное мнение, что если ставить сроки - то будет сделано больше работы.

3. Расчет дедлайна - это расчет даты, к которой точно будет готово, насколько это возможно. Как правило, это требует полноценного анализа и проектирования. В этом случае, чтобы минимизировать возникновение подводных камней - ключевая часть R&D должна быть произведена до начала работы. И здесь должны подробно учитываться всевозможные маловероятные риски (такие как болезни, увольнения и т.п.), на которые можно закрыть глаза в предыдущих вариантах.

Зачем это может быть нужно - например, запуск к публично анонсируемой дате. Или работа на другую компанию по договору.

Что еще важно знать про точность - то что люди очень часто путают разные типы оценок. Например:
1. Не понимают какую оценку они запрашивают и получают (типа, оценка есть оценка)
2. Берут грубую оценку, а используют как плановую (взял у разработки грубую оценку, пошел отчитался руководству о том, когда будет готово - супер частый кейс)
3. Берут плановую оценку, а воспринимают как дедлайн (болезненно резко реагируют на сдвиг сроков)

Такие ошибки ведут к росту напряженности, снижению доверия в компании.

Если вы - тот человек, который запрашивает оценки сроков, то стоит ясно коммуницировать какой тип оценки вы хотите получить и для чего. В этом случае результат вас удовлетворит с куда большей вероятностью.

А если тот, кто делает - возможно, стоит уточнить эти вопросы самостоятельно, и помочь человеку, который в этом еще не разобрался. И переслать ему этот пост )

Как обсуждать сроки разработки

Еще на шаг углубляемся в тему оценки, разберем уже совсем конкретную вещь - как менеджер может говорить об оценке сроков с исполнителем.

Допустим, вы менеджер в плюс-минус обычной команде, и какой-нибудь head of product запросил у вас сроки, вам нужно понять время разработки какой-то фичи. Берем самый простой вариант - вы спросили того, кто будет это делать (предположим, вы первый раз с этим человеком обсуждаете сроки), и он назвал свою оценку (скажем, 5 дней или месяц).

Ваши дальнейшие действия?

Здесь лучше на минутку задержаться и подумать над опциями самому, а потом читать дальше.

Популярные варианты, как я их вижу, следующие - тупой, ленивый и нормальный.

Тупой вариант это: тебе исполнитель сказал 5 дней, ты пошел и передал - 5 дней.

Ленивый вариант (очень популярный) - ты уточнил на что именно 5 дней (разработку до ревью, или до QA, или ready for deploy, или еще как-то). Дальше молча добавил от себя еще какой-то срок, и пошел передал заказчику. Дальше у исполнителя свой срок, а у заказчика твой - с запасом.

Норм вариант - исполнитель дал какой-то срок, допустим, время до QA. Ты поясняешь, что он не учел в своем расчете, что (например) еще есть время ожидания начала тестирования, есть время на деплой и т.п. Ты учитываешь все эти факторы и называешь (предлагаешь) ему какой-то срок, поясняя из чего он состоит. Дальше он делает замечания и/или соглашается. Эта договоренность фиксируется (например, пишется в задачу в Jira), и он же транслируется заказчику, команде и т.п.

Почему так лучше?

➖во-первых, это нормально работает. Повышает вероятность успешного прогноза
➖во-вторых, это позволяет другим членам команды нормально прокачиваться в навыках оценки и командной работе
➖в-третьих, 1 и 2 варианты приводят к выработке безразличного отношения к оценке, потому что с перспективы исполнителя они ничего общего с реальностью в итоге не имеют
➖наконец, это просто нормальное человеческое отношение к коллегам - в норм варианте коллега не объект, используемый как инструмент достижения цели, а равный участник решения задачи, а это основа нормальных доверительных отношений в команде

Это норм вариант, чтобы не оказаться в ситуации, когда всех постоянно пингуешь, а потом сидишь и задаешься вопросом - "почему кроме меня здесь никому ничего не надо?".

P.S. если вам нравится контент, вы можете поддержать канал, переслав пост людям, которым он тоже может быть интересен и/или полезен, а также поделиться своими мыслями или задать вопрос в комментариях 🤝

Время для внеплановых сообщений. Поэкспериментировал с последними тремя постами - покрутить одну тему (работу со сроками), каждый раз углубляясь на шаг в ее раскрытии. По итогу вышло, что за три больших поста получилось только поскрести по ее поверхности. В таком формате сложно достаточно раскрывать явление во всей глубине.

Выходит забавно, что о такой теме, которая, в сущности, в моей деятельности имеет довольно мизерный характер (условно, какие-нибудь 3-4 процента времени меня занимают сроки) - можно сделать и 5, и 10, и более постов. Или разговаривать несколько часов.

Например:
➖рассказать мой опыт оценки сроков при сдельной работе на аутсорсе, чему это меня научило
➖про холивар между прогерами, одни их которых за оценку по факту, а другие - за оценку от лица "среднего человека, который бы делал задачу"
➖история, когда один ведущий разработчик недооценил проект и решил пару месяцев работать бесплатно
➖как мы в продуктовой разработке оценили проект на неделю, поставили две с запасом, а делали в итоге 3 месяца
➖как я придумывал и внедрял механизм по расчету стоимости проектов на основании данных Jira
➖про то, как работает учет часов, во что это выливается и почему это хрень, в деталях

Ну и так далее.

Думаю, как-нибудь мы поразгоняем подобные крупные темы в формате видео или стримов.

Кстати, я сам читаю свои посты, когда они выходят. Обычно проходит прилично времени между тем, как я их написал, и их плановым выходом, поэтому они подзабываются, и я читаю их как что-то новое ) Конкретно про оценку сроков мне было скучновато. Но, может быть, это потому, что мне это слишком понятно? Сложно поставить себя на место того, для кого эта информация - новая.

Второе внеплановое сообщение. На этой неделе было кое-что особенное - у меня произошла официальная смена тайтла на Head of Development.

По факту я уже исполнял эту роль какое-то время, и, наверно, это можно было бы сделать раньше, но я специально откладывал. Говорят, заслуженно получать то, чего хочешь - доставляет гораздо больше удовлетворения. Я тоже играю в эти игры.

Так что есть что отметить - больше не придется объяснять во время нетворкинга, что такое engineering manager )

Бонусом больше всего запомнившийся мне фидбек с одного из 360° на роли Senior Technical Project Manager. Anonymous оставил след в моем сердечке:

"Мне иногда кажется, что Павел - это своего рода сверх AI, настроенный специально, чтобы повышать эффективность работы всего *название компании* и его структуру *названия команд разработки* (Не могу представить себе, как можно следить за всеми командами одновременно и корректировать их работу)"

Cheers.

Третье и последнее на сегодня внеплановое сообщение - добавил контакт для связи в описание канала. Если что, друг, не тушуйся - пиши по делу или по кайфу. Сейчас есть возможность расширять круг общения. Кто знает, что будет завтра.

Как происходит работа с приоритетами

Я с удивлением обнаружил не так давно, что даже менеджеры с большим опытом (не из разработки, но из айти компании) могут не знать, как команда разработки оперирует приоритетами.

Сейчас расскажу.

На очень базовом уровне у людей есть представление, что приоритет отвечает за то, что будет взято в работу первее. И все. В нормально работающей команде это не так.

Я перечислю факторы, которыми, например, может оперировать команда (часто менеджер команды) на основании заданного приоритета:

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

Последний пункт означает, что есть какой-то нормальный темп работы, который команда может долгосрочно поддерживать, и его можно временно повысить ради срочной задачи (и то не всегда). И это нельзя делать постоянно - приведет к дизморали и будет даже хуже, чем по дефолту. Но это стоит отдельной темы про то, как устроена производительность в разработке.

Как видно, есть очень много скрытых от поверхностного наблюдателя и неочевидных механик, связанных с тем, как по разному выполняются, например, срочные и несрочные задачи.

Именно поэтому нас так раздражает, когда системой приоритетов пользуются грубо и небрежно.

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

Из моей практики, в нормальной ситуации есть примерно такие приоритеты работы, смысл которых люди интуитивно понимают и действуют соответственно (по разному):

1. Критичный (Critical/panic/emergency) - "все бросаем и делаем это"
2. Срочный - как можно быстрее берем в работу и делаем максимально быстро, но без ущерба другой важной работе
3. Просто высокий - плановая работа (не срочная), но подчеркнуто важная. Нужно обеспечить выполнение без задержек
4. Обычный плановый приоритет, но важные - вообще не срочные, но ценные - не торопимся, но сделать надо
5. Обычный приоритет и не особо важные - вообще не паримся. Такие можно и дропнуть в пользу важных
6. Низкий приоритет - то, что мы делаем когда нечего делать

В конкретной компании, естественно, называться и объясняться может это по разному. Каких-то приоритетов может не быть, какие-то могут быть дополнительно к этим. Какие-то могут быть не в системе, а на уровне разговоров и неформальных просьб.

Это может выглядеть несколько сложно на первый взгляд (и граница между 3 и 4, например, тонкая), но это максимально близко к тому, как на моей практике людьми понимаются и исполняются приоритеты. То есть это - отражение реальности, и скорее открытие/наблюдение, чем изобретение.

Если же в компании приоритет означает лишь то, что будет взято в работу первее - вероятнее всего, это означает, что там просто забили болт на все перечисленные сложности и нюансы, занизили производительность и едут по накатанной.

Корпоративная культура, но по нормальному.

При упоминании корпоративной культуры - миссии, ценностей и т.п. - разработчик резко грустнеет. Корпоративная культура - это когда все собираются, кто-нибудь из топ-менеджеров рассказывает какие-то пафосные слова и тезисы, красиво звучащие, ничего не означающие и ничего не добавляющие к реальной работе.

Допустим, вы в общепите и вам рассказывают про ценности вашей компании: Вкус, Качество, Доступность, Открытость.

Или вы в технологической компании: Взаимодействие. Инновации. Благосостояние. Включенность.

Ну что это за херня? %) Унылая. Так многие подумают, но почти никто не скажет.

При этом, несмотря на подобную встречающуюся повсеместно профанацию, корпоративная культура реально существует, и я сейчас попробую объяснить, почему это имеет огромное значение, в том числе лично для тебя.

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

Примеры реальных ценностей, определяющих то, как будет выглядеть для вас работа:

➖Честность или манипуляции
➖Веселье или серьезность
➖Рациональность и аргументация или вера и вдохновение
➖Жесткая иерархия или децентрализация
➖Неформальность или корпоративная бюрократия
➖Инициативность или исполнительность
➖Плюрализм или авторитаризм
➖Увлеченность или "просто работа"
➖Токсичность или доброжелательность

И это не булево (да/нет), а шкалы, и каждой компании может быть ближе тот или иной полюс. И это не значит, что там все будут такие, одинаковые. Это значит, такая характеристика будет доминировать в коллективе и проявляться чаще.

И вот эти вещи (в отличие от красивых слов типа "для нас потребности клиента на первом месте") - действительно имеют значение.

Есть такое понятие - cultural misfit (культурное несоответствие) - это когда у человека несовпадение с какой-то культурной средой.

Представьте - ты любишь на работе расслабленную атмосферу с шутками, а все вокруг серьезные и надувают щеки. Или наоборот - ты привык очень серьезно относиться к делу, а вокруг постоянно орут, смеются и мешают сконцентрироваться.

Или ты хочешь просто делать свою часть работы, а от тебя требуют инициативы.

Или приходишь к руководителю с предложениями, а он отвечает: "тебе что, нечем заняться?".

Или ты увлечен и тебе хочется фигачить, а вокруг все вальяжно прохаживаются по офису с чашкой чая и бездельничают.

В лучшем случае культурное несовпадение доставляет дискомфорт и демотивирует. В худшем - делает нас действительно несчастными.

Важно понимать - корпоративная культура в общем случае распространяется сверху вниз. Так уж в целом мы устроены, что "вес" культурного влияния тем выше, чем выше позиция в компании. Это не значит, что нельзя сделать свой культурный анклав внутри компании, но все равно остальные будут на вас сильно влиять.

И раз уж мы тут про менеджмент, у этого есть еще одно важное свойство - культурное совпадение (или несовпадение) определяет вашу карьеру в конкретной компании. Как сказал один мой друг, "если хочешь сделать карьеру в компании - посмотри, хочется ли тебе выпить пива с ее топ-менеджерами".

Не думаю, что это так в точности работает (по крайней мере было бы грустно, так как я не пью), но в этом явно есть смысл.

Среди гостей нашего канала есть разные таланты ) зацените дебютный ролик отличного парня Жени Назирова https://youtu.be/7WlwIpzzYgU

К посту про корпоративную культуру сегодня появился интересный коммент, который стоит отдельной публикации в канале.

Вообще тот факт, что Пол (Paul Griffiths), чтобы читать посты, переводит их нейросеткой на английский, а когда пишет - переводит на русский, уже сам по себе заслуживает уважения )

Ну и вдвойне приятен развернутый комментарий от человека, который на две головы выше меня в кадровых вопросах.

Вот:

"Ответ директора по персоналу – Технологическая компания

Спасибо за столь яркое и честное размышление о корпоративной культуре. Как человек, много лет проработавший в HR — зачастую в самом центре «бури миссий и ценностей» — я не раз кивал в знак согласия, читая ваш текст. Вы очень точно уловили то ощущение разрыва, которое испытывают многие сотрудники между заявленной культурой и реальной повседневной рабочей средой.

Вы абсолютно правы: когда корпоративная культура сводится к лозунгам — она теряет смысл. Более того, она порождает цинизм. Людям не нужна «стена с ценностями» в холле офиса — им нужны лидеры, которые действительно демонстрируют эти ценности в своих действиях: на встречах, при принятии решений, при продвижении сотрудников и в ситуациях конфликта.

«Веселье или серьёзность. Инициативность или исполнительность. Плюрализм или авторитаризм.»
Ваши шкалы — отличная находка. На самом деле, мы используем похожий подход при анализе нашей культуры. Команды внутри компании, конечно, разные, но в каждой организации существуют преобладающие черты, определяющие стиль взаимодействия. Их важно не только признавать, но и осознанно формировать, а не прятать за корпоративными красивостями.

Позвольте добавить несколько наблюдений с точки зрения HR:

1. Культура — это стратегический актив (или пассив)
Культура — это не просто атмосфера, это усилитель. Команды с сильной культурной согласованностью быстрее решают проблемы, легче общаются и дольше удерживают таланты. При этом, как вы справедливо заметили, культурное несоответствие не означает, что сотрудник плохой — просто это не та среда, где он может реализовать себя.

2. Культура сверху вниз — это правда, но не вся
Вы правильно отметили, что культура, как правило, идёт сверху. Поэтому развитие лидерства для нас — один из ключевых инструментов. Но влияние коллег не менее значимо. Микрокультуры формируются вокруг тимлидов, неформальных лидеров и даже внутри отдельных Slack-каналов. Умные компании инвестируют в выявление и поддержку таких носителей культуры на всех уровнях.

3. Культура без подотчётности — это просто декорация
Мы ушли от формального опубликования «ценностей компании» и задаём себе вопрос: А как эти ценности проявляются в найме, продвижении и ежедневных решениях? Например, если мы говорим, что ценим «открытость», но при этом руководство наказывает за инакомыслие — настоящая культура очевидна. Культура — это не то, что мы говорим, а то, что мы делаем.

Если бы вы выступили с этим текстом на внутреннем митапе — я бы, как HR-директор, с радостью пригласил вас на кофе. Нам нужно больше таких голосов — честных, умных и заинтересованных в том, чтобы работа была осмысленной, а культура — живой."

Маринование задач

Погнали в мрачные закоулки управленческих инструментов. Далеко не обо всех приемах управления услышишь на конфах, потому что там такая атмосфера - "мы вместе дружно делаем общее дело". Реальность зачастую гораздо более серьезная и темная - борьба за ресурсы, манипуляции, выстраивание личных связей, конфликты интересов.

Начну с чего-то очень простого и в целом относительно безобидного - маринования задач. Это когда искусственно притормаживается выполнение задачи. Типа, "помаринуем пока эту задачу".

Цель этого фокуса - ожидание, что если задачу не делать, она "рассосется". То есть про нее забудут, или она будет сдвинута чем-то более приоритетным, и ее вообще не нужно будет делать.

Зачем это делают? Причины могут быть разные, например:

➖Менеджер оценил задачу как вредную или бесполезную, но при этом не хочет идти на открытый конфликт
➖Команда перегружена и таким образом выясняется, какие задачи "действительно нужны" - те, про которые кто-то вспомнит хотя бы еще 1 раз. Аналогично если перегружен сам менеджер
➖Нет ясной и работающей системы приоритетов, и таким образом с помощью маринования "на глаз" выясняется реальный приоритет
➖В компании идут какие-то подковерные игры и у менеджера есть мотив двигать вперед задачи одних людей и тормозить задачи других людей, чтобы зарабатывать очки в этой игре
➖Задача поставлена кем-то, кто не имеет полномочий, и менеджер не хочет создавать прецедент расширения фронта своих работ (и зоны ответственности)
➖Просто лень и хочется поменьше работать

И так далее.

Чаще всего это происходит при взаимодействии между отделами, особенно если это не основной заказчик.

Вы очень редко столкнетесь с тем, что кто-то будет явно отказываться делать что-либо, гораздо чаще - с разными формами саботажа, и маринование - одна из них.

Какие есть варианты контригры?

Во-первых, если это вы ставите кому-то задачи, убедитесь, что ваши задачи - не полная херня. Имеют какое-то разумное обоснование и бизнес-ценность. И что вам они действительно нужны. А то мало ли.

Если ваши задачи норм, и вы считаете, что вас динамят нелегитимно, можно попробовать следующие варианты:

1. Пинговать. Спрашивать статус задачи, узнавать когда будет сделано и т.п. Способ самый простой, но довольно утомительный.
2. Обсудить формат взаимодействия - расспросить по какому принципу задачи берутся в работу, как работают приоритеты, статусы и т.п.
3. Если взаимодействие регулярное, сделать раз в пару недель плановую встречу, где вы будете обсуждать статус вашего общего фронта работ
4. Попробовать завязать хорошие отношения с руководителем соответствующего отдела, чтобы перейти из категории NPC в игровых персонажей - а это резко снизит вероятность, что вас будут мариновать

В целом, важно понимать, что люди редко упорствуют в мариновании задач - в том и суть приема, что если ситуации оказывается сколь-нибудь существенное внимание, то никто не будет настаивать. Поэтому любое привлечение внимания или налаживание системного взаимодействия, скорее всего, устранит проблему.

P.S. возможно, кто-то из присутствующих здесь именно ради таких историй - инсайдов об изнанке менеджмента, про которые не узнаешь из большинства популярных ресурсов. Если это так - дайте как-то о себе знать, чтобы мне понимать, какой контент больше интересен. Ну и зашерьте заодно, если понравилось.

Сидел сегодня думал над одной из следующих тем - "как я оцениваю людей в команде" или типа того. Пока крутил в голове эту тему, которая, в общем-то, с трудом укладывалась в один пост, пришла в голову мысль просто включить видео и в формате импровизации ее развернуть.

Получился получасовой видос, записанный в зуме на старую камеру, так как у меня еще ничего толком не было готово ) На публичный дебют на ютубе не тянет, но залить и расшарить по ссылке - вполне норм.

Как выяснилось, в Казахстане еще и не работают sms-коды, чтобы зарегать канал на ютубе. Заливать просто в телегу не хочу - тут плеер неудобный. В общем, как только решу технические вопросы, так сразу )

Забавно, что на свежем канале, походу, нормально превью еще даже не работают. В общем ловите ) https://youtu.be/-tsvCDTNlYk

Время как рычаг в переговорах

Развивая тему всяких темных приемов. Этот не относится конкретно к менеджменту, но в нем тоже применяется, так как достаточно универсален. Это прием использования затягивания времени как рычага при переговорах о заключении сделки.

В любой сделке есть некая динамика в пользу одной из сторон. Кому-то решение нужно сильнее в данный момент. Например, когда мне вырезали аппендицит, то врач, который хотел получить взятку, пытался затягивать время, чтобы увеличить рычаг давления на вторую сторону. И лишь поняв, что сделка на его условиях 100% не будет заключена, решил отступить. Там где есть торги и срок имеет значение - это применяется достаточно широко.

Теперь ближе к нашей теме. История моя.

Расклад был такой:
1. Компания искала человека на должность delivery manager (разновидность проектного менеджера).
2. Пара кандидатов слились уже после того, как пришли на работу.
3. Я там работал прогером и проявлял повышенную организационную активность.
4. Мне решили предложить занять эту позицию.
5. Я сильно хотел перекатиться в менеджмент.

Естественно, сторонам не было все это известно на момент сделки.

В начале была динамика такая - кто-то из топов (уже не помню кто) никак не может закрыть позицию. Мяч на стороне потенциального кандидата.

После этого я предложил ряд улучшений, и мне предложили занять эту позицию. Я с радостью согласился, и сразу начал делать это.

Здесь динамика меняется - потребность найти человека уже закрыта. А я хочу получить хороший оффер. Теперь мяч на стороне гендира.

И гендир применяет этот прием - он начинает просто тянуть время. Со мной никто никак не обсуждает промоушен.

Изменение моего отношения во времени:
➖спокойное ожидание переговоров и обсуждения условий
➖беспокойство, что может быть что-то срывается, тревожное ожидание
➖"хоть бы как-нибудь уже закончить, пофиг на условия"

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

Я подписываю, так как уже устал ждать, не хочу бодаться и не готов вставать в позу и снимать с себя уже взятую ответственность. Карты уже открыты, ставки сделаны, ставок больше нет )

Хоть я и сделал свои выводы и срулил потом на норм деньги в другую компанию, но история не об этом - гендир свою цель по переговорам этим приемом легко прожал.

Естественно, я это считаю раком, и не рекомендую эксплойтить, но знать надо в том числе и для защиты. Ведя переговоры, стоит поразмыслить:

➖над тем, что нужно каждой стороне и как сильно
➖на чей стороне сейчас мяч
➖на кого играет время
➖как может поменяться ваша репутация в ходе переговоров

Оценив динамику, если она в вашу пользу - можно не торопиться и спокойно договариваться "на берегу". Если не в вашу - наверно, стоит брать что дают и не париться. И взять свое в следующем раунде.