Есть улей, в котором пчелы делают мёд. Чтобы сделать мёд, им нужен нектар. Без нектара мёд не получится.

Пусть мобильное приложение (улей) дожно показать нам расписание авиарейсов (мёд). Для этого оно делает запрос на сервер (система "Цветы"), чтобы получить данные из него (нектар).

На сервере выполняются сложные алгоритмы и сбор данных по БД в определенную структуру.

Как только данные подготовлены они возвращаются на клиента, в мобильное приложение (улей).

Мобильное приложение обрабатывает данные, размещает их определенным образом в пользовательском интерфейсе (UI).

После этого счастливые пользователи видят расписание рейсов (мёд).

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

Простыми словами про API приложений 🐝

Привет! Возвращаюсь к вам после небольшого перерыва 😉

Как всегда много событий:
🚀 Запустили 2 потока по Интеграциям на прошлой неделе.
🚀 Провела вебинар по массивам, синхронным и асинхронным запросам в REST API.
🚀 Писала стратегические планы и работала над бизнес-процессами в компаниях.
🚀 Готовы обновления на сайт про большой курс по системному анализу.
🚀 Обновлена его программа. Буду уточнять детали на этой неделе. Получилось что-то очень крутое! К концу недели анонсирую.
🚀 Продолжаю получать бизнес-навыки по программе MBA и применяю сразу, чтобы убедиться, что они работают.
🚀 Новый проект, который совмещает в себе все мои текущие навыки по ИТ и маркетингу, и еще чуть больше!
☀️Отдыхала.

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

У меня был период в последний год, да и ранее тоже, когда я была в графике 7/0, без отрыва от производства. И я не страдала. Мне это действительно нравилось, и я кайфовала! Просто в какой-то момент я заметила, что уже по привычке работаю на количество времени. И это не про продуктивность. Бывало у вас такое?

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

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

Готова врываться в неделю, быть продуктивной, и делиться с вами лайфхаками из рабочих процессов 😉 Живите жизнь не только у монитора, не забывайте вовремя перезагружаться! ❤️

P.S. Заглядывайте сегодня на квиз в GetAnalyst для начинающих системных аналитиков 🚀

Про детализацию требований 🧐

В работе системного аналитика мне всегда нравилось то, что мы видим системы гораздо шире, чем любой другой участник IT-команды.

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

Программисты делают конкретные задачи и чаще всего знакомятся с системой точечно. А аналитик в работе над своей задачей ищет все зависимости и изменения, к которым приведет новая функциональность.

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

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

Есть ли у вас свой подход к работе с задачами, универсальный порядок действий, чтобы не упустить детали? 👀 Делитесь в комментариях!

Общий подход к работе с любой задачей на системный анализ, в том числе на интеграции:

1. Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
2. Определение ролей пользователей и приложений, которые будут задействованы
3. Выделение и описание основных сценариев
4. Проработка альтернативных сценариев
5. Задачи на дизайнера
6. Проработка архитектуры решения совместно с архитекторами
7. Знакомство с API. Тестирование методов бэкенда нашей или внешней системы
8. Дополнение сценариев методами API и особенностями, возникшими после проработки архитектурного решения
9. Определение ключевых данных: сущности и их свойства
10. Задачи на доработку БД
11. Задачи на подготовку тестовых данных
12. Задачи на разработку методов Backend (API)
13. Задачи на фронтенд / мобильные
14. Задачи на тестирование
15. Задачи на подготовку пользовательских инструкций
16. Задачи на сохранение важных артефактов по документации после разработки


Этот общий подход адаптируется в зависимости от типа задачи и проекта. Но его я придерживаюсь, чтобы не упустить детали проектирования и все-все-все задачи на команду 🔑

Привет! Давно подкастов не было. Рискнем? 👀

Риски в IT-проектах и как системный аналитик может помочь их выявить или избежать 😎

Про риски:
😱 Срыв сроков
😱 Коммуникации с заказчиком
😱 Команда лишается бойцов на время отпусков/болезней
😱 Нет документации
😱 Изменения требований на ходу
😱 Неучтенные детали технической реализации и невыполнимость требований
😱 Неоднозначные формулировки требований

Все бывает. И давайте разберёмся, как с этим всем справляться 😏

Встань и сделай 15 приседаний 🤨

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

Но при всех плюсах, для меня стали минусами:
➖ Приходится заставлять себя выходить из дома. И вообще ходить. Особенно в холодное или пасмурное время года.
➖ Размытые границы рабочего дня.
➖ Работать там, где спишь, категорически запрещено. Это просто факт. Спальня 100% отдельно от "кабинета".
➖ Неподвижный и сидячий день стал еще более неподвижным и сидячим.

Основная боль - малоподвижность. Мышцы атрофируются, самочувствие хуже, энергия падает, продуктивность и настроение тоже.

Уже 5 лет я занимаюсь спортом. 3-5 раз в неделю. Все, кто подписан на меня в Инста, знают, что тренировки - моя ежедневная рутина. Зал 6-7 раз в неделю. Но для кого-то это нереально. Мы разные и это ок 👍

Делюсь 5 лайфкаками, как сделать себя подвижными с нашей неподвижной работой без ежедневных походов в зал и быть в форме 💪

🟢 Поставь напоминания о перемещении = 1 раз в 60 мин. Выбирайте цель. Например, пройти 5 кругов по дому.

🟢 Забудь про лифты – выбирай лестницу!

🟢 Обязательная послеобеденная прогулка или прогулка в дальний магазин от дома за каким-то снеком каждый день (я так за протеиновыми батончиками хожу 😄)

🟢 Митинги стоя. Если мне не нужно рисовать или печатать, то хожу с ноутбуком по дому.

🟢 Найди РЕГУЛЯРНЫЙ командный вид активности, который понравится: танцы, плавание, велосипед, волейбол, или что-то еще, что приносит удовольствие. А команда заставляет приходить

Еще есть вариант с "придумай офис". У меня был период, когда я гуляла по кофейням.

Возьмите для начала что-то одно и попробуйте внедрить в свою жизнь, если чувствуете, что не хватает движения.

Ие забывай про правильное питание и пить достаточно воды.

А сейчас... Встань и сделай 15 приседаний ❤️

Делитесь, с какими еще проблемами сталкиваетесь на удаленке и как решаете👇

А сейчас представьте ребёнка. Возраст не важен.

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

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

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

Но в то же время мы часто хотим прорыва в жизни.
И часто — это прорыв возможен, когда есть тыл за спиной. Поэтому, если чувствуете, что хочется перемен, смены деятельности, но есть сомнения, страхи, волнение, то не стесняйтесь обратиться за поддержкой. Разговаривайте с близкими, меняйте окружение, ищите наставников, и погружайтесь в новое постепенно.

В каждом из нас есть тот самый любопытный ребёнок, который хочет учиться, познавать мир. Поддержите его!
Неужели вы бы сказали своему ребёнку при первых попытках его в каком-то деле: «У тебя не получится», «Не берись», «Это не твоё». Вряд ли.

Эти фразы-сорняки нужно убрать и в отношении себя!
Ведь кто, если не мы сами, в первую очередь должны поверить в себя и свои начинания?

Переменам необходимо давать шанс. Они могут открыть новую интересную страницу жизни.

Так произошло со мной ни раз. Мне было страшно делать первые шаги в неизвестность. Но благодаря поддержке и вере окружения, близких, я в сегодняшнем дне. Каждый день я открываю глаза, смотрю за окно, и говорю себе: “Это правда моя жизнь? Спасибо, что не испугалась делать смелые шаги!”.

И у тебя получится. Я в тебя верю ❤️

Среди нас есть герои ⚡️

⚡️ С нуля погружаются в IT и аналитику, чтобы сменить профессию.
Это те, кому удалось понаблюдать за внедрением ИТ-решений и поработать с аналитиками, работники производства и заводов, менеджеры, архитекторы и другие специалисты, которые потеряли вдохновение от текущей работы и теперь готовы посмотреть в сторону трендовых IT-профессий

⚡️ Пришел в IT с нуля, на аналитика, учился на ходу.
И сейчас, когда хочется сменить работу - страшно. Не хватает знаний и опыта. Системные аналитики самоучки, которые смогли! Но каждая задача привносит немного стресса и переживаний в жизнь.

⚡️ Тестировщики, технические писатели и специалисты тех поддержки, кто видел как работают аналитики, часто им помогает, и чувствует в себе желание расти в этом направлении, но не знает как это сделать.

⚡️Бизнес-аналитики, кто понимает, что способен на большее, и готов разобраться с секретным языком программистов.

Есть и другие. И все вы Герои! Один раз получилось, а значит и всё остальное получится, в любом случае!


Сегодня я хочу анонсировать события:

⚡️🗓 22 июня в 19:00 Мск я проведу открытый вебинар, где покажу, как работают системные аналитики. В прямом эфире увидите подход к анализу проектов с нуля до задач на разработчиков.

⚡️🗓 С сегодняшнего дня и до 21 июня 23:59 Мск открыта предзапись на курс “Системный аналитик: с нуля до опыта работы на проекте”. Это практическая программа, которая поможет начать карьеру в системном анализе и структурировать знания действующим IT-специалистам. По анкете предзаписи действует скидка на обучение.

Почему я люблю эту программу еще больше сейчас? Я обновила ее и расширила в очередной раз. Еще больше погружения в технические детали, защита проекта на всех тарифах в конце обучения, проектный опыт в резюме и нахождение в комьюнити экспертов - действующих системных аналитиков! До 20 человек в потоке, с которыми постоянно будут взаимодействовать 5 кураторов и я.


Смелые шаги важны. И я хочу, чтобы были уверенны в них!

Не бойтесь идти вперед. Все возможно! ❤️

🌟Пример постановки задачи на фронт - мобильное приложение 🌟

Ранее я уже прислала чек-лист, что должна содержать постановка задачи на разработчика. Давайте разберем пример в рамках проектирования мобильного приложения для сообществ.

Задача
Регистрация личного кабинета пользователя (ЛК)

Общее описание (отвечаем на вопросы что это? зачем? для кого?)
Реализовать форму регистрации ЛК пользователей.
Цель регистрации - сделать пользователей приложения частью сообщества, чтобы они могли:
- Получать уведомления о новых публикациях не только в мобильном приложении.
- Оставлять комментарии к публикациям сообщества.
- Иметь возможность посещать открытые вебинары без повторяющихся регистраций по телефону и почте.
- Получать другие преимущества, доступные участникам сообщества.


Ссылка на макеты (дизайн): тут ссылка 🔗
И, кстати, дизайнеру в постановке задачи рекомендую рассказать какие состояние формы надо нарисовать: пустые поля, заполненные, вид ошибок и т.д.


Сценарий использования (Use Case)

Предусловие:
Пользователь использует мобильное приложение сообщества без ЛК.
Пользователь переходит к регистрации на вебинар или к форме входа в личный кабинет. Ему предлагается ввести данные своей учетной записи. Т.к. он еще не имеет ЛК, то ему предлагается пройти регистрацию.

Сценарий:
1. Отображается экран регистрации ЛК.
Для регистрации предлагается ввести:
+ имя,
+ адрес электронной почты,
+ номер телефона,
+ пароль для ЛК.

2. Пользователь заполняет предложенные поля ввода.

3. Пользователь подтверждает регистрацию - нажимает кнопку "Зарегистрироваться". Выполняется проверка введенных данных на стороне мобильного приложения - проверка условий валидации и ФЛК (форматно-логический контроль).
3.1. Пользователь заполнил поля ввода данными, которые не соответствуют требованиям к ФЛК или валидации. Отображается соответствующий текст ошибки.

продолжение скоро...👇

.....

4. После успешных проверок мобильное приложение вызывает метод POST /user.
4.1. В ответ на вызов метода получена ошибка - отобразить полученный текст ошибки от метода на экране приложения. Если текст ошибки не получен, отобразить общий текст ошибки "Ошибка регистрации. Проверьте введенные данные и повторите попытку".
(Важно! Про все проверки сервера, что пользователь уже зарегистрирован и т.п. надо писать в постановке задачи на сервер, но не здесь. Здесь это можно указать опционально, чтобы тестировщикам было проще писать сценарии тестирования. Можно не перегружать этим сценарий).

5. Запрос на регистрацию выполнен успешно.
От сервера получен регистрационный id пользователя.
Пользователю необходимо подтвердить регистрацию - ввести код, полученный в email-сообщении.

6. Пользователь вводит код из email.
6.1. Пользователь не ввел код и вышел из приложения или из процесса регистрации - регистрация не завершена. Личный кабинет не создан.

7. Мобильное приложение вызывает метод /user/{Id}/confirmEmail.
7.1. В ответ на вызов метода получена ошибка - отобразить полученный текст ошибки от метода на экране приложения. Если текст ошибки не получен, отобразить общий текст ошибки "Ошибка регистрации. Проверьте введенные данные и повторите попытку".
Пример: введен неверный код.

8. Пользователь успешно зарегистрирован.
+ Если пользователь регистрировался через форму входа в ЛК - отображается главный экран сообщества в состоянии для авторизованного пользователя.
+ Если пользователь перешел к регистрации в процессе выполнения каких-либо действий, связанных с необходимостью авторизоваться в ЛК, то выполняется переход к форме, с которой пользователь инициировал регистрацию.


Методы API
🔗 POST /user - метод регистрации пользователя, реализованный на стороне бэкенда приложения сообщества
🔗 POST /user/{Id}/confirmEmail - метод подтверждения учетной записи пользователя по коду из email
(Важно! В требованиях на мобильное приложение я ссылюсь на документацию API для нашего приложения.
Но я не описыаю логику работы методов сервера:
- поиск данных в БД,
- проверки почты, что пользователь ранее не был зарегистрирован,
- алгоритм генерации кода для email,
- процесс передачи кода в сервис Unisender, с которым надо сделать интеграцию для отправки email и т.д.
Это идет в требования к методам бэкенда, на бэкенд разработчиков, но не мобильных разработчиков.)


продолжение скоро...👇

Маппинг данных

Тут должны быть таблицы на 3 колонки, под каждый экран отдельно, в которой сопоставляются данные:
1. Элементы UI на экране - данные, картинки, кнопки, тексты и т.д. Актуальные названия.
2. Описание, требования к проверкам (валидация, ФЛК - форматно-логический контроль), которые должны выполняться фронтендом (эти же проверки могут дублироваться на сервере)
3. В API (API) - здесь указываем для каждого поля откуда его берем, если оно подгружается из API или передается в API запросе.

Пример (опишу текстом, который надо распределить по колонкам):

▫️Регистрация - статичный заголовок

▫️Имя - поле ввода
Описание:
Поле ввода имени пользователя. Ограничение на ввод - 128 символов. Допустим ввод букв и цифр, дефис. Запрещен ввод символов - скрыть их с экранной клавиатуры.
По нажатию на поле ввода оно должно быть зафиксировано над экранной клавиатурой.
По нажатию на экранной клавиатуре кнопки "Далее" (Done) переходить к следующему полю ввода - email.
В API:
POST /user ("name")

▫️Email - поле ввода
Описание:
Поле ввода email пользователя. Ограничение на ввод - 256 символов. Допустим ввод только латинских букв, цифр и символов, которые допустимы для email. Использовать стандартную маску для проверки email.
По нажатию на поле ввода оно должно быть зафиксировано над экранной клавиатурой.
По нажатию на экранной клавиатуре кнопки "Далее" (Done) скрывать экранную клавиатуру.
В API:
POST /user ("email")

▫️"Зарегистрировать" - кнопка
Описание:
По нажатию на кнопку:
1. Выполнить проверки полей ввода локально.
2. Вызвать метод POST /user в соответствии со сценарием.
В API:
-


и т.д.

Заключение скоро...👇

Коллеги, в заключении к этому большому примеру постановки задачи на мобильное приложение 🙂

1. Эту постановку задачи еще надо дописывать
Я остановилась, когда поняла, что Телеграм не готов принимать так много букв. И вас перегрузить сейчас не хочу.
Не хватает деталей в требованиях к валидации. А какие-то общие требования к обработке ошибок я бы вынесла в отдельную статью по общим правилам к разработке мобильного приложения.

2. В зависимости от компании
2.1 Уровень детализации требований можно сделать как глубже, так и более поверхностным.
Как показывает практика, с более поверхностным уровнем на этапе тестирования всплывает много непредсказуемых реакций.
Клавиатура закрывает поля ввода, почему-то вводим цифры в имя, в номере телефона буквы и другие непредсказуемые вещи "на усмотрение разработчика".
2.2. Есть разные шаблоны постановок задач. И у себя на обучении я даю и показываю всё, что знаю. И показываю: это можно убрать, а это можно добавить. Ориентируйтесь на правила, которые будут у вас в компании. Будьте гибкими, но и идеи не забывайте предлагать, если знаете, как улучшить вашу документацию.

3. Для аналитиков, кто уже знает что такое бэкенд и фронтенд, будет более очевидно что я имею ввиду под "вызываем метод POST". А за ним еще интеграция прячется. А вот для начинающих аналитиков это пока может быть сложно.
Когда я разрабатывала программу обучения для начинающих системных аналитиков, я старалась полностью провести вас по тому пути, который прошла я. Цепочка озарений, которые я получала на практике, боясь ошибиться. Все, чтобы сделать больше крутых специалистов вокруг - клонирую себя.

4. Практика-практика-примеры-шаблоны, постоянное изучение нового, знакомство с разными подходами и структурирование знаний. Это то, что помогает расти.

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