С Днём системного аналитика! 🎉
Сегодня чествуем тех, кто превращает запутанные требования в надежные решения и спасает проекты от хаоса. Пусть ваша документация всегда будет актуальна, а клиенты — чётко формулируют требования, в идеале, сразу с учётом критериев хороших требований!
Сегодня чествуем тех, кто превращает запутанные требования в надежные решения и спасает проекты от хаоса. Пусть ваша документация всегда будет актуальна, а клиенты — чётко формулируют требования, в идеале, сразу с учётом критериев хороших требований!
🎉16👍4🥰3💯1
❗Не забывайте про нашу Рубрику вопросов от подписчиков ✨
Есть вопросы о системном анализе, профессии аналитика или всё, что с этим связано? Пишите! Всё анонимно и без стеснения. 💬
Есть вопросы о системном анализе, профессии аналитика или всё, что с этим связано? Пишите! Всё анонимно и без стеснения. 💬
👍7
10 шагов к профессии системного аналитика 🚀
Вопрос от подписчика: «Что изучать, чтобы стать системным аналитиком? И нужно ли образование в сфере IT?»
Изучите:
1️⃣ Как устроен процесс разработки ПО? От Waterfall до Agile (Scrum, Kanban).
2️⃣ Узнайте, что ожидает каждый член команды разработки от СА.
3️⃣ Процесс работы с требованиями. Сюда же относятся навыки по Use Case и User Story.
4️⃣ Натренируйте аналитическое мышление. Научитесь прорабатывать алгоритмы, тех. процессы и бизнес-процессы.
5️⃣ Освойте нотации UML и DFD для визуализации алгоритмов и процессов.
6️⃣ Для моделирования бизнес-процессов дополнительно освойте BPMN и EPC.
7️⃣ Реляционные базы данных и SQL.
8️⃣ Научитесь проектировать ER-модель.
9️⃣ Познакомьтесь с форматами данных JSON и XML.
1️⃣0️⃣ Познакомьтесь с интеграциями.
Нужно ли IT-образование?
Нет, но это будет большим плюсом. IT-специальность в ВУЗе даёт базу, но всё это можно освоить самостоятельно. На курсах дают все необходимые знания для входа в профессию.
#questions
Вопрос от подписчика: «Что изучать, чтобы стать системным аналитиком? И нужно ли образование в сфере IT?»
Изучите:
1️⃣ Как устроен процесс разработки ПО? От Waterfall до Agile (Scrum, Kanban).
2️⃣ Узнайте, что ожидает каждый член команды разработки от СА.
3️⃣ Процесс работы с требованиями. Сюда же относятся навыки по Use Case и User Story.
4️⃣ Натренируйте аналитическое мышление. Научитесь прорабатывать алгоритмы, тех. процессы и бизнес-процессы.
5️⃣ Освойте нотации UML и DFD для визуализации алгоритмов и процессов.
6️⃣ Для моделирования бизнес-процессов дополнительно освойте BPMN и EPC.
7️⃣ Реляционные базы данных и SQL.
8️⃣ Научитесь проектировать ER-модель.
9️⃣ Познакомьтесь с форматами данных JSON и XML.
1️⃣0️⃣ Познакомьтесь с интеграциями.
Нужно ли IT-образование?
Нет, но это будет большим плюсом. IT-специальность в ВУЗе даёт базу, но всё это можно освоить самостоятельно. На курсах дают все необходимые знания для входа в профессию.
#questions
👍12🔥3🤔3👌1
Об AnalystCore. Знакомимся!
Мы основали AnalystCore в начале 2024 года.
👩💻 Вера — системный аналитик
👨💻 Юрий — фулстек-разработчик
Оба в IT более 7 лет.
В обычной жизни мы постоянно говорим об IT, рабочих кейсах и процессах. Мы любим технологии, и нам хотелось использовать в работе то, что нравится. Так пришла идея создать собственный проект.
🚀 Мы разработали свою платформу для проведения онлайн-курсов и запустили на ней курс по системному анализу.
Что нас вдохновило?
На рынке много материалов для СА, и они часто поданы только со стороны аналитика. Но мы пишем ТЗ и ставим задачи для разработчиков. Так что может быть лучше, чем спросить у самих разработчиков, что им нужно в ТЗ и задачах?
Наш курс — это тандем разработчика и аналитика. Мы подаём материал с двух точек зрения, СА и разработчика.
Развитие AnalystCore — наше любимое дело: мы обожаем разрабатывать системы и делиться знаниями по этой теме.
Мы основали AnalystCore в начале 2024 года.
👩💻 Вера — системный аналитик
👨💻 Юрий — фулстек-разработчик
Оба в IT более 7 лет.
В обычной жизни мы постоянно говорим об IT, рабочих кейсах и процессах. Мы любим технологии, и нам хотелось использовать в работе то, что нравится. Так пришла идея создать собственный проект.
🚀 Мы разработали свою платформу для проведения онлайн-курсов и запустили на ней курс по системному анализу.
Что нас вдохновило?
На рынке много материалов для СА, и они часто поданы только со стороны аналитика. Но мы пишем ТЗ и ставим задачи для разработчиков. Так что может быть лучше, чем спросить у самих разработчиков, что им нужно в ТЗ и задачах?
Наш курс — это тандем разработчика и аналитика. Мы подаём материал с двух точек зрения, СА и разработчика.
Развитие AnalystCore — наше любимое дело: мы обожаем разрабатывать системы и делиться знаниями по этой теме.
🔥15👍5🎉2💯2
Приветствуем всех наших подписчиков! Нам важно узнать, кто вы и чем занимаетесь, чтобы делать контент ещё интереснее и полезнее для вас. Пожалуйста, примите участие в опросе ниже.
Anonymous Poll
47%
📝 Я — системный аналитик
27%
💡 Планирую стать системным аналитиком
18%
🤔 Работаю в IT, задумываюсь о переходе в системный анализ
5%
👀 Работаю в IT, менять направление не хочу
4%
🧐 Не из IT, просто интересуюсь темой системного анализа
👍7
Вводим новую рубрику 🎉
Взгляд системного аналитика и разработчика
Рады представить вам новую рубрику! В ней мы будем писать о процессах, рабочих кейсах, о болях и прочих холиварных темах.
Мы хотим сделать эту рубрику максимально полезной и интересной для вас. Поэтому призываем вас активно участвовать:
* Пишите свои вопросы.
* Делитесь темами, которые вам интересны.
* Рассказывайте о своих кейсах и наблюдениях.
Взгляд системного аналитика и разработчика
Рады представить вам новую рубрику! В ней мы будем писать о процессах, рабочих кейсах, о болях и прочих холиварных темах.
Мы хотим сделать эту рубрику максимально полезной и интересной для вас. Поэтому призываем вас активно участвовать:
* Пишите свои вопросы.
* Делитесь темами, которые вам интересны.
* Рассказывайте о своих кейсах и наблюдениях.
👍7💯5🔥2
Как работать с требованиями, когда заказчик не знает, чего хочет?
Команда разработки не может работать с верхнеуровневыми требованиями — нам нужны детали. Задача системного аналитика — выявить эти детали. Но бывает так, что, пытаясь выяснить больше, мы заходим в тупик: заказчик не может объяснить, чего он хочет.
Что делать в такой ситуации? Вот один из лайфхаков 👇
Попросите заказчика показать аналогичные системы, которые примерно соответствуют его видению. Попросите ссылки, скриншоты, любые материалы. Это поможет понять, что заказчик считает важным.
Вне зависимости от того, дали вам аналоги или нет, сформируйте своё решение за заказчика и представьте идеи в виде макетов или кликабельных прототипов. Критиковать всегда проще, чем придумывать что-то с нуля! 😉 Глядя на ваши наработки, заказчик сможет сказать, что ему не нравится, что хочет изменить или добавить. И вуаля, требования становятся более конкретными, чем были вначале.
Помогайте заказчикам! 🤝
Команда разработки не может работать с верхнеуровневыми требованиями — нам нужны детали. Задача системного аналитика — выявить эти детали. Но бывает так, что, пытаясь выяснить больше, мы заходим в тупик: заказчик не может объяснить, чего он хочет.
Что делать в такой ситуации? Вот один из лайфхаков 👇
Попросите заказчика показать аналогичные системы, которые примерно соответствуют его видению. Попросите ссылки, скриншоты, любые материалы. Это поможет понять, что заказчик считает важным.
Вне зависимости от того, дали вам аналоги или нет, сформируйте своё решение за заказчика и представьте идеи в виде макетов или кликабельных прототипов. Критиковать всегда проще, чем придумывать что-то с нуля! 😉 Глядя на ваши наработки, заказчик сможет сказать, что ему не нравится, что хочет изменить или добавить. И вуаля, требования становятся более конкретными, чем были вначале.
Помогайте заказчикам! 🤝
👍11💯2
Насколько подробно описывать задачи по БД?
Вопрос от подписчика: «Насколько подробное должно быть описание БД для постановки задач на разработку? Прорабатывать ли вопросы безопасности, методы резервирования, варианты отказоустойчивости?»
На самом деле, уровень детализации задачи зависит от предпочтений команды. Мы выделили 2 уровня описания задачи по БД, смотрите их в картинках. 👆
Главное, чтобы было описание всех сущностей, связей между ними и атрибутов. Также указываем нефункциональные требования с позиции, а что критично для бизнеса: какой допустимый объём потери данных; какой прогнозируемый рост данных (например, через год) и пр.
По безопасности системный аналитик продумывает роли, уровни доступа и сценарии использования. А вот выбор алгоритмов шифрования для паролей или определение методов хранения паролей (как правильно «подсолить») — это задача сотрудника, который ответственен за техническую часть проекта. Если этот ответственный — системный аналитик, то это его задача. Но чаще всего это работа техлида или разработчика.
Важно понимать, что команда разработки занимается не только новыми фичами, но и обслуживанием и поддержкой. Разработчики постоянно следят за метриками и ищут пути улучшения. Поэтому такие задачи, как балансировка нагрузки, резервирование и прочие выполняются фоном, без запроса от заказчика или владельца продукта. Это то, о чём разработчики думают по умолчанию, без задачи от системного аналитика. 😅
❗️Если вы занимаетесь проработкой всех этих вопросов, возможно, ваш техлид перекладывает на вас часть своих обязанностей.
#questions
Вопрос от подписчика: «Насколько подробное должно быть описание БД для постановки задач на разработку? Прорабатывать ли вопросы безопасности, методы резервирования, варианты отказоустойчивости?»
На самом деле, уровень детализации задачи зависит от предпочтений команды. Мы выделили 2 уровня описания задачи по БД, смотрите их в картинках. 👆
Главное, чтобы было описание всех сущностей, связей между ними и атрибутов. Также указываем нефункциональные требования с позиции, а что критично для бизнеса: какой допустимый объём потери данных; какой прогнозируемый рост данных (например, через год) и пр.
По безопасности системный аналитик продумывает роли, уровни доступа и сценарии использования. А вот выбор алгоритмов шифрования для паролей или определение методов хранения паролей (как правильно «подсолить») — это задача сотрудника, который ответственен за техническую часть проекта. Если этот ответственный — системный аналитик, то это его задача. Но чаще всего это работа техлида или разработчика.
Важно понимать, что команда разработки занимается не только новыми фичами, но и обслуживанием и поддержкой. Разработчики постоянно следят за метриками и ищут пути улучшения. Поэтому такие задачи, как балансировка нагрузки, резервирование и прочие выполняются фоном, без запроса от заказчика или владельца продукта. Это то, о чём разработчики думают по умолчанию, без задачи от системного аналитика. 😅
❗️Если вы занимаетесь проработкой всех этих вопросов, возможно, ваш техлид перекладывает на вас часть своих обязанностей.
#questions
👍8🔥4💯2
T-shape = как легко забыть системный анализ
Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Мне захотелось поделиться своим отношением к T-shape.
СА могут привлечь к разным задачам, вплоть до развёртывания приложений, написания сложных SQL-миграций, кодинга, настройки различных инструментов и пр.
С одной стороны, мы расширяем кругозор. Но с другой, если эта «Tи-шейпная» задача — не разовая акция, и теперь занимает 1 день из 5 — это уже не ОК. Так аналитик занимается системным анализом всё меньше, и в итоге выходит на рынок с большим опытом, но слабым в СА: он становится невнимательным, забивает на документацию и пр.
НО! Есть практики, с которыми мы сталкиваемся часто. Мы рисуем макеты и тестируем ПО. К этому я отношусь спокойно. 😅 Но и здесь: мы не нарисуем макеты идеально, не продумаем адаптивность, не исправим автотесты и т. д. То есть, эту работу мы не выполним на 100% качественно.
...
А как вы относитесь к T-shape? Был ли у вас подобный опыт?
#sa_dev
Рубрика: взгляд СА на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера.
Мне захотелось поделиться своим отношением к T-shape.
СА могут привлечь к разным задачам, вплоть до развёртывания приложений, написания сложных SQL-миграций, кодинга, настройки различных инструментов и пр.
С одной стороны, мы расширяем кругозор. Но с другой, если эта «Tи-шейпная» задача — не разовая акция, и теперь занимает 1 день из 5 — это уже не ОК. Так аналитик занимается системным анализом всё меньше, и в итоге выходит на рынок с большим опытом, но слабым в СА: он становится невнимательным, забивает на документацию и пр.
НО! Есть практики, с которыми мы сталкиваемся часто. Мы рисуем макеты и тестируем ПО. К этому я отношусь спокойно. 😅 Но и здесь: мы не нарисуем макеты идеально, не продумаем адаптивность, не исправим автотесты и т. д. То есть, эту работу мы не выполним на 100% качественно.
...
А как вы относитесь к T-shape? Был ли у вас подобный опыт?
#sa_dev
👍9🔥3👏3💯2
Шаблон в User Story — необязательный 😱
Вовсе не обязательно следовать шаблону «Я, как <роль>, хочу <то-то>, чтобы <что-то>».
Фразы вроде «Регистрация» или «Авторизация» тоже могут быть историями, если команда понимает, что за ними стоит.
Суть User Story — зафиксировать потребность пользователя, а не следовать формату ради самого формата. История может быть записана любым удобным способом, главное, чтобы при просмотре карточки участники обсуждения вспомнили, о чём шла речь и что нужно сделать.
❗Безусловно, шаблон полезен. Если можно указать роль пользователя и его цель — сделайте это. Но иногда это излишне. Например, когда приложение имеет только одну роль — Клиент, или если задача техническая. А бывает, что цель неочевидна, и попытка следовать шаблону приводит к созданию несуразных формулировок в роде «потому что потому».
Вовсе не обязательно следовать шаблону «Я, как <роль>, хочу <то-то>, чтобы <что-то>».
Фразы вроде «Регистрация» или «Авторизация» тоже могут быть историями, если команда понимает, что за ними стоит.
Суть User Story — зафиксировать потребность пользователя, а не следовать формату ради самого формата. История может быть записана любым удобным способом, главное, чтобы при просмотре карточки участники обсуждения вспомнили, о чём шла речь и что нужно сделать.
❗Безусловно, шаблон полезен. Если можно указать роль пользователя и его цель — сделайте это. Но иногда это излишне. Например, когда приложение имеет только одну роль — Клиент, или если задача техническая. А бывает, что цель неочевидна, и попытка следовать шаблону приводит к созданию несуразных формулировок в роде «потому что потому».
👍7🔥3💯3
Доброе утро, коллеги! 🌅
Понедельник — это очередной шанс начать неделю продуктивно и с новыми идеями. Да здравствует «новая жизнь»! 🙌
Да, может быть, ещё не все проснулись, но уже пора разгоняться. Чтобы немного облегчить начало рабочей недели, напомните себе:
- Что вас ждёт в конце этой недели? Маленькие цели ведут к большим победам.
- Какие 3 задачи сегодня нужно закрыть, чтобы почувствовать себя молодцом?
- Чем порадуете себя после работы? Очень важен позитивный настрой на всю неделю.
Кофе уже на столе? ☕
Погнали! 🚀
Понедельник — это очередной шанс начать неделю продуктивно и с новыми идеями. Да здравствует «новая жизнь»! 🙌
Да, может быть, ещё не все проснулись, но уже пора разгоняться. Чтобы немного облегчить начало рабочей недели, напомните себе:
- Что вас ждёт в конце этой недели? Маленькие цели ведут к большим победам.
- Какие 3 задачи сегодня нужно закрыть, чтобы почувствовать себя молодцом?
- Чем порадуете себя после работы? Очень важен позитивный настрой на всю неделю.
Кофе уже на столе? ☕
Погнали! 🚀
❤6👍3💯3
Пример описания задачи по БД
Ранее мы говорили о шаблоне описания задачи по БД. Сегодня разберём пример — всё смотрите в картинках. 👆
Наша задача — проработать модель данных, уточнить требования и обсудить всё с командой. Важно отметить, что СУБД ещё не выбрана.
#db
Ранее мы говорили о шаблоне описания задачи по БД. Сегодня разберём пример — всё смотрите в картинках. 👆
Наша задача — проработать модель данных, уточнить требования и обсудить всё с командой. Важно отметить, что СУБД ещё не выбрана.
#db
👍10🔥5❤🔥4💯1