#books #мояполка #стоитпочитать #анализ #системныйанализ #требования
Алистер Коберн - “Современные методы описания функциональных требований к системам”
Раз всё таки, изначально я инженер и системный аналитик, то ко мне часто обращаются именно с темой - “как прокачать себя, как системного аналитика”. И тут я снова отправляю людей к основам. Многие ждут какой-то волшебной палочки, или серебрянной пули, что вот я сейчас какую-то книгу прочитаю или что-то изучу, и сразу стану системным аналитиком. Но почему-то не выходит. Иногда не выходит из-за того, что человек не совсем понимает, что такое системное мышление, это про soft skills, но также просто отсутствуют фундаментальные знания, это к hard skills. Если вы работаете с требованиями к информационным системам, то стоит всё таки вернуться к разделу с признаком “must”. При условие, конечно, если у вас отсутствуют подобные знания и навыки. Я намекаю на сценарную технику фиксирования требований. А именно я говорю про use case - те самые, добрые варианты использования. Но я бы копнула глубже и сказала, что сначала нужно разобраться с основами объектно-ориентированного программирования. Но по опыту могу сказать, что сценарии (или варианты использования) отлично понимают и далекие от инженерных наук люди. В телеком среде, в виде сценариев бизнес-аналитики описывали работу бизнеса. Есть книга, написанная признанным экспертом в области ИТ - Алистером Коберном. Её перевод на русский мне показался тяжеловесным, но это тот самый случай, когда просто стоит ознакомиться и понять как оно работает. Я говорю про книгу “Современные методы описания функциональных требований к системам”. И прошу Вас не путать понятия use case и user story. Т.к. это совсем про разные подходы к требованиям. Use case - вариант использования - это длинная “веревочка”, которая пронизывает ваше полотно функционала. Длинная и если вы за неё потянете, то как в кусочке ткани она будет пронизывать весь кусок. User story появились позже, чем use case, и дословный перевод - пользовательская история. Очень грубо говоря, это маленькая хотелка пользователя из разряда - “я хочу, чтобы моя программа делала вот этот расчет”. Аналог с тканью, это стежок, маленький кусочек ниточки, вот если кучу user story, как маленькие отрезки веревочки, связать вместе, то получится цепочка в виде use case. Правда на практике я не видела, чтобы кто-то одно превращал в другое, потому что эти инструменты из разных “весовых” категорий. Сценарная техника мне очень нравится, она и проста и сложна одновременно, но при этом дает возможность увидеть полную картину “бедствия” разработки функционала. Итого, рекомендую Вам хотя бы открыть книгу и прочитать примеры составления сценариев, а возможно взять их за основу шаблона для Ваших требований на проекте.
Алистер Коберн - “Современные методы описания функциональных требований к системам”
Раз всё таки, изначально я инженер и системный аналитик, то ко мне часто обращаются именно с темой - “как прокачать себя, как системного аналитика”. И тут я снова отправляю людей к основам. Многие ждут какой-то волшебной палочки, или серебрянной пули, что вот я сейчас какую-то книгу прочитаю или что-то изучу, и сразу стану системным аналитиком. Но почему-то не выходит. Иногда не выходит из-за того, что человек не совсем понимает, что такое системное мышление, это про soft skills, но также просто отсутствуют фундаментальные знания, это к hard skills. Если вы работаете с требованиями к информационным системам, то стоит всё таки вернуться к разделу с признаком “must”. При условие, конечно, если у вас отсутствуют подобные знания и навыки. Я намекаю на сценарную технику фиксирования требований. А именно я говорю про use case - те самые, добрые варианты использования. Но я бы копнула глубже и сказала, что сначала нужно разобраться с основами объектно-ориентированного программирования. Но по опыту могу сказать, что сценарии (или варианты использования) отлично понимают и далекие от инженерных наук люди. В телеком среде, в виде сценариев бизнес-аналитики описывали работу бизнеса. Есть книга, написанная признанным экспертом в области ИТ - Алистером Коберном. Её перевод на русский мне показался тяжеловесным, но это тот самый случай, когда просто стоит ознакомиться и понять как оно работает. Я говорю про книгу “Современные методы описания функциональных требований к системам”. И прошу Вас не путать понятия use case и user story. Т.к. это совсем про разные подходы к требованиям. Use case - вариант использования - это длинная “веревочка”, которая пронизывает ваше полотно функционала. Длинная и если вы за неё потянете, то как в кусочке ткани она будет пронизывать весь кусок. User story появились позже, чем use case, и дословный перевод - пользовательская история. Очень грубо говоря, это маленькая хотелка пользователя из разряда - “я хочу, чтобы моя программа делала вот этот расчет”. Аналог с тканью, это стежок, маленький кусочек ниточки, вот если кучу user story, как маленькие отрезки веревочки, связать вместе, то получится цепочка в виде use case. Правда на практике я не видела, чтобы кто-то одно превращал в другое, потому что эти инструменты из разных “весовых” категорий. Сценарная техника мне очень нравится, она и проста и сложна одновременно, но при этом дает возможность увидеть полную картину “бедствия” разработки функционала. Итого, рекомендую Вам хотя бы открыть книгу и прочитать примеры составления сценариев, а возможно взять их за основу шаблона для Ваших требований на проекте.
#мирвокруг #вопросответ #skills #аналитик #моемнение #требования
Хороший ко мне прилетел вопрос:
В вакансиях есть строчка - знание и умение работать в Kafka. Действительно ли это нужно аналитику?
Ответ мой следующий: по такому требованию можно предположить, что компания аналитика использует как разнорабочего. Это неплохо и нехорошо, это вот так в компании. И скорее всего зрелость этой компании в плане АйТи средняя. А вот учить кафку и идти или нет, это уже ваш выбор. Имхо, зачем спутывать понятия, каждый должен заниматься своим делом. Для настройки Кафки есть DevOps, у них это получится лучше. Так сказать, зачем топором забивать гвоздь, есть же молоток))
Я не знаю Kafka, но в своё время трогала руками MQ message broker от компании IBM. Времена изменились, появились микросервисы, биг дата и новые инструменты. Изучить что-то новое, при понимание, что это, и зачем, я считаю мне не составит труда.
Моё мнение, что важнее понимание, что это такое, зачем и для чего. Я всегда за фундамент. И считаю, что аналитику важнее понимать так сказать матчасть, что такое очередь, как она работает, как устроена, что там может быть и зачем подобный механизм нужен, как работает в среде микросервисов. Есть теория обслуживания и построения систем массового обслуживания. Мне её читали в институте, очень увлекательно и очень нравилось)))
Вот мне её вполне как фундамента хватало, чтобы изучить механизм работы брокера.
Ещё есть такой момент, что работодатель часто летает в облаках, и думает, что сейчас я найду универсала и он будет уметь всё, или просто пишет набор требований не понимая, кто им нужен и кто действительно такой аналитик (продакт или прожект, да кто угодно, нужное подчеркнуть). Но универсалов очень мало. Даааааа, мы тоже страдали большим набором требований, спустя какое-то время пришло осознание, что проще взять человека с базой и фундаментальными знаниями и научить тому, что нужно, готового специалиста со знанием нюансов, нужных именно твоей среде работы, может и не быть.
Так что ещё одно предположение, что вакансия сырая и возможно работодатель не совсем знает, кто есть на рынке. А возможно у них был хороший специалист, который закрывал все дыры, и ушёл, и теперь все хотят такого же.
Хороший ко мне прилетел вопрос:
В вакансиях есть строчка - знание и умение работать в Kafka. Действительно ли это нужно аналитику?
Ответ мой следующий: по такому требованию можно предположить, что компания аналитика использует как разнорабочего. Это неплохо и нехорошо, это вот так в компании. И скорее всего зрелость этой компании в плане АйТи средняя. А вот учить кафку и идти или нет, это уже ваш выбор. Имхо, зачем спутывать понятия, каждый должен заниматься своим делом. Для настройки Кафки есть DevOps, у них это получится лучше. Так сказать, зачем топором забивать гвоздь, есть же молоток))
Я не знаю Kafka, но в своё время трогала руками MQ message broker от компании IBM. Времена изменились, появились микросервисы, биг дата и новые инструменты. Изучить что-то новое, при понимание, что это, и зачем, я считаю мне не составит труда.
Моё мнение, что важнее понимание, что это такое, зачем и для чего. Я всегда за фундамент. И считаю, что аналитику важнее понимать так сказать матчасть, что такое очередь, как она работает, как устроена, что там может быть и зачем подобный механизм нужен, как работает в среде микросервисов. Есть теория обслуживания и построения систем массового обслуживания. Мне её читали в институте, очень увлекательно и очень нравилось)))
Вот мне её вполне как фундамента хватало, чтобы изучить механизм работы брокера.
Ещё есть такой момент, что работодатель часто летает в облаках, и думает, что сейчас я найду универсала и он будет уметь всё, или просто пишет набор требований не понимая, кто им нужен и кто действительно такой аналитик (продакт или прожект, да кто угодно, нужное подчеркнуть). Но универсалов очень мало. Даааааа, мы тоже страдали большим набором требований, спустя какое-то время пришло осознание, что проще взять человека с базой и фундаментальными знаниями и научить тому, что нужно, готового специалиста со знанием нюансов, нужных именно твоей среде работы, может и не быть.
Так что ещё одно предположение, что вакансия сырая и возможно работодатель не совсем знает, кто есть на рынке. А возможно у них был хороший специалист, который закрывал все дыры, и ушёл, и теперь все хотят такого же.
#капитаночевидность #историиизжизни #требования #мысливслух #рассуждения #администрирование
Пользовательские требования (а если юзер администратор?).
Источник требований - пользователь, тут всё понятно. И системы мы создаём для людей и наших пользователей. Но часто не то, что забываем про администратора системы, а скорее считаем, что он наш человек и вообще пусть имеет опыт, и справится с нашей админкой как нибудь.
А то, чтобы прийти и спросить как ему с этими настройками работается? Ну нет. Доведём до максимума, когда человек уже будет разговаривать с нами только криком.
Вот даже хочется добавить отдельный класс требований к системе - это пользователь, который будет производить бизнес и техническое администрирование системой.
Вспомнила тут случай, когда наш разработчик покрасил админку в нежно розовый цвет. Ох как был рад администратор системы))) Что стало ярче, веселее и приятнее. И на сдаче проекта заметил этот положительный момент. Мы все смеялись, а как известно смех снижает градус напряжения.
Так что, не забывайте об админах, команда сделает проект, а поддерживать другим. Я до сих пор встречаю проекты, где автоматизацию администрирования не то, что не прорабатывают, а считают не существенной. А вот когда система становится непредсказуемым камнем, уже поздно "пить боржоми".
Пользовательские требования (а если юзер администратор?).
Источник требований - пользователь, тут всё понятно. И системы мы создаём для людей и наших пользователей. Но часто не то, что забываем про администратора системы, а скорее считаем, что он наш человек и вообще пусть имеет опыт, и справится с нашей админкой как нибудь.
А то, чтобы прийти и спросить как ему с этими настройками работается? Ну нет. Доведём до максимума, когда человек уже будет разговаривать с нами только криком.
Вот даже хочется добавить отдельный класс требований к системе - это пользователь, который будет производить бизнес и техническое администрирование системой.
Вспомнила тут случай, когда наш разработчик покрасил админку в нежно розовый цвет. Ох как был рад администратор системы))) Что стало ярче, веселее и приятнее. И на сдаче проекта заметил этот положительный момент. Мы все смеялись, а как известно смех снижает градус напряжения.
Так что, не забывайте об админах, команда сделает проект, а поддерживать другим. Я до сих пор встречаю проекты, где автоматизацию администрирования не то, что не прорабатывают, а считают не существенной. А вот когда система становится непредсказуемым камнем, уже поздно "пить боржоми".
#анонс #китайскаяручка #тренинг #очно #системныйаналитик #требования
После своего долгого молчания возвращаюсь с анонсом!
Решила вспомнить былое и провести очный тренинг "Китайская ручка", по сбору требований!Сейчас Китай это модно, тем более Си++ прилетел в Москву.
Спасибо автору тренинга Сергею Нужненко за информацию и поддержку.
Кому нужен тренинг? Я бы сказала всем. Даже аналитики с опытом делают для себя выводы. Но будем объективными, что тренинг важен прежде всего начинающим аналитикам, и тем кто понимает, что буксует в части сбора, систематизации и анализа требований.
Тренинг будет проходить в виде игры в командах (или будет одна команда). Мы будем имитировать этапы:
✅интервью для сбора требований,
✅создания спецификации с
✅последующем согласованием,
✅изготовление,
✅приёмку результата с заказчиком.
Во второй части, мы затронем подход Agile, описание требований в виде user story, и составления user story mapping. Сравним подходы, посчитаем эффект.
Даты тренинга - 22 марта (среда, часть 1) и 29 марта (среда, часть 2) с 19:00 до 22:00.
Тренинг идёт две среды.
Стоимость 5000 рублей.
Адрес: (предварительно) зал в 5 минутах ходьбы от метро Кузнецкий мост, Москва
Регистрация - пишите сообщение мне в личку @tasha_kvitka
Если остались вопросы, пишите, спрашивайте!
После своего долгого молчания возвращаюсь с анонсом!
Решила вспомнить былое и провести очный тренинг "Китайская ручка", по сбору требований!
Спасибо автору тренинга Сергею Нужненко за информацию и поддержку.
Кому нужен тренинг? Я бы сказала всем. Даже аналитики с опытом делают для себя выводы. Но будем объективными, что тренинг важен прежде всего начинающим аналитикам, и тем кто понимает, что буксует в части сбора, систематизации и анализа требований.
Тренинг будет проходить в виде игры в командах (или будет одна команда). Мы будем имитировать этапы:
✅интервью для сбора требований,
✅создания спецификации с
✅последующем согласованием,
✅изготовление,
✅приёмку результата с заказчиком.
Во второй части, мы затронем подход Agile, описание требований в виде user story, и составления user story mapping. Сравним подходы, посчитаем эффект.
Даты тренинга - 22 марта (среда, часть 1) и 29 марта (среда, часть 2) с 19:00 до 22:00.
Тренинг идёт две среды.
Стоимость 5000 рублей.
Адрес: (предварительно) зал в 5 минутах ходьбы от метро Кузнецкий мост, Москва
Регистрация - пишите сообщение мне в личку @tasha_kvitka
Если остались вопросы, пишите, спрашивайте!
Требования - это же не rocket science, что тут сложного?
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.
Мы копаем дальше, но в какой-то момент понимаем, что нужно вернуться к базовым вещам, их скорректировать, и ещё раз разобрать работу с требованиями, их классификацию.
✅ Требования - это ключевая единица результата работы аналитика.
По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.
Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).
Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг
Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?
#работастребованиями #системныйанализ #системныйаналитик #требования
Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
Что же поможет аналитику при работе с требованиями?
✅Первое, это начать замечать уровни требований. Чтобы заметить проблему, её нужно сначала просто назвать. Тут поможет пирамида артефактов, дополнительные вопросы.
✅Второе, это инструменты выявления и фиксирования требований, нотации в том числе в помощь. Всё зависит от уровня требований. Если мы находимся на бизнес уровне, так на языке этого уровня и нужно говорить, брать бизнес-модели, орг структуру, бизнес-процессы.
✅Третье, это абстрактное мышление. До сих пор ведутся споры, что такое мышление, а тут ещё и абстрактное. Но действительно оно есть, способ думать так, чтобы минимально опираться на самое решение, разработку. Это действительно сложно. И подобный навык дают технические вузы, но как любое мышление, абстрактное мышление можно развивать.
✅Четвёртое, логика и взаимносвязи наших требований. Тут помогут знания по формальной логики, теория по пирамиде Минто, теория графов, математика. Но я бы ещё добавила и философию. Всё в системе даёт результат.
✅Пятое, банальные вещи, опыт, насмотренность, вопросы старшим коллегам, активность. Да и просто иногда нужно делать, как другие.
✅Шестое, знания методологий разработки программных продуктов. Всё таки среда очень сильно влияет и необходимо подстроиться под заказчика и команду одновременно.
✅Седьмое, понимание, когда нужно остановиться. Чем больше требований вы описываете на низком уровне, тем больше падает качество результата.
✅Восьмое, знание технологий, подходов в программирование. Всё таки аналитик должен иметь знания, не только на уровне бизнеса, но и на уровне информационных систем (я говорю про системного аналитика). Банально, но часто аналитик даже не может сказать заказчику - "такого не существует".
✅Девятое, soft skills, никто не отменял. Адекватность, умение открыть рот и начать говорить, кажется очень простым навыком, но по факту, это нефига не просто.
#требования #системныйаналитик #работастребованиями #чеклист #системныйанализ #моемнение
А что вам помогает в работе? Пишите в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Сейчас как всё порешаю, и нанесу добро!
Я каждый раз говорю аналитикам - вы не решатели, вы проектировщики, исследователи.
Один из "смертных грехов" аналитика - это добавить функционал, о котором никто не просил.
Этим чаще всего грешат начинающие специалисты или те, кто хочет показать свою экспертность. Да и заказчик может фантазировать до безумия, и накидывать решения, непонятной проблемы.
Чаще всего мы все работаем с уже понятным бизнесом, запросами, решениями. Для начала посмотри у конкурентов и сделай также.
Но нет наследие, научно-исследовательской работы сидит крепко у многих. Сейчас сделаем космический, уникальный, мегасуперпупер корабль, а потом уже разберёмся, как его применять. Будем честными, что всё таки редко кто работает с такими заказчиками, как уровень Илона Маска и Стива Джобса. Когда ситуация продакт вижен такая, что инженеры говорят это нереально, но заказчик говорит нужно, и нужно побеждает.
Но я о другом, я о том, что мы часто придумываем нечто, что точно будет нужно только в наших фантазиях. Но по факту оказывается лишним рудементом.
На менторстве на этот мой тезис аналитик рассказала случай из жизни. Автоматизация медицины, снимков рентген, мрт. Когда было обсуждение, аналитик с заказчиком решили сделать анализ по цвету. Ну якобы можно разукрасить снимок как тепловую карту в разные цвета и эти цвета анализировать. Красный, жёлтый, зелёный и т.д. Когда функционал выкатили в продуктив, первый же доктор сказал, а зачем оно мне нужно? Что мне с этим делать? Снимки всегда черно белые, тут нет разных цветов. Я анализирую по градиенту чёрного и белого. Разработку выкинули. Зря потратили время, бюджет.
Действительно, очень сложно определить, а что заказчик просит, что нет, что у него болит, а что нужно читать между строк. А что не стоит добрасывать в топку реализации, потому что хочется быть хорошими, красивыми, компетентными и сделать людям хорошо.
На тренинге по сбору требований, уже в эти выходные (9, 10 декабря по Москве с 10 до 14, в онлайн режиме), мы будем:
✅ проводить классификацию требований,
✅ имитировать общение с заказчиком,
✅ за 2 дня полностью разберём цикл реализации продукта от сбора требований, до приёмки.
Если замечаете за собой желание нанести добро, и добросить решений, присоединяйтесь!
#анонс #китайскаяручка #тренинг #требования #работастребованиями
Подробное описание тренинга читайте по ссылке:
https://sup.expert/pen
тамже можно оставить заявку на участие)
Я каждый раз говорю аналитикам - вы не решатели, вы проектировщики, исследователи.
Один из "смертных грехов" аналитика - это добавить функционал, о котором никто не просил.
Этим чаще всего грешат начинающие специалисты или те, кто хочет показать свою экспертность. Да и заказчик может фантазировать до безумия, и накидывать решения, непонятной проблемы.
Чаще всего мы все работаем с уже понятным бизнесом, запросами, решениями. Для начала посмотри у конкурентов и сделай также.
Но нет наследие, научно-исследовательской работы сидит крепко у многих. Сейчас сделаем космический, уникальный, мегасуперпупер корабль, а потом уже разберёмся, как его применять. Будем честными, что всё таки редко кто работает с такими заказчиками, как уровень Илона Маска и Стива Джобса. Когда ситуация продакт вижен такая, что инженеры говорят это нереально, но заказчик говорит нужно, и нужно побеждает.
Но я о другом, я о том, что мы часто придумываем нечто, что точно будет нужно только в наших фантазиях. Но по факту оказывается лишним рудементом.
На менторстве на этот мой тезис аналитик рассказала случай из жизни. Автоматизация медицины, снимков рентген, мрт. Когда было обсуждение, аналитик с заказчиком решили сделать анализ по цвету. Ну якобы можно разукрасить снимок как тепловую карту в разные цвета и эти цвета анализировать. Красный, жёлтый, зелёный и т.д. Когда функционал выкатили в продуктив, первый же доктор сказал, а зачем оно мне нужно? Что мне с этим делать? Снимки всегда черно белые, тут нет разных цветов. Я анализирую по градиенту чёрного и белого. Разработку выкинули. Зря потратили время, бюджет.
Действительно, очень сложно определить, а что заказчик просит, что нет, что у него болит, а что нужно читать между строк. А что не стоит добрасывать в топку реализации, потому что хочется быть хорошими, красивыми, компетентными и сделать людям хорошо.
На тренинге по сбору требований, уже в эти выходные (9, 10 декабря по Москве с 10 до 14, в онлайн режиме), мы будем:
✅ проводить классификацию требований,
✅ имитировать общение с заказчиком,
✅ за 2 дня полностью разберём цикл реализации продукта от сбора требований, до приёмки.
Если замечаете за собой желание нанести добро, и добросить решений, присоединяйтесь!
#анонс #китайскаяручка #тренинг #требования #работастребованиями
Подробное описание тренинга читайте по ссылке:
https://sup.expert/pen
тамже можно оставить заявку на участие)
sup.expert
"Китайская ручка"
В эти выходные 9 и 10 декабря 🔥
с 10 до 14 по Москве,
будем проводить онлайн
тренинг-игру по сбору требований "Китайская ручка". ✅
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику увидеть свои типичные ошибки и понять, как от них избавиться на практике, чтобы повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
➕ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
➕ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
➕ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
➕ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
➕ Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️ Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команда аналитиков будет работать над одним продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, чтобы сделать вывод что можно изменить, добавить в свой арсенал аналитики для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Ведущие:
Вводные теоретические материалы, читаю я, Косинова Наталья, мой опыт работы системным аналитиком более 17 лет, я принимала участие в проектах компаний Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, опыт в ИТ более 20 лет.
Андрей будет играть роль типичного заказчика и сможет раскрыть нюансы работы аналитика с точки зрения разработчика и архитектора. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице➡️
https://sup.expert/pen
с 10 до 14 по Москве,
будем проводить онлайн
тренинг-игру по сбору требований "Китайская ручка". ✅
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику увидеть свои типичные ошибки и понять, как от них избавиться на практике, чтобы повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
-------------------------------
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
Команда аналитиков будет работать над одним продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, чтобы сделать вывод что можно изменить, добавить в свой арсенал аналитики для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Ведущие:
Вводные теоретические материалы, читаю я, Косинова Наталья, мой опыт работы системным аналитиком более 17 лет, я принимала участие в проектах компаний Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, опыт в ИТ более 20 лет.
Андрей будет играть роль типичного заказчика и сможет раскрыть нюансы работы аналитика с точки зрения разработчика и архитектора. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице
https://sup.expert/pen
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
"Китайская ручка"
Старт 2024 с тренинга "Китайская ручка" ⭐️
Ох, вот и прошла первая рабочая неделя под лозунгом страдания, по крайней мере у меня так точно. Очень надеюсь, что у вас по-другому)
Процитирую своего коуча "праздники – для того чтобы отдыхать… а послепраздников - для чувства вины как раз".
Так что всё на своих местах)))
Вот с такими разными чувствами и отдохняком потихоньку возвращаюсь в строй!
И внезапно уже набирается мини группа на тренинг по сбору требований к ПО "Китайская ручка!".
Присоединяйтесь!
Анонсирую даты потока:
20 и 21 января с 10 до 14 по Москве, формат онлайн.
Для тех кто размышляет нужно оно или нет, представляю несколько пунктов выводов о тренинге:
✅Во-первых, тренинг и это доработанная, классическая задача собеседований системных аналитиков. Именно с помощью такой игры уже много лет в айти-сфере нанимают аналитиков.
✅Во-вторых, тренинг показывает минимальный необходимый набор знаний аналитика при работе с требованиями. То, без чего не может обойтись ни один аналитик.
✅В третьих, на тренинге разбираются базовые принципы работы с требованиями в том числе мы говорит о том, как корректно формулировать требования.
Подход - "у меня есть руки, я могу писать требования" - ошибочный.
✅В четвёртых, тренинг направлен на приобретение, укрепление навыков, которые аналитик неосознанно использует в своей основной работе.
✅В пятых, мы рассматриваем best practices, чек-листы, шаблоны, практики. Их структура позволяет создавать систему по работе с требованиями на проектах.
В заключение скажу, что сам формат тренинга ценен тем, что есть возможность общаться, делиться опытом и знаниями с коллегами. Именно за счёт групповой работы происходит рост специалистов.
#анонс #тренинг #китайскаяручка #требования
Прочитать подробнее о тренинге и оставить заявку можно на сайте➡️ https://sup.expert/pen
Ох, вот и прошла первая рабочая неделя под лозунгом страдания, по крайней мере у меня так точно. Очень надеюсь, что у вас по-другому)
Процитирую своего коуча "праздники – для того чтобы отдыхать… а послепраздников - для чувства вины как раз".
Так что всё на своих местах)))
Вот с такими разными чувствами и отдохняком потихоньку возвращаюсь в строй!
И внезапно уже набирается мини группа на тренинг по сбору требований к ПО "Китайская ручка!".
Присоединяйтесь!
Анонсирую даты потока:
20 и 21 января с 10 до 14 по Москве, формат онлайн.
Для тех кто размышляет нужно оно или нет, представляю несколько пунктов выводов о тренинге:
✅Во-первых, тренинг и это доработанная, классическая задача собеседований системных аналитиков. Именно с помощью такой игры уже много лет в айти-сфере нанимают аналитиков.
✅Во-вторых, тренинг показывает минимальный необходимый набор знаний аналитика при работе с требованиями. То, без чего не может обойтись ни один аналитик.
✅В третьих, на тренинге разбираются базовые принципы работы с требованиями в том числе мы говорит о том, как корректно формулировать требования.
Подход - "у меня есть руки, я могу писать требования" - ошибочный.
✅В четвёртых, тренинг направлен на приобретение, укрепление навыков, которые аналитик неосознанно использует в своей основной работе.
✅В пятых, мы рассматриваем best practices, чек-листы, шаблоны, практики. Их структура позволяет создавать систему по работе с требованиями на проектах.
В заключение скажу, что сам формат тренинга ценен тем, что есть возможность общаться, делиться опытом и знаниями с коллегами. Именно за счёт групповой работы происходит рост специалистов.
#анонс #тренинг #китайскаяручка #требования
Прочитать подробнее о тренинге и оставить заявку можно на сайте
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
"Китайская ручка"
Для тех кто любит запрыгнуть в последний вагон, и с пользой провести предстоящие выходные приглашаю на тренинг китайская ручка.
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
#анонс #китайскаяручка #тренинг #сбортребований #требования
Тренинг позволяет в игровой форме аналитику отследить типичные ошибки и понять, как их нивелировать на практике, что помогает повысить качество результата своей работы.
-------------------------------
Тренинг состоит из 4 блоков:
✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.
✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.
✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.
✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.
-------------------------------
💪Кому подойдёт тренинг?
Тем кто хочет освоить специальность ИТ-аналитика. Или тем кто хочет разобраться в том, кто такой ИТ-аналитик (часто это полезно менеджерам проектов, HR-специалистам). Вы сможете за 8 часов увидеть цикл разработки от сбора требований, до реализации решения. Поймёте место аналитика в процессе и какое влияние результат его работы оказывает на конечный программный продукт.
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.
Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, как стоит выстраивать работу команды, чтобы повысить качество результата работы аналитиков. Если вы формируете команду анализа, то сделаете для себя выводы, на что стоит обращать внимание в первую очередь, именно вам, при подборе специалистов.
-------------------------------
✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).
Команды участников тренинга будут работать над продуктом, это ручка. Мы специально берём знакомый всем предмет, чтобы наглядно показать, типичное поведение заказчика, ошибки аналитика, и сделать выводы что можно изменить, добавить в свой арсенал работы для повышения качества результата анализа.
-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.
-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇
Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen
sup.expert
"Китайская ручка"