Часто в индустрии слышу противопоставление заказная разработка vs in-house или outsource vs продуктовая разработка.
Причем иной раз работаешь в продукте, а отношение как к заказной. Или наоборот, ребята на аутсорсе, но настолько вовлечены – очень приятно работать.
Эта статья чуть лучше разделила для меня эти два мира и подсветила разницу.

Что я вынес из статьи:
1. Если в продуктовой компании вам кажется, что вы продаете (покупаете) время – что-то идет не так.
2. Если вам вашим разработчикам важно успеть сделать все запланированные таски (output) – возможно им будет менее интересен реальный результат (outcome).
3. Мы очень часто сталкиваемся (начиная со школьных оценок) с тем, что у нас фейковые, не приносящие ценности цели. Фича, написанная в стол. Отчет, который никто не читает.

И напоследок, пара цитат на эту тему

“The righter we do the wrong thing, the wronger we become” (Russell Ackoff)
"Successful outcomes over efficient delivery" (из статьи)

Понимайте своего потребителя и делайте правильные вещи

Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов

#DDD #MSA

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

По итогам нашего часового разговора я накидал такой список того, что я рекомендую почитать и посмотреть
1) Для будущих CTO - Technology Strategy Patterns - https://bit.ly/TechStrgPatterns - тут классно рассказано про подходы к мышлению бизнесменов и паттерны, которые они используют, например, Value Chain, SWOT Analysis, Growth Matrix, Futures Funnel, ... Эти подходы неплохо знать технарям, чтобы коммуницировать с бизнесом насчет техннических решений в терминах и подходах, которые будут им понятны
2) Про деливери - Визуализируте работу - https://apolomodov.medium.com/review-making-work-visible-8ff41a044f9b - базовая книжка про Kanban подход и чем он хорош при оптимизации Delivery
3) Про создание крутых продуктов - Дизайн привычных вещей - https://apolomodov.medium.com/review-design-of-everyday-things-part-1-ab86566431c6 - это книга про human centric design
4) Крутая книга про мышление - The Model Thinkign - https://apolomodov.medium.com/the-model-thinker-review-8ff710d38f96 - крутая книга, что улучшает понимание подходов к моделированию окружающего мира
5) Книга про топологии команд - Team Topologies - https://apolomodov.medium.com/review-team-topologies-part-1-205533a027c0 - здесь про струткуру команд и их эффективное взаимодействие
6) Мой доклад про изменение роли руководителя по мере роста компании и команды - Что такое CTO от стартапа до IPO, или трансформация роли CTO по мере роста компании - https://apolomodov.medium.com/highload-what-is-cto-406afab7fd5
7) Про изменение процессов (лучше прочитать и посмотреть видео, так как в тексте нет части про delivery managers) - Как мы меняли разработку лучшего* мобильного банка под требования бизнеса - https://apolomodov.medium.com/refactoring-of-mobile-bank-d40858d96f73
8) Моя статья про качество и скорость разработки - Качество vs скорость разработки — как найти баланс? - https://bit.ly/speedVsQuality
9) Книга про лидерство - The Art of Leadership - https://bit.ly/artOfLeadership

#SelfDevelopment #Software #Architecture #Management

В продолжение темы продуктовой разработки. На моем опыте хорошие инженерные практики (в том числе Domain-driven design) намного лучше приживаются если продакт взаимодействует с командой не с позиции "заказчик-исполнители", а активно вовлекает в свою работу и интересуется техническими аспектами реализации.

Приходите – поболтаем)

Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.

🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.

📍Программа и регистрация: https://archconf.ru/recap-27-07-22

В чате периодически пролетают вопросы про обучение. Поэтому решил написать серию постов с тегом #обучение

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

Первый пост про #обучение

Курс Проектирование микросервисов от Сергея Баранова и компании ScrumTrek.

На этом курсе Сергей рассказывает про микросервисный подход, в том числе о подходах к проектированию, Event Storming и DDD.

Сергей - активный участник нашего сообщества. Можно уточнить некоторые моменты у него напрямую.


Подробности на странице курса
http://l.devtrick.com/sergey-baranov-microservices

#обучение

Второй пост про Podlodka Crew.

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

18 июля стартует Podlodka Backend Crew, тема сезона – "Делаем приложения быстрее"!

В этот раз будут разбирать производительность приложений. А именно:
⚡️Замерять и анализировать нагрузку
⚡️Оптимизировать узкие места, не переписывая сервис с нуля
⚡️Грамотно использовать многопоточность и эффективно утилизировать доступные ресурсы
⚡️Ускорять все, что тормозит!

На этом потоке не будет привязки к конкретному стеку и фреймворкам. Из необычного - пара докладов посвящена рективному подходу и акторной модели.

Как всегда в Podlodka Crew все это на протяжении недели с различными форматами сессий и с живым комьюнити в Slack.

Купить билеты, посмотреть расписание и посмотреть подробнее темы можно на страничке http://l.devtrick.com/podlodka-crew

Промокод DDD500 даст скидку 500р

#обучение

И да, опять скоро 😜
Но на этот раз бесплатный курс Product Mindset

Я проходил один из потоков курса, но, кажется, ребята его переработали.

Зачем это разработчику? Можно:
- побыть в шкуре продакт оунера или продакт менеджера, чтобы челленджить и поддерживать;
- прокачать продуктовое мышление, чтобы делать правильные вещи;
- подумать про свой стартап, чтобы... придумайте сами)

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

Было у вас такое? У меня точно было много раз. Иной раз оптимальной стратегией будет просто не вступать в споры – все равно никто не готов менять свою позицию.

Но если вы все таки готовы менять свои убеждения и спор для вас это не прокачка ЧСВ, то рекомендую попробовать приемы уличной эпистемологии https://streetepistemology.ru/vvedenie-v-ue.

Помните, что цель дискуссии – не переубедить собеседника, а прийти к верному мнению)

Ребята из разных компаний обсудили популярную в DDD сообществе (благодарим Ника Тьюна) книгу Team Topologies с точки зрения различных подходов к масштабированию https://youtu.be/zfZilR0iSkA

Знал и ранее, что LeSS-овики считают её откровенно вредной)

#обучение

Ребята из StringConcat (@elukianov и @Bukharovsi_sg) активно участвуют в жизни нашего сообщества, работали в известных компаниях: Яндекс. Деньгах, Behavox (UK), ThoughtWorks, под одним логотипом с Мартином Фаулером и Нилом Фордом.

Теперь они делятся своим опытом на курсе "Разработка Enterprise-приложений на Java и Kotlin без боли и сожалений"

их доклад про Чистую архитектуру является самым кликбейтным просматриваемым на канале)

и я там был, мед-пиво коктейли пил...)

Многоликий DDD — Сергей Баранов

Domain Driven Design всегда имел высокий порог входа. Сложность изучения и применения усугублялась туманностью объяснений выгод как для коллег-разработчиков, так и для архитекторов, менеджеров, продактов. Подарившим DDD вторую жизнь ударом дефибрилятора стали микросервисы. Микросервисы — это то, как мы проводим границы и оказалось, что в DDD для этого содержаться одни из лучших инструментов. Профессиональное сообщество подхватило идеи DDD на хайпе микросервисов и началось бурное развитие.

Появились и новые техники, облегчающие вход в DDD и открывающие новые возможности. Умело комбинируя Event Storming и DDD можно из одной и той же модели получить бэклог, API, тестовые сценарии, наброски UI/UX, структуру команд, структуру компонентов и тех же микросервисов. Именно об этом пойдет речь в докладе.

Выступление будет полезно для того, чтобы:
1. Выжать из DDD еще больше, если вы уже его применяете
2. Научиться «продавать» DDD через выгоды, понятные тем, кому «продаете»
3. Расширить кругозор

https://www.youtube.com/watch?v=NSN-NXfbEqM