С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Аналитик, догони разработку!
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанноголошадь аналитика, который уже на грани срыва, где глаза наполняются слезами и он не понимает зачем он нужен, что он тут делает и весь мир тлен.
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"😵💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (кто-то скажет, он нам не нужен, хорошо, тогда не нанимайте подобных специалистов и не ждите от них результатов ). Аналитик занимается проектированием, а оно в свою очередь нужно перед разработкой программных продуктов, для описания решения на языке требований, чтобы в конечном итоге снизить неопределённость и уменьшить количество переделок.
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
😏 - повеселеет (руководство чаще всего думают, что все аналитики вечно в депрессии из-за кислого выражения лица, просто мы знаем чуть больше и нам трудно)))
😎 -станет более заряженный, будет действовать в интересах команды и приносить проработанные задачи на обсуждение разработчикам.
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Часто аналитик попадает в ловушку под названием "разработка опережает анализ".
При этом аналитик начинает летать в облаках "вот, вот, я сейчас поднажму и всех догоню!", ага, ага, плавали знаем... Турбо ускорителя у меня нет, да думаю и у вас тоже нет, у меня ни разу не получалось.
А кто-то скажет, а что в этом такого? Пусть разработка опережает, ничего страшного.
При этом мы видим загнанного
А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять"
В такой ситуации аналитик больше похож на уборщицу магазина, которая ходит нонстоп за посетителями и вытирает след от грязных ботинок. Но попросить разуться при входе, не может, так вроде заведено...
Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.
-------------------------------
Что можно с этим сделать:
✅ первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)
✅ второе, вспомнить зачем нужен анализ и технические задания, зачем нужен аналитик (
✅ аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)
✅ признаться аналитику, что вам нужен тестировщик или технический писатель, а что?)) может правда нужны другие специалисты
✅ и в конце концов поставить анализ перед разработкой, и дать аналитику возможность опережать разработку хотя бы на полспринта, а лучше на целый спринт.
Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.
И тогда наш аналитик:
А тут, глядишь и оценка сроков станет более чёткой)))
Сплошные плюсы, а всего лишь, всё расставили по своим местам))
#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Please open Telegram to view this post
VIEW IN TELEGRAM