Роль аналитика в запуске проекта
Setup проекта – это все, что делается на старте проекта, включая фундаментальные вещи и не очень. Ошибки, допущенные на старте проекта, могут влиять на работу команды в течение всей жизни проекта. В этом посте я попробовал собрать основные рекомендации.
Во-первых, надо разобраться в имеющемся контексте и артефактах. Согласованный с заказчиком список задач, которые будем делать в рамках проекта, должен точно соответствовать ожиданиям, описанным в техническом задании (ТЗ) и представленным в дизайне (уже готовом или пока только в концепции). Если возникают какие-то расхождения, важно сразу сообщить об этом менеджеру.
Во-вторых, очень важно владеть максимумом контекста. На старте проекта, у всех вопросов больше, чем ответов, проводится большое количество встреч, на которых принимаются важные для проекта решения. Аналитик должен быть в курсе всего происходящего на проекте, активно участвовать в жизни команды.
В-третьих, важно понимать, что цель любого бизнеса – достичь поставленной цели как можно быстрее, дешевле и качественнее. Эту глобальную и банальную мысль можно применить не только к проекту целиком, но и каждой из его задач. Когда аналитику поступает какая-то задача, крайне важно подумать о том, какую проблему она призвана решить, и как ее можно решить наиболее быстрым способом.
В-четвертых, настроить инструменты, шаблоны. Договориться с командой где вести документацию, где будет описание API, какой будет шаблон требований, об уровне детализации требований. Это нужно, чтобы удерживать консистентность (согласованность) документации и избежать беспорядка, а также чтобы вся команда, и приходящие люди, были синхронизированы в этом вопросе.
Ну и бонусом, в-пятых, надо приглядывать за другими, как минимум, в части:
1. ТЗ должно быть оценено разработчиками. За оценку работы должны быть ответственны те, кто выполняет эту работу. Когда команда вписывается в реализацию проекта, оцененного, например, менеджером, зачастую это либо плохо заканчивается, либо не начинается;
2. Процессы проекта должны быть выстроены так, чтобы команда функционировала практически автономно. Обратная полярность автономии – микроменджмент, это когда менеджер или тимлид делает работу за других (проектирует, разрабатывает, тестирует). Отсутствие автономии – серьезный риск для проекта, поэтому на это нельзя закрывать глаза;
3. Нельзя недооценивать RoadMap проекта. Команда, которая не знает куда идет, это отряд самураев, у которых есть только путь, причем обычно не очень эффективный.
Напоследок повторюсь, чтобы подчеркнуть важность: правильный старт проекта – залог его успешного завершения.
Setup проекта – это все, что делается на старте проекта, включая фундаментальные вещи и не очень. Ошибки, допущенные на старте проекта, могут влиять на работу команды в течение всей жизни проекта. В этом посте я попробовал собрать основные рекомендации.
Во-первых, надо разобраться в имеющемся контексте и артефактах. Согласованный с заказчиком список задач, которые будем делать в рамках проекта, должен точно соответствовать ожиданиям, описанным в техническом задании (ТЗ) и представленным в дизайне (уже готовом или пока только в концепции). Если возникают какие-то расхождения, важно сразу сообщить об этом менеджеру.
Во-вторых, очень важно владеть максимумом контекста. На старте проекта, у всех вопросов больше, чем ответов, проводится большое количество встреч, на которых принимаются важные для проекта решения. Аналитик должен быть в курсе всего происходящего на проекте, активно участвовать в жизни команды.
В-третьих, важно понимать, что цель любого бизнеса – достичь поставленной цели как можно быстрее, дешевле и качественнее. Эту глобальную и банальную мысль можно применить не только к проекту целиком, но и каждой из его задач. Когда аналитику поступает какая-то задача, крайне важно подумать о том, какую проблему она призвана решить, и как ее можно решить наиболее быстрым способом.
В-четвертых, настроить инструменты, шаблоны. Договориться с командой где вести документацию, где будет описание API, какой будет шаблон требований, об уровне детализации требований. Это нужно, чтобы удерживать консистентность (согласованность) документации и избежать беспорядка, а также чтобы вся команда, и приходящие люди, были синхронизированы в этом вопросе.
Ну и бонусом, в-пятых, надо приглядывать за другими, как минимум, в части:
1. ТЗ должно быть оценено разработчиками. За оценку работы должны быть ответственны те, кто выполняет эту работу. Когда команда вписывается в реализацию проекта, оцененного, например, менеджером, зачастую это либо плохо заканчивается, либо не начинается;
2. Процессы проекта должны быть выстроены так, чтобы команда функционировала практически автономно. Обратная полярность автономии – микроменджмент, это когда менеджер или тимлид делает работу за других (проектирует, разрабатывает, тестирует). Отсутствие автономии – серьезный риск для проекта, поэтому на это нельзя закрывать глаза;
3. Нельзя недооценивать RoadMap проекта. Команда, которая не знает куда идет, это отряд самураев, у которых есть только путь, причем обычно не очень эффективный.
Напоследок повторюсь, чтобы подчеркнуть важность: правильный старт проекта – залог его успешного завершения.
❤4🔥4👍2
Почему в обучении так важна практика и реальные задачи?
Давайте вспомним, сколько классных книжек по самулучшайзингу вы прочитали и сколько реально повлияли на вашу жизнь?
Можно предположить, что единицы. И скорее всего успешны были те авторы, что предлагали вам сразу же внедрять прочитанное в свою жизнь. Хочешь рано вставать и магию утра? Давай завтра проснемся хотя бы на 10 минут раньше. А дальше и остальное подтянется.
Теория, закрепленная на реальных задачах, помогает не просто лучше усвоить материал, а конвертировать ее в реальные навыки. Это мы очень быстро поняли на первых программах стажировки. Если стажеру, с определенной подготовкой, сразу предложить задачу с реального проекта по теме, то когда он увидит ее в следующий раз, будет меньше страхов и больше толку. Именно этот принцип мы тиражируем уже больше 10 лет.
Еще один прием наших образовательных программ: мы все приземляем на реальные проекты и не создаем учебные материалы, а делимся реальными артефактами.
Например, на старте для стажеров мы даем памятку и делаем адаптационный лист, где даем на изучение теорию по архитектурным паттернам (монолит/микросервисы, тонкий и толстый клиент), клиент-серверному взаимодействую (с упором на архитектурный стиль REST), повторяем основы по сетевому взаимодействию (модель OSI) и базам данных, охватывая как реляционные, так и нереляционные.
Для закрепления теории стажеры сразу приступают к практической части, где:
• собирают требования с помощью интервью и анкетирования, анализируют текущие процессы;
• проектируют новую систему, охватывая полученные знания по архитектуре (часто это HLD или диаграмма компонентов);
• учатся создавать диаграммы вариантов использования, активностей и последовательностей в UML;
• проводят ревью UI/UX дизайна, используя гайдлайны;
• проектируют и тестируют API;
• моделируют логическую модель реляционной БД с использованием ERD диаграммы.
Такая практика даёт опыт, максимально приближенный к реальной работе, и приносит много пользы всем участникам. Поэтому если вы когда-нибудь решите чему-нибудь научиться, ищите в программах как можно больше практики и реальных условий.
Давайте вспомним, сколько классных книжек по самулучшайзингу вы прочитали и сколько реально повлияли на вашу жизнь?
Можно предположить, что единицы. И скорее всего успешны были те авторы, что предлагали вам сразу же внедрять прочитанное в свою жизнь. Хочешь рано вставать и магию утра? Давай завтра проснемся хотя бы на 10 минут раньше. А дальше и остальное подтянется.
Теория, закрепленная на реальных задачах, помогает не просто лучше усвоить материал, а конвертировать ее в реальные навыки. Это мы очень быстро поняли на первых программах стажировки. Если стажеру, с определенной подготовкой, сразу предложить задачу с реального проекта по теме, то когда он увидит ее в следующий раз, будет меньше страхов и больше толку. Именно этот принцип мы тиражируем уже больше 10 лет.
Еще один прием наших образовательных программ: мы все приземляем на реальные проекты и не создаем учебные материалы, а делимся реальными артефактами.
Например, на старте для стажеров мы даем памятку и делаем адаптационный лист, где даем на изучение теорию по архитектурным паттернам (монолит/микросервисы, тонкий и толстый клиент), клиент-серверному взаимодействую (с упором на архитектурный стиль REST), повторяем основы по сетевому взаимодействию (модель OSI) и базам данных, охватывая как реляционные, так и нереляционные.
Для закрепления теории стажеры сразу приступают к практической части, где:
• собирают требования с помощью интервью и анкетирования, анализируют текущие процессы;
• проектируют новую систему, охватывая полученные знания по архитектуре (часто это HLD или диаграмма компонентов);
• учатся создавать диаграммы вариантов использования, активностей и последовательностей в UML;
• проводят ревью UI/UX дизайна, используя гайдлайны;
• проектируют и тестируют API;
• моделируют логическую модель реляционной БД с использованием ERD диаграммы.
Такая практика даёт опыт, максимально приближенный к реальной работе, и приносит много пользы всем участникам. Поэтому если вы когда-нибудь решите чему-нибудь научиться, ищите в программах как можно больше практики и реальных условий.
❤10🔥1
Роль аналитика в сборе требований. Часть 1
Давайте разберем, как собирать требования для проекта и избежать ошибок на ранних этапах.
Почему это важно?
Ошибки, допущенные в самом начале, могут дорого обойтись, если их обнаружить слишком поздно. Поэтому сбор требований — ключевой этап. Часто требования меняются, и это нормально, особенно если вы работаете по гибким методологиям. Юрий Куприянов в своей статье отмечает, что проблемы чаще возникают не из-за заказчика, а из-за того, что мы сами что-то не уточнили.
Каждый проект уникален, и нет универсального способа сбора требований. Но есть несколько принципов, которые помогут снизить риски. Применяйте эти советы только если уверены, что они не нарушат договоренности с заказчиком.
Что обсудим?
Этот пост будет разделен на 2 части. В первой поговорим об анализе предметной области и о том, как работать с лицом, принимающим решение, что делать на первых этапах.
Во втором посте затронем рекомендации по проведению интервью, и разберем какие артефакты нужно собрать на основе первых интервью.
1. Анализ предметной области
Сначала важно детально разобраться в предметной области. Это особенно критично, если вы раньше не работали с подобными продуктами.
Как погружаться в тему:
• Ресерч. Читайте книги, статьи, блоги, форумы. Изучите существующие процессы и подходы к автоматизации в данной области, а также заказчика и его конкурентов.
• Общение с экспертами. Найдите сообщества, Telegram- или YouTube-каналы, блоги, подкасты. Лучше всего — связаться напрямую с экспертами и задать им вопросы.
Результаты исследования делитесь с командой. Не ждите, что вам кто-то принесет всю информацию на блюдечке. Проактивность всегда лучше бездействия!
2. Работа с лицами, принимающими решения (ЛПР)
• Определите, кто входит в группу ЛПР. Это можно узнать у аккаунт-менеджера или самостоятельно.
• Проведите интервью с ключевыми ЛПР. Узнайте их цели и ожидания от продукта, а также степень их влияния.
Эта информация поможет вам правильно выстраивать коммуникацию с заказчиком и принимать решения в спорных ситуациях.
В следующем посте обсудим, как планировать интервью и разберем важные артефакты на старте проекта. Надеюсь, этот пост был полезен и помог вам разобраться, с чего начать.
Давайте разберем, как собирать требования для проекта и избежать ошибок на ранних этапах.
Почему это важно?
Ошибки, допущенные в самом начале, могут дорого обойтись, если их обнаружить слишком поздно. Поэтому сбор требований — ключевой этап. Часто требования меняются, и это нормально, особенно если вы работаете по гибким методологиям. Юрий Куприянов в своей статье отмечает, что проблемы чаще возникают не из-за заказчика, а из-за того, что мы сами что-то не уточнили.
Каждый проект уникален, и нет универсального способа сбора требований. Но есть несколько принципов, которые помогут снизить риски. Применяйте эти советы только если уверены, что они не нарушат договоренности с заказчиком.
Что обсудим?
Этот пост будет разделен на 2 части. В первой поговорим об анализе предметной области и о том, как работать с лицом, принимающим решение, что делать на первых этапах.
Во втором посте затронем рекомендации по проведению интервью, и разберем какие артефакты нужно собрать на основе первых интервью.
1. Анализ предметной области
Сначала важно детально разобраться в предметной области. Это особенно критично, если вы раньше не работали с подобными продуктами.
Как погружаться в тему:
• Ресерч. Читайте книги, статьи, блоги, форумы. Изучите существующие процессы и подходы к автоматизации в данной области, а также заказчика и его конкурентов.
• Общение с экспертами. Найдите сообщества, Telegram- или YouTube-каналы, блоги, подкасты. Лучше всего — связаться напрямую с экспертами и задать им вопросы.
Результаты исследования делитесь с командой. Не ждите, что вам кто-то принесет всю информацию на блюдечке. Проактивность всегда лучше бездействия!
2. Работа с лицами, принимающими решения (ЛПР)
• Определите, кто входит в группу ЛПР. Это можно узнать у аккаунт-менеджера или самостоятельно.
• Проведите интервью с ключевыми ЛПР. Узнайте их цели и ожидания от продукта, а также степень их влияния.
Эта информация поможет вам правильно выстраивать коммуникацию с заказчиком и принимать решения в спорных ситуациях.
В следующем посте обсудим, как планировать интервью и разберем важные артефакты на старте проекта. Надеюсь, этот пост был полезен и помог вам разобраться, с чего начать.
🔥7👍1🤝1
Симулятор системного анализа pinned «Разбор тестового задания со стажировки! Мы не просто так претендуем на статус симулятора, поэтому будем стараться прямо в канале разбирать задачи! Сегодня первый такой разбор. Отбор на каждую стажировку, а у нас их было очень много, включает тестовое задание…»
На Симуляторе кончаются скидки
Наверное вы знаете, что наш канал называется не просто так, и что все наши принципы образования мы воплотили не только в стажировках, но и в программе Симулятора системного анализа
Симулятор системного анализа - это по сути онлайн-программа нашей стажировки, полностью симулирующая работу системного аналитика. Если коротко, то пройдя программу вы получите все то, что и на работе в реальной компании за полгода. Только с подсказками, артефактами и бережным сопровождением.
Если вы все еще думаете о покупке Симулятора системного анализа, то сейчас самое время сделать это. Наши щедрые скидки на программу заканчиваются 1 августа, и до осени они вряд ли вернутся.
Лето — отличное время для апгрейда ваших знаний и навыков. Не упустите возможность инвестировать в себя по выгодной цене!
Заходите, выбирайте тариф и начинайте учиться.
Будем рады видеть вас среди наших студентов!
Наверное вы знаете, что наш канал называется не просто так, и что все наши принципы образования мы воплотили не только в стажировках, но и в программе Симулятора системного анализа
Симулятор системного анализа - это по сути онлайн-программа нашей стажировки, полностью симулирующая работу системного аналитика. Если коротко, то пройдя программу вы получите все то, что и на работе в реальной компании за полгода. Только с подсказками, артефактами и бережным сопровождением.
Если вы все еще думаете о покупке Симулятора системного анализа, то сейчас самое время сделать это. Наши щедрые скидки на программу заканчиваются 1 августа, и до осени они вряд ли вернутся.
Лето — отличное время для апгрейда ваших знаний и навыков. Не упустите возможность инвестировать в себя по выгодной цене!
Заходите, выбирайте тариф и начинайте учиться.
Будем рады видеть вас среди наших студентов!
simulator.kode.ru
Симулятор системного анализа
Онлайн-стажировка по профессии системный аналитик
❤4🔥3👍2
Роль аналитика в сборе требований. Часть 2
Во второй части поста разберем рекомендации по проведению интервью, и обсудим какие артефакты можно составить на их основе.
3. Рекомендации по проведении интервью
1. Планируйте интервью заранее. Подумайте какие у вас есть вопросы и запишите их, это позволит вам более полно собрать требования с заказчика, не забыть важных вещей.
2. В созвонах с заказчиком важно придерживаться техники активного слушания. Внимательно слушайте, задавайте вопросы, уточняйте сказанное, это даст вам дополнительные детали и пояснения.
3. Помните про неявные требования и ожидания, которые заказчик может упустить.
4. Не делайте предположений и не ограничивайте восприятие только тем, что говорит заказчик. Не воспринимайте услышанное за чистую монету, т.к. любые утверждения (в том числе ваши) должны быть поставлены под сомнение и проверены фактами.
5. Когда заказчик озвучивает «требования», разделяйте их на реально необходимые для продукта функции и на пожелания. Первое – в приоритете, второе – под вопросом.
6. Старайтесь «на лету» декомпозировать требования заказчика, это позволит вам сразу увидеть и подсветить риски, уточнения и т.п.
7. Все требования заказчика должны проходить через принциппочему зачем. Этот вопрос должен звучать при каждой сессии сбора требований. Необходимо его задавать до тех пор, пока вы не дойдете до корневой проблемы, которую хочет решить заказчик.
8. Фиксируйте договоренности. Каждый диалог (в жизни, на созвоне, в чате) с заказчиком и командой, который привел к каким-либо договоренностям, должен быть зафиксирован в общем пространстве.
4. Артефакты
На старте проекта, на основе имеющихся вводных артефактов (ТЗ, FL, договор и т.п.), а также на основе первых проведенных с заказчиком интервью, составьте следующие артефакты:
- Бизнес-требования. Помним, что БТ могут быть описаны как Job stories, User Stories, Use cases или в свободном формате, но не должны при этом опускаться до уровня клиент-серверного взаимодействия.
- Контекстную диаграмму. Это позволит любому члену команды быстро понять границы системы.
- Концептуальную модель данных. Это позволит любому члену команды предварительно понять с чем предстоит иметь дело.
- HLD диаграмму, если это не было сделано во время предпроектного анализа.
- Диаграмму состояний, если в проекте есть ключевые сущности со своей статусной моделью;
- CRUD матрицу по ключевым сущностям и ролям системы.
И также ответьте на вопросы:
1. Все ли операции над всеми объектами учтены?
2. Все ли требования учтены?
3. Установлены ли все связи с экранами, отчетами, внешними системами?
4. Все проверки, исключения и альтернативы описаны?
Во второй части поста разберем рекомендации по проведению интервью, и обсудим какие артефакты можно составить на их основе.
3. Рекомендации по проведении интервью
1. Планируйте интервью заранее. Подумайте какие у вас есть вопросы и запишите их, это позволит вам более полно собрать требования с заказчика, не забыть важных вещей.
2. В созвонах с заказчиком важно придерживаться техники активного слушания. Внимательно слушайте, задавайте вопросы, уточняйте сказанное, это даст вам дополнительные детали и пояснения.
3. Помните про неявные требования и ожидания, которые заказчик может упустить.
4. Не делайте предположений и не ограничивайте восприятие только тем, что говорит заказчик. Не воспринимайте услышанное за чистую монету, т.к. любые утверждения (в том числе ваши) должны быть поставлены под сомнение и проверены фактами.
5. Когда заказчик озвучивает «требования», разделяйте их на реально необходимые для продукта функции и на пожелания. Первое – в приоритете, второе – под вопросом.
6. Старайтесь «на лету» декомпозировать требования заказчика, это позволит вам сразу увидеть и подсветить риски, уточнения и т.п.
7. Все требования заказчика должны проходить через принцип
8. Фиксируйте договоренности. Каждый диалог (в жизни, на созвоне, в чате) с заказчиком и командой, который привел к каким-либо договоренностям, должен быть зафиксирован в общем пространстве.
4. Артефакты
На старте проекта, на основе имеющихся вводных артефактов (ТЗ, FL, договор и т.п.), а также на основе первых проведенных с заказчиком интервью, составьте следующие артефакты:
- Бизнес-требования. Помним, что БТ могут быть описаны как Job stories, User Stories, Use cases или в свободном формате, но не должны при этом опускаться до уровня клиент-серверного взаимодействия.
- Контекстную диаграмму. Это позволит любому члену команды быстро понять границы системы.
- Концептуальную модель данных. Это позволит любому члену команды предварительно понять с чем предстоит иметь дело.
- HLD диаграмму, если это не было сделано во время предпроектного анализа.
- Диаграмму состояний, если в проекте есть ключевые сущности со своей статусной моделью;
- CRUD матрицу по ключевым сущностям и ролям системы.
И также ответьте на вопросы:
1. Все ли операции над всеми объектами учтены?
2. Все ли требования учтены?
3. Установлены ли все связи с экранами, отчетами, внешними системами?
4. Все проверки, исключения и альтернативы описаны?
❤6🔥1
Основной инструментарий системного аналитика
Работа системного аналитика включает множество инструментов, которые помогают эффективно моделировать, анализировать и тестировать системы. Вот некоторые ключевые инструменты и советы как их можно изучить:
• Confluence для совместной работы с документами в едином пространстве. Тут можно создавать и управлять документацией, собирать требования и делиться знаниями, например, для создания спецификаций, протоколов встреч, а также для координации работы команды. Чтобы освоить Confluence, можно начать с создания простых страниц и постепенно переходить к более сложным документам и интеграциям.
• Swagger (сейчас OpenAPI)/Stoplight. Эти инструменты позволяют управлять контрактами API, предоставляя понятный интерфейс для их чтения и редактирования. В начале можно создать простые спецификации, а потом перейти к сложным. С помощью Stoplight также можно поднять собственный мок-сервер, в который можно отправлять запросы API и получать моковые данные в ответ.
• PlantUML - текстовый редактор, создающий по определенным командам диаграммы автоматически. Есть документация на русском языке. Чуть сложнее, чем визуальные редакторы. Но когда нужно будет править большие диаграммы изменением всего одной строчки, вы оцените инструмент по достоинству.
• BPMN (Business Process Model and Notation) - помогает моделировать бизнес-процессы, визуализируя их и делая их более понятными для всех участников.
• draw.io (diagrams.net) - это универсальный инструмент для моделирования, который позволяет создавать различные виды диаграмм, включая UML, BPMN и блок-схемы.
• Postman, при помощи него можно отправлять запросы, проверять ответы и автоматизировать тестирование API.
• Git - это система контроля версий, которая позволяет отслеживать изменения в коде и документации.
Начните с изучения основ каждого инструмента, используя доступные руководства и учебные материалы. Переходите к практике, создавая собственные проекты и применяя инструменты в реальных задачах. Регулярное использование поможет вам стать более уверенным в работе с этими инструментами.
Напоминаем, что эти инструменты вы также можете освоить в нашем Симуляторе системного анализа.
Работа системного аналитика включает множество инструментов, которые помогают эффективно моделировать, анализировать и тестировать системы. Вот некоторые ключевые инструменты и советы как их можно изучить:
• Confluence для совместной работы с документами в едином пространстве. Тут можно создавать и управлять документацией, собирать требования и делиться знаниями, например, для создания спецификаций, протоколов встреч, а также для координации работы команды. Чтобы освоить Confluence, можно начать с создания простых страниц и постепенно переходить к более сложным документам и интеграциям.
• Swagger (сейчас OpenAPI)/Stoplight. Эти инструменты позволяют управлять контрактами API, предоставляя понятный интерфейс для их чтения и редактирования. В начале можно создать простые спецификации, а потом перейти к сложным. С помощью Stoplight также можно поднять собственный мок-сервер, в который можно отправлять запросы API и получать моковые данные в ответ.
• PlantUML - текстовый редактор, создающий по определенным командам диаграммы автоматически. Есть документация на русском языке. Чуть сложнее, чем визуальные редакторы. Но когда нужно будет править большие диаграммы изменением всего одной строчки, вы оцените инструмент по достоинству.
• BPMN (Business Process Model and Notation) - помогает моделировать бизнес-процессы, визуализируя их и делая их более понятными для всех участников.
• draw.io (diagrams.net) - это универсальный инструмент для моделирования, который позволяет создавать различные виды диаграмм, включая UML, BPMN и блок-схемы.
• Postman, при помощи него можно отправлять запросы, проверять ответы и автоматизировать тестирование API.
• Git - это система контроля версий, которая позволяет отслеживать изменения в коде и документации.
Начните с изучения основ каждого инструмента, используя доступные руководства и учебные материалы. Переходите к практике, создавая собственные проекты и применяя инструменты в реальных задачах. Регулярное использование поможет вам стать более уверенным в работе с этими инструментами.
Напоминаем, что эти инструменты вы также можете освоить в нашем Симуляторе системного анализа.
simulator.kode.ru
Симулятор системного анализа
Онлайн-стажировка по профессии системный аналитик
❤10👍1🔥1
Процесс работы аналитика над проектом
Работа системного аналитика обычно проходит все этапы от идеи до реализации. Каждый из этих этапов важен для успешного завершения проекта.
Превращение идеи в требования
Все начинается с идеи, которую может предложить заказчик. Аналитик собирает эти идеи, уточняет цели проекта, изучает текущие процессы и потребности бизнеса. На основе этого создается документ с требованиями, учитывающий все детали и нюансы.
Задача аналитика — уточнить эти требования, не погружая заказчика в технические детали, но при этом представляя, что будет «под капотом». Для этого проводятся встречи с заказчиком, интервью с пользователями, чтобы убедиться, что все требования к системе были выявлены в полной мере и правильно. Итогом этого этапа становится четкое понимание текущих процессов и ожиданий от новой системы, оформленное в виде бизнес-требований или ином формате, который позволяет закрепить все договоренности.
Определение ролей пользователей и приложений
Аналитик выясняет, кто и как будет пользоваться приложением, описывает эти роли и их потребности. Это помогает всей команде понять, как будут организованы основные компоненты системы и как они будут взаимодействовать.
Выделение и описание сценариев, проработка альтернативных
Аналитик описывает, как различные роли будут взаимодействовать с системой, какие основные действия они будут выполнять в приложении. Также прописываются альтернативные сценарии на случай возможных исключений и ошибок.
Проектирование клиент-серверного взаимодействия и написание функциональных требований
По итогам всей ранее полученной информации, аналитик приступает к проектированию системы. Чаще всего аналитик на этом этапе работает с API, проектирует и фиксирует его. Порой может понадобиться помощь в проектировании базы данных или внешних интеграций, зависит от функциональности и проекта. Кроме того, аналитик всегда фиксирует функциональные требования, на основе которых, в дальнейшем, команда разработки будет писать код и разрабатывать приложение.
Этапы реализации проекта
1. Планирование: Определяются сроки, ресурсы и распределение задач. Это важный этап, так как правильное планирование позволяет избежать множества проблем в будущем.
2. Анализ: Проводится преданалитика с уклоном в бизнес-требования.
3. Дизайн: Разрабатываются прототипы и макеты, которые позволяют визуализировать будущую систему.
4. Системный анализ: Написание технических требований.
4. Имплементация: Команда разработчиков начинает работу над проектом. Аналитик помогает решать возникающие вопросы и корректирует требования при необходимости.
5. Тестирование: Проверяется соответствие продукта требованиям. Аналитик участвует в тестировании, помогает выявить и исправить ошибки, чтобы продукт был готов к запуску.
6. Внедрение и поддержка: После успешного тестирования продукт внедряется в рабочую среду. Аналитик следит за проектом и решает возникающие проблемы, обеспечивая поддержку системы.
На этом работа не заканчивается. Постоянное улучшение и адаптация к новым требованиям — залог успешного проекта. Аналитик продолжает играть важную роль, поддерживая связь между бизнесом и технологией, чтобы проект продолжал развиваться и соответствовать потребностям пользователей.
Работа системного аналитика обычно проходит все этапы от идеи до реализации. Каждый из этих этапов важен для успешного завершения проекта.
Превращение идеи в требования
Все начинается с идеи, которую может предложить заказчик. Аналитик собирает эти идеи, уточняет цели проекта, изучает текущие процессы и потребности бизнеса. На основе этого создается документ с требованиями, учитывающий все детали и нюансы.
Задача аналитика — уточнить эти требования, не погружая заказчика в технические детали, но при этом представляя, что будет «под капотом». Для этого проводятся встречи с заказчиком, интервью с пользователями, чтобы убедиться, что все требования к системе были выявлены в полной мере и правильно. Итогом этого этапа становится четкое понимание текущих процессов и ожиданий от новой системы, оформленное в виде бизнес-требований или ином формате, который позволяет закрепить все договоренности.
Определение ролей пользователей и приложений
Аналитик выясняет, кто и как будет пользоваться приложением, описывает эти роли и их потребности. Это помогает всей команде понять, как будут организованы основные компоненты системы и как они будут взаимодействовать.
Выделение и описание сценариев, проработка альтернативных
Аналитик описывает, как различные роли будут взаимодействовать с системой, какие основные действия они будут выполнять в приложении. Также прописываются альтернативные сценарии на случай возможных исключений и ошибок.
Проектирование клиент-серверного взаимодействия и написание функциональных требований
По итогам всей ранее полученной информации, аналитик приступает к проектированию системы. Чаще всего аналитик на этом этапе работает с API, проектирует и фиксирует его. Порой может понадобиться помощь в проектировании базы данных или внешних интеграций, зависит от функциональности и проекта. Кроме того, аналитик всегда фиксирует функциональные требования, на основе которых, в дальнейшем, команда разработки будет писать код и разрабатывать приложение.
Этапы реализации проекта
1. Планирование: Определяются сроки, ресурсы и распределение задач. Это важный этап, так как правильное планирование позволяет избежать множества проблем в будущем.
2. Анализ: Проводится преданалитика с уклоном в бизнес-требования.
3. Дизайн: Разрабатываются прототипы и макеты, которые позволяют визуализировать будущую систему.
4. Системный анализ: Написание технических требований.
4. Имплементация: Команда разработчиков начинает работу над проектом. Аналитик помогает решать возникающие вопросы и корректирует требования при необходимости.
5. Тестирование: Проверяется соответствие продукта требованиям. Аналитик участвует в тестировании, помогает выявить и исправить ошибки, чтобы продукт был готов к запуску.
6. Внедрение и поддержка: После успешного тестирования продукт внедряется в рабочую среду. Аналитик следит за проектом и решает возникающие проблемы, обеспечивая поддержку системы.
На этом работа не заканчивается. Постоянное улучшение и адаптация к новым требованиям — залог успешного проекта. Аналитик продолжает играть важную роль, поддерживая связь между бизнесом и технологией, чтобы проект продолжал развиваться и соответствовать потребностям пользователей.
❤10👍3🔥3
Как рождался симулятор
Как мы пришли к этой идее?
На протяжении 10 лет мы проводим стажировки. Изначально это были групповые стажировки, затем мы перешли на индивидуальный формат, где в течение месяца стажировались с каждым конкретным человеком. Сейчас мы поняли, что:
• Во-первых, количество желающих превышает наши возможности. Мы просто не можем принять всех, кто хочет попасть на наши стажировки.
• Во-вторых, мы хотели, чтобы эта возможность была не только у калининградцев, но и доступна всем желающим.
Так появилось желание автоматизировать и масштабировать наши стажировки. Автоматизировать через описание программы и задач, которые стажеры выполняют во время стажировки + добавить то, что они не успевают освоить за месяц, но тоже важное. И масштабировать, предоставив возможность пройти программу всей русскоязычной аудитории мира.
Кстати, на момент зарождения идеи не существовало ни одного комплексного курса по системному анализу, были только небольшие программы по отдельным навыкам в лекционном формате.
Благодаря Симулятору системного анализа это может сделать каждый, у которого есть доступ к интернету. По результатам прохождения каждого из блоков у вас будут конкретные артефакты — практические результаты вашей работы, а не просто теоретические знания, а также опыт, который позволит проходить собеседования, подаваться на вакансии в реальные компании и получать работу.
В чем наши отличия?
1. Реальная проектная работа. Это знания и опыт работы с реальными задачами, которые так ценится всеми работодателями. А также этот опыт психологически подготовит вас к реальной работе.
2. Систематизация знаний. Практика позволяет систематизировать все знания, которые вы получили ранее.
3. Внезапные задачи. Мы добавили "внезапные" задачи, которые отражают реальную жизнь аналитика, когда помимо текущих задач ему приходится решать что-то неожиданное.
Артефакты можно использовать на собеседованиях как конкретное преимущество перед другими кандидатами.
Для начинающих аналитиков это хорошая возможность получить ценный практический опыт, развить как технические, так и софт-скиллы, и подготовиться к успешной карьере, что станет ключом к вашему профессиональному росту и откроет двери в мир системного анализа.
Как мы пришли к этой идее?
На протяжении 10 лет мы проводим стажировки. Изначально это были групповые стажировки, затем мы перешли на индивидуальный формат, где в течение месяца стажировались с каждым конкретным человеком. Сейчас мы поняли, что:
• Во-первых, количество желающих превышает наши возможности. Мы просто не можем принять всех, кто хочет попасть на наши стажировки.
• Во-вторых, мы хотели, чтобы эта возможность была не только у калининградцев, но и доступна всем желающим.
Так появилось желание автоматизировать и масштабировать наши стажировки. Автоматизировать через описание программы и задач, которые стажеры выполняют во время стажировки + добавить то, что они не успевают освоить за месяц, но тоже важное. И масштабировать, предоставив возможность пройти программу всей русскоязычной аудитории мира.
Кстати, на момент зарождения идеи не существовало ни одного комплексного курса по системному анализу, были только небольшие программы по отдельным навыкам в лекционном формате.
Благодаря Симулятору системного анализа это может сделать каждый, у которого есть доступ к интернету. По результатам прохождения каждого из блоков у вас будут конкретные артефакты — практические результаты вашей работы, а не просто теоретические знания, а также опыт, который позволит проходить собеседования, подаваться на вакансии в реальные компании и получать работу.
В чем наши отличия?
1. Реальная проектная работа. Это знания и опыт работы с реальными задачами, которые так ценится всеми работодателями. А также этот опыт психологически подготовит вас к реальной работе.
2. Систематизация знаний. Практика позволяет систематизировать все знания, которые вы получили ранее.
3. Внезапные задачи. Мы добавили "внезапные" задачи, которые отражают реальную жизнь аналитика, когда помимо текущих задач ему приходится решать что-то неожиданное.
Артефакты можно использовать на собеседованиях как конкретное преимущество перед другими кандидатами.
Для начинающих аналитиков это хорошая возможность получить ценный практический опыт, развить как технические, так и софт-скиллы, и подготовиться к успешной карьере, что станет ключом к вашему профессиональному росту и откроет двери в мир системного анализа.
❤8🔥4
Коммуникация в работе аналитика
Работа системного аналитика – это не только про технические навыки, но и про психологию и умение общаться. Софт-скиллы в каждой профессии свои, и при прочих равных условиях они становятся конкурентным преимуществом специалиста.
Коммуникация - главный навык
Для того, чтобы донести сложные технические концепции до различных аудиторий, включая клиентов, разработчиков и менеджеров, системный аналитик должен уметь ясно и просто излагать свои мысли.
Активно слушать
Внимательное слушание помогает понять настоящие потребности и ожидания всех участников проекта. Это поможет также выявить неочевидные проблемы.
Работать в команде
Системный аналитик часто выступает посредником между различными отделами и должен уметь гармонизировать интересы всех участников проекта, поэтому важно находить "общий язык" со всеми.
Разрешать конфликты
Нужно уметь управлять конфликтами и находить компромиссы, чтобы поддерживать продуктивную рабочую атмосферу и двигаться вперед к достижению целей проекта.
Управлять временем
Планирование задач, расстановка приоритетов и умение работать в условиях многозадачности помогают завершать проекты вовремя и с высоким качеством.
Стрессоустойчивость
Важно всегда оставаться спокойным и адаптироваться к новым условиям.
Эмпатия
Понимание нужд клиентов – это ключ. Умение слушать и понимать их эмоции помогает создавать именно те решения, которые им нужны.
Эти софт-скиллы помогают не только выполнять задачи качественно, но и строить эффективные рабочие отношения, чтобы всем было комфортно. И вам в том числе!
Работа системного аналитика – это не только про технические навыки, но и про психологию и умение общаться. Софт-скиллы в каждой профессии свои, и при прочих равных условиях они становятся конкурентным преимуществом специалиста.
Коммуникация - главный навык
Для того, чтобы донести сложные технические концепции до различных аудиторий, включая клиентов, разработчиков и менеджеров, системный аналитик должен уметь ясно и просто излагать свои мысли.
Активно слушать
Внимательное слушание помогает понять настоящие потребности и ожидания всех участников проекта. Это поможет также выявить неочевидные проблемы.
Работать в команде
Системный аналитик часто выступает посредником между различными отделами и должен уметь гармонизировать интересы всех участников проекта, поэтому важно находить "общий язык" со всеми.
Разрешать конфликты
Нужно уметь управлять конфликтами и находить компромиссы, чтобы поддерживать продуктивную рабочую атмосферу и двигаться вперед к достижению целей проекта.
Управлять временем
Планирование задач, расстановка приоритетов и умение работать в условиях многозадачности помогают завершать проекты вовремя и с высоким качеством.
Стрессоустойчивость
Важно всегда оставаться спокойным и адаптироваться к новым условиям.
Эмпатия
Понимание нужд клиентов – это ключ. Умение слушать и понимать их эмоции помогает создавать именно те решения, которые им нужны.
Эти софт-скиллы помогают не только выполнять задачи качественно, но и строить эффективные рабочие отношения, чтобы всем было комфортно. И вам в том числе!
👍7🔥4❤1
Процесс разработки продукта: от идеи до релиза
Мы обратились к менеджеру портфеля проектов, чтобы узнать, как проходит процесс разработки продукта начиная от идеи и заканчивая релизом.
Многие думают, что разработка любого сервиса выглядит так: Заказчик что-то наговорил → Произошла какая-то магия → Разработка → Все готово!
Но на самом деле это достаточно сложный процесс. Системный аналитик играет важную роль и принимает участие на всех этапах, обеспечивает понимание бизнес-требований, помогает минимизировать риски и способствует успешному выполнению проекта. В одном из предыдущих постов мы уже говорили о Процессе работы аналитика над проектом.
Давайте теперь подробнее поговорим о каждом из этапов разработки продукта:
1. Presale. Этап, с которого начинается работа над проектом. На этом этапе компания предпринимает первые усилия для заключения сделки, изучения бизнес-модели заказчика и проведения предпроектной аналитики.
2. Планирование. Начинается работа по сбору команды и верхнеуровневое планирование реализации проекта. На этом этапе определяется сложность разработки, оцениваются готовые артефакты и свободные ресурсы в компании.
3. Анализ. В полную силу аналитики начинают работать именно на данном этапе, который включает в себя:
- Сбор бизнес и системных требований
- Проектирование архитектуры
- Проектирование API
- Проверку дизайна, которая делается на основании написанных требований
- Обновление списка функций разрабатываемого продукта (опционально)
4. Дизайн. На этом этапе дизайнеры собирают референсы, подготавливают детализированные "вайры", отрисовывают макеты и адаптируют их под разные платформы, подготавливают карты экранов, UI Kit и исходные материалы, а также проводят авторский надзор в конце разработки перед релизом и подготавливают промо-материалы.
5. Иплементация. Этап на котором разработчики подключаются к реализации функций продукта по подготовленным аналитиками постановкам и отрисованным дизайнерами экранам, он включает в себя:
- Проектирование/уточнение архитектуры
- Верстку дизайна
- Реализацию API и логики
- Интеграцию с внешними сервисами
- Сборку приложения или сервиса
6. Тестирование. На этом этапе:
- Ревью требований и дизайна
- Проверка API внешних сервисов
- Написание тест-кейсов
- Создание чек-листов для проверки
- Тестирование различными методами (Функциональное, Интеграционное, Нагрузочное, Регрессионное)
7. Приемка продукта. Вероятно, один из самых напряженных этапов разработки продукта, в рамках которого мы демонстрируем проделанные работы заказчику, который может включать в себя следующие активности. На этом этапе:
— Проводятся приемочные испытания и демо для сдачи работ, проверка по требованиям заказчика
— Передача исходного кода и документации
— Пилотирование продукта на маленькой аудитории
8. Поддержка и внедрение. Завершающим этапом любого проекта является — внедрение, то есть передача продукта в руки реальных пользователей, для которых этот продукт и создавался.
Он включает себя публикацию приложений в сторах, полномасштабное внедрение продукта в процессы компании или же раскатка на всех пользователей, обучение пользователей в случае разработки внутренних систем заказчика и изучение метрик использования продукта.
Мы не ждём завершения одного этапа, чтобы приступить к следующему. В современных условиях важно двигаться итеративно, пересматривая и дорабатывая различные функции. Грубо говоря, мы не разрабатываем всё приложение за один раз, а подходим к процессу поэтапно, одновременно работая над анализом, дизайном, реализацией и тестированием.
Мы обратились к менеджеру портфеля проектов, чтобы узнать, как проходит процесс разработки продукта начиная от идеи и заканчивая релизом.
Многие думают, что разработка любого сервиса выглядит так: Заказчик что-то наговорил → Произошла какая-то магия → Разработка → Все готово!
Но на самом деле это достаточно сложный процесс. Системный аналитик играет важную роль и принимает участие на всех этапах, обеспечивает понимание бизнес-требований, помогает минимизировать риски и способствует успешному выполнению проекта. В одном из предыдущих постов мы уже говорили о Процессе работы аналитика над проектом.
Давайте теперь подробнее поговорим о каждом из этапов разработки продукта:
1. Presale. Этап, с которого начинается работа над проектом. На этом этапе компания предпринимает первые усилия для заключения сделки, изучения бизнес-модели заказчика и проведения предпроектной аналитики.
2. Планирование. Начинается работа по сбору команды и верхнеуровневое планирование реализации проекта. На этом этапе определяется сложность разработки, оцениваются готовые артефакты и свободные ресурсы в компании.
3. Анализ. В полную силу аналитики начинают работать именно на данном этапе, который включает в себя:
- Сбор бизнес и системных требований
- Проектирование архитектуры
- Проектирование API
- Проверку дизайна, которая делается на основании написанных требований
- Обновление списка функций разрабатываемого продукта (опционально)
4. Дизайн. На этом этапе дизайнеры собирают референсы, подготавливают детализированные "вайры", отрисовывают макеты и адаптируют их под разные платформы, подготавливают карты экранов, UI Kit и исходные материалы, а также проводят авторский надзор в конце разработки перед релизом и подготавливают промо-материалы.
5. Иплементация. Этап на котором разработчики подключаются к реализации функций продукта по подготовленным аналитиками постановкам и отрисованным дизайнерами экранам, он включает в себя:
- Проектирование/уточнение архитектуры
- Верстку дизайна
- Реализацию API и логики
- Интеграцию с внешними сервисами
- Сборку приложения или сервиса
6. Тестирование. На этом этапе:
- Ревью требований и дизайна
- Проверка API внешних сервисов
- Написание тест-кейсов
- Создание чек-листов для проверки
- Тестирование различными методами (Функциональное, Интеграционное, Нагрузочное, Регрессионное)
7. Приемка продукта. Вероятно, один из самых напряженных этапов разработки продукта, в рамках которого мы демонстрируем проделанные работы заказчику, который может включать в себя следующие активности. На этом этапе:
— Проводятся приемочные испытания и демо для сдачи работ, проверка по требованиям заказчика
— Передача исходного кода и документации
— Пилотирование продукта на маленькой аудитории
8. Поддержка и внедрение. Завершающим этапом любого проекта является — внедрение, то есть передача продукта в руки реальных пользователей, для которых этот продукт и создавался.
Он включает себя публикацию приложений в сторах, полномасштабное внедрение продукта в процессы компании или же раскатка на всех пользователей, обучение пользователей в случае разработки внутренних систем заказчика и изучение метрик использования продукта.
Мы не ждём завершения одного этапа, чтобы приступить к следующему. В современных условиях важно двигаться итеративно, пересматривая и дорабатывая различные функции. Грубо говоря, мы не разрабатываем всё приложение за один раз, а подходим к процессу поэтапно, одновременно работая над анализом, дизайном, реализацией и тестированием.
👍8❤3🔥2👌1
История ментора
Привет! Я Даша, старший системный аналитик в компании KODE, больше 3 лет в IT.
Мой путь в системном анализе начался ещё на первом курсе, когда я прошла одну из стажировок в нашей компании. Но эта история не про успешный успех, потому что на старте было очень сложно, я совершала большое количество ошибок и очень многое не понимала.
Бывало такое, что я все выходные изучала новый материал для того, чтобы хоть немного разобраться в новых терминах и темах. В итоге благодаря упорству и помощи остальных людей (команда, ментор) у меня начало получаться, и с каждый месяцем я ставила себе большие цели.
Сейчас я сама организую стажировки и стараюсь помочь остальным ребятам. Мне нравится делиться своими знаниями и выстраивать работу так, чтобы их погружение в IT проходило полегче (спойлер: это все равно тяжело). Также я руковожу группой аналитиков в роли чаптер-лида, имею большой опыт в менторстве и развитии сотрудников.
В KODE мы разрабатываем мобильные приложения в разных сферах, и сложно представить работу над нашими проектами без аналитиков. Мой опыт больше связан с проектами edtech и fintech. Всегда стремлюсь создавать крутые продукты, пробовать что-то новое и получать удовольствие от работы. Кроме того, мне нравится делиться своим опытом с теми, кто только начинает свой путь в системном анализе.
Из моего опыта я поняла, что успех в любой сфере, особенно в IT, зависит от упорства и постоянного стремления к развитию. Не бойтесь ошибок и трудностей, ведь именно через них приходит настоящее понимание и рост.
Привет! Я Даша, старший системный аналитик в компании KODE, больше 3 лет в IT.
Мой путь в системном анализе начался ещё на первом курсе, когда я прошла одну из стажировок в нашей компании. Но эта история не про успешный успех, потому что на старте было очень сложно, я совершала большое количество ошибок и очень многое не понимала.
Бывало такое, что я все выходные изучала новый материал для того, чтобы хоть немного разобраться в новых терминах и темах. В итоге благодаря упорству и помощи остальных людей (команда, ментор) у меня начало получаться, и с каждый месяцем я ставила себе большие цели.
Сейчас я сама организую стажировки и стараюсь помочь остальным ребятам. Мне нравится делиться своими знаниями и выстраивать работу так, чтобы их погружение в IT проходило полегче (спойлер: это все равно тяжело). Также я руковожу группой аналитиков в роли чаптер-лида, имею большой опыт в менторстве и развитии сотрудников.
В KODE мы разрабатываем мобильные приложения в разных сферах, и сложно представить работу над нашими проектами без аналитиков. Мой опыт больше связан с проектами edtech и fintech. Всегда стремлюсь создавать крутые продукты, пробовать что-то новое и получать удовольствие от работы. Кроме того, мне нравится делиться своим опытом с теми, кто только начинает свой путь в системном анализе.
Из моего опыта я поняла, что успех в любой сфере, особенно в IT, зависит от упорства и постоянного стремления к развитию. Не бойтесь ошибок и трудностей, ведь именно через них приходит настоящее понимание и рост.
❤11👍3🔥3
О чем вы хотите поговорить на следующем эфире?
Мы готовим новый эфир, и хотим сделать его максимально полезным для вас. Какие темы вы считаете наиболее важными и интересными для обсуждения?
Поделитесь в комментариях своими предложениями!
Мы готовим новый эфир, и хотим сделать его максимально полезным для вас. Какие темы вы считаете наиболее важными и интересными для обсуждения?
Поделитесь в комментариях своими предложениями!
❤10🐳1
Ошибки, которые совершают менти
Очень часто начинающие специалисты совершают ряд ошибок, которые могут замедлить их развитие, а также создать неловкие ситуации, расскажу про некоторые из них:
1. «Полагаться на память»
Тезисно конспектировать встречи — нужно. Это правда необходимо, потому что обучение само по себе будет в начале стрессом, а когда человек находится в стрессе, и поверх этого состояния получает большой объем сложной информации, то легко упускает важные детали и замечания.
2. Переспрашивать
Из первого пункта следует второй. Никто не любит, когда спрашивают одно и тоже более двух раз. Вопросы — это важно и не нужно стесняться их задавать, но после получения ответа стоит его зафиксировать, переработать полученную информацию и сделать выводы. Если из полученных выводов формируются новые вопросы в рамках темы, то повторить итерацию вопрос-ответ-вывод.
3. «Я не сделал»
Есть очень крутой поинт «лучше попробовать и жалеть, чем жалеть, что не пробовал». Но в случае обучения и стажировок, если ты попробовал, то это уже успех. Случалось, что человек, пришедший к нам на стажировку, из-за страха сделать неправильно, не делал ничего. Ошибки — это зона роста, не стоит их бояться. Они помогут понять в какой области не хватает знаний и компетенций, на что стоит обратить внимание.
4. «Думать, что всем на вас все равно»
Запрашивай обратную связь, чтобы понять, что у тебя получается хорошо, а какие моменты стоит подтянуть. Аналогично ошибкам, ОС поможет развивать скиллы в правильном направлении. Менти, которые негативно относятся к критике и не запрашивают фидбэк, обычно не получают оффер.
5. «Не хочу, не буду»
Нужно проявлять заинтересованность и старание. Менти, которые не бросают вызов сложным темам и задачам могут себя зарекомендовать, как неготовых к развитию. Попробуй сделать чуть лучше, узнать чуть больше и эти маленькие шаги приведут к большому успеху и к офферу, соответственно.
Важно в каждой проблеме видеть новую возможность для роста и развития. Активно задавайте вопросы, применяйте новые знания, такой подход поможет быстрее достигать поставленных целей.
Очень часто начинающие специалисты совершают ряд ошибок, которые могут замедлить их развитие, а также создать неловкие ситуации, расскажу про некоторые из них:
1. «Полагаться на память»
Тезисно конспектировать встречи — нужно. Это правда необходимо, потому что обучение само по себе будет в начале стрессом, а когда человек находится в стрессе, и поверх этого состояния получает большой объем сложной информации, то легко упускает важные детали и замечания.
2. Переспрашивать
Из первого пункта следует второй. Никто не любит, когда спрашивают одно и тоже более двух раз. Вопросы — это важно и не нужно стесняться их задавать, но после получения ответа стоит его зафиксировать, переработать полученную информацию и сделать выводы. Если из полученных выводов формируются новые вопросы в рамках темы, то повторить итерацию вопрос-ответ-вывод.
3. «Я не сделал»
Есть очень крутой поинт «лучше попробовать и жалеть, чем жалеть, что не пробовал». Но в случае обучения и стажировок, если ты попробовал, то это уже успех. Случалось, что человек, пришедший к нам на стажировку, из-за страха сделать неправильно, не делал ничего. Ошибки — это зона роста, не стоит их бояться. Они помогут понять в какой области не хватает знаний и компетенций, на что стоит обратить внимание.
4. «Думать, что всем на вас все равно»
Запрашивай обратную связь, чтобы понять, что у тебя получается хорошо, а какие моменты стоит подтянуть. Аналогично ошибкам, ОС поможет развивать скиллы в правильном направлении. Менти, которые негативно относятся к критике и не запрашивают фидбэк, обычно не получают оффер.
5. «Не хочу, не буду»
Нужно проявлять заинтересованность и старание. Менти, которые не бросают вызов сложным темам и задачам могут себя зарекомендовать, как неготовых к развитию. Попробуй сделать чуть лучше, узнать чуть больше и эти маленькие шаги приведут к большому успеху и к офферу, соответственно.
Важно в каждой проблеме видеть новую возможность для роста и развития. Активно задавайте вопросы, применяйте новые знания, такой подход поможет быстрее достигать поставленных целей.
❤9👍5🔥5
Идентификация/аутентификация/авторизация - что это такое и почему надо знать аналитику
Для чего это нужно знать?
1. Авторизация - это базовая функциональность, которая есть практически в каждом приложении. Рано или поздно с авторизацией поработает каждый аналитик.
2. Авторизация влияет также и на остальные функциональности, потому что часто именно с помощью авторизации пользователь получает к ним доступ (или наоборот - не получает).
С понятием авторизации сталкивались практически все, но вот про идентификацию/аутентификацию уже наверняка слышало не так много людей. Давайте разберемся что значат все эти понятия:
Идентификация — процедура, в результате которой для субъекта идентификации выявляется его идентификатор (уникальное обозначение в рамках системы).
Аутентификация — процедура проверки подлинности (что вы действительно тот человек, за которого себя выдаете).
Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.
Звучит немного запутанно, поэтому приведу пример. Предположим, вы приходите в МФЦ для того, чтобы получить какой-нибудь документ и происходит следующий диалог:
Оператор: Здравствуйте, подскажите номер вашего паспорта?
Вы: Здравствуйте, 123456 1234.
Оператор: Отлично, у вас есть паспорт с собой?
Вы: Да, есть, держите.
Оператор: Спасибо, сейчас я проверю доступно ли вам оформление этого документа. Все отлично, держите заявление на выдачу вам нового документа!
Когда вы назвали номер паспорта - произошел процесс идентификации. Когда вы дали паспорт оператору - произошла аутентификация. Когда оператор проверил доступность оформления нового документа - произошла авторизация.
При разработке сайта или приложения методы для идентификации, аутентификации и авторизации могут использоваться совершенно разные, к примеру - по логину/паролю, по номеру телефона и otp из sms, по номеру телефона и звонку и тд.
Для чего это нужно знать?
1. Авторизация - это базовая функциональность, которая есть практически в каждом приложении. Рано или поздно с авторизацией поработает каждый аналитик.
2. Авторизация влияет также и на остальные функциональности, потому что часто именно с помощью авторизации пользователь получает к ним доступ (или наоборот - не получает).
С понятием авторизации сталкивались практически все, но вот про идентификацию/аутентификацию уже наверняка слышало не так много людей. Давайте разберемся что значат все эти понятия:
Идентификация — процедура, в результате которой для субъекта идентификации выявляется его идентификатор (уникальное обозначение в рамках системы).
Аутентификация — процедура проверки подлинности (что вы действительно тот человек, за которого себя выдаете).
Авторизация — предоставление определенному лицу или группе лиц прав на выполнение определенных действий.
Звучит немного запутанно, поэтому приведу пример. Предположим, вы приходите в МФЦ для того, чтобы получить какой-нибудь документ и происходит следующий диалог:
Оператор: Здравствуйте, подскажите номер вашего паспорта?
Вы: Здравствуйте, 123456 1234.
Оператор: Отлично, у вас есть паспорт с собой?
Вы: Да, есть, держите.
Оператор: Спасибо, сейчас я проверю доступно ли вам оформление этого документа. Все отлично, держите заявление на выдачу вам нового документа!
Когда вы назвали номер паспорта - произошел процесс идентификации. Когда вы дали паспорт оператору - произошла аутентификация. Когда оператор проверил доступность оформления нового документа - произошла авторизация.
При разработке сайта или приложения методы для идентификации, аутентификации и авторизации могут использоваться совершенно разные, к примеру - по логину/паролю, по номеру телефона и otp из sms, по номеру телефона и звонку и тд.
❤10🔥3👍2
Первый месяц на работе. Что делать?!
Получить оффер — это, безусловно, важный этап, но на самом деле это только начало пути. Дальше начинается самое интересное: адаптация в новой компании, знакомство с коллективом и процессами, а главное — демонстрация своих компетенций. Первые месяцы на новом месте — это время, когда нужно максимально проявить себя и заложить фундамент для успешной карьеры в компании. Вот несколько рекомендаций о том, что стоит и чего не стоит делать в этот период:
Что нужно делать:
Активно задавай вопросы. В первые месяцы никто не ожидает, что вы будете знать всё и сразу. Напротив, задавая вопросы, вы показываете, что заинтересованы в том, чтобы разобраться в деталях и понять, как всё работает. Это поможет вам быстрее адаптироваться и избежать ошибок.
Установи контакт с коллегами. Постарайтесь познакомиться с как можно большим количеством людей, особенно с теми, с кем вам предстоит работать напрямую. Знание, кто за что отвечает, и хорошее отношение с коллегами значительно облегчат работу.
Оцени культуру компании. Обратите внимание на корпоративные ценности и нормы поведения. Понимание корпоративной культуры поможет вам лучше вписаться в коллектив и избежать ненужных конфликтов.
Слушай больше, чем говори. Первое время лучше больше наблюдать и слушать, чем активно выражать свои идеи. Это поможет вам понять, как устроены внутренние процессы и какой подход будет наиболее уместен.
Планируй свою работу. Составьте план своих задач и целей на ближайшие месяцы. Это поможет вам организовать рабочий процесс и показать руководству свою продуктивность.
Чего не стоит делать:
Не пытайся сразу всё изменить. Даже если вам кажется, что вы знаете, как сделать лучше, в первые месяцы стоит воздержаться от кардинальных предложений. Сначала разберитесь в текущих процессах, их причинах и последствиях.
Не изолируйся. Некоторые новички стараются минимизировать общение с коллегами, чтобы сосредоточиться на задачах. Однако это может создать впечатление, что вы не заинтересованы в интеграции в коллектив.
Не игнорируй обратную связь. Важно быть открытым к критике и рекомендациям. Если вам дают обратную связь, это означает, что вам хотят помочь стать лучше, а не просто указать на ошибки.
Не перегружайся. В стремлении показать себя с лучшей стороны, многие новички берутся за слишком много задач. Это может привести к стрессу и снижению качества работы. Учитесь распределять нагрузку и говорить «нет», если необходимо.
Не забывай про work-life balance. Погружение в работу — это здорово, но не забывайте о личной жизни и отдыхе. Перегруженность может привести к выгоранию, что негативно скажется на вашей карьере.
Первые месяцы — это время, когда нужно быть внимательным, гибким и открытым для нового. Это залог успешной адаптации и дальнейшего роста в компании.
Получить оффер — это, безусловно, важный этап, но на самом деле это только начало пути. Дальше начинается самое интересное: адаптация в новой компании, знакомство с коллективом и процессами, а главное — демонстрация своих компетенций. Первые месяцы на новом месте — это время, когда нужно максимально проявить себя и заложить фундамент для успешной карьеры в компании. Вот несколько рекомендаций о том, что стоит и чего не стоит делать в этот период:
Что нужно делать:
Активно задавай вопросы. В первые месяцы никто не ожидает, что вы будете знать всё и сразу. Напротив, задавая вопросы, вы показываете, что заинтересованы в том, чтобы разобраться в деталях и понять, как всё работает. Это поможет вам быстрее адаптироваться и избежать ошибок.
Установи контакт с коллегами. Постарайтесь познакомиться с как можно большим количеством людей, особенно с теми, с кем вам предстоит работать напрямую. Знание, кто за что отвечает, и хорошее отношение с коллегами значительно облегчат работу.
Оцени культуру компании. Обратите внимание на корпоративные ценности и нормы поведения. Понимание корпоративной культуры поможет вам лучше вписаться в коллектив и избежать ненужных конфликтов.
Слушай больше, чем говори. Первое время лучше больше наблюдать и слушать, чем активно выражать свои идеи. Это поможет вам понять, как устроены внутренние процессы и какой подход будет наиболее уместен.
Планируй свою работу. Составьте план своих задач и целей на ближайшие месяцы. Это поможет вам организовать рабочий процесс и показать руководству свою продуктивность.
Чего не стоит делать:
Не пытайся сразу всё изменить. Даже если вам кажется, что вы знаете, как сделать лучше, в первые месяцы стоит воздержаться от кардинальных предложений. Сначала разберитесь в текущих процессах, их причинах и последствиях.
Не изолируйся. Некоторые новички стараются минимизировать общение с коллегами, чтобы сосредоточиться на задачах. Однако это может создать впечатление, что вы не заинтересованы в интеграции в коллектив.
Не игнорируй обратную связь. Важно быть открытым к критике и рекомендациям. Если вам дают обратную связь, это означает, что вам хотят помочь стать лучше, а не просто указать на ошибки.
Не перегружайся. В стремлении показать себя с лучшей стороны, многие новички берутся за слишком много задач. Это может привести к стрессу и снижению качества работы. Учитесь распределять нагрузку и говорить «нет», если необходимо.
Не забывай про work-life balance. Погружение в работу — это здорово, но не забывайте о личной жизни и отдыхе. Перегруженность может привести к выгоранию, что негативно скажется на вашей карьере.
Первые месяцы — это время, когда нужно быть внимательным, гибким и открытым для нового. Это залог успешной адаптации и дальнейшего роста в компании.
👍15🔥4❤3👌1🐳1