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

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

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

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

Господи…

Зачем я сегодня полез в этот эфир? 😬
Это был ужас: каждую минуту продавали консультации и мастер-классы. Я сначала даже не понял, что происходит!

Как я там оказался? Пообщался с ассистентом бывшего преподавателя ВШЭ (тот сейчас «прокачивает» эмоциональный интеллект у ИТ руководителей), меня пригласили в эфир — вроде всё цивильно, план обсуждения есть, общаться должен с бывшим преподавателем... Но… Сам эфир — жесть. Человек называет себя ИТ-экспертом, но не знает базовых нюансов ИТ и управления, говорит общими фразами, не разбирается в управленческих подходах…
Теперь буду как следует проверять, с кем связываюсь.
) 😀

Кажется "сглазил" я СА....

Вот буквально было несколько человек, но пока был в раздумьях, то 📂. Так что, поиск ещё открыт😁

Немного подробнее о проекте тут
https://news.1rj.ru/str/it_underside/196

И да, проект в крупном enterprise со всеми нюансами)) и достоинствами

Так немного сумбурных мыслей о поиске работы, команде....

Поделюсь своими мыслями о том, насколько сложным может быть процесс найма в уже слаженной команде. Когда все процессы отлажены, а вокруг тебя работают специалисты высокого уровня, поиск нового участника превращается в настоящее приключение – ведь как рук ты не можешь допустить фатальной ошибки и ошибиться в человеке, так как за твоей спиной деlлайны и kpi. Чем круче и опытнее команда, тем выше становятся критерии для кандидатов.😅😅

За годы управления командами я понял одно: новый человек должен не только соответствовать требованиям, но и вносить свою уникальную энергию в общее уравнение. Команда = уравнение, где каждая переменная имеет значение. Одним из главных критериев для меня всегда является именно уровень энергии. Конечно, профессиональный опыт и знания – необходимая база, но именно личная энергия, энтузиазм и стремление развиваться задают нужный тон всему коллективу. Лукавлю, желательно, чтобы был настоящий комбо!🥲

Не замечал такой корреляции? Чем выше уровень специалиста, тем иногда ниже его энергия – сигнал, что, возможно, он выгорел. А выгорание заметно: такой кандидат сразу попадает в категорию «неподходящих», ведь энергия – это то, что позволяет решать любые задачи и поддерживать баланс в команде, а за занавесом с потенциально низкой энергией может быть безынициативный или наоборот, кто знает?

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

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

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

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

И вот несколько советов для тех, кто находится в поиске новой работы⬇️⬇️

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

Если ты готов внести свою энергию в команду и расти вместе с моей командой – пиши, будем рады рассмотреть твою кандидатуру!

P.S. надеюсь Т9 не поменял ничего на выходе)))