Третий раз в стационаре (Рубрика #LifeStory)

В последнее время я начал получать фидбек, что больше историй из моей жизни разбавляют сухой контент канала с книгами, whitepapers и моими мыслями о работе. Я внял этой обратной связи и решил, что буду теперь периодически писать что-то из своей жизни и сегодня у меня есть о чем рассказать. Вчера я оказался в третий раз в своей жизни в стационаре, но первые два раза я был там сам, а вчера попал с сыном. Вообще, это длинная история:
- В ноябре у него был отит, что мы вроде бы вылечили
- В начале декабря мы сходили к лору из-за соплей и стало ясно, что у нас бинго: отит + воспаленные аденоиды
- Мы решили, что надо оперировать, так как не хотелось уходить больными в Новый год
- После операции, что должна была включать удаление аденоидов и операцию на ухе, ему нельзя бы было летать месяц
- В итоге, у нас чуть не сорвался отпуск, но при операции выяснилось, что ухо прокалывать не пришлось - вода ушла сама
- Удаление аденоидов приводило к запрету на полет в 2 недели, что позволило нам слетать в Шри Ланку, но средний и старший сын уже переиграли свои планы
- Когда мы были в Шри Ланке у старшего сына (18 лет) были проблемы со здоровьем - оказалось, что он за неделю без лечения довел себя до пневмонии
- В понедельник вечером мы прилетели в Москву, во вторник я сходил на работу, а вечером вторника жену и самого маленького сына накрыло болезнью
- В среду я решил остаться поработать из дома, но приехавшие на дом врачи диагностировали отит у малыша, а также грипп у жены - эффекты были такие, что температура была у обоих в 38.5 градусов
- Жене приехали ставить капельницу на дом, так как температура нурафеном не сбивалась, а я с малышом ближе к вечеру уехал в стационар, так как тоже температура была слишком высокой
- В стационаре малышу и мне сделали тест на ковид - оказалось, что не он. Потом померили у врача температуру и сказали "сорок два", оказалось, что это было 40.2.
- Получилось, что младший сын собрал страйк: отит с жидкостью, воспаленные мендалины и грипп, но зато теперь понятно как и чем лечить - капельницы проставили и температура пошла вниз

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

Update
У малыша оказался страйк: отит, грипп, пневмония. Классно, что мы его вовремя отвезли в стационар - сейчас температура сбита, идет планомерное лечение

#LifeStory #Storytelling

Глава "API Governance" из книги API Management - Part II (Рубрика #Management)

Продолжая рассказ из прошлого поста, обсудим как можно воспользоваться подходом разделяй и властвуй и организовать governance процесс через микс централизованного и децентрализованного подхода. Для этого стоит разделить процесс принятия решений на отдельные этапы, которые похожи на пайплан разработки:) И эти этапы следующие
1. Inception (начало). Каждое решение принимается, потому что кто-то считает, что это решение необходимо принять. Это означает, что кто-то определил, что проблема или возможность существуют с более чем одним возможным решением.
2. Choice generation (генерация опций). Если вы принимаете решение в области, в которой у вас большой опыт, генерирование вариантов может быть довольно простым. Но если есть много неизвестных, вам нужно будет потратить больше времени на определение возможностей.
3. Selection (выбор). Это сердце принятия решения, на котором большинство людей фокусируется, но важность элемента выбора во многом зависит от объема доступных вариантов.
4. Authorization (авторизация принятого решения). Тот факт, что выбор был сделан, не означает, что решение принято. Выбор должен быть авторизован, прежде чем он может быть реализован. Авторизация — это работа по принятию решения о действительности выбранного выбора. Был ли сделан правильный выбор? Осуществим ли он? Безопасен ли он? Имеет ли он смысл в контексте других принятых решений?
5. Implementation (реализация). Процесс принятия решения не заканчивается, когда выбор авторизован. Реализация является важной частью работы по управлению API. Если реализация решений происходит слишком медленно или некачественно, то все ваши решения напрасны.
6. Challenge (оспаривание). Решения не являются неизменными, и каждое решение, которое вы принимаете для вашей системы управления API, должно быть открыто для оспаривания. Часто мы не думаем о том, что принимаемые нами решения могут потребовать пересмотра, изменения или даже отмены в будущем. Определение элемента вызова позволяет нам планировать непрерывные изменения на уровне принятия решений.

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

Авторы отмечаютют, что хорошие governance системы должны включать следующие фичи
- Распределение решений на основе impact, scope, and scale (про это было в первом посте)
- Enforcement системных органичений и валидация имплементации (для централизованных решений)
- Incentivization для формаирования принятия решений (для децентрализованных решений)
- Адаптивность измерения импакта и постоянных улучшений

Продолжение в последнем посте из этой серии, где мы поговорим про паттерны организации governance процессов.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Глава "API Governance" из книги API Management - Part III (Рубрика #Management)

Заканчивая серию постов про governance, расскажу про три стандартных паттерна (предыдущие части здесь: 1 и 2)
1) Design authority
2) Embedded Centralized Experts
3) Influenced Self-Governance

Я видел реализацию всех вариантов, но на масштабе и в динамической компании, как мне кажется, полетит только третий вариант.

Design authority
В этом патерне authority выступает как gatekeeper, который контролирует, что результаты команд соответствуют минимальному уровню качества
- Enforcement and incentivization. Схема наиболее эффективна, когда у них есть полномочия предотвращать принятие некачественных и высокорисковых решений.
- Talent distribution. В этой схеме небольшое количество экспертов, принимающих решения, сосредоточено в команде авторитарного проектировщика.
- Costs and benefits. Основное преимущество этой схемы заключается в том, что все API проходят через одну и ту же команду для контроля качества. Это дает гарантию правильных решений, но одновременно приводит к бутылочному горлышку

Embedded Centralized Experts
В этом паттерне вместо проверки результатов работы команды API в команду встраиваются эксперты, которые помогают принимать решения.
- Enforcement and incentivization. Внедрение экспертов в проектную группу — это высшая форма принуждения. Если ваши эксперты принимают решения, соответствующие вашим основным целям, то же самое будут делать и команды, в которые они внедрены.
- Talent distribution. Большой проблемой управления консалтинговой командой является поиск и поддержание группы экспертов. Чтобы эта модель работала, вам понадобится пул экспертов по предметной области API, которых можно распределить по проектным и продуктовым группам.
- Costs and benefits. Лучшие решения принимаются на ранних этапах, эксперты шарят свой опыт с центральной командой, но сложно поддерживать общее понимание правильных стандартов среди этих экспертов, а также нужен большой пул экспертов. Ну и сами команды могут быть демотивированы наличием такого политрука в каждой команде:)

Influenced Self-Governance
В современных организациях есть тенденции ради скорости и инноваций приходить к уменьшению централизованного контроля и увеличению автономии команды в разумных пределах. Это приводит к третьему паттерну, который в значительной степени опирается на влияние, а не на контроль.
- Enforcement and incentivization. Эта модель полностью основана на стимулировании для влияния на принятие решений. Центральная команда обеспечивает golden paths для решения типовых вопросов, но у локальных команд есть свобода выбора. Однако они сами несут ответственность за успех своих продуктов. В идеале этот баланс побуждает команды принимать решения, которые соответствуют предложению центральной команды.
- Talent distribution. Чтобы этот паттернработал, команды должны быть способны принимать правильные решения независимо друг от друга, т.е в каждой команде должны быть свои эксперты (что бывает не в каждой компании)
- Costs and benefits. Главное преимущество этой модели - скорость. Команды могут двигаться очень быстро, когда у них есть ​​автономия в принятии решений. Правда, скорость сочетается с риском того, что решения будут непоследовательными и/или неадекватными или сильно упирать на локальную оптимизацию. Для фикса этих проблем обычно добавляют центральный governance

Конкретная governance модель может меняться по мере изменений в структуре работы компании, например, по мере роста компании. Главное ориентироваться на то, как работает ваша система и вовремя подстраивать ее под изменения:)

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Inner Drive: From Underdog to Global Company - Part I (Рубрика #Management)

В этой книге Арсен Томский от первого лица рассказывает про свой путь от скромного старта в Якутии до становления компании InDrive, которая сейчас работает практически по всему миру и является второй ride sharing компанией, если ориентироваться по количеству скачиваний мобильных приложений. В книге затрагиваются следующие основные темы
- Личное путешествие автора - Арсен много рассказывает о своем личном опыте преодоления личных проблем, включая заикания и проблемы в семье
- Эволюция бизнеса - Арсен делает большой акцент на осмысленном развитии компаний, а не просто погоней за прибылью. Это прослеживается в части про создание компании и портала Sinet (Саха Интернет), а дальше и при создании InDriver, который в конце концов превратился в InDrive
- Философия лидерства - Арсен подчеркивает важность создания сплоченной руководящей команды, основанной на доброте, открытости и честности, а также поддержания четкого глобального видения со сложными целями
борьбы с несправедливостью как движущей силой инноваций.

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

1) Programmer (программист)
В этой части идет речь о ранних годах автора в Якутске в конце 1980-х, включая:
- Его воспитание в семье ученых и раннее знакомство с академической литературой
- Ключевой момент, когда он получил программируемую игрушку-вездеход в Ленинграде
- Развитие его страсти к программированию и компьютерам
- Жизнь в период сложных экономических времен России

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

3) Entrepreneur (предприниматель)
Здесь Арсен говорит про его путь через бизнес-вызовы и рост:
- Выживание во время финансового кризиса и потеря b2b контрактов
- Основание Sakha Internet с ограниченными ресурсами, а также портала ykt.ru
- Ранние трудности с финансированием и построением команды
- Развитие его первых успешных предприятий
- Помощь Якутскому университету в получение государственных грантов на развитие технологий и отстранение Арсена от их реализации в дальнейшем
- Персональный кризис, который привел Арсена к следующему этапу

Окончание обзора книги будет в следующем посте.

P.S.
Кстати, эта книга попала в список ежегодных книжных рекомендаций от McKinsey’s на 2024 год.

#SuccessStory #History #Management #Leadership #Processes

Обложка книги "Inner Drive: From Underdog to Global Company"

Design, Form, and Chaos (Дизайн, форма и хаос)

Эта классическая книга по дизайну от Пола Рэнда вышла в далеком 1993 году в "Yale University Press", а в России ее издает "Студия Артемия Лебедева". Книга очень короткая, но в ней есть определенная глубина - автор делится своими мыслями о сути графического дизайна и его роли в обществе. Автор может себе это позволить, так как у него десятилется опыта как успешного новатора в области графического дизайна. Свою книгу он выстроил вокруг следующих ключевых тем
- Связь между формой и содержанием - автор подчеркивает решающее взаимодействие между формой и содержанием, утверждая, что хороший дизайн не просто декоративен, но и служит для эффективной передачи идей
- Важность интуиции в дизайне - автор исследует роль интуиции в творческом процессе, подчеркивая, как дизайнеры должны сбалансировать инстинкт с рациональным мышлением для создания инновационных решений4
- Роль компьютеров в процессе проектирования - автор обсуждает влияние технологий на дизайн, предостерегая от чрезмерной зависимости от компьютеров в ущерб концептуальному мышлению.
По-факту, он отмечал уже в начале 90х годов засилие компьютеров и то, что молодые дизайнеры учатся зачастую не дизайну, а умению пользоваться компьютером (интересно что бы Пол Рэнд сказал на это сейчас)
- Принципы эффективного дизайна логотипов - опираясь на свой обширный опыт создания знаковых логотипов, Рэнд излагает принципы эффективного дизайна логотипа, подчеркивая простоту и запоминаемость. Мне действительно понравилась эта подборка, включающая IBM, IDEO и многие другие компании
- Искусство представления дизайнерских работ клиентам

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

В общем, книгу интересно прочитать даже если вы не профессиональный дизайнер, а просто мимо проходили:)

#Design #Culture #History