В среду, 24 мая, 19.00 мск будет вебинар "Как увольнять и не лишиться поддержки команды?" от OTUS.

Расскажу, как правильно вести себя тимлиду/руководителю во время сокращений, как не наломать дров и не демотивировать вообще всю команду.

Регистрируйтесь и приходите поучаствовать!
https://meetup.otus.ru/team-reduction

Собрал воедино весь тредик про инструменты аудита команды. Получилась развесистая статья. Зато теперь удобно, не надо скакать по разным постам 🙂
https://habr.com/ru/articles/736908/

ИДЕАЛЬНЫЙ МЕНЕДЖЕР (АДИЗЕС)

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

Если повторить ее суть вкратце – менеджер должен выполнять и совмещать в себе 4 основные роли:
- Производитель (P) – сделать результат здесь и сейчас
- Администратор (A) – все настроить и добиться эффективности быстро
- Предприниматель (E) – придумать, как добиться успеха вдолгую
- Интегратор (I) – заставить всех работать вместе, добиться эффективности в стратегическом плане

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

Ну и отсюда появляются идеальные портреты разных руководителей:
- Тимлид – pAeI
- Техлид – PaEi
- CTO – pAEi

И т п. А идеальный менеджер, стало быть будет PAEI. И по мнение самого же Адизеса, его не существует.

Да и вы в моменте можете не соответствовать ожидаемой модели. Очень много начинающих тимлидов с портретом PaeI, а начинающих CTO – с PAei. Ничего не поделаешь, по щелчку пальцев сразу не поменяешься.

Что делать? Дополнять. Выделять дельту и заполнять ее. И для этого можно выделить несколько вариантов:

1. Развивать – прокачивать слабые роли:
- p → P: хард-скиллы
- a → A: процессы, системность
- e → E: стратегия, кругозор
- i → I: эмпатия, софт-скиллы

2. Дополнять – за счет привлечения к управлению сотрудников своей команды или кого-то извне:
- p → P: Senior-ы, Techlead
- a → A: Project Manager, Scrum-master
- e → E: Product Manager, Product Owner
- i → I: HR

3. Усилить команду – перебалансировать роли, чтобы стало больше таких, которые проседают у вас (вспоминаем модель Белбина):
- p → P: Исполнитель, Мотиватор, Педант
- a → A: Координатор
- e → E: Исследователь, Генератор идей
- i → I: Душа команды

Вот такой рецепт. Проверено – работает!

ПРО УВОЛЬНЕНИЯ #2

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

Первое, что может помочь – инструмент “ошибка/проступок”. Если четко понять разницу между ними, становится гораздо проще.

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

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

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

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

Так вот, за ошибки не увольняют. Ошибки, как правило, подсвечивают системные проблемы: изъяны процессов, недоработку руководителей и т п. Ну и в конце концов, все люди, все могут делать ошибки. А вот проступок не подсвечивает ничего, кроме того, что сотрудник игнорирует правила. Игнорирует ваши с ним договоренности, контрактинг. И вот за проступки увольнять стоит. Сразу же или дать шанс – решать вам. Но обратить на это внимание и обработать такую ситуацию точно следует. Самым жестким образом.

И еще один момент. Необработанная ошибка – это проступок руководителя. Любая ошибка должна быть исправлена. Причем исправлена в будущее, чтобы предотвратить повторение. И это задача руководителя.

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

Продолжение следует.

Видео вчерашнего эфира "Как увольнять и не лишиться поддержки команды?"

https://www.youtube.com/watch?v=s4_ynRUy4a8

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

Внутри немного рекламы OTUSа, но и контент, вроде бы, ничего 🙂

МОДЕЛЬ БЕННА И ШИТСА

Готов поспорить, про эту модель вы раньше не слышали. Во всяком случае, я сам на нее наткнулся совсем недавно. В отличие от популярных Такманов и Белбинов, про эту модель почти никто не говорит и не пишет. А зря.

Это снова модель про командные роли. Выделяется 3 основных уровня ролей:
1. Целевые роли – роли, связанные с выполнением непосредственно работы
2. Социальные роли – роли, способствующие позитивному функционированию коллектива
3. Дисфункциональные роли – роли, замедляющие продвижение к цели и ослабляющие сплоченность коллектива

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

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

А вот дисфункциональные роли – это что-то новенькое. Бенн и Шитс выделили 9 таких ролей:
- Агрессор
- Блокирующий
- Ищущий признания
- Исповедник
- Нарушитель/Бунтарь
- Playboy/Playgirl
- Доминирующий
- Ищущий помощи
- Преследующий свои интересы
Думаю, пояснять не нужно, из названия понятно, кто из них про что.

Так вот, основная идея модели включает 2 шага:
1. Проверить наличие Целевых и Социальных ролей, добавить недостающие и создать баланс
2. Отыскать все присутствующие в команде Дисфункциональные роли и устранить

Как устранить? В позитивном сценарии – перевоспитать плохиша. В негативном – убрать из команды.

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

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

Вот такой инструмент в копилочку. Как по мне – полезный.

ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ

Анонс моего МК на Skolkovo Tech Week - 28 июня в секции MANAGEMENT, буду рассказывать, как тимлид может стать ключевым звеном в изменении корпоративной культуры

Видео с вебинара "Я тимлид. Что дальше?" - рассказывал про роль Delivery Managera и про курс, который запускаем в OTUS

Пост про модель Мамонта - простая модель для целеполагания команды

Пост про то, как развалить команду - отпичные ошибки руководиелей в формате вредных советов

Пост про увольнения #1 - о том, как относиться к увольнениям, как научиться принимать эти решения

Небольшой кейс - проведенное корпоративное обучение по наставничеству

Пост про DISC - простая модель типизирования психотипов

Ссылка на статью про инструменты аудита команды - собрал в одном месте весь тредик из чата

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

Пост про увольнения #2 - разбор отличия ошибки и проступка, за что нужно увольнять

Видео с вебинара "Как увольнять и не лишиться поддержки команды" - о том, как вести себя руководителю, если ему приходится заниматься сокращениями, чтобы команда не развалилась

Пост про модель Бенна и Шитса - не самая популярная модель, выделяющая основные дисфункциональные роли в команде

Продолжение следует!

ВОПРОСНИК #14

Вопрос от @darya_samoylenko по мотивам вот этой статьи.

Вопрос:
Здравствуйте! Очень понравилась статья про People Management, подскажите, пожалуйста, в каких программах вы измеряли Тим-мораль и какой ERP-системой вы пользовались для измерения People Status?

Ответ:
Перво-наперво, спасибо за ваш вопрос, Дарья, и за фидбек. Рад быть полезным!

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

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

Теперь про People Status. Начинали мы также с гуглоформ. И это было неудобно, поскольку возникает проблема секьюрности. Мы пытались закрыть информацию об оценке человека от самого человека, и не показывать эту информацию никому, кроме руководителей человека и HR-ов. В простом варианте это означало примерно мильен разных форм и гуглодоков к ним, чтобы на каждую команду и на каждый уровень иерархии. А в сложном – когда кто-то переходил в другую команду или повышался, нужно было создавать новый файл. Почему? Потому что гугол хранит историю изменения документа, абсолютно всю.

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

Некоторое время назад, когда мы выходили на рынок РФ, мы делали маркетинговый анализ. Искали похожие сервисы, как наша внутренняя ERP. Хотели сделать из нее продукт, смотрели перспективы. Так вот. Готового инструмента со встроенным похожим функционалом мы не нашли. На следующей неделе наши HR даже сделают доклад на HR-API по этому поводу 🙂

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

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

Надеюсь, получилось ответить на вопрос.

P.S. Пишите свои вопросы и кейсы вот в эту форму https://forms.gle/aBX5PgU1CLU4FDPP8

В эту среду, 31 мая, в 20.00 МСК провожу открытый урок курса Тимлид в OTUS.

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

Зарегистрироваться можно по ссылке https://otus.ru/lessons/teamlead2-0/#event-2925

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

https://habr.com/ru/companies/otus/articles/738824/

В первую очередь, статья для Delivery Manager-ов и CTO (да-да, это все в предверии старта нового курса для DM, все верно). Но может пригодиться и самим тимлидам.

А еще по этой же теме проведу открытый урок 7 июня в 20.00 мск. Зарегистрироваться можно тамже в статье. Или ссылочку положу в комменте.

ПРО МЕТРИКИ ПРОЕКТА

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

H → Happiness — польза для клиента: метрики лояльности
E → Engagement — вовлеченность ЦА: метрики взаимодействия
A → Adoption — принятие: показатели роста новой аудитории
R → Retention — удержание клиентов: показатели удержания и оттока
T → Task Success — успех внедрения и продвижения продукта: финансовые показатели

Задумался, а есть ли что-то подобное для проектов? Иными словами, как понять, является ли ваш набор проектных метрик полным и достаточным, чтобы ничего не упустить из виду? Гуглил и искал – ничего (может плохо гуглил, конечно).

Но грустить я не стал, и решил состряпать такой инструмент сам 🙂 Не ну а чего.

Итак, представляю вашему вниманию инструмент PROJECT. Также как и HEART, он раскрывает основные фокусы внимания и наблюдения за проектом, чтобы ничего-ничего не прошло мимо вас.

P → People – команда проекта и ее состояние: метрики тимморали, текучка, eNPS и т п
R → Reliability – надежность, качество: количество инцидентов, bug leakage rate и т п
O → Operations – операционные показатели: метрики, на основании которых можно сделать вывод, что команда работает нормально, например velocity или lead time
J → Job – состояние скоупа: сколько сделано, сколько осталось, прогноз
E → Economy – финансовые показатели: бюджет проекта, маржинальность, потерянные деньги и т п
C → Customer – удовлетворенность клиента: NPS, средний чек, LTV, лояльность
T → Timetable – расписание: состояние роадмапа и деливери

Не знаю, приживется эта классификация или нет. Но как по мне, выглядит неплохо. Можно пользоваться. Выделяешь по 1-2 метрики на каждую букву, и вуаля, проект, как на ладони. Полезно будет и тимлидам, и ПМам, и delivery manager-ам, и CTO.

Как по-вашему? Стоит развивать и продвигать?

Или может надо добавить сюда что-то? Поделитесь мыслями.

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

https://www.youtube.com/watch?v=X6XJ9gNYqPs

ПРО УВОЛЬНЕНИЯ #3

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

В прошлых сериях мы говорили о том, как относиться к увольнениям, и как принимать решение, увольнять или нет. Разобрали подход “ошибка/проступок”. Сегодня рассмотрим еще один.

В свое время комбат Батырев ввел в повседневный обиход менеджеров термин, ставший уже нарицательным – “учить/лечить/мочить”. И вроде бы понятно, сначала учить, потом лечить. Но вот абстрактно как-то все равно, конкретики бы сюда.

Начнем с того, что выделяют 4 основные причины, отчего человек что-то не делает (или делает плохо):
1. Не понимает – не осознает важности задачи
2. Не умеет – просто не научил никто
3. Не может – нет ресурсов
4. Не хочет – вот тут уже без оправданий, чисто не хочет и все

Так вот, начинать свой анализ следует именно с выяснения причин. Сотрудник плохо делает свою работу – почему?

Если выясняется, что дело в пунктах 1-3 – нужно “учить”. Либо разжевать, почему задача важна и как она влияет на команду или целую компанию. Либо научить эту задачу делать, если вопрос в компетенциях. Либо выдать ресурсы (а в идеале научить ими правильно распоряжаться, сделать экскурс в мир приоритетов).

А вот если вы убедились в том, что причина 4, и сотрудник просто не хочет делать работу хорошо – сам себе буратино, надо “лечить”.

Как “лечить”? Я предлагаю 2-х шаговый алгоритм. Мы использовали его в компании и обкатали на практике. Могу сказать, что работает неплохо.

Шаг 1 – Предупреждение:
1. Донести обратную связь
2. Объяснить, что взаимоотношения под угрозой, и дальше так работать нельзя
3. Обозначить цели и сроки по исправлению – чем конкретнее здесь, тем лучше, прям все по SMART-у
4. Определить свое участие и помощь – на этом этапе не отключаемся, а помогаем сотруднику справиться с проблемой

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

Шаг 2 – Последний шанс:
1. Донести обратную связь
2. Объяснить, что следующий шаг – уже увольнение
3. Обозначить цели и сроки по исправлению – здесь надо еще конкретнее, все максимально по SMART-у

И обратите внимание, в “последнем шансе” мы уже не предлагаем свою помощь. Теперь каждый сам за себя. Справишься – молодец, работаем. Нет – значит нет, мы уже пытались тебе помочь на прошлом шаге.

Ну и здесь, конечно, 50/50. Кто-то проникается и исправляется. Кто-то дотапливает себя до конца. Но для случая 2 у вас есть целая куча аргументов к разговору об увольнении. Аргументов и фактов, спорить с которыми будет сложно.

Если сотрудник не сдюжил, то остается только “мочить” – увольняем. А про это будет в следующей серии.

Друзья!

В понедельник, 5 июня, в 19.00 мск приглашаю вас на вебинар "Как руководителю повысить прозрачность работы проектных команд?" от OTUS.

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

Зарегистрироваться можно тут https://meetup.otus.ru/project-optimisation

ПРОБЛЕМА РОСТА МЕНЕДЖЕРОВ

Часто говоря про проблемы роста менеджеров. Оно наблюдается при каждом переходе на новый уровень. Сначала управлял только самим собой, стал управлять командой – проблема роста. Управлял командой, стал управлять несколькими командами – проблема роста. Управлял командами, стал управлять целой функцией – проблема роста. И т д. До самых самых высот.

Для наглядности, возьмем модель Адизеса. Ну помните, да? Там 4 роли руководителя: производитель, администратор, стратег (предприниматель) и интегратор. И для каждого уровня менеджмента (хотя сказать по чести, для каждой отдельной компании тоже) есть своя комбинация, которая необходима здесь и сейчас.

В среднем по больнице получается так:
- Инженер → Paei
- Тимлид → PaeI (иногда указывают pAeI, что встречается, но как по мне, не совсем верно)
- Delivery Manager → pAEi
- CTO → paEi

Повторюсь, комбинации могут отличаться от компании к компании. Так что, если у вас иначе – это ок, все нормально. Я усредняю.

Обратите внимание на переход тимлид → delivery manager. Он здесь самый наглядный. Чтобы совершить такой рывок, нужно значительно прокачать свои A и E. Но это полбеды. Присказка, так сказать. Все это решается обучением, практикой новых задач, наблюдением за другими руководителями.

А вот сказка начинается дальше. Чтобы рывок получился, нужно еще и “приглушить” в себе P и I. Перестать делать руками, перестать тесно работать и взаимодействовать с сотрудниками. А это уже куда сложнее. Тут и обучение не сильно помогает. И практика слабовато развивает. Потому что это уже история про изменение mind-set-а, а не про наработку новых знаний и навыков.

Что делать? Заставлять себя. Осознать четко свою роль, ее новые границы и зоны ответственности. И осознанно делегировать все, что выходит за рамки. Иногда это особенно сложно, потому что вашими руками задача будет сделана за 5 минут, а сотруднику ее только объяснять 15. А потом еще проверять, да и не знай сделает, не знай нет. Но таков путь, как говорится.

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

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

Друзья!

Напоминаю, в среду, 7 июня, в 20.00 мск проведу открытый урок "Как управлять тимлидами" в предверии старта нового курса Delivery Manager в OTUS.

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

Зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-2938

ПРО ПЕРЕГОВОРЫ #5

Продолжаем переговорный тред. В предыдущих сериях:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
ПРО ПЕРЕГОВОРЫ #4

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

Шаг 1 – Аргументы и обоснования. Берем все результаты нашей стратегической подготовки, наше видение портрета оппонента и его интересов. И готовим аргументы, которые могут убедить его. Каждому аргументу нужны еще и обоснования. Здесь можно использовать инструмент из продаж и презентаций ПИОН:
- П – Поручение – мнение авторитетных людей
- И – История – реальные истории из жизни, свои или чужие
- О – Официальные данные
- Н – Наглядные модели

Шаг 2 – Подача аргументов. Да-да, мало что-то говорить, важно говорить это правильно! Вот здесь как раз на сцену выходит все разнообразие переговорных техник, которыми можно усиливать ваши аргументы:
- Удержание сильных аргументов
- Заезженная пластинка
- Паузы
- Открытые/закрытые вопросы
- Внимание на общую картину
- Тайм-аут
- Эскалация
- …

Шаг 3 – Оппонент. Теперь нужно прикинуть, исходя из портрета, целей и интересов, а также переговорной позиции оппонента, какими аргументами и приемами он может воспользоваться. Фантазируем, какие у него могут быть аргументы, как он может пытаться их обосновать, как будет их вам подавать (какие переговорные техники станет использовать).

Шаг 4 – Ответы оппоненту. Разворачиваем все возможные действия оппонента обратно на него. Готовим контраргументы к его аргументам. Чем больше, тем лучше. Готовим контрприемы на его переговорные приемы. И важный момент – готовим возможные уступки. При каких “если” мы можем соглашаться на его предложения и аргументы. Обязательно готовьте этот блок заранее, чтобы во время разговора не растеряться и сохранять твердость своей позиции.

Шаг 5 – План переговоров. Теперь берем все результаты шагов 1-4 и оформляем в единый план. Что будем говорить, как будет говорить. Как будем парировать аргументы и переговорные приемы оппонента. На какие уступки можем пойти с выгодой для себя, на какие – ни в коем случае.

Вот теперь точно все. Вы готовы к переговорам. И у вас есть план. Не скрипт, а именно план. Там возможны ветвления и креатив “на местности”. Но с планом гораздо спокойнее. Даже если вы им и не воспользуетесь в итоге. План – ничто, планирование – все!

А дальше уже поговорим про сами переговоры, что делать внутри, когда вы в них попали.

Видео вчерашнего вебинара "Как руководителю повысить прозрачность работы проектных команд?"

https://www.youtube.com/watch?v=E9wT5eSU6pg

Внутри, традиционно, немного рекламы OTUS 🙂

ПРО СТЕК

Недавно проводил занятие с романтическим названием “Обзор стека” для тимлидов. В целом все стандартно: не разводите зоопарк, не хайпуйте, берите те технологии, что уже опробованы на аналогичных задачах. Ничего особенного.

Но там подсмотрел одну метафору, которая мне показалась элегантной. Вот делюсь.

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

Ну разве это не гениально? 🙂

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

Инженер – он что? Он решает задачу наиболее простым способом. Усложнениями всякие разные ученые обычно занимаются, чо-то вот там придумывают, совершенствуют. А инженер берет готовое и известное, и из этого складывает то, что ему нужно. В строительстве, в производстве, везде так!

А программисты же не такие? У этих постоянно креатив, тяга к прекрасному, желание творить и развиваться. И они, наоборот, вперед всякого RnD стараются что-то придумать и первыми запустить. Даже не ради наград, а просто, потому что интересно.

И вот где тут, спрашивается, ошибка? Зря программистов инженерами назвали? Или классическое понимание инженера давно устарело и надо все пересматривать?

Я больше склоняюсь ко второму варианту. Это объясняет, почему в IT последние десятилетия движуха, а все остальные сферы жизни и производства развиваются заметно медленнее. Были бы везде такие “голодные” инженеры, глядишь совсем иначе выглядел бы мир. Но это не точно.

А вы как думаете? Кто же “не те” – программисты или инженеры? Или не надо их сравнивать, и инженер-программист – это как русский рок: рок, конечно, но очень особенный, “русский”?

Видео вчерашнего открытого урока в OTUS "Как управлять тимлидами"

https://www.youtube.com/watch?v=ZI6hvR5EVSg

Внутри информация о стартующем курсе Delievry Manager и немного рекламы OTUS.

Новая статья! На этот раз про метрики и управление сразу несколькими проектами.

https://habr.com/ru/companies/otus/articles/740834/

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

Приятного чтения!