​​Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA:

#вопросыссобеседования | @ba_and_sa

Часть 18:

📍Вопрос 1: Что такое Code First и для чего и где его используют?

✅Краткий ответ:
Code First - это подход к разработке программного обеспечения, который заключается в создании кода приложения сначала, а затем автоматической генерации базы данных и моделей на основе этого кода.

Этот подход обычно используется в случаях, когда разработчики хотят быстро создать прототип или MVP приложения. Однако, недостатком Code First является то, что API может не соответствовать требованиям клиентов или стандартам безопасности.

Для чего нужен подход Code First? Он позволяет разработчикам сосредоточиться на создании бизнес-логики и функциональности приложения, не тратя время на создание и поддержание схемы базы данных. Кроме того, Code First позволяет более гибко изменять структуру базы данных, так как изменения в коде сразу отражаются в базе данных.

➕Преимущества подхода Code First:
1. Быстрая разработка - разработчики могут быстро создавать и изменять модели данных, без необходимости написания SQL запросов или изменения схемы базы данных.
2. Гибкость - изменения в структуре базы данных можно легко вносить, не нарушая целостность данных.
3. Простота в поддержке - разработчики могут легко создавать и обновлять миграции базы данных для обновления схемы.

➖Недостатки подхода Code First:
1. Недостаточный контроль - генерация базы данных автоматически может привести к недостаточному контролю над структурой и индексами.
2. Не всегда оптимальная производительность - автоматически сгенерированные запросы могут быть не всегда оптимальными по производительности.
3. Сложность масштабирования - при большом количестве данных и сложной структуре базы данных, могут возникнуть проблемы с масштабируемостью.

📎Материалы по теме:
- Разработка REST API — что такое Code First подход?

📍Вопрос 2: Что такое Contract First и где его используют?

✅ Краткий ответ:
Contract First - это подход к разработке программного обеспечения, который заключается в определении и создании спецификации интерфейса API (например, формата передачи данных, структуры сообщений) до начала разработки кода приложения. Этот подход обычно используется для обеспечения соответствия API стандартам, требованиям клиентов и улучшения коммуникации между разработчиками и заказчиками.

Для чего нужен подход Contract First? Он помогает более предсказуемо определить структуру API и обеспечить согласованность между разработчиками и клиентами. Кроме того, Contract First упрощает тестирование API, так как спецификация уже определена заранее.

➕Преимущества подхода Contract First:
1. Повышение качества - задание структуры API заранее помогает избежать недочетов и ошибок в разработке.
2. Совместимость - спецификация API может быть использована для генерации кода на разных языках программирования.
3. Улучшенная коммуникация - заказчики и разработчики имеют общее обозначение структуры и функциональности API.

➖Недостатки подхода Contract First:
1. Дополнительные трудозатраты - создание спецификации API может потребовать дополнительного времени и ресурсов.
2. Ограничения гибкости - изменения в API могут потребовать корректировки спецификации, что может занять дополнительное время.

📎Материалы по теме:
- Разработка REST API — что такое Contract First?

📍Вопрос 3: В чем разница между Code First и Contract First?

✅ Краткий ответ:
Разница между Code First и Contract First заключается во времени начала создания API. Code First начинается с написания кода приложения, а затем автоматической генерации API на его основе, в то время как Contract First начинается с создания интерфейса API и определения спецификации, затем код приложения создается на основе этой спецификации.

В след раз поговорим о других подходах 😉

Источник: @ba_and_sa

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования

​​Алоха! Сегодня хочу описать еще один #случайизжизни, с которым я столкнулась на работе в сфере нефтепереработки

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

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

Тут и повалились на меня проблемы и недопонимаю со всех сторон 🤯

Я пришла такая деловая мелкая особа к мужикам на завод, со своими непонятными бумаженциями и схемами, где был описан идеальный процесс их работы в глазах их начальства 🤷‍♀️ Но! В тот же день, я получила очень много вопросов по работе ПО, очень много новых требований и удивленных глаз заводчан! Ведь шишки хотят идеальную картину мира, а на самом деле это все работает не совсем так! И у меня стояла задача разобраться, как донести истину до больших шишек, получить требования с заводчан, которые бы легли на процесс, и найти идеальную картину для всех! Это была задача не из легких, с меня сошло 7 потов, чтобы хоть с чего-то начать! Для начала, мне надо было пояснить заводчанам кто такой БА, с чем я пришла и как устроена разработка🤯

Еще в копилку то, что большие шишки были в СПб, а завод в Омске, и я к тому времени была на заводе в Омске на 2-3 дня! Т.е, у меня стояла задача в маленький срок собрать все требования с заводчан и понять суть их работы, чтобы автоматизировать ее часть и чтобы это все легло на процесс, который был согласован со стороны главных стейкхолдеров🤯

Если вдаваться в небольшие подробности, то в офисе у меня было порядка 3-4 главных стейкхолдеров, на заводе их было 5, это руководители по производству разных отделов, я была одна и со мной еще мой администратор проекта, которая помогала вести список требований и назначала встречи. Сроки для разработки MVP стоял 4 мес и это вместе с разработкой, т.е. в идеале, я должна была собрать все требования и описать процессы, наложить это все на бумагу (описать ТЗ) и передать на разработку, но как я говорила ранее, разработка начала делать все сама, не дожидаясь моих писулек и процессов🤷‍♀️ там тоже были свои конфликты.

Также забыла упомянуть, что главный заказчик был ближе к ИТ-разработке, чем заводчане, и иногда, что что хотел завод просто могло не ложиться в разработку


Что же было дальше❓

В прошлый раз было очень много интересных кейсов развязки конфликта, давайте в этот раз тоже попробуем придумать развязку и подсказать, что можно было мне сделать в данной ситуации, когда внутри заказчиков есть недопонимания того, что они хотят на выходе!! Делитесь в комментариях👇

Про возникновении вопросов, готова ответить в комментариях!

А я попозже поделюсь своей историей развязки, что я делала, кого привлекала, что вышло и не вышло!!

#случайизжизни | @ba_and_sa

Алоха! Сегодня я поделюсь с вами продолжением истории про ситуацию между заказчиками, когда они не смогли найти общее решение. И спасибо за ваши комментарии!! В след раз рассмотрим другие ситуации в таком же формате))
____________

Прежде чем, поделиться с вами моей ситуации, я бы хотела подвести небольшие итоги по вашим предложениям:

1️⃣Привлечение сторонних отделов, в чьей зоне ответственности это находится, в моем случае - центр компетенции. - «да, к такому решению можно прислушаться и прийти и свалить всю зону ответственности на них, если таковы имеются на проекте, но! В основном таковых нет»

2️⃣Переговоры со стейкхолдерами - «это само собой будет в цепочке развязки таких проблем, но просто переговоры не всегда все решают, ну или затянутся на долгий срок»

____

«Ну а что же было дальше у меня?»

Как мы помним, у меня стояла задача разобраться между заказчиками и найти верное единственное решение в разработке конкретного ПО. После сбора требований и описания процессов, я все накидала на бумажку и отправилась в командировку на завод! В командировке участвовала - я, как БА, был еще Владелец продукта, Тим лид раработки, администратор проекта и еще один руководитель с офиса (тоже стейкхоледр)

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

Вторым шагом было обсуждение отдельных мелких процессов с каждым руководителем отделов на заводе, где я собрала и с них требования по процессу! С каждым по отдельности

Третьим шагом было, напроситься на некий экскурс по заводу, чтобы я своими глазами увидела работу заводчан, и уже мне самой было немного понятнее, что можно автоматизировать, это был самый правильный шаг в моем пути развязки😉 тут я уже и на свои вопросы ответы нашла, которые появлялись во время разработки процесса и процесс стал прозрачным и более понятным) Если возникали вопросы, я сразу их задавала и мне в реальном времени на них отвечали или показывали, как это работает. Короч, живое общение - это тема!!!

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

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

После командировки, я отметила все собранные требования в документ, так же изучила всю полученную документацию, перерисовала процесс и отметила несовпадения, после чего подготовила опять презентацию для стейкхолдеров в офисе - это те, которые «большие шишки».
Дальше у нас прошло еще пару совещаний с обсуждением процесса новой ПО, я раз 100 перерисовывала что-то в процессе, и бегала по заказчикам с вопросами.

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

В итоге мы выпустили MVP🥳

#случайизжизни | @ba_and_sa