Седой директор

РЕФАКТОРИНГ VS ПРОЦЕССЫ – ЧТО БУДЕТ ПЕРВЫМ

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

Первым будет вопрос от Дмитрия Алина @raiserspb про приоритеты – с чего следует начинать: со сложного рефакторинга продукта или с построения процессов.

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

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

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

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

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

Для примера могу привести общие правила и фреймворки change management: сначала подготовка и “разморозка”, определение показателей для контроля и подтверждения результата, потом само изменение, а потом “заморозка”. Вот без разморозки бросаться в омут рефакторинга очень рискованно.

P.S. По словам Дмитрия, ответить на вопрос получилось 🙂

Коллеги, сегодня хочу прям набросить)

Вопрос такой - как вы относитесь к концепции "бирюзовых организаций"? Бывает ли такое, какие бонусы дает, как этого добиться?

Я почему про них вспомнил. Думал, что хайп уже прошел с этой темой. Ан нет. Много разных материалов видел последнее время, притом нестарых. Значит свежа мысль, теплится еще идея в головах-то!

Поделюсь своим мнением на этот счет. Считаю всю идею утопической и нереальной. От слова, совсем.

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

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

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

Что думаете по этому поводу? Напишите в комментарии!

Друзья, привет!

Я хочу немного трансформировать свой формат Вопросника. Запускаю Вопросник 2.0 - "Бесплатные консультации от "Седого директора".

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

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

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

Могу ответить не сразу, но отвечу обязательно каждому!

Пишите свои вопросы, всегда рад быть полезным! 🙂

ПРО АУДИТ КОМАНД. СНОВА

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

https://youtu.be/mCkBfXz7GXo

ТИПЫ ТИМЛИДОВ

В конце августа проводил небольшой вебинар для тимлидов на площадке РДТЕХ. И ребята нарезали несколько интересных видео оттуда, по узким, но востребованным вопросам.

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

https://youtu.be/-iMTfRtptOU

Всем привет!

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

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

Делюсь с вами полезным каналом про HR и карьеру в IT и не только. Аня - HR директор с большим опытом управления талантами в продуктовых и ИТ компаниях, карьерный консультант и коуч.

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

Если вы планируете строить карьеру в IT читайте этот пост, а если сейчас в поиске в России или зарубежом , заходите в рубрику #впоиске и внедряйте формулу успешного поиска. Также Аня вместе со своим мужем, который построил карьеру от ИТ консультанта до CTO в крупной телеком компании, делится интересным в мире ИТ в рубрике #PROайти

Подписывайтесь и у вас появится личный карьерный наставник!

КАК СКАЗАТЬ “НЕТ”

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

А сказать простое “нет” не можете. Почему так? Ну как почему. Есть же субординация. Он начальник, дает задачу, значит надо делать. Еще не хочется показаться каким-то нелояльным, мало ли что подумает руководитель про это. К тому же, предустановочки, куда ж без них: “челленджи развивают!”, “критикуешь – предлагай!” и т п вариации на тему.

А ведь сказать вовремя “нет” нужно уметь. Пока вы не согласились, пока вам хотят еще только поставить задачу, вы можете обсуждать что-то: условия, реализацию, ограничения. Это, по сути, переговоры, и поле торга для вас открыто. А как только согласились – все, считай, закоммитились. И теперь должны сделать. А не сделаете – виноваты только вы сами.

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

Так как же быть? Как говорить “нет” без зазрения совести? И чтоб начальник не расстроился и не обиделся? Есть пара вариантов:

- Прямо в лоб – просто “нет” и все, без сглаживания углов, иногда так даже получается лучше всего
- “Да, если ...” – добавить условий, например, “сделаю, но если реализация будет за мной”, или “если дадите премию моим сотрудникам”, или еще чего
- Альтернативный вариант – предложите что-то другое, т е “я так делать не хочу, но знаю, как можно было бы решить эту проблему, предлагаю свой план”
- Отложенное “нет” – что-то из разряда “это не приоритет сейчас, давайте вернемся к этому вопросу завтра/через неделю/30 февраля/с восходом солнца на Западе/…”
- Пауза – похоже на предыдущее, но не кормить завтраками, а просто взять паузу, по типу “не готов сейчас что-либо сказать, дайте мне день на подумать”, и дальше реально возвращаетесь через день, подумав, с планом или безмолвным согласием

Наверняка, есть еще рецепты. Это то, что по опыту помогает и работает. Накидывайте свои в комменты!

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

В общем, будьте здесь аккуратнее. Больше эмпатии, господа. Вы не обязаны сразу исполнять все указания руководителя, но и тупо саботировать их тоже не дело, никто этого не любит. Говорите “нет” правильно и осознанно.

Друзья!
Хочу напомнить вам про форму https://forms.gle/aBX5PgU1CLU4FDPP8
Пишите туда свои вопросы/кейсы, а я сделаю разбор. Форма анонимная, но можно подписаться.

ПРО ЗАНУДСТВО ВОК-ОВ

Не-не, мы не про японские макароны сейчас. Хочу поговорить про BOK-и – Body Of Knowledges.

Недавно добрался прочитать, наконец, DMBOK. Да, каюсь, много работал в Data Management и Data Governance, а всю целиком книжку, чтоб вот “от корки до корки”, так и не читал. Кусками все, отрывками. Теперь исправляюсь.

Так вот, основное впечатление – нудятина. Ну вот максимально скучно и неинтересно. Хотя тема не такая, тема очень интересная. Данные же! Это везде и всюду, очень про жизнь! Но написано вот как написано.

Аналогичное впечатление было и от PMBOK. Ну вот нудятина полная. Хотя, казалось бы, что мешает написать чуть выразительнее? Ну да, это справочник, а не роман. Ну да, там много сухих схем и моделей. Но это же не значит, что все, что между картинок, должно быть нудным? Ведь так?

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

И вот, мой вопрос – почему так то? Какое такое “чтобы что” заложено в подобной редакции? Фильтр на восприятие? Демонстрация интеллектуального превосходства? Тест на стойкость и смирение? Или если бы было легко и понятно написано, то слишком легко было бы и сертификацию пройти в соответствующих институтах?

Кто знает, кто знает… А вы как думаете? Читали всякие разные BOK-и? Понятно? Не нудно?

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

https://youtu.be/N5a5u3JGDnI

Видео вчерашнего эфира про портфельный Agile и про метрики

https://youtu.be/fW6w_fGPrjQ

А тем временем, мы вплотную подобрались к старту нового курса COO в IT на площадке OTUS. 27 сентября будем начинать!

А завтра, 20 сентября, в 20.00 мск проведу завершающий открытый урок, где обсудим аспекты финансовой эффективности IT-шного производства, чтобы раз и навсегда разобраться, а генерирует ли ваш продакшн прибыль.

Ссылочка для регистрации вот https://otus.ru/lessons/coo/#event-3284

SAFe, LESS, Scrum of Scrums – почему они все не работают?

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

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

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

А как быть аутсорсингу? Ведь там тоже есть портфели. А внутри будут разнородные и, часто, вообще не связанные между собой проекты. Да и не только аутсорсингу. Собрали в один портфель и отдали DMу пачку продуктов, и разбирайся теперь. А тут никакие LeSS-ы и SAFe уже не помогут.

Я в таких кейсах топлю за метрики. Я, своего рода, адвокат этого подхода. Про метрики рассказывал и писал уже много. И вот сделаю это снова.

Завтра, 19 сентября, 20.00 мск. Завершающий открытый урок перед стартом нового потока курса Delivery Manager. А зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-3290

Приходите, поговорим за метрики 🙂

Видео вчерашнего эфира про авторитет у технарей https://youtu.be/lGwYztIhvDo

СИЛЬНЫЙ УВАЖАЕТ ТОЛЬКО СИЛУ?

Есть мнение, что сильный уважает только силу. А технарь уважает только другого технаря. Так ли это? Во многом.

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

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

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

Какая? Например, повышение комфорта. Решение проблем сотрудников. Своего рода, “защита” от другого начальства. Должно формироваться ощущение, что с этим вот менеджером лучше, чем без него. И как только оно сформировалось – поздравляю, вы можете претендовать на какое-никакое лидерство в глазах технаря.

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

Тема эта непростая и многогранная. И потому мы приготовили открытый урок курса Delivery Manager, где я постараюсь сформулировать, как же, все-таки, снискать уважение у технарей, если ты сам не из таких. Завтра в 20.00 мск. А зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-3289

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

Срок ожидания прошел, поэтому делюсь теперь видео 🙂

https://youtu.be/gA47oZJnTrI?list=PLRdS-n5seLRpxYCLRdKdDJJdsy2PJPgib

Друзья!

Ровно через неделю, 15 сентября, выступлю с докладом на CrossConf в Москве. Расскажу про основные модели аудита команды, как их можно соединить в логичную систему, с помощью которой легко и просто отсканировать вдоль и поперек свою команду и поработать над ее эффективностью.

Всем, кто будет на конференции вживую - приходите на доклад и пишите в личку @ilya_prakht, буду рад встретиться!

Видео вчерашнего открытого урока "Тайное искусство оптимизации процессов".
Поговорили про БП, про методы и подходы к оптимизации, про роль СОО в этом.

https://youtu.be/5CaKNYqZf2k

КАК ОПТИМИЗИРОВАТЬ ПРОЦЕССЫ

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

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

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

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

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

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

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

В общем, одним постом и не расскажешь. А потому, хочу пригласить вас на открытый урок курса СОО, где мы, как раз, поразбираемся в вопросах оптимизации бизнес-процессов. Завтра, 6 сентября, в 20.00. А зарегистрироваться можно тут https://otus.ru/lessons/coo/#event-3283

Видео вчерашнего эфира в OTUS. Говорили про роль Delivery Manager-а, философию изменений, роль тимлида в изменениях.

https://youtu.be/K4xnjqA_xn0