Прибейте меня, я веду проект с нуля. Часть 3 🍑
В прошлых частях мы разобрали, с чего начинается работа аналитика и как зафиксировать бизнес-требования. Теперь переходим к следующему этапу — АНАЛитике описанию системы.
Если BRS отвечает на вопрос "что хочет бизнес?", то SRS — это уже про "как это должно работать?".
Что такое SRS и зачем он вообще нужен?🤔
Он нужен для того, чтобы:
😕 Разработчики понимали, как должна работать система.
🐈 Аналитик мог завести user story и сформировать понятные задачи.
🙄 Бизнес видел, как его хотелка будет работать.
Что должно быть в SRS?💡
1⃣ Как должна работать система.
2⃣ Какие у неё функции, ограничения и интеграции.
3⃣ Как с ней взаимодействуют пользователи.
У вас этот документ может называться по другому, но суть всегда одна: SRS — это инструкция для разработки.
В следующей части более подробно разберём, чем SRS отличается от BRS и какие ошибки чаще всего допускают аналитики при их написании.
📽 Если этот пост соберёт 30 реакций, дропну шаблон, который сам использую в работе.
IT АНАЛитика
Если BRS отвечает на вопрос "что хочет бизнес?", то SRS — это уже про "как это должно работать?".
Что такое SRS и зачем он вообще нужен?
System Requirements Specification — это документ, который связывает бизнес-требования с технической реализацией. Он описывает, как должна работать система: какие у неё функции, ограничения, интеграции, сценарии работы пользователей.
Он нужен для того, чтобы:
Что должно быть в SRS?
У вас этот документ может называться по другому, но суть всегда одна: SRS — это инструкция для разработки.
В следующей части более подробно разберём, чем SRS отличается от BRS и какие ошибки чаще всего допускают аналитики при их написании.
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥58👍4❤3❤🔥2
SRS_IT_АНАЛитика.docx
40 KB
Как и обещал, дропаю шаблон, который поможет быстро зафиксировать требования к системе.
Пользуйтесь, дорабатывайте под себя😎
IT АНАЛитика
Пользуйтесь, дорабатывайте под себя
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥14👍7❤🔥1
Если вы работаете с API, то, скорее всего, слышали от разработчиков фразы вроде:
"Настроили новую MAPI", "Надо глянуть логи в MAPI" и т. д
Но что это вообще такое и зачем это знать аналитику?
Что такое MAPI?
MAPI (Management API) — это инструмент для управления API без изменений в коде. Он позволяет настраивать доступы, отслеживать запросы, включать новые версии API и распределять нагрузку централизованно, без доработок в каждом сервисе.
Что можно делать через MAPI?
Почему это может быть важно для аналитика?
Если ваш сервис работает с внешними API, MAPI может управлять этими подключениями. Например, отключать неактуальные сервисы или переключать трафик на другие эндпоинты без доработок в коде.
Некоторые API работают сразу в нескольких версиях (например, v1, v2).
MAPI позволяет гибко управлять переходом на новые версии – это важно, если у вас есть интеграции, которые нужно переносить с устаревших API.
Аналитик желательно понимать, какие сервисы могут обращаться к API и как настроены права доступа. Через MAPI настраивают токены, ключи API и уровни привилегий, что критично для безопасности.
Если интеграция работает нестабильно, в MAPI можно посмотреть логи запросов, метрики и статус сервисов. Это помогает быстрее понять, проблема в API или в вашей системе.
Аналитику не нужно глубоко копать в MAPI, но понимать, как оно влияет на интеграции, доступы и стабильность API — полезно.
Если в вашем проекте куча микросервисов и сложные интеграции, возможно, MAPI уже используется, просто вы об этом не знали.
А вы сталкивались с MAPI в работе? Где оно у вас применяется? Делитесь в комментариях.
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥5❤🔥2👍1
Жизнь или смерть без нормальной документации?💀
Недавно посмотрел лекцию Яндекса для продактов (скидывать не буду — для аналитиков там пользы мало и идёт еще 2ч).
Но были хорошие тейки в защиту документации, и я понял, что пост "Как выглядит хорошая документация?" можно раскрыть еще больше.
Что дает хорошая документация?👍
👆 Ускоряет тайм-ту-маркет
Разработчики сразу понимают, что и как делать, а не пишут тебе с «Блииииин, а давай созвонимся, я не поняль».
👆 Бизнес🤝разработка
Бэклог приоритизируется легче: понятно, сколько стоит фича и какую пользу приносит.
👆 Гарантирует согласованность на всех платформах
Никаких «на iOS работает так, на Android эдак, а на Web вообще по-другому».
👆 Экономит время
Избавляет от повторяющихся вопросов и 100500 переписок с разработчиками и стейкхолдерами — вся нужная информация уже собрана в одном месте.
Что будет, если документации нет или она плохая?😭
🤯 Исправление косяков после релиза
Фичи выходят с багами, потому что изначально требования были неясными. Приходится дорабатывать и выкатывать повторно.
🤯 Бесконечные переписки
Разработчики и стейкхолдеры задают одни и те же вопросы, а информацию приходится вылавливать по чатам и задачам.
🤯 Размытые цели
Аналитику приходится по сто раз объяснять одни и те же вещи разным людям.
🤯 Низкий приоритет важных задач
Бизнес не видит ценности — важная задача пылится в бэклоге, а потом её и вовсе срезают.
Когда нужно начинать писать документацию?
Сразу. Как только пришла задача, даже если это всего два-три предложения. Лучше создать страницу и зафиксировать мысли, чем потом по крупицам вспоминать, что вообще обсуждали.
Как часто нужно обновлять документацию?
Краткий ответ — всегда.
➕ Как только изменился процесс, требования или появились новые вводные.
➕ После встреч и обсуждений
➕ Когда понимаете, что команда начала задавать вопросы, на которые уже должны быть ответы.
А как у вас с этим? Всё чётко, или тоже бывает, что бизнес говорит одно, разработка делает другое, а в итоге выходит третье?🔥
IT АНАЛитика
Недавно посмотрел лекцию Яндекса для продактов (скидывать не буду — для аналитиков там пользы мало и идёт еще 2ч).
Но были хорошие тейки в защиту документации, и я понял, что пост "Как выглядит хорошая документация?" можно раскрыть еще больше.
Что дает хорошая документация?
Разработчики сразу понимают, что и как делать, а не пишут тебе с «Блииииин, а давай созвонимся, я не поняль».
Бэклог приоритизируется легче: понятно, сколько стоит фича и какую пользу приносит.
Никаких «на iOS работает так, на Android эдак, а на Web вообще по-другому».
Избавляет от повторяющихся вопросов и 100500 переписок с разработчиками и стейкхолдерами — вся нужная информация уже собрана в одном месте.
Что будет, если документации нет или она плохая?
Фичи выходят с багами, потому что изначально требования были неясными. Приходится дорабатывать и выкатывать повторно.
Разработчики и стейкхолдеры задают одни и те же вопросы, а информацию приходится вылавливать по чатам и задачам.
Аналитику приходится по сто раз объяснять одни и те же вещи разным людям.
Бизнес не видит ценности — важная задача пылится в бэклоге, а потом её и вовсе срезают.
Когда нужно начинать писать документацию?
Сразу. Как только пришла задача, даже если это всего два-три предложения. Лучше создать страницу и зафиксировать мысли, чем потом по крупицам вспоминать, что вообще обсуждали.
Как часто нужно обновлять документацию?
Краткий ответ — всегда.
А как у вас с этим? Всё чётко, или тоже бывает, что бизнес говорит одно, разработка делает другое, а в итоге выходит третье?
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14✍1
Что интересного было в феврале?
Посты
Как принять задачу от бизнеса и не страдать?
Как выглядит хорошая документация?
Прибейте меня, я веду проект с нуля. Часть 3
Шаблон, чтобы зафиксировать требования к системе
MAPI: что это и зачем знать аналитикам?
Интересные статьи
26 паттернов микросервисов
Откуда есть пошла аналитика и что отличает DS, DA, BA и SA
Мемы
Мем
Мем посмешнее
#итоги_месяца
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10👏4❤🔥1🤝1
Вполне годный шаблон для описания микросервиса и всё, что из него вытекает — интеграции, API, ограничения и прочее.
Читать📚
IT АНАЛитика
Читать📚
IT АНАЛитика
Хабр
Как создать шаблон документации к микросервису
Всем привет. Меня зовут Таня, я работаю системным аналитиком в МТС. В этой статье я расскажу о том, как писать документацию для разработки микросервисов. Моя команда развивает несколько виджетов...
🔥11
Дорогие дамы, с 8 марта!
Пусть задачи закрываются легко, а дедлайны сами подстраиваются под вас.
Вы — самая ценная система, без которой всё бы рухнуло!
А главное — пусть вас ценят не только за чёткую постановку и схемы, а просто так и каждый день.❤️
IT АНАЛитика
Пусть задачи закрываются легко, а дедлайны сами подстраиваются под вас.
Вы — самая ценная система, без которой всё бы рухнуло!
А главное — пусть вас ценят не только за чёткую постановку и схемы, а просто так и каждый день.
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
❤30🦄6💘4🔥1
Прибейте меня, я веду проект с нуля. Часть 4 🍑
Мы уже разобрались, как фиксировать бизнес-требования и оформлять спецификацию системы.
Для закрепления давайте разберёмся, в чём ключевое отличие BRS от SRS и почему их нельзя мешать в одном документе.
❗️ Частая ошибка: всё в одной куче
Иногда аналитики пишут что-то среднее между BRS и SRS, где в одном документе намешаны и бизнес-цели, и технические детали. В результате:
❌Бизнес теряется в потоке технических деталей.
❌ Разработчики не могут понять конкретные требования среди описаний бизнес-целей.
Как правильно?
✅ Сначала BRS — фиксируем, что хочет бизнес и зачем это нужно.
✅ Потом SRS — описываем, как именно это будет работать с точки зрения системы.
Чёткое разделение = меньше хаоса, меньше недопонимания, меньше лишних вопросов.
А как у вас фиксируют требования? Всё чётко разделено или по старинке — одна огромная простыня на всех? Делитесь в комментариях!👇
IT АНАЛитика
Для закрепления давайте разберёмся, в чём ключевое отличие BRS от SRS и почему их нельзя мешать в одном документе.
❗️ Частая ошибка: всё в одной куче
Иногда аналитики пишут что-то среднее между BRS и SRS, где в одном документе намешаны и бизнес-цели, и технические детали. В результате:
❌Бизнес теряется в потоке технических деталей.
❌ Разработчики не могут понять конкретные требования среди описаний бизнес-целей.
Как правильно?
Чёткое разделение = меньше хаоса, меньше недопонимания, меньше лишних вопросов.
А как у вас фиксируют требования? Всё чётко разделено или по старинке — одна огромная простыня на всех? Делитесь в комментариях!
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14🔥2✍1
И чё ты мне сделаешь? Я вообще в другой компании работаю🚬
Ранее я уже писал про ламоду, профи.ру и яндекс.
Кажется, пора выносить это в отдельную рубрику, потому что я снова кое-что принёс.
Я, конечно, слышал легенды про легаси в телекоме... но чтобы настолько?😂
Это баг? Или так задумано?
IT АНАЛитика
Ранее я уже писал про ламоду, профи.ру и яндекс.
Кажется, пора выносить это в отдельную рубрику, потому что я снова кое-что принёс.
Я, конечно, слышал легенды про легаси в телекоме... но чтобы настолько?
Это баг? Или так задумано?
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣8🫡3❤1
Какое делаем название для рубрики?
Можете в комментариях выше предложить свой вариант.
Можете в комментариях выше предложить свой вариант.
Anonymous Poll
21%
И чё ты мне сделаешь? Я вообще в другой компании работаю
29%
И тааааак сойдет
21%
Баг или фича?
16%
Руки на стол. Бэклог и так полный!
14%
Фиксим или оставляем?
Рекрутинг 2077
Если что, вот настоящий текст из письма:
Я заметила твою резюмэшку👀😜, на хэхашке💻✨💅
У нас тут один банковский проектик🏦💼: нужно ковырять апишечки🧩🛠, писать документики📝📚, проводить встречки👥📅💬.
Давай организуем созвончик📞🤝 и устроим интервьюшку🎤😎
По результату, может быть хорошая денюжка💸💰🤑
IT АНАЛитика
Если что, вот настоящий текст из письма:
У нас тут один банковский проектик🏦💼: нужно ковырять апишечки🧩🛠, писать документики📝📚, проводить встречки👥📅💬.
Давай организуем созвончик📞🤝 и устроим интервьюшку🎤😎
По результату, может быть хорошая денюжка💸💰🤑
IT АНАЛитика
😁33🤣27 10🥴5❤3
Дизайн и ошибки 🎨
Наверное, один из самых недооценённых этапов в работе аналитика — работа с макетами.
Где-то недорисовали, где-то недосогласовали — и всё это весело уехало к пользователю в прод.
А потом начинается классика:
🤡 А почему эта кнопка тут, а не там?
🤡 Не все сценарии проработали — логика развалилась
🤡 И вечное: “А мы вообще хотели по-другому…”
Ставь лайк, если жиза
Как работать с задачами, где нужен дизайн?
1⃣ Ставите задачу дизайнеру
Про этот этап я уже писал отдельно. Если есть возможность — накидайте черновик: простую схему, wireframe или даже скетч от руки. Главное — передать идею. Это сэкономит время и вам, и дизайнеру.
2⃣ Проверяете макеты по требованиям Прорабатываете все состояния, сценарии, ошибки. А главное — логику переходов. Что происходит при нажатии? Что, если ошибка? Как выглядит лоадер, модалка?
3⃣ Согласовываете с бизнесом
Один из самых важных (и часто самых сложных) этапов. Нужно убедиться, что всё, что нарисовано, отвечает целям задачи и бизнес ожиданиям. Лучше потратить пару дней на согласование, чем неделю на переделки.
4⃣ Отдаете в разработку
Про это тоже есть отдельный пост. С понятной логикой, финальными макетами и зафиксированными сценариями.
5⃣ Сами проверяете в бою (по желанию)
Зашли на стенд, потыкали кнопки, посмотрели, как это работает вживую.
Раньше я частенько сам тестил свои задачи — и это реально помогает прокачать насмотренность, замечать мелочи и лучше понимать, как макеты превращаются в интерфейсы.
Макет — это не просто "чтобы красиво".
Это полноценная часть требований, такая же важная, как и другие артефакты.
Если не проконтролировать этап макетов, это легко превращается "ГАЛЯ У НАС ОТМЕНА, БИЗНЕС СНОВА НЕ СОГЛАСОВАЛ"
А как у вас с макетами? Всё чётко или тоже бывает фристайл от фронта? Делитесь в комментах👇
IT АНАЛитика
Наверное, один из самых недооценённых этапов в работе аналитика — работа с макетами.
Где-то недорисовали, где-то недосогласовали — и всё это весело уехало к пользователю в прод.
А потом начинается классика:
Как работать с задачами, где нужен дизайн?
Про этот этап я уже писал отдельно. Если есть возможность — накидайте черновик: простую схему, wireframe или даже скетч от руки. Главное — передать идею. Это сэкономит время и вам, и дизайнеру.
Один из самых важных (и часто самых сложных) этапов. Нужно убедиться, что всё, что нарисовано, отвечает целям задачи и бизнес ожиданиям. Лучше потратить пару дней на согласование, чем неделю на переделки.
Про это тоже есть отдельный пост. С понятной логикой, финальными макетами и зафиксированными сценариями.
Зашли на стенд, потыкали кнопки, посмотрели, как это работает вживую.
Раньше я частенько сам тестил свои задачи — и это реально помогает прокачать насмотренность, замечать мелочи и лучше понимать, как макеты превращаются в интерфейсы.
Макет — это не просто "чтобы красиво".
Это полноценная часть требований, такая же важная, как и другие артефакты.
Если не проконтролировать этап макетов, это легко превращается "ГАЛЯ У НАС ОТМЕНА, БИЗНЕС СНОВА НЕ СОГЛАСОВАЛ"
А как у вас с макетами? Всё чётко или тоже бывает фристайл от фронта? Делитесь в комментах
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍3❤🔥1✍1❤1
Что интересного было в марте?
Посты
Жизнь или смерть без нормальной документации?
Прибейте меня, я веду проект с нуля. Часть 4
И чё ты мне сделаешь? Я вообще в другой компании работаю
Интересные статьи
Шаблон для описания микросервиса
Мемы
Смешной мем про документацию
Рекрутёр с приколом
Депрессивный рабочий стол
Идеальный вариант проведения дэйлика
Снова неугомонные рекрутёры
#итоги_месяца
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤝2
Первая задача — это ты, а вторая — все твои мечты 🐈⬛
Раньше я уже делал серию постов про постановку задач разным специалистам. Но важно понимать, что сами задачи не живут в вакууме и являются лишь "низушкой" айсберга. Давайте по порядку:
🐒 Маленькая задачбка
То, что уходит в разработку:
— с конкретикой,
— с понятной формулировкой,
— и с нужным контекстом под каждого участника команды.
Если хочется примеров — вот весь цикл:
📦 User Story — задачбка побольше
User story — это часть функционала, которая решает конкретную задачу пользователя.
И внутри неё почти всегда:
— фронт,
— бэк,
— дизайн,
— тестирование,
— аналитика.
🤣 Классическая форма:
👀 Пример:
User story может завести как аналитик, так и product owner — зависит от процессов.
Главное — чтобы она была и была понятной.
🧊 Эпик — вообще большая задача жестб
С эпика всё начинается. Это хотелка бизнеса или идея на уровне «хотим новый процесс / продукт / модуль».
В нём ещё нет конкретных сценариев — есть только цель и боль.
Тут АНАЛитик и вступает в игру.
🧠 Как это выглядит в жизни?
1) Бизнес заводит эпик.
2) Аналитик берёт его в работу.
3) Погружается, собирает требования, оформляет BRS и SRS.
4) Делит на user story — понятно, по смыслу.
5) По каждой user story формирует задачи — уже для команды.
👉 В следующий раз расскажу про один удобный инструмент, который помогает выделить user story и не утонуть в хаосе.
С него удобно начинать декомпозицию и переходить к задачам.
Пишите, как у вас организована работа с эпиками и user story. Работает?😅
IT АНАЛитика
Раньше я уже делал серию постов про постановку задач разным специалистам. Но важно понимать, что сами задачи не живут в вакууме и являются лишь "низушкой" айсберга. Давайте по порядку:
То, что уходит в разработку:
— с конкретикой,
— с понятной формулировкой,
— и с нужным контекстом под каждого участника команды.
Если хочется примеров — вот весь цикл:
Хорошо поставленная задача есть? А если найду? : Часть 1 - Почему важно
Хорошо поставленная задача есть? А если найду? : Часть 2 - Общий шаблон задач
Хорошо поставленная задача есть? А если найду? : Часть 3 - Frontend
Хорошо поставленная задача есть? А если найду? : Часть 4 - Backend
Хорошо поставленная задача есть? А если найду? : Часть 5 - Тестировщик
Хорошо поставленная задача есть? А если найду? : Часть 6 - Дизайнер
Хорошо поставленная задача есть? А если найду? : Часть 7 - Архитектор
Хорошо поставленная задача есть? А если найду? : Часть 8 — DevOps Хорошо поставленная задача есть? А если найду? : Часть 9 — Аналитик
User story — это часть функционала, которая решает конкретную задачу пользователя.
И внутри неё почти всегда:
— фронт,
— бэк,
— дизайн,
— тестирование,
— аналитика.
Я, как КТО, хочу ЧТО, чтобы ЗАЧЕМ.
👀 Пример:
Я, как клиент, хочу видеть последние 5 операций на главной,
чтобы быстро проверить движение по счёту.
User story может завести как аналитик, так и product owner — зависит от процессов.
Главное — чтобы она была и была понятной.
🧊 Эпик — вообще большая задача жестб
С эпика всё начинается. Это хотелка бизнеса или идея на уровне «хотим новый процесс / продукт / модуль».
В нём ещё нет конкретных сценариев — есть только цель и
Тут АНАЛитик и вступает в игру.
1) Бизнес заводит эпик.
2) Аналитик берёт его в работу.
3) Погружается, собирает требования, оформляет BRS и SRS.
4) Делит на user story — понятно, по смыслу.
5) По каждой user story формирует задачи — уже для команды.
С него удобно начинать декомпозицию и переходить к задачам.
Пишите, как у вас организована работа с эпиками и user story. Работает?
IT АНАЛитика
Please open Telegram to view this post
VIEW IN TELEGRAM
Про первое интервью с рекрутером: как проходят собеседования в UK/US, что на самом деле смотрят на этапе “поговорим по зуму” и почему одного “я кайфовый😎” — мало.
👉Читать статью
IT АНАЛитика
👉Читать статью
IT АНАЛитика
Telegraph
«Хвалите компанию. Много. Наизусть»: как выдержать первую встречу с рекрутером
Рекрутер — начальный рубеж на пути специалиста в поиске работы. Именно первое собеседование с рекрутером определит, пригласят ли вас на офлайн интервью, и допустят ли до встречи с хайринг менеджером. Может показаться, что программа-минимум для достижения…
👍5❤1✍1