Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
ООП - объектно-ориентированный подход к программированию.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Паттерны интеграций (технологии передачи данных)
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Проектирование интеграции = частный случай системного анализа.
Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком))) и уметь переключать контексты.
Предыдущие потоки курса интеграции нам показали, что мы учим не только проектированию, но и подходу к задачам аналитика. Показываем системный анализ через интеграцию. Создаём систему знаний, навыков, что на выходе расширяет границы у аналитика.
Надеюсь всё таки границы знаний, а не сознания))) А когда ты видишь картину целиком, ты становишься более уверенным и хочется брать больше крутых задач.
Что и происходит с нашими учениками) Многие меняют проекты, меняют работу. И иногда меня не только карьерной феей называют, но и айти ведьмой)
На прошлом потоке, я забеспокоилась куда пропала участница, а оказалось, что в середине курса она уже поменяла работу. Вот так оно работает)))
Также есть те, кто только начинает свой путь в системном анализе и хочет понять надо оно или нет, куда дальше расти, что изучать. И тоже находят ответы на свои вопросы.
Есть те кто решил, что не надо мне всё это, но до конца курса всё таки дошли. И выбрали бизнес направление.
Каждый получил свой результат, и заберёт столько сколько сможет (все презентации, материалы и записи остаются в доступе навсегда).
Мне хочется, чтобы на проектах работали специалисты, которые могут проектировать качественные решения и делать наш мир лучше. А я смогу пользоваться более качественными сервисами)))
Что же нужно сделать, чтобы спроектировать интеграцию?
Если читали посты выше, то уже знаете:
✅1. Разобраться в том, для чего и зачем нужна интеграция. В каких процессах участвует. Спроектировать интеграционные сценарии на пользовательском уровне, их превратить в системный уровень. И зафиксировать организацию обмена данными под процессы.
✅2. Подключить знания по ООП. Взять предметку, выделить бизнес-объекты, понять их жизненный цикл. И выявить то как интеграция влияет на жизненный цикл объекта, как переключает статус, и как этот статус влияет на другие объекты и процессы.
✅3. Спуститься на уровень технологий и данных. И понять, как именно будут передаваться данные, как обрабатывать ошибки, какой паттерн интеграции будет. И описать маппинг данных нашего объекта при передачи от системы источник и систему приёмник.
Вроде бы всё понятно.
Но знать и кивать головой — это одно. А когда приступаешь к реализации — вот тут начинаются танцы с бубнами...
С какой стороны подходить?
Где знаю, а где нет, а может всё знаю?
А что должен делать я, а что нет?
Тратишь кучу времени и сил... Книги это хорошо, но свой опыт и опыт коллег ещё лучше.
У нас для вас хорошая новость))
Мы готовы делиться с вами своим опытом интеграционных проектов!
Запускаем 🚀набор на поток курса интеграции.
И я бы его уже переименовала в🔄 системный анализ в интеграции.
🔥 Старт 15 февраля!
(Для тех кто не успевает на этот поток, скажу, что на весну мы планируем ещё поток).
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
✅Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
✅Блок 2 - use cases, онтологическая модель предметной области, state machine
✅Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
✅Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
✅Блок 5 - введение в OSI модель сети, REST API, json
✅Блок 6 - SOAP, xml
✅Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
✅Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Запись на курс
➡️ https://sup.expert/
Для тех кто приходил ко мне на менторство, на китайскую ручку, для вас действует скидка 10%
Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком))) и уметь переключать контексты.
Предыдущие потоки курса интеграции нам показали, что мы учим не только проектированию, но и подходу к задачам аналитика. Показываем системный анализ через интеграцию. Создаём систему знаний, навыков, что на выходе расширяет границы у аналитика.
Что и происходит с нашими учениками) Многие меняют проекты, меняют работу. И иногда меня не только карьерной феей называют, но и айти ведьмой)
На прошлом потоке, я забеспокоилась куда пропала участница, а оказалось, что в середине курса она уже поменяла работу. Вот так оно работает)))
Также есть те, кто только начинает свой путь в системном анализе и хочет понять надо оно или нет, куда дальше расти, что изучать. И тоже находят ответы на свои вопросы.
Есть те кто решил, что не надо мне всё это, но до конца курса всё таки дошли. И выбрали бизнес направление.
Каждый получил свой результат, и заберёт столько сколько сможет (все презентации, материалы и записи остаются в доступе навсегда).
Мне хочется, чтобы на проектах работали специалисты, которые могут проектировать качественные решения и делать наш мир лучше. А я смогу пользоваться более качественными сервисами)))
Что же нужно сделать, чтобы спроектировать интеграцию?
Если читали посты выше, то уже знаете:
✅1. Разобраться в том, для чего и зачем нужна интеграция. В каких процессах участвует. Спроектировать интеграционные сценарии на пользовательском уровне, их превратить в системный уровень. И зафиксировать организацию обмена данными под процессы.
✅2. Подключить знания по ООП. Взять предметку, выделить бизнес-объекты, понять их жизненный цикл. И выявить то как интеграция влияет на жизненный цикл объекта, как переключает статус, и как этот статус влияет на другие объекты и процессы.
✅3. Спуститься на уровень технологий и данных. И понять, как именно будут передаваться данные, как обрабатывать ошибки, какой паттерн интеграции будет. И описать маппинг данных нашего объекта при передачи от системы источник и систему приёмник.
Вроде бы всё понятно.
Но знать и кивать головой — это одно. А когда приступаешь к реализации — вот тут начинаются танцы с бубнами...
С какой стороны подходить?
Где знаю, а где нет, а может всё знаю?
А что должен делать я, а что нет?
Тратишь кучу времени и сил... Книги это хорошо, но свой опыт и опыт коллег ещё лучше.
У нас для вас хорошая новость))
Мы готовы делиться с вами своим опытом интеграционных проектов!
Запускаем 🚀набор на поток курса интеграции.
И я бы его уже переименовала в
(Для тех кто не успевает на этот поток, скажу, что на весну мы планируем ещё поток).
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
✅Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
✅Блок 2 - use cases, онтологическая модель предметной области, state machine
✅Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
✅Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
✅Блок 5 - введение в OSI модель сети, REST API, json
✅Блок 6 - SOAP, xml
✅Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
✅Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Запись на курс
Для тех кто приходил ко мне на менторство, на китайскую ручку, для вас действует скидка 10%
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Наташа Косинова. Варю айти СУП pinned «Проектирование интеграции = частный случай системного анализа. Действительно, в чем же сложность проектирования интеграции? Да, в том, что приходиться все знания, на разных уровнях собирать в систему и выдавать результат. Быть реально системным аналитиком)))…»
Обожаю работать с аналитиками))
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой🔝 правил, которые помогают мне определить идеального клиента-аналитика:
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.Мест для выпендивания можно найти дофига других)))
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.Сделай с нуля из меня тим лида, чтобы я зарабатывал полляма и ничего не делал, это не ко мне))
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста😎
#интеграция #челлендж #топ #клиенты
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста
#интеграция #челлендж #топ #клиенты
Please open Telegram to view this post
VIEW IN TELEGRAM
Как выбрать решение по интеграции?
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территориюподвинься щенок, не задавай мне такие вопросы
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,подозрительно на которые нет ответов. Как-то на проекте я спросила, почему купили шину IBM, а не ORACLE? Мне сказали, тсссс! Молчи! Нашему инвестору IBM красивую презентацию показали и ужин устроили и ещё то, чего мы не знаем. И не говорим вслух...
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территорию
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
sup.expert
Курс по интеграции
Я тут пришла к выводу, что самые крутые инструменты начинаешь ценить за их простоту, только спустя годы работы)))
Блок-схема, ну фу, какое-то тупое название из 90-х, а DFD чет так просто, фу для детей.
Но в этой простоте гениальность💔
Блок-схема, ну фу, какое-то тупое название из 90-х, а DFD чет так просто, фу для детей.
Но в этой простоте гениальность
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥 Телеграм для Системного/Бизнес аналитика
Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера команд.
Специально для вас сделала подборку материала, изучив которую, вы сможете найти ответы на часто возникающие вопросы‼️:
Проектирование интеграций:
✅Чек-лист интеграции - проверь себя
✅Интеграционные сценарии - ключевой артефакт интеграции
✅ООП - основа проектирования
✅Паттерны интеграции - по типу передачи данных
Хочется больше знать и уметь в теме интеграции приходи на курс - https://sup.expert/ (следующий поток с 25 апреля)
------------
Для тех кто только начинает карьеру, и не знает, что делать, как себя позиционировать и выбрать нужное направление?
✅Поможет статья какие есть виды аналитиков?
✅И видео запись менторской сессии - про направления в айти.
✅Чем продукт отличается от проекта?
-----------------------------
Для тех кто сталкивается с новым проектом и не знает с чего начать?
✅Вебинар погружение в предметную область.
Кто давно в отрасли, но не понимает, как организовать базу знаний и выбрать нужные, именно вам артефакты анализа, инструменты, подходы - ответит вебинар "Пирамида артефактов анализа для IT-проекта".
Если вы менеджер продукта/проекта и не понимаете нужен ли вам аналитик? Или же вы аналитик, которому нужно "продать" команде свою роль - то ознакомьтесь с
✅вебинаром "Зачем аналитик проекту?"
------------
Также раз в месяц провожу тренинг по основам разработки требований "Китайская ручка"
О чем тренинг можно ознакомиться в посте.
Регистрация по ссылке - https://sup.expert/pen
Если у вас остались вопросы, есть предложения, или вам нужен тренинг для команда анализа, то ➡️
пишите мне напрямую и приходите на менторство)
Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера команд.
Специально для вас сделала подборку материала, изучив которую, вы сможете найти ответы на часто возникающие вопросы‼️:
Проектирование интеграций:
✅Чек-лист интеграции - проверь себя
✅Интеграционные сценарии - ключевой артефакт интеграции
✅ООП - основа проектирования
✅Паттерны интеграции - по типу передачи данных
Хочется больше знать и уметь в теме интеграции приходи на курс - https://sup.expert/ (следующий поток с 25 апреля)
------------
Для тех кто только начинает карьеру, и не знает, что делать, как себя позиционировать и выбрать нужное направление?
✅Поможет статья какие есть виды аналитиков?
✅И видео запись менторской сессии - про направления в айти.
✅Чем продукт отличается от проекта?
-----------------------------
Для тех кто сталкивается с новым проектом и не знает с чего начать?
✅Вебинар погружение в предметную область.
Кто давно в отрасли, но не понимает, как организовать базу знаний и выбрать нужные, именно вам артефакты анализа, инструменты, подходы - ответит вебинар "Пирамида артефактов анализа для IT-проекта".
Если вы менеджер продукта/проекта и не понимаете нужен ли вам аналитик? Или же вы аналитик, которому нужно "продать" команде свою роль - то ознакомьтесь с
✅вебинаром "Зачем аналитик проекту?"
------------
Также раз в месяц провожу тренинг по основам разработки требований "Китайская ручка"
О чем тренинг можно ознакомиться в посте.
Регистрация по ссылке - https://sup.expert/pen
Если у вас остались вопросы, есть предложения, или вам нужен тренинг для команда анализа, то ➡️
пишите мне напрямую и приходите на менторство)
sup.expert
Курс по интеграции
Наташа Косинова. Варю айти СУП pinned «🔥 Телеграм для Системного/Бизнес аналитика Подписывайся на канал и забирай материалы по проектированию, здоровому развитию себя как айти - аналитика, от эксперта с опытом более 17 лет, прошедшего путь от джуна до тим лида системного анализа, ментора, тренера…»
Я чувствую себя ненужным, лишним.
Непонятно зачем я команде?
Я пыталась вспомнить в какой момент моей трудовой деятельности посетило меня такое чувство. Пришла к выводу, что в самом начале, как пришла на проект, так и прилетел у меня вопрос - а что я тут делаю? Я же никому не нужна.
Когда уровень стал выше и смелость, и опыт, дали возможность сразу сходу говорить о том, что не так, стало легче.
Но когда ты приходишь в новую команду - ощущение ненужности, это прям как холодный душ. Бодрит!
Что с этим делать?
Во первых, если вы так чувствуете, значит это действительно так! И все эти разговоры - да ну че ты, всё пройдёт... И т.д. просто откладывание проблемы.
✅Так что первое признаем ситуацию.
✅Второе ищем причины, почему аналитик не нужен команде.
Предположим, что реально не нужен. Тогда вопрос к руководству - зачем мучаете специалиста?
Если нужен, в чем могут быть причины:
✔️ 1.Команда никогда не работала с аналитиком
✔️ 2.Команда не доверяет аналитику (прошлый негативный опыт мешает, сходил я тут к стоматологу, не понравилось, больше не пойду... Ну камон ...)
✔️ 3.Руководство не понимает зачем нужен аналитик (ну нам сказали, мы взяли)
✔️ 4.Все привыкли работать по процессам, которые не подразумевают анализ. И в итоге аналитик, где-то в конце подключается к процессу разработки.
✔️ 5.Аналитику дают не его задачи. Всё что угодно. Менеджерские, тех поддержка, тех писательство, тестирование, дизайн, а ещё я крестиком вышивать могу и борщ готовить))
✔️ 6.Аналитику часто меняют задачу. Вот на тебе, она уже просрочена. Упс, не успел. На другую, она тоже просрочена. Ай, ну что ж ты. Надо как-то быстрее переключаться с задачи на задачу. Контекст разный? Ну что ж ты нерасторопный такой, ты же профессионал, переключайся быстрее, мы тебе много деняг платим. Итог - нет видимого результата, как челночный бег, стоишь на месте, при этом жутко устал.
✔️ 7.Аналитик один, грустит и превращается в депрессивного странного чувака.
✔️ 8.Аналитик "не пришей кобыле хвост", пришёл к заказчику, тот его послал, он послался. Пришёл к команде, его послали, он послался. Пришёл к руководству, руководство сказало - не ной, не до тебя сейчас, иди найди оружие в бою. Ты сильный, я в тебя верю. Но потом спрошу!
Список можно пополнить своей историей в комментариях 👇
Дальше торг, депрессия, принятие, заявление об увольнение...
Что можно с этим сделать?
📍1.Начать говорить о проблеме и о том, что не так. Фиксировать все договорённости отчётами, датами, указывая имена.
📍2.Заручиться поддержкой руководства. Если вас взяли в команду, значит компания уже потратила время, деньги и ресурсы сотрудников, и вы нужны. Если не нужны, то это другой разговор.
📍3.Просить не менять контекст, не перекидывать с задачи на задачу. Дать шанс показать результат.
📍4.Общаться, и ещё раз общаться.
📍5. Своим результатом продавать заказчику, команде, руководству анализ. К сожалению это так. И только конкретным результатом, это можно показать. Тем более сейчас уровень компетенции падает и у многих разработчиков аллергия на аналитиков.
📍6.Выстраивать процесс так, чтобы аналитик опережал разработку на спринт, или хотя бы на половину спринта. Иначе он не аналитик, а техпис или ещё кто-то. Занять своё место в общем процессе.
📍7.Действительно заниматься своим делом. На стартапах все делают всё. И это чревато тем, что своими обязанностями вы не будете заниматься. И всем будет удобно, кроме вас. Закроете тестера, тех поддержку, секретаря, дизайнера. Если выхода нет. Можно наглядно показать, посчитав сколько времени вы тратите на другие направления. Я как-то посчитала сколько я работаю как HR, и как тим лид анализа. И я такой дорогой HR выхожу. Смысл тогда меня, как тим лида в компании? Когда переводишь разговор в русло денег, времени, ресурса, всё становится по местам и быстро с меня сняли работу HR и нашли спеца))
Непонятно зачем я команде?
Я пыталась вспомнить в какой момент моей трудовой деятельности посетило меня такое чувство. Пришла к выводу, что в самом начале, как пришла на проект, так и прилетел у меня вопрос - а что я тут делаю? Я же никому не нужна.
Когда уровень стал выше и смелость, и опыт, дали возможность сразу сходу говорить о том, что не так, стало легче.
Но когда ты приходишь в новую команду - ощущение ненужности, это прям как холодный душ. Бодрит!
Что с этим делать?
Во первых, если вы так чувствуете, значит это действительно так! И все эти разговоры - да ну че ты, всё пройдёт... И т.д. просто откладывание проблемы.
✅Так что первое признаем ситуацию.
✅Второе ищем причины, почему аналитик не нужен команде.
Предположим, что реально не нужен. Тогда вопрос к руководству - зачем мучаете специалиста?
Если нужен, в чем могут быть причины:
Список можно пополнить своей историей в комментариях 👇
Дальше торг, депрессия, принятие, заявление об увольнение...
Что можно с этим сделать?
📍1.Начать говорить о проблеме и о том, что не так. Фиксировать все договорённости отчётами, датами, указывая имена.
📍2.Заручиться поддержкой руководства. Если вас взяли в команду, значит компания уже потратила время, деньги и ресурсы сотрудников, и вы нужны. Если не нужны, то это другой разговор.
📍3.Просить не менять контекст, не перекидывать с задачи на задачу. Дать шанс показать результат.
📍4.Общаться, и ещё раз общаться.
📍5. Своим результатом продавать заказчику, команде, руководству анализ. К сожалению это так. И только конкретным результатом, это можно показать. Тем более сейчас уровень компетенции падает и у многих разработчиков аллергия на аналитиков.
📍6.Выстраивать процесс так, чтобы аналитик опережал разработку на спринт, или хотя бы на половину спринта. Иначе он не аналитик, а техпис или ещё кто-то. Занять своё место в общем процессе.
📍7.Действительно заниматься своим делом. На стартапах все делают всё. И это чревато тем, что своими обязанностями вы не будете заниматься. И всем будет удобно, кроме вас. Закроете тестера, тех поддержку, секретаря, дизайнера. Если выхода нет. Можно наглядно показать, посчитав сколько времени вы тратите на другие направления. Я как-то посчитала сколько я работаю как HR, и как тим лид анализа. И я такой дорогой HR выхожу. Смысл тогда меня, как тим лида в компании? Когда переводишь разговор в русло денег, времени, ресурса, всё становится по местам и быстро с меня сняли работу HR и нашли спеца))
Please open Telegram to view this post
VIEW IN TELEGRAM
Я чувствую себя ненужным, лишним.
Непонятно зачем я команде?
Начало 👆
-----------------
📍8.Может быть так, что задачи вам дают не по вашим компетенциям. Не стесняйтесь этот момент узнавать. Это может быть круто, а может быть бомба замедленного действия. Если меня поставить на сцену балета большого театра, я получу огромный шок. И никому от этого не будет хорошо. И ещё и спрос будет, а че не станцевала?
Возможно я ещё что-то упустила. И вы можете предложить свой вариант в комментариях 👇
Знаю что у многих аналитиков возникают такие эмоции, проблемы. Вы не одиноки, быть аналитиком сложно, и да, действительно работа на проектах, связана со сложными процессами высокой неопределённости, как у заказчика, так и внутри команды. С этим можно и нужно работать, и начинать говорить. Пробовать менять. Вода камень точит. Главное понимать свои силы, реальность, и заручаться поддержкой руководства. Ибо аналитик не всегда может влиять сам на процессы. Может говорить, и не всегда его могут слушать. Но надеюсь, что вам повезёт и вас услышат)))
Ой ну тебе там просто так рассуждать, ты же на опыте... Ну да, конечно очень просто... Никто не знает сколько слёз было пролито, со словами зачем я всё это делаю???... С вопросами руководству - зачем вам я?... И мыслями по утрам - больше не могу... С наездами и кознями от разработчиков) было и такое... Кнопки на стул не подкладывали, может конечно в кружку плевали, я теперь это не узнаю, а вот доступ закрывали, ответы не давали, в игнор кидали, и истерики устраивали))
P. S. Вам в помощь вебинар зачем аналитик проекту. Можно найти себе инсайты.
#системныйаналитик #проблемынапроекте #рольаналитика #мойопыт #моемнение
Непонятно зачем я команде?
Начало 👆
-----------------
📍8.Может быть так, что задачи вам дают не по вашим компетенциям. Не стесняйтесь этот момент узнавать. Это может быть круто, а может быть бомба замедленного действия. Если меня поставить на сцену балета большого театра, я получу огромный шок. И никому от этого не будет хорошо. И ещё и спрос будет, а че не станцевала?
Возможно я ещё что-то упустила. И вы можете предложить свой вариант в комментариях 👇
Знаю что у многих аналитиков возникают такие эмоции, проблемы. Вы не одиноки, быть аналитиком сложно, и да, действительно работа на проектах, связана со сложными процессами высокой неопределённости, как у заказчика, так и внутри команды. С этим можно и нужно работать, и начинать говорить. Пробовать менять. Вода камень точит. Главное понимать свои силы, реальность, и заручаться поддержкой руководства. Ибо аналитик не всегда может влиять сам на процессы. Может говорить, и не всегда его могут слушать. Но надеюсь, что вам повезёт и вас услышат)))
P. S. Вам в помощь вебинар зачем аналитик проекту. Можно найти себе инсайты.
#системныйаналитик #проблемынапроекте #рольаналитика #мойопыт #моемнение
"Молодым преградили путь в айти" - Очень мощное название у статьи, респект журналистам))) Порассуждаю.
✅Во первых, будем честны, джунов никогда, нигде не любили. Но как тебе стать сразу спецом то, без роста и развития? Во время учёбы в институте, фактически уже начинать практику. После окончания института в далёком 2006 года, я год искала работу со своим красным дипломом, с релевантным образованием. Тогда везде нужен был английский, у меня был технический французский. Мне отказывали все, пока команда шинной интеграции не предложила мне быть их тех писателем. А через пару месяцев они уже поняли, мой масштаб)))
✅Во вторых, я как Тим Лид брала джунов, но кого? Мне проще взять выпускника вуза, у которого горят глаза, есть база в том числе и по системному анализу, есть фундамент. Коммуникация проще, гибкость огромная, лепить могу что угодно, под свои проекты и задачи. Сопротивление, споры уже не будут, как с взрослым, состоявшимся человеком. Тут win - win. Я разгружаю сеньора, за счёт того, что рутину отдаю джуну и обучаю джуна. Как-то в отделе у меня было 4 джуна, все выстрелили и сейчас хорошие сеньоры, Лиды.
✅В третьих, сейчас компании приходят сразу в вузы, вот знаю по айти-центру МАИ, что выпускники до защиты диплома уже все трудоустроены. Конечно есть площадки, которые обещают 100% трудоустройство, по ним открытой статистики нет. Действительно, поэтому компании начинают делать свои центры подготовки для стажёров. И логично снимают зарплату на входе.
По поводу статьи. Честно говоря, всё очень логично. Курсы, наставники, менторы, показывают верх айсберга, а когда человек попадает в реальный проект, то айсберг всплывает и тогда уже становится очень тяжело.
При этом для меня странным ещё является тот факт, что, ну накрутил ты годы опыта в резюме, и что? Грамотный специалист на собеседование может за пару задач понять твой реальный уровень.
✅Тогда тут четвёртый вывод - а кто собеседует? Если компания потом оказывается в положение - есть сотрудник, но он ни на что негоден, и что с ним делать?
✅В пятых, я прихожу к выводу, что джуны никуда не исчезнут. Рынок и отбор перестроиться, что уже происходит. И мифы про быстрые деньги, легко в айти, тоже уже уходят в реальность.
P. S. Откуда у коммерсанта цифра, что нужно 2 млн айтишников на рынке, не очень понятно. И на каком рынке? СНГ, Россия? Мир?
Текст статьи:
https://www.kommersant.ru/doc/6494785
#карьера #войтивайти #моемнение #рынок #собеседования
А что вы скажете?
Тим Лиды, берете джунов?
Если да, то каких?
😎
✅Во первых, будем честны, джунов никогда, нигде не любили. Но как тебе стать сразу спецом то, без роста и развития? Во время учёбы в институте, фактически уже начинать практику. После окончания института в далёком 2006 года, я год искала работу со своим красным дипломом, с релевантным образованием. Тогда везде нужен был английский, у меня был технический французский. Мне отказывали все, пока команда шинной интеграции не предложила мне быть их тех писателем. А через пару месяцев они уже поняли, мой масштаб)))
✅Во вторых, я как Тим Лид брала джунов, но кого? Мне проще взять выпускника вуза, у которого горят глаза, есть база в том числе и по системному анализу, есть фундамент. Коммуникация проще, гибкость огромная, лепить могу что угодно, под свои проекты и задачи. Сопротивление, споры уже не будут, как с взрослым, состоявшимся человеком. Тут win - win. Я разгружаю сеньора, за счёт того, что рутину отдаю джуну и обучаю джуна. Как-то в отделе у меня было 4 джуна, все выстрелили и сейчас хорошие сеньоры, Лиды.
✅В третьих, сейчас компании приходят сразу в вузы, вот знаю по айти-центру МАИ, что выпускники до защиты диплома уже все трудоустроены. Конечно есть площадки, которые обещают 100% трудоустройство, по ним открытой статистики нет. Действительно, поэтому компании начинают делать свои центры подготовки для стажёров. И логично снимают зарплату на входе.
По поводу статьи. Честно говоря, всё очень логично. Курсы, наставники, менторы, показывают верх айсберга, а когда человек попадает в реальный проект, то айсберг всплывает и тогда уже становится очень тяжело.
При этом для меня странным ещё является тот факт, что, ну накрутил ты годы опыта в резюме, и что? Грамотный специалист на собеседование может за пару задач понять твой реальный уровень.
✅Тогда тут четвёртый вывод - а кто собеседует? Если компания потом оказывается в положение - есть сотрудник, но он ни на что негоден, и что с ним делать?
✅В пятых, я прихожу к выводу, что джуны никуда не исчезнут. Рынок и отбор перестроиться, что уже происходит. И мифы про быстрые деньги, легко в айти, тоже уже уходят в реальность.
P. S. Откуда у коммерсанта цифра, что нужно 2 млн айтишников на рынке, не очень понятно. И на каком рынке? СНГ, Россия? Мир?
Текст статьи:
https://www.kommersant.ru/doc/6494785
#карьера #войтивайти #моемнение #рынок #собеседования
А что вы скажете?
Тим Лиды, берете джунов?
Если да, то каких?
😎
Коммерсантъ
Молодым преградили путь в IT
Почему работодатели стали реже нанимать junior-специалистов
Про коуча или как я дошла до жизни такой...
Хотела вам рассказать, почему я начала работать с коучем.
Да, можно говорить про то, что коуч - это какой-то сферический конь в вакууме, и весь этот успешный успех из нельзяграм направление коучинга сильно обесценил и добавил флёр инфоцыгантва. Я сама, например, не очень верю в агил коучей (хотя это другое), и мне было интересно разобраться, а чем же хороши коучи, и кто из них действительно профессионалы и помогут добиться результата. При этом я же вижу хороших специалистов и понимаю, что психологию никто не отменяет, что в айти, собранная команда людей, должна начать приносить результат. И начать работать эффективно и так сказать, пройти период претирки может помочь коуч.
Да, коуч - это тренер. Я занималась разными видами спорта с тренерами, и работала с отличными тренерами. И мне импонирует направление тренерства.
Почему я пошла к коучу?
Моё перманентное состояние последних лет 3 - это море идей, которые лежат в ящике стола. Чтобы их воплотить в жизнь, что я делаю? Ничего!
Легко сказать, просто иди и сделай. Сложно действительно пойти и сделать.
Когда я сама пошла учиться на коуча, после первого потока курса пришла к выводу, что сам подход обучения не мой. Я не могу тупо брать практики и инструменты, и их применять бездумно. При этом радоваться. Вау, как клёво! Что блин?!!
Когда спрашиваешь доказательства, истоки, фундамент, причины возникновения у ведущего курс, он либо не знает, что ответить, либо уходит от ответа, что мол в следующем блоке узнаете, а стоит новый блок 100500 денЯг. Р-разочарование.
И я пришла к выводу, что коуч - это психолог, и психологии там много. А если учиться серьёзно, то это несколько лет точно.
Так вот, я и начала искать коуча, с образованием психолога. Плюс человека, которому я могу доберять и уважать, быть наравных. И конечно интересно работать со специалистом, который в твоей сфере мало что понимает, но цель состоит в том, чтобы делать мои идеи, воплощать в жизнь.
Так я и нашла Евгению Кутузову (подписывайтесь на канал Евгении), коуча с сертификатом, который серьёзно подходит к делу и параллельно учиться на психолога.
Какие выводы, я могу сделать, какой результат нашей работы есть, я опишу в следующих постах 😎
#коучинг #мойопыт #моемнение #саморазвитие #самомотивация
Хотела вам рассказать, почему я начала работать с коучем.
Да, можно говорить про то, что коуч - это какой-то сферический конь в вакууме, и весь этот успешный успех из нельзяграм направление коучинга сильно обесценил и добавил флёр инфоцыгантва. Я сама, например, не очень верю в агил коучей (хотя это другое), и мне было интересно разобраться, а чем же хороши коучи, и кто из них действительно профессионалы и помогут добиться результата. При этом я же вижу хороших специалистов и понимаю, что психологию никто не отменяет, что в айти, собранная команда людей, должна начать приносить результат. И начать работать эффективно и так сказать, пройти период претирки может помочь коуч.
Да, коуч - это тренер. Я занималась разными видами спорта с тренерами, и работала с отличными тренерами. И мне импонирует направление тренерства.
Почему я пошла к коучу?
Моё перманентное состояние последних лет 3 - это море идей, которые лежат в ящике стола. Чтобы их воплотить в жизнь, что я делаю? Ничего!
Легко сказать, просто иди и сделай. Сложно действительно пойти и сделать.
Когда я сама пошла учиться на коуча, после первого потока курса пришла к выводу, что сам подход обучения не мой. Я не могу тупо брать практики и инструменты, и их применять бездумно. При этом радоваться. Вау, как клёво! Что блин?!!
Когда спрашиваешь доказательства, истоки, фундамент, причины возникновения у ведущего курс, он либо не знает, что ответить, либо уходит от ответа, что мол в следующем блоке узнаете, а стоит новый блок 100500 денЯг. Р-разочарование.
И я пришла к выводу, что коуч - это психолог, и психологии там много. А если учиться серьёзно, то это несколько лет точно.
Так вот, я и начала искать коуча, с образованием психолога. Плюс человека, которому я могу доберять и уважать, быть наравных. И конечно интересно работать со специалистом, который в твоей сфере мало что понимает, но цель состоит в том, чтобы делать мои идеи, воплощать в жизнь.
Так я и нашла Евгению Кутузову (подписывайтесь на канал Евгении), коуча с сертификатом, который серьёзно подходит к делу и параллельно учиться на психолога.
Какие выводы, я могу сделать, какой результат нашей работы есть, я опишу в следующих постах 😎
#коучинг #мойопыт #моемнение #саморазвитие #самомотивация
Telegram
Евгения Кутузова | Оберег от выгорания
Хватит выгорать! Вы разрушаете озоновый слой!
Коуч/Психолог
Помогу найти и обезвредить причины тревожности, чтобы не довести себя до эмоционального выгорания
Сессия-Знакомство: @Evgenia_feory
Коуч/Психолог
Помогу найти и обезвредить причины тревожности, чтобы не довести себя до эмоционального выгорания
Сессия-Знакомство: @Evgenia_feory
Коллеги, аналитики, подписчики. Я переживаю сложный период моей жизни.
И не вижу смыслы выдавать полупосты или писать, потому что нужно.
Но я продолжаю вести свою деятельность, в том объёме насколько мне хватает ресурсов. И с радостью продолжаю делиться мыслями, опытом, знаниями.
Ко мне поступают вопросы насчёт курса и тренинга.
---------------------------
Следующий поток курса "Основы проектирования интеграции информационных систем", будем стартовать
16 мая 🔥 (перенесли старт из-за майских праздников).
Вы можете уже сейчас бронировать для себя места и для своих коллег. С юридическими лицами я также работаю.
Количество мест с обратной связью, у нас ограничено, мы делаем это специально, чтобы уделить каждому должное внимание и давать развёрнутые комментарии.
Описание курса и форму для заявок, вы найдёте на нашем Лендинге https://sup.expert/
---------------------------
Поток тренинга "Китайская ручка"- основы разработки требований к ПО, ориентировочно планирую провести
в даты 20, 21 апреля 🔥. Тренинг люблю и уже есть участники, но не хочу проводить абы как, поэтому набираюсь физических и моральных сил.
Лендинг тренинга -
https://sup.expert/pen
---------------------------
По любым вопросам, предложениям, как всегда открыта для вас.
И ещё раз хочу поблагодарить мою аудиторию за понимание, поддержку.
Это действительно очень ценно для меня ❤️
И не вижу смыслы выдавать полупосты или писать, потому что нужно.
Но я продолжаю вести свою деятельность, в том объёме насколько мне хватает ресурсов. И с радостью продолжаю делиться мыслями, опытом, знаниями.
Ко мне поступают вопросы насчёт курса и тренинга.
---------------------------
Следующий поток курса "Основы проектирования интеграции информационных систем", будем стартовать
16 мая 🔥 (перенесли старт из-за майских праздников).
Вы можете уже сейчас бронировать для себя места и для своих коллег. С юридическими лицами я также работаю.
Количество мест с обратной связью, у нас ограничено, мы делаем это специально, чтобы уделить каждому должное внимание и давать развёрнутые комментарии.
Описание курса и форму для заявок, вы найдёте на нашем Лендинге https://sup.expert/
---------------------------
Поток тренинга "Китайская ручка"- основы разработки требований к ПО, ориентировочно планирую провести
в даты 20, 21 апреля 🔥. Тренинг люблю и уже есть участники, но не хочу проводить абы как, поэтому набираюсь физических и моральных сил.
Лендинг тренинга -
https://sup.expert/pen
---------------------------
По любым вопросам, предложениям, как всегда открыта для вас.
И ещё раз хочу поблагодарить мою аудиторию за понимание, поддержку.
Это действительно очень ценно для меня ❤️
sup.expert
Курс по интеграции
Я боюсь, что разработчики решат, что я дурачок.
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований
Please open Telegram to view this post
VIEW IN TELEGRAM
Названия систем, ошибок, параметров и т.д.
Я помню, как в одной компании были интересные названия айти систем, старые, древние имена Богинь.
А тут один аналитик рассказал, как у них программист ошибки в системе назвал именами своих детей. Это забавно и мило.
Я поняла, что я часто в примерах на занятиях, называю имена своего дедушки, дядей. Это интересно, и что-то в этом есть. Воспоминания о своих близких, предках, роде. Имена, которые в честь кого либо.
А ведь аналитики могут такие вещи делать влёгкую))
Не брать имена героев сериала, а то что ближе к нам. Хотя, почему нет, Факундо Арано, отличное уникальное имя для РФ))
И старорусские имена часто стали встречаться.
А какие вы встречали имена, названия в проектах в айти ландшафтах?
Или на тестовых стендах?
#мысливслух #названиясистем #мирвокруг
Я помню, как в одной компании были интересные названия айти систем, старые, древние имена Богинь.
А тут один аналитик рассказал, как у них программист ошибки в системе назвал именами своих детей. Это забавно и мило.
Я поняла, что я часто в примерах на занятиях, называю имена своего дедушки, дядей. Это интересно, и что-то в этом есть. Воспоминания о своих близких, предках, роде. Имена, которые в честь кого либо.
А ведь аналитики могут такие вещи делать влёгкую))
Не брать имена героев сериала, а то что ближе к нам. Хотя, почему нет, Факундо Арано, отличное уникальное имя для РФ))
И старорусские имена часто стали встречаться.
А какие вы встречали имена, названия в проектах в айти ландшафтах?
Или на тестовых стендах?
#мысливслух #названиясистем #мирвокруг
Для тех кто любит запрыгнуть в последний вагон, и с пользой провести предстоящие выходные приглашаю на тренинг китайская ручка.
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
sup.expert
"Китайская ручка"
Аналитик исследует проблему и проектирует решение на языке требований.
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни