#uxui #проектирование #системныйанализ #системныйаналитик #мойопыт #капитанНЕочевидность #моемнение
Я очень рада, что эволюция команд разработки пришла к выводу, что команде нужен аналитик, и не любой член команды может быть аналитиком, но и кроме классического набора специалистов, команде нужен специалист по UX/UI.
А что нужно знать и уметь аналитику при соприкосновение со специалистом по UX/UI?
Итак, попробую составить список:
👉1. Понимать, что такое UI kit. Уметь его читать и работать с ним. Чтобы набор элементов интерфейсов был у всех единый.
👉2. Разбираться, и я бы даже сказала, что вытаскивать из front разработки архитектуру построения веб-интерфейса. Если у вас несколько окон, важно понять, чтобы переключаясь между окнами пользователь видел элементы управления на одних и тех же местах. А вы понимали, где что можно менять и располагать.
👉3. В одной из команд у нас был фреймворк front разработки. И это наше ограничение и инструмент. Поэтому аналитику нужно было понимать, что его фантазия и фантазия проектировщика ux/ui ограничена строгим набором элементов и их сочетанием.
👉4. У многих аналитиков проблема в том, что они не знают основные элементы веб-интерфейсов. Какой элемент, как работает, как называется. Стоит записывать названия за разрабами и проектировщиками, изучать, запоминать. А то начинается радиобаттон, становится чек боксом...
👉5. Не знаю как назвать, скажу что- веяние моды - и наверное виток развитие дизайна, это то что многие свои интерфейсы делают под гугл. И бывает бесполезно просить дизайнеров убирать серый цвет, потому что гугл всё делает именно так)))
👉6. Насмотренность. Смотрите как работают ваши конкуренты. Замечаете Паттерны в тех интерфейса, где вы, как пользователь, достигаете своей цели без эмоционных взрывов))) Если вы делаете ERP систему, посмотрите SAP, 1C, презентации разных систем.
👉7. Портрет пользователя (многие о нем забывают), можно найти в фотобанке или в справочнике сотрудников)))) тоже хорошо работает, когда говоришь, кто наш пользователь. Как ux/ui специалисту, так и команде разработки.
👉8. Без сценариев поведения пользователя в интерфейсе никуда))) тут конечно здорово проводить тестирование интерфейса и наблюдать за поведением реальных пользователей, очень прочищает мозги, когда видишь, что пользователь ведет себя не так, как ты думал и проектировал))
👉9. Знать названия, или в идеале уметь работать в самых распространенных приложениях моделирования, в которых работают проектировщики интерфейсов. Но на практике хватает visio, balsamiq, draw.io, axure. Рисовать кликабельные интерфейсы это уже топ. Я бы за рамками оставила.
👉10. Создавать макеты веб-интерфейса, как способ выявления требований. Тут очень аккуратно нужно быть, чтобы потом пользователь понимал, что это не 100% результат, или если интерфейс кликабельный, что это не равно рабочий интерфейс. И да, иногда макетом можно себя подписать под жёсткую разработку, если мы говорим, например, про госы.
👉11. И без мобильного приложения сейчас никуда. Так что стоит понимать как работает Android, IOS, как работает пользователь в том или другом интерфейсе. Аналитик у нас как-то спас команду, когда нарисовал диаграмму User Flow, показывая переходы по экранам мобилки. Я когда-то работала в приложение marvel, и переводила фоточки от руки нарисованных макетов в кликабельный интерфейс мобилки. Занимательно)
В заключение хочу сказать, что проектировщики ux/ui тоже выполняют часть анализа и очень круто, если в вашей команде есть такой человек)
Я очень рада, что эволюция команд разработки пришла к выводу, что команде нужен аналитик, и не любой член команды может быть аналитиком, но и кроме классического набора специалистов, команде нужен специалист по UX/UI.
А что нужно знать и уметь аналитику при соприкосновение со специалистом по UX/UI?
Итак, попробую составить список:
👉1. Понимать, что такое UI kit. Уметь его читать и работать с ним. Чтобы набор элементов интерфейсов был у всех единый.
👉2. Разбираться, и я бы даже сказала, что вытаскивать из front разработки архитектуру построения веб-интерфейса. Если у вас несколько окон, важно понять, чтобы переключаясь между окнами пользователь видел элементы управления на одних и тех же местах. А вы понимали, где что можно менять и располагать.
👉3. В одной из команд у нас был фреймворк front разработки. И это наше ограничение и инструмент. Поэтому аналитику нужно было понимать, что его фантазия и фантазия проектировщика ux/ui ограничена строгим набором элементов и их сочетанием.
👉4. У многих аналитиков проблема в том, что они не знают основные элементы веб-интерфейсов. Какой элемент, как работает, как называется. Стоит записывать названия за разрабами и проектировщиками, изучать, запоминать. А то начинается радиобаттон, становится чек боксом...
👉5. Не знаю как назвать, скажу что- веяние моды - и наверное виток развитие дизайна, это то что многие свои интерфейсы делают под гугл. И бывает бесполезно просить дизайнеров убирать серый цвет, потому что гугл всё делает именно так)))
👉6. Насмотренность. Смотрите как работают ваши конкуренты. Замечаете Паттерны в тех интерфейса, где вы, как пользователь, достигаете своей цели без эмоционных взрывов))) Если вы делаете ERP систему, посмотрите SAP, 1C, презентации разных систем.
👉7. Портрет пользователя (многие о нем забывают), можно найти в фотобанке или в справочнике сотрудников)))) тоже хорошо работает, когда говоришь, кто наш пользователь. Как ux/ui специалисту, так и команде разработки.
👉8. Без сценариев поведения пользователя в интерфейсе никуда))) тут конечно здорово проводить тестирование интерфейса и наблюдать за поведением реальных пользователей, очень прочищает мозги, когда видишь, что пользователь ведет себя не так, как ты думал и проектировал))
👉9. Знать названия, или в идеале уметь работать в самых распространенных приложениях моделирования, в которых работают проектировщики интерфейсов. Но на практике хватает visio, balsamiq, draw.io, axure. Рисовать кликабельные интерфейсы это уже топ. Я бы за рамками оставила.
👉10. Создавать макеты веб-интерфейса, как способ выявления требований. Тут очень аккуратно нужно быть, чтобы потом пользователь понимал, что это не 100% результат, или если интерфейс кликабельный, что это не равно рабочий интерфейс. И да, иногда макетом можно себя подписать под жёсткую разработку, если мы говорим, например, про госы.
👉11. И без мобильного приложения сейчас никуда. Так что стоит понимать как работает Android, IOS, как работает пользователь в том или другом интерфейсе. Аналитик у нас как-то спас команду, когда нарисовал диаграмму User Flow, показывая переходы по экранам мобилки. Я когда-то работала в приложение marvel, и переводила фоточки от руки нарисованных макетов в кликабельный интерфейс мобилки. Занимательно)
В заключение хочу сказать, что проектировщики ux/ui тоже выполняют часть анализа и очень круто, если в вашей команде есть такой человек)
Чем сложна интеграция?
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
курс проектирования интеграции, который мы развиваем с Андреем Корниенко это ещё и курс молодого бойца по проектированию информационных систем. Пока мы не хотим менять формат, наш курс больше похож на менторство, где в онлайн формате с участниками мы проходим основные шаги реализации проекта и разбираем трудности, которые чаще всего появляются. Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
sup.expert
Курс по интеграции
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
💥
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
✔️ Я и мой компаньон Андрей Корниенко, ведём курс в формате лекций, домашних заданий, обсуждений и менторства, чтобы показать, как именно аналитику нужно думать, чтобы спроектировать интеграцию.
✔️ У нас нет сумасшедших потоков, наше преимущество это работа в долгую, наш курс это аналитический марафон в 2 месяца. Мы специально даём время на освоение материала и его осознание.
✔️ Мы не фабрика, не огромная площадка, нам самим прежде всего интересно передать свои знания и опыт, так чтобы это было системно и структурно. Это даёт нам проявлять гибкость и нестандартно зачитывать материал.
📌 Подробнее о курсе можно прочитать тут https://sup.expert/
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!📣
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!
Please open Telegram to view this post
VIEW IN TELEGRAM
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, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея🤩 , понимаю, что уже несколько выпускников наших потоков курса поменяли работу и выросли в грейдах.
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний📈
Приходите к нам на интеграцию➡️ 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
Наташа Косинова. Варю айти СУП
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
Сначала вы работаете на интеграцию, потом интеграция работает на вас.
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
♟ Поискать инсайты и новую информацию, чего возможно я, как тренер, ментор, упускаю в системном подходе к проектированию интеграции. И довыявить точки расширения roadmap.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Please open Telegram to view this post
VIEW IN TELEGRAM
Аналитик исследует проблему и проектирует решение на языке требований.
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни
Интересно как много точек зрения на работу аналитика. И год за годом постоянно идут обсуждения по кругу, что должен или не должен делать аналитик. Когда я говорю, что аналитик проводит исследование, анализ проблемы, чтобы дальше перейти к описанию решения на языке требований, появляются альтернативные мнения.
Например, заказчику самому виднее, какое ему нужно решение и аналитик, просто сопровождает заказчика к результату, этого решения. Описывает. Хочется сказать, что становится тех писателем, секретарём или решателем.
Насколько подобная ситуация правдива?
Можно ли так работать аналитику?
И да, и нет, и с моей точки зрения, это ещё и вопрос компетенций аналитика и самого заказчика. Кто на что способен и в каких условиях оказалась команда и заказчик.
Если заказчик так уверен в своём решение, даже если оно ошибочное, проще сделать, чем спорить или убеждать.
И конечно вопрос ресурса, денег, времени и уровня критичности решаемой проблемы.
Чаще всего действительно заказчик приходит с решением в команду и команда это решение реализовывает. Да, и я так делала, мне принесли в клюве, я пошла и сделала. Могла повозмущаться или перепроверить решение, что когда ты рядовой аналитик сложно влиять на решение.
А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)
Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.
И вот потратив время на исследование проблемы, аналитик приступает к описанию решения на языке требований. И тут это отдельное искусство описать так, чтобы у команды была возможность выбрать технологии, оптимальные, эффектные реализации. Не прибивая всё гвоздями.
И будем реалистами, работа аналитика правда сложная, наши айти проекты правда сложные, и наши заказчики люди с множеством мыслей, эмоций, своим мнением, опытом, и к ним нужно искать подход, а работа с людьми это тяжело.
Как бы не хотел аналитик откреститься от заказчика, потому что, часто общение с заказчиком это сложно, ресурсоемко, и нужно быть психологом, коучем, чтобы найти контакт. Но горькая правда в том, что приходится прокачивать себя в переговорах, коммуникации и управление ожиданиями заказчика, чтобы исследовать проблему и только потом переходить к решению, которое должно помогать заказчику получать ожидаемый эффект.
Вот такие сегодня местами сложные мысли)
#мысливслух #сбортребований #исследование #проектирование #правдажизни