Andrei Kavaleu's blog

[Философское] Свободное время и НЕсвободное – порочная дихотомия (расщепление)

Sun, 31 Aug 2025 14:53:13 +0000

А теперь будет то, ради чего я расчехлил блог. Предупреждаю – будет очень нетипичный контент :)

Нас с самого детства приучают к мысли, что есть свободное время, когда мы можем делать все то, что хотим и есть обязанности, которые сначала нужно сделать, чтобы появилось то самое вожделенное “свободное время”. Вот это вот все “сделай уроки, потом будешь гулять”, “убери в комнате, потом пойдешь на улицу”, “в приставку можешь играть только в свободное время”, “закончи школу/университет, найди работу, а потом будешь поступать как считаешь нужным”, “заработай сначала на квартиру, а потом будешь жить как хочешь.”. Вплоть до “буду работать и откладывать, чтобы летом поехать на море” (внезапно). “Нужно заработать деньги на квартиру и машину, чтобы потом жениться”. “На работе меня выжимают нещадно, но ты бы видел мою зарплату” (привет консалтерам!). “Я сейчас работаю на дядю, чтобы сколотить начальный капитал и работать на себя” (да, да, конечно).

Не специально приучают, а потому что так учат давным-давно… наших мам, пап, бабушек, дедушек, … Это зашито в нашей культуре.

Создается впечатление (на глубинном, подсознательном уровне), что есть время когда мы являемся самими собой (и делаем что хотим), а есть время, когда, даже не знаю, отдаем долг, зарабатываем деньги, “копим ресурсы?”, … Чтобы потом начать жить.

Что есть свободное время

Лучше всего проблему можно проиллюстрировать на примере работы. Вы, скорее всего, знакомы с мыслью “на работе мы меняем свое время на деньги” – она не плоха, многое объясняет. Получается мы продаем свое “свободное время” работодателю, чтобы потом… что? Жить как мы хотим? А что мешало жить как хотим без продажи? ОК, скажем: жить более качественно – с айфонами, модными шмотками, машинами, вином, женщинами, поездками, впечатлениями (подставьте свое). Для которых нужны деньги.

Проблема проявляется не только на примере отпуска или же в работе “от звонка до звонка” (что я ненавижу и всячески стараюсь этому препятствовать). Например, понятие “пятницы” поднимает целый пласт ассоциаций. Мы друг друга поздравляем с пятницей (а люди косо смотрят когда я говорю, что рад понедельнику). А если “пятница-зарплатница” так вообще бинго.

А потом мы не знаем что делать в выходные (сколько можно уже пьянствовать и лежать на диване?). В отпуск мы чаще всего едем на море. Чтобы что? Чтобы было все включено и можно было лежать на пляже ничего не делая, так получается?

Как мы проводим свое свободное время? Насколько качественное оно? По каким критериям мы определяем его качество?

Для меня качественных выходные – выходные насыщенные событиями. Вот прямо сейчас у меня событий нет (жена и дочь пошли гулять, (пьянствовали) встречались с друзьями мы вчера…). Читать не хочется, учиться новому тоже. Кино? Разве что-то есть хорошее, что вот прямо стоит посмотреть из последнего. Работать тоже не хочется – планы понятны, их нужно реализовывать, а это общаться, договариваться, убеждаться – не то, что можно сделать в выходные.

В общем, меня сегодня вот эти 3-4 часа “свободного времени” скорее напрягают, чем радуют. Зато простимулировало писать.

Прогресс борется с несвободным временем человека, освобождая его для свободного

Все приспособления, изобретенные человеком помогают нам трудиться более эффективно. Более эффективно “накапливать ресурсы” для жизни. Наши предки 200 лет назад работали с 5-6 утра до глубокого вечера на своем хозяйстве. Да что говорить про 200 лет назад. Моя бабушка (по отцу) держала большое хозяйство и постоянно работала с весны до осени. Другая бабушка (по матери) уже была городская и работала на заводе – свободного времени у нее было больше, но забот по хозяйству (частный дом) у нее было тоже много. Моя мама уже жила в квартире – дрова колоть не нужно, воду носить, а потом греть не нужно, еду готовить можно на газу. Моей супруге со всеми стиральными машинами, доставками и роботами-пылесосами… вы можете продолжить сами.

Ок. Цепочку женщина-хозяйство завершили. Цепочку мужчина-“добыча мамонта (ресурсов)” вы построите сами. Но можете мне поверить, что в эффективности “добыче мамонта” я опережаю отца (главного инженера завода, на минуточку), он опережает своего (председателя колхоза, на вторую минуточку).

В общем, мы люди, получили в свое распоряжение так много свободного времени, что… начали его убивать. Вот эти вот все бесконечные сериалы, компьютерные игры (грешен), инстаграмм, тикток… Мы настолько не знаем что делать со свободным временем, что… скучаем и пробуем его заполнить хоть чем нибудь. Причем это все “скууучно!” было описано-переписано в классике сотни, если не тысячи лет назад. Правда тогда лишним свободным временем могли похвастаться только дворяне, аристократия и прочие люди на вершине пирамиды или “дурачки”.

Симбиоз Физиков и Лириков

Получается “Физики” как драйверы технического прогресса, освобождают для нас наше(!) свободное время, а вот что с ним делать и как использовать рассказывают нам “Лирики” – писатели, историки, социологи, психологи, и прочие философы.

У каждой культуры и каждого поколения свой способ ответа на вопрос “что делать со свободным временем”. Как примеры – аниме сообщества, сообщества реконструкторов, “танкистов”, байкеров, … В американской культуре – ответ в движении вперед и достижении высот. Отсюда огромное количество предпринимателей и стартаперов в США. В русской культуре – (возможно, будет смешно сейчас, но это правда – почитайте классиков, или современных русских философов) служение отечеству (не государству!) и/или смирение души. В этом истоки того, что у нас так много народу, которые ругают и рвутся во власть.

На этом остановлюсь – я, как “физик” (технарь), в этом не силен.. Лучше обратитесь к классикам или философам.

Технический прогресс не должен опережать общественный (прогресс общества)

Тут можно много обсуждать появление смартфонов (мы всегда на связи), интернета (на связи со всем миром), соцсетей (на связи с конкретными людьми и группами этого мира), ИИ (хз что тут, на самом деле… на связи с кем-то, кто заменит нам других людей?), … Но мы ведь про “свободное время” говорим, а не про гармоничное развитие цивилизации :)

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

Порочная дихотомия

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

Убиваем свое время. Сначала НЕсвободное (отсиживая от звонка до звонка), а потом свободное (на телек и пиво).

Причем НЕсвободное время очень даже свободное – в рамках ваших обязанностей вы принимаете решения что и как делать. Иначе как объяснить, что ваши подчиненные спорят с вами (а вы спорите с начальством). Не соглашаются, саботируют работу. Они же “продали” вам (или вашему работодателю) свое время, оно теперь ваше. А оказывается нет. Они вольны делать то, что считают правильно. Вплоть до увольнения. Причем продуктивность людей, которые вольно делают свою работу – в разы, если не на порядок, выше.

Так может наше НЕсвободное время не такое уж не-свободное?

Один из главных моих мотиваторов всегда был образ рабочего, которого я видел на конвейере в Гудьер, который днями отрезал от резиновой ленты кусок определенной ширины, поворачивал ее и клеил снова. Вот у него 100%-я НЕсвобода, ни грамма ни остается на принятие решения.

Может именно поэтому (эта мысль для меня новая, пришла прямо сейчас) этот образ всегда меня угнетал и мотивировал работать.

Что же с этим делать?

Жить. Это так как “работает наш мир” (мое текущее понимание) – вы либо понимаете как он работает и у вас есть возможность предсказуемо менять что-то в нем. Либо вы живете (меняете) его как придется и как получается.

Что же я вам (и себе) посоветую:

Попробовать не воспринимать свое не-свободное время, как чужое. Не как время когда мы не живем, ждем “конца смены”, а вот потом….
Учиться жить на(в) работе, увеличивая %% свободы – %% времени, когда вы вольны выбирать что и как делать.
Учиться жить в бытовых заботах – добровольно принимая на себя часть из них и отказываясь выполнять (автоматизируя или аутсорся) те, которые вы не можете принять.
А когда научимся – будем пробовать научиться качественно, с целью (у каждого она своя) проводить свое свободное время.

Главное понимать, что и в вольное, и в не-вольное время – это все мы. Это наша жизнь. Мы не живем от пятницы вечера, до понедельника утра, от отпуска до отпуска. Это все мы – в свободное и несвободное время. Помните “Найдите себе работу по душе, и вам ни дня не придется работать”? Вот оно. Тут же должна быть цитата про гармонию в доме :)

На этом все. Обсуждения, как обычно, в моем ТГ канале: https://t.me/akava_t/382

P.S. Ролик (внимание, 2 часа), который меня сподвигнул описать свои мысли и суждения: https://vkvideo.ru/video-231945006_456239066

Чем я занимался весь этот год 2024-2025

Sun, 31 Aug 2025 14:42:13 +0000

Смотрю целый год не писал в канал и блог. Но не потому, что нечем было поделиться – наоборот, жизнь бьет ключом. Настолько многим можно поделиться, что придется категоризировать :) Поехали.

Обучение и создание комьюнити.

1) Набрал и выпустил первый поток архитектурного курса дляBridge Lab (10 довольных клиентов). Полный цикл от рекламы, продажи, проведения курса, до вручения сертификатов и сбора отзывов (все положительные).

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

2) Это первые мои деньги, которые я заработал от начала до конца самостоятельно – от формирования продукта, до поиска аудитории, продажи его и поставки. И дал заработать другим, что тоже важно.

3) В планах сделать запуск курса с Иваном Подобедом по Системной Инженерии. И провести его до конца года. Так же есть мысли трансформировать комьюнити архитекторов в IT комьюнити подключив другие IT компетенции. Есть бодрые ребята, которые готовы делиться своими знаниями и компетенциями. Так же есть запрос на перевод архитектурного курса на английский. Его я пока придерживаю потому как нету драйвера (ответственного) за регион, а я один его не потяну.

Специализация.

4) Завершает кристаллизацию моя специализация. Не уверен, что писал про проблему эксперта-генералиста и необходимость выбора специализации. Но об этом я думаю уже лет 5. С тех пор как съездил в США и понял, что всем интересно какие конкретно проблемы ты можешь решать. А я могу решать все связанное с технологиями и IT организацией (с примерами и подтверждением). Но этого мало – мозг потенциально заказчика пасует и предпочитает не связываться.

Теперь же четко понимаю чем хочу заниматься, почему именно этим и какие перспективы.

5) Специализация напрямую связана с моей любимой (естественной?) фазой организации – Growth/Scale. Специализация заключается в построении процессов интеграции (всего со всем) – начну с технической, продолжу интеграцией компетенций, продуктов, партнеров и далее экосистем, платформ, отраслей… насколько хватит жизни. Системная инженерия научила не только думать масштабно, но дает ответы на вопрос как этот масштаб реализовать.

6) Удивительно, но эти планы я описал в статье Роль DevOps в изменении организации. Или рост DevOps (менеджера) в CTO (директора по развитию). Только тогда я считал, что это роль DevOps, как клея. Но сейчас я понимаю, что DevOps – только часть мозаики. А больший пазл называется Integration (систем, продуктов, отделов, компетенций, …). В общем, в статье выше можно практически без потери смысла заменить DevOps (менеджер) на Integration Head (название не цепляет, да, но пока другого нет) и понять мои планы.

7) У меня есть крупный клиент, которому нужно вот это вот все из статьи в пункте 6. Прямо прописано в стратегии на 2026-2028. Чтобы добиться этого мне самому нужно менять не только компанию клиента, но и налаживать связи в моей компании (та же интеграция). В общем, пока все сходится.

Понимание окружающего мира.

8) Благодаря СВО и всему тому, что сейчас происходит в мире (вот уж реально – не было бы счастья, да несчастье помогло) прямо сейчас происходит внутренняя трансформация меня как личности, так и моего понимания “как работает этот мир”. Ошметки этого процесса просачиваются в канал @AkavaT_thought_stream. Сегодня, например, был (и будет) особенно сильная трилогия Мараховского про происходящее в соседнем государстве (но в первую очередь, про то как работает мир: про радикализм, экстримизм, зачем и, главное, кому он нужен и как к нему относиться). В общем ответов становится больше. И это радует.

Эти знания шикарно помогают договариваться как на работе, так в жизни.

9) Это все происходит совсем не потому, что “война открывает мне глаза” – нет. Происходят вещи, кардинально выбивающиеся из моего понимания. Что стимулирует меня разбираться, читать, слушать… те источники, которые я бы никогда не читал и не слушал ранее. Как, например, философия, история, социология, …

ИИ и все-все-все

10) ИИ – отличный инструмент. Его боятся. Но на данный момент развития бояться нужно не “ИИ, который заберет твою работу”, а “другого человека с ИИ, который заберет твою работу”.

Так что пользуемся ЧатГПТ и проч., разбираемся как все работает на уровне принципов (что могут ЛЛМ, а что нет), не вкладываемся сильно в понимание текущих особенностей ЛЛМ (они прогрессируют быстрее, чем мы учимся)… В общем становимся тем самым “другим человеком с ИИ, который заберет у других работу”.

11) Мы, человечество, однозначно проходим через революцию коммуникации и отношений между людьми. Впервые в нашей истории “с той стороны коммуникации” появился не человек (ведь даже при чтении книги и просмотре фильма, с той стороны выступал автор, сценарист, режиссер, т.е. человек). Это все ставит перед человечеством вызовы, которых не было. Войны были, технический прогресс был, подъемы и упадки народов/империй/культур были, но с той стороны всегда был человек или группа людей.

12) Сегодняшний пост меня “вынудило” написать желание опубликовать мысли по прослушиванию одной философской дискуссии о… ИИ. Людей, которых я не слушал уже где-то год. И в этом 2х-часовом видео было столько “мыслей которых захотелось записать, обдумать и обсудить”, что “пришлось” писать вот это вот все, чтобы не возникало мыслей у вас, читателей (и меня, из будущего), что сообщение появилось внезапно из ниоткуда.

Обсуждения, как обычно в моем ТГ канале: https://t.me/akava_t/378

7 стадий стартапа. Взгляд архитектора

Sun, 02 Jun 2024 16:11:13 +0000

Грамотная статья, классифицирующая стадии жизненного цикла компании. Начиная с идеи (основание стартапа) до поиска Product-Market-Fit (через MVP и поиск инвестора для экспериментов), далее идет выход на рынок и рост (growth/scale), после чего идет этап зрелости и оптимизации (Maturity).

Сразу же захотелось наложить эту классификацию на модель из Digital Practitioner. Уж очень стадии близки и ровно ложатся друг на друга: Team of teams – однозначно стадия роста, Enterprise – стадия зрелости и оптимизации.

А еще на модель из книги Crossing the Chasm. Product-Market-Fit – как раз этап преодоления пропасти.

Ок, это все про мысли и будущее публикации. Давайте поговорим про модель из статьи и про роль архитектора на каждом из этапов. Поехали!

Этапы жизненного цикла

Начнем с модели предложенной в статье. Если вы с ней знакомы, то можно пропустить эту секцию без потери смысла.

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

Поиск идеи (Ideation)
- Вы нашли сообщество с проблемой, для которой нет удовлетворительного решения;
- Вы подтвердили, что достаточно людей готовы платить за решение этой проблемы (потенциал рынка);
- Вы сформулировали гипотезу решения этой проблемы.
MVP
- Вы создали минимально жизнеспособный продукт, с самой базовой версией ключевой функции, которую вы предлагаете;
- Вы протестировали ценностное предложение и каналы вашего MVP, собрав отзывы от потенциальных клиентов и изучив их;
- Вы решили, нужно ли доработать минимально жизнеспособный продукт или переключиться на новый MVP.
Поиск инвестиций (Investment)
- Вы подготовили свой стартап к получению инвестиций правильным образом;
- Вы проверили, на каком этапе финансирования вам следует сосредоточиться в данный момент;
- Вы изучили лучших инвесторов для вашего бизнеса, подготовили свою презентацию и начали развивать отношения с ними.
Product-market fit
- Вы находитесь на хорошем рынке с продуктом, который удовлетворяет этот рынок;
- Вы наблюдаете устойчивый и предсказуемый рост пользователей и доходов;
- Вы видите хорошие показатели удержания клиентов.
Выход на рынок (Go-to-market)
- Вы нашли маркетинговые, сбытовые, ценовые стратегии и стратегии удержания клиентов, которые сохраняют ваши CАС и LTV на здоровом уровне;
- Эти стратегии не легко скопировать конкурентам, так как вы создали вокруг них защитные барьеры;
- У вас есть повторяемая, масштабируемая и прибыльная модель генерации доходов.
Рост (Growth/Scale)
- Вы достигли соответствия продукта рынку, выхода на рынок и прибыли;
- Вы наблюдали устойчивый рост на протяжении длительного периода времени;
- Вы нашли успешные стратегии для поддержания этого роста, такие как приобретение других компаний или выход на новые рынки.
Зрелость (Maturity)
- Вы красавчик. Радуйтесь жизни
- Оптимизируйте продукт или же:
  - переходите к пункту 4 (с другим продуктом);
  - или п5 (с другим маркетом);
  - или п1 (с другой идеей).

Применение к архитектуре и архитекторам

Теперь, когда мы знакомы со стадиями стартапов, поговорим о ключевых аспектах и роли архитектора в каждой из них.

Ideation – Investment

Слоган: некогда думать – трясти нужно.

Первые стадии. Тут важны коммуникации, исследование вашей аудитории, работа с инвесторами.

С точки зрения технологий важно умение быстро “на коленке” слепить прототип, потом MVP, чтобы показывать демонстрации как пользователям, так и инвесторам.

Архитектор на данном этапе не нужен – достаточно адекватного Тим Лида в роли CTO. Не мешать разработчикам “творить” и умение собрать демо-стенд для “звонка инвесторам через полчаса” – ключевые требования.

Product-Market-Fit

Слоган: добыли карту сокровищ – давайте искать клад.

Вы уже понимаете проблему, которую решаете. Но не до конца понимаете как ее решить и за что готовы платить пользователи. У вас есть небольшая команда и деньги, чтобы сделать продукт для вашей целевой аудитории.

На данном этапе важна гибкость и умение быстро ставить эксперименты. Т.е. архитектура должна поддерживать эксперименты. Так же она не должна ограничивать – иначе ее “выкинут”. Необходимо уметь считать метрики – чтобы понять успешность экспериментов. Для этого нужно уметь интегрироваться с системами сбора и анализа данных.

С точки зрения разработки происходит развитие dev-excellence процессов (continuous delivery, configuration management (как умение версионировать и мигрировать схему данных), DevOps, …). Если об этом не позаботились на предыдущих этапах.

Go-to-Market

Слоган: вроде клад нашли – давайте его выкопаем.

У вас есть решение, есть пользователи которые хотят это решение – нужно им его дать.

На этом этапе происходит наведение порядка, адаптация продукта к рынку. Т.е. усложнение продукта, увеличение количества фич. Проработка их вглубь, причесывание UI/UX. Пользователи уже не Early Adopters, они более серьезно относятся к качеству и визуальной привлекательности продукта. Плюс увеличивается вариативность – поддержка разных способов оплаты, интеграция с популярными мессенджерами, заточка под разные платформы, …

Для архитектора на этом этапе 2 фокуса:

Вклад в надежность и доступность – в качество сервиса. Появляются интеграции с системами мониторинга, краш аналитики, …
А так же в вариативность – выделение “commodity” сервисов в платформу с целью подключить еще 10 способов оплаты, еще 3 интеграции со стандартными решениями на рынке, android, iOS, Web, Desktop, …

Growth

Слоган: быстрее, выше, сильнее.

Пользователи довольны качеством решения их проблемы. Советуют продукт другим. Вы “преодолели пропасть” – вам легко привлекать новых клиентов. Есть что показать инвесторам.

Продукт понятен, рынок его принимает, соответственно есть деньги. Начинается экспансия. Экспансия всегда сопровождается ростом персонала, а люди, когда их больше 10 уже мешают друг другу. А уж когда их 50+, то тем более.

Начинает играть первую скрипку организационная архитектура (у нас ведь 50+ человек и будет больше), выделение платформенного слоя (чтобы не делать по 100 раз одно и то же), независимое масштабирование разных каналов поставки “пользы” (value) и этапов Value Stream основного продукта. Complience (не знаю хорошего перевода этого термина) становится важным (еще не является ключевым аспектом, но уже сильно рядом). Team Topologies – наше все (Stream aligned teams появляются из Value Stream).

От архитектора нужно:

бежать впереди и убирать с пути все лишнее – лишние коммуникации (правильно разбив команды и продукты), лишнюю работу (выделив общие вещи в платформу).
смотреть чтобы все бежали примерно одинаково (но каждый в свою сторону) – governance и compliance.

Т.е. это про работу Chief Architect-a (70% – Enterprise Architect и 30% – Solution Architect).

Maturity

Слоган: бег на месте, общеукрепляющий.

Расти уже некуда – сохраняем статус-кво и сокращаем издержки. Бежать уже никуда не нужно. Бизнес понятен, пользователи понятны. Сохранить бы это все и, желательно, показывать динамику (позитивную).

(Хорошо если ваша компания смогла опять выбить себя в Growth стадию – новый маркет: география, сегменты аудитории, новый продукт/линейка продуктов, расширение текущего продукта, выстраивание экосистемы из продуктов. Тогда возможен Continious Growth – мечта инвестора.)

Тут нужны:

большие платформы и продукты (желательно коробочные);
серьезный гаверненс (а не как раньше). Т.е. разные борды умных “дядек” для наведения порядка;
жесткая рука “бухгалтера/счетовода” – надо ведь сокращать;
так же нужно держать руку на пульсе и не пропустить “the next big thing”. Как интернет, или мобилки, или Big Data & Realtime Analytics, blockchain (нет), или GenAI (да?);
не пропустить “the current thing”. Во-время перейти на Java с Power Builder, с SOAP на REST, с Cobol/Fortran на… ой, ничего адекватного не придумали (Java, к сожалению, не ответ).
cкупать и/или убивать конкурентов – да, это не про архитектуру.

ИМХО, архитектор на данном этапе нужен чтобы:

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

Каждому этапу свой архитектор

Видно, что на каждом из этапов разные вызовы для архитектора. Соответственно нужны разные таланты, знания и навыки.

Если на первых стадиях важна скорость и гибкость. То для стадии Go-To-Market важно умение строить надежные решения и внедрять вариативность. На стадии роста необходимы организаторские способности и умение увидеть “Big Picture”. Во время стадии Maturity нужен хороший администратор (т.е. 100% Enterprise Architect здорового человека).

Все это очень хорошо ложиться на модель роста (зрелости) архитектора о которой я рассказывал на митапе Hard&Soft Skills.

Какой я архитектор

Мне лучше всего подходят компании роста (growth/scale). Я там чувствую себя лучше всего. Продукт понятен, рынок его принимает, соответственно есть деньги. Но задор в глазах еще горит и есть желание “замутить еще”. Идет мощная экспансия на соседние рынки и бизнес вкладываются в линейку продуктов и соседние ниши. Есть поле как для экспериментов, так и для “посидеть-подумать”.

Моя текущая компания, в основном, работает с компаниями этапа Maturity (этапа Зрелости). Я не люблю работать в таких компаниях (ничего против не имею, но не люблю) – уж очень часто на первое место выступает корпоративная политика и вместо полезной и нужной работы мы делаем то, что было “продано” руководителем (своему руководителю). Поэтому я всегда стараюсь выйти на уровень выше или, хотя бы, понимать что там происходит.

Кроме того у меня, как инженера, всегда ощущение, что “пациент” уж слишком запустил себя. Причем большинство проблем он создал себе сам и их можно было избежать просто (что совсем не просто) следуя индустриальным лучшим практикам (best practices) пару лет назад. Да, тупо, следовал бы лучшим практикам. Причем не обязательно брать что-то образца 24го или даже 19го года. Возьмите Digital Practitioner – посмотрите что вам нужно на этапе Team of Teams и при переходе к этапу Enterprise и возьмите оттуда ТОЛЬКО здравый смысл.

(Это как делать зарядку по утрам и смотреть что мы “суем в рот” (я про еду) – сильно помогает в самочувствии. Особенно по сравнению с теми кто сидит днями в кресле или диване, а вечером поедает чипсы с пивом.)

Заключение. Какой вы архитектор?

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

Соответственно идти в компанию, которая не подходит вам, ради зарплаты или высокой должности, скажем, неполезно. Обращайте на это внимание или, как минимум, планируйте как будете прикрывать свои слабые стороны в новом окружении.

Какой вы архитектор? Читая про какой этап у вас было наибольшее количество “флэшбэков”? Расскажите об этом в обсуждении: https://t.me/akava_t/360.

P.S. Еще про этап Maturity. Несмотря на то что уже все понятно, никто не выделит бюджет под “переписывание всего, в этот раз правильно”. Хоть вы и сможете убедить всех, что “при правильной архитектуре” издержки будут кратно ниже. Но такое говорят раз в 5-10 лет в этой компании, но никто не знает как “это вот все” вместе работает (вспомните мем про голупя) – поэтому ничего масштабного вам не удастся протащить. Если же удастся – надеюсь вас не погребет под этим масштабом. В одной из моих компаний-клиентов до сих гуляет байка про прошлую попытку переписывания, стоящее компании 160 мультов за 2 года (снимаю шляпу перед менеджером, я в восхищении!, – освоить 80М в год! Мои “комплименты”).

Личностный рост и карьера

Sun, 04 Jun 2023 14:20:00 +0000

Человек меняет сферу деятельности. Это дается непросто, первые годы приходится очень много работать, поднимать большие пласты знаний и навыков, конкурировать со вчерашними студентами, у которых сил и энергии больше (а так же практически нет забот вне работы). Но, проходит время, человек разбирается в новой профессии, берет все более сложные задачи. И карьера внезапно взлетает в космос – вчерашние студенты остаются далеко позади, он проскакивает этап Сеньера, за пол года становится Тим Лидом и главой подразделения в 10+ человек, а через 2 года ему предлагают возглавить региональный офис на 150 человек, который он выводит из стагнации в стабильный и устойчивый рост (привет, Леша, не факт, что ты прочитаешь этот пост, но я все равно рад твоему успеху).

Вы, наверное, знаете примеры таких людей. Возможно не такие впечатляющие, но в IT таких много. Когда успешные в своей профессии люди заходят в IT и, после достаточно тяжелого периода работы, достигают успехов. Успехов, которые, как минимум, соответствуют их уровню в предыдущей профессии (при существенно более высокой зарплате), но чаще всего двигаются дальше и выше. Мой знакомый, из примера выше, раньше заведовал кафедрой в ВУЗе (это уровень начальника отдела), а сейчас работает на уровне ректора филиала или, возможно, декана факультета.

Как так происходит, что определяет успех нашей карьеры?

Hard skills – это еще не все

Очевидно, что суть в soft skills. Как только мы переходим из одной области человеческой деятельности в другую, нам приходится поднимать целый пласт знаний и навыков этой области (все это сейчас называется одним термином Hard Skills). Именно с приобретением таких навыков связана просадка в первое время, когда нам нужно конкурировать со вчерашними студентами.

Но как только hard skills подняты на нужный уровень – успех, карьера и, конечно же, зарплата взлетают вверх ракетой до пределов определяемых конкретной компанией. Компанией и тех soft skills, которые уже стали частью нашей личности за время нашей жизни.

Про разницу между soft и hard skills отлично написал vas3k. Статья отличная, разница показана на отличных примерах, отличное определение (“Софт скиллы — это всё, что не хард скиллы, но всё еще нужно на работе, чтобы [все] вокруг двигалось вперёд”). Но 1) не совсем понятно что с этим всем делать, 2) не отвечает на вопрос как же бывшие ВОЙТИшники за пару лет достигают высот, которых не достигают классические IT специалисты за десять лет?

Дело однозначно в soft skills, но каких конкретно? И как быть с тем, что софт скилы отличаются от профессии к профессии? На что обращать внимание? Связано ли это с личностным ростом?

Гипотеза – успех в карьере быстро развивается, достигая уровня развития личности

Ок. Развитие личности, круто! Чем это лучше понятия soft skills, как можно количественно и, главное, качественно измерить уровень развития личности? Непростой вопрос.

Мне нравится идеи Джордана Петерсона, что личность измеряется в уровне ответственности, которую эта личность готова взять на себя. Согласно Петерсону мы, люди, изначально живем в хаосе, который постепенно преобразовываем в порядок вокруг себя. Представьте “круги хаоса” вокруг нас – сначала мы разбираемся с беспорядком в своей комнате, потом в личных делах, в доме, среди друзей и родных, в коллективе и комьюнити, в городе и его обществе, народе, стране и государстве.

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

Уровень развития личности измеряется уровнем ответственности, которую эта личность готова на себя взять

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

Ответственность за себя и свои поступки сейчас, в моменте – мы приходим вовремя на работу (забудем на время удаленку и гибкий график, которые требуют еще большей ответственности), во время работы мы преимущественно работаем, а не имитируем бурную деятельность, выполняем свои обещания.
Ответственность за за себя и свои поступки на отрезке времени – можем делать все что выше достаточно долго и предсказуемо. Несмотря на проблемы и сложности, с которыми мы сталкиваемся (возможно это мое личное когнитивное искажение, но мне кажется правильным выделить этот этап отдельно).
Ответственность за людей вокруг себя (команду) и работу команды в моменте – умение работать с людьми и прикрывать сложности и просадки в их работе. Находить исполнителей, которые сделают работу, если член команды не придет на работу, заболеет, загуляет, уволится. В том числе становиться самостоятельно “у станка”, если не смог никого найти.
Ответственность за команду на отрезке времени – члены команды ходят на работу и даже готовы (иногда) подменять других и помогать тебе, но готовы ли они жить в таком режиме постоянно? Как сделать их работу более предсказуемой несмотря на все неопределенности? Этот этап про понимание компетенций, необходимых команде, налаживание процессов и поддержание (минимального, но достаточного) качества работы.
Ответственность за будущее команды и работы, которую она делает – умение планировать и думать наперед, умение держать “нос по ветру” и быть готовым к изменениям во внешнем мире, чтобы у твоих людей всегда была работа (и зарплата) и уверенность в завтрашнем дне. По сути, умение прогнозировать и нести ответственность за свои прогнозы, когда будущее не соответствует им.
Ответственность за будущее команды и работы, которую она делает на долгом отрезке времени – тут мы говорим про годы и пятилетки. Про стратегирование, а не планирование.

Замечание 1. В уровнях ответственности выше есть как минимум 2 составляющие, которые можно расширять: 1) размер группы людей, за которых мы ответственны: сам человек, команда, коллектив, …, 2) временной отрезок этой ответственности: сейчас, месяцы, годы, …, столетия. Стратегирование на десятки лет – огромное бремя ответственности, но нам тут помогает как общество, так и государство, в которых мы живем, делая ошибки на этом уровне не фатальными, как это было даже 500 лет назад.

В это “уравнение”, для полноты, хочется добавить еще один параметр – зону ответственности группы человек. Работы, которые выполняет такая группа, а так же компетенции необходимые для этого. Компетенции – это про hard skills, а не soft, но их однозначно не хватает для получения устойчивой модели.

Замечание 2. На самом деле есть до первого уровня есть много дополнительных уровней и этот уровень далеко не базовый, но у меня блог не по психологии и личностному росту. Надеюсь, что люди, которые меня читают уже умеют нести ответственность за себя и свои поступки.

Уровень личности – уровень ответственности, которую она готова брать за себя, людей вокруг и совместное будущее

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

Это уже довольно высокий уровень ответственности и неудивительно, что при наличии способностей (способностей освоить hard skills) он смог добраться до уровня ему соответствующего и, не остановившись на достигнутом, двигаться дальше по карьере.

Застряли, не знаете, что делать дальше? Берите на себя больше ответственности

Поэтому мой совет всем тем кто “застрял” – берите на себя больше ответственности. Пробуйте разобраться с ней и стать ключевым работником на вашем уровне. Умеете делать хорошо и предсказуемо свою работу?

У вас 3 варианта:

пробуйте отвечать за людей,
организовывайте их работу (делая ее более предсказуемой)
и думайте о будущем, его рисках и возможностях.

Ставьте гипотезы и несите за них ответственность. Это не останется незаметным.

Рядом со мной живет еще один яркий пример человека, который уже дважды сменил профессию и за короткий срок достиг (в обоих) больших успехов – потому, что не боялась брать на себя ответственность не только за себя, но и за других, и за общее дело.

Взяли на себя ответственность, а результата не видно? Ищите новое место, где ваши личностные навыки необходимы.

P.S. Не уверен, что связь личности и ответственности я почерпнул именно от Петерсона. Но он явно был катализатором этой мысли. Его основная идея как раз про взятие на себя ответственности.

Обсуждение: https://t.me/akava_t/267

Нашел очень интересную замену Integromat: https://n8n.io/

Sun, 15 Jan 2023 07:03:00 +0000

Давно искал low-code решение для “домашней” автоматизации, что-то похожее на Integromat: автоматизация от которой не тошнит как от IFTTT, но не такое жадное до денег, из-за чего приходится считать количество шагов в процессе и количество обработанных данных, что нивелирует всю пользу от него.

Мне вообще нужно что-то похожее на AWS lambda+step functions для дома, а не для работы. Чтобы был low-code с минимумом обслуживания: как создания, так и конфигурации и поддержкой, и возможность сделать дашборд, чтобы смотреть что не так. Т.е. минимум гемороя (и программирования) и максимум пользы.

Пробовал AWS lambda (always-free хватает за глаза) – не зашло и не прижилось. Все равно сильно low-level для low-code ( :) ). Хоть аккаунт есть и могу делать лямбда функции, если упрусь в ограничения low-code платформ.

Но обо всем по порядку.

Low-code в [моей] жизни

У меня есть несколько телеграмм ботов на Integromate (Make) (из них, самый используемый – бот закидывающий книги в kindle), а так же домашняя бухгалтерия на IFTTT и Airtable. И количество интеграций растет по мере роста “хотелок”. Причем в полный рост столкнулся с последствиями философской максимы “бытие определяет сознание” – наличие удобных инструментов определяет что и как я не просто автоматизирую, а думаю, что это что-то можно переложить на “железного помощника”.

Вообще, тема low-code для автоматизации простых и рутинных операций очень жирная. Отправной точкой, как часто у меня бывает, стал vas3k (инноватор, по классификации crossing the chasm, во многих интересных мне областях; я же, соответственно, early adopter) со статьей: https://vas3k.ru/blog/nocode/. Статья хороша тем, что не только затрагивает тему, но и показывает несколько шикарных примеров автоматизации от домашних дел, до небольшого бизнеса. Рекомендую.

Что меня в “техно-зоопарке” сейчас:

IFTTT – хорош большим количеством интеграций (коннекторов к разным системам), но у него вырвиглазный интерфейс, т.е. что-то более-менее сложное в нем сделать нереально. Еще из плюсов – он практически бесплатный.
Airtable – шикарный табличный процессор-переросток с огромным количеством визуализаций, включая календари и канбаны, т.е. на нем можно сделать систему управления проектами а-ля Jira/Trello. Говорят его можно превратить даже в CRM и я этому верю, функционала там достаточно. Есть свои возможности для автоматизации, можно даже программировать на JS (так у меня сделан парсинг sms для домашней бухгалтерии). Относительно дешев и стоит своих денег. Он так же умеет создавать формы-опросники (так и получается CRM), но я не использую этот функционал.
Integromat (сейчас Make) – low-code автоматизация процессов как она должна быть. У которого множество коннекторов, low-code интерфейс, от которого не тошнит, хорошие логирование и трейсинг и отличный визуальный дебагер чтобы понять что пошло не так. Минусы – очень быстро упираешься в ограничения бесплатной версии. И даже платная не сильно помогает, если честно – такое же ограничение количества операций (шагов) в месяц.

Так вот, если Airtable меня более чем устраивает, то Integromat – нет. С IFTTT я мирюсь.

Как я это все использую:

Airtable – центральная база-хранилице данных-процессов, с возможностью исторического анализа. Т.е. база данных и BI-инструмент одновременно.
Integromat (сейчас Make) – автоматизация цепочек процессов (workflows). В первую очередь интеграция с телеграммом – большинство процессов у меня либо начинаются в телеграмме, либо в нем заканчиваются.
IFTTT – все для чего у Integromat нету коннекторов. Таких как чтение SMS и интеграция с iRobot. Хотел бы от него избавиться, но не могу.

https://n8n.io/

Выглядит очень похоже на интегромат и имеет из коробки все нужные мне интеграции (в первую очередь телеграмм).

Интерфейс (судя по видео) очень приятный, множество интеграций и возможности посмотреть что же пошло не так.

Несколько скриншотов с сайта разработчика:

Чем лучше того же интегромата?

Во-первых опенсорс и имеет community лицензию на self-hosted ноды, т.е все крутиться у меня локально, а платформа не пропадет и не превратиться во что-то другое (как Integromat -> Make).
Во-вторых умеет в git-ops через cli. Т.е. можно настроить хранение конфигурации в гите, а не “на сервере дяди” и восстановить все в случае чего.
В третьих есть недорогая SaaS опция в случае если запросы еще вырастут и не захочется заморачиваться доступностью self-hosted машинки.

Переведу своих телеграмм ботов на него – посмотрю как это все будет работать. Может даже ChatGPT переведу в телеграмм, openai API куплен уже давно.

Stay tuned!

Обсуждение: https://t.me/akava_t/256

Architecture for Flow with Wardley Mapping, DDD, and Team Topologies

Tue, 20 Dec 2022 06:53:00 +0000

Знакомые поделились интересной презентацией Architecture for Flow with Wardley Mapping, DDD, and Team Topologies (так же есть книга с похожим названием).

В презентации собрано достаточно большое количество базвордов последних лет, поэтому первоначальная реакция была резко негативная: “взяли горячие темы последних лет и объединили вместе. Успех обеспечен”. Но базворды яркие поэтому все же скачал презентацию и пробежался по ней. В принципе, все как я и ожидал, ничего нового. Поэтому отложил презентацию и занимался своими делами в пол глаза просматривая вялую дискуссию по теме.

А вот сегодня утром проснулся с ясной мыслью, что мы на проекте можем с помощью техник Wardley Mapping разложить наши DDD домены горизонтально в соответствии с их зрелостью (важно: зрелость не только внутри организации, а в индустрии) и вертикально по мере удаления от клиентов и value stream. Нам при общении с Продуктами (PM/POs) очень не хватает такого инструмента. То, что мы предлагали (Engineering Team) не встретило нужного энтузиазма. А вот Werdley Mapping достаточно прост, что его мы можем легко объяснить (вместе с benefits), так и в крайнем случае можем поддерживать его самостоятельно.

В общем, буду пробовать. А так же сегодня другими глазами просмотрел презентацию и нашел достаточно много других интересных мыслей. Например то, что Wardley Mapping можно использовать для принятия решения Build vs Buy. И многое другое. Поэтому рекомендую.

Сама презентация.

Сложности при выборе целевой системы

Sat, 17 Dec 2022 13:54:00 +0000

Продолжаем разбираться с Системным Мышлением и Системной Инженерией. Причем, что важно, не только в теории, но и на практике. В том числе в составе рабочей группы, где мы разбираем на части компьютерную игру Pirate Raid.

В самом начале, когда мы выбирали какую систему взять за целевую (что же мы будем конструировать) проскакивала мысль, что очень важно выбрать то, что мы можем “заземлить”, перевести в физическую реальность. А если совсем просто, то выбрать то, что мы можем измерять.

Изначально я не придал этому значения. Мол да, естественная мысль. Можем измерить – можем попробовать влиять, изменять и в итоге управлять, конструировать целевую систему. Нет – можем только гадать и “стрелять в темноте” не понимая достигли ли мы цели.

Сейчас, после опыта полученного во время участия в рабочей группе я четко понимаю, что выбор целевой системы еще сложнее, чем я думал. Ее мало найти (что тоже непросто). Ее нужно еще научиться уметь измерять и оценивать. А потом, когда найдешь, то можно обнаружить несколько кандидатов в целевые системы с разной степенью “измеримости”.

Игра, как система

Не буду расписывать подробно, опишу тезисно. Игра, как система состоит из следующих частей:

Игровой процесс – процесс непосредственно связанный с игрой в Pirate Raid конкретного игрока на конкретном телефоне. Причем мы разделяем сам процесс (логически) состоящий из череды сессий “включения/выключения в игру”.
Игровой опыт – образы и эмоции, которые появляются в голове игрока в тот момент, когда он играет в игру. Эмоции могут быть как простые: страх, желание, раздражение, воодушевление. Так и сложное: азарт, увлеченность, эстетическое удовольствие, ненависть.
Игровое поведение – решения игрока, которые он принимает во время игрового процесса.

Мы достаточно быстро решили, что Игровой процесс будет у нас системой создания для игрового опыта. Т.е. игровой опыт – целевая система. Игровое поведение, как производная – было нам малоинтересно. Им мы практически не занимались.

Конструирование Игрового опыта через Игровой процесс

Представлю черновик V-модели конструирования игрового опыта.

Декомпозиция создания игрового опыта, создание описания (спуск по левой части V-модели):

Спуск начинается с “образа [желанного] будущего (в голове игрока)”, через описание шагов достижения этого будущего, еще ниже к описанию препятствий, стоящих на пути игрока. Конструирование опыта и эмоций, через воплощение описаний в игре и голове игрока (подъем по правой части V-модели):
Cбор препятствий из описания механик (игрой), с постепенным выполнение шагов достижения (совместно игроком и игрой) и “совпадение (или нет) образа будущего с реальностью”, которое порождает эмоции.

Важно: это нормально если написанное выше непонятно, все же я описываю тезисно. Я планирую выходить на защиту в ШСМ и, как результат, написать статью и выложить подробную презентацию.

Получилось складно. Действительно, с помощью такой модели Гейм Дизайнер может конструировать опыт и эмоции игрока. Вопрос теперь как его мерять.

Как измерять опыт и эмоции игрока?

Если мы не сможем измерять опыт и эмоции, то как же мы убедимся, что мы сконструировали именно то, что планировали? Как подтвердить или опровергнуть гипотезы, которые ставит Гейм Дизайнер?

Как измерить опыт и эмоции игрока, если они в голове. Учитывая, что ЭЭГ мы к каждому игроку не подключим (да даже к фокус группе не подключить),. Спрашивать игроков (и прерывать игровой процесс?) – нарываться на пофигизм и несерьезное отношение, усталость, жульничество, сокрытие информации.

Да, есть приемы, которые позволяют с этим более-менее справиться. Но это все равно не то. Не говоря уже о том, что спрашивать о сложных эмоциях бесполезно – люди под радостью или гневом будут понимать разные вещи. Т.е. опросник будет состоять из косвенных вопросов.

Игровое поведение (и игровые решения), как система, которую проще измерять

Вот игровое поведение измерять намного намного проще. Оно логируется игрой, как решения пользователя.

Это могут быть как простые, так и сложные решения: (по мере усложнения) повернуть направо или налево; исследовать мир или сражаться, выйти из боя или продолжать; взять задание или продолжить free-play; выполнить его (даже если это не просто) или же выйти из него и улучшить корабль; купить что-то за реальные деньги или продолжать смотреть рекламу за плюшки или же принципиально развиваться естественным образом; выйти из игры или остаться; удалить игру или оставить ее и продолжить играть.

Каждое из таких решений – событие, которые подлежит анализу. Куда уж проще-то?

Мир, как обычно, не черный и белый. А состоит из оттенков сергого.

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

И перед командой возникает выбор: конструировать то, что проще измерять, но сложнее конструировать или же наоборот то, что сложнее измерить, но проще конструировать. Не просто.

Мой ответ: выбирать то, во что верит команда, даже если я, как руководитель выбираю другой вариант. Вне зависимости от выбора на пути ей встретятся сложности и проблемы, и как раз вера в свою правоту – это то, что поможет команде двигаться дальше и не сдаться на пол пути.

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

Игровой опыт, как целевая система

Меня же полностью устраивает Игровой опыт, как целевая система. Я верю в этот подход.

Я могу думать о том как ставить о нем гипотезы, как подходить к его измерению. Пусть несовершенные, но всегда можно улучшать инструменты измерения.

Например: использовать (с согласия пользователей) распознавание лиц и эмоций и сопоставление их с игровым процессом (система создания) и игровым поведением (где-то выше, в надсистеме). Технически это тот же телефон, который одновременно записывает и экран, и фронтальную камеру, и действия игрока. На сервере все обрабатывается в результат: эмоции с привязкой к системе создания (выполнению задания) и игровому поведению.

Про согласие пользователя. Есть платформы, которые платят людям деньги за то, что они играют в разные игры. Вот и согласие. Чем не идея для стартапа :) Ведь во время “золотой лихорадки” выгоднее продавать “кирки и лопаты”.

VP здорового человека. Копаем вглубь

Sun, 27 Nov 2022 10:06:56 +0000

Продолжение серии постов про VP здорового человека.

Получается, что VP здорового человека - это предприниматель в большой компании, владелец бизнеса end-2-end. У этого бизнеса, внутри бизнеса, есть своя Value Chain. Свои отчеты о продажах (продукт ведь должны покупать) и затраты на производство, продвижение, … затраты на все то, что есть в нашей Value Chain. У него есть своя Value Chain. Свой P&L, бюджет. Он может стратегически развивать свое подразделение.

Да, этот бизнес встроен в большую компанию, поэтому ему не нужно решать многие, уже решенные, проблемы. Но это ничем не отличается от взаимодействия самой компании с ее подрядчиками и партнерами. Никто не вырабатывает электроэнергию самостоятельно – ее покупают. Уборкой помещений может заниматься клининговая компания. Доставкой товара – партнер. Никто не выстраивает Value Chain с нуля. Всегда есть подрядчики и партнеры.

Продукты и разные VP

Раз все крутится вокруг продукта (то что покупают у компании), то VP – человек, отвечающий за продукт или линейку продуктов. Если двигаться выше, то SVP - за семейство продуктов (семейство линеек продуктов).

Сюда же может попасть региональная специфика (Азия, Европа, Африка, …) – за каждый регион может отвечать свой VP. Причем это верно и логично – даже если функционально это тот же продукт (что вряд ли), то конструктивно он точно собирается из других модулей. А так же от региона к региону могут отличаться Value Chain.

VP везде

С одной стороны продукт всегда связан с деньгами, которые компания получает за него. А вот разбиение на компании очень условное и зависит от того как договоримся. Получается даже внутри компании можно ввести денежные отношения и тогда будут продукты, продаваемые другим юнитам.

На примере большой сервисной IT компании:

Глава Java Global Delivery Organization (GDO) обучает и растит Java специалистов, команды Java-специалистов, Java-консультантов – это первый продукт.
Их покупает проект конкретного аккаунта и перепродает клиенту предварительно собрав их, организовав в команду – это второй продукт (тут реальные деньги).
Эту команду (или команды) клиент далее использует для создания своего продукта, …

Даже больше скажу, это уже пытались ввести на уровне всей компании. У Delivery Manager-ов проекта есть P&L, у Reporter-ов (глав больших юнитов, как Java GDO VS) он так же есть. Не слышал, чтобы он именно использовался для управления и развития. Но учитывается как один из KPI, health уровня.

Т.е. разница именно в том действуете ли вы, на вашем уровне, как предприниматель, владелец своего бизнеса или нет. Если действуете – можете считать себя VP и развивать соответствующие навыки. Нет – выберите себе уровень ниже по иерархии (Директор, Менеджер – оба варианта неплохи) и действуйте в соответствии с ним.

Выбор за вами. Впрочем, как всегда.

Бонус.

Выходит, что даже если ваш продукт не покупают напрямую, то это не значит, что вы не можете считать себя VP (владельцем бизнеса, но уже по роли). Это значит, что вашу пользу посчитать очень сложно. Но можно. И если так все же сделать, то будет проще обосновывать зачем вам дополнительные ресурсы. Или же узнать, что вам они не нужны и вы занимались не тем. Как повезёт.

Зато можно понять, что раз вы “владелец бизнеса”, то можете свой бизнес развивать, выстраивать его стратегию и добиваться успехов в том, что вы делаете.

Вице-президент (VP) здорового человека

Sun, 27 Nov 2022 09:54:56 +0000

Это будет серия постов про мое понимание тайтла* Vice President. Какие должности он может занимать, какие роли выполнять. Мне кажется, я достаточно неплохо приблизился к пониманию. Поехали.

Серия:

VP здорового человека (этот пост)
VP здорового человека. Копаем вглубь
Организация, как набор бизнесов на общем фундамете
Собираем VP- title назад: компетенции и навыки VP-здорового человека
VP здорового человека. Противоречия, которые еще осталось разрешить
…буду продолжать серию по мере появления мыслей

Описание проблемы

Сразу скажу, что рассуждать о VP (который title) как о роли или должности – неверно. Title – это как раз описание набора компетенций и навыков, которые умеет выполнять конкретный работник. И стоило бы начать с этого. Но знания и умения вряд ли дадут нам понимание зачем нужен VP и чем он отличается, скажем, от Директора. Поэтому я буду рассуждать о Должностях и Ролях, которые может занимать VP. Мне кажется, так будет понятнее, и уже из них можно понять какие навыки и знания ему нужны.

Так же важно отметить, что я считаю, что все VP-titles, выданные для мотивации, будут VP-нездорового человека. Так же как и все VP-тайтлы выданные, как часть пакета бенефитов тоже не является здоровыми. Да, они имеют право на жизнь, но по ним невозможно разобраться что это за title и какие компетенции ему нужны (кроме умения играть в гольф с SVP).

Еще одно важное замечание: Должность (в организации), Позиция (в проекте), Роль (так же в проекте) и title (как уровень квалификации сотрудника) – разные вещи. Пример: Андрей Ковалев, sr. solution architect по тайтлу, Head of Architecture, Java VS по должности, работает на проекте на позиции Delivery Manager (да, было и такое), но, в числе прочего, выполняет роль Business Analyst потому что эта практика на проекте хромает и ее нужно вытягивать. Конец отступления.

В общем, если мы хотим понять что нужно знать и уметь будучи VP, как думать о его работе, то лучше думать о роли (ролях) которую он исполняет в организации. Будем разбираться. Поехали.

Какие работы может выполнять VP, которые не может (не готов) выполнять Директор, а так же что его отличает от C-level executives

Поехали. Начнем опять издалека (тема-то сложная), с иерархии отвественности:

Исполнитель – хорошо знает свою работу, отлично умеет ее делать. Взаимодействует с другими людьми, но не организует их работу. Не отвечает за коллективный результат (хоть и понимает, что он часть команды).
Менеджер – умеет организовывать людей в команды, чтобы они вместе могли выполнять общее дело. Решает вопросы с нехваткой работников, сроками исполнения. Недоступностью исполнителей, болезнями, отпусками, сменами… Отвечает за выполнение работ и достижение показателей. Но не отвечает за использование результата дальше (хоть и понимает, как этот результат укладывается в то, что делает компания).
Директор – отвечает за конкретное капабилити (capability) в компании, отвечает за постановку и достижение показателей, умеет ставить цели по развитию этого капабилити в соответствии со стратегией. Не отвечает за выработку стратегии: что же мы развиваем и куда стремимся (хоть и участвует в ее выработке и почему она такая какая есть.).
Вице-президент – мы тут, разбираемся что же это за фрукт.
C-level executive – управляющий на уровне всей компании, отвечает за конкретные практики и типы работ на уровне всей компании.

В общем, получается, что VP отвечает за стратегию (чего-то), но не отвечает за всю компанию (там уже C-level). Так что же там может такого быть в компании, что требует своей стратегии, но не вся компания?

Вы уже понимаете к чему я веду: к Business Units – направлениям бизнеса в компании, отдельным продуктам и линейкам продуктов, которые продает компания. Т.е. эдакая мини-компания внутри большой компании. Вот за нее, по моему, и должен отвечать VP.

Выходит, VP – это предприниматель в большой компании, владелец бизнеса end-2-end. Но встроенного в большую компанию, поэтому ему не нужно решать многие, уже решенные, проблемы. А вот C-level executives нужно – они отвечают за всю организацию.

Получилось достаточно складно. Детали будут в следующем посте.

Примечания

Я прошу вас поспорить и покритиковать/попинать иерархию выше. Очень может оказаться, что я натягиваю сову на глобус и разница в уровнях не такая, тогда и понимание будет неверным. Давайте улучшать или даже исправлять его (понимание) вместе.
Википедия делает интересное замечание: “A vice president, also director in British English”. Т.е. в британском английском Vice President == Director.

Еще интересно, что если разбираться в тайтле Директор, то оказывается, что директора – это C-level executives (executive directors). Но “Large organizations may also have “assistant” or “deputy” directors. In this context, Director commonly refers to the lowest level of executive in an organization, but many large companies use the title of associate director more frequently.”

В общем весело у них там. А мы даже не говорим про плоские (flat) организации. В общем будем разбираться :)

Не знаю аналога title в русском. Ближе всего: погоны в армии. Вот “Слесарь II-разряда” – это что? Квалификация? Что находится в тарифной сетке? Вот не нашел. Зато нашел отличное описание требований к квалификации такого слесаря. Это специальность? Тоже нет. Вот и мучаюсь. Если кто поможет – буду рад отказаться от английского “title” или аналогии с армией и погонами.

Роль DevOps в изменении организации. Или рост Dev Ops (менеджера) в CTO (директора по развитию)

Wed, 16 Nov 2022 13:14:00 +0000

Роль DevOps (менеджера) в организации

С одной стороны роль DevOps (менеджера) одна из самых важных в современной организации, в наше время экономики скорости (Economy of Speed, Death by Efficiency Is Slow and Painful). Ведь DevOps (как роль) отвечает за то, чтобы компания как можно быстрее и, главное, стабильнее вносила изменения в существующие продукты и доставляла их клиенту в готовом виде. Даже есть мнение, что именно их задача сделать так, чтобы всё работало на конце клиента.

В идеале поставка клиенту (от момента внесения последних изменений разработчиками) должна происходить по принципу “холодной и темной фабрики”, т.е. полностью автоматизированна (холодной и темной потому, что “роботам” не нужен свет и тепло, они могут работать и в темноте). Это задача DevOps.

С другой стороны, такие DevOps не работают над своими продуктами, а помогают другим руководителям быстрее и качественнее доставлять их продукты конечным потребителям. Исполнители такого DevOps менеджера работают непосредственно с командами руководителей продуктов (как бизнес, так и IT). И на нем сконцентрировано внимание многих служб, ожидающих от него результата. Ведь без технологий сейчас невозможно обслуживать клиентов с ожидаемой скоростью и качеством.

Зона ответственности DevOps (менеджера)

Получается, что DevOps действительно находится в центре переплетения всего и вся в организации.

Но где же будет его зона ответственности? Я не согласен, что его ответственность “чтобы всё работало на конце клиента”. Такая ответственность обычно только у руководителей, которые работают напрямую с клиентами (клиентами банка), именно они принимают на себя весь “огонь”. Вернее их подчиненные (скажем, кассиры/менеджеры по работе с клиентами/c кредитами…, работающие непосредственно с клиентом в зале). А уже потом сами руководители.

Да, такой DevOps (менеджер) оказывается организатором работы десятка бригад, и с клиентами эти бригады связывает именно он. Особенно, когда на предприятии обычный зоопарк и этим зоопарком такой DevOps вынужден заниматься. То есть у DevOps оказывается под сотню человек в непрямом подчинении, организацией труда которых он занимается.

Получается очень организационно сильная позиция. Но с другой такой DevOps постоянно тушит пожары (чужие) и огребает в чужой зоне ответственности. Как можно это понять? Легко. Спросите у него кто получает нагоняй (и главное от кого) если что-то не работает? А потом кто получает поощрения и премии (и опять от кого?), когда все работает как часы? Сильно сомневаюсь, что наш DevOps.

DevOps как владелец чего-то end2end

Как такой DevOps может стать ответственным за свою работу и только за нее? Получая поощрения и премии за хорошую работу и не получая нагоняи за чужие просчеты? Ниже – один из вариантов ответа. Мне кажется, что он единственный, но who knows.

Для этого DevOps (менеджер) должен:

1) Выделить из своей работы платформу, перевести на нее все отделы с которыми он работает. Перевести с помощью своей команды.

2) Структурировать свой отдел на платформенную команду отдельно (со всеми метриками и показателями, особенно финансовыми) и на интеграторов отдельно (их структурировать в соответствии со структурой тех кто платформой пользуется). Платформенная команда будет заниматься поддержкой и развитием платформы, а команда интеграторов будет по-старинке помогать отделам, но на платформе.

3) На 3м этапе передать интеграторов в отделы, которые платформой пользуются, а у себя оставить только ту часть интеграторов (“enablement team”), которая бы онбордила новые отделы и помогала внедрять новые элементы платформы и выпиливать старые.

4) Отвечать только за платформу, ее развитие и ее метрики. Метрики доступности, надежности, отказоустойчивости. И, конечно же, метрики стоимости. А еще полезно собирать информацию о пользователях платформы. Как часто и как полно они ей пользуются, дружить с лояльными пользователями и делать из их успехов Case Studies и показывать их. В общем делать все то, что делает грамотный Product Manager.

Вот только тогда DevOps будет владеть чем-то end2end. Своей платформой.

Под платформой я имею ввиду вот это: https://martinfowler.com/articles/talk-about-platforms.html Именно из такой платформы появился AWS клауд.

Что конкретно делать и куда вести свою DevOps платформу?

Об этом написано десятки книг, масса статей и видео в интернете. Есть пример Public Clouds – того идеала к которому нужно стремиться. Полный Self-service для ваших пользователей. Причем нам сейчас проще. Можно выбрать из тех же Public Clouds и других доступных технологий.

Процессы, зоны ответственности, так же можно взять из книг и методологий – это не так принципально. Вы все равно в первый раз ошибетесь, важно умение учиться и исправлять свои ошибки (помните: стратегия – ничто, стратегирование – все).

Одна из таких книг – это учебник Системной Инженерии (от ШСМ). В нем (а далее учебнике Системного Менеджмента эта мысль разворачивается дальше) про DevOps/SRE/platform engineering говорится достаточно много. Про то как определить границы систем и платформы, как организовать работу людей, какие компетенции нужны.

Но есть маленькая проблемка. Она даже не в том, что именно технически делается внутри DevOps, а как это все вписывается в общую работу фирмы. В этом вся сложность. Мало понимать как надо и где место DevOps на предприятии: “DevOps вот тут, занимается вот таким”.

Нужен DevOps (менеджер) который сможет договорить всех вокруг себя, получить бюджет на такие изменения (часть подчиненных ведь будет заниматься не только интеграцией, но и самой платформой, т.е. вкладом в будущее), уметь показывать промежуточные результаты и идти к цели.

Как таким стать или как его найти – читаем дальше.

Но подожди, как всех вокруг договорить?

Получается, что мало знать куда мы хотим придти, это только половина дела. Да, Системная Инженерия и Системный менеджмент (и другие книги) дают ответы на то как нужно. Еще важно именно договорить всех вокруг себя. А это сильно непросто.

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

По сути, DevOps сталкиваются ровно с той же проблемой, с которой сталкиваются при внедрении любой IT системы уровня предприятия:

а) Процессы не гармонизированы и в куче своей решаются людьми на стыках. Такие процессы и решения не видно, они спрятаны в головах людей.

б) Инвентаризация, каталогизация и шире “configuration management” оставляет желать лучшего. Snowflake configuration антипаттерн как один из аспектов.

Поэтому такие решения должны приниматься на уровне CIO/CTO или хотя бы на уровне portfolio manager (portfolio в терминах SAFe, например). Нужно с ними договариваться, у них брать бюджеты, от них получать авторитет и право вносить изменения на уровне каждой подсистемы предприятия или подсистемы portfolio.

Именно они должны вложиться в гармонизацию процессов, именно они должны мотивировать своих подчиненных (лидеров) подниматься по уровням зрелости в дашборде.

Дашборд и уровни зрелости должны быть предоставлены нашим DevOps менеджером.

В итоге оказывается, что тут вопрос по мотивации и стратегии организации. Такие изменения не сделать предварительно не разобравшись в лидерстве и стратегировании (или не пройдя предварительно курс Системного Менеджмента и Стратегирования).

Т.е. да, у ШСМ есть ответы. Но пройти этот путь нужно каждому самостоятельно.

И да, идеально, чтобы системный инженер был в должности CTO (директора по развитию) – ему проще всех договаривать.

Заключение

Еще я бы добавил, что далеко не на всех предприятиях, где “созрела необходимость”, эту необходимость понимают на уровне разработки стратегии. Зачастую проще и безопаснее, чтобы работники продолжали работать по-старому. “Работает ведь? Ч0 париться-то?”. Да и репутация не страдает в случае неудачи. Ведь всегда так делали-то.

Именно поэтому такие изменения должен привносить внешний человек. Либо новый в компании, либо консультант – у него нет мотивации сохранить “статус кво”.

А еще, в CTO и директоров по развитию вырастали из начальников аналитических служб –– им виднее что в организации делается не так.