6️⃣ Тестируемая

Команда должна хорошо представлять, как проверить исполнимость истории. Нетестируемые истории (те, что нельзя проверить) по большей части возникают для нефункциональных требований.

👎 Как пользователь, я не хочу долго ждать создания личного кабинета, чтобы быстрее приступать к оформлению заказа в приложении.

👍 Как пользователь, я хочу, чтобы личный кабинет создавался не дольше двух секунд, чтобы быстрее приступать к оформлению заказа в приложении.

Первую историю проблематично тестировать из-за формулировки «долго», потому что каждый может тракотовать долготу по своему. Вторую историю мы сможем протестировать, а значит, она будет соответствовать последнему INVEST-критерию.



Подведём итог.

При формировании пользовательских историй старайтесь соблюсти два правила:

🔑 Стройте историю по шаблону:
Как [роль], я хочу [выполнить задачу], чтобы [достичь цель];

🔑 Соблюдайте INVEST-критерии в формулировке.

Благодаря этому вы и ваша команда сможете грамотно оценить и спланировать работу в проектировании ПО 😊

Друзья, всем привет!😊


Недавно мы рассказывали вам про INVEST-критерии для грамотной формулировки пользовательских историй (user stories). Предлагаем вам закрепить полученные знания и пройти КВИЗ 👀💡

Представьте, что вам необходимо проверить пользовательские истории, которые сформулировал ваш коллега-аналитик 🦸‍♀️🦸
Ознакомьтесь с условиями каждого вопроса и укажите, соответствует ли история заданному критерию.

Пока коллега несёт вам документацию, предлагаем отмотать сообщения выше и вспомнить про каждый из критериев 😉

Начинаем через два часа ⏰💥 #quizGetAnalyst

1️⃣ Внимательно изучите историю:

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

2️⃣ Проверим выполнимость критерия масштабируемости.

Вы уже знаете, что в разработку рекомендуется передавать истории низкого уровня, которые максимально детализированы.


Вернёмся к нашей истории про хранение персональных данных:

🔸 Как пользователь, я хочу, чтобы мои персональные данные хранились в системе в зашифрованном виде, чтобы предотвратить утечку данных.

И финальный вопрос (в чём сила?) 👀

3️⃣ Внимательно изучите историю:

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

💥 БОНУСНЫЙ ВОПРОС для самых умниц
(то есть для всех вас) 😊🖤

Представьте, что в бэклоге продукта две истории:

🔸 Как пользователь, я хочу привязывать банковскую карту к профилю, чтобы удобнее оплачивать заказы в приложении;

🔸 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных.

Друзья, очень важно не забывать, что история может совсем не соотвествовать INVEST-критериям (не надо так), а может соответствовать только части из них.


Разберём на примере:

🔹 Как пользователь, я хочу, чтобы номер моей банковской карты хранился в системе в зашифрованном виде, чтобы предотвратить утечку данных

☝️ История явно не выполняет критерий оцениваемости, потому что нет информации о том, каким способом необходимо зашифровать номер банковской карты.

✌️Но эту историю можно протестировать, банально проведя анализ того, какие данные указывает клиент и как они отображаются в системе и на интерфейсе пользователя.



Задача бизнес- и системного аналитика как раз и заключается в том, чтобы сформировать конечное пользовательское требование в истории так, чтобы все INVEST-критерии были учтены.
Поэтому очень круто, что мы можем ошибаться на этапе обучения, чтобы потом меньше ошибаться на реальных проектах, верно? 🙃


Вот такие вот дела. Как вам КВИЗ, кстати?
Если такой формат для закрепления материала понравился, ставьте реакции – будем почаще запускать 😊

В мире IT существуют два вида аналитиков: бизнес-аналитики и системные аналитики #expertGetAnalyst

🟡 Бизнес-аналитики разбираются в потребностях заказчика в автоматизации бизнеса.
🟡 Системные аналитики превращают потребности заказчика в понятные задачи для команды разработки, а также занимаются проектированием функциональной и архитектурной части систем.

Системный аналитик - это почти архитектор, который строит фундамент системы и рассказывает как она должна работать программистам и тестировщикам. Без нашей работы процесс разработки был бы хаосом из переговоров между непонимающими друг-друга программистами и бизнес-заказчиками.

В статье "О роли системного аналитика и шаблоне для проектирования" я рассказала:
▫️кто такие аналитики в IT,
▫️познакомила с их задачами,
▫️поделилась шаблоном для написания требований и постановки задач.

Если вы только пытаетесь понять кто такие системные аналитики и их зону ответственности, или уже работаете системным аналитиком и ищете свои точки роста, то эта статья для вас 😉

У многих не было возможности подойти к делу, которым они занимаются, осознанно, с толком, чтобы нравилось изначально. Обычно просто нет на это времени.

Очень много случааев, что работа или учеба были выбраны, потому что так сказали родители, или потому что нужны были деньги и важно было закрыть базовые потребности.

Но есть и другие истории, когда люди выбирали из того, что нравится. Так как не было финансовых проблем, или ранняя осознанность, что случается реже.
Я рассказывала о том, что выбрала профессию системного аналитика сразу после школы. Но мой случай скорее исключение из правил, чем норма.
И если так получилось, что свою работу вы выбрали сами, то скорее всего вы кайфуете от нее, как я от системного анализа ❤️

Сейчас я делюсь своей любовью к профессии с вами, рассказываю о своем призвании. Чтобы вы могли посмотреть на эту ИТ-профессию моими глазами и принять осознанное решение куда и как расти в ИТ, или как войти в ИТ на позицию системного аналитика.

Важно, чтобы при выборе профессии было время подумать и не было паники. И появлялось ощущение кайфа от того, чем вы будете заниматься. Хорошо, когда есть возможность попробовать поделать что-то на практике. В фоне к основной работе. Не обязательно менять резко свою сферу деятельности.

Для меня в профессии аналитика кайф - это релиз. Когда я вижу, как результаты сбора требований, проектирования, плотной работы с разработчиками и тестировщиками, начинают приносить пользу людям. Это важно 🙌

Я точно знаю, что своё дело можно выбрать в любой момент. Можно менять профессию, менять компанию, направление деятельности, расти в должности. Главное заниматься тем, что нравится, прямо сегодня.

И хорошо, когда рядом с вами есть люди, которые вас поддерживают: любимые, родные, друзья и наставники. Их энергия поможет пройти любые испытания и преодолеть любые трудности. Их поддержка - ваша мотивация расти.

Окружайте себя людьми, кто верит в вас. И тогда любые перемены и рост в карьере будут даваться вам в гармонии, уверенности и с легкостью 🚀❤️

Привет! Записала для вас подкаст про то, как аналитики могут влиять на риски в IT-проектах и помогать их выявлять 😉

Когда все идет легко, то меня это напрягает. Значит я стою на месте, и не развивюсь. В этот момент я говорю себе - пора 🚀 И начинаются удивительные приключения... Так я уже почти 2 года непрерывно чувствую себя тупой. И страшно, и интересно 🤔

Часто наш рост ограничивают установки и ограничения, которые мы носим с собой. Но иногда нам нужно собраться с силами и выбросить их. Ведь только отказавшись от них мы сможем меняться и развиться.

Знаете, иногда в шкафу есть старые вещи. Какие-то мы вообще не носим, потому что они вышли из моды, не очень нравятся, но занимают место. А какие-то уже старые и стёртые до дыр, но любимые и удобные. Шкаф захламлен привычным. И на внутренний вопрос "А могу ли я купить новую красивую одежду?" я раньше отвечала себе "Ну у меня же полно старых вещей, полный гардероб, не надо пока, всё есть. Потом куплю". Знакомо?

Так и со знаниями. Они у нас уже есть. Много старых, которыми мы не особо пользуемся. А есть регулярно применяемые в работе, и мы чувствуем себя с ними хорошо. Нам комфортно. И на вопрос "А надо ли мне сейчас учиться?". Ответ понятен...

Помните кайф, когда покупаешь новые красивые вещи? И чтобы все помещалось в шкафу, я периодически собираю часть старых вещей и выбрасываю. А 3 раза жизнь заставила оказаться в ситуациях, когда старых вещей больше нет, и весь гардероб приходилось собирать с нуля. В этот момент жизнь подталкивала менять всё принудительно, было сложно. Но я оглядываюсь и говорю этим ситуациям спасибо!

Я постоянно донаращиваю знания в разных направлениях: архитектура систем, управление бизнесом, маркетинговый анализ... Ищу обучения, встречи сообществ, конференции, новые проекты. Я привыкаю, что рост кажый день и глобальные изменения почти каждый месяц - это нормально. Это постоянный кайф!

Бывает страшно оставлять старое, выходить из зоны комфорта, менять работу или начинать учиться с нуля. Но именно в этих моментах мы меняем свою жизнь к лучшему. И когда мы оглядываемся назад, благодарим себя за смелые шаги.

Если всё идёт легко, то скорее всего ты стоишь на месте. Но если трудно, если нужно преодолеть сложности, то поздравляю! Ты на пути к росту, и я уверена, что ты справишься. Ты силен и готов к вызовам!

Помни, что изменения происходят постепенно. Не нужно сразу бросать всё и начинать с чистого листа. Просто постепенно убирай часть старых установок, вводи новые привычки. Маленькие шаги приведут к большим изменениям 🌟

Не бойся меняться и расти! Всё получится! 🔝

Какие установки и привычки вы меняете сегодня? К чему идете? Делитесь в комментариях! 👇

Друзья, всем привет! ✌️
Меня зовут Нина и я бизнес-аналитик команды GetAnalyst 🥷🌪

Сегодня хочу поговорить об этапах разработки продукта в IT-компании и рассказать про свой опыт работы аналитиком в нескольких крупных проектах по разработке софта. #expertGetAnalyst

Важно сразу сделать оговорку, что жизненный цикл разработки ПО в большинстве компаний схож и состоит из следующих последовательных этапов:

1️⃣ Сбор и анализ требований;
2️⃣ Документирование требований;
3️⃣ Проектирование архитектуры решения;
4️⃣ Разработка системы;
5️⃣ Тестирование созданной системы;
6️⃣ Внедрение и перевод в поддержку и развитие.


В зависимости от типа задачи и правил, принятых внутри компании, некоторые этапы могут:

🔸 сливаться в один;
Например, сбор и анализ требований идёт в параллель с их документированием.

🔸 выпадать из цикла разработки, потому что в нём нет необходимости.
Например, при рефакторинге системы не всегда нужен этап аналитики, а при работе с данными – этап тестирования.

Но помимо того, как адаптируется процесс разработки ПО под компанию, точно также размываются границы ответственности аналитика в этом процессе.

Далее расскажу про два кейса участия аналитика в разработке ПО из своей жизни, пристёгивайтесь.


1️⃣ Я пришла в крупную логистическую компанию, которая только начала набирать обороты в IT-сфере. Поэтому некоторые процессы внутри были ещё не до конца проработаны. В том числе те, что были связаны с работой аналитика.

Вообще казалось, что аналитик нужен был в компании для того, чтобы разгрузить команду разработки от задачи коммуницировать с бизнес-заказчиком, тем самым позволив им больше времени уделять коду.

Именно поэтому задача аналитика была:

🔹 собрать требования с заказчика;
🔹 описать техническую документацию;
🔹 разработать прототипы с низкой и средней точностью.

Далее требования передавались в разработку, а прототипы – дизайнерам в качестве референсов для проектирования конечного интерфейса.

Иными словами, аналитик был не только аналитиком, который формулирует требования к решению, но ещё и джуниор- дизайнером, который лучше всех понимает заказчика – ведь он говорит с ним на одном языке.


2️⃣ В другой компании я тоже не была просто бизнес-аналитиком. Скорее это была фулстек позиция, где ты и бизнес-, и системный, и ещё немного дата-аналитик.

В мои обязанности, помимо работы с требованиями, входило:

🔹 находить точки оптимизации процессов,
🔹проектировать архитектуру решения с учётом возможностей системы (согласуя концепции с разработчиками),
🔹 искать закономерности в данных.
Но прототипы интерфейсов уже не далала – они приходили ко мне вместе с задачей от заказчика и всё, что мне нужно было с ними сделать – это провести ревью и отслеживать их актуальность.


☝️Короче говоря, аналитик – это универсальный IT-специалист, которому необходимо иметь множество навыков в разных сферах IT. Особенно если ты работаешь в РФ.

Набор должностных обязанностей аналитика в компании может зависеть от:

🔸 сферы деятельности компании;
🔸 грейдной сетки (то есть уровня аналитика);
🔸 типа задачи, которую отдают в отдел разработки.

Если небольшие компании ещё могут позволить себе разделить обязанности аналитика между другими членами проектной команды: разработчиком, тестировщиком и менеджером проекта, то в средних и крупных компаниях это почти невозможно.

Чем крупнее компания, тем более чёткие в ней разграничения между аналитиками в команде. Но хороший аналитик должен уметь чуть больше, чем требуется в моменте.

Например, я, как бизнес-аналитик, не могу ограничиться только софт-скиллами и хард скилами работы с требованиями. После погружения в системную архитектуру (хвала GetAnalyst!🖤) и дизайн я стала передавать более качественные требования к разработке (в том числе к интеграции), а анализ представленного интерфейса теперь основывается не только на «паучьем чутье», но и на знаниях UX/UI-правил проектирования.

Подвожу итог.

Друзья, если вы ещё не испугались того, что аналитик – это не только «многоденег», но и:

💥 нон-стоп учёба;
💥 постоянное присутствие в проекте на всех этапах разработки;
💥 страховка бизнеса от возможных рисков;
💥 высокая ответственность

и всё ещё хотите ступить на этот путь воина 🥷, то вы настоящие смельчаки, а ещё невероятно амбициозные ребята!

У таких крутых специалистов обязательно всё получится, особенно с командой GetAnalyst во главе с Екатериной Ананьевой 🚀