❗️Начинаем через 15 минут❗️

Подключайтесь по ссылке

❗️Сегодня проведем последний повтор❗️

📹 Команда разработки в США и место аналитика в ней
⏰ 6 января, 13:00 - 15:00 Мск
🔗 Регистрация по этой ссылке

❗️Начинаем через 15 минут❗️

Подключайтесь по ссылке

Завершили повторы вебинара про команду разработки в США и место аналитика в ней 🇺🇸

Публикую самый важный слайд из нее - работа с резюме. На эти пункты смотрят в первую очередь!

Через пару недель проведу для вас бесплатный воркшоп, на котором создадим ваши резюме 😏

До встречи!

Примеры User Stories для системы доставки пиццы:

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

▫️Я, как покупатель, хочу отслеживать процесс доставки пиццы, чтобы можно было заказать ее заранее, пока я буду ехать с работы домой, и понимать где находится курьер.


А теперь со стороны владельца пиццерии:

▫️Я, как владелец пиццерии, хочу предоставить пользователям возможность заказа доставки пиццы, чтобы увеличить продажи в ресторане (похожа на первую для покупателя, но здесь фокус на отчетах для владельца ресторана)

▫️Я, как владелец пиццерии, хочу платить зарплату сотрудникам за количество выполненных каждым из них заказов.

Разные роли - фокус на разные приложения и функциональность.


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

Учитесь сочинять разнообразные User Stories. Чем больше - тем лучше. Среди множества пользовательских историй всегда можно выбрать самые важные для пользователей.А лишнее отбросить.

ООП (объектно-ориентированное программирование) – это возможность рассмотреть программу как набор взаимодействующих друг с другом объектов. Главное — научиться выделять свойства этих объектов и методы их обработки.

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

Тема очень интересна. Для самостоятельного погружения рекомендую 2 книги:

1️⃣ Гради Буч «Объектно-ориентированный анализ и проектирование с примерами приложений»
2️⃣ Мэтт Вайсфельд «Объектно-ориентированное мышление».

Добавляйте пост в избранное, чтобы не потерять информацию.

Базовые принципы ООП:

1️⃣ Наследование
2️⃣ Полиморфизм
3️⃣ Инкапсуляция

Три слова, которые от разработчиков в диалогах вы услышите редко, но именно этими терминами они руководствуются, организуя код.

Я неосознанно исользую эти три принципа ООП для решения задач системного анализа:
✔️ Проектирование алгоритмов, в которых переиспользуют уже реализованные методы в системе
✔️ Проектирование дизайна RESR API методов сервера - постановка задач на Backend-разработчиков
✔️ Создание структуры документации

Картинка для привлечения внимания 😉 С ходу непонятная. Но за несколько постов раскрою вам суть

📌 Инкапсуляция - это что-то про private, protected и public

Вот по такому ассоциативному ряду я каждый раз вспоминаю о чем это вообще.

"Прятать в капсулу" - тоже прекрасно помогает.

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

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

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

Реализуется за счет установки модификаторов доступа public и private для свойств класса и его методов.

+ Public — доступ открыт всем другим классам, кто видит определение данного класса.
+ Protected — доступ открыт классам, созданным на основе данного - производные. Производные классы получают свободный доступ к таким свойствам или методам. Другие классы такого доступа не имеют.
+ Private — доступ открыт самому классу (т.е. функциям-членам данного класса) и друзьям (friend) данного класса - как функциям, так и классам. Производные классы не получают доступа к этим данным совсем. Другие классы такого доступа не имеют.

Наследование - это когда есть родитель с базовыми свойствами и дети с уникальными 👨‍👩‍👧‍👦

Процесс, при помощи которого один объект может приобретать свойства другого.

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

Представим, что в кондитерской много лет готовили один и тот же торт "Наполеон". Спустя время повара понимают - нужно усовершенствовать десерт и что-то поменять. За основу берут старый рецепт и также добавляют какие-то новые ингредиенты. Получается все-тот же Наполеон, но, например:
+ с глазурью и ягодами внутри
+ шоколадный - с ягодами и какао

Базовый Наполнеон - класс-родитель, ягодный и шоколадый - производные классы, потомки👌

Наследование на примере с животными 😼

Есть базовый класс - животные

У Животного есть свойства:
Название
Цвет
Порода
Наличие шерсти

И методы:
Говорить
Кушать

От базового класса животные можно выделить подклассы:
1. Котик с методом носить шляпу и бабочку
2. Собачка с методом кушать еду и переваривать в сладости
3. Паук 😹 с методом пугать

Совсем детский пример. Но суть наследования такова. Забрать базовые свойства и методы от родителя и дополнительно реализовывать свои.

Как аналитик я использую знания о наследовании ООП при:
✔️ организации структуры документации - переиспользование статей, ссылочность
✔️ переиспользование общих алгоритмов
✔️ дизайн объектов API (например, json)

Полиформизм - это способность объектов с одним интерфейсом иметь разную реализацию

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

За счёт того, что полиморфизм разрешат использовать один интерфейс для задания единого класса действий, в разы снижается сложность программ.

На картинке мы видим разных животных. У них есть общий метод - говорить. Задача - одна. Но реализация разная. Поэтому мы можем:
1. Создать метод Speak() - одинаковый для всех животных
2. Реализовать его по-разному, в зависимости от того, какой подкласс животных его вызывает. Собачка гавкает, котик мяукает и т.д.

Как разговаривать с разработчиками на одном языке? Можно поставить себя на место разработчика и написать немного кода, чтобы понять о чем они там на своем "птичьем" поют 🙂

Бесплатный вебинар уже завтра!
🚀 Основы ООП для аналитиков - пишем код в прямом эфире
🗓 11 января (ср), 19:00 (Мск)
🔗Регистрация здесь

В программе:
✔️ напишем вместе небольшую программу
✔️ чтобы понять классы и объекты
✔️ разобраться с наследованием, полиморфизмом и инкапсуляцией
✔️ и применять знания ООП при разработке требований.

Подключаться с компьютера - будем программировать!
До встречи в прямом эфире! 😉

Уже через 3 часа! Прямой эфир с Екатериной Ананьевой!

📹 Основы ООП для системных аналитиков
⏰ 19:00 - 21:00 Мск

Ссылку на трансляцию пришлем в канал за 15 минут до начала.

Команда разработки отвечает за качество создаваемого ими программного обеспечения. Хочу поделиться с вами обобщенными критериями определения этого самого качества.

Метрики для определения успешности проекта - качество ПО

✔️ Функциональность
Соответствие функциональных возможностей ПО набору требуемой пользователем функциональности.
Сделали все, что хотел бизнес и пользователи - все довольны 🙂 Система соответствует ТЗ.

✔️ Надёжность
Способность ПО сохранять уровень качества функционирования в течение определенного периода времени.
Чем дольше прод не падал и баги с него не прилетали - тем надежнее ПО.
Ежедневные митинги с одной из команд: "У нас 100 дней без падения прода", "У нас 101 день без падения прода", "Мы обнулились".

✔️ Эффективность
Оптимизация объемов используемых ресурсов.
Чем меньше платим за аренду серверов, тем лучше.
Если на графиках пиковая загрузка ниже 60%, то вероятно мы даже отказоустойчивы 😅

✔️Сопровождаемость
Удобство проведения конкретных изменений (модификаций) кода.
Код читаем, сопровождается комментариями. В проекте есть документация в достаточном объеме, и при очередных доработках нет вопросов: "А почему здесь так сделали?", "А это что, и как оно должно работать?"

✔️Практичность
Легкость эксплуатации ПО.
Низкое количество обращений в тех. поддержку по вопросам работы ПО.
Низкое количество багов и запросов на модификации от пользователей.
За практичность во многом отвечают аналитик и дизайнер UI/UX приложения.


🔥, если теперь знаешь, как оценить качество своего проекта!

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

И вот с какими ошиками я сталкивалась, когда только начинала работать аналитиком.

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

Длинные письма по результатам переговоров или их отсуствие
Если мы с заказчиком внесли уточнения в требования в процессе разработки, когда уже ТЗ и договор были подписаны, то правки нужно было фиксировать не только в задачах Jira. Нужно было еще и отправлять письма.
Слишком длинные письма - не читают, и потом на приемке их приходится искать и зачитывать их вслух. Отсутствие письма по уточнениям на приемке как-то обернулось "мы этого не обсуждали, почему не как по ТЗ?".

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


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

Коллеги, всем привет!

За 2022 GetAnalyst вырос в 5 раз и с этого года мы будем запускать обучение в США и Европе, плюс новые программы. В связи с этим ищу себе помощника.

🔎 GetAnalyst в поисках системного аналитика (part-time, 4-8 часов в неделю)

▫️Опыт от 3-х лет
▫️Middle/Senior/Руководители/Ведущие
▫️Не менее 2-х проектов в копилке
▫️Умение работать с требованиями: сбор, анализ, написание документации, постановка задач, User Stories, Use Cases
▫️Уверенное владение 1 и более навыками системного, о которых можете рассказать
▫️Грамотная речь (письмо и разговор)
▫️Ответственность
▫️Знание английского очень приветствуется

Что будете делать:
▫️Помощь в проведении занятий, воркшопов
▫️Поддержка учеников школы в чатах
▫️Помощь с проверкой ДЗ

Преимущества:
▫️Бесплатное обучение
▫️Личная работа с основателем проекта - Екатериной Ананьевой
▫️Помощь в подготовке к публичым выступлениям и конференциям
▫️Возможно участие в консалтинговой деятельности на зарубежных проектах

Заполняйте анкету. Я и моя команда обязательно дадим вам обратную связь ♥️

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

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

Бесплатный практический вебинар для системных и бизнес-аналитиков с применением навыков на практике:

🚀 5 лайфхаков для создания цепляющего резюме
🗓 18 января, 19:00 (Мск)
🔗 Регистрация здесь

Готовимся активно участвовать!