Профиль инвестора System_Analyst | Тинькофф Инвестиции Пульс

Войти

📊 "Какими компетенциями должен обладать системный аналитик?" Продолжаю тему навыков и хочу поговорить о компетенциях системного аналитика. Что такое компетенция❔ Компетенция - это способность сотрудника успешно и регулярно решать определённый класс задач. Чтобы определить и оценить компетенции, используют матрицу компетенций - таблицу, где указаны навыки специалиста и уровень владения ими для конкретной должности. Зачем нужна матрица компетенций❔ Она помогает: ▫️оценить себя как специалиста на рынке; ▫️выявить сильные и слабые стороны; ▫️понять, какие навыки стоит прокачать, чтобы оставаться конкурентоспособным. Из чего состоит матрица❔ Матрица компетенций обычно включает: 1️⃣ Навыки (что должен уметь специалист) 2️⃣ Ожидаемый уровень владения для должности 3️⃣ Фактический уровень владения 📈 Уровень владения навыком часто оценивают по шкале: 0 - не знаком 1 - базовое представление 2 - уверенное владение 3 - опыт применения в проектах 4 - эксперт 5 - профессионал, обучающий других 💻 Базовые компетенции системного аналитика Hard skills • Интервьюирование заказчика • Изучение нормативно-правовых актов и других документов • Разработка технического задания (ТЗ) • Разработка спецификаций требований • Моделирование данных • SQL • Прототипирование интерфейсов • UML • BPMN • Интеграция REST - сторонних сервисов • Интеграция REST - собственных сервисов Soft skills • Работа в режиме многозадачности • Работа в команде • Умение слушать • Самостоятельность • Оценка 📎 Пример базовой матрицы компетенций системного аналитика - в таблице ниже. 💬 А как у вас с этими компетенциями? Какие развиты сильнее, а какие требуют прокачки? По себе могу сказать: у меня пробел в интеграциях - поставил бы 0, потому что никогда их не делал. А вот по прототипированию интерфейсов - 1, только потому что не работал в Figma (делал макеты в Excel и даже Paint 😅). Остальные оценил бы на минимальный уровень по таблице и выше.

📚 База про навыки Короткий пост перед темой, которую хочу раскрыть на этой неделе - компетенции системного аналитика. Но прежде давайте поговорим про навыки. Что такое навык? Навык (skill, "скилл") - это действие, которое человек выполняет легко или на автомате. Навык формируется только через практику. Можно знать теорию, но не уметь применить её в реальной ситуации - особенно если она нестандартная. При этом навык может существовать и без знания теории (например, кто-то отлично строит визуальные схемы, не зная правил BPMN). Виды навыков Навыки условно делятся на hard skills и soft skills. 💻 Hard skills ("жёсткие") - это профессиональные умения, которые можно измерить, оценить и проверить. Примеры: знание SQL, BPMN, Excel, умение готовить понятные презентации и документацию. 🧠 Soft skills ("мягкие") - это личные и социально-психологические умения, которые сложнее измерить. Они направлены на себя и взаимодействие с другими людьми: планирование времени, аналитическое мышление, работа в команде, умение обучать других. Зачем нужны навыки? 🎯 Hard skills помогают быть конкурентоспособным на рынке. Мир меняется → профессии эволюционируют → важно развивать новые профессиональные навыки. Это база любого специалиста. 🤝 Soft skills делают нас успешными внутри компании. Они помогают выстраивать отношения в команде, расти в должности и повышать эффективность совместной работы. 💬 Что думаете, какие навыки сегодня наиболее важны для специалиста?

📊 "Сколько аналитиков должно быть в компании по отношению к разработчикам?" Хочу обсудить одну из наболевших тем - оптимальное количество аналитиков и разработчиков в компании. Есть ли на это готовая формула? 🤔 Искал информацию в интернете - прямых "признанных" стандартов нет. Почему? Потому что слишком много факторов влияет: тип проекта, зрелость команды, методология, доменная сложность, глубина требований и пр. Что удалось найти: ▫️ в статье ArgonDigital: в Agile командах часто встречается соотношение 3-4 разработчика на 1 аналитика; ▫️ в классическом Waterfall аналитики могут быть менее загружены во время фазы разработки → тогда отношение выше, например 8:1; ▫️ на форумах часто пишут про диапазон 1 аналитик на 2-5 разработчиков; ▫️ многие отмечают, что жёсткие соотношения опасны → важно учитывать контекст и нагрузку. 📌 Если обобщить: часто за основу берут 1 аналитик на 3-6 разработчиков. Как на самом деле у меня в компании? Картина противоположная: ▪️ 74 аналитика и 13 разработчиков → почти 6 аналитиков на 1 разработчика; ▪️ если убрать аналитиков поддержки, отчётности и планирования → остаётся 48 аналитиков и 13 разработчиков → около 4 аналитика на 1 разработчика. Я попросил ChatGPT оценить такое соотношение, он сказал, что это может значить: 1️⃣ Широкое понимание роли аналитика. Аналитики берут на себя не только системный/бизнес-анализ, но и: сопровождение, планирование, отчётность, поддержку пользователей. 2️⃣ Фокус на документации и согласованиях. Разработчиков мало → чтобы их работа шла эффективно, огромная армия аналитиков готовит и сопровождает требования - соглашусь отчасти, правда, не всегда это отражается на качестве в лучшую сторону. 3️⃣ Минусы: 🔹️ риск "бюрократизации" (слишком много согласований, длинный цикл от идеи до кода) - 💯 одна из главных проблем на мой взгляд; 🔹️ аналитики могут конкурировать за задачи, часть ресурсов простаивает - явных ситуаций лично я не припомню, но дублирование задач среди разных подразделений часто встречается, и не всегда это выясняется вовремя. 🔹️ нагрузка на разработчиков остаётся высокой, потому что реальных "рук" мало - так и есть. 4️⃣ Плюсы: 🔹️ разработчики, вероятно, получают максимально проработанные требования - ох не всегда, зависит от конкретных аналитиков, кто делал задачу; 🔹️ меньше шансов, что "упадёт" качество из-за недопониманий - у нас это не работает, количество как раз повлияло на качество в обратную сторону. 🔹️ хорошая база для масштабирования (если нанять ещё разработчиков) - тогда наймут ещё аналитиков, потому что даже сейчас набор продолжается 😂 А теперь интересно обсудить с вами 👇 👉 Какое соотношение аналитиков и разработчиков в вашей компании? 👉 Считаете ли вы «1:3–6» универсальной нормой или мифом?

📝 "Use Case diagram: нужна ли она в ТЗ?" Недавно рисовал Use Case диаграмму для одного ТЗ - всего второй раз за мою рабочую практику. Первый раз - когда делал ТЗ с помощью ИИ: он её сгенерировал, я просто вставил. А впервые познакомился с этим инструментом ещё в 2023 году на курсе, тогда и рисовал на практике. Потом как-то забыл и не применял. У нас в компании привычки использовать Use Case диаграммы нет. Обычно хватает описания бизнес-процессов в BPMN 2.0. Но тут на днях обсуждали ТЗ с новым для меня заказчиком. В привычном формате документ оказался для них слишком "техническим" - пришлось много пояснять словами и показывать куски интерфейсов. Мы с коллегами давно привыкли описывать всё максимально подробно для разработчиков, чтобы не было недопониманий. Но заказчик-то "не разработчик", ему важна картинка процесса сверху. В итоге ТЗ приняли, но после обсуждения я решил доработать его: добавил немного текста во вводную часть и самое главное - нарисовал Use Case diagram в UML, чтобы показать функционал для пользователя в одном месте. И знаете, она реально закрывает почти все вопросы заказчика: сразу стало видно, "что может делать пользователь". И рисуется-то элементарно! Вывод, который я сделал: Use Case diagram - это не просто "формальность". Это мост между техническим заданием и бизнес-заказчиком. Она закрывает базовые вопросы пользователя и при этом рисуется за 15 минут. Теперь я задаюсь вопросом: а почему раньше я её не использовал в своих ТЗ? 🤔 Ниже прикладываю свою диаграмму - посмотрите, что получилось. Можно ещё как-то доработать? P. S. Я нарисовал здесь include прямой стрелкой, так как рисовал диаграмму до того, как подготовил предыдущий пост по теории и освежил знания, на самом деле стрелка include должна быть пунктирной. Поделитесь опытом: - Используете ли вы Use Case diagram в своих ТЗ? - Или обходитесь BPMN и текстовым описанием?

📌 "Как и для чего рисовать Use Case Diagram?" Одно и то же требование можно рассмотреть по-разному: • через разные модели, • в разных нотациях. Каждая нотация хороша для "своей" задачи. В UML есть десятки диаграмм, и одна из самых популярных - Use Case Diagram (диаграмма вариантов использования системы или по-другому называют диаграммой прецедентов). 👉 Она отвечает на вопрос: "Как пользователь может воздействовать на систему?" Акторы и варианты использования Актор - действующее лицо (человек или приложение), которое взаимодействует с системой. Use case (вариант использования) - действие, которое актор выполняет в системе. 💡 Чтобы выделить акторов, можно задать себе вопросы: 🔹️ Кто получает уведомления, если в системе что-то произошло? 🔹️ Кто предоставляет системе данные или сервисы? 🔹️ Кто помогает системе выполнить задачу? Когда полезна Use Case Diagram ✔️ Подходит для систем с разными сценариями использования. ❌️ Не очень подходит для приложений "хранения данных" или генерации отчётов (там вариантов немного). Плюс: диаграмма помогает системным аналитикам точнее формулировать функциональные требования и не упустить важное. Ключевые элементы Use Case Diagram 👤 Актор - схематичный "человечек". 🔄 Use case - овал с текстом (глагол в инфинитиве + существительное: "посмотреть события"). 🔳 Границы системы - прямоугольник, отделяющий "внутри системы" от "снаружи". 🔗 Связи: ● Ассоциация (простая линия) - актор ↔ use case. ● Обобщение (стрелка с пустым наконечником) - "от общего к частному". ● Include (пунктирная стрелка с подписью) - один use case включает другой. ● Extend (пунктирная стрелка с подписью) - один use case может опционально расширять другой. 📎 Пример из практики я покажу в следующем посте. А вы как относитесь к Use Case Diagram? Часто используете или обходите стороной?

📌 "Моделирование требований: что это и зачем?" Когда системный аналитик собирает требования, важно привести их в понятный и рабочий вид. Требования должны быть такими, чтобы: ▪️по ним можно было создать и протестировать ПО; ▪️они были читаемы и понятны всем - от разработчика до заказчика; ▪️их было удобно поддерживать в актуальном состоянии; ▪️их можно было согласовать и "зафиксировать" с заказчиком. 👉 Для этого и существует моделирование требований. Что такое модель? Модель - это упрощённое представление реальности. Она сохраняет ключевые свойства объекта и позволяет передать информацию для анализа, обобщения и понимания. С помощью модели можно проверить поведение системы ещё до того, как она создана. Зачем нужны модели требований? ▫️показать поведение программы с точки зрения пользователя (а не кода); ▫️однозначно описать требования без "двойных трактовок"; ▫️сократить количество ошибок, пропусков и противоречий; ▫️упростить внесение изменений в требования. Как строятся модели? Мы используем элементы диаграмм (стрелки, овалы, квадраты и др.). Эти элементы задаёт нотация - условный язык, на котором понимают друг друга специалисты. Популярные нотации: UML - множество видов диаграмм, включая Use Case (разберём её отдельно в следующем посте 👀); BPMN - для описания бизнес-процессов; ERD - диаграммы "сущность-связь" (например, нотации Чена, Мартина с "вороньи лапки", IDEF1X). 💬 А вы какие нотации используете в работе или встречали в проектах?

Как системный аналитик, который во многих рабочих задачах использует активно ИИ, я решил довериться ChatGPT и выйти из стратегии Почему вышел? 🤔 За 1 год и 9 месяцев следования я оказался в минусе на 8,65%: по сути я лишился налоговых вычетов, которые вернул за это время, и недополучил около (боюсь называть эти цифры) - 350 000 - 450 000 р. по грубым расчётам, если бы вложения с ИИС лежали на вкладах последние 2 года. Меня уже давно напрягала эта стратегия, каждый раз, когда заходил сюда, ужасался от ежедневных комиссий за следование 😬 Давно были мысли написать промт для ИИ, и попробовать управлять портфелем вместе с ним, но все никак не доходили руки. На днях я купил подписку на ChatGPT - теперь нет ограничений, которые раньше мешали работать с ним. И решил предварительно оценить, сможет ли он вообще помочь мне с портфелем как-то. Я не стал писать отдельный промт, просто скинул ему скрин портфеля и спросил, разбирается ли он в инвестировании 😂 В общем, он оценил мой портфель, дал рекомендации по балансировке, даже сделал прогноз двух сценариев: остаться в стратегии или выйти и сбалансировать портфель. Его советом было - выйти, хотя бы потому что я уже буду в плюсе, когда перестану платить комиссии за следование. Тут всё очевидно 🤭 В итоге я согласился с ним, вышел и докупил на оставшиеся рубли, которые без дела лежали на ИИС, несколько бумаг из других секторов, которые он посоветовал. Теперь я спокоен 🙏 Дальше в планах создать отдельный проект в ChatGPT под инвестиции и написать специальный промт под него, который будет мне помогать управлять портфелем.

🔥 "Выгорание на работе: как я с ним справляюсь (личный опыт)" Недавно ко мне обратились за советом: "Я сейчас в сильнейшем выгорании. Кажется, что всё, что делаю - неправильно. Ты недавно сам через это прошёл, подскажи, что делать?" За 10,5 лет работы в одной компании у меня было несколько выгораний разной силы. Каждый раз они проходили, но почти всегда - на фоне перемен: • смена структуры, должности или задач; • полноценный отпуск и путешествия; • новые хобби - бег, кроссфит и т.п. Недавно я снова пережил волну выгорания, и вот что помогло именно сейчас 👇 🔄 1. Смена подхода к работе В моём случае - активное использование ИИ для написания ТЗ и других артефактов. По сути, это та же смена обстановки: мозг переключается с рутины на что-то новое и интересное. Это реально вернуло интерес к задачам. 📚 2. Саморазвитие в профессии Бесплатные и платные курсы, вебинары, изучение новых тем через статьи и блоги. Для меня стимулом стало и ведение этого канала. Когда учишься новому, выходишь из зоны комфорта, мозг снова начинает работать активнее - и это отличный "антидот" от выгорания. 🛡️ 3. Выстраивание границ Если основная причина выгорания - токсичная атмосфера в компании или определённые триггеры (думаю, многие понимают, о чём я), то: • включаем "здорового пофигиста": если процесс тормозится из-за отдельных людей, напомни себе - они вредят не тебе, а компании. Упущенная выгода - проблема компании, а не твоя личная. Ты сделал максимум со своей стороны, дальше ответственность не твоя; • минимизируем контакты: можно обсудить ситуацию с руководителем и договориться, как сократить взаимодействие, которое чаще всего вызывает стресс. Это три кита, на которых я сейчас держусь. ⚓ Надеюсь, мой опыт окажется полезным. P.S. Ещё небольшой вклад в борьбу с выгоранием внесло обустройство нового рабочего места дома 👨‍💻: заказал новый стол, удобный мягкий стул, поставил ночник из гималайской соли 🪔 рядом с ноутбуком (стал, правда, теперь чаще работать вечерами из-за этой атмосферы 😁) Ставьте ⚡️, если советы откликнулись. А вы как справляетесь с выгоранием? Делитесь в комментариях 👇

📋 "Артефакты тестирования: какие документы готовит QA-специалист?" В прошлом посте мы разобрали теорию тестирования. Логичный вопрос: а что же "на выходе"? Какие документы и объекты создаются в процессе? Сегодня говорим об артефактах - материальных результатах работы тестировщика. Артефакты тестирования - это не только документы. Это любые созданные или использованные объекты, которые помогают обеспечить качество ПО. 1. Документы до тестирования (планирование и подготовка) 📄 Тест-план (Test Plan) Главный документ, который описывает всю стратегию тестирования. Что внутри: цели, объем, подход, расписание, оценки рисков, критерии начала/окончания тестирования, необходимые ресурсы. Зачем нужен: чтобы все участники процесса понимали, КАК мы будем тестировать. 📋 Чек-лист (Checklist) Свободный список пунктов для проверки без детальных шагов. Помогает не упустить ключевые функции. Зачем нужен: для быстрого покрытия основных сценариев, когда не хватает времени на детальные тест-кейсы. 🧪 Тест-кейс (Test Case) Детальная инструкция для проверки конкретного условия. Что внутри: ID, заголовок, предусловия, шаги, ожидаемый результат, фактический результат, статус. Зачем нужен: для точного воспроизведения проверки и документирования результата. 📊 Матрица трассируемости требований (Traceability Matrix) Таблица, которая связывает требования с тест-кейсами. Зачем нужна: чтобы убедиться, что каждое требование покрыто тестами, и быстро оценить impact при изменении требования. 🗄 Тестовые данные (Test Data) Подготовленные наборы данных для воспроизведения ситуаций (в предыдущем посте о практике тестирования у меня в компании я называл их тестовыми кейсами, как принято у меня в компании, теперь буду знать, что тест-кейс - это немного другое 🤫) 2. Документы во время тестирования (исполнение и фиксация) 🐞 Баг-репорт (Bug Report) Документ, описывающий обнаруженный дефект. Что внутри: заголовок, краткое описание, шаги для воспроизведения, ожидаемый и фактический результат, окружение (ОС, браузер, версия), severity (серьезность), priority (приоритет), скриншоты/логи. Зачем нужен: чтобы разработчик понял и воспроизвел проблему, а менеджер расставил приоритеты на исправление. 📈 Отчет о выполнении тестирования (Test Execution Report) Ежедневный или еженедельный отчет о прогрессе. Что внутри: сколько тест-кейсов выполнено, сколько passed/failed, сколько багов найдено, общие метрики. Зачем нужен: чтобы команда и заказчик видели текущий статус тестирования. 3. Документы после тестирования (завершение и анализ) 📝 Отчет о тестировании (Test Summary Report) Итоговый документ по итогам тестового цикла. Что внутри: что было протестировано, общая статистика (успешные/неуспешные тесты), критичные найденные проблемы, оценка качества ПО, рекомендации к выпуску (release). Зачем нужен: чтобы принять объективное решение о готовности продукта к выпуску. 🎯 Метрики качества (Quality Metrics) Оцифрованные данные о процессе тестирования и качестве ПО. Примеры: количество дефектов на модуль, плотность дефектов, процент успешных тест-кейсов, время на исправление багов. Зачем нужны: для анализа эффективности тестирования и улучшения процесса в будущем. Почему это важно? Даже если в вашем проекте всё сводится к чек-листам и баг-репортам в Jira, - понимание полной картины помогает выстраивать более качественный процесс и говорить с профессиональными QA-командами на одном языке. Напомню, в моей практике мы используем чек-листы, в которых, исходя из изученной теории, мы часто совмещаем и баг-репорт, а также иногда уровень детализации чек-листа позволяет назвать его тест-кейсом 🧠. А какие артефакты тестирования используете вы? Поделитесь в комментариях! 👇

🧪 Теория тестирования: как "правильно" должно быть В прошлом посте я делился, как у нас в компании тестирование происходит "по-простому" - вручную и по чек-листам. Теперь разберёмся, а как по теории всё это должно выглядеть 👇 Зачем вообще нужно тестирование? Не чтобы "найти баги", а чтобы оценить риск того, что продукт подведет пользователя в самый ответственный момент. Это страховка для бизнеса. 🔹 Виды тестирования • Функциональное - проверяем, что ПО делает то, что написано в требованиях. • Нефункциональное - скорость, надёжность, удобство, безопасность. • Модульное (Unit) - проверяем отдельные "кирпичики" (модули) - функции, классы. Делают разработчики. • Интеграционное - как модули и сервисы работают вместе (часто - тестировщики + разработчики). • Системное (E2E) - проверка всей системы целиком, как это слелал бы пользователь (проверяют тестировщики). • Приёмочное (UAT) - готов ли продукт к сдаче заказчику (проверяет заказчик или его представитель). Нужно, чтобы подтвердить: "Да, это то, что мы хотели". • По принципу работы: ○ Позитивное - проверка, что система работает как должна на корректных данных. ○ Негативное - проверка, как система обрабатывает ошибки (неверный пароль, битый файл). ○ Дымовое (Smoke / Sanity) - быстрая проверка "заводится ли вообще" после обновления, работает ли сборка, стоит ли её дальше гонять. ○ Регрессионное - проверка, что новое обновление не сломало старое. ○ Нагрузочное - проверка, как система поведет себя под нагрузкой. 🔹 Manual vs Automated • Ручное тестирование - глазами и руками: удобно для UX, интерфейса и нестандартных процессов. Минус - долго и можно упустить баг. • Автоматизированное - скрипты и инструменты гоняют тесты сами. Удобно для регрессии, API и повторяющихся задач. Минус - дорого внедрять и поддерживать. На практике чаще всего сочетают оба подхода. 🔹 Подходы • Тестирование на основе риска - сначала проверяем то, что "сломается" с наибольшими последствиями. • Чёрный / белый / серый ящик - разный уровень знаний о системе и коде: ■ Белым ящиком (White Box): Тестируем, зная внутреннее устройство системы. Нужно знать код. ▪︎Черным ящиком (Black Box): Тестируем только внешнее поведение, не зная, что внутри. Как делает пользователь. □ Серым ящиком (Gray Box): Что-то знаем о внутренностях, но тестируем снаружи. • Эквивалентные классы и граничные значения - тестируем самые важные и крайние случаи, чтобы не перегружать проверку. • Исследовательское тестирование (Exploratory) - выделяешь время и "играешь" с системой, чтобы найти неожиданные баги, идёшь не по чек-листу, а ищешь баги опытом и интуицией. 🔹 Как выглядит процесс • Анализ требований и сценариев. • Определяем виды тестов. • Составляем чек-листы / тест-кейсы. • Готовим тестовые данные и среду. • Проводим тестирование. • Логируем ошибки, отправляем на исправление. • Повторная проверка (регрессия). • Приёмка и выпуск. • Сбор обратной связи после релиза. 🔹 На что обратить внимание аналитику • Проверяй и UI, и "под капотом" (БД, логи). • Составляй чек-листы и тест-кейсы с неочевидными случаями. • Замечай, чего нет в требованиях. • Работай в связке с тестировщиками и разработчиками: это даёт очень сильный эффект. Почему так сложно? В идеальном мире каждый этап формализован. Но на практике, как и в моём случае, часто всё сводится к ручному тестированию по чек-листам. И это нормально, если проект небольшой и риски низкие. Главное - понимать, к чему стоит стремиться. В следующем посте разберу, какие артефакты тестирования можно использовать (чек-листы, тест-кейсы, баг-репорты и др.). А как у вас устроено тестирование? Делитесь опытом 👇

🔎 "Как правильно делать тестирование?" Задаюсь этим вопросом каждый раз, когда провожу тестирование очередного автоматизированного процесса или нового раздела CRM-системы. Меня специально тестированию никто не обучал, курсов не проходил. Знаю только на слух такие слова, как "автотесты", "чек-листы", "ручное тестирование" и другие. На практике же сталкивался в основном только с ручным тестированием и чек-листами 😅 Однажды встречался с таким документом, как ПМИ - когда принимали ПО от контрагента. По сути, он показался мне тем же чек-листом, только официальным и с подписями сторон. В нашей компании аналитики используют в работе именно ручное тестирование. Почему так? Всё просто: • нет компетенций по автоматическому тестированию; • процессы часто однотипные, и ручной проверки достаточно. Как у нас проходит тестирование: 📌 1. Кто тестирует? Чаще всего - я сам, как аналитик, который готовил ТЗ. Реже подключаюсь к тестированию "чужих" проектов для помощи. 📌 2. Главный инструмент - чек-лист Это документ, где расписаны шаги и ожидаемый результат. Составляю его я же на основе ТЗ. Проверяю не только действия пользователя, но и то, что происходит "под капотом" (данные в БД). 📌 3. Процесс проверки Иду по каждому пункту чек-листа, отмечаю статус ("корректно" или "некорректно"), пишу комментарии. Обнаруживаю не только баги, но и упущенные в ТЗ нюансы - тогда дополняю документ. 📌 4. Тестовые данные Часто нужны тестовые кейсы - отдельные атрибуты или сущности в базе с тестовыми данными или документы (в зависимости от процесса). Иногда мы тестируем целые процессы на тестовой базе. 📌 5. Завершение тестирования По итогу прохождения теста чек-лист отправляется разработчикам для исправления багов. 💡 Личный вывод: Идеально тестировать то, что сам проектировал - видишь все нюансы. Если проверяю чужой процесс, всё равно сначала внимательно читаю ТЗ. Часто нахожу то, что упустили в чек-листе. Что в итоге? Тестируем вручную по чек-листам на тестовых данных или базе. А вот как должно быть "по науке", я попробую разобрать в следующем посте - с точки зрения теории. 👉 А как у вас проходит тестирование?

📁 "Что такое артефакты системного аналитика и зачем они нужны?" Мы уже разобрали, чем занимается аналитик. Теперь вопрос: что остается после его работы? Всё просто - артефакты! Артефакты - это любой осязаемый результат работы аналитика. То, что можно «пощупать»: документы, диаграммы, схемы, модели. 📄✏️ Условно их делят на две группы: 🧑💼 1. Внешние артефакты (для заказчика и пользователей) Нужны, чтобы все поняли, что мы делаем и зачем. • User Story (Пользовательские истории) - короткие и понятные описания функций. • Use Case (Варианты использования) - сценарии взаимодействия с системой. • SRS (Software Requirements Specification) - спецификация требований к ПО. • ТЗ (Техническое задание) - часто по внутреннему стандарту компании. 👨💻 2. Внутренние артефакты (для команды разработки) Нужны,чтобы объяснить, как всё должно работать. • Диаграммы (BPMN, UML, ER) - визуализация процессов, данных и архитектуры. • Прототипы интерфейсов (Figma, Sketch, мокапы). • Документ "Постановка задачи" - описание архитектуры, API, алгоритмов. 👨‍💻 На практике в каждой компании есть свои стандарты документации: шаблоны, инструкции, готовые формы. Это сильно упрощает жизнь - не нужно изобретать велосипед. 💡 Личный опыт: У нас в компании внешние и внутренние артефакты объединены в одно общее ТЗ. Удобно, что всё собрано в одном месте. Но есть и минус - иногда неудобно заказчику или разработчику: приходится читать большой документ целиком. Мы решаем это структурой: разделы сделаны так, что понятно, кому какой блок читать. ‼️ Важно: Артефакты - это не просто бумажка для галочки. Это инструменты коммуникации. Всегда собирайте обратную связь: что было непонятно заказчику? что вызывало вопросы у разработчиков? Это поможет улучшать документы в будущем. А какие артефакты готовите вы? Что чаще всего используете в работе? Делитесь в комментариях👇

🔎 "Что делает системный аналитик на проекте разработки ПО?" Ранее мы разобрали основные этапы разработки ПО и проектную команду. Теперь давайте подробнее посмотрим на функции системного аналитика на каждом этапе. Анализ ▪️сбор требований (интервью с заказчиком); ▪️анализ текущего ПО (если оно есть); ▪️формирование требований к новому продукту (цели, задачи, функции); ▪️взаимодействие с менеджером проекта и бизнес-аналитиком (если он есть); ▪️согласование требований с заказчиком и другими заинтересованными лицами. Проектирование ▪️описание работы будущего ПО (как оно должно работать, из каких компонентов состоять и как они будут взаимодействовать); ▪️подготовка прототипа пользовательского интерфейса (если он предусмотрен). Дизайн ▪️UI/UX-дизайнер создаёт макеты интерфейса (самостоятельно или на основе прототипа от аналитика); ▪️аналитик консультирует дизайнера по сценариям использования ПО и участвует в согласовании макетов. 💡На практике, например, в моей компании эти три этапа часто объединяются в один документ - ТЗ (техническое задание). Его готовит системный аналитик и, при необходимости, сам рисует прототипы - чаще всего в Figma, но бывает и в Excel или даже Paint (всё зависит от задач и навыков аналитика). Разработка ▪️постановка задач разработчикам (если нет отдельного менеджера проекта); ▪️консультирование по ТЗ, сценариям работы и вопросам взаимодействия пользователя с ПО; ▪️уточнение спорных моментов у заказчика и внесение правок в документацию. Тестирование ▪️ответы на вопросы тестировщиков (например, о поведении пользователей или критериях качества); ▪️приёмка продукта «глазами пользователя»; ▪️написание чек-листов и тестирование (если тестировщика нет в команде). Внедрение ▪️обновление ТЗ (приведение его в соответствие с фактической реализацией); ▪️подготовка инструкций для пользователей; ▪️презентация продукта и обучение пользователей (если нет выделенных специалистов). Поддержка и развитие ▪️анализ запросов от пользователей; ▪️помощь в устранении ошибок; ▪️участие в доработках и развитии продукта. Таким образом, системный аналитик задействован на всех этапах разработки ПО. Где-то больше, где-то меньше - зависит от компании, проекта и состава команды. ❓А вам на каком этапе интереснее всего участвовать в проекте?

👥 "Кто делает проект? Формируем идеальную команду под задачи" В одном из прошлых постов мы разобрали этапы разработки. Логичный следующий шаг - понять, какие специалисты нужны для их реализации. Собрал для вас гид по ролям в проекте. Состав сильно зависит от сложности и масштабов. Чем их больше - тем больше ролей будет задействовано. 🛠 Базовый состав (для большинства проектов): 👑 **Менеджер проекта (PM, РП, проджект)** Отвечает за то, чтобы проект был успешно завершён в срок. Функции: планирование, контроль, управление рисками, коммуникация. На практике: часто эти функции выполняет системный аналитик. 🧠 **Системный аналитик** Разрабатывает требования к ПО. Максимально задействован на этапах анализа и проектирования. Функции: сбор требований, проектирование решений, документирование. 💻 **Разработчик** Создает и развивает ПО (Frontend, Backend, Fullstack). Функции: написание кода, тестирование, исправление ошибок. 🐞 **Тестировщик (QA-инженер)** Отвечает за качество продукта. Функции: описание сценариев, проверка работы, фиксация ошибок. На практике: тестированием часто занимается сам аналитик и/или разработчик. 🚀 Расширенный состав (для сложных продуктов): 📊 **Бизнес-аналитик** Изучает процессы в компании и предлагает улучшения. Функции: описание процессов "как есть" (As Is) и "как будет" (To Be), оценка эффективности. На практике: часто эти задачи входят в функционал системного аналитика. 🎨 **UX/UI-дизайнер** Проектирует интерфейс, которым будет приятно и удобно пользоваться. Функции: исследование аудитории, создание дизайн-макетов. На практике: в отдельных проектах макеты может делать также системный аналитик. 🏗 **Архитектор ПО** Проектирует сложные системы. Функции: разбиение на компоненты, выбор технологий. На практике: эту роль часто выполняет senior-разработчик. 🔄 **DevOps-инженер** Автоматизирует процессы поставки и развертывания ПО. Функции: сборка, настройка environments, CI/CD. 🛟 **Специалист сопровождения** Работает с пользователями после запуска. Функции: поддержка, сбор обратной связи, формирование базы знаний. В моей компании: эту работу почти всегда выполняет системный аналитик проекта. В итоге: • Ролей много, и они зависят от проекта. • Часто один специалист совмещает несколько функций - это нормально. А у вас какой состав команды? Делитесь в комментариях - у кого самый необычный набор ролей на проекте? 👇 У меня чаще всего минимальный: я (аналитик, он же менеджер проекта и тестировщик) и разработчик.

🚀 "Путь от идеи до продукта: как не потеряться в этапах разработки" Знакомая картина? Вам накидали кучу пожеланий, а в голове - каша 🤯. С чего начать? Что делать после сбора требований? Кого подключать к работе? Чтобы перестать паниковать, нужна карта. И это - основные этапы разработки ПО 🗺 (смотрите схему ниже). Кратко про каждый этап разработки ПО: 🎯 1. Анализ Собираем требования, понимаем, что должно делать ПО. Ответ на вопрос "Зачем мы это делаем?". 📐 2. Проектирование Решаем, как оно будет работать изнутри (архитектура, алгоритмы, API), чтобы выполнять свои задачи. Ответ на вопрос "Как должно быть устроено ПО?". 🎨 3. Дизайн Создаем дизайн-макеты ПО. UI/UX - это тоже требования, просто визуальные. Ответ на вопрос "Как будет выглядеть ПО?" 💻 4. Разработка Пишем код. Здесь магия превращения ТЗ в работающий продукт. 🐞 5. Тестирование Ловим баги и проверяем, что получилось ровно то, что задумывалось на этапе анализа. Ответ на вопрос "ПО готово к работе?" 🚀 6. Внедрение Отдаём продукт пользователям, обучаем их и получаем первую обратную связь. Финальный рывок! Зачем это всё аналитику? Чтобы не изобретать велосипед для каждого проекта. Понимая этапы, вы сможете: • Правильно подобрать команду и роли; • Составить реалистичный план и оценить сроки/бюджет; • Объяснить заказчику, что и почему происходит в проекте. С какими моделями сталкивался я? На крупных проектах (например, в разработке CRM) мы проходили все этапы от и до. А в задачах автоматизации процессов часто пропускали этапы дизайна (интерфейс не нужен) и внедрения в том понимании, как здесь указано (запускали процесс в работу автоматически, без обучения пользователей - они просто видят готовый результат). А как у вас? Делитесь в комментариях - какой этап самый хаотичный и "горящий" в ваших проектах? 👇

"Кто такой системный аналитик и зачем он нужен?" Системный аналитик - это человек, который помогает компаниям и командам понимать, как устроены их процессы и системы, и как их можно улучшить. Если вы только начинаете путь в ИТ или бизнес-анализе, этот пост поможет разобраться, чем занимается аналитик и какие бывают его "типы". В процессе прохождения курсов по системному анализу и изучения информации в открытых источниках я понял, что единого определения профессии нет. В разных источниках акцент делается на разные аспекты: где-то больше на технической части, где-то - на бизнес-анализе. На примере моей компании и изучении рынка я увидел, что функционал системного аналитика часто широкий и размытый, а формально такой человек может называться бизнес-аналитиком или старшим/ведущим аналитиком (я, например, сейчас ведущий специалист). Например, "Яндекс практикум" в своем курсе "Системный аналитик" пишет, что это специалист, который разрабатывает требования к программному обеспечению, т.е. ограничивает аналитика узкой специализацией, но он выделяет отдельно бизнес-аналитика, которому передан остальной функционал, связанный с взаимодействием с бизнесом, анализом и описанием бизнес-процессов. Если обобщать все возможные функции системного аналитика, то получится примерно такая картина: 1. Что делает системный аналитик: 🔹 Анализирует процессы компании и выявляет проблемы. 🔹 Формулирует требования к системам и ПО. 🔹 Создаёт модели процессов, диаграммы и схемы. 🔹 Связывает бизнес-задачи с техническими решениями. 2. Почему он нужен: 🔹 Чтобы системы работали так, как нужно бизнесу. 🔹 Чтобы команды разработчиков понимали, что именно требуется. 🔹 Чтобы экономить время и деньги на исправление ошибок. 3. Типы системных аналитиков (по специализации): Вот несколько основных ролей, которые встречаются на практике: 📝Бизнес-аналитик – фокус на бизнес-процессах, требованиях и пользователях. 💻Технический аналитик – ближе к ИТ, занимается архитектурой системы, интеграциями. 🛠Функциональный аналитик – отвечает за функциональные спецификации и сценарии использования. Иногда аналитик совмещает несколько ролей, особенно в небольших компаниях. Таким образом, системный аналитик — это "мост" между бизнесом и разработкой. Он помогает понять, что нужно компании, и как это реализовать в системе. Даже если вы начинаете, важно знать, что эта профессия сочетает анализ, коммуникацию и моделирование процессов. А вы знаете кого-то, кто работает системным аналитиком? Или хотели бы попробовать себя в этой роли? Напишите в комментариях 👇