Почему коллега отдыхает, а я работаю?

👀 Мне поручили очень большую задачу, которую нужно выполнять мелкими итерациями ещё года два.

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

🫠 И вот тут начинается самое интересное.

Задачи я разделила следующим образом:

🦾 Трудные задачи (там, где я предполагала проблемы) оставила себе. Почему?

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

🐶 Остальные задачи передала коллеге: обучила его, всё показала и мягко контролировала процесс.

😵‍💫 Но почему тогда я всё ещё зашиваюсь, а коллега уже несколько недель назад закончил свои задачи?

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

🤔 Что вы думаете?

Не скрывается ли здесь ошибка организационного или управленческого характера?
Где грань между тем, чтобы делегировать ответственность и "скинуть" её?

🙈Как быть ментором для синьора, если ты не синьор🙈

Cвой уровень я не оцениваю как синьор, в этом вопросе я к себе очень строга. Но так вышло, что ко мне на менторство пришла коллега, чей уровень оценивается именно так.

Именно эти общения в ходе менторской программы MENTOR IN TECH 6.0 мне понравились больше всего.

Но давайте обо всём по порядку. 😏

❓Что сделала я, когда поняла, что уровень человека с запросом на менторство очень близок к моему, а местами и выше❓

👉🏼Честно сказала об этом человеку. Никаких попыток показаться опытнее, чем я есть. После предложила чётко узнать её запрос, а также помочь с поиском более опытного ментора.

После разбора запроса стало понятно, что общение из положения ментор-менти нам не подходит.👌🏼 И мы перешли в общение, которое я бы назвала "расширяем понимание профессии друг у друга" или дружеские посиделки ☕️.

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

Конечно, местами было неуютно, намного легче с серьёзным лицом рассказывать о чём-то новичку, чем опытному коллеге. Самозванцу очень неудобно в эти моменты. С другой стороны, отличный тест для самой себя: понять, где ты откровенно сам себе не договариваешь.

⚡️Отвечая на вопрос, как быть ментором в такой ситуации? Я для себя определила, что в большинстве случаев никак. Но это не повод отказываться от возможности пообщаться на равных.

❓А как бы поступили вы❓

Для полноты картины, у моей несостоявшейся менти я тоже соберу ОС, и если она разрешит, поделюсь с вами.
#менторингИт #КарьеравИТ #нетворкинг

🫠Мы сделали идеальные требования. Теперь страдают все🫠

Наконец-то наша команда аналитиков выработала стандарты документации, и теперь наши постановки стали проработаннее, детальнее и структурированнее.

💡 Как думаете, стали ли проще разработка, уменьшился Time to Market (время выхода в релиз фичи с момента создания) и снизилось количество ошибок при разработке?

🚫 НЕТ. 🚫

📌 Детализация = больше проверок

Теперь в постановках больше деталей, которые можно трактовать по-разному или просто не заметить, но которые QA теперь точно должны проверить. Если раньше на задачу хватало 5 проверок, то теперь их 20. Время проверки увеличилось кратно.

📌 Ревью — плюс часы к разработке

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

📌 Меньше гибкости для команды
А где-то мы закрываем возможность предложить бэкам и фронтам лучшее решение, потому что уже кажется, что всё продумано. Конечно, есть груминг и обсуждения, но на нашем уровне детализации они не спасают.

📌 Проблемы с планированием

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

Я смотрю на этот снежный ком и думаю:
Мы действительно улучшили процесс, или просто придумали способ посидеть в песочнице подольше?

Безусловно, есть и плюсы:
✅ Выпускаемые фичи продуманнее, и ошибок меньше. Клиенты отзываются, что решения стали качественными.
✅ Процессы и решения стали прозрачнее. Мы не только шаблоны постановок придумали)
✅ Команда не тратит время на погружение, и можно давать такие постановки новичкам.

Но вот точно ли мы как команда разработки выиграли? 🤔 Не знаю. И имеющимися инструментами оценить не могу.

Ваши мысли?

📌 Как понять, насколько детализированными должны быть требования?
📌 Как прикинуть пользу от нового шаблона?

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

#SA #systemanalyst #системныйаналитик #ИТБоль

🌀 Марианская впадина и выжженное поле документации 🌋

Иногда мне кажется, что мы прокляты или отсутствием документации, или ее избыточным количеством!

🌵 Первое проклятие: выжженное поле.
Это проекты без документации. Ты приходишь, вокруг пусто, торчат "бадылки" кода, а объяснений — nichts. Ты даже не знаешь, что когда-то должно было тут расти. Нет комментариев, нет задач. Это уже не археология, так как даже код устарел, и обращаться к нему, как к истине может быть ОПАСНО (как в анекдоте: ниточку оборвешь — уши отвалятся)!

🌊 Второе проклятие: Марианская впадина.
Это противоположность: документации так много, что ты просто теряешься. За одним конфлюенсом скрывается еще один, архивный. А за ним — целый лабиринт тикетов в JIRA, а проектов несколько и часть тоже архивная.

И что хуже — отсутствие документации или ее избыток?
На мой взгляд, избыточная документация пугает больше. Она демотивирует, создает апатию, потому что:
- Трудно объяснить, почему при ее обилии все равно не хватает информации.
- Трудно использовать неподдерживаемые документы, которые давно устарели.
- Это не помогает другим командам/новичкам/"археологам" понять, как проект устроен — они просто теряются в потоке.

Я не могу придумать красивое решение, как выйти из ситуации, когда вас "завалило" доками! ИМХО, путь тот же, что и с отсутвием - начать с чистого листа создавать документацию!

🎯 Но с учетом того, что важно помнить о нескольких условиях!

☝️ 0: Определите ЦЕЛЬ и ПОТРЕБИТЕЛЕЙ документации.
Без этого пункта можно ничего не писать! Так как получится, что либо написанное никому ненужно, либо для тех кому нужно так и не появилась документация!

1️⃣ Сначала договоритесь о терминах.
Никакой документации не будет толку, если внутри команды все понимают слова по-разному. На днях столкнулась с ситуацией, когда для меня "зонтик" = кросс-командный проект, для коллеги — кобренд с внешним партнером.

2️⃣ Определите продукт и его границы.
О чем ваш продукт? Кто его потребитель? Это не просто набор фич. Это должен быть четко очерченный набор ценностей, которые продукт приносит.

3️⃣ Поймите, как ваш продукт монетизируется.
Даже если он внутренний (например, платформа), его монетизация — это сокращение затрат других подразделений. Это тоже нужно учитывать.

4️⃣ Решите, нужна ли вам документация наружу.
Если у вас платформа (а уж если не платформа - тем более), подумайте, будете ли вы публиковать документацию (и какую ее часть) для внешних пользователей. Это определяет, как выстроить структуру документов.

5️⃣ Сосредоточьтесь на “бережливой документации”.
Не нужно писать многотомные руководства, которые никто не будет читать. Актуализируйте, если не постоянно, то — регулярно. Разделяйте информацию на уровне: стратегический (общее представление) и тактический (подробные инструкции).

6️⃣ Интегрируйте документацию в процесс работы.
Документация должна быть не только полезной, но и доступной, а также стать частью вашего рабочего процесса! Документы — это артефакты фиксации мыслей, и именно через них можно идеи челенджить, тестировать, да и риски митигировать и нивелировать на этапе документирования приятнее, чем в проде :)

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

А как вы справляетесь с “проклятиями” документации? Какие аксиомы лежат в базисе ваших артефактов? Делитесь опытом, мне будет интересно! 😊

#architecture #project_management

💴Оффер есть, а денег нет: два взгляда на контракты💴

😬Ситуация, однако😬
Моя подруга несколько месяцев проходила собеседования в одной компании. Наконец, получила заветный оффер и оставалось подписать договор.

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

😱Почему компания может уволить сотрудника за один день, но требует предупреждать об увольнении за 30 дней?

После раздумий компания ответила, что "договор стандартный, все подписывают как есть". Здесь уже подруга решила подумать.
Но работодатель не стал ждать ответа и отозвал оффер, написав:
😱"Нарушены договоренности выхода. Оффер отзываем. Удачи!"😱

💶Ситуация, однако 2💶
Кандидат получил оффер, его устраивала зарплата. Но перед подписанием договора он решил пообщаться с коллегами из компании через LinkedIn. В результате, зная информацию об опциональных плюшках, договор удалось дополнить следующими условиями:

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

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

Что думаете? Стоит ли читать договоры? Может, у вас были похожие случаи?

Мои мысли:
Я, честно, раньше не слишком внимательно читала договоры. Если не было вопросов — подписывала. Теперь понимаю, что это было ошибкой.

Обе истории, на мой взгляд, удачные по-своему:

Компания, которая отзывает оффер после уточняющих вопросов и прописывает возможность увольнения за 1 день, — это явный риск для соискателя. Такие моменты важно сделать прозрачными заранее.
А дополнительные "плюшки" во второй истории только подтверждают: всегда стоит пробовать договариваться.

#КарьеравИТ #юридическое

Как узнать, что пора просить повышение? Уйти в отпуск.

Или я снова пришла поныть.

У меня закончился отпуск. Это уже само по себе печально. За три дня моего отсутствия работа не то чтобы встала, но ряд задач оказался заблокирован.

🤔 Ситуация, однако.

С одной стороны, я такой уникальный, незаменимый специалист, что даже имея к кому обратиться в моё отсутствие, команда без меня не справляется.
З-значимость.

💡 С другой стороны, на этапе регрессионного тестирования команде всё равно приходится обращаться к аналитику. Значит, я не смогла достаточно продумать и качественно донести до команды, что и как должно быть.
П-провал меня как специалиста.

💡 С третьей стороны, это неверно встроенные процессы, отсутствие распространения знаний в команде и уже до неприличия расползающаяся система, разобраться в которой можно только через Людей-Документацию.
П-провал, но уже менеджеров.
И У-успех меня как одного из тех самых I am DOCUMENTATION.

🛑 В реальности – это всё сразу. И уникальность, и провалы, и значимость.

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

Или у вас совсем другое видение такой ситуации? Как вас встречают после отпусков?

#СистемныйАналитик #РаботаСА #ЯДокументация #ИТРеалии