Вводим новую рубрику 🎉
Взгляд системного аналитика и разработчика
Рады представить вам новую рубрику! В ней мы будем писать о процессах, рабочих кейсах, о болях и прочих холиварных темах.
Мы хотим сделать эту рубрику максимально полезной и интересной для вас. Поэтому призываем вас активно участвовать:
* Пишите свои вопросы.
* Делитесь темами, которые вам интересны.
* Рассказывайте о своих кейсах и наблюдениях.
Взгляд системного аналитика и разработчика
Рады представить вам новую рубрику! В ней мы будем писать о процессах, рабочих кейсах, о болях и прочих холиварных темах.
Мы хотим сделать эту рубрику максимально полезной и интересной для вас. Поэтому призываем вас активно участвовать:
* Пишите свои вопросы.
* Делитесь темами, которые вам интересны.
* Рассказывайте о своих кейсах и наблюдениях.
👍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
Чем больше всего нравится заниматься на работе? 🔍 У каждого системного аналитика есть свои любимые задачи. Что вам приносит наибольшее удовольствие в работе?
Anonymous Poll
26%
1️⃣ Проектировать API
5%
2️⃣ Разбираться с брокерами
21%
3️⃣ Описывать задачи для фронтенда, продумывая UI
22%
4️⃣ Рисовать макеты и продумывать пользовательский интерфейс
25%
5️⃣ Работать с базами данных
37%
6️⃣ Рисовать диаграммы
18%
7️⃣ Вести документацию
32%
8️⃣ Моделировать бизнес-процессы
23%
9️⃣ Общаться с заказчиками и собирать требования
37%
1️⃣ 0️⃣ Продумывать бизнес-логику
🤩6🥰4🙏3💯1
Добавляете новое обязательное поле в БД? Не забудьте продумать миграцию!
Представьте, что нужно добавить новое обязательное поле в БД — customer_type. Его возможные значения: BASIC и PREMIUM.
Что делать с записями, которые уже есть в базе данных? Поле должно быть заполнено, так как оно обязательное.
❗Необходимо продумать миграцию данных: как будем добавлять новое поле и что делать с уже существующими записями? Проставим им значение по умолчанию — BASIC.
Пример миграции:
Что делать?
1️⃣ Оповестите бизнес-команду о добавлении нового обязательного поля и о том, что все текущие записи в БД будут автоматически обновлены со значением BASIC.
2️⃣ Протестируйте миграцию на тесте.
3️⃣ После успешного тестирования добавьте поле в продовую базу и проведите миграцию для существующих записей.
#db
Представьте, что нужно добавить новое обязательное поле в БД — customer_type. Его возможные значения: BASIC и PREMIUM.
Что делать с записями, которые уже есть в базе данных? Поле должно быть заполнено, так как оно обязательное.
❗Необходимо продумать миграцию данных: как будем добавлять новое поле и что делать с уже существующими записями? Проставим им значение по умолчанию — BASIC.
Пример миграции:
ALTER TABLE customersADD COLUMN customer_type ENUM('BASIC', 'PREMIUM') NOT NULL DEFAULT 'BASIC';UPDATE customersSET customer_type = 'BASIC'WHERE customer_type IS NULL;Что делать?
1️⃣ Оповестите бизнес-команду о добавлении нового обязательного поля и о том, что все текущие записи в БД будут автоматически обновлены со значением BASIC.
2️⃣ Протестируйте миграцию на тесте.
3️⃣ После успешного тестирования добавьте поле в продовую базу и проведите миграцию для существующих записей.
#db
👍8🔥2👏2💯1