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

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

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

Вот, например, однажды я общался с Максимом Цепковым — человеком с репутацией, о которой знают многие. Но только на 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

Накипело немного.......🤬🤬

Когда работаешь в интерпрайзе, ощущение, то у тебя любое действие должно быть в рамках и со множеством ограничений. Огромное количество политик безопасности, и каждый твой шаг – под пристальным наблюдением и логированием. И вот у тебя есть несколько контуров, учетных записей, и все эти "адские" пароли с длиной переходящей за десяток символов, и вот вопрос, как их запомнить??? Когда их меняют каждые несколько месяцев, и комбинации должны быть уникальными? Ах да, еще и на каждом ПК свои пароли. Как в этом всем вообще не запутаться и через пару лет не поехать🤪? А у вас как?😱

Думаешь, хороший дизайн системы – это когда сел, напряг извилины, нарисовал идеальную схему, реализовал, и всё? Эх, да кабы так всё было, тогда..... Ладно, это не наш случай😀

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

Почему рефакторинг – не опция, а необходимость?
🔁 Бизнес меняется, значит требования меняются - код устаревает.
Ты можешь спроектировать идеальный сервис, но через год он превратится в кучу костылей, если не обновлять архитектуру.

⚡ Быстрое решение – не всегда плохое решение. Но оно временное.
Когда-то ты заложил "временный workaround". Если не вернуться и не переделать – через год этот "временный" костыль станет легаси, которое в твоей команде будут боятся трогать.

🏗️ Систему всегда можно улучшить, если её трогать.
Но если ты её не трогаешь – она медленно разваливается. Как старый код, который "работает, не трожь". Поэтому не бойтесь этого, главное хорошенько тестируйтесь и побольше регреса.

Кейс из жизни
Когда мы разрабатывали платформу для real-time решений, всё было логично и красиво. Потом бизнес захотел новую фичу. Думаете всё????? Потом ещё одну. Думаете всё????? Потом расширение. Всё это наворачивалось поверх исходной архитектуры, как заплатки.

Думаете мы стали ждать пока всё этого зарастёт и прирастёт - ноууу, поэтому периодически обсуждаем каждый кусок архитектуры и модернизируем его🚀

Как итог мыслИ
Архитектура не бывает "готовой". А если ты не рефакторишь систему – ты не архитектор, а скульптор, который вырубил что-то из камня и надеется, что оно само адаптируется.

📌 Как часто вы возвращаетесь и меняете фундамент своих решений? Или ваш код – это музей архитектурных решений/ошибок? 😏


@it_underside

Вот читаешь порой статьи и ухахатываешься, насколько все нереалистично и большая часть аналитики, которую выбрасывают в массы - бред, особенно люблю за это дзен😁, главное броски заголовки научились делать😀

Пример ниже
https://dzen.ru/a/Z5MUSY6bG07j0I_F

Была статья от рбк, но как всегда в своём репертуаре, сохранял, сохранял и потерял....

Нормальные люди отдыхают, а я вот NDA по новому проекту готовлю.... Как только начинаешь вчитываться в юридические формулировки, кажется, что это отдельный язык — и мозг уже рисует круги на воде 🌀 и голова кругом...... 🐱