Вчера наконец-то добралась до Клуба проектирования NextWay (сайт).
⭐️Что это такое?
Это воркшопы, похожие на архитектурные каты, где можно прокачать навыки проектирования систем на разных кейсах. NextWay запустили клуб недавно, и 19 числа была только третья встреча.
👀Мой отзыв будет состоять из двух постов:
1️⃣О воркшопе: организация, кейс, степень полезности и кому подходит.
2️⃣Мои собственные впечатления о том, как проходить такие воркшопы и о сложностях участия.
✌🏼Кейс✌🏼
Проектировали систему A/B-тестирования для сравнения версий функционала путём их предоставления разным группам пользователей. Огромный плюс - это не избитый кейс, типа работы книжного магазина.
👂🏻Как проходит👂🏻
В командах по 3 человека мы итерациями строили архитектуру уровня компонентов в нотации C4. Итерации включали выяснение требований, логическую модель данных и последующие.
👉🏻Организация👉🏼
Не без косяков: материалы иногда задерживали, выход из тайминга на 1,5 часа был болезненным (особенно в выходной), поэтому часть людей не дошла до конца. С другой стороны, последнее можно рассматривать как "больше пользы" за те же деньги. Ещё была некоторая путаница в ответах, из-за чего я путалась и теряла время. Хотя, если честно, вряд ли отсутствие путаницы помогло бы мне успешнее дойти до конца.
Будет ли это поводом не вернуться в клуб снова? Нет. Мои студенты знают, что с таймингом я тоже грешу (но стараюсь исправиться). А небольшая несогласованность? Ну, это уникальный продукт, который проводится без повторов, так что это допустимо. Просто я уже избалована тем, как хорошо может быть организовано у тех же NextWay и других школ.
🤌🏻Полезность🤌🏻
Для меня это был крутой опыт, учитывая мои планы на ближайшие годы (да, я из тех, кто может сказать, где видит себя через 3–5 лет). Такие воркшопы позволяют трогать разные системы и видеть, как работают другие.
👍🏻Кому полезно👍🏻
Если проектирование архитектуры вам интересно, и вы либо начали уже прикасаться к этой теме, либо планируете в обозримом будущем — однозначно полезно.Но нормально, если вы, будучи системным аналитиком, не видите в этом пользы для себя.
Стоит также смотреть на кейсы — возможно, в следующий раз будут разбирать именно ту тему, над которой вы сейчас работаете, и тогда безусловно стоит участвовать.
Если вы опытный архитектор или супер продвинутый СА, и, уже читая описание кейса, у вас в голове сложилась картина действий и достаточно точная диаграмма компонентов, то, вероятно, вам стоит попроситься в команду организаторов или подумать, где ещё можно применить свои силы.
⭐️Итог⭐️
Несмотря на небольшие промахи, я в восторге. Это было увлекательно и полезно. Есть, что обдумать и куда копать дальше.
#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем #NextWay #школысистемногоанализа
⭐️Что это такое?
Это воркшопы, похожие на архитектурные каты, где можно прокачать навыки проектирования систем на разных кейсах. NextWay запустили клуб недавно, и 19 числа была только третья встреча.
👀Мой отзыв будет состоять из двух постов:
1️⃣О воркшопе: организация, кейс, степень полезности и кому подходит.
2️⃣Мои собственные впечатления о том, как проходить такие воркшопы и о сложностях участия.
✌🏼Кейс✌🏼
Проектировали систему A/B-тестирования для сравнения версий функционала путём их предоставления разным группам пользователей. Огромный плюс - это не избитый кейс, типа работы книжного магазина.
👂🏻Как проходит👂🏻
В командах по 3 человека мы итерациями строили архитектуру уровня компонентов в нотации C4. Итерации включали выяснение требований, логическую модель данных и последующие.
👉🏻Организация👉🏼
Не без косяков: материалы иногда задерживали, выход из тайминга на 1,5 часа был болезненным (особенно в выходной), поэтому часть людей не дошла до конца. С другой стороны, последнее можно рассматривать как "больше пользы" за те же деньги. Ещё была некоторая путаница в ответах, из-за чего я путалась и теряла время. Хотя, если честно, вряд ли отсутствие путаницы помогло бы мне успешнее дойти до конца.
Будет ли это поводом не вернуться в клуб снова? Нет. Мои студенты знают, что с таймингом я тоже грешу (но стараюсь исправиться). А небольшая несогласованность? Ну, это уникальный продукт, который проводится без повторов, так что это допустимо. Просто я уже избалована тем, как хорошо может быть организовано у тех же NextWay и других школ.
🤌🏻Полезность🤌🏻
Для меня это был крутой опыт, учитывая мои планы на ближайшие годы (да, я из тех, кто может сказать, где видит себя через 3–5 лет). Такие воркшопы позволяют трогать разные системы и видеть, как работают другие.
👍🏻Кому полезно👍🏻
Если проектирование архитектуры вам интересно, и вы либо начали уже прикасаться к этой теме, либо планируете в обозримом будущем — однозначно полезно.
Стоит также смотреть на кейсы — возможно, в следующий раз будут разбирать именно ту тему, над которой вы сейчас работаете, и тогда безусловно стоит участвовать.
Если вы опытный архитектор или супер продвинутый СА, и, уже читая описание кейса, у вас в голове сложилась картина действий и достаточно точная диаграмма компонентов, то, вероятно, вам стоит попроситься в команду организаторов или подумать, где ещё можно применить свои силы.
⭐️Итог⭐️
Несмотря на небольшие промахи, я в восторге. Это было увлекательно и полезно. Есть, что обдумать и куда копать дальше.
#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем #NextWay #школысистемногоанализа
nextway.pro
Клуб проектирования NextWay
Регулярные воркшопы для развития навыков проектирования архитектуры.
🔥6👍4
👀Как стать гением архитектуры👀
Продолжаю делиться впечатлениями о клубе проектирования NextWay.
Поскольку школа NextWay ориентируется на аналитиков, большинство участников - аналитики. И мы оказались немного "подставлены" нашей проф. деформацией, в сравнении с тем как проходят такие секции архитекторы.
😱Выяснение требований: ФТ и НФТ
Первыми этапами стали сбор функциональных (ФТ) и нефункциональных требований (НФТ). Привычная задача для аналитиков. Мы с энтузиазмом бросились собирать информацию: задали кучу вопросов, узнали массу деталей. Но сколько из этого мы реально использовали? В лучшем случае, процентов 15.
🤔Провал с НФТ
Лично для меня этап с НФТ стал провалом. Я часто говорю своим менти, что одна из главных проблем аналитиков — это сбор НФТ "по-детски". То есть: спросили, записали и забыли, даже не пытаясь понять, зачем эти требования нужны.
В этот раз произошло то же самое. Все НФТ собрали, но использовала их только одна команда, да и то — минимально. Вспоминаю, как архитекторы на других мероприятиях, задавая меньше вопросов, использовали НФТ для расчетов, вплоть стоимости разработки и учёта в архитектуре. Это важный навык, которому аналитикам стоит учиться.
😁Проблемы внутри команд
Во время обсуждений в командах возникало немало сложностей. Мы держались за привычные нам вещи, что порой мешало двигаться дальше.
Много времени в моей команде потратили на обсуждение сервисов аутентификации, BFF и API Gateway. Обсуждения почти дошли до конфликтов, пока на схеме не появился заветный прямоугольник. Иронично, что эти компоненты для решаемого кейса были вовсе не важны. В результате на обсуждение критически важных систем времени просто не оставалось.
🙈Моя грустная реальность
К сожалению, я восприняла кейс и активность больше как экзамен, из-за чего испытала ступор и панику. Но с практикой придёт более чёткое понимание действий.
Я осознала, что клуб проектирования можно "хакнуть" и даже с минимальными знаниями выдавать хорошие решения. Пока у меня нет полного плана, но вот несколько мыслей:
❔Как хакнуть архитектуру❔
1️⃣Не забывать, что это учебный кейс.
Не нужно выяснять все требования до мельчайших деталей. В подобных задачах почти всегда есть конечный набор вопросов по ФТ и НФТ, который стоит задавать. После 5–10 практик я, возможно, смогу поделиться этим списком.
2️⃣Избегать конфликтов в команде.
Если в вашей команде есть конфликтные люди, которые тянут обсуждение на себя, попроситесь в другую группу.
3️⃣ Не тратить время на второстепенные сервисы.
Компоненты вроде аутентификации и API Gateway часто вторичны. Чтобы избежать "стопора", можно сразу нарисовать эти блоки на схеме и больше к ним не возвращаться.
4️⃣ Провокационные ответы ради обратной связи.
Чтобы услышать больше аргументов, полезно написать спорный ответ. Например, наша команда выбрала Cassandra в качестве одной из баз данных, хотя никто толком не знал, подходит ли она. В результате мы получили развернутую обратную связь, почему это не лучший выбор, и узнали о других вариантах.
5️⃣ Работай на знакомом уровне абстракции.
Если не знаете деталей многих решений, сосредоточьтесь на общем: интерфейс, бэкенд, кэш, БД. Главное — фокусироваться на системах, критичных для решения кейса.
6️⃣ Архитектура любит поцелуи
"KISS" (Keep It Simple, Stupid). Если систему можно не добавлять — не добавляйте. А если не понимаете, зачем она нужна, лучше не включайте её в архитектуру.
7️⃣ Освой базовые знания.
Минимальный набор: знание нотации C4 (до третьего уровня) и понимание технологий первого выбора.
8️⃣ Рефлексируй после практики.
Перерисуй эталонную архитектуру. Сформулируй вопросы к ней. Разбери неизвестные элементы. Подумайте, как можно улучшить решение.
⚡️Заключение⚡️
Эти советы не заменят знаний и реальной практики, но точно помогут лучше ориентироваться и быстрее развиваться. А дальше только опыт.
#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем
Продолжаю делиться впечатлениями о клубе проектирования NextWay.
Поскольку школа NextWay ориентируется на аналитиков, большинство участников - аналитики. И мы оказались немного "подставлены" нашей проф. деформацией, в сравнении с тем как проходят такие секции архитекторы.
😱Выяснение требований: ФТ и НФТ
Первыми этапами стали сбор функциональных (ФТ) и нефункциональных требований (НФТ). Привычная задача для аналитиков. Мы с энтузиазмом бросились собирать информацию: задали кучу вопросов, узнали массу деталей. Но сколько из этого мы реально использовали? В лучшем случае, процентов 15.
🤔Провал с НФТ
Лично для меня этап с НФТ стал провалом. Я часто говорю своим менти, что одна из главных проблем аналитиков — это сбор НФТ "по-детски". То есть: спросили, записали и забыли, даже не пытаясь понять, зачем эти требования нужны.
В этот раз произошло то же самое. Все НФТ собрали, но использовала их только одна команда, да и то — минимально. Вспоминаю, как архитекторы на других мероприятиях, задавая меньше вопросов, использовали НФТ для расчетов, вплоть стоимости разработки и учёта в архитектуре. Это важный навык, которому аналитикам стоит учиться.
😁Проблемы внутри команд
Во время обсуждений в командах возникало немало сложностей. Мы держались за привычные нам вещи, что порой мешало двигаться дальше.
Много времени в моей команде потратили на обсуждение сервисов аутентификации, BFF и API Gateway. Обсуждения почти дошли до конфликтов, пока на схеме не появился заветный прямоугольник. Иронично, что эти компоненты для решаемого кейса были вовсе не важны. В результате на обсуждение критически важных систем времени просто не оставалось.
🙈Моя грустная реальность
К сожалению, я восприняла кейс и активность больше как экзамен, из-за чего испытала ступор и панику. Но с практикой придёт более чёткое понимание действий.
Я осознала, что клуб проектирования можно "хакнуть" и даже с минимальными знаниями выдавать хорошие решения. Пока у меня нет полного плана, но вот несколько мыслей:
❔Как хакнуть архитектуру❔
1️⃣Не забывать, что это учебный кейс.
Не нужно выяснять все требования до мельчайших деталей. В подобных задачах почти всегда есть конечный набор вопросов по ФТ и НФТ, который стоит задавать. После 5–10 практик я, возможно, смогу поделиться этим списком.
2️⃣Избегать конфликтов в команде.
Если в вашей команде есть конфликтные люди, которые тянут обсуждение на себя, попроситесь в другую группу.
3️⃣ Не тратить время на второстепенные сервисы.
Компоненты вроде аутентификации и API Gateway часто вторичны. Чтобы избежать "стопора", можно сразу нарисовать эти блоки на схеме и больше к ним не возвращаться.
4️⃣ Провокационные ответы ради обратной связи.
Чтобы услышать больше аргументов, полезно написать спорный ответ. Например, наша команда выбрала Cassandra в качестве одной из баз данных, хотя никто толком не знал, подходит ли она. В результате мы получили развернутую обратную связь, почему это не лучший выбор, и узнали о других вариантах.
5️⃣ Работай на знакомом уровне абстракции.
Если не знаете деталей многих решений, сосредоточьтесь на общем: интерфейс, бэкенд, кэш, БД. Главное — фокусироваться на системах, критичных для решения кейса.
6️⃣ Архитектура любит поцелуи
"KISS" (Keep It Simple, Stupid). Если систему можно не добавлять — не добавляйте. А если не понимаете, зачем она нужна, лучше не включайте её в архитектуру.
7️⃣ Освой базовые знания.
Минимальный набор: знание нотации C4 (до третьего уровня) и понимание технологий первого выбора.
8️⃣ Рефлексируй после практики.
Перерисуй эталонную архитектуру. Сформулируй вопросы к ней. Разбери неизвестные элементы. Подумайте, как можно улучшить решение.
⚡️Заключение⚡️
Эти советы не заменят знаний и реальной практики, но точно помогут лучше ориентироваться и быстрее развиваться. А дальше только опыт.
#ИТархитектура #СистемныйАнализ #АрхитектурнаяКата #проектированиеИТсистем
🔥8👍4❤1🤔1
Почему коллега отдыхает, а я работаю?
👀 Мне поручили очень большую задачу, которую нужно выполнять мелкими итерациями ещё года два.
Я продумала, как с ней работать в долгосрочной перспективе: создала стандарты, шаблоны и стартовые требования. Всё это сделано так, чтобы разные аналитики могли подключаться к задаче с минимальными затратами времени на погружение. Чтобы успеть выполнить первый пул задач к ближайшему релизу, я также подключила менее опытного коллегу.
🫠 И вот тут начинается самое интересное.
Задачи я разделила следующим образом:
🦾 Трудные задачи (там, где я предполагала проблемы) оставила себе. Почему?
Чтобы проработать решения, которые помогут в долгосрочной перспективе избежать подобных проблем в будущем.
Взять на себя больше ответственности, так как коллега менее опытный и я местами справлюсь быстрее и эффективнее.
🐶 Остальные задачи передала коллеге: обучила его, всё показала и мягко контролировала процесс.
😵💫 Но почему тогда я всё ещё зашиваюсь, а коллега уже несколько недель назад закончил свои задачи?
С одной стороны, мои действия кажутся логичными. С другой — я будто намеренно сложила все "протухшие яйца" в одну корзину и удивляюсь почему воняет именно из моей корзины. И, скорее всего, это произошло, потому что я не смогла до конца довериться коллеге.
🤔 Что вы думаете?
Не скрывается ли здесь ошибка организационного или управленческого характера?
Где грань между тем, чтобы делегировать ответственность и "скинуть" её?
👀 Мне поручили очень большую задачу, которую нужно выполнять мелкими итерациями ещё года два.
Я продумала, как с ней работать в долгосрочной перспективе: создала стандарты, шаблоны и стартовые требования. Всё это сделано так, чтобы разные аналитики могли подключаться к задаче с минимальными затратами времени на погружение. Чтобы успеть выполнить первый пул задач к ближайшему релизу, я также подключила менее опытного коллегу.
🫠 И вот тут начинается самое интересное.
Задачи я разделила следующим образом:
🦾 Трудные задачи (там, где я предполагала проблемы) оставила себе. Почему?
Чтобы проработать решения, которые помогут в долгосрочной перспективе избежать подобных проблем в будущем.
Взять на себя больше ответственности, так как коллега менее опытный и я местами справлюсь быстрее и эффективнее.
😵💫 Но почему тогда я всё ещё зашиваюсь, а коллега уже несколько недель назад закончил свои задачи?
С одной стороны, мои действия кажутся логичными. С другой — я будто намеренно сложила все "протухшие яйца" в одну корзину и удивляюсь почему воняет именно из моей корзины. И, скорее всего, это произошло, потому что я не смогла до конца довериться коллеге.
🤔 Что вы думаете?
Не скрывается ли здесь ошибка организационного или управленческого характера?
Где грань между тем, чтобы делегировать ответственность и "скинуть" её?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
Нужен ваш совет
Что подарить на 33 летние мужу айтишнику, если тонометр и ортопедическое кресло у него уже есть?
#выходнойконтент
Что подарить на 33 летние мужу айтишнику, если тонометр и ортопедическое кресло у него уже есть?
#выходнойконтент
🤡4😁2❤1🤔1
Бинго ментора, или как я была ментором для: интерна, мидла и синьора
Завершилась программа Mentor in Tech, в рамках которой я была наставником для 3 специалисток. Их уровень варьировался от интерна до синьора, а запросы — от первых шагов в профессии до сложных карьерных вопросов, на которые я порой и сама искала ответы.
Для контекста, синьор был на одном уровне со мной, а может, даже выше. Это добавило новых граней в процесс менторства и стало настоящим вызовом.
Каждая сессия была уникальной, ведь запросы у всех были разными, но все они так или иначе крутились вокруг карьерного трека. Честно говоря, мне пришлось непросто: где-то я справилась достойно, а где-то чувствовала, что не оправдала ожиданий.
Проверьте вашу интуицию!
Как думаете:
С кем из них мне было интереснее всего?
🔥 - интерн 👍 - мидл 👀 - синьор
С кем оказалось сложнее всего? (голосование в опросе)
Человеку с каким уровнем я вообще не смогла помочь? (голосование в опросе)
#СистемныйАнализ #ментор #наставничествовИТ
Завершилась программа Mentor in Tech, в рамках которой я была наставником для 3 специалисток. Их уровень варьировался от интерна до синьора, а запросы — от первых шагов в профессии до сложных карьерных вопросов, на которые я порой и сама искала ответы.
Для контекста, синьор был на одном уровне со мной, а может, даже выше. Это добавило новых граней в процесс менторства и стало настоящим вызовом.
Каждая сессия была уникальной, ведь запросы у всех были разными, но все они так или иначе крутились вокруг карьерного трека. Честно говоря, мне пришлось непросто: где-то я справилась достойно, а где-то чувствовала, что не оправдала ожиданий.
Проверьте вашу интуицию!
Как думаете:
С кем из них мне было интереснее всего?
🔥 - интерн 👍 - мидл 👀 - синьор
С кем оказалось сложнее всего? (голосование в опросе)
Человеку с каким уровнем я вообще не смогла помочь? (голосование в опросе)
#СистемныйАнализ #ментор #наставничествовИТ
👀6🔥3👍1
🙈Как быть ментором для синьора, если ты не синьор🙈
Cвой уровень я не оцениваю как синьор, в этом вопросе я к себе очень строга. Но так вышло, что ко мне на менторство пришла коллега, чей уровень оценивается именно так.
Именно эти общения в ходе менторской программы MENTOR IN TECH 6.0 мне понравились больше всего.
Но давайте обо всём по порядку. 😏
❓Что сделала я, когда поняла, что уровень человека с запросом на менторство очень близок к моему, а местами и выше❓
👉🏼Честно сказала об этом человеку. Никаких попыток показаться опытнее, чем я есть. После предложила чётко узнать её запрос, а также помочь с поиском более опытного ментора.
После разбора запроса стало понятно, что общение из положения ментор-менти нам не подходит.👌🏼 И мы перешли в общение, которое я бы назвала "расширяем понимание профессии друг у друга" или дружеские посиделки☕️ .
Мы достаточно плодотворно общались по инструментам, проблемам и другим вопросам, которые встречаются в наших задачах.🐶 Я ждала и жду этих встреч 🐶 , потому что узнаю новое, вспоминаю об успешно забытых вещах и в очередной раз понимаю: "И это тоже про работу системного аналитика". Например, вновь вспомнила и стараюсь внедрять "Три амиго", а также подглядела несколько хороших шаблонов для бизнес-анализа. После этих общений мне проще воспринимать, что я чего-то не знаю, а также находить для себя новые темы для изучения.
Конечно, местами было неуютно, намного легче с серьёзным лицом рассказывать о чём-то новичку, чем опытному коллеге. Самозванцу очень неудобно в эти моменты. С другой стороны, отличный тест для самой себя: понять, где ты откровенно сам себе не договариваешь.
⚡️Отвечая на вопрос, как быть ментором в такой ситуации? Я для себя определила, что в большинстве случаев никак. Но это не повод отказываться от возможности пообщаться на равных.
❓А как бы поступили вы❓
Для полноты картины, у моей несостоявшейся менти я тоже соберу ОС, и если она разрешит, поделюсь с вами.
#менторингИт #КарьеравИТ #нетворкинг
Cвой уровень я не оцениваю как синьор, в этом вопросе я к себе очень строга. Но так вышло, что ко мне на менторство пришла коллега, чей уровень оценивается именно так.
Именно эти общения в ходе менторской программы MENTOR IN TECH 6.0 мне понравились больше всего.
Но давайте обо всём по порядку. 😏
❓Что сделала я, когда поняла, что уровень человека с запросом на менторство очень близок к моему, а местами и выше❓
👉🏼Честно сказала об этом человеку. Никаких попыток показаться опытнее, чем я есть. После предложила чётко узнать её запрос, а также помочь с поиском более опытного ментора.
После разбора запроса стало понятно, что общение из положения ментор-менти нам не подходит.👌🏼 И мы перешли в общение, которое я бы назвала "расширяем понимание профессии друг у друга" или дружеские посиделки
Мы достаточно плодотворно общались по инструментам, проблемам и другим вопросам, которые встречаются в наших задачах.
Конечно, местами было неуютно, намного легче с серьёзным лицом рассказывать о чём-то новичку, чем опытному коллеге. Самозванцу очень неудобно в эти моменты. С другой стороны, отличный тест для самой себя: понять, где ты откровенно сам себе не договариваешь.
⚡️Отвечая на вопрос, как быть ментором в такой ситуации? Я для себя определила, что в большинстве случаев никак. Но это не повод отказываться от возможности пообщаться на равных.
❓А как бы поступили вы❓
Для полноты картины, у моей несостоявшейся менти я тоже соберу ОС, и если она разрешит, поделюсь с вами.
#менторингИт #КарьеравИТ #нетворкинг
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11
Ты закрываешь глаза, а там... 😱НОВЫЕ ТРЕБОВАНИЯ😱
Самое неприятное в сложные моменты на работе — это невозможность отключиться от них после рабочего дня.
Например, сейчас я не могу нормально спать, потому что мне раз за разом снится утрированная ситуация:
Я прихожу к команде 💃🏻 и объявляю: "Требования снова поменялись".
QA и backend-разработчики медленно поднимают головы, уставшие, с темными кругами под глазами, и как зомби спрашивают: "Зачем?🧟♀️🧟♀️🧟♀️🧟♀️"
Этот сон повторяется уже неделю. От такого "отдыха" я сама превращаюсь в зомби, и мои решения становятся менее точными😢.
Для меня сон — важная часть моей неудержимой энергии. Опытным путем я знаю, что мне нужно 9 часов сна, и обычно они у меня есть. Но сейчас из-за этих кошмаров их меньше.
А ведь я люблю спать и видеть сны. Обычные сновидения для меня — это яркие, фантастические миры, которые я искренне обожаю. А сейчас у меня один и тот же кошмар, где главная злодейка — это я.
И здесь начинается замкнутый круг:
🔄 Сложный период → нужны силы на решения → сил не хватает, потому что сложный период.
Как выбираюсь из таких состояний? За счет внутренних ресурсов. Но они не бесконечны.
📌 Моя стратегия в долгосрочной перспективе — строить работу так, чтобы минимизировать вероятность тяжелых периодов. Но в реальности полностью исключить их невозможно.
Обычно помогают маленькие ритуалы: спорт, массаж, прогулки… но в такие моменты всё это просто посылается в Ж*
А у вас бывало такое? Как справляетесь? Делитесь — вдруг спасете не только меня, но и весь отдел QA😅
#ИТМысли #выходнойконтент #МеняйТребованияКаждыйДень #ИТБоль
Самое неприятное в сложные моменты на работе — это невозможность отключиться от них после рабочего дня.
Например, сейчас я не могу нормально спать, потому что мне раз за разом снится утрированная ситуация:
Я прихожу к команде 💃🏻 и объявляю: "Требования снова поменялись".
QA и backend-разработчики медленно поднимают головы, уставшие, с темными кругами под глазами, и как зомби спрашивают: "Зачем?🧟♀️🧟♀️🧟♀️🧟♀️"
Этот сон повторяется уже неделю. От такого "отдыха" я сама превращаюсь в зомби, и мои решения становятся менее точными😢.
Для меня сон — важная часть моей неудержимой энергии. Опытным путем я знаю, что мне нужно 9 часов сна, и обычно они у меня есть. Но сейчас из-за этих кошмаров их меньше.
А ведь я люблю спать и видеть сны. Обычные сновидения для меня — это яркие, фантастические миры, которые я искренне обожаю. А сейчас у меня один и тот же кошмар, где главная злодейка — это я.
И здесь начинается замкнутый круг:
🔄 Сложный период → нужны силы на решения → сил не хватает, потому что сложный период.
Как выбираюсь из таких состояний? За счет внутренних ресурсов. Но они не бесконечны.
📌 Моя стратегия в долгосрочной перспективе — строить работу так, чтобы минимизировать вероятность тяжелых периодов. Но в реальности полностью исключить их невозможно.
Обычно помогают маленькие ритуалы: спорт, массаж, прогулки… но в такие моменты всё это просто посылается в Ж*
А у вас бывало такое? Как справляетесь? Делитесь — вдруг спасете не только меня, но и весь отдел QA😅
#ИТМысли #выходнойконтент #МеняйТребованияКаждыйДень #ИТБоль
👀4😁3
👀Какую технологию выбрать?👀
Здесь я вскользь упомянула технологии первого выбора. Давайте разберём подробнее.
👉🏻Большинство из нас, если упомянуть БД, сразу подумают про PostgreSQL и MySQL, а говоря о брокерах — про Kafka и RabbitMQ. Такие технологии, которые действительно стоит рассмотреть в первую очередь при выборе технологий, называются технологиями первого выбора.
❔Что такое технологии первого выбора❔
Это проверенные временем и опытом решения, которые применяются в большинстве типовых кейсов в ИТ системах.
😏Почему их выбирают?😏
- Универсальность. Эти технологии подходят для самых разных задач.
- Масштабируемость. Они хорошо справляются с ростом нагрузки.
- Отказоустойчивость. Высокая надёжность в критичных ситуациях.
- Интеграция. Простота подключения к другим системам.
- Сообщества и документация. Большая база знаний и активное комьюнити.
👍🏻Значит ли это, что их всегда нужно использовать👍🏻
Нет, выбор зависит от ваших конкретных задач и требований. Определиться помогает грамотное осмысление функциональных и нефункциональных требований.
☺️ Как использую эту информацию я ☺️
Я выписала для себя технологии первого выбора. Теперь, в областях, где у меня пока мало опыта, буду сосредотачивать своё обучение именно на них. Можно не распыляться!
В картинках, примеры разных технологий первого выбора. Сохраняйте себе)
И делитесь в комментариях как бы дополнили карточки вы?
#проектированиеИТсистем #СистемныйАнализ
Здесь я вскользь упомянула технологии первого выбора. Давайте разберём подробнее.
👉🏻Большинство из нас, если упомянуть БД, сразу подумают про PostgreSQL и MySQL, а говоря о брокерах — про Kafka и RabbitMQ. Такие технологии, которые действительно стоит рассмотреть в первую очередь при выборе технологий, называются технологиями первого выбора.
❔Что такое технологии первого выбора❔
Это проверенные временем и опытом решения, которые применяются в большинстве типовых кейсов в ИТ системах.
😏Почему их выбирают?😏
- Универсальность. Эти технологии подходят для самых разных задач.
- Масштабируемость. Они хорошо справляются с ростом нагрузки.
- Отказоустойчивость. Высокая надёжность в критичных ситуациях.
- Интеграция. Простота подключения к другим системам.
- Сообщества и документация. Большая база знаний и активное комьюнити.
👍🏻Значит ли это, что их всегда нужно использовать👍🏻
Нет, выбор зависит от ваших конкретных задач и требований. Определиться помогает грамотное осмысление функциональных и нефункциональных требований.
☺️ Как использую эту информацию я ☺️
Я выписала для себя технологии первого выбора. Теперь, в областях, где у меня пока мало опыта, буду сосредотачивать своё обучение именно на них. Можно не распыляться!
В картинках, примеры разных технологий первого выбора. Сохраняйте себе)
И делитесь в комментариях как бы дополнили карточки вы?
#проектированиеИТсистем #СистемныйАнализ
👍8❤1🔥1
😂Почему энергия из отпуска не работает на буднях?😂
Оказывается, человек в отпуске и человек в рабочее время — это совсем разные люди.
На каникулах я решила попробовать новый формат для блога. Формат интересный, с элементами образовательного контента, но требующий много времени и усилий. Тогда я чувствовала себя полной сил.
🙈Потом каникулы закончились.
Времени стало в разы меньше, сил тоже. То, что казалось мне прекрасной идеей, начало тяготить.
😕Но я же уже публично пообещала🤔
Потому собиралась сдержать обещание. Подготовила посты на эту тему и они должны были начать публиковаться сегодня. Но в тот же момент ведение блога стало вызывать отторжение. Это стало сигналом, чтобы пересмотреть подход.
❌Не очередной образовательный контент
Я вспомнила, что изначально не хотела превращать блог в очередной образовательный ресурс. Причин много, но главная — мне хотелось больше личных историй. У нас уже есть замечательные каналы вроде Get Analyst или Systems Education, где полно полезностей. А вот заглянуть в жизнь других ИТ-специалистов бывает негде.
💙Всегда есть что сказать
А еще мне почти всегда есть что рассказать: чему удивиться, на что пожаловаться, чем поделиться. И как совместить это с целым месяцем одной тематики я не знаю и не хочу.
😁Катя из отпуска отправилась в игнор😁
Поэтому я решила не слушать ту Катю из отпуска, которая была переполнена энергией. Лучше поддержу ту себя, которая большую часть времени работает⭐️.
Тем не менее, я всё же сохраню часть из обещанного. Идея небольшого тестирования и последующей дискуссии по теме брокеров всё еще мне близка. Такой формат кажется интересным и менее обременительным.
Надеюсь на ваше понимание и поддержку.
❤️ А с тех, кто тоже слишком много всего обещает себе в отпуске, лайк и интересная история об этом в комментарии.🙌
Оказывается, человек в отпуске и человек в рабочее время — это совсем разные люди.
На каникулах я решила попробовать новый формат для блога. Формат интересный, с элементами образовательного контента, но требующий много времени и усилий. Тогда я чувствовала себя полной сил.
🙈Потом каникулы закончились.
Времени стало в разы меньше, сил тоже. То, что казалось мне прекрасной идеей, начало тяготить.
😕Но я же уже публично пообещала🤔
Потому собиралась сдержать обещание. Подготовила посты на эту тему и они должны были начать публиковаться сегодня. Но в тот же момент ведение блога стало вызывать отторжение. Это стало сигналом, чтобы пересмотреть подход.
❌Не очередной образовательный контент
Я вспомнила, что изначально не хотела превращать блог в очередной образовательный ресурс. Причин много, но главная — мне хотелось больше личных историй. У нас уже есть замечательные каналы вроде Get Analyst или Systems Education, где полно полезностей. А вот заглянуть в жизнь других ИТ-специалистов бывает негде.
💙Всегда есть что сказать
А еще мне почти всегда есть что рассказать: чему удивиться, на что пожаловаться, чем поделиться. И как совместить это с целым месяцем одной тематики я не знаю и не хочу.
😁Катя из отпуска отправилась в игнор😁
Поэтому я решила не слушать ту Катю из отпуска, которая была переполнена энергией. Лучше поддержу ту себя, которая большую часть времени работает⭐️.
Тем не менее, я всё же сохраню часть из обещанного. Идея небольшого тестирования и последующей дискуссии по теме брокеров всё еще мне близка. Такой формат кажется интересным и менее обременительным.
Надеюсь на ваше понимание и поддержку.
❤️ А с тех, кто тоже слишком много всего обещает себе в отпуске, лайк и интересная история об этом в комментарии.🙌
Telegram
Анализ, коты, цветы и Катя
Каникулы прошли успешно, и я чувствую, что готова попробовать новый уровень контента.
Новый формат: буду объявлять тему месяца, и вместе с вами разбираться в ней через серию коротких и не очень постов.
У меня есть темы, где я уже готова делиться экспертизой…
Новый формат: буду объявлять тему месяца, и вместе с вами разбираться в ней через серию коротких и не очень постов.
У меня есть темы, где я уже готова делиться экспертизой…
❤10💩1
🫠Мы сделали идеальные требования. Теперь страдают все🫠
Наконец-то наша команда аналитиков выработала стандарты документации, и теперь наши постановки стали проработаннее, детальнее и структурированнее.
💡 Как думаете, стали ли проще разработка, уменьшился Time to Market (время выхода в релиз фичи с момента создания) и снизилось количество ошибок при разработке?
🚫 НЕТ. 🚫
📌 Детализация = больше проверок
Теперь в постановках больше деталей, которые можно трактовать по-разному или просто не заметить, но которые QA теперь точно должны проверить. Если раньше на задачу хватало 5 проверок, то теперь их 20. Время проверки увеличилось кратно.
📌 Ревью — плюс часы к разработке
Появляется больше возможностей ошибаться самим аналитикам. По возможности привлекаем друг друга для ревью, а это плюс часы к разработке фичи и размывание ответственности.
📌 Меньше гибкости для команды
А где-то мы закрываем возможность предложить бэкам и фронтам лучшее решение, потому что уже кажется, что всё продумано. Конечно, есть груминг и обсуждения, но на нашем уровне детализации они не спасают.
📌 Проблемы с планированием
Чем больше требований, тем больше их можно проигнорировать. Добавляются часы к разработке и страдания всей команды, особенно менеджеров, потому что сроки покинуличат ещё на этапе аналитики.
Я смотрю на этот снежный ком и думаю:
Мы действительно улучшили процесс, или просто придумали способ посидеть в песочнице подольше?
Безусловно, есть и плюсы:
✅ Выпускаемые фичи продуманнее, и ошибок меньше. Клиенты отзываются, что решения стали качественными.
✅ Процессы и решения стали прозрачнее. Мы не только шаблоны постановок придумали)
✅ Команда не тратит время на погружение, и можно давать такие постановки новичкам.
Но вот точно ли мы как команда разработки выиграли? 🤔 Не знаю. И имеющимися инструментами оценить не могу.
Ваши мысли?
📌 Как понять, насколько детализированными должны быть требования?
📌 Как прикинуть пользу от нового шаблона?
Без вашего взгляда не справлюсь. А то я в своих размышлениях уже почти дошла до того, что аналитики не нужны(если вы хотите страдать). 😆
#SA #systemanalyst #системныйаналитик #ИТБоль
Наконец-то наша команда аналитиков выработала стандарты документации, и теперь наши постановки стали проработаннее, детальнее и структурированнее.
💡 Как думаете, стали ли проще разработка, уменьшился Time to Market (время выхода в релиз фичи с момента создания) и снизилось количество ошибок при разработке?
📌 Детализация = больше проверок
Теперь в постановках больше деталей, которые можно трактовать по-разному или просто не заметить, но которые QA теперь точно должны проверить. Если раньше на задачу хватало 5 проверок, то теперь их 20. Время проверки увеличилось кратно.
📌 Ревью — плюс часы к разработке
Появляется больше возможностей ошибаться самим аналитикам. По возможности привлекаем друг друга для ревью, а это плюс часы к разработке фичи и размывание ответственности.
📌 Меньше гибкости для команды
А где-то мы закрываем возможность предложить бэкам и фронтам лучшее решение, потому что уже кажется, что всё продумано. Конечно, есть груминг и обсуждения, но на нашем уровне детализации они не спасают.
📌 Проблемы с планированием
Чем больше требований, тем больше их можно проигнорировать. Добавляются часы к разработке и страдания всей команды, особенно менеджеров, потому что сроки покинули
Я смотрю на этот снежный ком и думаю:
Мы действительно улучшили процесс, или просто придумали способ посидеть в песочнице подольше?
Безусловно, есть и плюсы:
✅ Выпускаемые фичи продуманнее, и ошибок меньше. Клиенты отзываются, что решения стали качественными.
✅ Процессы и решения стали прозрачнее. Мы не только шаблоны постановок придумали)
✅ Команда не тратит время на погружение, и можно давать такие постановки новичкам.
Но вот точно ли мы как команда разработки выиграли? 🤔 Не знаю. И имеющимися инструментами оценить не могу.
Ваши мысли?
📌 Как понять, насколько детализированными должны быть требования?
📌 Как прикинуть пользу от нового шаблона?
Без вашего взгляда не справлюсь. А то я в своих размышлениях уже почти дошла до того, что аналитики не нужны
#SA #systemanalyst #системныйаналитик #ИТБоль
Please open Telegram to view this post
VIEW IN TELEGRAM
😁6❤1🤔1
Как будто в продолжение моего вчерашнего поста, сегодня появился этот пост. Не мой (а специалиста с прекрасным именем Катя), но кажется что многое из этого я тоже собиралась сказать) Ну а кое что было полезно вспомнить и узнать.
Telegram
ITKatya: культурные паттерны в IT
Я - Катя Лысенко. Техлид/Техменеджер с 15+ летним опытом в сферах fintech, e-grocery, и TIS.
Знаю как «сработать» IT команды и биздев, делюсь практическим опытом в финтехе - менторю, провожу мастер-классы и обучения.
Для сотрудничества @eslysenko
Знаю как «сработать» IT команды и биздев, делюсь практическим опытом в финтехе - менторю, провожу мастер-классы и обучения.
Для сотрудничества @eslysenko
Forwarded from ITKatya: культурные паттерны в IT
🌀 Марианская впадина и выжженное поле документации 🌋
Иногда мне кажется, что мы прокляты или отсутствием документации, или ее избыточным количеством!
🌵 Первое проклятие: выжженное поле.
Это проекты без документации. Ты приходишь, вокруг пусто, торчат "бадылки" кода, а объяснений —nichts. Ты даже не знаешь, что когда-то должно было тут расти. Нет комментариев, нет задач. Это уже не археология, так как даже код устарел, и обращаться к нему, как к истине может быть ОПАСНО (как в анекдоте: ниточку оборвешь — уши отвалятся )!
🌊 Второе проклятие: Марианская впадина.
Это противоположность: документации так много, что ты просто теряешься. За одним конфлюенсом скрывается еще один, архивный. А за ним — целый лабиринт тикетов в JIRA, а проектов несколько и часть тоже архивная.
И что хуже — отсутствие документации или ее избыток?
На мой взгляд, избыточная документация пугает больше. Она демотивирует, создает апатию, потому что:
- Трудно объяснить, почему при ее обилии все равно не хватает информации.
- Трудно использовать неподдерживаемые документы, которые давно устарели.
- Это не помогает другим командам/новичкам/"археологам" понять, как проект устроен — они просто теряются в потоке.
Я не могу придумать красивое решение, как выйти из ситуации, когда вас "завалило" доками! ИМХО, путь тот же, что и с отсутвием - начать с чистого листа создавать документацию!
🎯 Но с учетом того, что важно помнить о нескольких условиях!
☝️ 0: Определите ЦЕЛЬ и ПОТРЕБИТЕЛЕЙ документации.
Без этого пункта можно ничего не писать! Так как получится, что либо написанное никому ненужно, либо для тех кому нужно так и не появилась документация!
1️⃣ Сначала договоритесь о терминах.
Никакой документации не будет толку, если внутри команды все понимают слова по-разному. На днях столкнулась с ситуацией, когда для меня "зонтик" = кросс-командный проект, для коллеги — кобренд с внешним партнером.
2️⃣ Определите продукт и его границы.
О чем ваш продукт? Кто его потребитель? Это не просто набор фич. Это должен быть четко очерченный набор ценностей, которые продукт приносит.
3️⃣ Поймите, как ваш продукт монетизируется.
Даже если он внутренний (например, платформа), его монетизация — это сокращение затрат других подразделений. Это тоже нужно учитывать.
4️⃣ Решите, нужна ли вам документация наружу.
Если у вас платформа (а уж если не платформа - тем более), подумайте, будете ли вы публиковать документацию (и какую ее часть) для внешних пользователей. Это определяет, как выстроить структуру документов.
5️⃣ Сосредоточьтесь на “бережливой документации”.
Не нужно писать многотомные руководства, которые никто не будет читать. Актуализируйте, если не постоянно, то — регулярно. Разделяйте информацию на уровне: стратегический (общее представление) и тактический (подробные инструкции).
6️⃣ Интегрируйте документацию в процесс работы.
Документация должна быть не только полезной, но и доступной, а также стать частью вашего рабочего процесса! Документы — это артефакты фиксации мыслей, и именно через них можно идеи челенджить, тестировать, да и риски митигировать и нивелировать на этапе документирования приятнее, чем в проде :)
Хорошая документация — это баланс между пустотой и хаосом. Это не только описание текущего состояния, но и инструмент, который помогает новым людям разобраться в проекте, а продукту — развиваться.
А как вы справляетесь с “проклятиями” документации? Какие аксиомы лежат в базисе ваших артефактов? Делитесь опытом, мне будет интересно! 😊
#architecture #project_management
Иногда мне кажется, что мы прокляты или отсутствием документации, или ее избыточным количеством!
🌵 Первое проклятие: выжженное поле.
Это проекты без документации. Ты приходишь, вокруг пусто, торчат "бадылки" кода, а объяснений —
🌊 Второе проклятие: Марианская впадина.
Это противоположность: документации так много, что ты просто теряешься. За одним конфлюенсом скрывается еще один, архивный. А за ним — целый лабиринт тикетов в JIRA, а проектов несколько и часть тоже архивная.
И что хуже — отсутствие документации или ее избыток?
На мой взгляд, избыточная документация пугает больше. Она демотивирует, создает апатию, потому что:
- Трудно объяснить, почему при ее обилии все равно не хватает информации.
- Трудно использовать неподдерживаемые документы, которые давно устарели.
- Это не помогает другим командам/новичкам/"археологам" понять, как проект устроен — они просто теряются в потоке.
Я не могу придумать красивое решение, как выйти из ситуации, когда вас "завалило" доками! ИМХО, путь тот же, что и с отсутвием - начать с чистого листа создавать документацию!
🎯 Но с учетом того, что важно помнить о нескольких условиях!
Без этого пункта можно ничего не писать! Так как получится, что либо написанное никому ненужно, либо для тех кому нужно так и не появилась документация!
1️⃣ Сначала договоритесь о терминах.
Никакой документации не будет толку, если внутри команды все понимают слова по-разному. На днях столкнулась с ситуацией, когда для меня "зонтик" = кросс-командный проект, для коллеги — кобренд с внешним партнером.
2️⃣ Определите продукт и его границы.
О чем ваш продукт? Кто его потребитель? Это не просто набор фич. Это должен быть четко очерченный набор ценностей, которые продукт приносит.
3️⃣ Поймите, как ваш продукт монетизируется.
Даже если он внутренний (например, платформа), его монетизация — это сокращение затрат других подразделений. Это тоже нужно учитывать.
4️⃣ Решите, нужна ли вам документация наружу.
Если у вас платформа (а уж если не платформа - тем более), подумайте, будете ли вы публиковать документацию (и какую ее часть) для внешних пользователей. Это определяет, как выстроить структуру документов.
5️⃣ Сосредоточьтесь на “бережливой документации”.
Не нужно писать многотомные руководства, которые никто не будет читать. Актуализируйте, если не постоянно, то — регулярно. Разделяйте информацию на уровне: стратегический (общее представление) и тактический (подробные инструкции).
6️⃣ Интегрируйте документацию в процесс работы.
Документация должна быть не только полезной, но и доступной, а также стать частью вашего рабочего процесса! Документы — это артефакты фиксации мыслей, и именно через них можно идеи челенджить, тестировать, да и риски митигировать и нивелировать на этапе документирования приятнее, чем в проде :)
Хорошая документация — это баланс между пустотой и хаосом. Это не только описание текущего состояния, но и инструмент, который помогает новым людям разобраться в проекте, а продукту — развиваться.
А как вы справляетесь с “проклятиями” документации? Какие аксиомы лежат в базисе ваших артефактов? Делитесь опытом, мне будет интересно! 😊
#architecture #project_management
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤4
Привезла мужа в Стамбул 🎉
Спасибо всем за классные идеи подарков на день рождения для мужа! Некоторые из них мы обязательно попробуем воплотить и после праздника.
А в этот раз решили взять мини-отпуск и отправиться в Стамбул. Уже второй день наслаждаемся прелестями местной жизни: неспешные прогулки, толпы торговцев, голодные чайки и красивые виды на Босфор. Больше всего удивили коты которые живут в метро и вероятно никогда не выходили на поверхность и цистерна Феодосия, где древность соединилась с современностью. Тот случай, когда подарок вроде бы мужу, но, кажется, больше мне. Ну, мы, женщины, так умеем. Если знакомо с вас реакция -
😁
Встречать день рождения в новых местах или просто делать этот день ярким уже становится традицией. И за такую возможность я во многом благодарна IT.
Впрочем, с ценами в Стамбуле даже 2 опытным айтишникам не очень комфортно. Все цены в 3 раза выше чем в Сочи😱
Из других минусов — когда отмечаешь ДР за границей, друзья и родные не могут позвонить и поздравить лично. Но, возможно, для кого-то это только плюс?
#выходнойконтент
Спасибо всем за классные идеи подарков на день рождения для мужа! Некоторые из них мы обязательно попробуем воплотить и после праздника.
А в этот раз решили взять мини-отпуск и отправиться в Стамбул. Уже второй день наслаждаемся прелестями местной жизни: неспешные прогулки, толпы торговцев, голодные чайки и красивые виды на Босфор. Больше всего удивили коты которые живут в метро и вероятно никогда не выходили на поверхность и цистерна Феодосия, где древность соединилась с современностью. Тот случай, когда подарок вроде бы мужу, но, кажется, больше мне. Ну, мы, женщины, так умеем. Если знакомо с вас реакция -
😁
Встречать день рождения в новых местах или просто делать этот день ярким уже становится традицией. И за такую возможность я во многом благодарна IT.
Из других минусов — когда отмечаешь ДР за границей, друзья и родные не могут позвонить и поздравить лично. Но, возможно, для кого-то это только плюс?
#выходнойконтент
🔥9😁9👍4❤1
💴Оффер есть, а денег нет: два взгляда на контракты💴
😬 Ситуация, однако😬
Моя подруга несколько месяцев проходила собеседования в одной компании. Наконец, получила заветный оффер и оставалось подписать договор.
Контракт был вычитан крайне внимательно. В процессе обнаружились ссылки на несуществующие пункты и несколько моментов, вызывающих сомнения. Например:
😱 Почему компания может уволить сотрудника за один день, но требует предупреждать об увольнении за 30 дней?
После раздумий компания ответила, что "договор стандартный, все подписывают как есть". Здесь уже подруга решила подумать.
Но работодатель не стал ждать ответа и отозвал оффер, написав:
😱 "Нарушены договоренности выхода. Оффер отзываем. Удачи!"😱
💶 Ситуация, однако 2💶
Кандидат получил оффер, его устраивала зарплата. Но перед подписанием договора он решил пообщаться с коллегами из компании через LinkedIn. В результате, зная информацию об опциональных плюшках, договор удалось дополнить следующими условиями:
🔥фиксированная компенсация ежедневного проезда из другого города в офис (хотя он работает удаленно);
🔥несколько дополнительных дней отпуска за вредность (Неосторожное открытие ноутбука — реальная угроза здоровью. Я проверяла, есть фотки разбитой губы);
🔥оплата обедов в виде фиксированной суммы без предоставления чеков.
Специалист оказался редким на рынке труда, и компания согласилась на все условия. Интересно, что у его коллег таких "плюшек" не было и после.
Что думаете? Стоит ли читать договоры? Может, у вас были похожие случаи?
Мои мысли:
Я, честно, раньше не слишком внимательно читала договоры. Если не было вопросов — подписывала. Теперь понимаю, что это было ошибкой.
Обе истории, на мой взгляд, удачные по-своему:
Компания, которая отзывает оффер после уточняющих вопросов и прописывает возможность увольнения за 1 день, — это явный риск для соискателя. Такие моменты важно сделать прозрачными заранее.
А дополнительные "плюшки" во второй истории только подтверждают: всегда стоит пробовать договариваться.
#КарьеравИТ #юридическое
Моя подруга несколько месяцев проходила собеседования в одной компании. Наконец, получила заветный оффер и оставалось подписать договор.
Контракт был вычитан крайне внимательно. В процессе обнаружились ссылки на несуществующие пункты и несколько моментов, вызывающих сомнения. Например:
После раздумий компания ответила, что "договор стандартный, все подписывают как есть". Здесь уже подруга решила подумать.
Но работодатель не стал ждать ответа и отозвал оффер, написав:
Кандидат получил оффер, его устраивала зарплата. Но перед подписанием договора он решил пообщаться с коллегами из компании через LinkedIn. В результате, зная информацию об опциональных плюшках, договор удалось дополнить следующими условиями:
🔥фиксированная компенсация ежедневного проезда из другого города в офис (хотя он работает удаленно);
🔥несколько дополнительных дней отпуска за вредность (Неосторожное открытие ноутбука — реальная угроза здоровью. Я проверяла, есть фотки разбитой губы);
🔥оплата обедов в виде фиксированной суммы без предоставления чеков.
Специалист оказался редким на рынке труда, и компания согласилась на все условия. Интересно, что у его коллег таких "плюшек" не было и после.
Что думаете? Стоит ли читать договоры? Может, у вас были похожие случаи?
Мои мысли:
Обе истории, на мой взгляд, удачные по-своему:
Компания, которая отзывает оффер после уточняющих вопросов и прописывает возможность увольнения за 1 день, — это явный риск для соискателя. Такие моменты важно сделать прозрачными заранее.
А дополнительные "плюшки" во второй истории только подтверждают: всегда стоит пробовать договариваться.
#КарьеравИТ #юридическое
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
Как узнать, что пора просить повышение? Уйти в отпуск.
Или я снова пришла поныть.
У меня закончился отпуск.Это уже само по себе печально. За три дня моего отсутствия работа не то чтобы встала, но ряд задач оказался заблокирован.
🤔 Ситуация, однако.
С одной стороны, я такой уникальный, незаменимый специалист, что даже имея к кому обратиться в моё отсутствие, команда без меня не справляется.
З-значимость.
💡 С другой стороны, на этапе регрессионного тестирования команде всё равно приходится обращаться к аналитику. Значит, я не смогла достаточно продумать и качественно донести до команды, что и как должно быть.
П-провал меня как специалиста.
💡 С третьей стороны, это неверно встроенные процессы, отсутствие распространения знаний в команде и уже до неприличия расползающаяся система, разобраться в которой можно только через Людей-Документацию.
П-провал, но уже менеджеров.
И У-успех меня как одного из тех самых I am DOCUMENTATION.
🛑 В реальности – это всё сразу. И уникальность, и провалы, и значимость.
Но для меня это неприятно. Показателем профессионализма мне кажется, когда аналитик делает свою работу так, чтобы результатами могли пользоваться автономно. А отпуск (и выход из него) приятнее, когда не боишься, что в твое отсутствие всё упадёт.
Или у вас совсем другое видение такой ситуации? Как вас встречают после отпусков?
#СистемныйАналитик #РаботаСА #ЯДокументация #ИТРеалии
Или я снова пришла поныть.
У меня закончился отпуск.
С одной стороны, я такой уникальный, незаменимый специалист, что даже имея к кому обратиться в моё отсутствие, команда без меня не справляется.
З-значимость.
💡 С другой стороны, на этапе регрессионного тестирования команде всё равно приходится обращаться к аналитику. Значит, я не смогла достаточно продумать и качественно донести до команды, что и как должно быть.
П-провал меня как специалиста.
💡 С третьей стороны, это неверно встроенные процессы, отсутствие распространения знаний в команде и уже до неприличия расползающаяся система, разобраться в которой можно только через Людей-Документацию.
П-провал, но уже менеджеров.
И У-успех меня как одного из тех самых I am DOCUMENTATION.
🛑 В реальности – это всё сразу. И уникальность, и провалы, и значимость.
Но для меня это неприятно. Показателем профессионализма мне кажется, когда аналитик делает свою работу так, чтобы результатами могли пользоваться автономно. А отпуск (и выход из него) приятнее, когда не боишься, что в твое отсутствие всё упадёт.
Или у вас совсем другое видение такой ситуации? Как вас встречают после отпусков?
#СистемныйАналитик #РаботаСА #ЯДокументация #ИТРеалии
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤3