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

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

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

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

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

Что тут может и должен сделать РП?

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

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

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

Продолжаю рассуждать про разницу в работе между руководителем проектов и тимлидом. Она в том числе вытекает из простого факта, что РП ближе к бизнесу.

Тут важно небольшое пояснение. Везде, где мы говорим о ролях РП, тимлида, иногда архитектора в компаниях в сфере ИТ, мы заранее понимаем, что в каждой компании своё представление о роли. Вот где-то даже СТО обязан писать код. А где-то (мои личные знакомые) тимлид вообще не прикасается к коду, а занимается только people-management и немного project-management.

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

Да, я считаю, что РП должен уметь думать про пользу. Где-то есть чёткое разделение: руководитель продукта про сам продукт и пользу, которую он приносит юзерам, акционерам и всем-всем-всем, а руководитель проектов только про исполнение задумок.

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

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

Бывает, забегают в пятницу вечером: всё, капут, выводи всех своих завтра на overtime, даже заплатим по ТК РФ, нужно срочно добавить вон ту плашку на сайт! Аккуратно интересуешься, а зачем, а сколько народу ей будет пользоваться, а что это за категория посетителей, а какой средний чек она обеспечивает, а есть ли репутационные потери? Всем вдруг становится очевидно, что overtime стоимостью условно 100 тысяч рублей принесёт компании условные 5 тысяч, и то с вероятностью 0,7.

Ещё хуже с фичами. Готов повторять много раз: до сих пор ещё много где ИТ воспринимают как волшебников, которые могут всё сделать быстро и сделать буквально всё. Это мнение рождается из нематериальной сущности нашего производства: сложность, в отличие от постройки домов и прокладки дорог, не выражена в громоздких материальных объектах, а значит, не видна.

Далеко не за каждым проектом стоит элементарное экономическое обоснование: что это нам даст, каких целей достигаем, какой срок окупаемости, какие риски. Понятное дело, РП не обязан быть, как та тётя Циля из анекдота, старшим экономистом. Однако он должен дать заказчику достаточно полное понимание реальной стоимости проекта: непосредственно разработка, трудозатраты, умноженные на часовую ставку. Также взаимовлияние на другие части продукта и/или проекты. Также риски и их стоимость. Также приоритетность отвлечения команды: если мы делаем это, то значит, не делаем вот это - как вам, меняем важность запросов внутри компании?

Последнее особенно важно. Часто в inhouse-разработке у ИТ-команд всегда больше запросов на изменения, чем она сможет выполнить. Поэтому приоритезация запросов бизнеса падает на РП. Если, будучи тимлидом, я ждал, что бизнес сам между собой договорится, что ему важнее, то на роли РП этой работы ожидают непосредственно от меня. А для этого нужно подбирать инструменты: экономическое обоснование, опора на авторитетность того или иного лидера бизнес-направления, "всем понемногу", прямые указания от директора и так далее, так далее.

Попался на глаза короткий, но очень эмоциональный разбор одной небольшой джазовой пьесы Jumpin' At The Woodside в исполнении двух гениев джаза - Каунта Бейси и Оскара Питерсона. Автор наглядно разбирает, в чём именно состоит гениальность и за что нам стоит любить мастерство обоих пианистов: https://www.youtube.com/watch?v=PkMFLD4KtJg

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

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

Действительно, он издаёт по сравнению с Оскаром сильно меньше звуков, но главным впечатлением от произведения управляет он. Просто одна нота точно в нужном месте. Потом ещё одна. И вот ещё две, но не больше. А ближе к концу вообще ломает ритм, окончательно давая понять, кто тут в аккомпанементе.

И вообще оба играючи выбиваются из ритма, давая понять, что даже presto им не помеха намеренно отставать на 1/8-1/16-е ради того, чтобы поиграться друг с другом и со слушателем. Азартная игра со временем внутри азартной и быстрой пьесы!

Очень, очень классно! Имею возможность прослушивать Jumpin' At The Woodside на хороших Bang & Olufsen, получаю настоящий восторг от этой игры двух джазменов. Ты как-будто сам становишься умнее и тоньше, когда тебе предлагают настолько изысканное блюдо. Возвышает и окрыляет!

#джаз

Пет-проекты

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

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

Однако я вот о чём подумал. С разработчиками более-менее понятно. Что же спрашивать на собеседованиях у менеджеров в качестве пет-проекта?

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

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

Я бы вспомнил несколько пет-эпизодов. Например, как идеально распланировал и организовал собственную свадьбу. Точнее даже две: одну официальную с родственниками, вторую после свадебного путешествия с друзьями на природе. Или рассказал бы про организацию путешествий, которые почти всегда проходят чётко, с учётом рисков. Упомянул бы также своё байкерское прошлое, как стихийно организовывал байкерские выезды во всякие интересные места. Ещё бы обязательно рассказал, как организовал родителей из класса моей дочери, чтобы урезонить двух распоясавшихся хулиганов, и моим противником, отцом одного из хулиганов, оказался ни много ни мало бывший глава госкорпорации. Весело было, а главное, всё очень удачно срослось.

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

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

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

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

Во-вторых, я попросил рассказать, что изображено на рисунке. Там достаточно простая sequence-диаграмма, фронт запрашивает бэк, бэк идёт в базу, достаёт JSON и прокидывает обратно клиенту. Обычно все начинают рассуждать сразу вслух. Этот претендент завис секунд на 15 (думаю, скармливал картинку ИИ), потом начал говорить и выдал какой-то совершенно невообразимый канцелярский речекряк типа "на данной схеме мы наблюдаем последовательность осуществления роутинга запроса в реальном времени, направленную на поддержание процесса чего-то там". Я аж в голос засмеялся и попросил кандидата рассказать ещё раз своими словами, что происходит.

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

Вывод: использовать онлайн-ассистенты для прохождения интервью, наверное, можно. Но если у вас не вгиковская или мхатовская школа актёрского мастерства, выглядеть вы будете глупо. Для внимательного наблюдателя даже HD-камера и простенький микрофон скажут о вас буквально всё.

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

Во первых и главных: вообще есть мало фильмов про управленческие факапы. Если мы берём голливудское кино, которое можно отнести к производственным драмам, то оно всё так или иначе про истории успеха: от "Соцсети" про Цукерберга до "Основателя" про Рея Крока. Советские фильмы 60-80-х годов, вопреки устоявшемуся мнению о всесильной цензуре, часто весьма жёстко критикуют некоторые практики того времени. Вроде бы страна продолжает развиваться быстрыми темпами - рост производства очень впечатляет - а кинодеятели бичуют отдельные пороки только в путь!

Во вторых, советские фильмы сняты про обычных пиджаков, бюрократов, партийцев, то есть менеджеров. Иногда прямо про обычные рабочие бригады (как "Премия"), иногда про молодого главу горкома партии, как "Обратная связь". Но в любом случае, таких людей много. Можно представить себя на их месте. В то время как Голливуд снимает про выдающиеся величины: в фокусе находится личность, которая меняет целый мир. Интересно, но не про нас с вами.

Фильм на себе, конечно, вывозят великие актёры: Янковский, Ульянов, Лавров. Заняты также Гурченко, Гундарева. Ничего себе обычная производственная драма!

Сюжет строится вокруг того, что в горком приходит новый глава, а в городе сдаётся могучий комбинат всесоюзного значения. Фильм начинается со сцены: тётя меняет огромные цифры на конструкции комбината - "До пуска осталось N дней". Короче, дедлайн.

Дальше спойлер. Молодой управленец Янковский вдруг узнаёт, что definition of done по ходу строительства комбината подменил авантюристичный строитель Ульянов. В итоге отрасль и государство получат серьёзный убыток при формально успешно выполненной работе. Много кто понимает, что это плохо, но все приняли идею, что по-другому уже не получится. У Янковского хватает пороха докрутить ситуацию до конца. Конечно, у всех сторон есть своя правда, и в итоге то решение, которое было принято самым большим московским начальством, не сказать чтобы обрадовало хоть кого-то. Типичный компромисс.

Однако если пытаться найти причину, которая больше всех повлияла, то кмк она в товарище Большом Начальнике, которого играет Кирилл Лавров. Этот бич, кажется, преследует очень многих Больших Начальников:
- они стараются выжать из подчинённых коллективов ещё больше (в советских реалиях это обязательство по перевыполнению плана);
- они надеются, что возможные негативные последствия их излишнего авантюризма или жёсткости как-то сами рассосутся: для этого нижестоящие и нужны, чтобы у них голова болела.

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

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

Читаю "Впереди перемен" Джона Коттера. Наткнулся вот на такое интересное рассуждение:

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

По-моему, очень интересный вопрос ставит автор ещё в 2012 году, и пока удовлетворительного ответа нет.

Даже у нас в ИТ уже некоторое время назад стало принято думать, что время гениев-одиночек прошло (я писал об этом ранее). Программисты, в одиночку пишущие за одну ночь гениальный код, который потом приносит миллиарды вашей фирме, - такое в прошлом. И программистов стало сильно больше, чем 30-40 лет назад, и код пишут не только люди, и конкуренция гораздо жёстче. Короче, новое качество способны давать команды, коллективы, группы, причём умело составленные.

Но вопрос в том, как мы умеем нанимать людей, раскрывающих свой потенциал именно в команде? - Если честно, в среднем по отрасли не очень.

Тысячи копий ломаются вокруг собеседований программистов, например. Но если посмотреть на них с этой рамкой, то мы всё равно выясняем хард-скиллы конкретного единичного исполнителя, как он в одно лицо будет переворачивать деревья и снижать О-эн-квадрат до просто О-эн. Ну, теперь ещё с помощью ИИ. "Мы" - имею ввиду отрасль в целом.

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

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

У меня нет красивого ответа. Вопрос в том числе и мне. Лично я не собеседованиях всегда думаю о человеке именно в рамках команды, куда его нанимаю. Но говорить о целенаправленных метриках, надёжных подходах к прояснению этого вопроса на собеседованиях пока рано. Скорее полагаешься на собственную интуицию и общее умение оценить человека.

Так что с одной стороны, да, "участвовал в успешной команде" выглядит блекло. И поэтому карьерные консультанты под копирку советуют писать в своих резюме эти уже до крови из глаз надоевшие "внедрил фреймворк Х, чем поднял производительность сервиса на 12,5%". А с другой - умеем ли мы, нанимающая сторона, среди тысячи других разглядеть того единственного человека, которого не достаёт именно нашей команде?..

О тестировании

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

Ситуация анекдотичная, и заставляет подумать о ценности тестирования как такового. В ИТ есть люди, которые, возможно, не понимают самой постановки вопроса: в смысле, ценность же очевидна, о чём тут рассуждать! Но есть достаточное количество человек - и я сам с такими знаком - которые почти буквально говорят что-то в духе "ну вы разрабатывайте без багов, тестировать и не придётся".

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

Теперь же настала пора более вдумчиво работать над продуктом. Уровень качества, который вы при этом обеспечиваете, является одной из ключевых метрик. Выпустить вообще сырой продукт, который пользователи пусть и тестируют? - Ну если вы всем известные монополии и олигополии (не будем показывать пальцем), то наверное можно. Я лично наблюдаю в некоторых очень крупных сервисах явные баги, которые не закрываются 10 лет.

А если конкурируете с другими? Закрывать вообще все баги, не выпускать релиз, если есть хотя бы один минор? - Не вариант, будете разрабатывать вечно. Надо принимать решение, что допустимо, что нет. Для принятия качественного решения нужны аргументы. Вы узнаёте, как именно работает ваш продукт, что чаще используют клиенты, какой функционал приносит больше прибыли, какой меньше, какие фичи вообще дороже поддерживать, чем просто отключить раз и навсегда.

И через это тестирование становится не просто очередной группой в вашем отделе или департаменте, на которую надо выделять ФОТ, потому что надо. А начинает быть инструментом влияния на прибыль, который приносит продукт. Вы контролируете глубину тестирования - вы играете с балансом стоимость разработки / скорость / качество. Вы проводите глубокое пользовательское тестирование - вы возвращаете себе упущенную прибыль, которую вы не сможете посчитать ни одним анализом простоев в ваших Zabbix и Grafana. Вы настроили разумные нагрузочные и E2E - вы заставляете разработчиков лучше думать об архитектуре и вкладываться в надёжность, а не только в скорость доставки до прода.

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

Возвращение

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

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

Я уже ранее писал про своё отношение к отпуску руководителя: https://t.me/playingjazz/45 . Пересказывать лонгрид не буду даже кратко, повторю оттуда только один тезис: "Мы будем считать отпуском то состояние человека, когда он не работает свою работу ни в каком виде".

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

На моё удивление, по приезду я обнаружил, что дела идут даже немного лучше, чем предполагал. Хотя релиз подвинули вправо: к вышеуказанным сложностям прибавился ещё больничный одного из исполнителей задач. Но гораздо более важно для меня было, как именно команда справлялась с поступающими трудностями. Очень внимательно читал 600+ сообщений, которые накопились в релизном чате.

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

Я даже поймал себя на мысли, что сегодня в течение рабочего дня мне становится немного скучновато. Они все работают без меня, и у них всё хорошо! Просто стой и наблюдай рядом! Шероховатости есть везде, но в главном, считаю, у меня получилось. Еду домой окрылённый...

В поисках информации об управлении изменениями прочитал две книги Джона Коттера: "Впереди перемен" и "Наш айсберг тает". Автор - известный авторитет в области лидерства, профессор Гарварда и так далее.

Коттер пропагандирует свою собственную 8-шаговую модель управления изменениями:

1) Внушение людям ощущения необходимости перемен
2) Создание команды реформаторов
3) Видение перспектив и определение стратегии
4) Пропаганда нового видения
5) Создание условий для широкого участия сотрудников в преобразованиях
6) Получение скорых результатов
7) Закрепление достигнутых успехов и углубление перемен
8) Укоренение изменений в корпоративной культуре

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

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

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

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

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

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

(продолжение тут)

(начало тут)

В книге "Впереди перемен" автор даже предлагается искусственно спровоцировать кризис, чтобы начать движение к переменам. Смело и рискованно. И это обнажает ещё один пункт в миропонимании Джона Коттера. Оно не проговаривается в книгах слишком явно, но тем не менее очевидно.

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

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

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

Я смело могу рекомендовать обе книги к прочтению, особенно тем руководителям, кто не хочет сидеть на одном месте. Как пророчит сам автор, в XXI организации будут подвержены всё более частым изменениям, в частности, из-за обостряющейся международной конкуренции. Мы из 2026 видим, что в целом он был прав, только двигателем конкуренции бывает не только глобализация, но и другие внезапные события. Так или иначе, а меняться приходиться, и всё быстрее.

ps. Потихоньку начинаю пользоваться Obsidian в качестве собственной базы знаний. Давно хотел начать, и вот случилось. В частности, по книгам теперь делаю конспект, что позволяет быстро возобновить память о прочитанном. Пока очень нравится! По мере получения опыта расскажу более подробно.

Про то, как ИИ всех уволит

Тут попался случай. Некоему бизнес-юниту стал позарез нужен клиентский портал, без него продавать совсем трудно. Помочь вызвался один биг босс, у которого в подчинении куча ребят с головой. Биг босс: "Выделю вам команду, сейчас она возьмёт ИИ и за две недели сделает вам как надо".

Команда действительно была выделена. Приступили. Но хорошо бы узнать подробности, ограничения и т.д. Создали чат. Биг босс немного побыл там аналитиком. На первоначальный сбор требований тоже ушло время, стало не 2 недели, а месяц с небольшим. В итоге на второй месяц MVP увидело свет.

И тут заказчик говорит: "Кстати, вот мы ещё работаем с такими клиентами..." И безопасники подоспели: "А помните про разделение персданных на разные контуры? И сколько типов операций, столько разных инстансов и согласий?" Короче, MVP как бы есть, но его точно никому нельзя показывать. Биг босс пишет: мол, сорян, но срок вправо на месяц.

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

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

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

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

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

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

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

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

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

Самое удивительное, что это мой 17-й забег вообще. Конечно, раньше иногда бегал по стадиону, 2-3 раза в год, то 5, то 8 км. А с января 2026 начал целенаправленно бегать по дорожке в зале. И вот на 17-й раз уже полумарафон.

Когда один мой коллега по другой компании тоже начал бегать и где-то через полгода пробежал столько же, то я сильно удивлялся: мол, у тебя талант!

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