Чистый дизайн (Tidy First?) - Part II - Очистка (Tidyings)

Продолжая первый пост о книге "Чистый дизайн" расскажу для начала про первую часть, в которой автор рассказывает о концепции небольших изменений, которые делают код проще. Причем здесь мы меняем структуру софта, а не его поведение. Автор говорит, что это напоминает рефакторинг и tidyings - это подможество рефакторинга. Отдельный термин появился потому, что рефакторингом теперь часто называют и те измения, что меняют поведение программы, а автор это хочет четко отделить.

В итоге автор предлагает следующие подходы
- Охранные выражения (guarding clauses) - вынос в начало функции начальных выражений, которые надо учитывать и ранний возврат при их наступлении из функции
- Мертвый код (dead code) - его просто надо удалить (если он понадобится, то его можно будет восстановить из системы контроля версий)
- Нормализация симметрий (normalize symmetries) - если кратко, то надо использовать консистентные подходы по всему коду, например, подход к определению и инициализации переменных. Тут могут помочь линтеры или подходы к readability, как в Google (про которые я писал раньше в посте про measuring engineering productivity)
- Новый интерфейс, старая реализация (new interface, old implementation) - при реализации изменений мы можем определить новый красивый интерфейс и всех перевести на него, а поначалу под капотом дергать вызов старой реализации. На самом деле это дефолтный подход при миграциях:)
- Порядок чтения кода (reading order) - файл с кодом должен быть устроен так, чтобы его было удобно изучать читателю (забавно, что это верно для всего: книг, презентаций, мануалов)
- Принцип связности (cohesion order) - суть в том, чтобы организовать код в файле так, чтобы при изменениях элементы, что меняются вместе, распологались рядом. Это же верно и для разных файлов, что сцеплены (coupling) - их можно перенести в общий каталог.
- Соединение объявления переменной и его инициализации (move declaration and initialization together) - опять же тут суть в том, чтобы свести связанные кусочки логики вместе
- Пояснительные переменные (explaining variables) - создание отдельных переменных для сложных выражений вместо вычисления их just in place, например при прокидывании выражения в параметры вызываемой функции
- Пояснительные константы (explaining constants) - создание констант вместо раскиданных по коду магических значений
- Явная передача параметров (explicit parameters) - вместо прокидывания hashmap с ненормированным количеством параметров лучше их явно прокинуть в параметры при вызове функции
- Визуальная группировка инструкций (chunk statements) - если при чтении кода вы понимаете, что одна часть делает вот это, а другая делает то, то просто добавьте дополнительную пустую линию между этими блоками кода, плюс этот блоки кода можно улучшать при помощи остальных советов из этой части
- Извлечение функций-хелперов (extract helper) - извлечение вспомогательных блоков кода в отдельные функции с именем
- Одна большая свалка (one pile) - во время очистки иногда требуется свести все части кода в одно место, а уже потом применять остальные подходы. Когда мы делаем так, то получаем одну большую свалку.
- Содержательные комментарии (explaining comments) - если при чтении куска кода у вас щелкает и возникает мысль "Ах, вот что это такое", то есть смысл записать это озарение в комментарий
- Удаление избыточных комментариев (delete redundant comments) - иногда при очистке кода часть комментариев становится очевидной, в этот момент такие комментарии стоит удалить.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Lessons from a Hyperscaler • Casey Rosenthal • GOTO 2024

Интересный доклад от Casey Rosenthal, автора книги "Chaos Engineering", в котором он рассказывает о тех уроках, что были получены от работы в компаниях-гиперскейлерах, где hyperscale это

Hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system.

Сам автор работал в компании Netflix и был изначально в traffic team, которая отвечала за то, чтобы Netflix работал для пользователей. А в комплексных системах возникает такой уровень сложности, который не помещается ни в одну голову. Для того, чтобы бороться с этой сложностью в Netflix придумали Chaos Monkey, который рандомно отключает машинки с частями системы. Это помогает инженерам искать системные недостатки и принимать решения для повышения надежности системы. Дальше автор приводит конкретный пример с двумя микросервисами, один из которых stateful и хранит данные в persistent DB, а также у него есть кеш в Redis. А дальше что-то идет не так со stateful сервисом и вся система деградирует:) Суть примера в том, что в комплексных системах возможны пробелмы, несмотря на то, что все компоненты соответствуют спецификациям.

Автор говорит про 4 модели, что помогают гиперскейлерам бороться со сложностью:
- Observability (not metrics) - обеспечение наблюдаемости системы, просто метрик для этого не достаточно
- DevUX (platfoorm engineering) - создание платформенных команд, что делают dev2dev продукты, что снижают когнитивную сложность (можно почитать мой разбор "State of Platform Engineering Report 2023 от Puppet")
- Experimentation over testing - экспериментирование, а не тестирование. Суть в том, что эксперименты помогают узнать что-то новое о системе, а тестирование - это проверка того, что система соответствует нашим ожиданиям
- Low bureaucracy - низкий уровень бюрократии, где у инженеров достаточно полномочий на то, чтобы делать свою работу без кучи согласований

Автор рассказывает про 4 экономических столпа комлексности
- States - ограничение количества состояний системы. Например, Ford Model T, где потребитель мог купить машину любого цвета, если этот цвет черный:) Но сейчас это ушло в прошлое и мы ценим вариативность и персонализацию продуктов под конкретного клиента
- Relationships - здесь у нас тоже все идет по нарастающей - добавляются новые связи, новые уровни абстракции, динамическое поведение систем становится все сложнее
- Environment - окружающая среда тоже не отличается предсказуемостью и мало кто из компаний может на нее как-то значимо повлиять в свою пользу (если вы не Amazon или Google)
- Reversability - а вот тут разработка софта сильно выделяется на общем фоне. Мы можем выбрать для себя фокус на этом и получить возможность откатывать изменения. Тут нам в помощь CI/CD, a/b тестирование гипотез, ... Но для того, чтобы это все работало нам требуется observability.

И автор рассказывает про подходы: observability 1.0 и observability 2.0, где observability 1.0 это
• Metrics (метрики)
• Unstructured logs (неструктурированные логи)
• Structure logs (структурированные логи)
Недостатком observability 1.0 является убывающая полезность и нарастающие затраты на создание и хранение логов и метрик. Суть в том, что по мере роста системы, добавления компонентов, инцидентов, логов будет становиться все больше и сложно будет искать в них нужную информацию, а также это все будет занимать все больше места.

В качестве ответа автор говорит про observability 2.0, который обладает следующими возможностями:
- Это подход с high cardinality / high dimenions и в одном месте, который является единым источником истины
- Из этого хранилища можно получать показатели, логи, структурированные и неструктурированные данные
- А кроме того, это не уменьшает эффективность разработчиков, а скорее увеличивает за счет использования одного решения

У нас в Tinkoff таким единым источником истины является Sage, наша obserbility платформа, которая является стандартом де-факто для всех в компании.

#Devops #PlatformEngineering #Management #SoftwareDevelopment #Software #SRE

Чистый дизайн (Tidy First?) - Part III - Управление (Managing)

Продолжая посты (1 и 2) о книге "Чистый дизайн" расскажу про вторую часть, в которой автор рассказывает о том, как управлять очисткой: когда начинать, когда заканчивать, а также как объединить ее с изменением поведения системы. Здесь автор дает следующие советы

- Очистка отдельно (separate tidying) - очистку надо проводить отдельно от изменений, что меняют поведение системы. Это можно легко организовать заворачивая все изменения по очистке в отдельный MR (merge request). Плюс надо думать над размером MR - он должен давать некоторую картину для понимания изменений, но, одновременно, не быть слишком большим для осмысления
- Цепочки (chaining) - когда вы начинаете очистку, то эти изменения начинают создавать изменения для дальнейшей очистки. Важно уметь планировать очистку на несколько шагов, а также знать, когда требуется остановиться. Подробнее про подходы к очистке можно прочитать во втором посте по книге
- Размер наборов операций (batch sizes) - здесь автор рассказывает как определиться с размером очистики. Он предлагает оценивать стоимость ревью изменений (что форсирует не делать маленькие MRs с очисткой) и проблемы с большими батчами по очистке: потенциальные коллизии, изменения в поведении и спекулятивные изменения. В итоге, нам надо найти оптимум:)
- Ритм (rhythm) - автор говорит о том, что в уборке нужна ритмичность - мы не можем разово убраться и забыть об очистке:) Нам надо делать это периодически, если мы хотим жить в чистом месте
- Распутывание (getting untangled) - иногда, при написании кода, изменяющего поведение, приходит идея провести очистку. Дальше опять дописать код, что меняет поведение, а потом еще почистить код. Автор предлагает не делать так, а если все таки у вас получилось такое запутанное изменение, то снести его и дальше сделать все сначала с новыми знаниями и пониманием, что надо поделить изменения поведения и очистку на отдельные MRs
- До, после, позже, никогда (first, after, later, never) - ответ на вопрос, а когда делать очистку. И это как обычно it depends ... И тут все зависит от экономических эффектов: если очистка сильно поможет нам с дальнейшим внесением изменений, то можно начать с нее. А если нам никогда-никогда не придется менять код (мы пишем разовый скрипт), то чистить ничего не требуется:) А вот варианты в промежутке уже посложнее и по ним автор дает следующие рекомендации:
- Проводите очистку после изменений, если
-- Ожидание следующего удобного случая, чтобы провести ее сразу перед изменениями, обойдется дороже
-- Без этого вы не чувствуете, что работа завершена
- Проводите очистку позже, если
-- Очистка предполагает много работы, которая не возымеет немедленного эффекта
-- Ее завершение окупится позже
-- Ее можно проводить небольшими частями

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

МегаШкола ИТМО 2024 Игорь Котенков - State of the LLM Landscape

Интересный доклад с обобщением состояния дел в LLM (large language modes) от Игоря Котенкова, автора канала "Сиолошная" (@seeallochnaya), который я почитываю с интересом. Конкретно в этом видео автор за 2 часа дает хороший обзор последних достижений для студентов ИТМО.

Из презентации (что доступна здесь) я вынес следующие моменты
- Что такое большие языковые модели, как они работают и для чего их сейчас используют
- Как LLMs уже влияют на реальный мир (особенно когда они начинают использовать интернет для выполнения действий) и какое их ждет будущее
- Как обучают большие языковые модели - по-факту, модели предсказывают следующее слово в контексте, модель обучается на большом количестве текста (значимая часть интернета), дальше на выходе получается многогигабайт параметров, которые задают веса в моделе
- Дальше модельку доучивают с использованием человека - есть пара текстов, где один из ответов выбирается человеком как лучший и это подается модельке. В итоге, это ускоряет процесс обучения и оптимизирует человеческие предпочтения.
- ChatGPT - для создания модели использовались огромные мощности и высококачественные данные, а дальше продукт стал самым быстрорастущим в мире и достиг 100 млн пользователей примерно за 2 месяца
- Чатботы сейчас уже можно использовать для автоматизации деятельности, например, для повышения эффективности разработчиков (подробнее в докладе про Copilot) или для повышения эффективности консультантов (пример от BCG)
- LLMs могут научиться не просто гененрировать текст, но и некоторым навыкам, например, математическим
- Исследователи активно работают на интерпертируемостью LLMs, в перспективе это позволяет модели запоминать и применять паттерны, а не запоминать все подряд.
- При использовании LLMs могут быть проблемы с утечкой конфиденциальной информации
- Пока единственный гарантированный способ сделать LLM лучше - это насыпать больше мощностей и подкинуть данные получше на стадии обучения, но исследователи постоянно пытаются придумать еще что-то, например, оптимизируя алгоритмы
- К моделям можно подключать инструменты, например, калькулятор (или Wolfram Alfa, про это можно подробнее почитать в книге Стивена Вольфрама "What Is ChatGPT Doing ... and Why Does It Work?", про которую я рассказывал раньше)
- Модели можно помогать, попросив построить цепочку рассуждения (chain-of-thought prompting)
- Дальше внешние инструменты и chain-of-thought можно объединить в подходе ReAct (Reasoning + Actions). ReAct - это способ промтинга, позволяющий модели выполнять несколько шагов поиска информации. Игорь дает интересные примеры с моделями
-- Для поиска информации в интернете и вставкой текста в модель
-- Для использования сервиса для обмана капчи:)
-- Для синтеза ядов
-- Для генерации предметов в майнкрафте, где модель создала себе skill library и выучила скиллы по созданию предметов
- LLMs могут работать не только с текстом, но и с видео, звуками и другими модальностями
- На базе LLMs можно создавать автономные браузерные агенты, которые будут выполнять действия на сайте, предсказывая, что нужно сделать.
- Для обучения моделей можно использовать синтетические данные, сгенерированные другими моделями. Это позволяет улучшить качество обучения и увеличить навыки модели.
- Есть направление по использованию LLM в научных исследованиях, так как LLM могут генерировать десятки тысяч, сотни тысяч ответов на задачи, что позволяет строить дерево мыслей и находить правильный ответ. В будущем такие модели могут быть использованы для создания научных статей и новых знаний.
- Сейчас LLMs могут выдумывать факты или соглашаться с неправильными фактами, но это может быть решено в будущем.
- Дальше ML будет охватывать все новые и новые сферы или доводить до идеала те, в которых уже применяются технологии. В итоге, будет работа как по созданию лучших моделей, так и по интеграции существующих моделей для решения реальных бизнес-задач.

#DataScience #ML #AI #Data #PopularScience #Math

Чистый дизайн (Tidy First?) - Part IV - Теория (Theory)

Продолжая посты (1, 2 и 3) о книге "Чистый дизайн" расскажу про последнюю часть, в которой автор делится своими теоретическими изысканимями, которые позволяют наработать интуицию в принятии решений относительно дизайна софта. Здесь автор рассматривает вопросы

- Что такое программный дизайн?
- Как дизайн влияет на разработку и эксплуатацию софта и наоборот?
- Стоит ли вкладываться в проработку струтктуры софта и к чем это приведет?
- Каакие принципы (экономические и гуманитарные) можно использовать для принятия решений о изменении структуры софта?

И вот что я вынес из этой части
- Взаимовыгодные отношения между элементами (bene€cially relating elements) - собственно, это и есть определение программного дизайна от автора, которое лаконично и интересно. По-факту, в определении приведены основные части: элементы, отношения и взаимная выгода между ними. А дизайнеры - это те, кто как раз обеспечивают то, чтобы отношения были взаимовыгодными.
- Структура и поведение (structure and behavior) - ценность кода в том, что он умеет делать уже сейчас (поведение), а также в том, что он сможет делать завтра (структура). Поведение можно характеризовать двумя способами: парами вход/выход и инвариантами, которые сохраняются во время изменений системы. Структура не влияет напрямую на поведение, но она влияет на варианты развития событий - насколько нам просто будет дорабатывать систему тем или иным способом. Изменения в поведении видны сразу, а вот изменения в структуре замерить сложно, поэтому их часто откладывают.
- Экономика: ценность во времени и вариативность (economics: time value and optionality) - автор рассказывает про природу денег:
-- Доллар сегодня стоит больше доллара завтра, поэтому зарабатывать надо раньше - тут можно посмотреть в сторону дисконтированных денежных потоков и NPV
-- В ситуации хаоса лучше вариативность, чем однозначность, поэтому перед лицом неопределенность создавайте варианты
В итоге, задачей дизайн автор видит согласование императивов "зарабатывать раньше/тратить позже" (поведение) и "создаавать вариативность, а не однозначность" (структура).
- Доллар сегодня стоит больше, чем доллар завтра (a dollar today > a dollar tomorrow) - рассказ про пальцах про дисконтирование денежных потоков
- Вариативность (options) - рассказ про "дилемму Златовласки", где у нас не должно быть слишком много дизайна или очень рано, но и не должно быть слишком мало дизайна или слишком поздно. Дальше вступает в дело концепция опционов, когда мы платим деньги сейчас за возможность купить что-то в будущем. В итоге, проектирование, которым мы знимаемся сегодня, - это "опционная премия", которую мы платим, "покупая" изменения поведения программы в будущем.
- Опционы и денежные потоки (options versus cash flows) - здесь автор объясняет как принимать решения об очистке (tidying) с учетом наших знаний ою опционах. Одновременно звучит тезис о том, что программный дизайн - это про налаживание отношений с людьми, а очистка - это про отношения с самим собой:) Считать всю экономику для очистки часто бывает затратно, но принимая решения о ней мы тренируем
-- Привычку читывать факторы, влияющие на время и область действия дизайна
-- Навыки выстраивать взаимоотношения с людьми
- Обратимые изменения структуры (reversible structure changes) - структурные изменения обычно обратимы, а вот изменения в поведении приводят к сайд-эффектам, которые мы не всегда можем откатить (условно, рассылка не тех сообщений не тем людям). В итоге, надо работать с разной степенью тщательности с обратимыми и необратимыми изменениями (это сходно с концепцией one-way door и two-way door decisions как это описывал Джефф Безос)

В следующем посте я расскажу про оставшиеся части теории и про литературу, что советует изучать автор.

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

Как Китай теряет свое экономическое превосходство | Разбор на цифрах (видео с канала MyGap)

Как-то раньше я уже говорил, что мне нравится инфографика для представления информации. А еще я люблю иногда читать комиксы по сложным темам. Обе эти вещи скомбинированы на канале MyGap, где автор делает информативные мультики на интересные темы. Например, в последнем видео была разобрана история с китайским экономическим чудом, которое вывело экономику КНР на второе место о номинальному ВВП после США, и на первое по ВВП по паритету покупательной способности (с 2014 года). Бурный рост проходил с 1979 года по 2010, но потом чуддо забуксовало и за фасадом мегапроектов забрезжили убытки и долги.

В этом видео MyGap расскажет на пальцах как китайское экономическое чудо теряет волшебный ореол и как это может отразиться на остальном мире:)

#PopularScience #Economics #Comics #Infographics

Чистый дизайн (Tidy First?) - Part V - Теория (Theory)

Этот пост заканчивает серию про книгу "Чистый дизайн" (предыдущие посты: 1, 2, 3 и 4).

- Зацепление (coupling) - автор описывает концепцию каскадных изменений, когда изменения в одном компоненте тянут за собой изменения в других компонентах. Это свойство описали еще Эд Йордон и Ларри Константайн в своей книге "Structured Design" и определение звучало так

Два элемента считаются связанным в отношении некоторого изменения, если изменение одного элемента требует изменения другого элемента

В это определении важно не просто, что элементы связаны между собой, но и что эта связь существует относительно определенного изменения. Поэтому для анализа coupling недостаточно простого просмотра исходного кода - важно знать какие изменения уже произошли, а также какие возможны в будущем. В итоге, coupling повышает затраты на разработку, поэтому при очистке часто полезно понимать какие изменения приведут к его уменьшению.
- Равенство Костантайна (Constantine’s equivalence) - интересная цепочка размышлений автора
-- Где он начинает с того, что большую часть совокупной стоимости владения кодов составляет стоимость измений -> cost(software) ~= cost(change)
-- Продолжает тем, что стоимость изменений имеет степенное распределение (power law distribution), а не нормальное, откуда следует, что стоимость больших изменений перевешивает нормальные события -> cost(change) ~= cost(big changes)
-- А большие изменения обусловлены высоким coupling -> cost(big changes) ~= coupling
Так получается равенство Константайна: cost(software) ~= cost(change) ~= cost(big changes) ~= coupling или проще говоря

cost(software) ~= coupling

Поэтому все и хотят уменьшать coupling, но это требует компромиссов.
- Зацепление и его уменьшение (coupling versus decoupling) - автор начинает с того, что "зацепление часто остается незаметным, пока на него не наступишь - совсем как кубик Лего в темной комнате". Но как появляется зацепление - есть несколько вариантов
-- При реализации поведения мы выбрали путь с дополнительным зацеплением, учтя NPV решения (можно было сделать без него, но это было дольше и не ясно когда окупится)
-- Изначально оно не создавало проблем (мы изначально не планировали делать изменения, которые теперь внезапно появились перед нами)
-- Его было не избежать - в конце концов между нашими элементами системы должны быть отношения и взаимосвязи иначе это уже не система, а группа элементов:)
Дальше мы должны принять решение - платить дальше за зацепление или заплатить за его уменьшение. Если построить график, то видно, что оба экстремальных решения приведут к чрезмерным затратам и нам нужно выбрать что-то посередине (как обычно где именно посередине остановиться надо искать эмпирически).
- Связанность (cohesion) - здесь автор фактически говорит про кластеризацию элементов нашей системы. Условно сильносвязанные элементы должны попадать в свои кластера, а несвязанные элементы должны оказываться в разных кластерах. А вот coupling - это уже связи между этими кластерами.
- Заключение (conclusion) - в последней главе автор рассказывает о том, как принимать решение по очистке

-- Затраты. Снизит ли уборка затраты на более позднее время или сделает их менее вероятными?
-- Доход. Повысит ли уборка доход больше, быстрее или вероятнее?
-- Coupling. Приведет ли уборка к тому, что мне придется менять меньше элементов?
-- Cohesion. Сможет ли наведение порядка привести к тому, что элементы, которые мне нужно изменить, будут находиться в меньшем и более концентрированном объеме?

И напоследок он приводит сравнение очистки, рефакторинга и эволюции архитектуры, где меняется масштаб изменений, стейкхолдеры, причины и способы осуществления каждого из подходов. Плюс это только первая книга из серии, поэтому ждем следующую.

P.S.
В конце автор рекомендует кучу книг, из которых я читал всего несколько
- "A philosophy of software Design"
- "The Design of Everyday Things"

#Architecture #Software #SystemDesign #Management #Leadership #SoftwareArchitecture

MBA в картинках (The Visual MBA) - Part I

В отпуске я прочитал эту книгу с кучей картинок, где двухгодичный цикл обучения MBA упакован в 200 страниц картинок с небольшими примесями текста. И могу сказать, что формат подачи и сами иллюстрации в книге достаточно неплохие, но если вы не изучали эти темы отдельно, то такое краткое саммари не даст вам понимания ни в одной из тем - в книге 20 отдельных глав, где каждой уделяется 10 страниц. Но вот если вы были знакомы с темами заранее, то чтение этой книги позволяет вспомнить много из изученного. У меня как раз такой случай - я проходил разные вариации mini-MBA и MBA уже несколько раз и даже писал про них
- Про программу MBA INSEAD+Tinkoff и рекомендованная литература (моя версия)
- Блоки из mini MBA, что проходил до этого про лидерство и про мотивацию
- Блоки из новой программы MBA Tinkoff + Сколково, которую я посещал со вторым потоком, например, про организационное поведение

Если возвращаться к самой книге, то она состоит из 20 глав
1. Лидерство - здесь немного про бренд лидера и как производить впечатление, про автономность, мастерство и цель, которую надо давать своим последователям и про командную работу
2. Корпоративная финансовая отчетность - здесь речь про бухгалтерский учет (Активы = Обязательства + Собственный капитал), про отчеты о финансовых результатах, о движении денежных средств, прогнозный отчет. Также разбираются фин коэффициенты соотношение заемного капитала к собственному, коэффициент текущей ликвидности, рентабельность собственного капитала, норма чистой прибыли, а также модель Дюпона
3. Предпринимательский менеджмент - как искать идею для своего бизнеса (стоит идти от боли, которую мы хотим решить). Здесь приводится цепочка: сопереживание -> распознование -> идея -> прототип -> испытание.
4. Управленческий учет - базовый рассказ про постоянные и переменные издержки и ABC (activity-based costing)
5. Финансы предприятия - рассказ про цепочку капиталовложний: капитал -> активы -> товары -> продажи -> прибыль -> капитал. Дальше рассказ про дисконтированную стоимость денег и сложные проценты
6. Маркетинг - рассказ про сегментирование аудитории, позиционирование продукта и брендинг, а также про цепочку: свойство продукта -> преимущество продукта -> преимущество для покупателя -> личная ценность.
7. Операционный менеджмент - здесь рассказ про то, как организовывать процессы и основные моменты вида: время выполнения, выработка, время цикла, производительность, эффективность, узкое место. Про это можно глянуть книгу “Визуализируйте работу” (“Making Work Visible”)
8. Стратегическое управление персоналом - найм, мотивация и оценка результативности сотрудников (выше уже упоминал что можно почитать)
9. Деловые переговоры - здесь надо больше слушать, а не говорть, а также иметь альтернативный вариант для обсуждаемого соглашения. Рекомендую почитать "Большую книгу переговоров" для прокачки этих навыков (я уже вспоминал про нее)
10. Стратегия - здесь все начинается с модели 5 сил Портера, продолжается модель VRIO (Value,Rarity, Imitability (ease/difficulty to Imitate), Organization (ability to exploit the resource or capability)) и заканчивается концепциями алого и голубого океанов:) Рекомендую на тему стратегии почитать книгу "Теория игр. Искусство стратегического мышления в бизнесе и жизни" за авторством Авинаша Диксита и Барри Нейлбаффа. И еще материалов, что я рекомендовал раньше
11. Деловая этика - контролируйте эмоции + проверьте мысленно что будет, если про ваши действия расскажут в новостях ... а дальше действуйте в соответствии с этикой
12. Финансирование предпринимательской деятельности - рассказ про SWOT анализ, венчурные инвестиции, жизненный цикл компании

А про оставшиеся 8 глав я расскажу в следующем посте.

#Thinking #SelfDevelopment #Management #Leadership #MBA

MBA в картинках (The Visual MBA) - Part II

Продолжая первый пост про книгу, расскажу про оставшиеся 8 глав

13. Рассмотрение и принятие решений - рассказ алгоритм вида: проблема -> цели -> альтернативы -> последствия -> компромиссы. А дальше автор рекомендует использовать волшебный вопрос "зачем", смотреть на вопрос с разных точек зрения и знать про наши biases и две системы мышления 1 и 2 Канемана и Тверски. Подробнее про мышление и принятие решений можно почитать книги из моих подборок: на тему системного и критического мышления и на тему работы мозга
14. Роль генерального директора - про решение задач и устранение проблем в условиях неопределенности, про постановку задачек по SMART (specific, measurable, assignable, realistic, time-related), а также про change management (про это можно почитать простенькую книгу "Наш айсберг тает", про которую я писал раньше и по мотивам которой часто проводят игры на тему внедрения изменений)
15. Стратегическое мышление - такая себе глава, где говорится про консенсус в принятии коллективных решений, а рядом говоритс о том, что надо знать когда принять решения самому. Приводятся в пример разные исторические лидеры и дальше оценивается их стиль принятия стратегических решений по итоговому результату:) В общем, проявление эффекта ореола во всей красе. Рекомендую по поводу стратегического мышления прочитать книгу "Теория игр. Искусство стратегического мышления в бизнесе и жизни", а по поводу заблуждений менеджеров почитать книгу "The Halo Effect", про которую я уже рассказывал
16. Креативность и инновации - рассказ про дивергенцию и конвергенцию, про метод мозгового штурма, человека типа Т. Рекомендую на тему креативности в компаниях прочитать книгу про Pixar "Корпорация гениев" ("Creativity, Inc"), про которую я уже рассказывал
17. Основы стартап-маркетинга - рассказ о том, как придумать крутую идею продукта, как работать с фокус-группами (используя подход шести шляп мышления), как продавать эмоции от использования продукта, а не его свойства
18. Производительность и мотивация - здесь разбирается модель принципала и агента, которую я люблю использовать для размышлений, а также упоминается сбалансированная система показателей (balanced scorecard), которая была модной 20 лет назад вместе с концепцией реинжиниринга бизнес-процессов:)
19. Глобальный менеджмент - как выходить на глобальный рынок, учитывая все отличия: культурные, административные, географические, экономические
20. Собираем все воедино - в этой главе автор показывает как построить путь к своему бизнесу используя знания из предыдущих глав (условно перечисляет в каком порядке знакомится с этими главами)

#Thinking #SelfDevelopment #Management #Leadership #MBA