#2
Проблема:
снова у человека ощущение, что он — центр вселенной и работает всю работу в этом мире, при этом есть сигналы, что команда считает иначе: аналитик на проекте — тупо ради мебели. По итогу это “бьёт по самоидентификации”.
Как решали и что получилось:
1) Совместно строили Исикаву, пытаясь забрейнстормить, откуда идут подобные сигналы и чем они могут быть вызваны.
2). Пару девелоперов, с которыми есть более-чем-формально-рабочий контакт, попросили заполнить опросник под условным грифом “Я хочу быть лучше; что вы обо мне думаете и что я могу сделать, чтобы быть более полезной”.
3) Подтвердилась, хоть и на примере пары человек, гипотеза о том, что команда, как и в предыдущем кейсе, не видит работу. Аналитик много общается с заказчиком (почему-то практически всегда письменно, что отнимает тонны времени — с этим будем также пытаться работать), и это остаётся невидимым для команды от слова “совсем”. При этом часть с документированием требований (то, что, собственно, ярко видимо для команды) остаётся в просадке за счет многих факторов, но в основном по незнанию того, как оно может быть иным. Общий посыл, который словили: “Документация — полное гуано, брезгуем ей пользоваться, приходится постоянно спрашивать.” Плюс вскрылось, что техническая часть у аналитика страдает. А точнее её практически нет, что также влияет на то, что команда едва смотрит в сторону БА на встречах. Такое, кстати, я описывал вот тут.
4) Точечных решений было много, но ключевые такие:
- Построили план по приведению документации в порядок: перенос в Confluence, построение структуры, работа с требованиями к данным, НФТ и пр. В AS IS была фактически только постановка задач в Jira в относительно свободном формате. Те же девелоперы, которые участвовали в опросе, на примере прототипа сказали, что огонь огненный. Для этого, правда, серьёзно пришлось подтянуть теорию/практику по тому, какими бывают требования, как с ними работать и документировать, в частности.
- Построили планы на техническую прокачку. Будем наблюдать, как это повлияет на самоощущение от работы и восприятие участия аналитика со стороны.
Итоговые мысли: на мой взгляд, корень проблем тут в том, что аналитик начал работать по принципу “разберусь в процессе” — без качественной теоретической хотя бы подготовки. Я вижу большую ценность в грамотно структурированной теории в голове, о чем также не раз тут писал — не зная, как оно должно быть “по учебнику” и какие вариации могут быть на практике, сложно видеть недостатки собственных процессов. Да, можно учиться и на ходу, но только звезды могут сойтись как удачно (ментор на работе научит; теория выведется, причем правильно, из практики “наощупь”), так и не очень (потеря репутации в команде, негативное влияние на проект, сильно ограниченная применимость вне текущего места работы). Конечно, лучше поздно, чем никогда, и все эти проблемы решаемы, но не покидает мысль, что путь изначально мог быть более правильным и менее болезненным.
Проблема:
снова у человека ощущение, что он — центр вселенной и работает всю работу в этом мире, при этом есть сигналы, что команда считает иначе: аналитик на проекте — тупо ради мебели. По итогу это “бьёт по самоидентификации”.
Как решали и что получилось:
1) Совместно строили Исикаву, пытаясь забрейнстормить, откуда идут подобные сигналы и чем они могут быть вызваны.
2). Пару девелоперов, с которыми есть более-чем-формально-рабочий контакт, попросили заполнить опросник под условным грифом “Я хочу быть лучше; что вы обо мне думаете и что я могу сделать, чтобы быть более полезной”.
3) Подтвердилась, хоть и на примере пары человек, гипотеза о том, что команда, как и в предыдущем кейсе, не видит работу. Аналитик много общается с заказчиком (почему-то практически всегда письменно, что отнимает тонны времени — с этим будем также пытаться работать), и это остаётся невидимым для команды от слова “совсем”. При этом часть с документированием требований (то, что, собственно, ярко видимо для команды) остаётся в просадке за счет многих факторов, но в основном по незнанию того, как оно может быть иным. Общий посыл, который словили: “Документация — полное гуано, брезгуем ей пользоваться, приходится постоянно спрашивать.” Плюс вскрылось, что техническая часть у аналитика страдает. А точнее её практически нет, что также влияет на то, что команда едва смотрит в сторону БА на встречах. Такое, кстати, я описывал вот тут.
4) Точечных решений было много, но ключевые такие:
- Построили план по приведению документации в порядок: перенос в Confluence, построение структуры, работа с требованиями к данным, НФТ и пр. В AS IS была фактически только постановка задач в Jira в относительно свободном формате. Те же девелоперы, которые участвовали в опросе, на примере прототипа сказали, что огонь огненный. Для этого, правда, серьёзно пришлось подтянуть теорию/практику по тому, какими бывают требования, как с ними работать и документировать, в частности.
- Построили планы на техническую прокачку. Будем наблюдать, как это повлияет на самоощущение от работы и восприятие участия аналитика со стороны.
Итоговые мысли: на мой взгляд, корень проблем тут в том, что аналитик начал работать по принципу “разберусь в процессе” — без качественной теоретической хотя бы подготовки. Я вижу большую ценность в грамотно структурированной теории в голове, о чем также не раз тут писал — не зная, как оно должно быть “по учебнику” и какие вариации могут быть на практике, сложно видеть недостатки собственных процессов. Да, можно учиться и на ходу, но только звезды могут сойтись как удачно (ментор на работе научит; теория выведется, причем правильно, из практики “наощупь”), так и не очень (потеря репутации в команде, негативное влияние на проект, сильно ограниченная применимость вне текущего места работы). Конечно, лучше поздно, чем никогда, и все эти проблемы решаемы, но не покидает мысль, что путь изначально мог быть более правильным и менее болезненным.
🔥21👍1🫡1
Сегодня поговорим о user stories (US) и частых ошибках при их проработке (#23). Я затрагивал некоторые в предыдущих постах (тут и тут), но надежный как швейцарские час план подразумевает посвященный этому отдельный пост. При всем моем стремлении сделать это вкратце, заметка, скорее всего, в очередной раз задавит объемом: ну извините — как вы давно поняли, за форматом инстапостов не сюда 😊
1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.
Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.
2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».
Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.
3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.
1. US не отражают эволюцию продукта. Такое часто наблюдается, когда аналитик переходит в agile из традиционных подходов. Аналитик берет планируемую систему, нарезает ее на доски, и они становятся единицами скоупа, причем сложив эти доски воедино выходит полный статичный срез системы на какой-то момент времени. Что не учтено в этом, так это то, что US используются, как правило, в agile-разработке, которой свойственны короткие итерации и постоянная эволюция системы от MVP-самоката до космического корабля — это дает поэтапную проверку того, что мы делаем нужные вещи и быструю обратную связь от стейкхолдеров.
Как избегать: внимательно изучить SPIDR (подход к декомпозиции US) и всегда держать в голове, что подход «начинаем с малого и постепенно улучшаем» к любой функциональности может быть выигрышным для проекта (конечно, если подобное — в ногу с видением заказчика).
Например, у вас с заказчиком может быть вполне себе огненное видение фичи «Отправить письмо» для почтового клиента, который призван втоптать Outlook в грязь. И тут целесообразным может являться не кушать этот кусок целиком и сразу (хотя, если подумать, чем не фича или юз кейс сам по себе?), а разбить по Paths и Data из SPIDR, чтобы поставлять это постепенно: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы и пр. — это разные истории в таком подходе.
2. Затронутый недавно в чате момент: нарезка «торта» по горизонтали, а не по вертикали. Да, user story — это постановка задачи (об этом детальнее поговорим в другом пункте), но это постановка задачи команде, а не ее отдельным ролям. User Story — это user (!) story. Это прирост функциональности, который несет ценность пользователям (может, кстати, и иным стейкхолдерам, а может — и прирост НЕфункциональности, но это уже полезные порой извращения за рамками темы). US — это не кусок БД или кода, который нужен для будущих свершений и который пользователи не заметят. Называйте такие куски кода тасками, спайками и пр., но краеугольным камнем бэклога являются полноценные куски торта, затрагивающие все его слои и несущие ценность для «едоков».
Как избегать: смотреть на US с описанной выше позиции и не дробить US на задачи отдельным исполнителям — команда сделает это без вас как аналитиков. Не работать с такими историями, как, например, БД для писем, UI для писем с мобилок, Структура микросервисов для отправки и т. п. Для юзера есть только Отправка письма, которую можно (и, скорее всего, стоит) разбить по примеру в пункте выше, а не на технические задачи фронтенду, бэкенду, DBA, дизайнеру и пр., называя их при этом все так же user stories.
3. «Большие» US. Все мы, надеюсь, в курсе про INVEST и Small в нем. И все равно зачастую не особо стремимся «декомпозировать, пока декомпозируется». Фишка в том, что с небольшими задачами команде обычно легче работать (до разумной степени, естественно), а US, еще раз напомню, — постановка задачи. Т. е. помимо эволюции продукта (пункт 1 выше) «дробление» US, скорее всего, облегчит команде планирование и контроль в рамках проекта.
👍8❤🔥1❤1
Как избегать: если абстрагироваться от «процессы везде разные», то за дефолтный подход рекомендую взять следующий:
1) Декомпозируйте US до разумного максимума — дробите, пока сохраняется ценность в кусках для пользователей, но с учетом имеющегося у вас опыта оценки того, что такое эти истории для команды разработки в плане эффортов. Тот же самый пример: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы — так я как аналитик могу разбить исходную историю, и каждый из этих кусков даст юзерам новую ценность в сравнении с тем, что было до их поставки.
2) Согласуйте с заказчиком/PO/любым лицом, кто является для вас ЛПР для бэклога, ок ли такая разбивка. Это может быть объединено с первым пунктом, если вы делаете эту работу совместно. Например, заказчик сомневается в том, что имеет смысл разделять CC и BCC — либо мы даем юзерам все сразу, либо нифига не даем. Ок, будем иметь в виду, что это либо одна история, либо две (для удобства разработки), но обязательно в одной итерации.
3) Несите получившиеся истории команде на refinement и по факту обратной связи корректируйте декомпозицию (т. е. снова split/merge, если нужно). Например, команда сказала, что CC и BCC надо объединить — это крайне схожая работа и делить это на две задачи смысла мало. Замечательно, учли фидбэк всех ЗЛ, а потому объединим в одну US.
4 и 5. Нет ценности или ценность-тавтология + абстрактный «пользователь». Про «нет ценности», думаю, понятно, т. к. первое, что мы узнаем про US, — это три компонента их statement/title. И пользу несет не столько описанная ценность на бумаге, сколько ментальное упражнение при ее формулировке — иногда вы или заказчик придете к тому, что ценность не получается сформулировать именно потому, что ее нет, и нафиг тогда эту историю.
Чаще встречается бесполезно или абстрактно сформулированная ценность. И тут же я затрону еще одну проблему, которая часто идет в связке — абстрактный пользователь.
Примеры: Как пользователь я хочу заказать услугу, чтобы осуществить заказ услуги; Как пользователь я хочу просмотреть каталог услуг, чтобы получить нужную мне информацию.
Что тут не так? В первом случае это «хочу заюзать функциональность X, чтобы заюзать функциональность X». А в чем, собственно, потребность данной категории пользователей? Если мы грамотно используем персоны (техника сегментации пользователей), то история может превратиться в нечто типа «Как одинокий работающий мужчина, я хочу заказать услугу уборки на дому, чтобы не тратить время на неинтересную мне уборку».
Во втором случае ценность абстрактна. Логично, да, что человеку нужна информация, но в чем мотивация/ценность этой информации? «Как человек, ищущий обучение БА, я хочу просмотреть каталог курсов, чтобы выбрать подходящее моим потребностям обучение». Тут мы также эмпатируем, примеряем на себя ситуацию этого человека и понимаем (или выдвигаем гипотезу), для чего конкретно человек будет пользовать функциональность. Это понимание может оказать огромное влияние на то, какие еще US мы дадим в системе именно этим людям и как построим их UX в рамках этих US — т. е. мы будем делать продукт для человека, ищущего обучение по БА, а не для непонятной нам абстракции «пользователь» с неизвестной мотивацией (ну пришел на сайт и пришел — хз, что ему там нужно).
Как избегать:
1) Избегайте, по возможности, «пользователей». Если не получается выделить роли (что вполне может быть актуальным для масс-продуктов), рассмотрите технику персон. Это всяко будет бОльшее погружение в ценности и потребности будущих пользователей, чем анализ их в виде безликой массы.
2) Узнавайте/обдумывайте действительную ценность/мотивацию US для целевой категории. Не для галочки, чтобы закрыть третий компонент абы было «по книжке», а для того, чтобы продукт был ориентирован на конкретных людей и закрывал их конкретные актуальные потребности.
1) Декомпозируйте US до разумного максимума — дробите, пока сохраняется ценность в кусках для пользователей, но с учетом имеющегося у вас опыта оценки того, что такое эти истории для команды разработки в плане эффортов. Тот же самый пример: Отправка письма в базовом варианте, Указание СС, Указание BCC, Прикрепление файлов, Проверка заполненности темы — так я как аналитик могу разбить исходную историю, и каждый из этих кусков даст юзерам новую ценность в сравнении с тем, что было до их поставки.
2) Согласуйте с заказчиком/PO/любым лицом, кто является для вас ЛПР для бэклога, ок ли такая разбивка. Это может быть объединено с первым пунктом, если вы делаете эту работу совместно. Например, заказчик сомневается в том, что имеет смысл разделять CC и BCC — либо мы даем юзерам все сразу, либо нифига не даем. Ок, будем иметь в виду, что это либо одна история, либо две (для удобства разработки), но обязательно в одной итерации.
3) Несите получившиеся истории команде на refinement и по факту обратной связи корректируйте декомпозицию (т. е. снова split/merge, если нужно). Например, команда сказала, что CC и BCC надо объединить — это крайне схожая работа и делить это на две задачи смысла мало. Замечательно, учли фидбэк всех ЗЛ, а потому объединим в одну US.
4 и 5. Нет ценности или ценность-тавтология + абстрактный «пользователь». Про «нет ценности», думаю, понятно, т. к. первое, что мы узнаем про US, — это три компонента их statement/title. И пользу несет не столько описанная ценность на бумаге, сколько ментальное упражнение при ее формулировке — иногда вы или заказчик придете к тому, что ценность не получается сформулировать именно потому, что ее нет, и нафиг тогда эту историю.
Чаще встречается бесполезно или абстрактно сформулированная ценность. И тут же я затрону еще одну проблему, которая часто идет в связке — абстрактный пользователь.
Примеры: Как пользователь я хочу заказать услугу, чтобы осуществить заказ услуги; Как пользователь я хочу просмотреть каталог услуг, чтобы получить нужную мне информацию.
Что тут не так? В первом случае это «хочу заюзать функциональность X, чтобы заюзать функциональность X». А в чем, собственно, потребность данной категории пользователей? Если мы грамотно используем персоны (техника сегментации пользователей), то история может превратиться в нечто типа «Как одинокий работающий мужчина, я хочу заказать услугу уборки на дому, чтобы не тратить время на неинтересную мне уборку».
Во втором случае ценность абстрактна. Логично, да, что человеку нужна информация, но в чем мотивация/ценность этой информации? «Как человек, ищущий обучение БА, я хочу просмотреть каталог курсов, чтобы выбрать подходящее моим потребностям обучение». Тут мы также эмпатируем, примеряем на себя ситуацию этого человека и понимаем (или выдвигаем гипотезу), для чего конкретно человек будет пользовать функциональность. Это понимание может оказать огромное влияние на то, какие еще US мы дадим в системе именно этим людям и как построим их UX в рамках этих US — т. е. мы будем делать продукт для человека, ищущего обучение по БА, а не для непонятной нам абстракции «пользователь» с неизвестной мотивацией (ну пришел на сайт и пришел — хз, что ему там нужно).
Как избегать:
1) Избегайте, по возможности, «пользователей». Если не получается выделить роли (что вполне может быть актуальным для масс-продуктов), рассмотрите технику персон. Это всяко будет бОльшее погружение в ценности и потребности будущих пользователей, чем анализ их в виде безликой массы.
2) Узнавайте/обдумывайте действительную ценность/мотивацию US для целевой категории. Не для галочки, чтобы закрыть третий компонент абы было «по книжке», а для того, чтобы продукт был ориентирован на конкретных людей и закрывал их конкретные актуальные потребности.
👍2❤1🔥1
6. Нарушение границ US в критериях приемки.
Критерии приемки — это требования, детализирующие US, которые команде необходимо реализовать. То есть еще раз: то, что описано в КП, это инструкция к разработке в контексте именно данной US. Иная их трактовка может сбивать читателей с толку, если не согласована заранее.
Пример: US «Написать письмо» и ее КП:
1) Находясь в папке «Входящие», я вижу список полученных мной и неотсортированных по иным папкам писем.
2) Я могу отсортировать письма по теме.
3) Я могу открыть создание нового письма.
1 и 2 — это не часть данной истории. Это КП о просмотре писем и их сортировке. Этим КП не место в истории «Написать письмо». История должна начинаться с «Находясь в папке «Входящие», я могу открыть создание нового письма». Именно это требование будут реализовывать разработчики, расширяя продукт с некоего AS IS состояния до TO BE, в котором для пользователей теперь появится создание писем.
Как избегать: фактически, это уже описано — понять, что такое критерии приемки, и рассматривать их именно с этой позиции.
7. Привязка к UI, когда это вредит. Это частный случай нарушения Negotiable в INVEST (при условии, что за UI отвечаете не вы) и более общего «не лезь не в свой огород».
Когда мы говорим, что US должна быть Negotiable, мы имеем в виду, что на команду не должны быть наложены лишние ограничения, т. к. они ценные союзники в выработке решения и его деталей. Если вы что-то закладываете в требования (КП), то допускайте, что а) некоторые вещи — в целом вне вашей компетенции на проекте и не стоит в них вообще лезть в контексте требований (например, структура БД или технический алгоритм взаимодействия двух сервисов — ну то есть серьезно, это ваша часть работы и в команде нет людей, руки которые более прямо заточены на это?) б) заложенные КП не высечены в камне: а точнее, вы должны понимать, что в них является не обсуждаемыми требованиями, а что — решением, открытым к альтернативным идеям. И часто этим самым моментом является как раз UI.
Как избегать:
1) Прочитать вот эту заметку 😊
2) Определить, кто в команде занимается проектированием UI. И я имею в виду именно проектирование (формы, контролы, их типы, схематичное расположение, навигационная схема), а не визуальный дизайн (шрифты, цвета, попиксельное расположение, конкретные картинки и пр.)
3) Если это не вы, то не затрагивайте UI в КП для US:
«Я могу открыть создание нового письма», а не «Я могу нажать на кнопку «Создать письмо».
«Когда письмо успешно отправлено, система отображает мне список входящих писем», а не «Система перенаправляет меня на страницу «Входящие».
4) Если вы тот человек, который проектирует UI, игнорируйте описанное в этом пункте и пишите требования так, как привыкли 😊
8. Игнорирование short name для US.
Мелочь, которая, скорее, для удобства. Не раз замечал, что для многих по какой-то причине US — это полная формулировка (statement/title) из трех компонентов. И по-другому ссылаться на такую US люди не могут, ибо учебники гласят, что за отсутствие какого-либо из компонентов вас низвергнут в ад. Но не все понимают, что формулировка не равна названию. Отсюда и куча лишних слов в обсуждении истории с какими-либо стейкхолдерами.
Как избегать: понять, что у US кроме формулировки есть короткое имя/название, аналогичное фичам и юз кейсам, и использовать в обсуждениях и артефактах (например, в User Story Map) именно его. Примеры названий историй я не раз выше использовал и ссылался на истории именно по названиям, а не по «Как пользователь, я хочу написать письмо, чтобы…»
Критерии приемки — это требования, детализирующие US, которые команде необходимо реализовать. То есть еще раз: то, что описано в КП, это инструкция к разработке в контексте именно данной US. Иная их трактовка может сбивать читателей с толку, если не согласована заранее.
Пример: US «Написать письмо» и ее КП:
1) Находясь в папке «Входящие», я вижу список полученных мной и неотсортированных по иным папкам писем.
2) Я могу отсортировать письма по теме.
3) Я могу открыть создание нового письма.
1 и 2 — это не часть данной истории. Это КП о просмотре писем и их сортировке. Этим КП не место в истории «Написать письмо». История должна начинаться с «Находясь в папке «Входящие», я могу открыть создание нового письма». Именно это требование будут реализовывать разработчики, расширяя продукт с некоего AS IS состояния до TO BE, в котором для пользователей теперь появится создание писем.
Как избегать: фактически, это уже описано — понять, что такое критерии приемки, и рассматривать их именно с этой позиции.
7. Привязка к UI, когда это вредит. Это частный случай нарушения Negotiable в INVEST (при условии, что за UI отвечаете не вы) и более общего «не лезь не в свой огород».
Когда мы говорим, что US должна быть Negotiable, мы имеем в виду, что на команду не должны быть наложены лишние ограничения, т. к. они ценные союзники в выработке решения и его деталей. Если вы что-то закладываете в требования (КП), то допускайте, что а) некоторые вещи — в целом вне вашей компетенции на проекте и не стоит в них вообще лезть в контексте требований (например, структура БД или технический алгоритм взаимодействия двух сервисов — ну то есть серьезно, это ваша часть работы и в команде нет людей, руки которые более прямо заточены на это?) б) заложенные КП не высечены в камне: а точнее, вы должны понимать, что в них является не обсуждаемыми требованиями, а что — решением, открытым к альтернативным идеям. И часто этим самым моментом является как раз UI.
Как избегать:
1) Прочитать вот эту заметку 😊
2) Определить, кто в команде занимается проектированием UI. И я имею в виду именно проектирование (формы, контролы, их типы, схематичное расположение, навигационная схема), а не визуальный дизайн (шрифты, цвета, попиксельное расположение, конкретные картинки и пр.)
3) Если это не вы, то не затрагивайте UI в КП для US:
«Я могу открыть создание нового письма», а не «Я могу нажать на кнопку «Создать письмо».
«Когда письмо успешно отправлено, система отображает мне список входящих писем», а не «Система перенаправляет меня на страницу «Входящие».
4) Если вы тот человек, который проектирует UI, игнорируйте описанное в этом пункте и пишите требования так, как привыкли 😊
8. Игнорирование short name для US.
Мелочь, которая, скорее, для удобства. Не раз замечал, что для многих по какой-то причине US — это полная формулировка (statement/title) из трех компонентов. И по-другому ссылаться на такую US люди не могут, ибо учебники гласят, что за отсутствие какого-либо из компонентов вас низвергнут в ад. Но не все понимают, что формулировка не равна названию. Отсюда и куча лишних слов в обсуждении истории с какими-либо стейкхолдерами.
Как избегать: понять, что у US кроме формулировки есть короткое имя/название, аналогичное фичам и юз кейсам, и использовать в обсуждениях и артефактах (например, в User Story Map) именно его. Примеры названий историй я не раз выше использовал и ссылался на истории именно по названиям, а не по «Как пользователь, я хочу написать письмо, чтобы…»
👍3❤2
9. Чрезмерная детализация на старте. Спорный момент, на который сильно влияет то, как у вас построены процессы, поэтому трактуйте это как одну из best practices, которые стоит рассмотреть и оценить полезность в контексте именно ваших процессов. Agile свойственна постепенная проработка требований — в первую очередь, чтобы не делать лишнюю работу с риском ее бесполезности.
Пример: вы как истинный перфекционист сели и описали КП для всех US в вашей карте историй на 5 баллов: каждый негативный сценарий; сообщения и проверки во всех ситуациях; то, как система должна реагировать на юзера в полнолуние в високосные годы. Это то, чему нас учили в контексте написания спек, не так ли? Но есть нюанс: agile открыт к изменениям и построен, в целом, на этом. Представьте такие (абсолютно нормальные, стоит заметить) ситуации: через пару дней история выброшена на помойку по инициативе заказчика; после приоритизации история опустилась на дно бэклога aka сделаем через пару лет (что = не сделаем никогда); команда на refinement предложила иные решения или вообще похерила то поведение, которое вы описывали, ибо не юзабельно, дорого или технически невозможно. Все это мало того, что не есть эффективное использование вашего времени, так еще и затронет ваше эго и приведет к ненужным страданиям.
Как избегать: найти точку, в которой ваши эффорты будут just enough исходя из контекста. Есть agile-команды, в которых именно так и поставлен акцент и исходя из этого продуманы процессы постепенной проработки требований. Например, 1) вы быстро на глаз накидываете ключевые КП для всех историй в обозримые пару месяцев разработки, чтобы было что обсуждать с заказчиком и на что получать его первичный фидбэк, 2) вы дорабатываете КП на плюс условные 30% качества для историй в верхней части бэклога и несете их на refinement, 3) вы дорабатываете истории после refinement на базе выработанных решений, 4) вы дорабатываете истории еще на 20% после планнинга, 5) остатки вы дописываете в процессе реализации US, по мере обращения к вам исполнителей. Процесс не должен быть именно таким, но примерьте эту концепцию на свою ситуацию — вероятно, увидите возможность более рационального использования своего и стейкхолдеров времени.
Пример: вы как истинный перфекционист сели и описали КП для всех US в вашей карте историй на 5 баллов: каждый негативный сценарий; сообщения и проверки во всех ситуациях; то, как система должна реагировать на юзера в полнолуние в високосные годы. Это то, чему нас учили в контексте написания спек, не так ли? Но есть нюанс: agile открыт к изменениям и построен, в целом, на этом. Представьте такие (абсолютно нормальные, стоит заметить) ситуации: через пару дней история выброшена на помойку по инициативе заказчика; после приоритизации история опустилась на дно бэклога aka сделаем через пару лет (что = не сделаем никогда); команда на refinement предложила иные решения или вообще похерила то поведение, которое вы описывали, ибо не юзабельно, дорого или технически невозможно. Все это мало того, что не есть эффективное использование вашего времени, так еще и затронет ваше эго и приведет к ненужным страданиям.
Как избегать: найти точку, в которой ваши эффорты будут just enough исходя из контекста. Есть agile-команды, в которых именно так и поставлен акцент и исходя из этого продуманы процессы постепенной проработки требований. Например, 1) вы быстро на глаз накидываете ключевые КП для всех историй в обозримые пару месяцев разработки, чтобы было что обсуждать с заказчиком и на что получать его первичный фидбэк, 2) вы дорабатываете КП на плюс условные 30% качества для историй в верхней части бэклога и несете их на refinement, 3) вы дорабатываете истории после refinement на базе выработанных решений, 4) вы дорабатываете истории еще на 20% после планнинга, 5) остатки вы дописываете в процессе реализации US, по мере обращения к вам исполнителей. Процесс не должен быть именно таким, но примерьте эту концепцию на свою ситуацию — вероятно, увидите возможность более рационального использования своего и стейкхолдеров времени.
👍3❤2
10. База знаний вместо постановки задачи. Не раз уже упомянутая тема в канале, и я еще раз отошлю к замечательному докладу (на мой взгляд, must see для всех, дабы понимать упомянутые концепции, даже если вы с US не работаете): https://www.youtube.com/watch?v=qpwcE1rsBNg
Этот пункт, как и предыдущий, сильно зависит от ваших процессов — я лишь упомяну его в контексте «классического» взгляда на US по умолчанию.
В чем роль US на проекте? US — это ценный инкремент продукта (дополнение/изменение в продукте), плюс механизм планирования и контроля проекта и его итераций ("в спринт пойдут вот эти вот US, вот как мы их оценим, вот кто будет каждой заниматься" и пр.).
Что такое ведение базы знаний (спецификации) в виде US? Вы делаете US «Отправить письмо», отдаете в разработку, но в новом спринте заказчик хочет добавить сюда аттачмент файлов. Как вы поступаете, трактуя US как спецификацию/базу знаний? Обновляете историю до версии, условно, 2, дополняя КП требованиями к тому, как должен происходить аттачмент.
Что тут не так? Все так, если вы хотите вести актуализируемую базу знаний по системе. Однако, а в чем полезный инкремент для системы? В кусочке истории, который явным образом не выделен? Как выполнить оценить историю, как отдать US на разработку и тестирование? Как описать DoD (definition of done) для US, если US — это не сделанный в рамках спринта кусок, а актуализированная и усложненная US из прошлого? Вам придется дополнять это костылями, которые все равно введут новый термин и будут служить постановкой задачи вместо US — например, это привязанные к US задачи, которые в описанных процессах займут место US.
Что такое трактовка US в виде постановки задачи? Была US «Создание письма». Спринт закончился, US принята, DoD выполнен — US «выброшена» (осталась в анналах системы документации). Заказчик хочет теперь аттачменты? Ок, это новая US («Аттачменты файлов») и именно она фигурирует в верхушке бэклога как полезный инкремент продукта, именно ее будут планировать в спринты, оценивать, обсуждать, брать члены команды в работу и закрывать по DoD. И в этом и есть best practice по работе с историями.
В чем недостаток такого подхода? Если пользоваться только US как контейнерами требований, то вы остаетесь без базы знаний. Хорошая новость: она не всегда и нужна. Вам может казаться, что без нее не обойтись, но это только на первый взгляд. Большое количество проектов не требуют базы знаний в виде документации или же вполне допускают, что эффорты, которые будут сэкономлены на ее отсутствии с лихвой покроют ситуации, когда надо раскопать, как там сейчас работает какой-либо кусок. А иногда и комменты к коде или грамотная структура US в Confluence или ином месте (не в Jira, нет 😊) облегчат закрытие задач, стоящих перед актуализируемой базой знаний.
Плохая новость: иногда она таки нужна (часто меняются люди в команде, сложная логика системы, большие длительность и объемы проекта). И в таком случае нужно искать подход к тому, как сделать и то, и другое: и базу знаний вести, и задачи ставить команде. Ну или же думать, какими словами обозвать и в каких единицах выполнять оба эти процесса.
Этот пункт, как и предыдущий, сильно зависит от ваших процессов — я лишь упомяну его в контексте «классического» взгляда на US по умолчанию.
В чем роль US на проекте? US — это ценный инкремент продукта (дополнение/изменение в продукте), плюс механизм планирования и контроля проекта и его итераций ("в спринт пойдут вот эти вот US, вот как мы их оценим, вот кто будет каждой заниматься" и пр.).
Что такое ведение базы знаний (спецификации) в виде US? Вы делаете US «Отправить письмо», отдаете в разработку, но в новом спринте заказчик хочет добавить сюда аттачмент файлов. Как вы поступаете, трактуя US как спецификацию/базу знаний? Обновляете историю до версии, условно, 2, дополняя КП требованиями к тому, как должен происходить аттачмент.
Что тут не так? Все так, если вы хотите вести актуализируемую базу знаний по системе. Однако, а в чем полезный инкремент для системы? В кусочке истории, который явным образом не выделен? Как выполнить оценить историю, как отдать US на разработку и тестирование? Как описать DoD (definition of done) для US, если US — это не сделанный в рамках спринта кусок, а актуализированная и усложненная US из прошлого? Вам придется дополнять это костылями, которые все равно введут новый термин и будут служить постановкой задачи вместо US — например, это привязанные к US задачи, которые в описанных процессах займут место US.
Что такое трактовка US в виде постановки задачи? Была US «Создание письма». Спринт закончился, US принята, DoD выполнен — US «выброшена» (осталась в анналах системы документации). Заказчик хочет теперь аттачменты? Ок, это новая US («Аттачменты файлов») и именно она фигурирует в верхушке бэклога как полезный инкремент продукта, именно ее будут планировать в спринты, оценивать, обсуждать, брать члены команды в работу и закрывать по DoD. И в этом и есть best practice по работе с историями.
В чем недостаток такого подхода? Если пользоваться только US как контейнерами требований, то вы остаетесь без базы знаний. Хорошая новость: она не всегда и нужна. Вам может казаться, что без нее не обойтись, но это только на первый взгляд. Большое количество проектов не требуют базы знаний в виде документации или же вполне допускают, что эффорты, которые будут сэкономлены на ее отсутствии с лихвой покроют ситуации, когда надо раскопать, как там сейчас работает какой-либо кусок. А иногда и комменты к коде или грамотная структура US в Confluence или ином месте (не в Jira, нет 😊) облегчат закрытие задач, стоящих перед актуализируемой базой знаний.
Плохая новость: иногда она таки нужна (часто меняются люди в команде, сложная логика системы, большие длительность и объемы проекта). И в таком случае нужно искать подход к тому, как сделать и то, и другое: и базу знаний вести, и задачи ставить команде. Ну или же думать, какими словами обозвать и в каких единицах выполнять оба эти процесса.
❤5🔥2❤🔥1
Привет всем!
Заметка о такой огненной штуке, как Impact Map, с примером, разбором и советами: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i
Заметка о такой огненной штуке, как Impact Map, с примером, разбором и советами: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i
shesterov.by
Impact Map и User Story Map: как быстро и сердито проработать скоуп (ч. 1)
Связка из двух отличных agile-техник для проработки скоупа решения. В первой части обсуждается Impact Map на примере и то, как применять эту технику на практике.
❤12🔥1🍓1
Ещё несколько занимательных статей на почитать:
Want to Communicate Effectively at Work? Eliminate These 5 Cognitive Distortions (https://betterprogramming.pub/want-to-communicate-effectively-at-work-eliminate-these-5-cognitive-distortions-679caa76cd2a): в продолжение темы о когнитивных искажениях, на этот раз в контексте коммуникаций. Интересно, полезно и познавательно.
Про OKR и Гарри Поттера (https://www.linkedin.com/posts/kirakuzmenko_%D0%B3%D0%B0%D1%80%D1%80%D0%B8-%D0%BF%D0%BE%D1%82%D1%82%D0%B5%D1%80-%D0%B8-okr-ugcPost-7196081864183341056-s_--): совсем не уверен насчёт полезности, плюс заметки со словом OKR заставляют мой глаз истерически дёргаться, но кайф тут именно в примере.
Top 10 Phrases To Include In Your Elevator Pitch (https://english4it.medium.com/top-10-phrases-to-include-in-your-elevator-pitch-8e177bcad5a3): от все того же классного канала про фразы, которые помогут звучать более модно. Огонь, как обычно.
Want to Communicate Effectively at Work? Eliminate These 5 Cognitive Distortions (https://betterprogramming.pub/want-to-communicate-effectively-at-work-eliminate-these-5-cognitive-distortions-679caa76cd2a): в продолжение темы о когнитивных искажениях, на этот раз в контексте коммуникаций. Интересно, полезно и познавательно.
Про OKR и Гарри Поттера (https://www.linkedin.com/posts/kirakuzmenko_%D0%B3%D0%B0%D1%80%D1%80%D0%B8-%D0%BF%D0%BE%D1%82%D1%82%D0%B5%D1%80-%D0%B8-okr-ugcPost-7196081864183341056-s_--): совсем не уверен насчёт полезности, плюс заметки со словом OKR заставляют мой глаз истерически дёргаться, но кайф тут именно в примере.
Top 10 Phrases To Include In Your Elevator Pitch (https://english4it.medium.com/top-10-phrases-to-include-in-your-elevator-pitch-8e177bcad5a3): от все того же классного канала про фразы, которые помогут звучать более модно. Огонь, как обычно.
❤7🔥1
ITMINE: о бизнес-анализе
Привет всем! Заметка о такой огненной штуке, как Impact Map, с примером, разбором и советами: https://shesterov.by/tpost/fzh1lezxp1-impact-map-i-user-story-map-kak-bistro-i
Салют!
Подъехала вторая часть — о User Story Map и том, каким может быть процесс её проработки: https://shesterov.by/tpost/c447fei0c1-impact-map-i-user-story-map-kak-bistro-i
Подъехала вторая часть — о User Story Map и том, каким может быть процесс её проработки: https://shesterov.by/tpost/c447fei0c1-impact-map-i-user-story-map-kak-bistro-i
shesterov.by
Impact Map и User Story Map: как быстро и сердито проработать скоуп (ч. 2)
Вторая часть заметки о двух agile-техниках для проработки скоупа решения. Во второй части обсуждается User Story Map.
❤10🔥1
Пятничное чтиво-рассуждалка о стереотипах в бизнес-анализе (https://shesterov.by/tpost/3dgtau3211-stereotipi-v-biznes-analize).
Если появится желание доказать несостоятельность доводов — не сдерживайтесь, буду рад обсудить 😊
Если появится желание доказать несостоятельность доводов — не сдерживайтесь, буду рад обсудить 😊
shesterov.by
Стереотипы в бизнес-анализе
Моменты, которые не стоит бездумно брать за истину, если хочется войти в и развиваться в IT бизнес-анализе
🔥10❤5🤓1
Салют!
Еще одна подборка статей для нескучных вечеров:
- В очередной раз можно освежить в памяти SPIDR — на этот раз в подаче от Дениса Гобова: https://www.artofba.com/post/spidr-how-t-decompose-user-story. Активно читающие канал вряд ли найдут что-то новое для себя, а для еще не знакомых с этой техникой — отличный повод изучить эту штуку в огненной обертке.
- О том, как проводить Скрам-ретроспективы полезно: https://medium.com/beyond-agile-leadership/3-essential-practices-in-sprint-retrospective-to-unleash-agile-teams-potential-a0e2963c70d9. Так-то об очевидных вещах, но кратко и систематизировано.
И немного о технике (осторожно, внутри статей много букв):
- Understanding the Top 10 Software Architecture Patterns (https://www.designgurus.io/blog/understanding-top-10-software-architecture-patterns): отличный гайд для новичков — рекомендую проштудировать, если принципы построения программных систем совсем в новинку.
- Гайд постарше, но от этого не менее замечательный — What is code (кстати, один из материалов, которые мы рекомендуем в качестве технической подготовки к курсу): https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/. Для тех, кто в IT недавно или как раз планирует путешествие, must read.
Еще одна подборка статей для нескучных вечеров:
- В очередной раз можно освежить в памяти SPIDR — на этот раз в подаче от Дениса Гобова: https://www.artofba.com/post/spidr-how-t-decompose-user-story. Активно читающие канал вряд ли найдут что-то новое для себя, а для еще не знакомых с этой техникой — отличный повод изучить эту штуку в огненной обертке.
- О том, как проводить Скрам-ретроспективы полезно: https://medium.com/beyond-agile-leadership/3-essential-practices-in-sprint-retrospective-to-unleash-agile-teams-potential-a0e2963c70d9. Так-то об очевидных вещах, но кратко и систематизировано.
И немного о технике (осторожно, внутри статей много букв):
- Understanding the Top 10 Software Architecture Patterns (https://www.designgurus.io/blog/understanding-top-10-software-architecture-patterns): отличный гайд для новичков — рекомендую проштудировать, если принципы построения программных систем совсем в новинку.
- Гайд постарше, но от этого не менее замечательный — What is code (кстати, один из материалов, которые мы рекомендуем в качестве технической подготовки к курсу): https://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/. Для тех, кто в IT недавно или как раз планирует путешествие, must read.
🔥12👍1
Всем привет!
Компания Lesta Games ищет Business Analyst в команду Platform в Минске. Выпускники ITMINE очень приветствуются 😊
Подразделение Platform занимается разработкой и оперированием общих сервисов для игр компании. BA будет работать в отдельном стриме с группой сервисов двух направлений и внутренними заказчиками.
Требуемый опыт работы: от 2-х лет.
Формат работы: офисный 5/2 (удаленки и гибрида нет).
Подробнее о вакансии здесь: https://hh.ru/vacancy/98162200
Компания Lesta Games ищет Business Analyst в команду Platform в Минске. Выпускники ITMINE очень приветствуются 😊
Подразделение Platform занимается разработкой и оперированием общих сервисов для игр компании. BA будет работать в отдельном стриме с группой сервисов двух направлений и внутренними заказчиками.
Требуемый опыт работы: от 2-х лет.
Формат работы: офисный 5/2 (удаленки и гибрида нет).
Подробнее о вакансии здесь: https://hh.ru/vacancy/98162200
hh.ru
Вакансия Business Analyst в Минске, работа в компании Леста Игры (вакансия в архиве c 13 июня 2024)
Зарплата: не указана. Минск. Требуемый опыт: 1–3 года. Полная занятость. Дата публикации: 11.06.2024.
👍4🙏1
Приветы!
Снова на почитать:
1. Как работают API-методы на пальцах (отличный материал для тех, кто с API едва сталкивался до этого): https://productcoalition.com/endpoints-inputs-and-outputs-the-essentials-of-api-structure-37fe6228146c
2. Заметка годом постарше о том, для чего нужны аналитики и с чем аналитики сталкиваются в работе. По уровню погружения это также для новичков, если тут таковые имеются. Заметка классно акцентирует внимание как на то, чем полезен БА в команде, так и на ключевых “сложностях”, с которыми они сталкиваются: https://habr.com/ru/companies/surfstudio/articles/594199/
3. О том, как решать конфликты между девелоперами и дизайнерами. Саму тему статья не сказать, что раскрывает, но как описалочка “хорошего” agile-процесса интересно читается: https://medium.com/beyond-agile-leadership/how-to-solve-conflicts-between-developers-and-designers-in-software-projects-da12d2021ccc
Снова на почитать:
1. Как работают API-методы на пальцах (отличный материал для тех, кто с API едва сталкивался до этого): https://productcoalition.com/endpoints-inputs-and-outputs-the-essentials-of-api-structure-37fe6228146c
2. Заметка годом постарше о том, для чего нужны аналитики и с чем аналитики сталкиваются в работе. По уровню погружения это также для новичков, если тут таковые имеются. Заметка классно акцентирует внимание как на то, чем полезен БА в команде, так и на ключевых “сложностях”, с которыми они сталкиваются: https://habr.com/ru/companies/surfstudio/articles/594199/
3. О том, как решать конфликты между девелоперами и дизайнерами. Саму тему статья не сказать, что раскрывает, но как описалочка “хорошего” agile-процесса интересно читается: https://medium.com/beyond-agile-leadership/how-to-solve-conflicts-between-developers-and-designers-in-software-projects-da12d2021ccc
❤16👏2
И лютая полезняшка на закуску: тут автор огненно собрал разные алгоритмы проектирования UI, однако материала для раскопок там многовато. Сделал это, чтобы вам не пришлось😊 Вот лучшие гайды оттуда в копилку:
- Поля ввода/выбора: https://oxygen.doctolib.design/60b411768/p/70925f-choosing-form-components
- Контролы действия:
https://oxygen.doctolib.design/60b411768/p/7334c9-choosing-actions
https://web.archive.org/web/20240118144311/https://canvas.workday.com/patterns/calls-to-action/#tab=usage
- Ошибки: https://oxygen.doctolib.design/60b411768/p/8918c1-designing-better-errors
- Хелпы: https://oxygen.doctolib.design/60b411768/p/704279-choosing-a-help-component
- Уведомляшки: https://web.archive.org/web/20240118144833/https://canvas.workday.com/patterns/notifications/#tab=usage
- Индикаторы загрузки: https://web.archive.org/web/20240118144613/https://canvas.workday.com/patterns/loading/#tab=usage
- Поля ввода/выбора: https://oxygen.doctolib.design/60b411768/p/70925f-choosing-form-components
- Контролы действия:
https://oxygen.doctolib.design/60b411768/p/7334c9-choosing-actions
https://web.archive.org/web/20240118144311/https://canvas.workday.com/patterns/calls-to-action/#tab=usage
- Ошибки: https://oxygen.doctolib.design/60b411768/p/8918c1-designing-better-errors
- Хелпы: https://oxygen.doctolib.design/60b411768/p/704279-choosing-a-help-component
- Уведомляшки: https://web.archive.org/web/20240118144833/https://canvas.workday.com/patterns/notifications/#tab=usage
- Индикаторы загрузки: https://web.archive.org/web/20240118144613/https://canvas.workday.com/patterns/loading/#tab=usage
🔥17⚡1
Может, кого-то заинтересует вакансия, включающая работу с требованиями помимо прочего:
GP Solutions is looking for an Operational Analyst for our Product project!
Location: Belarus, remotely or in the Minsk office
Type: Full-time with shifted work schedule, starting between 10.00-12.00 Minsk time.
https://docs.google.com/document/d/1a1vHkuWocGm66JxWLaK0WT9marrUOZtp6bCyG3EGbsE/edit?usp=sharing
Key Responsibilities:
- Continuously monitor the dashboard for accurate performance metrics.
- Identify and analyze any problems, including data inaccuracies, bugs, and UI/UX issues.
- Collaborate with the development and audit teams to investigate and document the root causes of dashboard issues, examining log files thoroughly when needed.
We look forward to your application! You can contact me on Telegram - https://t.me/HRDaryaK
GP Solutions is looking for an Operational Analyst for our Product project!
Location: Belarus, remotely or in the Minsk office
Type: Full-time with shifted work schedule, starting between 10.00-12.00 Minsk time.
https://docs.google.com/document/d/1a1vHkuWocGm66JxWLaK0WT9marrUOZtp6bCyG3EGbsE/edit?usp=sharing
Key Responsibilities:
- Continuously monitor the dashboard for accurate performance metrics.
- Identify and analyze any problems, including data inaccuracies, bugs, and UI/UX issues.
- Collaborate with the development and audit teams to investigate and document the root causes of dashboard issues, examining log files thoroughly when needed.
We look forward to your application! You can contact me on Telegram - https://t.me/HRDaryaK
👍6
Forwarded from Денис Бесков написал
Плагин https://chatgpt.com/g/g-J0FYgDhN5-software-architect-gpt помогает быстро ответить на ключевые вопросы по программе и получить черновик-описание решения
Фактически это тот самый «генератор ТЗ», святой грааль аналитиков и философский камень)
Архитектуру всё ещё нельзя нагуглить, но можно уже получить черновик за 2 минуты.
Пример того, что можно получить
Фактически это тот самый «генератор ТЗ», святой грааль аналитиков и философский камень)
Архитектуру всё ещё нельзя нагуглить, но можно уже получить черновик за 2 минуты.
Пример того, что можно получить
ChatGPT
ChatGPT - Software Architect GPT
ChatGPT helps you get answers, find inspiration, and be more productive.
❤5🔥3😱1
Салют!
Новая неделя — новая подборка для коротания вечеров:
1. Дядюшка Карл, видимо, почитывает наш канал и чатик, а потому решил также высказаться на тему ведения базы знаний: To Document or Not to Document? That Is the Question. Рекомендуется в виде мотивашки сторонникам чаще забивать на ведение спецификаций, чем нет.
2. Факапы аналитиков: где они обитают? Кейсы Mad Brains. Интересная подборка кейсов, но есть ощущение, что выработанным решениям недостает понимания «хороших» процессов бизнес-анализа (правда, не все эти кейсы связаны с бизнес-анализом в нашем понимании). Можем потренироваться в решении подобных проблем — если кому-нибудь интересно, пишите в комментарии, что предложили бы вы в качестве процессного фикса по факту этих ситуаций.
3. NFR Checklist With Their Testing Approaches. Нефункциональные требования — одна из наиболее сложных областей в работе БА, и либо аналитиками игнорируется, либо вызывает попоболь. По ссылке — неплохой чеклист НФТ, который можно взять себе в копилку. Круто, если бы он был более полон и проработан вглубь, с примерами и метриками, но и так весьма полезно. Может, когда-нибудь руки и мотивация дойдут скомпилировать собственный чеклист из своего и чужого опыта 😊
4-5. 2-Page Login Pattern, And How To Fix It — интересные рассуждения на тему разнесения логина и пароля на две страницы. Новички наберутся умных слов и концепций, а старички смогут почерпнуть идеи для проектирования входа в систему.
И от того же автора: Hidden vs. Disabled In UX. О том, когда контролы скрывать, а когда — дизейблить. Выпускники нашего курса и так должны знать общие рекомендации, а для незнакомых с темой — must read.
Новая неделя — новая подборка для коротания вечеров:
1. Дядюшка Карл, видимо, почитывает наш канал и чатик, а потому решил также высказаться на тему ведения базы знаний: To Document or Not to Document? That Is the Question. Рекомендуется в виде мотивашки сторонникам чаще забивать на ведение спецификаций, чем нет.
2. Факапы аналитиков: где они обитают? Кейсы Mad Brains. Интересная подборка кейсов, но есть ощущение, что выработанным решениям недостает понимания «хороших» процессов бизнес-анализа (правда, не все эти кейсы связаны с бизнес-анализом в нашем понимании). Можем потренироваться в решении подобных проблем — если кому-нибудь интересно, пишите в комментарии, что предложили бы вы в качестве процессного фикса по факту этих ситуаций.
3. NFR Checklist With Their Testing Approaches. Нефункциональные требования — одна из наиболее сложных областей в работе БА, и либо аналитиками игнорируется, либо вызывает попоболь. По ссылке — неплохой чеклист НФТ, который можно взять себе в копилку. Круто, если бы он был более полон и проработан вглубь, с примерами и метриками, но и так весьма полезно. Может, когда-нибудь руки и мотивация дойдут скомпилировать собственный чеклист из своего и чужого опыта 😊
4-5. 2-Page Login Pattern, And How To Fix It — интересные рассуждения на тему разнесения логина и пароля на две страницы. Новички наберутся умных слов и концепций, а старички смогут почерпнуть идеи для проектирования входа в систему.
И от того же автора: Hidden vs. Disabled In UX. О том, когда контролы скрывать, а когда — дизейблить. Выпускники нашего курса и так должны знать общие рекомендации, а для незнакомых с темой — must read.
❤13👍1🔥1
ITMINE: о бизнес-анализе
что предложили бы вы в качестве процессного фикса по факту этих ситуаций
Кстати, любимый пример на тему процессных фиксов: https://youtu.be/VPDJXngp2bM?t=882 (рекомендую посмотреть полностью, но сабж именно с 14:42 по 17:20)
👍1
Если кому-то интересен уклон в работу с процессами, Syberry предлагает выпускникам ITMINE возможность получить практический опыт. Они организуют недельную стажировку для начинающих ВА, по результатам которой заявлена возможность получить оффер:
https://www.syberry.com/careers/vacancy/?id=pe935
https://www.syberry.com/careers/vacancy/?id=pe935
Syberry
Careers at Syberry - Find job in IT | Syberry
Job vacancies at Syberry: from HR Officers to Developers, find your place in IT and advance the industry.
👍7
И (не)много о требованиях и том, как они могут помочь в определении границ работ БА: https://shesterov.by/tpost/8m01i21o31-trebovaniya-vs-ne-trebovaniya-ili-gde-ko
shesterov.by
Требования VS не-требования, или где кончается аналитик
Почему может быть важным нащупать границу между требованиями и смежной информацией и как это сделать.
🔥8