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"

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

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

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

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

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

#Design #Culture #History

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