Как просить повышение?
Дискеймер: Я убежден, что быстрый рост по зп на начальных этапах возможен только через смену компаний. Менять работу нужно каждые 1-1.5 года. Но так делают не все, поэтому и появился этот текст.
Животрепещущий вопрос. Ты классный системный аналитик, проработавший некоторое время в компании. Все здорово, задачки закрываются, бизнес доволен, скилл растет. Но как же правильно попросить повышение? Многие стесняются это делать. Давайте разбираться.
Просить о повышении зп можно всегда и на любую сумму. Просить в целом можно все, что угодно, другой вопрос, согласуют ли. Важно выстраивать диалог. В компании могут быть регламенты, когда повышение проходит в определенное время. Но у каждого правила бывают исключения, и, если вы ценный сотрудник, высока вероятность, что работодатель пойдет на встречу. Я бы задал следующие вопросы: «Как мне повысить доход? Какие практики в компании? На сколько можно увеличить зп?»
Нужно собрать свои достижения. Так разговор станет предметным. Вы, как сотрудник, отлично поработали, и теперь просите за это повышение. Логично? Вполне. Так вы показываете результат и обоснуете, почему просите больше, чем принято.
Принесите оффер из другой компании. Вредный совет, но на моей практике первые два пункта работают не так эффективно, как третий. У компании всегда кризис и всегда не хватает денег. Они будут рассказывать, что вы классный и буквально через полгода сделают вас каким-нибудь начальником, а пока вот 10к прибавки к зп. Оффер из другой компании чудесным образом материализует повышение не «когда-то», а здесь и сейчас. Теряется ли лояльность компании? Думаю да, но вы можете успокоить себя тем, что начали с диалога, а не с козырей. Да и странно говорить о лояльности, когда «любимая компания» не может дать денег по рынку.
В качестве бонуса – если предлагают брать дополнительные обязанности, всегда уточняйте, сколько за это платят? На первой работе для меня было шоком, когда на время отпуска искали замену на проект и взяли коллегу, а он первым делом спросил: «Да, все круто, а это будет дополнительно оплачиваться?» Мы не альтруисты, мы помогаем бизнесу зарабатывать деньги. Вас (аналитика) могут хвалить, навешивать дополнительную нагрузку: интервью, обучение стажеров, проведение тестирования и т.д. Но зачем это делать за бесплатно, если можно получать деньги? В трудовом договоре четко прописаны обязанности, просто так никто не может заставить вас заниматься дополнительной активностью.
Как итог, не стесняйтесь и не бойтесь просить повышение. Это абсолютно нормально. Нет ничего постыдного в том, чтобы хотеть улучшить финансовое положение.
Дискеймер: Я убежден, что быстрый рост по зп на начальных этапах возможен только через смену компаний. Менять работу нужно каждые 1-1.5 года. Но так делают не все, поэтому и появился этот текст.
Животрепещущий вопрос. Ты классный системный аналитик, проработавший некоторое время в компании. Все здорово, задачки закрываются, бизнес доволен, скилл растет. Но как же правильно попросить повышение? Многие стесняются это делать. Давайте разбираться.
Просить о повышении зп можно всегда и на любую сумму. Просить в целом можно все, что угодно, другой вопрос, согласуют ли. Важно выстраивать диалог. В компании могут быть регламенты, когда повышение проходит в определенное время. Но у каждого правила бывают исключения, и, если вы ценный сотрудник, высока вероятность, что работодатель пойдет на встречу. Я бы задал следующие вопросы: «Как мне повысить доход? Какие практики в компании? На сколько можно увеличить зп?»
Нужно собрать свои достижения. Так разговор станет предметным. Вы, как сотрудник, отлично поработали, и теперь просите за это повышение. Логично? Вполне. Так вы показываете результат и обоснуете, почему просите больше, чем принято.
Принесите оффер из другой компании. Вредный совет, но на моей практике первые два пункта работают не так эффективно, как третий. У компании всегда кризис и всегда не хватает денег. Они будут рассказывать, что вы классный и буквально через полгода сделают вас каким-нибудь начальником, а пока вот 10к прибавки к зп. Оффер из другой компании чудесным образом материализует повышение не «когда-то», а здесь и сейчас. Теряется ли лояльность компании? Думаю да, но вы можете успокоить себя тем, что начали с диалога, а не с козырей. Да и странно говорить о лояльности, когда «любимая компания» не может дать денег по рынку.
В качестве бонуса – если предлагают брать дополнительные обязанности, всегда уточняйте, сколько за это платят? На первой работе для меня было шоком, когда на время отпуска искали замену на проект и взяли коллегу, а он первым делом спросил: «Да, все круто, а это будет дополнительно оплачиваться?» Мы не альтруисты, мы помогаем бизнесу зарабатывать деньги. Вас (аналитика) могут хвалить, навешивать дополнительную нагрузку: интервью, обучение стажеров, проведение тестирования и т.д. Но зачем это делать за бесплатно, если можно получать деньги? В трудовом договоре четко прописаны обязанности, просто так никто не может заставить вас заниматься дополнительной активностью.
Как итог, не стесняйтесь и не бойтесь просить повышение. Это абсолютно нормально. Нет ничего постыдного в том, чтобы хотеть улучшить финансовое положение.
👍17🔥3
Портрет участника канала (Не)Системная аналитика
Подводим итоги опроса! Спасибо каждому, кто принял участие в опросе. Некоторые результаты оказались неожиданными. Ловите выжимку ниже, а с полными результатами можете ознакомиться по ссылке
- Почти 46% опрошенных обучались самостоятельно для вката в профессию, 36.5% получили профильное образование;
- 48.7% получили профильное образование, а без образования работают только 9%. Кстати, совсем недавно мы рассуждали о пользе вышки в ИТ, можете заценить тут;
- 52.6% оценивают себя как миддлы. Ожидаемо, но интересно посмотреть на результат в разрезе зарплат Там есть миддлы и за 100 и за 250)
- 40.8% работают 5-6 часов, когда как 10.5% свыше 8 часов;
- 51.3% не перерабатывают (респект!), а 36.8% перерабатывают редко и переработки не оплачиваются (стоит задуматься);
- Почти 15% респондентов меняют работу каждые 3.5-5 лет. Ребята, вы теряете в деньгах;
Денежный вопрос предлагаю заценить самостоятельно в коммьюнити.
Как вам результаты?
Подводим итоги опроса! Спасибо каждому, кто принял участие в опросе. Некоторые результаты оказались неожиданными. Ловите выжимку ниже, а с полными результатами можете ознакомиться по ссылке
- Почти 46% опрошенных обучались самостоятельно для вката в профессию, 36.5% получили профильное образование;
- 48.7% получили профильное образование, а без образования работают только 9%. Кстати, совсем недавно мы рассуждали о пользе вышки в ИТ, можете заценить тут;
- 52.6% оценивают себя как миддлы. Ожидаемо, но интересно посмотреть на результат в разрезе зарплат Там есть миддлы и за 100 и за 250)
- 40.8% работают 5-6 часов, когда как 10.5% свыше 8 часов;
- 51.3% не перерабатывают (респект!), а 36.8% перерабатывают редко и переработки не оплачиваются (стоит задуматься);
- Почти 15% респондентов меняют работу каждые 3.5-5 лет. Ребята, вы теряете в деньгах;
Денежный вопрос предлагаю заценить самостоятельно в коммьюнити.
Как вам результаты?
🔥19⚡3
Итоги года 🎄
Ребята, привет!
В последний рабочий день подводим итоги года. Я никогда не планировал, но в ретроспективе всегда видится, что время потрачено не зря. Большое спасибо всем, кто был рядом и помогал.
В январе мы тусили своей компанией в Ярославле. Культурно-развлекательная программа на несколько дней. Максимум живого общения. Рекомендую всем периодически собираться друзьями и отдыхать.
В феврале начался ремонт. Ремонт…. Сложная штука, приходилось постоянно менеджерить. Крайне нервно, но результат стоил того. Отдельное спасибо родителям за постоянную помощь, без них бы ничего не вышло.
В мае ворвался в менторство. Огромное спасибо всем, кто обратился за помощью и получил то, что хотел. Мне очень приятно читать отзывы и видеть, как вы находите работу и становитесь лучше.
В июне ушел из аспирантуры. Совершенно не жалею об этом. Учился 18 лет без перерыва, кажется на данном этапе этого достаточно.
В июле повысил зп на текущем месте работы через контроффер. Поступил некрасиво, думал, что 100к на ровном месте не накинут. А оказалось, наоборот. Но, задачи на проекте интереснее не стали.
В августе запустил канал, где вы сейчас находитесь. Огромное спасибо всем, кто подписался и читает. Спасибо за реакции и комментарии, спасибо, что участвуете в дискуссиях. Канал и медийка в целом приносят большое удовольствие (и немножко денег), буду продолжать этим заниматься. А еще в августе мы переехали в свою квартиру, там был стол, кровать и ванная. Без мебели и кухни. Сейчас вспоминаем с улыбкой, но тогда было невесело.
В сентябре закончили ремонт. 80% изначального дизайна было реализовано. Остались мелкие доделки, но в целом картина полная. Также в первый раз за пару лет выбрались отдохнуть, я вообще впервые был в Египте, до этого только «наш юг». Шарм с трудом переживает кризисы и выглядит уставшим, но море, солнце, все дела – решает.
В ноябре я сменил работу, где нахожусь сейчас. Совокупный рост дохода с июля по ноябрь составил х2. Активно погружаюсь в процессы, вникаю. Если раньше я копал исключительно бэк, то тут еще и фронтовые задачи.
Как-то так. Сейчас ухожу на зимние каникулы, вернусь уже в январе. Меня можно найти в коммьюнити. Еще раз спасибо всем, кто подписан, вы даете топливо для дальнейшего движения. Пусть в новом году у вас сбудется все, что пожелаете. Добивайтесь карьерных успехов, но не забывайте отдыхать и беречь голову.
Всех обнял,
Андрей
З.Ы. (сейчас олды пустят слезу) Когда-то давно вел канал с рецензиями о кино. Если вдруг соскучитесь, здесь очень много материала, несвязанного с ИТ. Кто знает, может вернусь)
Ребята, привет!
В последний рабочий день подводим итоги года. Я никогда не планировал, но в ретроспективе всегда видится, что время потрачено не зря. Большое спасибо всем, кто был рядом и помогал.
В январе мы тусили своей компанией в Ярославле. Культурно-развлекательная программа на несколько дней. Максимум живого общения. Рекомендую всем периодически собираться друзьями и отдыхать.
В феврале начался ремонт. Ремонт…. Сложная штука, приходилось постоянно менеджерить. Крайне нервно, но результат стоил того. Отдельное спасибо родителям за постоянную помощь, без них бы ничего не вышло.
В мае ворвался в менторство. Огромное спасибо всем, кто обратился за помощью и получил то, что хотел. Мне очень приятно читать отзывы и видеть, как вы находите работу и становитесь лучше.
В июне ушел из аспирантуры. Совершенно не жалею об этом. Учился 18 лет без перерыва, кажется на данном этапе этого достаточно.
В июле повысил зп на текущем месте работы через контроффер. Поступил некрасиво, думал, что 100к на ровном месте не накинут. А оказалось, наоборот. Но, задачи на проекте интереснее не стали.
В августе запустил канал, где вы сейчас находитесь. Огромное спасибо всем, кто подписался и читает. Спасибо за реакции и комментарии, спасибо, что участвуете в дискуссиях. Канал и медийка в целом приносят большое удовольствие (и немножко денег), буду продолжать этим заниматься. А еще в августе мы переехали в свою квартиру, там был стол, кровать и ванная. Без мебели и кухни. Сейчас вспоминаем с улыбкой, но тогда было невесело.
В сентябре закончили ремонт. 80% изначального дизайна было реализовано. Остались мелкие доделки, но в целом картина полная. Также в первый раз за пару лет выбрались отдохнуть, я вообще впервые был в Египте, до этого только «наш юг». Шарм с трудом переживает кризисы и выглядит уставшим, но море, солнце, все дела – решает.
В ноябре я сменил работу, где нахожусь сейчас. Совокупный рост дохода с июля по ноябрь составил х2. Активно погружаюсь в процессы, вникаю. Если раньше я копал исключительно бэк, то тут еще и фронтовые задачи.
Как-то так. Сейчас ухожу на зимние каникулы, вернусь уже в январе. Меня можно найти в коммьюнити. Еще раз спасибо всем, кто подписан, вы даете топливо для дальнейшего движения. Пусть в новом году у вас сбудется все, что пожелаете. Добивайтесь карьерных успехов, но не забывайте отдыхать и беречь голову.
Всех обнял,
Андрей
З.Ы. (сейчас олды пустят слезу) Когда-то давно вел канал с рецензиями о кино. Если вдруг соскучитесь, здесь очень много материала, несвязанного с ИТ. Кто знает, может вернусь)
🔥17👍4❤3🎄1
6 архитектурных паттернов, которые ты должен знать
Event-Driven Architecture:
EDA фокусируется на производстве, обнаружении, потреблении и реакции на события. Компоненты в этой архитектуре взаимодействуют асинхронно через события. Когда происходит событие, оно запускает действия или уведомления по всей системе. Этот паттерн повышает масштабируемость, разделяет компоненты и позволяет реагировать на события в режиме реального времени.
Применение: Идеально подходит для систем, в которых события вызывают действия, способствуя масштабируемости и быстроте реакции.
Layered Architecture:
Многослойная архитектура организует систему на логические уровни, каждый из которых отвечает за определенную функциональность. Как правило, эти слои включают в себя представление, логику приложения, бизнес-правила и доступ к данным. Такое разделение обеспечивает модульность, способствует удобству обслуживания и упрощает обновление или изменение отдельных слоев, не затрагивая другие.
Применение: Распространена в корпоративных приложениях, повышает отказоустойчивость за счет разделения и модульной разработки.
Monolithic Architecture:
В монолитной архитектуре все приложение разрабатывается и развертывается как единое целое. Все компоненты взаимосвязаны и взаимозависимы, используют одну и ту же кодовую базу и ресурсы. Несмотря на простоту разработки на начальном этапе, масштабирование и поддержка монолитных приложений могут стать сложной задачей по мере их роста.
Применение: Подходит для небольших приложений или экземпляров, ориентированных на простоту. Упрощает разработку и развертывание с потенциальными проблемами масштабирования.
Microservices Architecture:
Микросервисы разбивают приложение на более мелкие, независимые сервисы, каждый из которых отвечает за определенные функции. Эти сервисы взаимодействуют через API и могут разрабатываться, развертываться и масштабироваться независимо друг от друга. Микросервисы способствуют гибкости, масштабируемости и позволяют командам одновременно работать над разными сервисами.
Применение: Идеально подходит для больших и сложных систем, улучшая масштабируемость, изоляцию от сбоев и позволяя разрабатывать независимые сервисы.
Model-View-Controller (MVC):
MVC разделяет приложение на три взаимосвязанных компонента: Модель (представление данных), Вид (пользовательский интерфейс) и Контроллер (бизнес-логика). Этот паттерн повышает удобство сопровождения, позволяет вести параллельную разработку и способствует четкому разделению задач.
Приложение: Распространена в веб-приложениях, улучшает организацию и сопровождение кода за счет разделения сложной логики пользовательского интерфейса.
Master-Slave Architecture:
В этой схеме ведущий узел управляет одним или несколькими ведомыми узлами. Ведущий распределяет задачи или процессы между ведомыми узлами, которые выполняют поставленные задачи и отчитываются перед ведущим узлом. Эта схема повышает отказоустойчивость, масштабируемость и производительность за счет распределения рабочей нагрузки между несколькими узлами.
Применение: Повсеместно используется в распределенных вычислениях, оптимизируя параллельную обработку и балансировку нагрузки.
Графический материал прикрепил в комментариях.
Какие недостатки того или инного паттерна можете назвать?
Event-Driven Architecture:
EDA фокусируется на производстве, обнаружении, потреблении и реакции на события. Компоненты в этой архитектуре взаимодействуют асинхронно через события. Когда происходит событие, оно запускает действия или уведомления по всей системе. Этот паттерн повышает масштабируемость, разделяет компоненты и позволяет реагировать на события в режиме реального времени.
Применение: Идеально подходит для систем, в которых события вызывают действия, способствуя масштабируемости и быстроте реакции.
Layered Architecture:
Многослойная архитектура организует систему на логические уровни, каждый из которых отвечает за определенную функциональность. Как правило, эти слои включают в себя представление, логику приложения, бизнес-правила и доступ к данным. Такое разделение обеспечивает модульность, способствует удобству обслуживания и упрощает обновление или изменение отдельных слоев, не затрагивая другие.
Применение: Распространена в корпоративных приложениях, повышает отказоустойчивость за счет разделения и модульной разработки.
Monolithic Architecture:
В монолитной архитектуре все приложение разрабатывается и развертывается как единое целое. Все компоненты взаимосвязаны и взаимозависимы, используют одну и ту же кодовую базу и ресурсы. Несмотря на простоту разработки на начальном этапе, масштабирование и поддержка монолитных приложений могут стать сложной задачей по мере их роста.
Применение: Подходит для небольших приложений или экземпляров, ориентированных на простоту. Упрощает разработку и развертывание с потенциальными проблемами масштабирования.
Microservices Architecture:
Микросервисы разбивают приложение на более мелкие, независимые сервисы, каждый из которых отвечает за определенные функции. Эти сервисы взаимодействуют через API и могут разрабатываться, развертываться и масштабироваться независимо друг от друга. Микросервисы способствуют гибкости, масштабируемости и позволяют командам одновременно работать над разными сервисами.
Применение: Идеально подходит для больших и сложных систем, улучшая масштабируемость, изоляцию от сбоев и позволяя разрабатывать независимые сервисы.
Model-View-Controller (MVC):
MVC разделяет приложение на три взаимосвязанных компонента: Модель (представление данных), Вид (пользовательский интерфейс) и Контроллер (бизнес-логика). Этот паттерн повышает удобство сопровождения, позволяет вести параллельную разработку и способствует четкому разделению задач.
Приложение: Распространена в веб-приложениях, улучшает организацию и сопровождение кода за счет разделения сложной логики пользовательского интерфейса.
Master-Slave Architecture:
В этой схеме ведущий узел управляет одним или несколькими ведомыми узлами. Ведущий распределяет задачи или процессы между ведомыми узлами, которые выполняют поставленные задачи и отчитываются перед ведущим узлом. Эта схема повышает отказоустойчивость, масштабируемость и производительность за счет распределения рабочей нагрузки между несколькими узлами.
Применение: Повсеместно используется в распределенных вычислениях, оптимизируя параллельную обработку и балансировку нагрузки.
Графический материал прикрепил в комментариях.
Какие недостатки того или инного паттерна можете назвать?
🔥15👍1
Сравнение архитектурных паттернов
Это продолжение статьи, выходившей вчера. Сначала рекомендую ознакомиться с ней.
Давайте сравним описанные паттерны по нескольким критериям: Масштабируемость, Удобство обслуживания, Гибкость, Сложность.
Масштабируемость:
EDA: Высокая масштабируемость благодаря своей асинхронной природе. Может обрабатывать большое количество событий одновременно.
Layered Architecture: Масштабируемость может быть ограничена, так как масштабирование отдельных слоев может быть затруднено независимо друг от друга.
Monolithic Architecture: Масштабирование может быть сложным, так как необходимо реплицировать все приложение.
Microservices Architecture: Обеспечивает отличную масштабируемость за счет независимого масштабирования сервисов в зависимости от спроса.
Master-Slave Architecture: Масштабируемость зависит от распределения задач между ведомыми и возможностей ведущего узла.
Удобство обслуживания:
EDA: Разрозненные компоненты облегчают обслуживание и обновление конкретных функций.
Layered Architecture: Способствует удобству обслуживания за счет разделения проблем, но может создавать зависимости между слоями.
Monolithic Architecture: Может быть сложной в обслуживании, так как изменения могут повлиять на всю систему.
Microservices Architecture: Легче поддерживать благодаря независимым сервисам, но управление несколькими сервисами требует эффективной координации.
Master-Slave Architecture: Сопровождение проще, поскольку каждый ведомый может управляться независимо, но работоспособность всей системы зависит от ведущего.
Гибкость:
EDA: Очень гибкая благодаря своей слабосвязанной природе, позволяющей легко добавлять или изменять компоненты.
Layered Architecture: Обеспечивает умеренную гибкость, но для определенных модификаций может потребовать изменения нескольких слоев.
Monolithic Architecture: Менее гибкая, поскольку изменения могут повлиять на всю систему.
Microservices Architecture: Обеспечивает высокую гибкость, поскольку отдельные сервисы могут быть изменены, обновлены или заменены, не затрагивая другие.
Master-Slave Architecture: Гибкость ограничена структурой, в которой ведомые зависят от указаний ведущего.
Сложность:
EDA: Умеренно сложная из-за управления асинхронными событиями и обеспечения согласованности событий.
Layered Architecture: Умеренная сложность, но может стать сложной, если плохо управлять зависимостями между слоями.
Monolithic Architecture: Проще в разработке на начальном этапе, но может стать сложной в управлении и масштабировании по мере роста.
Microservices Architecture: Может быть сложной в настройке и управлении из-за распределенной природы и межсервисного взаимодействия.
Master-Slave Architecture: Умеренная сложность в управлении отношениями "ведущий-ведомый" и обеспечении синхронизации.
Каждый архитектурный паттерн имеет свои компромиссы и подходит для различных сценариев в зависимости от таких факторов, как размер приложения, потребности в масштабируемости, структура команды и ожидаемые изменения с течением времени. Выбор правильного паттерна часто включает в себя рассмотрение этих аспектов в соответствии с требованиями проекта.
Это продолжение статьи, выходившей вчера. Сначала рекомендую ознакомиться с ней.
Давайте сравним описанные паттерны по нескольким критериям: Масштабируемость, Удобство обслуживания, Гибкость, Сложность.
Масштабируемость:
EDA: Высокая масштабируемость благодаря своей асинхронной природе. Может обрабатывать большое количество событий одновременно.
Layered Architecture: Масштабируемость может быть ограничена, так как масштабирование отдельных слоев может быть затруднено независимо друг от друга.
Monolithic Architecture: Масштабирование может быть сложным, так как необходимо реплицировать все приложение.
Microservices Architecture: Обеспечивает отличную масштабируемость за счет независимого масштабирования сервисов в зависимости от спроса.
Master-Slave Architecture: Масштабируемость зависит от распределения задач между ведомыми и возможностей ведущего узла.
Удобство обслуживания:
EDA: Разрозненные компоненты облегчают обслуживание и обновление конкретных функций.
Layered Architecture: Способствует удобству обслуживания за счет разделения проблем, но может создавать зависимости между слоями.
Monolithic Architecture: Может быть сложной в обслуживании, так как изменения могут повлиять на всю систему.
Microservices Architecture: Легче поддерживать благодаря независимым сервисам, но управление несколькими сервисами требует эффективной координации.
Master-Slave Architecture: Сопровождение проще, поскольку каждый ведомый может управляться независимо, но работоспособность всей системы зависит от ведущего.
Гибкость:
EDA: Очень гибкая благодаря своей слабосвязанной природе, позволяющей легко добавлять или изменять компоненты.
Layered Architecture: Обеспечивает умеренную гибкость, но для определенных модификаций может потребовать изменения нескольких слоев.
Monolithic Architecture: Менее гибкая, поскольку изменения могут повлиять на всю систему.
Microservices Architecture: Обеспечивает высокую гибкость, поскольку отдельные сервисы могут быть изменены, обновлены или заменены, не затрагивая другие.
Master-Slave Architecture: Гибкость ограничена структурой, в которой ведомые зависят от указаний ведущего.
Сложность:
EDA: Умеренно сложная из-за управления асинхронными событиями и обеспечения согласованности событий.
Layered Architecture: Умеренная сложность, но может стать сложной, если плохо управлять зависимостями между слоями.
Monolithic Architecture: Проще в разработке на начальном этапе, но может стать сложной в управлении и масштабировании по мере роста.
Microservices Architecture: Может быть сложной в настройке и управлении из-за распределенной природы и межсервисного взаимодействия.
Master-Slave Architecture: Умеренная сложность в управлении отношениями "ведущий-ведомый" и обеспечении синхронизации.
Каждый архитектурный паттерн имеет свои компромиссы и подходит для различных сценариев в зависимости от таких факторов, как размер приложения, потребности в масштабируемости, структура команды и ожидаемые изменения с течением времени. Выбор правильного паттерна часто включает в себя рассмотрение этих аспектов в соответствии с требованиями проекта.
🔥7
Channel name was changed to «(Не)Системная аналитика by Андрей Царев»
Как вы попали в професию
Ребята, салют!
Давайте немного пообщаемся. Очень интересно, чтобы вы рассказали:
1) Почему выбрали бизнес/системный анализ?
2) Какие плюсы/минусы видите?
3) Куда думаете развиваться дальше?
Начну с себя:
1) Обучался в ВУЗе, верхнеуровнево объяснили, чем занимаются аналитики - понравилось. Плюс спрашивал у знакомых, которые рассказывали, что тут много "творческой работы". В процесс доучился из бизнес аналитика в системного
2) Плюсы: платят, как разрабам; востребовано в РФ; в процессе качаешь скиллы архитектора; относительно низкий порог входа;
Минусы: много коммуникации с людьми (для кого-то может быть плюсом); не востребовано вне РФ; от компании к компании обязанности сильно разнятся
3) Для себя вижу путь архитектора. Хочется больше качаться в технических задачах, чем в бизнесовых.
Ребята, салют!
Давайте немного пообщаемся. Очень интересно, чтобы вы рассказали:
1) Почему выбрали бизнес/системный анализ?
2) Какие плюсы/минусы видите?
3) Куда думаете развиваться дальше?
Начну с себя:
1) Обучался в ВУЗе, верхнеуровнево объяснили, чем занимаются аналитики - понравилось. Плюс спрашивал у знакомых, которые рассказывали, что тут много "творческой работы". В процесс доучился из бизнес аналитика в системного
2) Плюсы: платят, как разрабам; востребовано в РФ; в процессе качаешь скиллы архитектора; относительно низкий порог входа;
Минусы: много коммуникации с людьми (для кого-то может быть плюсом); не востребовано вне РФ; от компании к компании обязанности сильно разнятся
3) Для себя вижу путь архитектора. Хочется больше качаться в технических задачах, чем в бизнесовых.
👍19
Сравнение Kafka и RabbitMQ
RabbitMQ
- Обзор: RabbitMQ, надежный и проверенный брокер сообщений, работает на основе протокола Advanced Message Queuing Protocol (AMQP). Уделяя особое внимание гибкости и простоте использования, RabbitMQ хорошо подходит для сценариев, требующих связи в реальном времени, распределения задач и архитектуры, ориентированной на события.
- Сильные стороны: универсальность в поддержке различных шаблонов обмена сообщениями, надежная доставка сообщений.
- Примеры использования: Идеально подходит для приложений, требующих совместной работы в реальном времени, распределения задач, а также для тех, где важен гибкий механизм маршрутизации сообщений.
Kafka
- Обзор: Kafka, платформа для потоковой передачи событий, отлично справляется с высокопроизводительными, отказоустойчивыми и горизонтально масштабируемыми потоками данных. Построенная на принципах распределенных журналов фиксации, Kafka рассчитана на долговечность, отказоустойчивость и масштабируемость.
- Сильные стороны: постоянное и отказоустойчивое хранение данных, эффективная обработка потоков.
- Примеры использования: Лучше всего подходит для сценариев, требующих аналитики в реальном времени, агрегации журналов, поиска событий и создания приложений с большим объемом данных.
Сравнение:
- Масштабируемость: Распределенная архитектура Kafka делает ее горизонтально масштабируемой, что позволяет легко справляться с растущими объемами данных. RabbitMQ, хотя и масштабируется, может потребовать дополнительных конфигураций для оптимального масштабирования.
- Долговечность: Долговечная и отказоустойчивая конструкция Kafka обеспечивает целостность данных даже в условиях сбоев. RabbitMQ обеспечивает надежную доставку, но может потребовать дополнительных настроек для обеспечения долговечности.
- Шаблоны обмена сообщениями: RabbitMQ поддерживает различные схемы обмена сообщениями, включая pub-sub и request-reply. Kafka, ориентированная на потоковую передачу событий, лучше справляется со сценариями, по принципу pub-sub, а также логгированию.
RabbitMQ
- Обзор: RabbitMQ, надежный и проверенный брокер сообщений, работает на основе протокола Advanced Message Queuing Protocol (AMQP). Уделяя особое внимание гибкости и простоте использования, RabbitMQ хорошо подходит для сценариев, требующих связи в реальном времени, распределения задач и архитектуры, ориентированной на события.
- Сильные стороны: универсальность в поддержке различных шаблонов обмена сообщениями, надежная доставка сообщений.
- Примеры использования: Идеально подходит для приложений, требующих совместной работы в реальном времени, распределения задач, а также для тех, где важен гибкий механизм маршрутизации сообщений.
Kafka
- Обзор: Kafka, платформа для потоковой передачи событий, отлично справляется с высокопроизводительными, отказоустойчивыми и горизонтально масштабируемыми потоками данных. Построенная на принципах распределенных журналов фиксации, Kafka рассчитана на долговечность, отказоустойчивость и масштабируемость.
- Сильные стороны: постоянное и отказоустойчивое хранение данных, эффективная обработка потоков.
- Примеры использования: Лучше всего подходит для сценариев, требующих аналитики в реальном времени, агрегации журналов, поиска событий и создания приложений с большим объемом данных.
Сравнение:
- Масштабируемость: Распределенная архитектура Kafka делает ее горизонтально масштабируемой, что позволяет легко справляться с растущими объемами данных. RabbitMQ, хотя и масштабируется, может потребовать дополнительных конфигураций для оптимального масштабирования.
- Долговечность: Долговечная и отказоустойчивая конструкция Kafka обеспечивает целостность данных даже в условиях сбоев. RabbitMQ обеспечивает надежную доставку, но может потребовать дополнительных настроек для обеспечения долговечности.
- Шаблоны обмена сообщениями: RabbitMQ поддерживает различные схемы обмена сообщениями, включая pub-sub и request-reply. Kafka, ориентированная на потоковую передачу событий, лучше справляется со сценариями, по принципу pub-sub, а также логгированию.
🔥15👍1
4 года в ИТ, что я понял за это время
Казалось бы, только вчера вкатился в «айтишку», а уже прошло четыре года. В контексте жизни – это ничто, но для понимания профессии и достижения некоторых результатов – достаточно. Все ли так круто, как казалось в начале? Я построил статью по принципу «плюс-минус». Давайте разбираться.
ИТ – наиболее простой путь к заработку и обретению финансовой независимости. Это правда, за пару лет можно кратно увеличить зп и позволять себе больше, чем ты мог даже подумать. За 4 года мой доход с работы вырос в 10 раз! Покажите мне еще сферу, где такое возможно.
Работники в ИТ подвержены «выгоранию». Это работа с высокой нагрузкой на психику. Ты постоянно думаешь головой, решаешь задачи, развиваешься и впихиваешь в себя новое. Диссонанс случается, когда оказывается, что в рабочих процессах нужно 10% от того, что ты знаешь. А ключ к повышению дохода – это не объем знаний, а умение грамотно себя продать. Из-за того, что первичные потребности закрыты, возникают вопросы: «А что делать дальше?» Когда ты всю жизнь видел, как старшие жили и постоянно копили: на ремонт, на новую квартиру, на отдых, а ты можешь закрыть эти потребности не напрягаясь. Круто? Безусловно. Но вот представь, ты сделал ремонт, купил себе новые девайсы, заказал доставку и клининг. А что дальше?
Системный анализ – одна из востребованных и оплачиваемых специальностей в РФ на данный момент. Аналитиков не хватает, компании постоянно пишут, а для новичков проводятся стажировки. Порог входа здесь не такой высокий, как в программировании, а уровень зп соразмерен. Работая аналитиком, ты не только углубляешься в ИТ, но и изучаешь бизнес. Плюс, получаешь компетенции архитектора, которые пригодятся в дальнейшем.
С другой стороны, обязанности аналитика могут сильно разниться от компании к компании. Где-то ты можешь только писать требования, а где-то подрабатывать РП на пол ставки. Плюсом, легко поймать «синдром фронтендера», когда кажется, что у других специальностей работа важнее. Ведь ты не пишешь код. Хватаешь немного от бизнеса, немного от разработчиков, пишешь спеку и не факт, что будет сделано так, как описал ты. А эти бесконечные звонки и встречи….
Социальный пакет ИТшника поражает. Тут тебе и удаленка, печеньки в офисе, гибкое начало рабочего дня, отпуск, когда захочется, конференции, митапы, планы развития и далее по списку. Все прыгают вокруг тебя, платят огромные деньги, лишь бы ты работал. Компании реально дорожат специалистами и ситуация, когда можно остаться на улице, практически нереальна.
Но боевые задачи не всегда удовлетворяют желаниям. Круто, когда твоя работа приносит пользу бизнесу. Когда фичи доезжают в прод. Но часто бывает, что ты несколько месяцев работаешь: собираешь требования, пишешь документацию, а в итоге задача не доезжает в прод. Либо доезжает, но функционалом никто не пользуется. Просто так получилось, ты не виноват, поменялись приоритеты. Осознание работы в стол – удручает.
Что вы думаете по теме? Какие откровения открылись, спустя некоторое время?
Казалось бы, только вчера вкатился в «айтишку», а уже прошло четыре года. В контексте жизни – это ничто, но для понимания профессии и достижения некоторых результатов – достаточно. Все ли так круто, как казалось в начале? Я построил статью по принципу «плюс-минус». Давайте разбираться.
ИТ – наиболее простой путь к заработку и обретению финансовой независимости. Это правда, за пару лет можно кратно увеличить зп и позволять себе больше, чем ты мог даже подумать. За 4 года мой доход с работы вырос в 10 раз! Покажите мне еще сферу, где такое возможно.
Работники в ИТ подвержены «выгоранию». Это работа с высокой нагрузкой на психику. Ты постоянно думаешь головой, решаешь задачи, развиваешься и впихиваешь в себя новое. Диссонанс случается, когда оказывается, что в рабочих процессах нужно 10% от того, что ты знаешь. А ключ к повышению дохода – это не объем знаний, а умение грамотно себя продать. Из-за того, что первичные потребности закрыты, возникают вопросы: «А что делать дальше?» Когда ты всю жизнь видел, как старшие жили и постоянно копили: на ремонт, на новую квартиру, на отдых, а ты можешь закрыть эти потребности не напрягаясь. Круто? Безусловно. Но вот представь, ты сделал ремонт, купил себе новые девайсы, заказал доставку и клининг. А что дальше?
Системный анализ – одна из востребованных и оплачиваемых специальностей в РФ на данный момент. Аналитиков не хватает, компании постоянно пишут, а для новичков проводятся стажировки. Порог входа здесь не такой высокий, как в программировании, а уровень зп соразмерен. Работая аналитиком, ты не только углубляешься в ИТ, но и изучаешь бизнес. Плюс, получаешь компетенции архитектора, которые пригодятся в дальнейшем.
С другой стороны, обязанности аналитика могут сильно разниться от компании к компании. Где-то ты можешь только писать требования, а где-то подрабатывать РП на пол ставки. Плюсом, легко поймать «синдром фронтендера», когда кажется, что у других специальностей работа важнее. Ведь ты не пишешь код. Хватаешь немного от бизнеса, немного от разработчиков, пишешь спеку и не факт, что будет сделано так, как описал ты. А эти бесконечные звонки и встречи….
Социальный пакет ИТшника поражает. Тут тебе и удаленка, печеньки в офисе, гибкое начало рабочего дня, отпуск, когда захочется, конференции, митапы, планы развития и далее по списку. Все прыгают вокруг тебя, платят огромные деньги, лишь бы ты работал. Компании реально дорожат специалистами и ситуация, когда можно остаться на улице, практически нереальна.
Но боевые задачи не всегда удовлетворяют желаниям. Круто, когда твоя работа приносит пользу бизнесу. Когда фичи доезжают в прод. Но часто бывает, что ты несколько месяцев работаешь: собираешь требования, пишешь документацию, а в итоге задача не доезжает в прод. Либо доезжает, но функционалом никто не пользуется. Просто так получилось, ты не виноват, поменялись приоритеты. Осознание работы в стол – удручает.
Что вы думаете по теме? Какие откровения открылись, спустя некоторое время?
🔥31❤11👍1
Притеснение в ИТ
Ребята, салют!
Предлагаю немного пообщаться.
На одной из консультаций меня спросили: «Встречается ли в ИТ эйджизм?»
Я замешкался, ведь лично не встречался ни с какими притеснениями. Ко мне всегда относились с уважением, как и я к другим. С одной стороны, в ИТ высокая корпоративная культура, все понимают серьезность и ответственность профессии. Но с другой, если бы все складывалось гладко, то историй, вроде этой или этой не было бы.
А как у вас? Приходилось ли сталкиваться с любыми видами ущемлений (сексизм, эйджизм, расизм и т.д.)? Как боролись с этим? Какие выводы сделали для себя?
Ребята, салют!
Предлагаю немного пообщаться.
На одной из консультаций меня спросили: «Встречается ли в ИТ эйджизм?»
Я замешкался, ведь лично не встречался ни с какими притеснениями. Ко мне всегда относились с уважением, как и я к другим. С одной стороны, в ИТ высокая корпоративная культура, все понимают серьезность и ответственность профессии. Но с другой, если бы все складывалось гладко, то историй, вроде этой или этой не было бы.
А как у вас? Приходилось ли сталкиваться с любыми видами ущемлений (сексизм, эйджизм, расизм и т.д.)? Как боролись с этим? Какие выводы сделали для себя?
🌭7👍1
Как работает Single Sign-On (SSO)?
Определение
Single Sign-On - это процесс аутентификации, который позволяет пользователю получить доступ к нескольким приложениям с помощью одного набора учетных данных. Повышает удобство пользователей, снижает утомляемость от ввода паролей и упрощает доступ к различным платформам.
Как работает SSO
1. Аутентификация: Пользователи входят в систему один раз, используя свои учетные данные.
2. Выдача токена: После успешной аутентификации генерируется токен.
3. Проверка токена: Токен проверяется участвующими приложениями для последующего доступа.
Плюсы SSO
1. Удобство: Пользователи получают доступ к нескольким приложениям с помощью одного логина, что избавляет их от необходимости запоминать несколько паролей.
2. Безопасность: Централизованная аутентификация улучшает контроль, видимость и соблюдение политик безопасности.
3. Производительность: Упорядоченный доступ повышает эффективность и сокращает время, затрачиваемое на процессы аутентификации.
Типы SSO
Корпоративный SSO (ESSO): Доступ к приложениям в корпоративной сети.
Web SSO: доступ к веб-приложениям с использованием единого логина.
SSO протоколы
1. SAML (Security Assertion Markup Language): Стандарт на основе XML для обмена данными аутентификации и авторизации.
2. OAuth (Open Authorization): Протокол для безопасного, делегированного доступа к ресурсам.
3. OpenID Connect: Уровень идентификации поверх OAuth 2.0, облегчающий аутентификацию пользователей.
Примеры SSO
1) Google Sign-In
2) Apple SSO
3) VK SSO
Подробнее
Определение
Single Sign-On - это процесс аутентификации, который позволяет пользователю получить доступ к нескольким приложениям с помощью одного набора учетных данных. Повышает удобство пользователей, снижает утомляемость от ввода паролей и упрощает доступ к различным платформам.
Как работает SSO
1. Аутентификация: Пользователи входят в систему один раз, используя свои учетные данные.
2. Выдача токена: После успешной аутентификации генерируется токен.
3. Проверка токена: Токен проверяется участвующими приложениями для последующего доступа.
Плюсы SSO
1. Удобство: Пользователи получают доступ к нескольким приложениям с помощью одного логина, что избавляет их от необходимости запоминать несколько паролей.
2. Безопасность: Централизованная аутентификация улучшает контроль, видимость и соблюдение политик безопасности.
3. Производительность: Упорядоченный доступ повышает эффективность и сокращает время, затрачиваемое на процессы аутентификации.
Типы SSO
Корпоративный SSO (ESSO): Доступ к приложениям в корпоративной сети.
Web SSO: доступ к веб-приложениям с использованием единого логина.
SSO протоколы
1. SAML (Security Assertion Markup Language): Стандарт на основе XML для обмена данными аутентификации и авторизации.
2. OAuth (Open Authorization): Протокол для безопасного, делегированного доступа к ресурсам.
3. OpenID Connect: Уровень идентификации поверх OAuth 2.0, облегчающий аутентификацию пользователей.
Примеры SSO
1) Google Sign-In
2) Apple SSO
3) VK SSO
Подробнее
👍9❤6👎2
Документация как код
На прошлой работе внедрили офигенную практику – вести документацию как код (docs as a code). Перед нами стояла задача перетащить всю доку из Confluence в Git, сделав удобно всем. Спойлер, получилось не совсем гладко, но давайте по порядку.
Я работал в команде интеграций на бэке. Мы пилили интеграционные адаптеры с различными банками и МФО. Процесс выглядел так: адаптер слушает определенную очередь, получает сообщение, преобразовывает его и отправляет вовне. В рамках адаптера содержится несколько методов, от одного до нескольких десятков. Это чисто техническая история, мы не взаимодействовали с фронтом и не описывали его.
Ситуация “As-Is”. Под каждый адаптер есть статья в Confluence, где пошагово расписан процесс: какую очередь слушаем, куда отправляем результат, в какую очередь складываем ответ, пример/описание входящего/исходящего сообщения, и другая техническая информация. Если методов было много, то прикладывали ссылку на draw.io с Sequence Diagram.
Что же получилось? Для текстового описания выбрали AsciiDoc. У него понятный синтаксис, а главное, он корректно отображается в Confluence. Для того, чтобы не делать двойную работу, вся документация велась в Git, а в Confluence указывались ссылки на репозитории.
Помимо AsciiDoc стали использовать PlantUML. Он сильно ускорил процесс «отрисовки» диаграмм, ведь теперь аналитик работает с текстом, а графическое расположение формируется автоматически. Плюс, для каждого метода стали моделировать Class Diagram. В перспективе из них разработчики могли бы генерировать классы.
Наконец, шлифанули это все OpenAPI. Ранее аналитик прописывал параметры и ограничения запроса, а разработчик дублировал эту работу в коде. OpenAPI позволял делать это один раз – аналитик формирует спеку, а разработчик из нее генерирует код. Искренне не понимаю, почему всю доку API не делают именно в формате OpenAPI, ведь это наглядный и понятный стандарт.
В идеальной картине мы видели следующие плюсы:
- Всегда актуальная документация. Ведь она изменяется только вместе с кодом.
- Ускоренная разработка. Ведь часть работы уже выполнил аналитик.
- Прокаченные аналитики. Ведь им нужно освоить несколько новых инструментов.
Реальность оказалось суровее. После ухода тимлида (мощнейший эксперт, безумно рад, что нам удалось поработать вместе) инициативу стало почти невозможно толкать. В работе использовалось только Ascii описание, а Puml и Swagger никто не использовал. Соседние команды смотрели на нас как на сумасшедших – «ведь аналитикам придется делать столько дополнительной работы». А бизнес говнялся, ведь им было неудобно смотреть рендеринг репозиториев Git в Confluence.
По итогу, из запланированного взлетела только часть. Несмотря на это, каждый раз, когда я говорил на собеседованиях, что веду документацию в Git, в ответ получал только «мое почтение».
А как обстоят дела с докой на работе у вас?
На прошлой работе внедрили офигенную практику – вести документацию как код (docs as a code). Перед нами стояла задача перетащить всю доку из Confluence в Git, сделав удобно всем. Спойлер, получилось не совсем гладко, но давайте по порядку.
Я работал в команде интеграций на бэке. Мы пилили интеграционные адаптеры с различными банками и МФО. Процесс выглядел так: адаптер слушает определенную очередь, получает сообщение, преобразовывает его и отправляет вовне. В рамках адаптера содержится несколько методов, от одного до нескольких десятков. Это чисто техническая история, мы не взаимодействовали с фронтом и не описывали его.
Ситуация “As-Is”. Под каждый адаптер есть статья в Confluence, где пошагово расписан процесс: какую очередь слушаем, куда отправляем результат, в какую очередь складываем ответ, пример/описание входящего/исходящего сообщения, и другая техническая информация. Если методов было много, то прикладывали ссылку на draw.io с Sequence Diagram.
Что же получилось? Для текстового описания выбрали AsciiDoc. У него понятный синтаксис, а главное, он корректно отображается в Confluence. Для того, чтобы не делать двойную работу, вся документация велась в Git, а в Confluence указывались ссылки на репозитории.
Помимо AsciiDoc стали использовать PlantUML. Он сильно ускорил процесс «отрисовки» диаграмм, ведь теперь аналитик работает с текстом, а графическое расположение формируется автоматически. Плюс, для каждого метода стали моделировать Class Diagram. В перспективе из них разработчики могли бы генерировать классы.
Наконец, шлифанули это все OpenAPI. Ранее аналитик прописывал параметры и ограничения запроса, а разработчик дублировал эту работу в коде. OpenAPI позволял делать это один раз – аналитик формирует спеку, а разработчик из нее генерирует код. Искренне не понимаю, почему всю доку API не делают именно в формате OpenAPI, ведь это наглядный и понятный стандарт.
В идеальной картине мы видели следующие плюсы:
- Всегда актуальная документация. Ведь она изменяется только вместе с кодом.
- Ускоренная разработка. Ведь часть работы уже выполнил аналитик.
- Прокаченные аналитики. Ведь им нужно освоить несколько новых инструментов.
Реальность оказалось суровее. После ухода тимлида (мощнейший эксперт, безумно рад, что нам удалось поработать вместе) инициативу стало почти невозможно толкать. В работе использовалось только Ascii описание, а Puml и Swagger никто не использовал. Соседние команды смотрели на нас как на сумасшедших – «ведь аналитикам придется делать столько дополнительной работы». А бизнес говнялся, ведь им было неудобно смотреть рендеринг репозиториев Git в Confluence.
По итогу, из запланированного взлетела только часть. Несмотря на это, каждый раз, когда я говорил на собеседованиях, что веду документацию в Git, в ответ получал только «мое почтение».
А как обстоят дела с докой на работе у вас?
❤12👍4