Как я проектирую интеграцию.
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея🤩 , понимаю, что уже несколько выпускников наших потоков курса поменяли работу и выросли в грейдах.
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний📈
Приходите к нам на интеграцию➡️ https://sup.expert/
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний
Приходите к нам на интеграцию
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Наташа Косинова. Варю айти СУП
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
Ошибки проектирования сценариев взаимодействия систем при их интеграции.
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
Через 2 недели стартует, последний в этом году, поток интеграции.
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 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 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте➡️ https://sup.expert/
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу🔽
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 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 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Аналитик, догони разработку!
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанноголошадь аналитика, который уже на грани срыва, где глаза наполняются слезами и он не понимает зачем он нужен, что он тут делает и весь мир тлен.
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"😵💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (кто-то скажет, он нам не нужен, хорошо, тогда не нанимайте подобных специалистов и не ждите от них результатов ). Аналитик занимается проектированием, а оно в свою очередь нужно перед разработкой программных продуктов, для описания решения на языке требований, чтобы в конечном итоге снизить неопределённость и уменьшить количество переделок.
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
😏 - повеселеет (руководство чаще всего думают, что все аналитики вечно в депрессии из-за кислого выражения лица, просто мы знаем чуть больше и нам трудно)))
😎 -станет более заряженный, будет действовать в интересах команды и приносить проработанные задачи на обсуждение разработчикам.
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанного
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Please open Telegram to view this post
VIEW IN TELEGRAM
Новому человеку в команде виднее, что не так в процессах.
Когда-то я набирала большой отдел и с каждым новым аналитиком проходила процесс онбординга. Я ждала того момента, когда аналитик начинал видеть внутреннюю кухню и сравнивать со своим опытом и понимал, что чёт не так, и чёт оно не очень хорошо работает))) А так как процесс усовершенствования бесконечный, примерно со всеми аналитиками была, одна и та же история под названием "Наташа, я вот там посмотрел документацию, процесс, давай изменим".
И я так радовалась, ну вот оно!
Вцелом я сама также всегда поступала в новых командах. Это как хозяйка приходит в новый дом и решает, что надо бы прибраться. Кого-то это бесило, не лезь! Кто-то, как истинный руководитель говорил - делай! Тут главное не наступить на грабли с надписью на них "нереально изменить".
И на самом деле это очень круто, когда 2-5 человек говорят одни и те же проблемы, их подсвечивают, значит реально их нужно решать. Если не решать, не вносить изменений, то не будет развития. #капитаночевидность
Как там говорят, только в болоте не течёт вода, и только на кладбище всё без изменений, в жизни всё постоянно меняется. В нашей с вами жизни всё меняется ещё быстрее!
Для меня от нового человека получить список проблем, это равносильно анализу текущего состояния дел. Какая проблема исчезла, мы её закрыли, что нового решение породило в плане новых проблем. А для меня, как для сотрудника компании, это тоже показатель, что меня слушают, со мной ведут диалог, и я могу привнести новую практику. И это тоже некий показатель адекватности.
Изменениями нужно управлять, не всё так просто внедряется, что-то через сопротивление и боль. Главное, чтобы потом было лучше)))
#изменения #новыйсотрудник #мойопыт #онбординг #лидер
Когда-то я набирала большой отдел и с каждым новым аналитиком проходила процесс онбординга. Я ждала того момента, когда аналитик начинал видеть внутреннюю кухню и сравнивать со своим опытом и понимал, что чёт не так, и чёт оно не очень хорошо работает))) А так как процесс усовершенствования бесконечный, примерно со всеми аналитиками была, одна и та же история под названием "Наташа, я вот там посмотрел документацию, процесс, давай изменим".
И я так радовалась, ну вот оно!
Вцелом я сама также всегда поступала в новых командах. Это как хозяйка приходит в новый дом и решает, что надо бы прибраться. Кого-то это бесило, не лезь! Кто-то, как истинный руководитель говорил - делай! Тут главное не наступить на грабли с надписью на них "нереально изменить".
И на самом деле это очень круто, когда 2-5 человек говорят одни и те же проблемы, их подсвечивают, значит реально их нужно решать. Если не решать, не вносить изменений, то не будет развития. #капитаночевидность
Как там говорят, только в болоте не течёт вода, и только на кладбище всё без изменений, в жизни всё постоянно меняется. В нашей с вами жизни всё меняется ещё быстрее!
Для меня от нового человека получить список проблем, это равносильно анализу текущего состояния дел. Какая проблема исчезла, мы её закрыли, что нового решение породило в плане новых проблем. А для меня, как для сотрудника компании, это тоже показатель, что меня слушают, со мной ведут диалог, и я могу привнести новую практику. И это тоже некий показатель адекватности.
Изменениями нужно управлять, не всё так просто внедряется, что-то через сопротивление и боль. Главное, чтобы потом было лучше)))
#изменения #новыйсотрудник #мойопыт #онбординг #лидер
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Надо VS Хочу
#мойопыт #моемнение #надохочу #мотивация #коучинг
#мысливслух
Я помню, как меня когда-то удивил статус в jira для задач - don't want.
Я тогда думала, всмысле не хочу??? Что за детский сад, отклонить задачу, потому что не хочу. Мы же тут бизнес делаем, какой блин не хочу!! Давай делай!
А если посмотреть на это глубже?
Я правда не хочу, зачем себя насиловать. В какой-то момент, переступая постоянно через себя, всё скатиться в проблемы со здоровьем.
Я тут не говорю о том, что всегда должно быть хочу, я говорю о трезвом, здоровом, взрослом состояние, я хочу, потому что потом получу определённые плюсы для себя. А эти плюсы, когда переходят в удовольствие, становятся топливом для хочу.
На одном проекте я работала не ради должности, бизнес целей, достижений, премий, я работала, потому что мне было интересно посмотреть, как предприниматель строит бизнес. И каждый день я была исследователем, а что будет дальше? Как он принимает решения? Что будет говорить? Какие эмоции транслирует?
Понятно, что зарплата, деньги, задачи, это всё тоже важно. Но позиция немного вне замеса, меня сильно спасала, от турбулентности стартапа. Дикий интерес, что же будет дальше, чем же это все закончится)
Я занимаюсь лыжами, и когда я это говорю, часто у моих собеседников появляется жуткая мина на лице, все начинают морщится))) Трагизм школьных лыж, убил всякое желание когда либо возвращаться к ним снова.
Зима, холод, некомфортно, снег, летящий в лицо, лыжи, которые стоят колом, учитель который орёт на детей, пока эти лыжи до школы донесешь, они раз 100 упадут и вот это вот всё...
Одна из девушек на тренировке по лыжам сказала, что она пришла в лыжи, чтобы полюбить зиму. И это прикольная мотивация))) Я пришла в лыжи, потому что они доступные, новый высокотехничный вид спорта, помогает развитию мозга, своя тусовка, и мне нужно было выбрать спорт в кайф, чтобы восстановиться после болезни. Плюс закалка, чтобы все эти болячки отстали. Что-то на регулярной основе без кайфа делать невозможно.
И что меня радует. Это то, что в нашем спорте я всё чаще и чаще слышу и от тренеров и от спортсменов, что они вышли на старт, чтобы получить удовольствие!
Да и в наших любительских соревнованиях, когда тренер подходит и говорит, вы тут не за медаль боретесь, просто получите удовольствие от праздника спорта, компании, леса, природы, погоды.
До сих пор помню, как в минус, в финале рождественской гонки, еду я по стадиону на лыжах, а в руках бутылка шампанского, бабахает салют, каааайф 😂
Вернёмся к надо.
Мне кажется в моей жизни, так много было надо. Что когда встречаешь такого советского человека, он транслирует тебе надрыв в погоне за идеалом.
-Девушка, вы вот так плохо катаетесь, зачем вы вообще на лыжню вышли?
-Вышла кайфануть, а что нельзя?
-Вы как тупая корова тут стоите и мешаете своей техникой и остановками!
И такое тоже бывает. Как можно помешать в огромном лесу и на широкой лыжне, для меня загадка.
Это как обслуживание в почте, ты уже виноват, потому что ты родился и туда пришёл и ещё посмел открыть рот.
Большие достижения без надо не беруться, но и по лезвию бритвы, выжимая из себя последнее, такая себе стратегия. У нас всё должно быть из крайности в крайность, либо всё, либо ничего. С огромным давлением сверху. Такая мы страна.
Конечно без надо, только на одном хочу далеко не уедешь, потому что бывают состояния дна, когда ничего не хочу. И тут нужно переходить в режим энергосбережения, восстановления и на низком надо, делать, стараясь заботится о себе, даже в мелочах. И тогда и появится хочу. И капля за каплей вернётся энергия.
Самое крутое, это переключить не хочу, в попробую, а вдруг! Без ожиданий. И сейчас много профессионалов, которые помогут попробовать, поддержат и настроят на получение удовольствия от процесса.
---------------------
Продолжение 👇
#мойопыт #моемнение #надохочу #мотивация #коучинг
#мысливслух
Я помню, как меня когда-то удивил статус в jira для задач - don't want.
Я тогда думала, всмысле не хочу??? Что за детский сад, отклонить задачу, потому что не хочу. Мы же тут бизнес делаем, какой блин не хочу!! Давай делай!
А если посмотреть на это глубже?
Я правда не хочу, зачем себя насиловать. В какой-то момент, переступая постоянно через себя, всё скатиться в проблемы со здоровьем.
Я тут не говорю о том, что всегда должно быть хочу, я говорю о трезвом, здоровом, взрослом состояние, я хочу, потому что потом получу определённые плюсы для себя. А эти плюсы, когда переходят в удовольствие, становятся топливом для хочу.
На одном проекте я работала не ради должности, бизнес целей, достижений, премий, я работала, потому что мне было интересно посмотреть, как предприниматель строит бизнес. И каждый день я была исследователем, а что будет дальше? Как он принимает решения? Что будет говорить? Какие эмоции транслирует?
Понятно, что зарплата, деньги, задачи, это всё тоже важно. Но позиция немного вне замеса, меня сильно спасала, от турбулентности стартапа. Дикий интерес, что же будет дальше, чем же это все закончится)
Я занимаюсь лыжами, и когда я это говорю, часто у моих собеседников появляется жуткая мина на лице, все начинают морщится))) Трагизм школьных лыж, убил всякое желание когда либо возвращаться к ним снова.
Зима, холод, некомфортно, снег, летящий в лицо, лыжи, которые стоят колом, учитель который орёт на детей, пока эти лыжи до школы донесешь, они раз 100 упадут и вот это вот всё...
Одна из девушек на тренировке по лыжам сказала, что она пришла в лыжи, чтобы полюбить зиму. И это прикольная мотивация))) Я пришла в лыжи, потому что они доступные, новый высокотехничный вид спорта, помогает развитию мозга, своя тусовка, и мне нужно было выбрать спорт в кайф, чтобы восстановиться после болезни. Плюс закалка, чтобы все эти болячки отстали. Что-то на регулярной основе без кайфа делать невозможно.
И что меня радует. Это то, что в нашем спорте я всё чаще и чаще слышу и от тренеров и от спортсменов, что они вышли на старт, чтобы получить удовольствие!
Да и в наших любительских соревнованиях, когда тренер подходит и говорит, вы тут не за медаль боретесь, просто получите удовольствие от праздника спорта, компании, леса, природы, погоды.
До сих пор помню, как в минус, в финале рождественской гонки, еду я по стадиону на лыжах, а в руках бутылка шампанского, бабахает салют, каааайф 😂
Вернёмся к надо.
Мне кажется в моей жизни, так много было надо. Что когда встречаешь такого советского человека, он транслирует тебе надрыв в погоне за идеалом.
-Девушка, вы вот так плохо катаетесь, зачем вы вообще на лыжню вышли?
-Вышла кайфануть, а что нельзя?
-Вы как тупая корова тут стоите и мешаете своей техникой и остановками!
И такое тоже бывает. Как можно помешать в огромном лесу и на широкой лыжне, для меня загадка.
Это как обслуживание в почте, ты уже виноват, потому что ты родился и туда пришёл и ещё посмел открыть рот.
Большие достижения без надо не беруться, но и по лезвию бритвы, выжимая из себя последнее, такая себе стратегия. У нас всё должно быть из крайности в крайность, либо всё, либо ничего. С огромным давлением сверху. Такая мы страна.
Конечно без надо, только на одном хочу далеко не уедешь, потому что бывают состояния дна, когда ничего не хочу. И тут нужно переходить в режим энергосбережения, восстановления и на низком надо, делать, стараясь заботится о себе, даже в мелочах. И тогда и появится хочу. И капля за каплей вернётся энергия.
Самое крутое, это переключить не хочу, в попробую, а вдруг! Без ожиданий. И сейчас много профессионалов, которые помогут попробовать, поддержат и настроят на получение удовольствия от процесса.
---------------------
Продолжение 👇
На календаре 8 декабря. Но нового года осталось 23 дня, а народ вокруг и физически и морально уже подустал.
Или только я это чувствую?)
Хотела тут написать, то что я часто повторяю аналитикам, которые приходят на менторство, с разными запросами. И эти запросы могут звучать, как: "я ничего не понимаю, ничего не успеваю, я дно!"
Как-то в год пандемии, когда я вышла на новый проект увидела, как в декабре 90% команды за год были уже подгоревшие.
И тут что можно сделать?
Вернуть себе себя и реальность вокруг, просто начиная оперировать фактами.
Пандемия была огромным стрессом, неизвестностью и всех пошатовало, а когда уже видишь, что скоро можно выдохнуть и отдохнуть, то на морально волевых существуешь. И это факт.
➡️Зима, короткий световой день - факт, это всё влияет на самочувствие.
Конец года, гонка по закрытию задач за год - факт.
Общая моральная и физическая усталость - факт.
➡️Большая нагрузка на работе, просто посчитайте сколько задач, диаграмм вы сделали, когда мне говорят, что за неделю было нарисовано 50 диаграмм! Даже если тут помог ИИ, это всё равно много, их ещё нужно подкорректировать. Это факт!
➡️Айти, хоть и передовая, но сложная среда, особенно для людей, у которых строение чувствительное (есть чувствительная нервная система, тоже уже факт). И в этой среде ещё нужно существовать, и давать результат, работать эффективно. Психологическое давление есть, это факт.
Безоценочно говорить, только фактами, убирая эмоции, действительно очень сложно. Но это крутое упражнение, которое возвращает человеку реальность и возможность управления собой, и собственной жизнью.
Если вам сложно это сделать самостоятельно, приходите к менторам, коучам, которые со стороны смогут, после вашего рассказа взять из него факты и безоценочно вернуть вам))
P. S. Кстати сегодня пятница, это факт 😄
#мысливслух #коучинг #факт #моемнение #мойопыт #выгорание #менторство
Или только я это чувствую?)
Хотела тут написать, то что я часто повторяю аналитикам, которые приходят на менторство, с разными запросами. И эти запросы могут звучать, как: "я ничего не понимаю, ничего не успеваю, я дно!"
Как-то в год пандемии, когда я вышла на новый проект увидела, как в декабре 90% команды за год были уже подгоревшие.
И тут что можно сделать?
Вернуть себе себя и реальность вокруг, просто начиная оперировать фактами.
Пандемия была огромным стрессом, неизвестностью и всех пошатовало, а когда уже видишь, что скоро можно выдохнуть и отдохнуть, то на морально волевых существуешь. И это факт.
➡️Зима, короткий световой день - факт, это всё влияет на самочувствие.
Конец года, гонка по закрытию задач за год - факт.
Общая моральная и физическая усталость - факт.
➡️Большая нагрузка на работе, просто посчитайте сколько задач, диаграмм вы сделали, когда мне говорят, что за неделю было нарисовано 50 диаграмм! Даже если тут помог ИИ, это всё равно много, их ещё нужно подкорректировать. Это факт!
➡️Айти, хоть и передовая, но сложная среда, особенно для людей, у которых строение чувствительное (есть чувствительная нервная система, тоже уже факт). И в этой среде ещё нужно существовать, и давать результат, работать эффективно. Психологическое давление есть, это факт.
Безоценочно говорить, только фактами, убирая эмоции, действительно очень сложно. Но это крутое упражнение, которое возвращает человеку реальность и возможность управления собой, и собственной жизнью.
Если вам сложно это сделать самостоятельно, приходите к менторам, коучам, которые со стороны смогут, после вашего рассказа взять из него факты и безоценочно вернуть вам))
P. S. Кстати сегодня пятница, это факт 😄
#мысливслух #коучинг #факт #моемнение #мойопыт #выгорание #менторство
Развивающая обратная связь.
Большинство руководителей, к сожалению, не умеют давать развивающую обратную связь. Может конечно, кому-то и круто когда их жёстко мотивируют и им нравится жить по принципу no pain, no gain (нет боли, нет результата), но я хрупкая снежинка, и со мной нужно с пряником, я тогда я даже больше делаю)
Я когда-то писала о том, как теннисистка Динара Сафина стала первой ракеткой мира, и вот она выиграла турнир большого шлема и даёт интервью. И журналист такой - вас можно поздравить!!! А она хмуриться и говорит - мама недовольна.
Ну вы же первая ракетка мира!
Мама-тренер и она нашла ошибки...
Вот и у нас, и так часто. Ты выпрыгиваешь из трусов, но мало, недостаточно, нет идеала, и все недовольны. А руководитель даже не умеет говорить о хорошем и говорить хотя бы факты, что действительно получилось. Это правда трудно. Я сама в менторстве долго училась замечать у аналитиков действительно факты, что ты вот дорогой аналитик, действительно сделал хорошо, то что ты просто даже стал делать, это уже полпути к успеху!
А часто мы с сами к себе так относимся, мало дорогой товарищ! Но мне же плохо? Что! Чтобы я такого не слышал, а ну вперёд! К светлому будущему!
Так вот развивающая обратная связь, это мягкий способ указать человеку на то, что стоит развивать, но чтобы это сделать нужно построить диалог и начать с плюсов, фактов, достижений.
Не нужно врать, придумывать, или льстить. Просто стоит говорить о фактах со знаком плюс. И лучше 3 +++ потом добавить один минус.
И всё! Прикиньте как сложно?) один минус!! Мы же любим на людей сбросить ушат из 100500 минусов. И пусть потом человек в депрессию впадает, ты живёшь в России чувак, боль и героизм, наш путь. Ну c'est la vie, страдай!
Но я тут побуду #капитаночевидность и распишу пример, классической обратной связи при разговоре:
✅1.Small talk, вообще прям мне нравится всегда такое начало, расслабиться, переключиться.
✅2.Цель разговора, обсуждение, а готов ли сотрудник к такому диалогу. А головы ли вы? Банально, самочувствие, ресурс, запрос.
✅3.Потом 3 +++ и подкрепить фактами. Вот конкретное ТЗ, вот удалось, вот тут тоже удалось. Вот тут я вижу твой рост. Не начинайте с минусов! Человек может уйти в жёсткую защиту и дальше всё как в тумане...
✅4.Можно сказать о минусе и тоже подкреплять фактами. Спросите разрешения, можно ли свои советы давать и рекомендации.
✅5.Добавить рекомендации, конкретику, курсы, книги примеры. Как улучшить, на что обратить внимание.
✅6.Закрытие. Спросить у сотрудника, что он сам об этом думает? Мы запускаем рефлексию, она тоже необходима. Делаем выводы. И их фиксируем.
✅7.Договариваемся о дальнейших шагах, что конкретно будем делать и как.
Самое сложное это начинать замечать плюсы. Если не получается их сразу выявлять, просто начните говорить себе спасибо за то, что пробуете. Я не устану повторять, что иногда, даже встать утром и начать, что-то делать это подвиг. И можно себя за это начать хвалить.
Даже если не получилось, вы же попробовали)))
И часто, мы ждём одобрение от Тим Лида, а он загружен и не понимает этого, подойти сами и попросите, а ты можешь мне дать обратную связь? Но тоже понимайте, у кого вы её просите))
Люди разные и обратную связь от жёстких карьеристов может в вашем случае стоит делить на N.
#обратнаясвязь #менторство #руководствокомандой #мойопыт #коучинг #факт #развитие
Большинство руководителей, к сожалению, не умеют давать развивающую обратную связь. Может конечно, кому-то и круто когда их жёстко мотивируют и им нравится жить по принципу no pain, no gain (нет боли, нет результата), но я хрупкая снежинка, и со мной нужно с пряником, я тогда я даже больше делаю)
Я когда-то писала о том, как теннисистка Динара Сафина стала первой ракеткой мира, и вот она выиграла турнир большого шлема и даёт интервью. И журналист такой - вас можно поздравить!!! А она хмуриться и говорит - мама недовольна.
Ну вы же первая ракетка мира!
Мама-тренер и она нашла ошибки...
Вот и у нас, и так часто. Ты выпрыгиваешь из трусов, но мало, недостаточно, нет идеала, и все недовольны. А руководитель даже не умеет говорить о хорошем и говорить хотя бы факты, что действительно получилось. Это правда трудно. Я сама в менторстве долго училась замечать у аналитиков действительно факты, что ты вот дорогой аналитик, действительно сделал хорошо, то что ты просто даже стал делать, это уже полпути к успеху!
А часто мы с сами к себе так относимся, мало дорогой товарищ! Но мне же плохо? Что! Чтобы я такого не слышал, а ну вперёд! К светлому будущему!
Так вот развивающая обратная связь, это мягкий способ указать человеку на то, что стоит развивать, но чтобы это сделать нужно построить диалог и начать с плюсов, фактов, достижений.
Не нужно врать, придумывать, или льстить. Просто стоит говорить о фактах со знаком плюс. И лучше 3 +++ потом добавить один минус.
И всё! Прикиньте как сложно?) один минус!! Мы же любим на людей сбросить ушат из 100500 минусов. И пусть потом человек в депрессию впадает, ты живёшь в России чувак, боль и героизм, наш путь. Ну c'est la vie, страдай!
Но я тут побуду #капитаночевидность и распишу пример, классической обратной связи при разговоре:
✅1.Small talk, вообще прям мне нравится всегда такое начало, расслабиться, переключиться.
✅2.Цель разговора, обсуждение, а готов ли сотрудник к такому диалогу. А головы ли вы? Банально, самочувствие, ресурс, запрос.
✅3.Потом 3 +++ и подкрепить фактами. Вот конкретное ТЗ, вот удалось, вот тут тоже удалось. Вот тут я вижу твой рост. Не начинайте с минусов! Человек может уйти в жёсткую защиту и дальше всё как в тумане...
✅4.Можно сказать о минусе и тоже подкреплять фактами. Спросите разрешения, можно ли свои советы давать и рекомендации.
✅5.Добавить рекомендации, конкретику, курсы, книги примеры. Как улучшить, на что обратить внимание.
✅6.Закрытие. Спросить у сотрудника, что он сам об этом думает? Мы запускаем рефлексию, она тоже необходима. Делаем выводы. И их фиксируем.
✅7.Договариваемся о дальнейших шагах, что конкретно будем делать и как.
Самое сложное это начинать замечать плюсы. Если не получается их сразу выявлять, просто начните говорить себе спасибо за то, что пробуете. Я не устану повторять, что иногда, даже встать утром и начать, что-то делать это подвиг. И можно себя за это начать хвалить.
Даже если не получилось, вы же попробовали)))
И часто, мы ждём одобрение от Тим Лида, а он загружен и не понимает этого, подойти сами и попросите, а ты можешь мне дать обратную связь? Но тоже понимайте, у кого вы её просите))
Люди разные и обратную связь от жёстких карьеристов может в вашем случае стоит делить на N.
#обратнаясвязь #менторство #руководствокомандой #мойопыт #коучинг #факт #развитие
Не все продукты рождаются из боли.
Была у меня как-то заруба по теме какие бывают продукты? И восновном везде все говорят о продуктах "боли". Вот ты находишь боль клиента и её решаешь и тогда твой продукт выстреливает, при условии что это общая боль. Действительно, большинство бизнесов, у которых мощный рост, это продукты боли.
Так ли это?
Диплом продакта иногда не даёт мне спокойно жить и продукт, над которым работала я с командой, был продукт возможностей. Не было в нём боли.
Но теперь я бы ещё сказала, что продукт может быть продуктом работ. На какую работу кого или что я нанимаю. И это уже ближе к возможностям.
Итак, про продукт возможности. Мы работали над умной примерочной. И в самом процессе примерки одежды нет боли. Сколько бы мы не проводили интервью, сколько бы не исследовали сам процесс, не было там боли и нам от этого было больно.
Есть боль в самой одежде, качестве, размере, фасоне и т.д. Есть просто не желание примерять, или наоборот кто-то наслаждается процессом подбора образа и примеркой, кто-то не хочет ни с кем общаться, кто-то наоборот хочет. Поэтому продукты, которые расширяют нам возможности, вызывая новые привычки - это игра вдолгую. Там выстрела не будет точно в цель. Готовы ли вы платить за возможность? Да, если это ускорение, удобство или привычка.
В случае умной примерочной, какие-то точные плюсы и метрики влияния на продажи не были нами найдены. Хотя в мире умная примерочная, как продукт, развивается и она подсказывает дополнительный товар, собирает образ, даёт возможность вызвать консультанта и куча всего, что можно автоматизировать и добавить.
Если посмотреть на сервис YouTube там нет боли. Есть желание получить быстрый дофамин, эмоции, разгрузить голову, посмотреть что-то интересное, найти контент, чтобы мне подобрали ролик.
И YouTube долго жил без монетизации, потом появилась реклама, а потом и платные подписки. Это мощный инструмент работы с массами тоже не сразу, например до меня, дошло. Да, возможно сейчас в какой-то степени YouTube и решает боль, например поиска информации, лекций или учебного материала, но он всё таки про возможности. И больше похож на один из каналов телека.
Когда убирают нам сервис возможностей, например, как нельзяграм, мы перестраиваемся. Да, многих колбасит, кто-то остаётся, многие ищут замену, замена идёт, но тяжело, долго. Но по сути уже нет боли, как была в самом начале, когда качество фотографий было плохое и фильтры, маски давали вау эффект.
Грань между болью и возможностью очень тонкая, потому что кажется, что всё можно свести к боли.
Но при этом есть ещё более мощный инструмент Job to be done. Который вроде как очевидный, но имеет под собой очень мощный и скрытый потенциал.
Работа, которая должна быть выполнена. То есть в любом случае человек нужную ему работу выполнит. Подумает и сделает выбор в сторону того, что более приемлемо в его контексте и условиях. И работа вполне может быть новой возможностью, расширением вариантов решения той же цели подбора одежды, через маркетплейс, например.
Про то что и кого я нанимаю на работу, писала вот тут➡️ https://t.me/start_in_IT/649
#jtbd #продуктболи #продуктвозможности #мысливслух #мойопыт
А ваши продукты про боль или возможность?🤑
Была у меня как-то заруба по теме какие бывают продукты? И восновном везде все говорят о продуктах "боли". Вот ты находишь боль клиента и её решаешь и тогда твой продукт выстреливает, при условии что это общая боль. Действительно, большинство бизнесов, у которых мощный рост, это продукты боли.
Так ли это?
Диплом продакта иногда не даёт мне спокойно жить и продукт, над которым работала я с командой, был продукт возможностей. Не было в нём боли.
Но теперь я бы ещё сказала, что продукт может быть продуктом работ. На какую работу кого или что я нанимаю. И это уже ближе к возможностям.
Итак, про продукт возможности. Мы работали над умной примерочной. И в самом процессе примерки одежды нет боли. Сколько бы мы не проводили интервью, сколько бы не исследовали сам процесс, не было там боли и нам от этого было больно.
Есть боль в самой одежде, качестве, размере, фасоне и т.д. Есть просто не желание примерять, или наоборот кто-то наслаждается процессом подбора образа и примеркой, кто-то не хочет ни с кем общаться, кто-то наоборот хочет. Поэтому продукты, которые расширяют нам возможности, вызывая новые привычки - это игра вдолгую. Там выстрела не будет точно в цель. Готовы ли вы платить за возможность? Да, если это ускорение, удобство или привычка.
В случае умной примерочной, какие-то точные плюсы и метрики влияния на продажи не были нами найдены. Хотя в мире умная примерочная, как продукт, развивается и она подсказывает дополнительный товар, собирает образ, даёт возможность вызвать консультанта и куча всего, что можно автоматизировать и добавить.
Если посмотреть на сервис YouTube там нет боли. Есть желание получить быстрый дофамин, эмоции, разгрузить голову, посмотреть что-то интересное, найти контент, чтобы мне подобрали ролик.
И YouTube долго жил без монетизации, потом появилась реклама, а потом и платные подписки. Это мощный инструмент работы с массами тоже не сразу, например до меня, дошло. Да, возможно сейчас в какой-то степени YouTube и решает боль, например поиска информации, лекций или учебного материала, но он всё таки про возможности. И больше похож на один из каналов телека.
Когда убирают нам сервис возможностей, например, как нельзяграм, мы перестраиваемся. Да, многих колбасит, кто-то остаётся, многие ищут замену, замена идёт, но тяжело, долго. Но по сути уже нет боли, как была в самом начале, когда качество фотографий было плохое и фильтры, маски давали вау эффект.
Грань между болью и возможностью очень тонкая, потому что кажется, что всё можно свести к боли.
Но при этом есть ещё более мощный инструмент Job to be done. Который вроде как очевидный, но имеет под собой очень мощный и скрытый потенциал.
Работа, которая должна быть выполнена. То есть в любом случае человек нужную ему работу выполнит. Подумает и сделает выбор в сторону того, что более приемлемо в его контексте и условиях. И работа вполне может быть новой возможностью, расширением вариантов решения той же цели подбора одежды, через маркетплейс, например.
Про то что и кого я нанимаю на работу, писала вот тут
#jtbd #продуктболи #продуктвозможности #мысливслух #мойопыт
А ваши продукты про боль или возможность?
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Наташа Косинова. Варю айти СУП
Я нанимаю на работу...
Эмоции неотъемлемая часть жизни человека. Наш организм защищает нас постоянно, чтобы мы смогли выжить в среде, которая нас окружает. Да, к сожалению, мир в последние годы, очень сильно изменился и базовые потребности человека не то…
Эмоции неотъемлемая часть жизни человека. Наш организм защищает нас постоянно, чтобы мы смогли выжить в среде, которая нас окружает. Да, к сожалению, мир в последние годы, очень сильно изменился и базовые потребности человека не то…
Пирамида артефактов & абстрактное мышление
Уже несколько раз, за эти дни, я получила порцию благодарности на вебинар "Пирамида артефактов ИТ-проекта". ❤️
Мне очень приятно, что результат живёт и ходит по рукам. И ещё раз спасибо наставнику моих вебинаров Евгению Галактионову.
Решила, что пора напомнить вам о вебинаре, так как у меня много новых подписчиков пришло за последние полгода)
И сегодняшняя моя мысль - это то, что аналитику, техническому айти специалисту необходимо абстрактное мышление.
Проводя курсы, менторство, понимаю, что есть такие вещи, которые сложно потрогать. А если сложно потрогать нам нужно развивать представление о предмете. Наш мозг, и вцелом наш организм, это очень гибкая система, которую мы можем постоянно прокачивать, как и любую мышцу, наш мозг это тоже мышца.
Как увидеть или померить мышление, я не знаю, и с удовольствием бы поговорила на эту тему с нейро-экспертами.
Но аналитик часто работает с тем, что невозможно потрогать. Айти часто это то, что не увидеть, конечно можно открыть код и прочитать, но говоря на языке требований, моделей, образов приходится представлять себе эти абстракции. И моё мнение именно такое, что техническое образование формирует так необходимое мышление для работы в айти отрасли. Безусловно физики, химики работают тоже с абстрактными моделями, отлично делают расчёты и показывают хорошие когнитивные способности в айти разработке.
Но инженер, изначально некий маг, который из говна и палок может сделать колесо. И его мозг заточен так, чтобы соорудить решение в среде жёстких ограничений, используя свои знания.
Уровни абстракции, о которых говорят многих эксперты по проектированию айти решений, требуют как раз прокачки мышцы, чтобы представить этот уровень, выстроить в голове классификацию и на кончиках пальцев понимать, где я сейчас нахожусь, и как мне перейти с одного уровня на другой.
Как раз вебинар рассказывает о том, как эти уровни требований могут быть представлены. Это один из примеров, подходов к тому, как можно организовать работу команды с артефактами и действительно начать проектировать!)
➡️ Ссылка на вебинар
🟢 Ссылка на презентацию
🟢 Канал Евгения Галактионова
#пирамида #вебинар #абстрация #вспомнимважное #мойопыт #капитаночевидность
Уже несколько раз, за эти дни, я получила порцию благодарности на вебинар "Пирамида артефактов ИТ-проекта". ❤️
Мне очень приятно, что результат живёт и ходит по рукам. И ещё раз спасибо наставнику моих вебинаров Евгению Галактионову.
Решила, что пора напомнить вам о вебинаре, так как у меня много новых подписчиков пришло за последние полгода)
И сегодняшняя моя мысль - это то, что аналитику, техническому айти специалисту необходимо абстрактное мышление.
Проводя курсы, менторство, понимаю, что есть такие вещи, которые сложно потрогать. А если сложно потрогать нам нужно развивать представление о предмете. Наш мозг, и вцелом наш организм, это очень гибкая система, которую мы можем постоянно прокачивать, как и любую мышцу, наш мозг это тоже мышца.
Как увидеть или померить мышление, я не знаю, и с удовольствием бы поговорила на эту тему с нейро-экспертами.
Но аналитик часто работает с тем, что невозможно потрогать. Айти часто это то, что не увидеть, конечно можно открыть код и прочитать, но говоря на языке требований, моделей, образов приходится представлять себе эти абстракции. И моё мнение именно такое, что техническое образование формирует так необходимое мышление для работы в айти отрасли. Безусловно физики, химики работают тоже с абстрактными моделями, отлично делают расчёты и показывают хорошие когнитивные способности в айти разработке.
Но инженер, изначально некий маг, который из говна и палок может сделать колесо. И его мозг заточен так, чтобы соорудить решение в среде жёстких ограничений, используя свои знания.
Уровни абстракции, о которых говорят многих эксперты по проектированию айти решений, требуют как раз прокачки мышцы, чтобы представить этот уровень, выстроить в голове классификацию и на кончиках пальцев понимать, где я сейчас нахожусь, и как мне перейти с одного уровня на другой.
Как раз вебинар рассказывает о том, как эти уровни требований могут быть представлены. Это один из примеров, подходов к тому, как можно организовать работу команды с артефактами и действительно начать проектировать!)
#пирамида #вебинар #абстрация #вспомнимважное #мойопыт #капитаночевидность
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Наталья Косинова. Пирамида артефактов для ИТ-проекта: анализ и проектирование
Создавать полную документацию на проекте трудоемкий, долгий и местами нудный процесс, при этом документация ради документации или документация «в стол» ником...
Моё лицо выглядит примерно вот так, когда мне говорят - нам нужно ТЗ на интеграцию!
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Как оценить задачу?
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Я чувствую себя ненужным, лишним.
Непонятно зачем я команде?
Начало 👆
-----------------
📍8.Может быть так, что задачи вам дают не по вашим компетенциям. Не стесняйтесь этот момент узнавать. Это может быть круто, а может быть бомба замедленного действия. Если меня поставить на сцену балета большого театра, я получу огромный шок. И никому от этого не будет хорошо. И ещё и спрос будет, а че не станцевала?
Возможно я ещё что-то упустила. И вы можете предложить свой вариант в комментариях 👇
Знаю что у многих аналитиков возникают такие эмоции, проблемы. Вы не одиноки, быть аналитиком сложно, и да, действительно работа на проектах, связана со сложными процессами высокой неопределённости, как у заказчика, так и внутри команды. С этим можно и нужно работать, и начинать говорить. Пробовать менять. Вода камень точит. Главное понимать свои силы, реальность, и заручаться поддержкой руководства. Ибо аналитик не всегда может влиять сам на процессы. Может говорить, и не всегда его могут слушать. Но надеюсь, что вам повезёт и вас услышат)))
Ой ну тебе там просто так рассуждать, ты же на опыте... Ну да, конечно очень просто... Никто не знает сколько слёз было пролито, со словами зачем я всё это делаю???... С вопросами руководству - зачем вам я?... И мыслями по утрам - больше не могу... С наездами и кознями от разработчиков) было и такое... Кнопки на стул не подкладывали, может конечно в кружку плевали, я теперь это не узнаю, а вот доступ закрывали, ответы не давали, в игнор кидали, и истерики устраивали))
P. S. Вам в помощь вебинар зачем аналитик проекту. Можно найти себе инсайты.
#системныйаналитик #проблемынапроекте #рольаналитика #мойопыт #моемнение
Непонятно зачем я команде?
Начало 👆
-----------------
📍8.Может быть так, что задачи вам дают не по вашим компетенциям. Не стесняйтесь этот момент узнавать. Это может быть круто, а может быть бомба замедленного действия. Если меня поставить на сцену балета большого театра, я получу огромный шок. И никому от этого не будет хорошо. И ещё и спрос будет, а че не станцевала?
Возможно я ещё что-то упустила. И вы можете предложить свой вариант в комментариях 👇
Знаю что у многих аналитиков возникают такие эмоции, проблемы. Вы не одиноки, быть аналитиком сложно, и да, действительно работа на проектах, связана со сложными процессами высокой неопределённости, как у заказчика, так и внутри команды. С этим можно и нужно работать, и начинать говорить. Пробовать менять. Вода камень точит. Главное понимать свои силы, реальность, и заручаться поддержкой руководства. Ибо аналитик не всегда может влиять сам на процессы. Может говорить, и не всегда его могут слушать. Но надеюсь, что вам повезёт и вас услышат)))
P. S. Вам в помощь вебинар зачем аналитик проекту. Можно найти себе инсайты.
#системныйаналитик #проблемынапроекте #рольаналитика #мойопыт #моемнение
Про коуча или как я дошла до жизни такой...
Хотела вам рассказать, почему я начала работать с коучем.
Да, можно говорить про то, что коуч - это какой-то сферический конь в вакууме, и весь этот успешный успех из нельзяграм направление коучинга сильно обесценил и добавил флёр инфоцыгантва. Я сама, например, не очень верю в агил коучей (хотя это другое), и мне было интересно разобраться, а чем же хороши коучи, и кто из них действительно профессионалы и помогут добиться результата. При этом я же вижу хороших специалистов и понимаю, что психологию никто не отменяет, что в айти, собранная команда людей, должна начать приносить результат. И начать работать эффективно и так сказать, пройти период претирки может помочь коуч.
Да, коуч - это тренер. Я занималась разными видами спорта с тренерами, и работала с отличными тренерами. И мне импонирует направление тренерства.
Почему я пошла к коучу?
Моё перманентное состояние последних лет 3 - это море идей, которые лежат в ящике стола. Чтобы их воплотить в жизнь, что я делаю? Ничего!
Легко сказать, просто иди и сделай. Сложно действительно пойти и сделать.
Когда я сама пошла учиться на коуча, после первого потока курса пришла к выводу, что сам подход обучения не мой. Я не могу тупо брать практики и инструменты, и их применять бездумно. При этом радоваться. Вау, как клёво! Что блин?!!
Когда спрашиваешь доказательства, истоки, фундамент, причины возникновения у ведущего курс, он либо не знает, что ответить, либо уходит от ответа, что мол в следующем блоке узнаете, а стоит новый блок 100500 денЯг. Р-разочарование.
И я пришла к выводу, что коуч - это психолог, и психологии там много. А если учиться серьёзно, то это несколько лет точно.
Так вот, я и начала искать коуча, с образованием психолога. Плюс человека, которому я могу доберять и уважать, быть наравных. И конечно интересно работать со специалистом, который в твоей сфере мало что понимает, но цель состоит в том, чтобы делать мои идеи, воплощать в жизнь.
Так я и нашла Евгению Кутузову (подписывайтесь на канал Евгении), коуча с сертификатом, который серьёзно подходит к делу и параллельно учиться на психолога.
Какие выводы, я могу сделать, какой результат нашей работы есть, я опишу в следующих постах 😎
#коучинг #мойопыт #моемнение #саморазвитие #самомотивация
Хотела вам рассказать, почему я начала работать с коучем.
Да, можно говорить про то, что коуч - это какой-то сферический конь в вакууме, и весь этот успешный успех из нельзяграм направление коучинга сильно обесценил и добавил флёр инфоцыгантва. Я сама, например, не очень верю в агил коучей (хотя это другое), и мне было интересно разобраться, а чем же хороши коучи, и кто из них действительно профессионалы и помогут добиться результата. При этом я же вижу хороших специалистов и понимаю, что психологию никто не отменяет, что в айти, собранная команда людей, должна начать приносить результат. И начать работать эффективно и так сказать, пройти период претирки может помочь коуч.
Да, коуч - это тренер. Я занималась разными видами спорта с тренерами, и работала с отличными тренерами. И мне импонирует направление тренерства.
Почему я пошла к коучу?
Моё перманентное состояние последних лет 3 - это море идей, которые лежат в ящике стола. Чтобы их воплотить в жизнь, что я делаю? Ничего!
Легко сказать, просто иди и сделай. Сложно действительно пойти и сделать.
Когда я сама пошла учиться на коуча, после первого потока курса пришла к выводу, что сам подход обучения не мой. Я не могу тупо брать практики и инструменты, и их применять бездумно. При этом радоваться. Вау, как клёво! Что блин?!!
Когда спрашиваешь доказательства, истоки, фундамент, причины возникновения у ведущего курс, он либо не знает, что ответить, либо уходит от ответа, что мол в следующем блоке узнаете, а стоит новый блок 100500 денЯг. Р-разочарование.
И я пришла к выводу, что коуч - это психолог, и психологии там много. А если учиться серьёзно, то это несколько лет точно.
Так вот, я и начала искать коуча, с образованием психолога. Плюс человека, которому я могу доберять и уважать, быть наравных. И конечно интересно работать со специалистом, который в твоей сфере мало что понимает, но цель состоит в том, чтобы делать мои идеи, воплощать в жизнь.
Так я и нашла Евгению Кутузову (подписывайтесь на канал Евгении), коуча с сертификатом, который серьёзно подходит к делу и параллельно учиться на психолога.
Какие выводы, я могу сделать, какой результат нашей работы есть, я опишу в следующих постах 😎
#коучинг #мойопыт #моемнение #саморазвитие #самомотивация
Telegram
Евгения Кутузова | Оберег от выгорания
Хватит выгорать! Вы разрушаете озоновый слой!
Коуч/Психолог
Помогу найти и обезвредить причины тревожности, чтобы не довести себя до эмоционального выгорания
Сессия-Знакомство: @Evgenia_feory
Коуч/Психолог
Помогу найти и обезвредить причины тревожности, чтобы не довести себя до эмоционального выгорания
Сессия-Знакомство: @Evgenia_feory
Я боюсь, что разработчики решат, что я дурачок.
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований
Аналитики перфекционисты, и возмутители спокойствия одновременно.
Часто аналитик находится в ситуации:
✅- все всё понимают, я не понимаю,
✅- якобы все знают, что я должен выдать и как, но почему-то мне не говорят и я как сапёр хожу по минированному полю,
✅- боюсь, сделать неверный шаг в сторону и возмутить спокойствие и будет взрыв негодования.
Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎
Возможно, это будет сексизм, но иногда разработчики более лояльны к девушкам, "ну что с неё взять, она девушка. Какой-то бред написала. Ну и пусть..."
Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"
Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"
Но надо дождаться, когда вулкан эмоций выльется, и тогда можно показать вариант, а можно и чуть позже показать вариант, дав людям управлять ситуацией.
Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.
Тут единственное но нужно учиться ставить границы, что этот взрыв эмоций, не потому что я плохой специалист, а потому что я управляю этой ситуацией и использую этот способ выявления требований, подкинув катализатор.
Конечно риски такого способа тоже нужно взвесить, чтобы не влияло на вашу репутацию.
И быть готовым к разному развитию событий.
А вы какие используете катализаторы в работе?
#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований
Как запрыгнуть в проект на полном ходу и выжить?
Часть 1. 🚅
Условие - аналитика бросили в разработку, когда уже всё запущено и работает.
То есть поезд уже запущен и с большой скоростью едет по рельсам. А тебя в него закинули и ты должен понять куда, в вагон ресторан, в пассажирский вагон или в кабину машиниста. При этом дали задачу "сварить кофе". И вот надо понять, ты готовишь как бариста (если умеешь) в ресторане, или просто разводишь в кипятке или надо заказать приготовление кофе к вагону, для кого-то.
Что делать?
Пойти уволиться))
Хочется пойти по классике онбординга, который никто не отменял. Поэтому в самом начале, я бы пошла собирать основную информацию и освоение я бы вела в следующих направлениях:
✅1.Устройство компании, в чем цель бизнеса, место айти команды в нём и аналитика соответственно. Ответ на вопрос где я?
✅2.Устройство команды, кто Тим Лид, какая была история создания. Как ведётся управление, какие методологии (если они вообще были). И как в этих процессах участвует аналитик. Ответ на вопрос кто я тут?
✅3.Карта stakholders, кто за что отвечает, кто мне ставит задачи, кто будет их принимать (100500 руководителей не самый лучший вариант). Мне же хочется закрыть задачу и закрыть сносно и успешно.
✅4.Управление проектами, продуктами, цели, сроки, бюджеты, ресурсы, риски. Как это всё влияет на мою задачу?
Основы, короче говоря, осмотрелась вокруг и поняла, в каком я вагоне отказалась, "горящем на полном ходу, или в вагоне ресторане", иначе сложно понять свою задачу и критерии того, как её делать, кому сдавать, закрывать.
Это первый шаг, а вы с чего начинаете работу над новым проектом?🤔
#запрыгнутьвпроект #онбординг #первыйшаг #правдажизни #мойопыт
Часть 1. 🚅
Условие - аналитика бросили в разработку, когда уже всё запущено и работает.
То есть поезд уже запущен и с большой скоростью едет по рельсам. А тебя в него закинули и ты должен понять куда, в вагон ресторан, в пассажирский вагон или в кабину машиниста. При этом дали задачу "сварить кофе". И вот надо понять, ты готовишь как бариста (если умеешь) в ресторане, или просто разводишь в кипятке или надо заказать приготовление кофе к вагону, для кого-то.
Что делать?
Хочется пойти по классике онбординга, который никто не отменял. Поэтому в самом начале, я бы пошла собирать основную информацию и освоение я бы вела в следующих направлениях:
✅1.Устройство компании, в чем цель бизнеса, место айти команды в нём и аналитика соответственно. Ответ на вопрос где я?
✅2.Устройство команды, кто Тим Лид, какая была история создания. Как ведётся управление, какие методологии (если они вообще были). И как в этих процессах участвует аналитик. Ответ на вопрос кто я тут?
✅3.Карта stakholders, кто за что отвечает, кто мне ставит задачи, кто будет их принимать (100500 руководителей не самый лучший вариант). Мне же хочется закрыть задачу и закрыть сносно и успешно.
✅4.Управление проектами, продуктами, цели, сроки, бюджеты, ресурсы, риски. Как это всё влияет на мою задачу?
Основы, короче говоря, осмотрелась вокруг и поняла, в каком я вагоне отказалась, "горящем на полном ходу, или в вагоне ресторане", иначе сложно понять свою задачу и критерии того, как её делать, кому сдавать, закрывать.
Это первый шаг, а вы с чего начинаете работу над новым проектом?🤔
#запрыгнутьвпроект #онбординг #первыйшаг #правдажизни #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM