Книжный куб

Обзор книги "Цифровая трансформация" ("Digital Transformation. Survive and Thrive in an Era of Mass Extinction") Где-то год назад я прочитал книгу Томаса Зибеля про цифровые трансформации и никак не мог написать обзор. Суть в том, что книга достаточно хорошо описывает современные подходы и концепции и показывает, почему организациям сейчас требуется меняться или уйти с рынка. Поэтому я и хотел про нее написать, но мешали другие факторы, например то, что Siebel для меня - это имя нарицательное, которое окрашено в негативные тона переездом с Siebel CRM, которым я к счастью не занимаюсь напрямую. То есть Зибель - это некто вроде Авгия, чьи конюшни должен был почистить Геракл, выполняя свой шестой подвиг. Но Геракл справился за один день, а миграция с Siebel CRM - это многолетний процесс:) Интересно, что даже сам Томас Зибель смигрировал с Siebel CRM, продав ее Oracle, в стартап C3.ai, который появился еще в далеком 2009 году и стал платформой для создания AI приложений (Томас умеет ловить тренды до того, как они стали хайпом). Хотя если возвращаться в 2019, когда была издана эта книга, то уже тогда digital transformation было bullshit словосочетанием, этаким маркетинговым термином, который использовали консультанты, чтобы продать очередной проект в устоявшуюся корпорацию. Краткий обзор содержимого можно прочитать в моем блоге. Плюс если вам нравится тема digital transformation, то рекомендую еще несколько книг — "Digital@Scale. Настольная книга по цифровизации бизнеса" — книга от ребят из McKinsey, про которую я писал раньше — "Digital Transformation Game Plan" от ребят из ThoughtWorks, на которую у меня есть краткий обзор —"The Software Architect Elevator. Redefining the Architect’s Role in the Digital Enterprise" — книга про роль археолога архитектора, который и помогает обеспечить digital transformation внутри организации. Я писал про эту книгу чуть раньше #Management #Consulting #Digitalization #Leadership #Processes #ProductManagement #Project

DevPlatform Party (by Yandex Infrastructure) #4 от 2023.10.17 Вчера был интересный митап Devplatform от Yandex в Белграде, на котором было 4 выступления разной степени плотности и о которых хотелось бы рассказать 1) Что же такое Capacity Planning на самом деле 2) Параллельная разработка и тестирование микросервисов через feature branches 3) Куда пропала инженерная романтика 4) Поднимаем инфраструктуру с нуля, если вы - маленький стартап Что же такое Capacity Planning на самом деле (доклад Дмитрия Нестерова из Yandex) На самом деле митап я решил посмотреть из-за этого выступления, так как оно рассказывает об актуальной для крупных ИТ-компаний теме, а точнее о планировании и распределеннии мощностей. Мне был интересен путь Яндекса в этой теме, так как мы внутри идем по похожему маршруту:) В Яндексе были стадии - Появление capacity planning в 2016-2017 года - нет понятных процессов и правил, нет автоматизации, но есть excel:) - Становление capacity planning в 2018-2019 - появление системного подхода (заявки, роль capacity planner, коммуникация с заказчиками) - Развитие capacity planning в 2020-2021 - решены технологические проблемы, появилась автоматизация, но она неудобная - Зрелость capacity planning в 2022-2023 - внедрен продуктовый подход (пошли от JTBD пользоватетелй), формализованы и упрощены процессы, есть статегия развития Дальше Дмитрий показывал и рассказывал как работают эти инструменты и это было интересно. Параллельная разработка и тестирование микросервисов через feature branches (доклад Дмитрия Костюкова из Alfa Bank) Если бы митап начался с этого доклада, то я бы не стал его смотреть. И тут история не про качество доклада, а про подход к развитию технологий и платформы. По-факту, Дмитрий рассказывал про то, как в условном процессе gitflow с кучей микросервисов, выстроенных в цепочку, тестировать фичи. И эту проблему он через свой способ решил ... НО, при развитии технологической платформы важно делать так, чтобы правильные вещи было делать легко, а кривые вещи было делать сложно. И в разработке программного обеспечения сейчас целевым процессом работы с кодом является TBD (trunk based development), в котором не нужны долгоживущие ветки. Для его достижения надо писать много автоматизированных тестов, уметь работать с feature toggles и так далее. Это позволяет быстрее разрабатывать и бьстрее видеть и решать конфликты в логике фичей, так как это видно внутри кода (а не как в gitflow где это видно во время merge). В такой схеме вся эта машинерия, что упоминалась в докладе не нужна, а даже вредня, так как она провоцирует делать долгоживущие ветки. В итоге, тактическую задачу ребята из платформы Alfa Bank решили, а вот стратегическую ... увы нет:) Куда пропала инженерная романтика (доклад от Ярослава Астафьева) Философская история, которую интересно было послушать и которая должна мотивировать на развитие. В принципе, слушать было интересно, но это скорее софтовый доклад Поднимаем инфраструктуру с нуля, если вы - маленький стартап (доклад от Алексея Шаграева из pora.ai) Рассказ от Леши на тему использования AWS Fargate (Serverless compute for containers) для организации инфры для стартапа:) И простенького CI/CD для деплоя туда. Суть в том, что стартаперам круто использовать as a Service решения, которые позволяют погрузиться в создание бизнес-логики вместо построения инфры, которая предоставляет базовые абстракции и умеют в self healing. Мне показалось, что это достаточно простая история, которую рассказывал именно Леша, потому что он когда-то работал в Yandex:) #SoftwareDevelopment #PlatformEngineering #Engineering #SRE #Devops #Architecture

Краткий обзор "Говори на языке диаграмм" ("Say it with Charts") Первое издание этой классической книги появилось еще до моего рождения, а точнее в 1985 году. С тех пор конечно много воды утекло, но значительная часть книги до сих пор кажется актуальной и полезной. Ее написал Джин Желязны, который когда-то работал директором по визуальным коммуникациям в McKinsey & Company. Я решил поделиться кратким саммари этой книги, так как я видел слишком много диаграмм, что были сделаны без особой идеи и смысла, а эта книга в свое время мне помогла научиться визуализировать данные внутри моих презентаций. Чуть подробнее про книгу можно прочитать в моем блоге. #Math #Presentation #PublicSpeaking #Vizualization

Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022 Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов - Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations. - What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги. - When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать. - Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:) - How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана. - Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа. В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты. P.S. Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:) #Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML

Обзор книги "Объединяя точки. Уроки лидерства" ("Connecting the Dots: Lessons for Leadership in a Startup World") Недавно я прочитал книгу Джона Чемберса, который 20 лет был CEO Cisco, а до этого успел поработать в IBM и Wang Laboratories. Многие считают, что Джон был великим визионером и его умение улавливать едва уловимые сдвиги на рынке позволяли Cisco выбирать нужное направление и успешно покупать небольшие компании, расширяя свой портфель продуктов. В итоге, после ухода из компании и перехода в JC2 Ventures Джон решил написать книгу, в которой он обобщил свой опыт. И книга состоит из 4 частей и 13 глав, которые выстраиваются в интересную и личную историю. Подробнее про книгу можно почитать в моем блоге, плюс я раньше уже рассказывал про подход Джона Чемберса к слияниям и поглощениям, который был одной из глав этой книги. P.S. По мнению российских издателей (издательство "МИФ") эту книгу хорошо дополняют книги: — "От хорошего к великому" ("Good to Great") Джима Коллинза — важная книга про культуру компаний, но выводы из которой ставятся под сомнение, если ориентироваться на результаты "великих компаний" после выпуска книги. Про это отлично рассказывается в книге "Эффект ореола" ("The Halo Effect"), на которую я раньше уже написал обзор. — "Обновить страницу" ("Hit Refresh") от Сатья Наделла — крутая книга про трансформацию Microsoft, я уже публиковал краткое саммари по этой книге — "Принципы" ("Principles: Life and Work") от Рэя Далио — крутая книга с перечнем принципов, многие из которых звучат просто, но очень сложно реализуются на практике, но пока я про нее не рассказывал — "Принципы лидера" ("Leading Matters") от Джона Хеннесси — интересная книга от сооснователя корпорации MIPS и экс-ректора Стэнфордского университета. Также Джон входил в совет директоров Cisco и Google. Эта книга похожа по мотивам на книгу Джона Чемберса, которая обсуждается в этой статье. Кстати, на нее я тоже уже написал краткий обзор #Management #Leadership #SelfDevelopment #Engineering

Дом моего детства (Jours sucrés) На выходных я прочитал этот уютный французский роман с иллюстрациями. Я хотел немного отвлечься от работы и отдохнуть и, читая этот комикс, у меня это получилось. Канва истории достаточно проста - главная героиня уезжает из Парижа в свой родной город для того, чтобы встретиться с нотариусом. Оказывается, что ее отец, которого она не видела с детства завещал ей дом и пекарню, в которой она проводила в детстве много времени. В планах у главной героини было вернуться в Париж в тот же вечер, но ... что-то идет не так и она остается в городе на подольше, окруженная воспоминаниями из детства ... В общем, мне эта история понравилась и я рекомендую ее к прочтению. #Comics #Fiction

Interviewing & Hiring Like a Boss • Kristine Howard • YOW! 2023 Интересное выступление Kristine Howard из Amazon, которая рассказала про то как проводить интервью более качественно. Мне эта тема интересна из-за того, что я сильно вовлечен в процессы найма и я стараюсь улучшать их по мере своих сил. Если же возвращаться к выступлению Кристин, которая является AWS Head of Developer Relations APJ, то она начала выступление с того, что лет 8 назад ненавидела проводить интервью, но как известно от любви до ненависти один шаг и когда-то она сделала его в обратном направлении как принято в Amazon:) Дальше она перешла к основным пунктам своего выступления - Что делать перед интервью - рассказ про подготовку job description, про ревью CV (и их подготовку со стороны кандидатов), как выстроить структуру цепочки интервью, как проверять hard skills и leadership principles (шардируя проверку разных скиллов по разным интервьюерам), как проводить preebrief, на котором можно получить дополнительную информацию о требованиях к кандидату, как готовить конкретные вопросы к кандидату (выбирая из подготовленого списка вопросов) - Как проводить интервью - помочь им успокоиться, рассказать про регламент проведения интервью, зачем и как просить кандидатов рассказывать истории - по-факту, спикер рассказывает про использование STAR (situation-task-action-result) и SBI (situation-behavior-impact) для проведения интервью:) Дальше она говорит о том, на что обращать внимание при общении с кандидатом: смотреть на цифры, scope, impact. Уточнять что именно делал кандидат для получения результата. Не бояться прерывать поток воды и переходить к следующему вопросу. Как написать фидбек о кандидате - здесь спикер говорит о том, как уменьшить влияние предубеждений и объективно оценить кандидата по заранее составленному списку критериев. - Как принимать решения по итогам всех интервью - здесь идет речь про debrief и ревью итоговых результатов кандидата и стоит ли его нанимать. Здесь приводятся стандартные подходы к принятию решений в группе. А также как обсуждать сильные и слабые стороны кандидата, а также интересный вопрос про непреодолимую причину для найма кандидата. Тут же разбирается вопрос о том, как коучить интервьюеров и давать им фидбек для их роста. А заканчивается эта часть тем, что у ребят весь процесс найма обвешан метриками и существует SLA на скорость и качество каждого шага процесса. - Подсказки - спикер рассказывает про важность менеджмента календаря и затраты по времени на проведение интервью, также про отдельное интервью, где кандидат может поспрашивать не под запись о том, как работается в компании (полезно для minority representatives), про важность процесса обучения интервьюверов, а также улучшение опыта кандидатов. P.S. За 7 лет в Тинькофф я провел 700+ интервью и прошел путь от фаната найма к себе в команду с кастомным интервью в один этап до человека, который понимает зачем нужен четкий и понятный процесс, разделенный на отдельные этапы с формальными критериями оценки для каждого из них. И основное отличие в размерах компании и стоимости ошибок первого и второго рода (ложноположительных и ложноотрицательных соответственно). В итоге, теперь я часто рассказываю про наши подходы к найму: - Про проверку навыков проектирования (system design interview) - мы спрашиваем про это у software development engineer и технических руководителей - вот тут есть материалы по этому типу интервью - Про проверку навыков работы с инцидентами (troubleshooting interview) - мы спрашиваем про это у site reliability engineers и их руководителей - подробнее подробнее можно здесь - Про менеджмент интервью - этот тип интервью варьируюется для тимлидов и руководителей уровнем выше - вот тут можно почитать подробнее #Management #Hiring #Leadership #Process #Software

100 главных принципов презентаций (100 Things Every Presenter Needs to Know About People) В любой деятельности, которой я занимаюсь системно, я пытаюсь повышать свой уровень мастерства. Для этого я использую книги, статьи, общение с экспертами. И сегодня я решил вспомнить о крутой книги, которую я прочитал еще до того, как начал часто выступать. Мне редко нравятся книги по типу 7 волшебных способов прийти к успеху, 12 шагов мастерства, язык XYZ за 24 часа, публичные выступления за 7 дней и им подобные. Но эта книга не такая - в ней автор действительно приводит 100 вещей, которые полезно знать про то, как думают люди, как они общаются, на что обращают внимание, как принимают решения и так далее. Мне эта книга напомнила микс из книг про мозг и мышление, про которые я писал в посте раньше. Если говорить про структуру книги, то она разделена на следующие разделы - Как человек думает и учится - здесь автор погружается практические советы с учетом мышления людей: зачем нужен контекст, зачем делить информацию на порции, как работает долговременная память и забывание, зачем нужны примеры, сколько элементов одновременно может держать в голове человек, почему люди любят выделять категории, как культура влияет на мышление и так далее. Это очень интересная часть, особенно если вы уже изучали эти темы, а теперь просто изучаете как это влияет на создание презентаций и публичные выступления  - Как удержать внимание аудитории - здесь автор говорит про длительность непрерывного внимания, а также то, что человек не многозадачен, что важен ритм и частота новых порций информации и как на внимание влияет подсознание - Как мотивировать человека на деятельность - здесь идет речь про дофамин, внутреннее и внешнее вознаграждение, усиление мотивации по мере приближения к цели, про сложность формирования правильных привычек и их пользу - Как человек слышит и видит - здесь идет речь про конкуренцию сенсорных каналов, важность активного слушания, насколько важно зрение и как влияет направление чтения на позиционирование элементов, а также про важность хороших заголовков и правильный подбор размера шрифта, почему мы хорошо распознаем лица, а также о проценте дальтоников - Как человек реагирует на окружающую обстановку - здесь идет речь про то, как количество людей в аудитории меняют динамику выступления, про расстановку мебели, освещенность, температуру, близость приема пищи и ожидания возможности подключиться к сети по WiFi:) - Эмоциональная реакция человека - начинается эта глава с того, что люди лучше реагируют на истории и эта реакция зачастую эмоциональна, продолжается тем, что люди любят сюрпризы, но одновременно любят безопасность, которая достигается за счет предсказуемости. Дальше идет речь про реакцию людей на красоту, музыку, радость и печаль, а также дефицитность того, что нам предлагают - Как люди реагируют на вас - эта глава важна для того, чтобы понять как вести себя во время выступлений. Например, тут идет речь про то, как люди реагируют на авторитеты, как реагируют на позы и движение, искренность и интонации, выражения лица и эмоции. Насколько важна правильная одежда и попадание в ожидания аудитории. И почему аудитория хочет того, чтобы спикер контролировал ситуацию во время выступления. - Как человек принимает решение действовать - эта часть книги пересекается с книгой Канемана “Думай медленно, решай быстро”. Здесь идет речь про принятие подсознательных решений, что страх потери сильнее предвкушения выгодыы, как настроение влияет на принятие решений, про конформизм и важность соответствовать мнению группы. Как мнение лидера влияет на коллективное принятие решений и как использовать подарки для получения обратной услуги  - Как подготовить презентацию - здесь автор рассказывает про свой пятишаговый процесс: исследование, создание, подготовка содержимого, репетиции (много репитиций), выступления (много выступлений) - Ваш 90 дневный план совершенствования - рекомендации автора как за 100 дней прокачать свои навыки презентации #Presentation #PublicSpeaking #SelfDevelopment

Почему инфраструктура big tech обычно состоит из самописных решений Крутая статья от Дмитрия, CTO команды Yandex Platform Engineering, в которой он объясняет появление кастомных решений в больших компаниях. Он выделяет 6 причин: 1. Инновации - крупные компании часто сталкиваются с новыми проблемами, для которых пока нет стандартных решений. А дальше им придумывать эти решения сами 2. Масштабы - этот пункт частично вкладывается в предыдущий, так как часто новые проблемы обусловлены масштабом компании и ее задач. В итоге, дефолтные решения на таком объеме не особо работают 3. Инерция - когда собственный инструмент уже сделан и заточен под решение внутренней проблемы, то при появлении общего инструмента он часто не так хорошо заточен на конкретные кейсы. В итоге, для переезда часто требуется допиливать сам общий инструмент 4. Миграция - тут идет речь про стоимость переезда пользователей. Часто такие миграции со старых инструментов на новые стоят дорого и могут тянуться очень долго, что подрывает сам смысл переезда - дешевле дальше поддерживать собственный велосипед 5. Business continuity - внутренние инструменты позволяют обеспечить независимость от решений вендоров и даже от изменений лицензий open source проектов. Что важно в текущей реальности 6. Синдром not invented here (NIH) - этот синдром влияет на решение пилить собственные велосипеды и это объективная реальность:) Автор демонстрирует эти причины на двух примерах - Собственное облако Яндекса, которое появилось до K8s и сейчас продолжает использоваться и развиваться - Монорепозиторий Аркадия, который позволил решить проблему svn, git, mercurial и все таки иметь возможность хранения всего кода (2 TiB) в одном репозитории Интересно, что я примерно про это писал в статье "Как RnD появляется в крупных ИТ-компаниях" на примере Google, Amazon и почему это нужно Тинькофф:) #Management #RnD #PlatformEngineering #Engineering #Software #SoftwareDevelopment #Leadership