Книжный куб

Книга-квест "Ам Ням. Жми" (Рубрика #ForKids) Вчера прочитал перед сном сыну эту книгу, в которой 20 небольших глав, а сегодня мы прошли все мини игры в дополненной реальности. Если кратко, то описание книги обещает раскрыть истинную историю появления Ам Няма, а потом Ам Ням спасет мир от супер-злодея из комптьютерной игры. Мне показалось, что это неплохая книга для дошкольников - весело и интересно, а родителям забавно читать про взаимоотношение Ам Няма и его "дамочки" сердца, Ам Няши, которую он спасает на протяжении всей книге. P.S. Книги от DEVAR нравятся нашим детям и у нас дома собрался из них полный комплект, а о некоторых я уже рассказывал: например, о "Живой раскраске Смешарики". #ForKids #ForParents #Tales

Недавно выступал на конфе имени Андрея Смирнова из X5, где рассказывал про soft skills и важности баланса между ними и hard skills. На записи есть проблемы с качеством звука, поэтому краткое саммари того, что я рассказывал такое 1) Эволюция разработки и роль софтов - Разработка за последние 20 лет стала сложнее. - В современных компаниях разработчики должны проектировать системы, писать код и тесты. - Важность коммуникации и взаимодействия между различными ролями в разработке. 2) Pipeline Driven Organization и абстракции - Pipeline Organization: интеграция различных ролей в начале процесса. - Нам нужно использовать абстракции для упрощения работы, но все равно остается необходимость взаимодействия с деталями. - Важность понимания под капотом систем и взаимодействия с разработчиками. 3) Сложность современного мира и коммуникация - Мир меняется быстро, что требует постоянной адаптации. - Коммуникация становится ключевым фактором в сложных и хаотичных условиях. - Конечно можно работать на одном уровне, но часто люди хотят активного роста. 4) Рост в инженерии и лидерство - Возможность роста в инженерии через индивидуальные проекты и менеджмент. - Важность лидерских качеств и умения вести за собой команду. - Инициатива о повышении исходит от самих сотрудников. 5) Личный опыт и планирование роста - Личный опыт становления руководителем и важность планирования времени. - Умение брать ответственность и доводить дела до конца. - Важность коммуникационных навыков и навыков переговоров. 6) Мотивация и планирование - Важно понимать, зачем ты делаешь то, что делаешь. - Поддерживай мотивацию окружающих, особенно если ты лидер. - Планирование помогает структурировать задачи и достигать целей. 7) Матрица Эйзенхауэра - Важные и срочные задачи решаются сразу. - Важные, но не срочные задачи откладываются на потом. - Срочные, но не важные задачи можно делегировать. - Цели должны быть амбициозными и достижимыми. 😍 Подход от желаемого результата (working backwards) - Начинайте с желаемого результата, а не с текущего состояния. - Стройте шаги от цели к текущему состоянию, а не наоборот. • Это помогает избежать ментальных блокировок и достигать амбициозных целей. 9) Проектный менеджмент - Проектный менеджмент полезен для больших задач с большими затратами на координацию - Важно уметь использовать проектный менеджмент для достижения целей. 10) Принятие ответственности - Признайте и примите ответственность за свои действия. - Четко определите свои обязанности и цели. - Фокусируйтесь на том, что можете контролировать 11) Решение проблем и рефлексия - Решайте проблемы, а не откладывайте их. - Учитесь на своих и чужих ошибках. - Будьте устойчивы к проблемам и показывайте пример. 12) Развитие навыков коммуникации - Активное слушание помогает лучше понимать собеседника. - Адаптируйте стиль коммуникации под аудиторию. - Важно понимать, что хочет услышать аудитория, и адаптировать свои выступления. 13) Проблемы с ясностью и публичными выступлениями - Обсуждение важности ясности в речи и публичных выступлениях. - Личный опыт выступлений на конференциях и трудности с эмоциями. - Важность фидбека и рефлексии для развития коммуникационных навыков. 14) Планирование и чекпоинты - Идея планирования с чекпоинтами для достижения больших целей. - Личный опыт написания постов и создания книг. - Важность фиксации результатов и планирования для достижения успеха. 15) Теоретический и практический подходы - Различие между теоретическим и практическим подходом к решению проблем. - Личный опыт работы с теоретическими и практическими методами. - Важность фиксации и повторения результатов для роста и развития. 16) Лидерство и софт скилы - Софт скилы важны как для инженеров, так и для лидеров. - От высокогрейдового инженера сейчас ожидается лидерская проактивная позиция - Для достижения амбициозных результатов необходимы лидерские качества и эффективные коммуникации. - Без этих навыков сложно достичь масштабных результатов. #Management #Leadership #Software #Processes #SelfDevelopment

Teaching Software Architecture Design - Building Intuition - Part II (Рубрика #Architecture) Продолжая первый пост с разбором whtepaper про обучение архитектуре, здесь я расскажу про оставшуюся часть статьи Анализ гипотез по отношению к требованиям в итоге должен вести к - Развитию инженерного подхода к принятию дизайн решений - Повышению уверенности инжнеров, что предложенный ими диазайн удовлетворяет требованиям - Способствует дискуссии о компромиссах, которые принимаются при выборе того или иного варианта дизайна Для этого авторы предлагают использовать подход с опровержимой аргументацией (defeasible argumentation), в которой аргументы принимаются на текущий момент, если они звучат разумно и приняты на основе доказательств, что есть на текущий момент. Но эти аргументы могут быть пересмотрены при появлении новых данных. Этот подход очень напоминает то, как работают люди, что проектируют софт - Они опираются на текущие данные и принимают решения в этом контексте - При появлении новой информации они могут увидеть, что это противоречит предпосылкам, на которых был основан дизайн раньше - А это потребует принятия нового решения, что изменит старое Обычно такой процесс реализуется с использованием подходов RFC и ADR, где - RFC - это request for comments или подход коммитетов к принятию решения - ADR - это architecture decision record, что добавляется в список принятых архитектурных решений. В рамках SADM студенты учатся задавать критические вопросы по отношению к дизайн гипотезам, практикуясь в формулировании аргументации, а также в ее опровержении. Причем здесь есть 2 формата аргументов 1) Аргументы для анализа use cases Если предложенная гипотеза о декомпозиции помогает реализовать необходимое поведение для конкретного сценария, то студенты могут попробовать задать критические вопросы вида - Какие исключения из шагов в сценарии делают его вклад в вариант использования недействительным? - Есть ли какие-либо побочные эффекты предлагаемой архитектуры, которые отрицательно влияют на шаги или мешают им выполняться? - Вносит ли предлагаемая архитектура отрицательный вклад в другие требования системы (варианты использования или требования к атрибутам качества)? - Нарушаются ли какие-либо ограничения во время выполнения сценария или его исключений? 2) Аргументы для анализа атрибутов качества Эта часть посложнее, так как требует много лет опыта, чтобы приводить неотразимые аргументы. А у начинающих часто аргументы звучат в формате "так работает google/aws/netflix", а значит это масштабируется, что является очень слабым аргументом. Здесь авторы предлагают студентам делать отсылки к референсной архитектуре, а также общепринятым архитектурным паттернам. Например, во второй части книги "Software Architecture in Practice" есть примеры паттернов, что приведены в свзяи с теми атрибутами качества, которые они поддерживают. Для использования паттернов можно использовать следующий подход - Показать, как предлагаемая архитектура является примером задокументированного шаблона или эталонной архитектуры. - Показать, что шаблон или эталонная архитектура, как известно, удовлетворяют указанному атрибуту качества. Критические вопросы, которые студенты могут задавать по этим аргументам звучат примерно так - Включает ли предлагаемая архитектура другие паттерны, которые отрицательно влияют на атрибут качества? - Мешает ли предлагаемый шаблон/эталонная архитектура другому требованию к системе? Авторы давали студентам дизайнить решения из разных индустрий, что приводило к тому, что баланс между атрибутами качества каждый раз был разный. Это позволило студентам научиться анализировать требования, выдвигать дизайн-гипотезы, а также составлять аргументацию в поддержку своих гипотез. В общем, цель развития интуиции при принятии дизайн-решений была достигнута. P.S. Мне кажется, что здесь описан логичный и легкий процесс того, как можно подтянуть свои умения в дизайне сложных систем:) #Architecture #Software #Engineering #SelfDevelopment

Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024 (Рубрика #Architecture) Интересное выступление Кента Бека, который когда-то не просто участвовал в подписании Agile Manifesto, а был первым подписантом среди уважаемых джентельментов ... так как шел первым по алфавиту. В этом выступлении Кент, создатель методологии XP (eXtreme Programming) рассказывает о своих экстремальных подходах к дизайну и кратко про книгу "Tidy First?", про которую я уже рассказывал раньше. Если кратко обобщить его рассказ в этом выступлении, то получится следующее 1) Начинается все с мотивации к деятельности - у нас есть порядка 3 млрд секунд (~ 95 лет). Если думать об истекающем времени, то есть мотивация не тратить его впустую 2) А в разработке софта есть много таких бесполезных вещей, например, автор так троллит тему с документацией:) 3) Когда-то давно автор участвовал в панельной дискуссии на конфе с корифеями Edward Yourdon, Larry L. Constantine, что написали книгу "Structured Design". Кент к той панельке прочел эту книгу и решил написать обновленную версию 4) Так появилась "Tidy First?", где Кент говорит про то, как наводить порядок в коде. Это позволит разработчику улучшить свое рабочее место и упростить работу. 5) Есть идея на вторую книгу "Tidy together?", в которой Кент планирует рассказать про совместную работу инженеров в командах, а в третьей книге будет рассказ про связь технологий с бизнесом 6) Основная идея автора - важность дизайна для изменения поведения системы. Софт состоит из фунукций и структуры. Про фукнции думает бизнес, а структура является backbone для этих функций 7) Если мы только клепаем фичи, то структура оказывается недоинвестированной - мы создаем технический долг, что усложняет внедрение новых фичей в дальнейшем 8 ) Цель правильного подхода в том, чтобы сбалансировать инвестиции в функции и структуру (автор приводит пример с выпиливанием дублирующего функционала) 9) Кент много говорит про социальные эффекты в разработке, про доверие и отвественность, а также разные стимулы и интересы у разных участников процесса. Обычно это называют социотехнической системой. 10) Кент много говорит про ограничения документации вида того, что она устаревает быстрее, чем ее обновляют и т.д. но не ясно какую альтернативу он предлагает 11) Кент говорит, что в разработке софта совокупная стоимость владения складывается по большей части из стоимости поддержки и модификации написанного, а не из первоначальных инвестиций в написание кода. Кстати, про этот тезис часто сейчас забывают, когда оценивают эффекты написания кода LLM ассистентами, считая только легкость начальной генерации кода:) 12) Но не все изменения стоят одинаково - обычно небольшие изменения стоят недорого, но много небольших изменений могут накапливаться и превращаться в большее, которое может стоить как значительная часть системы. В терминальном случае это большое изменение приводит к запрету версии 1.0 и создании нового пректа с нуля 13) Для снижения стоимости изменений, которые точно будут, надо понимать структуру затрат - это поможет подготовить софт к эволюции по мере изменений требований бизнеса 14) Кент говорит про coupling и про то, что изначально coupling между компонентами означал что изменения в одном элементе могут потребовать изменений в других. А потом определение Edward Yourdon, Larry L. Constantine начало мутировать и потеряло изначальный смысл 15) При разработке ПО нужно учитывать стоимость связей и стоимость их отсутствия. Важно находить компромиссы между стоимостью изменений и их последствиями. Пространство компромиссов помогает оценить целесообразность изменений. 16) Оценивать эти компромиссы лучше понимая экономические факторы вида NPV и стоимости денег во времени, оценки рисков и так далее. Например, инвестиции в структуру создают возможности для будущих изменений, что дает нам опцион на реализацию дешевых изменений в будущем 17) Отдельно автор отмечает, что наличие ограничений дает инженерам пространство и стимул для хороших решений:) #Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Teaching Software Architecture Design - Building Intuition - Part I (Рубрика #Architecture) Прочитал недавно интересный whitepaper про обучение архитектуре от Gaurav Agerwala, Len Bass. Заинтересовался я этой статьей из-за ее автора - Len Bass, который является соавтором классической книги "Software Architecture in Practice" и преподает в Carnegie Mellon University. И могу отметить, что я не был разочарован - подход авторов к обучению чем-то напоминает тот процесс system design interview, что мы практикуем у себя в компании:) Кстати, описание подхода есть на Github Ну а теперь давайте перейдем к самой статье. Исследователи в статье рассказывают о своем методе и структуре курса, который ставит себе целью демистифицировать процесс проектирования софта и помочь студентам думать аналитически, одновременно развивая интуицию, о компромиссных решениях, принимаемых на этапе проектирования. Но начинается все с введения, где авторы вспоминают про разные процессы проектирования - ACDM (Architecure Centric Design Method) - итеративный подход из середины двухтысячных к проектированию софта, который ставит проектирование в центр процессов разработки. Подробнее можно почитать здесь - ADD (Attribute Driven Design) - системная методология из начала двухтысячных для проектирования софта, которая фокусируется на внедрении и приоритизации атрибутов качества (quality attributes) одновременно с функциональными требованиями. Цель в том, чтобы создать эффективную архитектуру, которая будет удовлетворять как функциональные, так и нефункциональные требования. К обоим подходам имел отношение Len Bass, но для студентов он решил сделать процесс SADM (Software Architecture Design Method), который доступен на GitHub и который фокусируется на ключевых активностях по идентификации и анализу верхнеуровнего дизайна на основе требований. В этом он похож на ADD, но он менее формален и фокусируется на том, чтобы помочь студентам наработать интуицию. Здесь фокус скорее не на отдельных шагах сложного процесса, а на практике в дизайне сложных систем, где много неизвестных. Сама суть метода SADM в том, чтобы дать дизайнером инструмент для работы с этими неизвестными. SADM - это метод для декомпозиции системы или компонета, который выглядит так - У нас на входе есть требования - Мы строим контекстную диаграмму - Дальше выбираем scope для декомпозиции - Предлагаем гипотезу того, как можно сделать декомпозицию - Проверяем, что при этом мы удовлетворяем функциональные требования (сценарии) - Проверяем, что при этом удовлетворяем атрибуты качества (кстати, в Github репозитории есть презентации про такие атрибуты как availability, performance, observability, security, modifiability, integrability) - Если у нас есть неизвестные моменты, то мы заносим их в таблицу с process steps, чтобы разобраться с ними позже Такая декомпозиция идет пока мы не декомпозировали систему на части так, чтобы закрыть все требования. А теперь немного про process steps, куда мы переместили моменты, по которым требовалась дополнительная работа. Собственно, там могут быть 3 активности - Отложенные решения - это решения, что мы отложили до появления новой информации. Например, использовать DBaaS решение или разворачивать самому кастомную технологию. Это решение может принимать после некоторого количества итерацаций SADM процесса - Исследовательские активности - возможно требуется дополнительный сбор информации и поиск по внешним источникам, например, варианты подключаемых устройств к умному дому при дизайне IoT системы - Активности по тестированию - некоторые решения стоит принимать после построения прототипа и проверки гипотез на нем. Продолжение разбора статьи в следующем посте. #Architecture #Software #Engineering #SelfDevelopment

Как я начал публично выступать (Рубрика #LifeStory) Вчера я был на ИТ-квартирнике от наших devrel, который они проводили для людей, кто много делает для технического бренда компании. Мероприятие было теплым и ламповым - я пообщался со старыми знакомыми и похлопал коллегам, что победили в разных номинациях и поехал домой. Но пока ехал, я решил свпомнить о том, как я поборол страх выступлений и впервые вышел на сцену большой конференции, которой оказалась Teamlead Conf. К этому привели события весны 2018 года, когда я решил в марте с друзьями съездить в Сорочаны покататься на сноуборде. Вроде это должна была быть рядовая поездка, ведь катать я начал лет за девять до этого, пару раз ездил в Альпы, достаточно много катал в Подмосковье. Но тут все пошло не по плану - за мной утром, как мы и договаривались заехали друзья и мы поехали на каталку. В ту ночь я поспал пару часов, но считал, что этого достаточно. Незадолго до этого я купил жесткую и быструю доску и очень хотел ее обкатать ... Дальше я помню, как я очнулся на пассажирском сидении автомобиля, у меня болела голова, грудь, нога ... Я повернулся к своему другу, что вел машину и задал вопрос "А где мы и что происходит?". Он посмотрел на меня и, как бы нехотя, начал рассказывать, что мы поехали на склон, приехали и начали кататься, прошел где-то часик, а потом один из них увидел как кого-то похожего на меня увозят на снегокате в сторону медпункта. Дальше они пришли туда и увидели, как мне оказывают помощь. В какой-то момент я очнулся и дальше начал задавать вопросы в стиле "А где мы и что происходит?", мне на них отвечали, но через 30 секунд происходил reboot и дальше я задавал их по новой. Мои друзья решают отвезти меня в Москву, чтобы вызвать для меня скорую и положить в московскую больницу. Медперсонал дает совет по дороге общаться со мной и отвечать на повторяющиеся вопросы, ожидая, что через N итераций ребуты перестанут происходить и память схватится. Собственно, в какой-то момент так и произошло, где-то на полпути по дороге в Москву. Дальше мы доехали до нашего офиса на Водном, к которому мы вызвали скорую. Дальше меня увезли и лечили около недели от ушиба головного мозга. Из этого происшествия я вынес несколько важных уроков 1) Не стоит в плохой форме заниматься экстремальными видами спорта 2) Даже если ты профи в чем-то, то техника безопасности наше все (теперь шлем всегда со мной) 3) Очень тяжело чувствовать себя как главный герой из романа "Цветы для Элджернона" ("Flowers for Algernon") 4) Через месяц, когда из основных пост-эффектов остались только очки, я решил, что надо начать больше делится своим опытом с окружающими - чтобы были материальные подтверждения для потенциальных внуков, что их дедушка до того, как впал в маразм, был достаточно прошаренным :) Осенью 2018 года я уже выступил на питерском Teamlead Conf, где рассказывал про то, как мы выстраивали процессы разработки в наших фронтовых командах. Если найти запись этого выступления, то видно, что я сильно волнуюсь и мне сложно дается выступление на публике. Но с тех пор много воды утекло, поэтому сейчас публичные выступления на русском для меня это просто. В конце 2019 года я планировал в 2020 году податься на западные конференции и съездить выступить ... но не сложилось. Но из этих публичных выступлений вырос мой бложик TellMeAbout.Tech, а также этот tg канал. P.S. Как мне сказал однажды мой лучший друг: "В любых ситуациях надо попробовать увидеть лучшее, а не фокусироваться на проблемах". Кажется, что я внял совету и теперь вспоминаю про то падение, не как о причине серьезной травмы, а как триггер серии событий, что привели меня к знакомству с моей будущей женой. Мы с ней познакомились и начали общаться на первой конференции ArchDays, которую я открывал в главном зале, а она была ведущей второго зала:) #Storytelling #PublicSpeaking #Leadership #SelfDevelopment

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part II (Рубрика #Management) В продолжении первого поста о книге "Think Like a CTO" здесь я расскажу про вторую часть книги. 7. Ежегодная оценка сотрудников - здесь автор рассказывает про performance review, промотирование и увольнение сотрудников. Я отдельно рассказывал про performance review, а также про наш процесс Т-Роста, который мы используем для роста сотрудников 8. Технологические решения - рассказ о том, как принимать сложные технологические решения, например, buy vs build, on-prem vs cloud, reliability vs cost или closed source vs open source, микросервисы или монолиты. Если кратко, то автор рассматривает плюсы и минусы каждого из подходов. Но вообще, общий паттерн рассмотрения вопроса долженн быть таков, что надо провести исследования, сравнить альтернативы, а потом принять решения. Я больше 5 лет назад рассказывал примерно об этом в докладе "Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения" 9. Разработка - здесь автор рассказывает пару страниц о проектном управлении, потом криво рассказывает про waterfall и agile (очень криво), дальше про обеспечение качества. Честно говоря, это очень слабая глава, ооочень. По поводу проектов и продуктов рекомендую почитать мою статью, а про инженерные процессы рекомендую глянуть книгу "Grokking Continuous Delivery", про которую я рассказывал недавно 10. Работа с договорами - здесь гигиеническая база по договорной работе и важности привлечения юристов для изучения договоров:) А также важность лицензий на интеллектуальную собственность в общем, и код в частности. 11. Документация - здесь автор рассказывает базу про документацию. Правда, здесь видно, что автор привык работать в маленьких конторах и, например, предлагает документировать релизный процесс, а не нормально его автоматизировать. В общем, опять слабая глава. 12. Безопасность - очередная базовая глава про безопасность. Рекомендую вместо этого почитать книгу от Goolge "Building Secure and Reliable Systems", про которую я рассказывал. Также можно почитать старенькую книгу "Agile Application Security", про которую я рассказывал раньше 13. Поддержка и обслуживание - здесь автор рассказывает про operations часть, но делает это очень базово:) Рекомендую вместо этого почитать про это мой доклад о том, как проектировать надежные системы и поддерживать их надежность во время эксплуатации системы 14. Рост компании - глава про проведение due diligence, принятии и передаче должности технического директора. В принципе, норм, но очень базово. 15. Вы, Inc - глава о том, как идти в ногу со временем, поддеживать свой технический уровень, а также скиллы руководителя. А в конце автор дает совет, что не стоит задерживаться на работе, которая не соответствует вашим долговременным карьерным целям и не приносит удовлетворения. P.S. Про должности и ответственность CTO я уже как-то рассказывал в посте про инфляцию должности CTO #Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement

Обложки книг "Think Like a CTO" и "Настоящий CTO: думай как технический директор"

Think Like a CTO (Настоящий CTO: думай как технический директор) - Part I (Рубрика #Management) Прочитал на неделе эту книгу Алана Уильямсона, что работает в частном инвестиционном фонде и часто выступает временным CTO для небольших компаний, что покупает этот фонд. Алан написал достаточно интересную книгу на тему бытия техническим директором. По оглавлению книга выглядит как надо - автор постарался обсудить большую часть важных тем. Правда, если заглядывать внутрь, то многие из этих тем прокопаны не слишком глубоко. Я связываю это с тем, что Алан работал в основном с небольшими и нетехнологическими компаниями, поэтому его советы годятся на инженерный масштаб до нескольких десятков людей. Оригинальная книга издана в Manning, а перевод вышел в издательстве "Питер" и он приемлемый. А теперь давайте заглянем в содержание книги 1. Технический директор - размышления автора насчет содержимого роли технического директора в зависимости от размера компании, ее типа, стадии жизненного цикла. В далеком 2021 году я рассказывал доклад "Что такое CTO от стартапа до IPO" на Highload++". Смысл примерно такой же, но мне кажется, что у меня получилось поинтереснее:) 2. Взаимодействие с руководителями и коллегами - здесь автор рассказывает как находить общий язык с CEO и CFO. Звучат советы про то, чтобы понять потребности коллег и найти с ними общий язык. Вообще важно уметь в правильные коммуникации и разбираться во внутренней политике:) А также надо уметь правильно реализовывать изменения. Отдельно автор упоминает про разные стили лидерства, приводя в пример оркестр - тут я рекомендую почитать книгу "Несведущий маэстро" ("The ignorant maestro") про стили лидерства на примере стилей знаменитых дирижеров, про которую я уже рассказывал. А также рекомендую изучить книгу "Seat at the Table", которая рассказывает что нужно уметь техническому директору, чтобы сидеть за одном столом с другими топ-менеджерами (я про нее тоже рассказывал). 3. Долгосрочное видение - здесь речь идет про видение, миссию, стратегию организации, а также необходимость сделать так, чтобы технологическая стратегия помогала с этим. Автор рассказывает про долгосрочное планирование, питчинг идей, бюджетирование, окупаемость проектов, а также работу с ожиданиями стейкхолдеров. Я на эту тему могу порекомендовать отличную книгу "Technology Strategy Patterns. Architecture as Strategy", которую я изучил больше пяти лет назад и которая дала мне многое в плане построения технологической стратегии (я рассказывал про нее здесь) 4. Создание команды - здесь автор рассматривает разные способы формирования команды: найм в штат, найм на подряд, аутстафф, аутсорс и так далее. По-факту, автор дает базовую сравнительную табличку с плюсами и минусами каждого из вариантов. Также он рассказывает про матрицу навыков, которую стоит заполнять по своим людям в команде, чтобы понимать какие области небходимых навыков закрыты хорошо, а по каким есть риски (условно, только Петя знает про инфру и если он уйдет, то хз что станет с серверами) - это позволяет искать кандидатов, что усилят команду. Дальше автор говорит про составление вакансии и поиск кандидатов через разные источники. В общем, все очень просто и базово. 5. Собеседования, выбор подходящего кандидата и его онбординг - здесь автор рассказывает про собеседования, но очень базово. Мне кажется, что я гораздо интереснее это раскрыл в своей серии статьей про найм: как нанимают в крупные компании, а потом отдельно про разработчиков, руководителей, SRE и даже аналитиков. 6. Управление командой - здесь автор говорит про типы команд, их цели, метрики, состав и так далее. Но мне кажется, что про эту тему лучше почитать книгу "Team topologies", в которой отлично разложено какие команды бывают, какие у них бывают цели и форматы взаимодействия, тем более я уже рассказывал про эту книгу раньше. Ну и у меня есть большой рассказ про то, как создавать команды под запросы бизнеса Продолжение обзора книги будет в следующем посте. #Management #Leadership #Processes #Software #Architecture #Strategy #ChangeManagement

Code of Leadership #28 - Interview with Vadim Goncharov about Design in Software Development (Рубрика #Management) В этом выпуске подкаста ко мне пришел Вадим Гончаров поговорить про свой путь в ИТ и как на это повлияло увлечение дизайном. Вадим в веб-разработке больше 15 лет. В 2008 руководил собственной веб-студией. С 2013 работал в VK, а в 2017 присоединился к Т-Банку, где в качестве технического руководителя запускал "Тинькофф Журнал", самое крупное медиа про деньги в России. С 2020 Вадим начал руководить разработкой интерактивных спецпроектов и игр в мобильном приложении Т-Банка. Он проповедует lifelong learning: закончил МИЭМ, учился в Британке и Вышке, а сейчас учится в Сколково на программе МБА. Эпизод также доступен в Yandex Music и podster.fm Мы обсудили следующие темы - Ранние годы Вадима и учебу в школе и универе: Вадим всегда увлекался играми, учился в физмат лицее, а потом пошел в МИЭМ - Влияние образования на карьеру: университет дал Вадиму базовые знания и умение учиться. Он подчеркивает важность понимания взаимосвязи различных идей и концепций. - Создание агентства дизайна: после школы Вадим основал агентство дизайна в Подольске, которое занималось разработкой и дизайном сайтов - Принципы работы и качество: В агентстве уделялось большое внимание качеству и эстетике. Вадим подчеркивает важность развития вкуса и поиска хороших специалистов. - Влияние книг и обучения: Вадим рассказывает о влиянии различных книг, что повлияли на его подход к дизайну и разработке. - Сертификация и фреймворки: обсуждается важность сертификации в программировании и изучения различных фреймворков. - Визуализация данных: Вадим говорит о важности визуализации данных и упоминает работы Эдварда Тафта. - Взаимодействие дизайнеров и разработчиков: Вадим подчеркивает важность синергии между дизайнерами и разработчиками для создания качественных продуктов. - Опыт работы в Mail.ru: Вадим рассказывает о своем опыте работы в Mail.ru, где он развивался как фронтенд-разработчик и тесно сотрудничал с дизайнерами. - Обучение в Британке: Вадим рассказывает о том, как обучение в Британской школе дизайна прокачало его скиллыы Список рекомендаций для изучения - Программист Прагматик. Эндрю Хант - Совершенный код. Стив Макконнелл - Чистый Код. Роберт Мартин - Release It! Second Edition. Design and Deploy Production-Ready Software. Michael Nygard - Дизайн привычных вещей. Дональд Норман - Дизайн для реального мира. Виктор Папанек - Дизайн-мышление в бизнесе. Тим Браун - Beautiful Evidence. Edward Tufte - Visual Explanations: Images and Quantities, Evidence and Narrative. Edward Tufte - Envisioning Information. Edward Tufte - The Visual Display of Quantitative Information. Edward Tufte - Look Inside: Cutaway Illustrations and Visual Storytelling. Juan Velasco and Samuel Velasco #Management #Leadership #Software #Processes #Retrospective #Design #Processes #SelfDevelopment

From Requirements to Architecture: An AI-Based Journey to Semi-Automatically Generate Software Architectures (Рубрика #Architecture) Это очередной академический whitepaper про использование AI в разработке софта. Здесь исследователи за 4 странички успевают - Изложить свой план исследований, все значимое обещают в следующих сериях - Сделать обзор предыдущих статей на тему генерации архитектуры из документации и автоматической оценки ее качества. Концептуально процесс генерации от ребят выглядит так 1) Взять качественные требования и сгенерировать LLMs доменную модель и набор use cases 2) Взять напильник и немного ручками доработать получившуюся доменную модель и сценарии 3) Взять доработанные модель и сценарии и сгенерировать LLMs несколько архитектур-кандидатов + вытащить как-то ключевые ADR, которые были приняты при их проектировании. Тут предполагается использовать старый добрый "4+1 Model" от P. Kruchten (из 1995 года) + диаграммы в PlantUML и Mermaid 4) Взять кандидатов и прогнать через автоматизированную оценку (стандартный ATAM или другие подходы). Если с автоматизацией не сложится, то авторы готовы к запасному варианту в виде ручной оценки 5) Дальше если нужно эти архитектуры-кандидаты доработать через промпты к LLMs с просьбами о доработках 6) Финальным шагом является ручной выбор лучшего кандидата Процесс до боли напоминает ICONIX в части генерации архитектуры из требований, но автоматизированный. Кстати, про ICONIX я сегодня уже вспоминал. В рамках исследования авторы стаивили перед собой следующие вопросы

RQ1: Can state-of-the-art NLP technology generate reproducible, correct, and elaborate domain models and use case scenarios based on requirements in natural language? RQ2: Can state-of-the-art AI technology generate software architectures based on a domain model, use case scenarios, and requirements that can appropriately fulfill these requirements? RQ3: Can quantitative and qualitative software architecture evaluations and trade-off analyses be automated through the use of AI? RQ4: Does a method for semi-automatic architecture generation improve the architecture’s quality while reducing the time required? Ответы

на вопросы в этой статье не даны, но есть план на дальнейшие исследования, который включает 1) Ручной разбор нескольких референсных архитектур для восстановления списка требований к ним 2) Дальше скармливание этих требований обратно LLMs и получение архитектур-кандидатов 3) Сравнение этих кандидатов с референсными архитектурами глазами 4) Попытка сделать автоматическую оценку архитектур-кандидатов Отдельно авторы отмечают, что на следующих этапах на вход они хотят подавать не только требования, но и текущую архитектуру системы, а также архитектурные решения, что к ней привели. Это позволит прийти к итеративно-эволюционной модели развития архитектуры системы по мере ее создания из начального набора требований, а потом ее изменений по мере изменения внешнего контекста и требований к системе. Из референсов к статье мне показались интересными - "Software Architecture Metrics: a literature review" с обзором архитектурных метрик - "Experiences applying automated architecture analysis tool suites" с опытом автоматического примения инструментов для анализа Также я вспомнил - "Architecture Anti-patterns: Automatically Detectable Violations of Design Principles" - хороший paper, мой разбор здесь - "Enhancing Software Design and Developer Experience Via LLMs" - поверхностый paper, мой разбор здесь Собственно, этот paper по уровню практической проработанности слаб, но теоретически план исследований выглядит интересно. #LLM #AI #Architecture #Software #Engineering #Management #Processes

Applying Use Case Driven Object Modeling With Uml: An Annotated E-Commerce Example (Применение объектного моделирования с использованием UML и анализ прецедентов) В очередной раз я достал с полки старую книжку про проектирование приложений из начала двухтысячных. В этот раз эта книга создателей процесса ICONIX, который предшествовал RUP и Agile. В книге базово описывается теоретическая часть процесса, а также даются практические примеры его применения для проектирования книжного онлайн магазина, а также списки типичных ошибок. По-факту, подробно описываются четыре основных этапа из ICONIX 1) Анализ требований - Создание функциональных требований - Моделирование предметной области - Определение поведенческих требований (прецеденты использования) 2) Предварительное проектирование - Проведение анализа надежности (robustness analysis) - Обновление модели предметной области 3) Детальное проектирование - Создание диаграмм последовательности - Доработка статической модели (диаграммы классов) 4) Реализация - Написание кода и модульных тестов - Интеграционное и сценарное тестирование В итоге, весь процесс выглядит примерно так, как представлено на приложенных изображениях:) Для начала двухтысячных подход был достаточно интересен и книга была полезна, но сейчас она скарее находка для коллекционеров, чем актуальное руководство по уже отмершему процессу ICONIX. P.S. Раньше я уже рассказывал про ретро-книги из начала 2000-х про процессы разработки софта - Введение в RUP (The Rational Unified Process. An Introduction) - Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки (Agile Modeling: Effective practices for XP) - Разработка Web-приложений с использованием UML (Building Web Applications with UML) А также разбирал видео с Гради Бучем про эволюцию software architecture, кстати, Гради - один из создателей UML #SoftwareArchitecture #Architecture #Software #Management #Processes

Обложка книг "Design, Form, and Chaos" и "Дизайн, форма и хаос"

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

Баскетбол: ЦСКА - Локомотив (Рубрика #LifeStory) В пятницу вечером мы с младшим сыном выписались из стационара долечиваться дома, а в воскресенье со средним сыном у нас был запланирован поход на баскетбольный матч. Максим еще ни разу не был на баскетболе, поэтому мы не просто смотрели матч, но и обсуждали правила игры, а также ее динамику. В этом плане матч не подвел - игра получилась равной, большую часть ЦСКА пытался догнать Локомотив, в четвертой четверти это сделать получилось ... Но потом Локомотив опять вышел вперед, а на последних секундах игроки ЦСКА попытались забить победную треху под сирену ... но мяч пролетел мимо. В общем, матч нам понравился, видимо, со средним сыном теперь иногда будем хотить и на баскетбол. #ForKids #Sports

Inner Drive: From Underdog to Global Company - Part II (Рубрика #Management) Заканчивая обзор этой книги, начатый ранее, я хочу рассказать про самые интересные последний две части книги. 4) Seeker (искатель) Именно здесь начинается история про InDriver, прототипом которого была группа в VK, которую запустил студент для постинга заказов для independent drivers (отсюда inDriver). Интересно, что Арсен и команда потом выкупили эту группу у студента, а самого его пригласили в штат компании. Но на одной группе они не остановились, а сделали мобильное приложение, куда постепенно переехали водители и пассажиры. Но вообще это самая философская часть, в которой Арсен ищет свой путь. Он рассказывает много про велосипедный клуб, бег, психологов, коучинг и так далее, а заканчивает рассказом о том, к чему он пришел в итоге

I am deeply invested in promoting the development of the things I care about – in building something huge, brilliant, and excellent from nothing. This inspires me, my team, and many others, giving us strength and energy. And I’m the one helping to make it happen, a “developist,” a true believer in development’s power and opportunities––that’s the word that best describes my sense of self and my personal mission.

Собственно, отсюда рождается название последней части "developer". 5) Developer (разработчик) Это самая динамичная часть книги, которая содержит все перепитии развития компании InDriver. Здесь есть и битвы с Yandex и Uber, поиск инвесторов и отказ от предложенных инвестиций, работу в hide режиме после получения раундов и подстройка под ковидные изменения. Здесь разбираются и события после начала 2022 года, которые привели к разделению inDriver на российскую и зарубежную части, последняя из которых лишилась буквы R и стала просто inDrive. В общем, эту часть очень интересно читать - она напоминает приключенческий детектив (как мы уже знаем со счастливым концом. В итоге, эта интересная книга объединяет темы личностного роста, развития бизнеса и преодоления трудностей, показывая, как можно пройти путь от программиста в Сибири до глобального бизнес-лидера. #SuccessStory #History #Management #Leadership #Processes

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

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 контрактов - Основание Saka Internet с ограниченными ресурсами, а также портала ykt.ru - Ранние трудности с финансированием и построением команды - Развитие его первых успешных предприятий - Помощь Якутскому университету в получение государственных грантов на развитие технологий и отстранение Арсена от их реализации в дальнейшем - Персональный кризис, который привел Арсена к следующему этапу Окончание обзора книги будет в следующем посте. P.S. Кстати, эта книга попала в список ежегодных книжных рекомендаций от McKinsey’s на 2024 год. #SuccessStory #History #Management #Leadership #Processes

Глава "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

Глава "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