Срочно признавайтесь, кто писал архитектуру на уровне с4??

😀

Когда речь заходит о проектировании архитектуры, на ум приходят те самые уровни C1, C2, C3, C4, описанные Саймоном Брауном. Это как матрешка, только вместо кукол — слои:

⚫️C1 (Контекст): общая картина мира — кто, что и зачем.
⚫️C2 (Контейнеры): из каких блоков состоит система и как они общаются.
⚫️C3 (Компоненты): углубляемся в контейнеры и рассматриваем их состав.
⚫️C4 (Код): доходим до уровня классов и методов.

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

Вот, например, я знаю только шестерых человек, которые могут реально проектировать на этом уровне. Это не те, кто «немного слышал», а те, кто реально живет архитектурой и понимает, что связывает эти уровни. Также это крайне непубличные товарищи)

А вы таких встречали или может сами можете? С4 реальность или утопия?

Как вы относитесь к таким новостям? 👇

Для меня конференции — это не просто формальность или способ "поставить галочку". Это шанс:

🟢Перетереть свои боли и переживания. Увидеть, что ты не один такой, что твои проблемы — часть огромного пазла индустрии.
🟢Поймать волну вдохновения. Узнать о новых подходах, которые могут кардинально поменять твой взгляд на привычные процессы.
🟢Пересмотреть рутину. Иногда кажется, что делаешь все правильно, пока не услышишь свежий взгляд извне.
🟢Лично прокачаться. А где еще можно найти идеи, как повысить свою эффективность и профессиональную ценность?
🟢Ну и да, "продать" себя. Как бы цинично это ни звучало, такие мероприятия дают возможность либо показать себя новым работодателям, либо заново обсудить договоренности со своей текущей компанией.

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

Вот, например, однажды я общался с Максимом Цепковым — человеком с репутацией, о которой знают многие. Но только на WAW я увидел его с совершенно новой стороны (с лучшей😅), которая заставила задуматься о пересмотре вообще подхода к анализу, да, такие моменты бесценны.

Кстати, совсем недавно мне написал мой хороший знакомый Эльдар — тот самый, кто организует конференции Analyst Days (23-24 мая), SQA Days (25-26 апр.) и TechWriter Days (28-29 марта). Он сообщил, что они только что завершили формирование программы для конференции технических писателей. Если эта тема вам интересна — обязательно загляните!

На фото, если что, я и Эльдар на WAW 2024. Прекрасный человек и отличный организатор. 👌

#Конференция #Вдохновение #Networking #AnalystDays, #SQADays #TechWriterDays

Парадокс.....

На тему поста меня навела вечерняя переписка с одним хорошим аналитиком.

В проектах порой встречается парадокс, чем глубже системные аналитики прописывают требования тем более низкий уровень разработчиков на проекте. А если, наоборот, ТЗ (не важно как вы ТЗ у себя на проекте называете, главное суть) не детализировано, т.е. скажем, ограничиваемся лишь уровнем абстракции описания максимум до С2/С3 ), то разработчики обычно выше на уровень. Т.е. когда аналитики описывают всё вплоть до нюансов: классов, функций и т.д., тем меньше у разработчиков простора для принятия архитектурных решений — и, как итог, их экспертность со временем стагнирует или их изначальный уровень уже крайне низкий. В случае, когда аналитик оставляет простор дышать совбодно разработчика, то они получают возможность «создавать» и думать сами и в итоге растут быстрее, у них есть возможность использования множества различных вариантов, есть и оборотная сторона медали: отсутствие подробных требований может обернуться рисками и срывом сроков, а вдруг разработчик свернёт не туда и спринт потерян?

Почему детальные ТЗ могут «отбивать» экспертизу?
1. Нет пространства для R&D. Аналитики «заложили» решение, разработчику остаётся лишь воплотить его в коде. Меньше творчества, меньше причин думать о новых технологиях, алгоритмах и паттернах
2. Сокращение инициативы, когда всё продумано заранее, разработчики превращаются в «исполнителей» - кодеров. Со временем это убивает мотивацию предлагать альтернативы и учиться новому. Для умного разработчика - это путь в никуда.
3. Узкое горлышко аналитики. Разработка ждёт, пока аналитики сделают свою работу. Если документ «подвис» или требует переделок, команда разработки простаивает, а когда дело доходит до кода, уже сложно изменить что-то фундаментально.

А в чём же, плюсы детального ТЗ??
⚫️Повышенная предсказуемость, т.е. заказчик и менеджмент понимают сроки и объём работ.
- Быстрый старт: проще начать, меньше вопросов на входе.
- Меньше рисков по бизнес-логике: аналитики учитывают все нюансы и сценарии. Помните тот мем? когда заказчик рисует одну картину на спине аналитика, аналитик вторую и так дальше, по итогу как и в сломанном телефоне мы имеет что-то формально близкое, но отличающееся от видения заказчика.

Минусы детального ТЗ
- Ограниченное развитие разработчиков, меньше возможностей «изобретать» и повышать технологическую экспертизу. (Останется кодером)
- Зависимость от аналитиков, если те сделали неточность, баг и «тянется» по всей цепочке.
- Потенциальная потеря «уникальных» решений, у разработчиков могут быть идеи, но они останутся невостребованными. (Выгорание)

Если, наоборот, ТЗ общее и не детализированное
Плюсы: гибкость, пространство для технического креатива, рост экспертизы разработчиков, совместное решение проблем.
Минусы: выше риски, что что-то пойдёт не так по срокам, объёмам и качеству. Нужна сильная команда, умеющая держать удар, иначе застрянут в бесконечных уточнениях.

Как найти баланс???
Если честно, то тут всё весьма субъективно и зависит от множества переменных уравнения, какая компания, забюрократизированность, сложность проекта и т.п. - у меня есть некий чек-лист с алгоритмом, который я для себя выработал по итогу опыта работы с разными командыми, если захотите можем обсудить🙂Но ещё раз, всё крайне субъективно и переменные уравнения придется не раз подтачивать.

1. Разделяйте зоны ответственности. Аналитики занимаются бизнес-логикой, пользовательскими сценариями и требованиями, а ведущие разработчики — архитектурой и выбором технологий.
2. Совместные воркшопы. Подключайте разработчиков на этапе обсуждения требований, а аналитиков — на этапе ревью архитектурных концепций. Вовлечённость обеих сторон повышает общий уровень экспертизы.
3. Фокус на мотивацию и культуру. Создавайте условия, где разработчикам интересно предлагать и обосновывать новые решения.
4. Ставьте гибкие рамки. Детально расписывайте только самые рисковые участки системы, а всё остальное давайте доработать товарищам разработчикам.

@it_underside