Inner Drive: From Underdog to Global Company - Part II (Рубрика #Management)
Заканчивая обзор этой книги, начатый ранее, я хочу рассказать про самые интересные последний две части книги.
4) Seeker (искатель)
Именно здесь начинается история про InDriver, прототипом которого была группа в VK, которую запустил студент для постинга заказов для independent drivers (отсюда inDriver). Интересно, что Арсен и команда потом выкупили эту группу у студента, а самого его пригласили в штат компании. Но на одной группе они не остановились, а сделали мобильное приложение, куда постепенно переехали водители и пассажиры. Но вообще это самая философская часть, в которой Арсен ищет свой путь. Он рассказывает много про велосипедный клуб, бег, психологов, коучинг и так далее, а заканчивает рассказом о том, к чему он пришел в итоге
Собственно, отсюда рождается название последней части "developer".
5) Developer (разработчик)
Это самая динамичная часть книги, которая содержит все перепитии развития компании InDriver. Здесь есть и битвы с Yandex и Uber, поиск инвесторов и отказ от предложенных инвестиций, работу в hide режиме после получения раундов и подстройка под ковидные изменения. Здесь разбираются и события после начала 2022 года, которые привели к разделению inDriver на российскую и зарубежную части, последняя из которых лишилась буквы R и стала просто inDrive. В общем, эту часть очень интересно читать - она напоминает приключенческий детектив (как мы уже знаем со счастливым концом.
В итоге, эта интересная книга объединяет темы личностного роста, развития бизнеса и преодоления трудностей, показывая, как можно пройти путь от программиста в Сибири до глобального бизнес-лидера.
#SuccessStory #History #Management #Leadership #Processes
Заканчивая обзор этой книги, начатый ранее, я хочу рассказать про самые интересные последний две части книги.
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
Telegram
Книжный куб
Inner Drive: From Underdog to Global Company - Part I (Рубрика #Management)
В этой книге Арсен Томский от первого лица рассказывает про свой путь от скромного старта в Якутии до становления компании InDrive, которая сейчас работает практически по всему миру…
В этой книге Арсен Томский от первого лица рассказывает про свой путь от скромного старта в Якутии до становления компании InDrive, которая сейчас работает практически по всему миру…
❤5👍5🔥2
Баскетбол: ЦСКА - Локомотив (Рубрика #LifeStory)
В пятницу вечером мы с младшим сыном выписались из стационара долечиваться дома, а в воскресенье со средним сыном у нас был запланирован поход на баскетбольный матч. Максим еще ни разу не был на баскетболе, поэтому мы не просто смотрели матч, но и обсуждали правила игры, а также ее динамику. В этом плане матч не подвел - игра получилась равной, большую часть ЦСКА пытался догнать Локомотив, в четвертой четверти это сделать получилось ... Но потом Локомотив опять вышел вперед, а на последних секундах игроки ЦСКА попытались забить победную треху под сирену ... но мяч пролетел мимо. В общем, матч нам понравился, видимо, со средним сыном теперь иногда будем хотить и на баскетбол.
#ForKids #Sports
В пятницу вечером мы с младшим сыном выписались из стационара долечиваться дома, а в воскресенье со средним сыном у нас был запланирован поход на баскетбольный матч. Максим еще ни разу не был на баскетболе, поэтому мы не просто смотрели матч, но и обсуждали правила игры, а также ее динамику. В этом плане матч не подвел - игра получилась равной, большую часть ЦСКА пытался догнать Локомотив, в четвертой четверти это сделать получилось ... Но потом Локомотив опять вышел вперед, а на последних секундах игроки ЦСКА попытались забить победную треху под сирену ... но мяч пролетел мимо. В общем, матч нам понравился, видимо, со средним сыном теперь иногда будем хотить и на баскетбол.
#ForKids #Sports
🔥15👍7❤5
Design, Form, and Chaos (Дизайн, форма и хаос)
Эта классическая книга по дизайну от Пола Рэнда вышла в далеком 1993 году в "Yale University Press", а в России ее издает "Студия Артемия Лебедева". Книга очень короткая, но в ней есть определенная глубина - автор делится своими мыслями о сути графического дизайна и его роли в обществе. Автор может себе это позволить, так как у него десятилется опыта как успешного новатора в области графического дизайна. Свою книгу он выстроил вокруг следующих ключевых тем
- Связь между формой и содержанием - автор подчеркивает решающее взаимодействие между формой и содержанием, утверждая, что хороший дизайн не просто декоративен, но и служит для эффективной передачи идей
- Важность интуиции в дизайне - автор исследует роль интуиции в творческом процессе, подчеркивая, как дизайнеры должны сбалансировать инстинкт с рациональным мышлением для создания инновационных решений4
- Роль компьютеров в процессе проектирования - автор обсуждает влияние технологий на дизайн, предостерегая от чрезмерной зависимости от компьютеров в ущерб концептуальному мышлению.
По-факту, он отмечал уже в начале 90х годов засилие компьютеров и то, что молодые дизайнеры учатся зачастую не дизайну, а умению пользоваться компьютером (интересно что бы Пол Рэнд сказал на это сейчас )
- Принципы эффективного дизайна логотипов - опираясь на свой обширный опыт создания знаковых логотипов, Рэнд излагает принципы эффективного дизайна логотипа, подчеркивая простоту и запоминаемость. Мне действительно понравилась эта подборка, включающая IBM, IDEO и многие другие компании
- Искусство представления дизайнерских работ клиентам
Книга оказала глубокое влияние на сообщество дизайнеров.
1) Пол Рэнд укрепил свой статус лидера в графическом дизайне и поднял дизайн на уровень искусства и способа решения проблем клиентов
2) Акцент на форме и функции, а также призыв к критическому мышлению относительно своей работы, актуален для дизайнеров и сегодня
3) Стиль письма и крутые примеры Рэнда делают книгу популярной и доступной
4) Пол Рэнд не только делился своими мыслями и обучал коллег, но также смог поднять статус дизайна как профессии
В общем, книгу интересно прочитать даже если вы не профессиональный дизайнер, а просто мимо проходили:)
#Design #Culture #History
Эта классическая книга по дизайну от Пола Рэнда вышла в далеком 1993 году в "Yale University Press", а в России ее издает "Студия Артемия Лебедева". Книга очень короткая, но в ней есть определенная глубина - автор делится своими мыслями о сути графического дизайна и его роли в обществе. Автор может себе это позволить, так как у него десятилется опыта как успешного новатора в области графического дизайна. Свою книгу он выстроил вокруг следующих ключевых тем
- Связь между формой и содержанием - автор подчеркивает решающее взаимодействие между формой и содержанием, утверждая, что хороший дизайн не просто декоративен, но и служит для эффективной передачи идей
- Важность интуиции в дизайне - автор исследует роль интуиции в творческом процессе, подчеркивая, как дизайнеры должны сбалансировать инстинкт с рациональным мышлением для создания инновационных решений4
- Роль компьютеров в процессе проектирования - автор обсуждает влияние технологий на дизайн, предостерегая от чрезмерной зависимости от компьютеров в ущерб концептуальному мышлению.
По-факту, он отмечал уже в начале 90х годов засилие компьютеров и то, что молодые дизайнеры учатся зачастую не дизайну, а умению пользоваться компьютером (
- Принципы эффективного дизайна логотипов - опираясь на свой обширный опыт создания знаковых логотипов, Рэнд излагает принципы эффективного дизайна логотипа, подчеркивая простоту и запоминаемость. Мне действительно понравилась эта подборка, включающая IBM, IDEO и многие другие компании
- Искусство представления дизайнерских работ клиентам
Книга оказала глубокое влияние на сообщество дизайнеров.
1) Пол Рэнд укрепил свой статус лидера в графическом дизайне и поднял дизайн на уровень искусства и способа решения проблем клиентов
2) Акцент на форме и функции, а также призыв к критическому мышлению относительно своей работы, актуален для дизайнеров и сегодня
3) Стиль письма и крутые примеры Рэнда делают книгу популярной и доступной
4) Пол Рэнд не только делился своими мыслями и обучал коллег, но также смог поднять статус дизайна как профессии
В общем, книгу интересно прочитать даже если вы не профессиональный дизайнер, а просто мимо проходили:)
#Design #Culture #History
👍5❤4🔥3
Обложка книг "Design, Form, and Chaos" и "Дизайн, форма и хаос"
❤4🔥4👍2
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
В очередной раз я достал с полки старую книжку про проектирование приложений из начала двухтысячных. В этот раз эта книга создателей процесса 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
❤8🔥3👍2
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 я сегодня уже вспоминал.
В рамках исследования авторы стаивили перед собой следующие вопросы
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
Это очередной академический 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
arXiv.org
From Requirements to Architecture: An AI-Based Journey to...
Designing domain models and software architectures represents a significant challenge in software development, as the resulting architectures play a vital role in fulfilling the system's quality...
🔥5❤4👍1
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
В этом выпуске подкаста ко мне пришел Вадим Гончаров поговорить про свой путь в ИТ и как на это повлияло увлечение дизайном. Вадим в веб-разработке больше 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
Yandex Music
Interview with Vadim Goncharov about Design in S...
👍7🔥6❤4
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
Прочитал на неделе эту книгу Алана Уильямсона, что работает в частном инвестиционном фонде и часто выступает временным 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
🔥22👍15❤7