Полезная заметка о декомпозиции user stories (кому-то напоминалка, а кому-то, вероятно, и новые идеи): https://medium.com/@eiki1212/9-patterns-of-user-story-splitting-b1498ecad8dd
Medium
9 Patterns of User Story Splitting
One of the biggest challenges in Agile Product Backlog management is how to split a User Story. While one of the important practices in…
👍4❤2
Ошибка # 6 весьма глобальна по своей сути, а потому заварите чайку и приготовьтесь к длиннопосту — мы поговорим про узкий арсенал техник у аналитика.
Когда такое бывает? Подобное наблюдается, когда у аналитика нет багажа знаний о том, что бывает как-то иначе, нежели в его мире. Т. е. аналитик не читает книжки, не смотрит видосики, не общается в проф. чатиках и не проходит курсики. А если аналитик еще и работает в узкоспецифичной в любом значении среде (процессы, заказчики, культура, домен), то часто это вызывает серьёзный застой. Я собеседовал множество аналитиков с приставкой senior (ну а какую им себе еще поставить, если там, откуда человек пришел, он проработал 7+ лет?), когда в процессе рука так и не смогла отлипнуть от лица. Типовой усредненный кейс в этом контексте: “я звался аналитиком, семь лет работал над перекладыванием инфы из эксельки одного формата в эксельку другого формата, ибо иного и не требовалось от меня; не разу не слышал про какие-то там юзер стори и прочие слова, которые вы тут лопочете; насыпайте мне вагон бабла!” Аналогичное можно сказать и про джунов/миддлов, у которых процесс накопления знаний и кругозора ограничивается сугубо случайно рекомендованными видосами на YouTube (в более печальных случаях — постами в ленте Instagram).
Когда такое бывает? Подобное наблюдается, когда у аналитика нет багажа знаний о том, что бывает как-то иначе, нежели в его мире. Т. е. аналитик не читает книжки, не смотрит видосики, не общается в проф. чатиках и не проходит курсики. А если аналитик еще и работает в узкоспецифичной в любом значении среде (процессы, заказчики, культура, домен), то часто это вызывает серьёзный застой. Я собеседовал множество аналитиков с приставкой senior (ну а какую им себе еще поставить, если там, откуда человек пришел, он проработал 7+ лет?), когда в процессе рука так и не смогла отлипнуть от лица. Типовой усредненный кейс в этом контексте: “я звался аналитиком, семь лет работал над перекладыванием инфы из эксельки одного формата в эксельку другого формата, ибо иного и не требовалось от меня; не разу не слышал про какие-то там юзер стори и прочие слова, которые вы тут лопочете; насыпайте мне вагон бабла!” Аналогичное можно сказать и про джунов/миддлов, у которых процесс накопления знаний и кругозора ограничивается сугубо случайно рекомендованными видосами на YouTube (в более печальных случаях — постами в ленте Instagram).
Подобное ярко заметно не только на интервью, но и в общении — часто их посылы идут в комбинации с постулатом “Зачем нужно обучение и развитие, пфф… Сам разберусь, пока не жаловались.” Речь тут, конечно, не про всех, прошедших подобные пути, — люди часто умеют вполне себе качественно и системно самообучиться и поддерживать свой кругозор и навыки.
А как стоило бы? Нужно понимать, что мощь аналитика — в широте набора техник, которыми он владеет для решения проф. задач и умении составить из них работы на конкретном проекте. В отличие от ряда иных ролей (например, от многих подвидов разработчиков), фишка — не в глубине владения одной из них, а в их наборе. Даже крупная часть BABOK, как вы наверняка знаете, — это глава с большим списком техник, пригодных в той или иной ситуации. И, соответственно, когда приходит полярный лис, аналитик собирает из кирпичиков в своем арсенале план действий, подходящий под конкретный проект.
Давайте попробуем рассмотреть это, вспомнив пять основных областей работы с информацией (или 5 областей работы с требованиями, если чуть более узко, но зато по дядюшке Вигерсу): извлечение, анализ, документирование, проверка, управление.
Начнем с извлечения информации/требований. Вот прилетает к вам заказчик и говорит, что его компании нужно некую систему забабахать для сотрудников.
Что есть в арсенале (и, как следствие, в плане действий) у аналитика, который действует “по наитию”? Потрындеть с заказчиком, вестимо (иногда еще и сугубо письменно — см. предыдущую ошибку).
Что есть у аналитика с багажом подходов? Все известные нам техники извлечения требований: интервью, воркшопы, опросы, наблюдение, анализ интерфейсов, документации, обратная инженерия и пр. Как минимум они есть в виде чеклиста в голове или базе знаний, что уже эпик вин — не обязательно при этом иметь глубокий практический опыт применения каждой из них. И такой аналитик может составить себе “немного иной” план, нежели тупо написать заказчику письмо с посылом “Сыпь в меня требованиями, я внемлю.” Например, такой:
- Согласовать с заказчиком и провести первичный сбор информации с конечных пользователей анкетированием.
- Провести персональные интервью с теми, чьи ответы надо раскрыть и уточнить.
- Изучить документацию на стороне заказчика по вопросам X и Y.
- Провести итоговый воркшоп с заказчиком, главами отделов и лидами своей команды, чтобы донести и обсудить в реальном времени итоги сбора информации и выработать план действий. Что-то подсказывает, что и для проекта, и для самого аналитика вероятность успеха во второй ситуации чуточку повыше.
Рассмотрение того, какие есть бест практики и техники и когда они полезны — это фактически курс по БА, поэтому дальше буду относительно краток.
Анализ информации/требований:
“По наитию” = “Опа, а тут у нас пробел :( Пошёл я обратно к заказчику :(:(” и тому подобные наблюдения, зависящие только от внимательности автора и расстановки планет в небе.
С багажом техник: понимание типов требований и информации по БА и пользование этим как чеклистом для извлечения и анализа полноты извлеченного, понимание характеристик (качеств) требований разных видов и рекомендаций по их обеспечению, знание визуальных моделей разных видов и направленности (а чем с больших сторон мы смоделируем решение, тем больше неполноты/противоречий и прочих проблем мы найдем), специфические техники, в разы облегчающие работу с качеством требований (CRUD, матрицы трассировки, юз кейсы и типы их сценариев, техники приоритизации и пр.). Например, а вы знаете, что такое CRUD/CRUDL? Если нет, то вы даже не представляете, насколько владение 4/5 буквами и умение вспомнить про них в нужный момент может повлиять на полноту прорабатываемых вами требований :)
Документирование информации:
“По наитию” = “А я вот знаю сторьки, знаю Confluence… а большего мне и не надо!” Сюрприз-сюрприз: далеко не всегда и не везде user stories в том формате, который принят лично у вас на проекте (а чаще всего это означает не особо осмысленный рандомный подход к подаче требований, всего-лишь исторически принятый командой),
А как стоило бы? Нужно понимать, что мощь аналитика — в широте набора техник, которыми он владеет для решения проф. задач и умении составить из них работы на конкретном проекте. В отличие от ряда иных ролей (например, от многих подвидов разработчиков), фишка — не в глубине владения одной из них, а в их наборе. Даже крупная часть BABOK, как вы наверняка знаете, — это глава с большим списком техник, пригодных в той или иной ситуации. И, соответственно, когда приходит полярный лис, аналитик собирает из кирпичиков в своем арсенале план действий, подходящий под конкретный проект.
Давайте попробуем рассмотреть это, вспомнив пять основных областей работы с информацией (или 5 областей работы с требованиями, если чуть более узко, но зато по дядюшке Вигерсу): извлечение, анализ, документирование, проверка, управление.
Начнем с извлечения информации/требований. Вот прилетает к вам заказчик и говорит, что его компании нужно некую систему забабахать для сотрудников.
Что есть в арсенале (и, как следствие, в плане действий) у аналитика, который действует “по наитию”? Потрындеть с заказчиком, вестимо (иногда еще и сугубо письменно — см. предыдущую ошибку).
Что есть у аналитика с багажом подходов? Все известные нам техники извлечения требований: интервью, воркшопы, опросы, наблюдение, анализ интерфейсов, документации, обратная инженерия и пр. Как минимум они есть в виде чеклиста в голове или базе знаний, что уже эпик вин — не обязательно при этом иметь глубокий практический опыт применения каждой из них. И такой аналитик может составить себе “немного иной” план, нежели тупо написать заказчику письмо с посылом “Сыпь в меня требованиями, я внемлю.” Например, такой:
- Согласовать с заказчиком и провести первичный сбор информации с конечных пользователей анкетированием.
- Провести персональные интервью с теми, чьи ответы надо раскрыть и уточнить.
- Изучить документацию на стороне заказчика по вопросам X и Y.
- Провести итоговый воркшоп с заказчиком, главами отделов и лидами своей команды, чтобы донести и обсудить в реальном времени итоги сбора информации и выработать план действий. Что-то подсказывает, что и для проекта, и для самого аналитика вероятность успеха во второй ситуации чуточку повыше.
Рассмотрение того, какие есть бест практики и техники и когда они полезны — это фактически курс по БА, поэтому дальше буду относительно краток.
Анализ информации/требований:
“По наитию” = “Опа, а тут у нас пробел :( Пошёл я обратно к заказчику :(:(” и тому подобные наблюдения, зависящие только от внимательности автора и расстановки планет в небе.
С багажом техник: понимание типов требований и информации по БА и пользование этим как чеклистом для извлечения и анализа полноты извлеченного, понимание характеристик (качеств) требований разных видов и рекомендаций по их обеспечению, знание визуальных моделей разных видов и направленности (а чем с больших сторон мы смоделируем решение, тем больше неполноты/противоречий и прочих проблем мы найдем), специфические техники, в разы облегчающие работу с качеством требований (CRUD, матрицы трассировки, юз кейсы и типы их сценариев, техники приоритизации и пр.). Например, а вы знаете, что такое CRUD/CRUDL? Если нет, то вы даже не представляете, насколько владение 4/5 буквами и умение вспомнить про них в нужный момент может повлиять на полноту прорабатываемых вами требований :)
Документирование информации:
“По наитию” = “А я вот знаю сторьки, знаю Confluence… а большего мне и не надо!” Сюрприз-сюрприз: далеко не всегда и не везде user stories в том формате, который принят лично у вас на проекте (а чаще всего это означает не особо осмысленный рандомный подход к подаче требований, всего-лишь исторически принятый командой),
❤8
позволят эффективно донести инфу до стейкхолдеров (и тут будет уместным отметить, что еще и понимание того, кто такие стейкхолдеры и зачем и как их идентифицировать и прорабатывать — также чууууточку увеличивает вероятность успеха вашей работы).
С багажом техник: как минимум знание о и понимание разных видов артефактов и систем хранения информации (V&S, SRS, ТЗ, User Stories, RMS, Confluence и пр.) может помочь вам выбрать нужные гвозди, когда придется думать, чем забить целевые доски. Естественно, это включает в себя и хотя бы базовое понимание того, когда и что уместно и в каких условиях сработает лучше. А представьте теперь, что можно еще и понимать, что и зачем нужно вообще от документирования и хранения информации в разных ситуациях и уметь продумать эти аспекты для проекта (редактирование, чтение, версионирование, история изменений, коллаборативная работа, трассировка, ведение атрибутов требований — да, бизнес-анализ может быть иногда слегка навороченнее, чем механически сторьки писать :))
Проверку и управление информацией пропустим — там тоже есть вполне себе техники-полезняшки, но они не настолько очевидные и наглядные, чтобы донести пойнт ошибки.
Что хочется отметить по итогу:
Часто вижу уверенные заявления вида “У меня во всех ситуациях тупо работает подход X, что вы мне тут усложняете жизнь всякими ругательными словами?” или “Зачем усложнять такую простую работу, как анализ требований? Собери требования, донеси до команды — вот 2-3 подхода, просто делай это, и не надо мне голову забивать всем этим умным булшитом.” Тут важно понимать, что есть большая разница между тем, когда 1) такое исходит от человека, знакомого с большинством бест практик и сделавшим осознанный выбор в сторону любимых подходов (и их адаптации к разным ситуациям), и 2) тем, когда подобное идет от банальной неосведомленности — от людей, незнакомых с тем, что бывают различные проекты, ситуации, культуры и заказчики, а заодно и не осознающих, что практически на каждую ситуацию уже кем-то придуман свой вполне себе работающий велосипед. Да, вы можете забивать одни и те же гвозди одним и тем же молотком, и это может вполне себе работать. Только вот работать работу можно по-разному. Когда вы узнаете об иных подходах, позволяющих сделать то же, но эффективнее с любой позиции (качество, время, эффорты), вы едва ли сделаете себе и проекту хуже. А потому повторим то, с чего начали: мощь аналитика — в широте набора техник, которыми он владеет для решения задач и умении составить из них работы на конкретном проекте. Не замыкайтесь на том, с чем работаете сейчас: читайте правильные книжки, ресурсы, каналы (ага, как этот ;)), проходите хорошее обучение время от времени — в общем, не забрасывайте саморазвитие. А еще лучше — пробуйте по факту всего этого разные техники и подходы — это и контент для резюме, и практический опыт, который позволит собирать все более крутые комбинации техник в будущих проектах.
С багажом техник: как минимум знание о и понимание разных видов артефактов и систем хранения информации (V&S, SRS, ТЗ, User Stories, RMS, Confluence и пр.) может помочь вам выбрать нужные гвозди, когда придется думать, чем забить целевые доски. Естественно, это включает в себя и хотя бы базовое понимание того, когда и что уместно и в каких условиях сработает лучше. А представьте теперь, что можно еще и понимать, что и зачем нужно вообще от документирования и хранения информации в разных ситуациях и уметь продумать эти аспекты для проекта (редактирование, чтение, версионирование, история изменений, коллаборативная работа, трассировка, ведение атрибутов требований — да, бизнес-анализ может быть иногда слегка навороченнее, чем механически сторьки писать :))
Проверку и управление информацией пропустим — там тоже есть вполне себе техники-полезняшки, но они не настолько очевидные и наглядные, чтобы донести пойнт ошибки.
Что хочется отметить по итогу:
Часто вижу уверенные заявления вида “У меня во всех ситуациях тупо работает подход X, что вы мне тут усложняете жизнь всякими ругательными словами?” или “Зачем усложнять такую простую работу, как анализ требований? Собери требования, донеси до команды — вот 2-3 подхода, просто делай это, и не надо мне голову забивать всем этим умным булшитом.” Тут важно понимать, что есть большая разница между тем, когда 1) такое исходит от человека, знакомого с большинством бест практик и сделавшим осознанный выбор в сторону любимых подходов (и их адаптации к разным ситуациям), и 2) тем, когда подобное идет от банальной неосведомленности — от людей, незнакомых с тем, что бывают различные проекты, ситуации, культуры и заказчики, а заодно и не осознающих, что практически на каждую ситуацию уже кем-то придуман свой вполне себе работающий велосипед. Да, вы можете забивать одни и те же гвозди одним и тем же молотком, и это может вполне себе работать. Только вот работать работу можно по-разному. Когда вы узнаете об иных подходах, позволяющих сделать то же, но эффективнее с любой позиции (качество, время, эффорты), вы едва ли сделаете себе и проекту хуже. А потому повторим то, с чего начали: мощь аналитика — в широте набора техник, которыми он владеет для решения задач и умении составить из них работы на конкретном проекте. Не замыкайтесь на том, с чем работаете сейчас: читайте правильные книжки, ресурсы, каналы (ага, как этот ;)), проходите хорошее обучение время от времени — в общем, не забрасывайте саморазвитие. А еще лучше — пробуйте по факту всего этого разные техники и подходы — это и контент для резюме, и практический опыт, который позволит собирать все более крутые комбинации техник в будущих проектах.
❤20
Ошибка #7 — непроговоренные/неявные ожидания. Это нетривиальный момент, потому что далеко не всегда фиксится простым “делай сюда, а туда не делай”. Обычно, чтобы быть аккуратнее с ожиданиями, которые могут вызвать конфликт, нам нужно вначале наступить на эту граблю несколько раз.
Что это означает? У нас есть некая картина мира относительно того, как должен или не должен поступать человек. И редко мы стопаем себя в процессе оценки и пытаемся применить пресловутое критическое мышление, оперируя вместо этого такими категориями, как “Это же очевидно / логично / нормально. Именно поэтому я ожидаю, что должно быть вот так.” Соответственно, и мы, и другие (например, ваша команда или стейкхолдеры со стороны клиента) формируем эти ожидания на базе собственных представлений, часто не задумываясь о том, а с какой, собственно, стати. Давайте на примере пары реальных кейсов:
1) Ситуация, скорее, грустная. Многим этот пример будет знаком, т. к. я часто делюсь им на тренингах. На старте проекта аналитики в команде работали аки пчелки, общаясь с заказчиком и по утрам, и по вечерам, а в особо запущенных случаях еще и ночью. Со временем запал ноулайфера спал, т. к. и проект перешел в фазу саппорта, и аналитики повзрослели. И тут все ярче стала проявляться раздражительность заказчика. Списали это на финансовые проблемы с продажей системы и просто привыкли к этому и регулярным хождениям по минному полю при написании писем. Сам заказчик, при этом, стал локальным мемом, про которых аналитики в курилках часто общаются в духе “Ну как, снова мозг тебе вые(л)?” Так получилось, что спустя пару лет довелось пересечься с заказчиком на одном из корпоративов. И, внезапно, он оказался огненным чуваком, с которым дернуть пивка — кайфовое дело. Соответственно, в процессе сего дела пошел разговор по душам, и всплыла интересная штука: оказывается, то, что аналитики делали вне работы, воспринималось как само собой разумеющееся (часть сервиса), и когда это перестали делать, заказчик подумал, что качество услуг резко снизилось и приобиделся. Как только это было донесено заказчику в личном общении, реакция была вполне ожидаемая: “Епрст, а че вы сразу не сказали? А я тут себе картин негативных нарисовал…”
2) Ситуация, скорее, веселая. Есть профильное сообщество X. Оно делится материалами, проводит мероприятия и всячески по-иному наводит движ. И вот после очередного мероприятия идет анализ обратных связей, среди которых встречается что-то в духе “Все было неплохо, но сильно напрягло отсутствие вегетарианской пиццы на ланче." Немного контекста: сообщество некоммерческое, люди там активничают даже не за еду, мероприятия в плане организации — это порой пара месяцев геморроя с уговариванием людей со всех сторон, у которых часто склонны меняться планы (докладчики, кухня, помещение, финансы и пр.). При этом само посещение мероприятия — либо бесплатное, либо сугубо с компенсацией еды. Соответственно, с одной стороны у нас есть ожидания одного человека (потребителя): “Ну ок, еще один профильный ресурс. Ну лан, посмотрим, че там. И вообще, пусть борются за мое внимание, сообществ много.” (я утрирую и всего-лишь полагаю, что подобное может крутиться в голове человека с подобным фидбэком). С другой стороны, у нас есть мысли человека, который был вовлечен в организацию на протяжении пары месяцев: вначале много мата, а потом “Ну и зачем мне всем этим заниматься? Мы тут стараемся, что-то делаем бесплатно; мало того, что интереса, кроме самого процесса создания чего-то крутого, никакого. А человеку, блин, тут пиццы вегетарианской не хватило на конференции с проф. докладами. Вы там вообще уже “уху” “ели"? После этого у человека наступает демотивация делать нечто подобное впредь. Именно для этой ситуации не факт, что подойдут решения, описанные ниже, но я привел это, чтобы показать, к чему может привести mismatch в ожиданиях, если его а) не осмыслить, б) вероятно, как-то с ним не поработать.
Что с этим делать?
Что это означает? У нас есть некая картина мира относительно того, как должен или не должен поступать человек. И редко мы стопаем себя в процессе оценки и пытаемся применить пресловутое критическое мышление, оперируя вместо этого такими категориями, как “Это же очевидно / логично / нормально. Именно поэтому я ожидаю, что должно быть вот так.” Соответственно, и мы, и другие (например, ваша команда или стейкхолдеры со стороны клиента) формируем эти ожидания на базе собственных представлений, часто не задумываясь о том, а с какой, собственно, стати. Давайте на примере пары реальных кейсов:
1) Ситуация, скорее, грустная. Многим этот пример будет знаком, т. к. я часто делюсь им на тренингах. На старте проекта аналитики в команде работали аки пчелки, общаясь с заказчиком и по утрам, и по вечерам, а в особо запущенных случаях еще и ночью. Со временем запал ноулайфера спал, т. к. и проект перешел в фазу саппорта, и аналитики повзрослели. И тут все ярче стала проявляться раздражительность заказчика. Списали это на финансовые проблемы с продажей системы и просто привыкли к этому и регулярным хождениям по минному полю при написании писем. Сам заказчик, при этом, стал локальным мемом, про которых аналитики в курилках часто общаются в духе “Ну как, снова мозг тебе вые(л)?” Так получилось, что спустя пару лет довелось пересечься с заказчиком на одном из корпоративов. И, внезапно, он оказался огненным чуваком, с которым дернуть пивка — кайфовое дело. Соответственно, в процессе сего дела пошел разговор по душам, и всплыла интересная штука: оказывается, то, что аналитики делали вне работы, воспринималось как само собой разумеющееся (часть сервиса), и когда это перестали делать, заказчик подумал, что качество услуг резко снизилось и приобиделся. Как только это было донесено заказчику в личном общении, реакция была вполне ожидаемая: “Епрст, а че вы сразу не сказали? А я тут себе картин негативных нарисовал…”
2) Ситуация, скорее, веселая. Есть профильное сообщество X. Оно делится материалами, проводит мероприятия и всячески по-иному наводит движ. И вот после очередного мероприятия идет анализ обратных связей, среди которых встречается что-то в духе “Все было неплохо, но сильно напрягло отсутствие вегетарианской пиццы на ланче." Немного контекста: сообщество некоммерческое, люди там активничают даже не за еду, мероприятия в плане организации — это порой пара месяцев геморроя с уговариванием людей со всех сторон, у которых часто склонны меняться планы (докладчики, кухня, помещение, финансы и пр.). При этом само посещение мероприятия — либо бесплатное, либо сугубо с компенсацией еды. Соответственно, с одной стороны у нас есть ожидания одного человека (потребителя): “Ну ок, еще один профильный ресурс. Ну лан, посмотрим, че там. И вообще, пусть борются за мое внимание, сообществ много.” (я утрирую и всего-лишь полагаю, что подобное может крутиться в голове человека с подобным фидбэком). С другой стороны, у нас есть мысли человека, который был вовлечен в организацию на протяжении пары месяцев: вначале много мата, а потом “Ну и зачем мне всем этим заниматься? Мы тут стараемся, что-то делаем бесплатно; мало того, что интереса, кроме самого процесса создания чего-то крутого, никакого. А человеку, блин, тут пиццы вегетарианской не хватило на конференции с проф. докладами. Вы там вообще уже “уху” “ели"? После этого у человека наступает демотивация делать нечто подобное впредь. Именно для этой ситуации не факт, что подойдут решения, описанные ниже, но я привел это, чтобы показать, к чему может привести mismatch в ожиданиях, если его а) не осмыслить, б) вероятно, как-то с ним не поработать.
Что с этим делать?
❤11
Гарантированного практического решения не видится, но можно выделить два пункта, которые могут сократить либо вероятность, либо impact от таких ситуаций (причем как со своей, так и с других сторон):
1) Держать в голове, что это может быть источником проблем и попробовать хоть иногда проактивно подобное упреждать. Попробовать внедрить в практику, что в случае серьезных переговоров (с командой, заказчиком и иными подобными ролями) — например, на старте взаимоотношений (начало взаимодействий с заказчиком, работы в новой команде с девелоперами, тестировщиками и прочими ролями) — актуальным может быть аккуратно проговорить следующее: “Давайте, чтобы не было потом обмана ожиданий, проговорим следующие вещи: … Просто на всякий случай — сделаем неявное явным.”
2) Осваивать техники и подходы, которые касаются подобной проблемы. Из того, что есть в арсенале у БА, это, например:
- План коммуникаций с ЗЛ, суть которого — настроить и синхронизировать взаимные коммуникационные ожидания на старте (”Блин, ну я ж не ожидал, что ты уйдешь в отпуск в середине проекта”; “Ну я не думал, что тебе, чтобы заапрувить спеку, надо 5 дней ее вычитывать. А у нас сроки горят :(”; “Ну кто мог подумать, что если тебе что-то непонятно в требованиях, ты не подойдешь спросить, а сделаешь по собственному разумению”).
- Есть такое понятие, как анализ рисков у БА — это заранее подумать о том, что может пойти не так, и что с этим можно сделать (”Заказчик будет долго отвечать на письма. Заказчик не поймет документ с требованиями. Что я могу сделать уже сейчас, чтобы сократить вероятность/влияние этого?”). Именно на этом этапе у вас в качестве политики по работе с рядом рисков может контекстно всплыть решение “Правильно согласовать взаимные ожидания от работы”.
- Если мы говорим про требования и прочую информацию по БА, то в копилке аналитика есть такое понятие, как assumptions. Крайне полезный инструмент, который помогает лавировать в условиях неопределенности. “Мы полагаем, что вот такое решение будет оптимальным. Assumptions, при этом, следующие (если мы тут неправы, укажи нам на это): 1) систему будут использовать на Северном полюсе в варежках. 2) Юзеры — не ламеры, сами разберутся в трех кнопках без обучения. 3) GPS будет всегда доступен — перебоев не ожидается. Если предположения валидны, то тогда рекомендованное нами решение в силе.”
- А еще тут можно посоветовать (скорее уже как дополнительный фреймворк, который позволит выйти из ряда подобных ситуаций и сделать многие неявные вещи явными) вот такую заметку о том, почему люди могут чего-то не делать: https://habr.com/ru/companies/stratoplan/articles/220793/. Он не раз спасал от поспешных мыслей и реакций из разряда “Ах, он редиска такая! Ну раз ты так, то и я так.”
1) Держать в голове, что это может быть источником проблем и попробовать хоть иногда проактивно подобное упреждать. Попробовать внедрить в практику, что в случае серьезных переговоров (с командой, заказчиком и иными подобными ролями) — например, на старте взаимоотношений (начало взаимодействий с заказчиком, работы в новой команде с девелоперами, тестировщиками и прочими ролями) — актуальным может быть аккуратно проговорить следующее: “Давайте, чтобы не было потом обмана ожиданий, проговорим следующие вещи: … Просто на всякий случай — сделаем неявное явным.”
2) Осваивать техники и подходы, которые касаются подобной проблемы. Из того, что есть в арсенале у БА, это, например:
- План коммуникаций с ЗЛ, суть которого — настроить и синхронизировать взаимные коммуникационные ожидания на старте (”Блин, ну я ж не ожидал, что ты уйдешь в отпуск в середине проекта”; “Ну я не думал, что тебе, чтобы заапрувить спеку, надо 5 дней ее вычитывать. А у нас сроки горят :(”; “Ну кто мог подумать, что если тебе что-то непонятно в требованиях, ты не подойдешь спросить, а сделаешь по собственному разумению”).
- Есть такое понятие, как анализ рисков у БА — это заранее подумать о том, что может пойти не так, и что с этим можно сделать (”Заказчик будет долго отвечать на письма. Заказчик не поймет документ с требованиями. Что я могу сделать уже сейчас, чтобы сократить вероятность/влияние этого?”). Именно на этом этапе у вас в качестве политики по работе с рядом рисков может контекстно всплыть решение “Правильно согласовать взаимные ожидания от работы”.
- Если мы говорим про требования и прочую информацию по БА, то в копилке аналитика есть такое понятие, как assumptions. Крайне полезный инструмент, который помогает лавировать в условиях неопределенности. “Мы полагаем, что вот такое решение будет оптимальным. Assumptions, при этом, следующие (если мы тут неправы, укажи нам на это): 1) систему будут использовать на Северном полюсе в варежках. 2) Юзеры — не ламеры, сами разберутся в трех кнопках без обучения. 3) GPS будет всегда доступен — перебоев не ожидается. Если предположения валидны, то тогда рекомендованное нами решение в силе.”
- А еще тут можно посоветовать (скорее уже как дополнительный фреймворк, который позволит выйти из ряда подобных ситуаций и сделать многие неявные вещи явными) вот такую заметку о том, почему люди могут чего-то не делать: https://habr.com/ru/companies/stratoplan/articles/220793/. Он не раз спасал от поспешных мыслей и реакций из разряда “Ах, он редиска такая! Ну раз ты так, то и я так.”
🔥12👍1
Пятничное и, надеемся, чуть более занимательное чтиво ☺️
Ошибочка #8 в терминологии Максима Дорофеева (замечательный автор книг и тренингов по проектному управлению и самоорганизации) — эффект дырявого стека.
Вообще, личная организация — объемная и интересная тема, и тут много о чем можно поговорить (об инструментах, подходах и прочих фишках, которые этому способствуют). Если интересны заметки и на эту тему, сигнальте. Плюс, если мы ведем речь о софт-скиллах не только аналитика, но любого IT-специалиста и не только IT, есть ряд вещей, которые подразумеваются по умолчанию. Да, о них иногда явно пишут в вакансиях, но даже если не пишут, они точно негласно входят в требования к специалисту. Что основное можно отметить из вещей подобного плана, что для аналитика важно:
- ответственность (вот вы пообещали сделать работу в срок, но профакапили — грустяшка 😞; а если еще и никому проактивно не сказали до дедлайна — совсем печалька 😡)
- самоорганизованность (за полным определением можно сходить в какую-нибудь Википедию; если вкратце, то, например, следить за своими задачами и их сроками — ваша и только ваша ответственность)
- тайм-менеджмент (вы в состоянии сами приоритизировать свои задачи по важности/срочности и действовать, исходя из этого)
- адаптируемость (то бишь вы можете выбрать работающие подходы и морально подстроиться под любые контексты: жесткий/любвеобильный заказчик, сеньорная/начинающая команда, либеральный/не очень менеджмент, адаптивный/предиктивный подход к БА и т. п.)
- командная работа (вы, естественно, можете функционировать как часть команды и способны мириться с тем, что есть и другие мнения и подходы).
Еще раз повторюсь, что в большинстве случаев такие банальные навыки даже не обсуждаются. У вас должно это быть, и точка. Но, естественно, на практике где-то у кого-то бывают пробелы, и наиболее частое из встречающегося, что можно отнести к навыку “Самоорганизованность”, это эффект дырявого стека.
Что это такое? Наверное, картинка от автора покажет это наиболее наглядно: https://infostart.ru/upload/iblock/9c4/9c480c51b7cf7ffd7bdb7c73d44474af.jpg. Слегка перефразируя описанное в книге “Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо”, если человек неспособен вести аккуратный список задач, то весь стек заданий удерживается в голове, к чему она не приспособлена. И все, что в этот стек не помещается, «падает на пол». Грубо говоря, это продалбливание задач/дел, когда их много.
Типовая ошибка джуна (гораздо чаще именно у начинающих это встречается), которой быть не должно:
- Я как БА-менеджер закидываю сотрудника задачами. Или заказчик закидывает аналитика письмами. И добавим сюда условие, что это большой или очень большой поток. Можно даже еще усложнить ситуацию: у сотрудника аврал, попа горит, и все это на пяти проектах, которые он одновременно тянет. Если при этом старые задачи/письма/что угодно “забылись” или “потерялись”, ибо много всего, — это косяк, за который ответственен только исполнитель. И я сейчас не про критичность проблемы, которая может быть разной и в экстремальных условиях даже приемлемой и понятной, а про правильное взятие ответственности на себя. Ну а если это системная проблема (т. е. нет рабочего механизма для подобного, а есть только перегруженная весом проблем голова), то это грусть, и в большинстве случаев я резко не хотел бы дальше работать с этим человеком.
Ошибочка #8 в терминологии Максима Дорофеева (замечательный автор книг и тренингов по проектному управлению и самоорганизации) — эффект дырявого стека.
Вообще, личная организация — объемная и интересная тема, и тут много о чем можно поговорить (об инструментах, подходах и прочих фишках, которые этому способствуют). Если интересны заметки и на эту тему, сигнальте. Плюс, если мы ведем речь о софт-скиллах не только аналитика, но любого IT-специалиста и не только IT, есть ряд вещей, которые подразумеваются по умолчанию. Да, о них иногда явно пишут в вакансиях, но даже если не пишут, они точно негласно входят в требования к специалисту. Что основное можно отметить из вещей подобного плана, что для аналитика важно:
- ответственность (вот вы пообещали сделать работу в срок, но профакапили — грустяшка 😞; а если еще и никому проактивно не сказали до дедлайна — совсем печалька 😡)
- самоорганизованность (за полным определением можно сходить в какую-нибудь Википедию; если вкратце, то, например, следить за своими задачами и их сроками — ваша и только ваша ответственность)
- тайм-менеджмент (вы в состоянии сами приоритизировать свои задачи по важности/срочности и действовать, исходя из этого)
- адаптируемость (то бишь вы можете выбрать работающие подходы и морально подстроиться под любые контексты: жесткий/любвеобильный заказчик, сеньорная/начинающая команда, либеральный/не очень менеджмент, адаптивный/предиктивный подход к БА и т. п.)
- командная работа (вы, естественно, можете функционировать как часть команды и способны мириться с тем, что есть и другие мнения и подходы).
Еще раз повторюсь, что в большинстве случаев такие банальные навыки даже не обсуждаются. У вас должно это быть, и точка. Но, естественно, на практике где-то у кого-то бывают пробелы, и наиболее частое из встречающегося, что можно отнести к навыку “Самоорганизованность”, это эффект дырявого стека.
Что это такое? Наверное, картинка от автора покажет это наиболее наглядно: https://infostart.ru/upload/iblock/9c4/9c480c51b7cf7ffd7bdb7c73d44474af.jpg. Слегка перефразируя описанное в книге “Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо”, если человек неспособен вести аккуратный список задач, то весь стек заданий удерживается в голове, к чему она не приспособлена. И все, что в этот стек не помещается, «падает на пол». Грубо говоря, это продалбливание задач/дел, когда их много.
Типовая ошибка джуна (гораздо чаще именно у начинающих это встречается), которой быть не должно:
- Я как БА-менеджер закидываю сотрудника задачами. Или заказчик закидывает аналитика письмами. И добавим сюда условие, что это большой или очень большой поток. Можно даже еще усложнить ситуацию: у сотрудника аврал, попа горит, и все это на пяти проектах, которые он одновременно тянет. Если при этом старые задачи/письма/что угодно “забылись” или “потерялись”, ибо много всего, — это косяк, за который ответственен только исполнитель. И я сейчас не про критичность проблемы, которая может быть разной и в экстремальных условиях даже приемлемой и понятной, а про правильное взятие ответственности на себя. Ну а если это системная проблема (т. е. нет рабочего механизма для подобного, а есть только перегруженная весом проблем голова), то это грусть, и в большинстве случаев я резко не хотел бы дальше работать с этим человеком.
👍7
- Аналогичный пример, который я иногда наблюдаю на курсах и в менторинге: я могу закидывать людей материалами на “почитать при случае”, причем в условиях и так немалой нагрузки. И если наблюдается ситуация “О не, я это не видел / не читал / не планирую, потому что и так много всего, я просто не могу все это себе зафиксировать”, то а) учитывая, что мы еще только обучаемся, плюс человек никому ничего не должен в этом аспекте (в меньшей степени такое актуально для менторинга), то без проблем, понимаемо; б) если при этом проблема перекладывается на ментора/тренера (“не надо столько всего давать, когда и так все плотно — загружайте в мои планы информацию в меру”), то я в зависимости от контекста либо стойко смирюсь, либо мягко донесу описанное в предыдущем пункте — в рабочем окружении это будет ваша и только ваша проблема, и уже там у этого есть и ответственность, и последствия.
Что с этим делать? Капитан Очевидность, настало твое время:
1) Фиксировать все НЕ в голове. Честно, я редко встречаю аналитиков со стажем, у которых инструмент фиксации — память. Ведем речь про задачи? Инструмент для фиксации задач: блокнот, календарь, Todoist или прочее ПО для организации дел. Говорим про материалы и прочие заметки, которые могут понадобиться в будущем? Ровно аналогично, только ПО для этого будет слегка другое (все, думаю, слышали про Evernote, OneNote, Notion и им подобное). То есть это просто надо делать. И раз уже в теме: вот интересно, а есть такие, кто систематически проводит интервью со стейкхолдерами, не фиксируя извлеченную информацию, а держа полученное только в голове? Нужно ли пояснять, что это путь в ад? 🙈
2) Второй момент лишь косвенно касается озвученной проблемы, но для работы с “не забыть” есть прекрасный инструмент — чек-листы. Есть даже целые книги, которые посвящены чек-листам и тому, как с ними работать. И тут просто удивительно, насколько это банальный инструмент, о котором даже писать как-то неловко, и с другой стороны — как мало им пользуются. Смотрите, все просто. Вы собираетесь в отпуск. У вас была проблема когда-нибудь, что вы что-то не взяли и страдали от этого впоследствии? Вы хотели бы не допустить этого в будущем? Сделайте чек-лист в вашей системе заметок “Брать с собой в отпуск” и пополняйте его по мере наступания на грабли. Плюс внедрите себе практикой условный рефлекс: когда наступает событие X, я иду читать чеклист “Что сделать при событии X” (“Не забыть сделать при поступлении CR от заказчика”, “Не забыть описать в документе при добавлении новой фичи”, “Не забыть сделать после устной сессии с ЗЛ”).
Собственно, всё 🤷♂️ Подобная проблема встречается, и нередко. На проекте в первый раз вам, вероятно, объяснят, что это нехорошо (а может еще и расскажут описанное выше, если заинтересованы в вас). Если же вы и дальше с этим косячите… Скажем так: именно в силу наличия простых инструментов для решения этой проблемы и банального желания/нежелания подобное внедрить в практику, мне и многим другим аналитикам сложно понять и принять, когда в рабочей среде аналитик продолжает системно совершать ошибки такого плана. Ну и если обобщить до тех пунктов, с которых начинали: многие готовы работать над прокачкой аналитика с уровня X до уровня Y — это вопрос опыта и погружения в профессию; гораздо меньше людей готовы работать с прокачкой софт-скиллов, которые были упомянуты и не только, — это уже вопрос того, готов ли человек сам приложить усилия, чтобы обладать необходимым минимумом для работы в сфере интеллектуального труда. Что интересно, иногда люди банально не понимают, почему их не взяли на ту или иную вакансию (”рынок вообще пуст, 2 года уже ищу работу”) или по факту стажировки на фоне таких явлений, как, например, “забыл ответить интервьюеру в срок”, “сделал задание частично, потому что невнимательно прочитал условие”, “выключил камеру и провел собеседование на фоне шума поезда и за два метра от микрофона”, “в резюме сделал 100500 ошибок” и т. п.
Что с этим делать? Капитан Очевидность, настало твое время:
1) Фиксировать все НЕ в голове. Честно, я редко встречаю аналитиков со стажем, у которых инструмент фиксации — память. Ведем речь про задачи? Инструмент для фиксации задач: блокнот, календарь, Todoist или прочее ПО для организации дел. Говорим про материалы и прочие заметки, которые могут понадобиться в будущем? Ровно аналогично, только ПО для этого будет слегка другое (все, думаю, слышали про Evernote, OneNote, Notion и им подобное). То есть это просто надо делать. И раз уже в теме: вот интересно, а есть такие, кто систематически проводит интервью со стейкхолдерами, не фиксируя извлеченную информацию, а держа полученное только в голове? Нужно ли пояснять, что это путь в ад? 🙈
2) Второй момент лишь косвенно касается озвученной проблемы, но для работы с “не забыть” есть прекрасный инструмент — чек-листы. Есть даже целые книги, которые посвящены чек-листам и тому, как с ними работать. И тут просто удивительно, насколько это банальный инструмент, о котором даже писать как-то неловко, и с другой стороны — как мало им пользуются. Смотрите, все просто. Вы собираетесь в отпуск. У вас была проблема когда-нибудь, что вы что-то не взяли и страдали от этого впоследствии? Вы хотели бы не допустить этого в будущем? Сделайте чек-лист в вашей системе заметок “Брать с собой в отпуск” и пополняйте его по мере наступания на грабли. Плюс внедрите себе практикой условный рефлекс: когда наступает событие X, я иду читать чеклист “Что сделать при событии X” (“Не забыть сделать при поступлении CR от заказчика”, “Не забыть описать в документе при добавлении новой фичи”, “Не забыть сделать после устной сессии с ЗЛ”).
Собственно, всё 🤷♂️ Подобная проблема встречается, и нередко. На проекте в первый раз вам, вероятно, объяснят, что это нехорошо (а может еще и расскажут описанное выше, если заинтересованы в вас). Если же вы и дальше с этим косячите… Скажем так: именно в силу наличия простых инструментов для решения этой проблемы и банального желания/нежелания подобное внедрить в практику, мне и многим другим аналитикам сложно понять и принять, когда в рабочей среде аналитик продолжает системно совершать ошибки такого плана. Ну и если обобщить до тех пунктов, с которых начинали: многие готовы работать над прокачкой аналитика с уровня X до уровня Y — это вопрос опыта и погружения в профессию; гораздо меньше людей готовы работать с прокачкой софт-скиллов, которые были упомянуты и не только, — это уже вопрос того, готов ли человек сам приложить усилия, чтобы обладать необходимым минимумом для работы в сфере интеллектуального труда. Что интересно, иногда люди банально не понимают, почему их не взяли на ту или иную вакансию (”рынок вообще пуст, 2 года уже ищу работу”) или по факту стажировки на фоне таких явлений, как, например, “забыл ответить интервьюеру в срок”, “сделал задание частично, потому что невнимательно прочитал условие”, “выключил камеру и провел собеседование на фоне шума поезда и за два метра от микрофона”, “в резюме сделал 100500 ошибок” и т. п.
👍8❤1🔥1
Всем салют!
Следующая ошибка, которую хотелось бы отметить (#9) — слабое погружение в бизнес-домен (предметную область) на проекте или как минимум непонимание ключевых терминов домена.
Все мы, кажись, знаем теорию: аналитик должен более-менее разбираться в области, автоматизировать которую нацелено решение. А потому не будем тут жечь красивыми теоретическими выкладками, а рассмотрим на пальцах, чем плохо это игнорировать. Личный опыт: работали кучкой аналитиков над долгоиграющим проектом из незнакомой финансовой области в US. Было это еще, когда динозавры по земле бегали, а все, что было давно — это как правило = “хз, кто такой хороший БА, нет курсов, книг и прочих мест, где можно уяснить, как надо, а потому делаем все по наитию”. И наитие подсказывало нам, что функция БА — выслушать заказчика и передать в разработку ровно то, что он глаголет. Главное, “белый шум” из его уст слушать очень внимательно. Так и поступали, причем в процессе интервью чаще всего не понимали вообще, о чем в плане бизнеса идет речь — в приоритете всегда было знакомые английские слова выделить из кучи полувнятных звуков. В общем, тупо фиксировали за заказчиком формулы и прочие бизнес-правила, не интересуясь, что все это значит. К чему это приводило:
1) Нам повезло с заказчиком и его ЗЛ, и в течение нескольких лет они терпеливо нам объясняли, что именно нужно задевелопить, прекрасно видя при этом, что мы вообще не пытаемся разобраться в бизнес-аспектах. Иной заказчик (особенно учитывая постоянную эволюции БА-области и повышение требований к аналитикам) мог бы и возопить: “Екарный бабай, мы уже это пару лет колбасим — ну разберитесь вы наконец в том языке, на котором я с вами общаюсь!” Т. е. как минимум это показатель вашего профессионализма в контексте общения с клиентом на его языке.
2) Сильно повышенная вероятность ошибок. Если белый шум, зафиксированный на звонке, зафиксировать криво, то понимание области не подскажет вам, что случился фейл. И да, были ситуации, когда после добавления очередной формулы в систему, невербальная реакция клиента была где-то на грани “Вы дебилы, да? Как можно было ТАК это понять?” Приходилось в курилке признавать, что да, мы такие 🤷♂️
3) Отсутствие генерации идей/решений от слова “совсем”. Помощи от нас как от людей, которые могут, понимая домен и суть решения, что-то полезное предложить, было где-то чуть меньше нуля. Ну, зато навыки отстраненного протоколирования развили огненно.
Когда спустя годы (!) решили все-таки разобраться в том, а что же за фигню и для кого/чего мы тут делаем, внезапно не только проблемы выше исчезли, а еще и на проекте стало работать интереснее.
Как надо? Разбирайтесь в том домене, проект для которого делаете, причем как можно быстрее. На уровне, достаточном для осмысленной проработки требований к этому решению:
- Заведите глоссарий терминов, дайте терминам однозначное определение, зафиксируйте для них синонимы из языка заказчика и согласуйте с ним обязательно этот контент. Не лишним тут будет вспомнить также про такой полезный инструмент, как модель бизнес-домена/предметной области. Часто помогает, ага.
- Не упускайте, как мы ранее очерчивали в ошибке #1, изучение AS IS и бизнес-требований — именно тут вы активно погружаетесь в домен на старте.
Следующая ошибка, которую хотелось бы отметить (#9) — слабое погружение в бизнес-домен (предметную область) на проекте или как минимум непонимание ключевых терминов домена.
Все мы, кажись, знаем теорию: аналитик должен более-менее разбираться в области, автоматизировать которую нацелено решение. А потому не будем тут жечь красивыми теоретическими выкладками, а рассмотрим на пальцах, чем плохо это игнорировать. Личный опыт: работали кучкой аналитиков над долгоиграющим проектом из незнакомой финансовой области в US. Было это еще, когда динозавры по земле бегали, а все, что было давно — это как правило = “хз, кто такой хороший БА, нет курсов, книг и прочих мест, где можно уяснить, как надо, а потому делаем все по наитию”. И наитие подсказывало нам, что функция БА — выслушать заказчика и передать в разработку ровно то, что он глаголет. Главное, “белый шум” из его уст слушать очень внимательно. Так и поступали, причем в процессе интервью чаще всего не понимали вообще, о чем в плане бизнеса идет речь — в приоритете всегда было знакомые английские слова выделить из кучи полувнятных звуков. В общем, тупо фиксировали за заказчиком формулы и прочие бизнес-правила, не интересуясь, что все это значит. К чему это приводило:
1) Нам повезло с заказчиком и его ЗЛ, и в течение нескольких лет они терпеливо нам объясняли, что именно нужно задевелопить, прекрасно видя при этом, что мы вообще не пытаемся разобраться в бизнес-аспектах. Иной заказчик (особенно учитывая постоянную эволюции БА-области и повышение требований к аналитикам) мог бы и возопить: “Екарный бабай, мы уже это пару лет колбасим — ну разберитесь вы наконец в том языке, на котором я с вами общаюсь!” Т. е. как минимум это показатель вашего профессионализма в контексте общения с клиентом на его языке.
2) Сильно повышенная вероятность ошибок. Если белый шум, зафиксированный на звонке, зафиксировать криво, то понимание области не подскажет вам, что случился фейл. И да, были ситуации, когда после добавления очередной формулы в систему, невербальная реакция клиента была где-то на грани “Вы дебилы, да? Как можно было ТАК это понять?” Приходилось в курилке признавать, что да, мы такие 🤷♂️
3) Отсутствие генерации идей/решений от слова “совсем”. Помощи от нас как от людей, которые могут, понимая домен и суть решения, что-то полезное предложить, было где-то чуть меньше нуля. Ну, зато навыки отстраненного протоколирования развили огненно.
Когда спустя годы (!) решили все-таки разобраться в том, а что же за фигню и для кого/чего мы тут делаем, внезапно не только проблемы выше исчезли, а еще и на проекте стало работать интереснее.
Как надо? Разбирайтесь в том домене, проект для которого делаете, причем как можно быстрее. На уровне, достаточном для осмысленной проработки требований к этому решению:
- Заведите глоссарий терминов, дайте терминам однозначное определение, зафиксируйте для них синонимы из языка заказчика и согласуйте с ним обязательно этот контент. Не лишним тут будет вспомнить также про такой полезный инструмент, как модель бизнес-домена/предметной области. Часто помогает, ага.
- Не упускайте, как мы ранее очерчивали в ошибке #1, изучение AS IS и бизнес-требований — именно тут вы активно погружаетесь в домен на старте.
shesterov.by
Модель предметной области и логическая модель данных (техники БА)
В этом очерке я опишу свое видение двух схожих моделей в бизнес-анализе — модели предметной области (aka бизнес-домена) и логической модели данных.
👍9
- Постарайтесь убедиться, что в требованиях любого уровня, которые вы фиксируете, нет “белого шума” — высоких материй, которые вы не понимаете. Даже более: старайтесь вообще не оперировать (извлекать, анализировать, документировать и пр.) информацией, которую вы не понимаете. Это, в целом, отдельная ошибка, но мы не будем ее обособленно разбирать: например, вы копируете кусок API из Интернета в вашу спеку (”не знаю, что это и надо ли, но пусть будет на всякий случай”).
А еще в памяти отложилось яркое собеседование с одним “сильно сеньорным” аналитиком (надеюсь, он нас не читает :)), который свято верил в то, что все описанное выше — чухня. Да еще и обиделся по итогу, будучи с интервьюером резко несогласным. Человеку задали вопрос: “Какая ключевая бизнес-сущность, с которой работает система?” Человек ответил. Последовал логичный вопрос: “А что это такое? Ни разу не слышали.” Человек ответил, что никогда не интересовался, после чего со стойкостью самурая доказывал, цитата, “Вот вам простой пример… Если я работаю с глазами, это не значит, что я должен понимать, что такое глаз. Это не мешает мне с ним работать!” Что-то подсказывает, что такой аналитик — бомба замедленного действия на проекте. Не будьте как этот аналитик 🫵
А еще в памяти отложилось яркое собеседование с одним “сильно сеньорным” аналитиком (надеюсь, он нас не читает :)), который свято верил в то, что все описанное выше — чухня. Да еще и обиделся по итогу, будучи с интервьюером резко несогласным. Человеку задали вопрос: “Какая ключевая бизнес-сущность, с которой работает система?” Человек ответил. Последовал логичный вопрос: “А что это такое? Ни разу не слышали.” Человек ответил, что никогда не интересовался, после чего со стойкостью самурая доказывал, цитата, “Вот вам простой пример… Если я работаю с глазами, это не значит, что я должен понимать, что такое глаз. Это не мешает мне с ним работать!” Что-то подсказывает, что такой аналитик — бомба замедленного действия на проекте. Не будьте как этот аналитик 🫵
👍7❤1
Приветствие всем!
Выделим такую ошибку (#10), как “технические знания не моё, я всего лишь аналитик”. Но я уже рассуждал на эту тему, поэтому просто отошлю туда: https://shesterov.by/tpost/k90kjs6sa1-it-ba-eto-it
Добавлю только: если чувствуете, что это про вас, почитайте. Вы не сделаете себе хуже, внедрив IT-прокачку в свой план.
Выделим такую ошибку (#10), как “технические знания не моё, я всего лишь аналитик”. Но я уже рассуждал на эту тему, поэтому просто отошлю туда: https://shesterov.by/tpost/k90kjs6sa1-it-ba-eto-it
Добавлю только: если чувствуете, что это про вас, почитайте. Вы не сделаете себе хуже, внедрив IT-прокачку в свой план.
👍4
Всем привет!
Второй блин 😁 Будем рады критике и любым иным комментам. 🙏
https://youtu.be/4hU3CAkFJsQ?si=nag13XWVSIl-Awxn
Второй блин 😁 Будем рады критике и любым иным комментам. 🙏
https://youtu.be/4hU3CAkFJsQ?si=nag13XWVSIl-Awxn
YouTube
Требования заинтересованных лиц
Курс по бизнес-анализу от ITMINE: https://itmine.by/course/business-analysis-online/
Облегченная версия курса для самостоятельного изучения: https://itmine.by/course/business-analysis-lite/
Чат для общения по теме бизнес-анализа: https://t.me/itminebachat…
Облегченная версия курса для самостоятельного изучения: https://itmine.by/course/business-analysis-lite/
Чат для общения по теме бизнес-анализа: https://t.me/itminebachat…
🔥18❤1👍1
Всем привет!
В компании ООО ИКомЧардж (Беларусь, Минск) открыта вакансия на позицию СА: https://rabota.by/vacancy/91269908?from=employer&hhtmFrom=employer
Выпускники ITMINE приветствуются 😉
Дополнительное описание от авторов:
Проекты не большие, но интересные. Например, сегодня надо интегрироваться с Российским банком, а завтра интегрироваться с платежной системой из Индии, Беларуси или Европы (на примере UPI, ЕРИП, PayPal и т.д.). От кандидата требуется: общее понимание работы HTTP методов, уметь читать API спецификацию (читаем API документ, понимаем какие запросы и в какой последовательности надо отправить, «пробиваем API» через Postman, curl и т.д.), умение описать флоу интеграции текстом и с помощью сиквенс диаграммы (в любом инструменте), в целом понимать как работает обмен запросами между системами. Если можете выполнить готовый html запрос (либо чуть подпилить и выполнить) в браузере (либо в другом инструменте) – приветствуется. Желательно – чуть-чуть уметь читать код (в API документации может быть указан небольшой отрывок кода для формирования сигнатуры. Но если вам сложно понять код, можно обратиться за помощью к разработчикам). Опыт как у БА у вас может быть минимальный (возможно только курсы), но техническая база описанная выше должна быть. Если требуется общение с англоязычными заказчиками – почти всегда переписка. B1 минимум. Работа очень интересная – каждый интеграционный проект уникальный и по времени обычно длится до 5-10 дней. Если есть неуверенность – не бойтесь. Рядом много технических специалистов, которые помогут. Всегда можно задать вопрос или попросить рассказать как «это» работает. Отводится время на онбординг (обучение лидом БА + материалы компании + можно задавать вопросы). Первое время – поддержка, далее втянитесь сами. Домен – фин. тех: процессинг платежей. Поддается осмыслению и погружению нормально.
В компании ООО ИКомЧардж (Беларусь, Минск) открыта вакансия на позицию СА: https://rabota.by/vacancy/91269908?from=employer&hhtmFrom=employer
Выпускники ITMINE приветствуются 😉
Дополнительное описание от авторов:
Проекты не большие, но интересные. Например, сегодня надо интегрироваться с Российским банком, а завтра интегрироваться с платежной системой из Индии, Беларуси или Европы (на примере UPI, ЕРИП, PayPal и т.д.). От кандидата требуется: общее понимание работы HTTP методов, уметь читать API спецификацию (читаем API документ, понимаем какие запросы и в какой последовательности надо отправить, «пробиваем API» через Postman, curl и т.д.), умение описать флоу интеграции текстом и с помощью сиквенс диаграммы (в любом инструменте), в целом понимать как работает обмен запросами между системами. Если можете выполнить готовый html запрос (либо чуть подпилить и выполнить) в браузере (либо в другом инструменте) – приветствуется. Желательно – чуть-чуть уметь читать код (в API документации может быть указан небольшой отрывок кода для формирования сигнатуры. Но если вам сложно понять код, можно обратиться за помощью к разработчикам). Опыт как у БА у вас может быть минимальный (возможно только курсы), но техническая база описанная выше должна быть. Если требуется общение с англоязычными заказчиками – почти всегда переписка. B1 минимум. Работа очень интересная – каждый интеграционный проект уникальный и по времени обычно длится до 5-10 дней. Если есть неуверенность – не бойтесь. Рядом много технических специалистов, которые помогут. Всегда можно задать вопрос или попросить рассказать как «это» работает. Отводится время на онбординг (обучение лидом БА + материалы компании + можно задавать вопросы). Первое время – поддержка, далее втянитесь сами. Домен – фин. тех: процессинг платежей. Поддается осмыслению и погружению нормально.
rabota.by
Вакансия Системный аналитик в Минске, работа в компании ИКомЧардж (вакансия в архиве c 20 февраля 2024)
Зарплата: не указана. Минск. Требуемый опыт: 1–3 года. Полная занятость. Дата публикации: 08.02.2024.
👍1
Всех с долгожданным и радостным началом рабочей недели! 😈
Сегодняшняя ошибка #11 — это игнор визуализации в коммуникации.
Как обычно, давайте вначале пофилософствуем. Аналитик — это обработчик информации (извлечь, проанализировать, задокументировать и поддерживать в актуальном состоянии, если нужно). Ну то есть, чтобы выполнить свою основную задачу (поспособствовать заказчику и команде в качественной реализации нужного стейкхолдерам IT-решения), аналитик бОльшую часть времени работает с информацией, включая её передачу (коммуникацию) между стейкхолдерами. Наверняка мы помним, что в коммуникации есть отправители/получатели и кодирование/декодирование, плюс то, что мы как аналитики можем поработать с каждым компонентом, чтобы сделать коммуникацию круче. Так вот, один из простейших приемов, которые позволят вам “закодировать” информацию аки боженька, является визуализация.
Снова вернёмся к кораблям, бороздящим просторы. Что я часто вижу, в особенности у начинающих аналитиков: отсутствие эмпатии тем, на кого нацелена какая-либо активность. Посудите сами: часто ли вы слышали или сами таким страдали, когда ставится не вопрос “Зачем и каким образом, как следствие, донести требования до команды?”, а “Где взять “правильный" шаблон юзер стори”? А слышали когда-нибудь такой постулат, что у аналитика все “it depends”? Это потому, что редко бывают правильные подходы и неправильные — есть кирпичики техник, из которых складывается домик анализа. И домик не сложится устойчиво, если вы не будете ставить вопрос “Зачем мне это делать именно здесь и сейчас?” И внезапно при правильной постановке вопроса в голову приходят полезные мысли: “Зачем мне писать спеку?" - > “Если для того, чтобы команда качественно и с минимум вопросов ко мне реализовала/проверила систему, а заказчик дал на это отмашку, то получается, что мне нужно написать это так, чтобы все они без адской боли это читали, верно?” В контексте любой коммуникации (а написать и отдать требования — это также коммуникация), если вы ответили на вопрос “Зачем?”, следующим вопросом у вас будет “Как сделать коммуникацию более эффективной для получателей?” И один из основных ответов на это — визуальное подкрепление.
Представьте или вспомните такое:
- Докладчик выступает без презентации (картинок)
- Пост в вашей любимой соцсетке длинен и не имеет при этом картинок (ага, как тут 😂)
- Учебная книжка совсем не имеет картинок
- Ваша спека/сторьки не имеют картинок. Упс 😧. Часто бывает такое, говорите? 😊
В общем, визуальная составляющая важна. Зачастую она преображает любую коммуникацию из состояния “скучно/сложно” в “интересно/легко”. Вспоминаем эмпатию: "да, я SME в этом вопросе и мне он важен, но а получателям это будет как интересным, так и понятным?" На примере спеки: "А они все вообще будут вчитываться в полотна моего текста, как в плане желания, так и способности понять мой паровозик мысли?"
А теперь советы:
- В спеках и сторях самое место диаграммам и прототипам UI — там, где а) сложно, б) скучно. Что может быть сложным? Длинные алгоритмы с кучей ветвлений и навороченные структуры ("Ща я как опишу четырехуровневую структуру фич сплошным текстом с четырехразрядной нумерацией пунктов! Уух, какой я клевый писатель!") .Что может быть скучным? Да собственно всё 😏 Требования — не то, чтобы любимый настольный жанр у заказчика и команды. В копилке аналитика есть много визуальных моделей, которые позволят визуализировать всё, что угодно.
Сегодняшняя ошибка #11 — это игнор визуализации в коммуникации.
Как обычно, давайте вначале пофилософствуем. Аналитик — это обработчик информации (извлечь, проанализировать, задокументировать и поддерживать в актуальном состоянии, если нужно). Ну то есть, чтобы выполнить свою основную задачу (поспособствовать заказчику и команде в качественной реализации нужного стейкхолдерам IT-решения), аналитик бОльшую часть времени работает с информацией, включая её передачу (коммуникацию) между стейкхолдерами. Наверняка мы помним, что в коммуникации есть отправители/получатели и кодирование/декодирование, плюс то, что мы как аналитики можем поработать с каждым компонентом, чтобы сделать коммуникацию круче. Так вот, один из простейших приемов, которые позволят вам “закодировать” информацию аки боженька, является визуализация.
Снова вернёмся к кораблям, бороздящим просторы. Что я часто вижу, в особенности у начинающих аналитиков: отсутствие эмпатии тем, на кого нацелена какая-либо активность. Посудите сами: часто ли вы слышали или сами таким страдали, когда ставится не вопрос “Зачем и каким образом, как следствие, донести требования до команды?”, а “Где взять “правильный" шаблон юзер стори”? А слышали когда-нибудь такой постулат, что у аналитика все “it depends”? Это потому, что редко бывают правильные подходы и неправильные — есть кирпичики техник, из которых складывается домик анализа. И домик не сложится устойчиво, если вы не будете ставить вопрос “Зачем мне это делать именно здесь и сейчас?” И внезапно при правильной постановке вопроса в голову приходят полезные мысли: “Зачем мне писать спеку?" - > “Если для того, чтобы команда качественно и с минимум вопросов ко мне реализовала/проверила систему, а заказчик дал на это отмашку, то получается, что мне нужно написать это так, чтобы все они без адской боли это читали, верно?” В контексте любой коммуникации (а написать и отдать требования — это также коммуникация), если вы ответили на вопрос “Зачем?”, следующим вопросом у вас будет “Как сделать коммуникацию более эффективной для получателей?” И один из основных ответов на это — визуальное подкрепление.
Представьте или вспомните такое:
- Докладчик выступает без презентации (картинок)
- Пост в вашей любимой соцсетке длинен и не имеет при этом картинок (ага, как тут 😂)
- Учебная книжка совсем не имеет картинок
- Ваша спека/сторьки не имеют картинок. Упс 😧. Часто бывает такое, говорите? 😊
В общем, визуальная составляющая важна. Зачастую она преображает любую коммуникацию из состояния “скучно/сложно” в “интересно/легко”. Вспоминаем эмпатию: "да, я SME в этом вопросе и мне он важен, но а получателям это будет как интересным, так и понятным?" На примере спеки: "А они все вообще будут вчитываться в полотна моего текста, как в плане желания, так и способности понять мой паровозик мысли?"
А теперь советы:
- В спеках и сторях самое место диаграммам и прототипам UI — там, где а) сложно, б) скучно. Что может быть сложным? Длинные алгоритмы с кучей ветвлений и навороченные структуры ("Ща я как опишу четырехуровневую структуру фич сплошным текстом с четырехразрядной нумерацией пунктов! Уух, какой я клевый писатель!") .Что может быть скучным? Да собственно всё 😏 Требования — не то, чтобы любимый настольный жанр у заказчика и команды. В копилке аналитика есть много визуальных моделей, которые позволят визуализировать всё, что угодно.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍3
- Когда вы общаетесь, используйте визуальные подкрепления. И неважно, общаетесь вы письменно или устно. Я вот, например, часто делаю вывод о том, что человек — классный коммуникатор (и кайфую от перспективы рабочего общения с ним), когда:
- Если к нему подходит разработчик с вопросом "Че-то я тут не понял, что написано в требованиях", берет его за шкирку и тащит к доске/флипчарту, чтобы маркером помогать доносить мысль.
- Общаясь с заказчиком на звонке, почти всегда шарит досочку в Miro или прочий инструмент как для фиксации того, о чем идет общение, так и для рисования схем в процессе, чтобы задействовать больше каналов.
- В письмах периодически, как и в спеке, что-то рисует: диаграммы, чтобы вместо или в дополнение к тексту ярче донести инфу; макеты, чтобы показать, как это будет выглядеть на UI.
- Вместо описательных отсылок к чему-то делает скриншоты и рисует на них стрелочки ("вот тут кнопка — на ней описка")
- Когда доносит мысль, показывает ее активным жестикулированием (но лучше в меру — чуть поменьше гангста-рэпперов): например, считая пункты, загибает пальцы. Ну а что, это тоже визуализация 😊
В общем, строго рекомендую как минимум просто попробовать. Вероятно, со временем у вас в большинстве коммуникаций также будет срабатывать условный рефлекс "Так, а что я буду показывать в процессе? Как это показать?" Где-то грустит один заказчик, когда аналитик на звонке начинает рассказывать сценарии юз кейсов голосом, читая их со спеки у себя под рукой, а потом, прочитав это минут за 10, спрашивает "Все ли хорошо, есть ли комменты?" Не меньше грустит и разработчик, когда открывает спеку аналитика, окидывает взглядом 50 страниц сплошного текста и понимает, что в ближайшие дни секс его мозгу обеспечен.
- Если к нему подходит разработчик с вопросом "Че-то я тут не понял, что написано в требованиях", берет его за шкирку и тащит к доске/флипчарту, чтобы маркером помогать доносить мысль.
- Общаясь с заказчиком на звонке, почти всегда шарит досочку в Miro или прочий инструмент как для фиксации того, о чем идет общение, так и для рисования схем в процессе, чтобы задействовать больше каналов.
- В письмах периодически, как и в спеке, что-то рисует: диаграммы, чтобы вместо или в дополнение к тексту ярче донести инфу; макеты, чтобы показать, как это будет выглядеть на UI.
- Вместо описательных отсылок к чему-то делает скриншоты и рисует на них стрелочки ("вот тут кнопка — на ней описка")
- Когда доносит мысль, показывает ее активным жестикулированием (но лучше в меру — чуть поменьше гангста-рэпперов): например, считая пункты, загибает пальцы. Ну а что, это тоже визуализация 😊
В общем, строго рекомендую как минимум просто попробовать. Вероятно, со временем у вас в большинстве коммуникаций также будет срабатывать условный рефлекс "Так, а что я буду показывать в процессе? Как это показать?" Где-то грустит один заказчик, когда аналитик на звонке начинает рассказывать сценарии юз кейсов голосом, читая их со спеки у себя под рукой, а потом, прочитав это минут за 10, спрашивает "Все ли хорошо, есть ли комменты?" Не меньше грустит и разработчик, когда открывает спеку аналитика, окидывает взглядом 50 страниц сплошного текста и понимает, что в ближайшие дни секс его мозгу обеспечен.
🔥13👍2❤1
Заметка о 4-х ключевых вопросах аналитика перед стартом работ: https://www.artofba.com/post/how-to-take-task-into-work-part2-four-key-questions
Рабочие и жизненные примеры, плюс в целом интересно читается.
Рабочие и жизненные примеры, плюс в целом интересно читается.
ArtofBA
Пост | ArtofBA
👍6
Очередной очерк от любимого дядюшки: https://medium.com/analysts-corner/when-use-cases-arent-enough-bb2094f5b01d
От себя: редко встречал использование именно таких таблиц на практике. Зато когда-то на собеседовании мне задали вопрос из этой области: как бы ты описал требования к такому вот проекту (несколько систем между собой активно взаимодействуют, при этом для конечного юзера либо нет операций, либо их одна-две полезных). Я перебрал все, что знаю (разные диаграммы, алгоритмы текстом и пр.). Собеседующий удивился и сказал, что самое элементарное и подходящее я не назвал — юз кейсы (ведь там же есть сценарии, так?). Я начал активно доказывать, что юз кейсы — не для таких ситуаций, и на минут 20 мы ушли в дискуссию. Зато по итогу человек сказал, что редко встречает ситуацию, когда его переубеждают, и был весьма доволен. Может, и вам пригодится 😊
От себя: редко встречал использование именно таких таблиц на практике. Зато когда-то на собеседовании мне задали вопрос из этой области: как бы ты описал требования к такому вот проекту (несколько систем между собой активно взаимодействуют, при этом для конечного юзера либо нет операций, либо их одна-две полезных). Я перебрал все, что знаю (разные диаграммы, алгоритмы текстом и пр.). Собеседующий удивился и сказал, что самое элементарное и подходящее я не назвал — юз кейсы (ведь там же есть сценарии, так?). Я начал активно доказывать, что юз кейсы — не для таких ситуаций, и на минут 20 мы ушли в дискуссию. Зато по итогу человек сказал, что редко встречает ситуацию, когда его переубеждают, и был весьма доволен. Может, и вам пригодится 😊
Medium
When Use Cases Aren’t Enough
Although use cases are valuable for many projects, sometimes event analysis is a more effective requirements elicitation technique.
О разнице между верификацией и валидацией ☝️ Огненной недели :)
https://www.youtube.com/watch?v=GJao4qnLHIE
https://www.youtube.com/watch?v=GJao4qnLHIE
YouTube
Big Bang Theory - Hawking - Sheldon What you do is not worth doing.wmv
Big Bang Theory - Hawking episode - Sheldon to Howard "What you do is not worth doing"
🤣10🔥2
Приветствие!
Продолжим цикл ошибок, и сегодня — не всегда критичное, но часто раздражающее явление: общение с ЗЛ языком требований решению (#12).
Сразу очертим, когда эта претензия не применима: когда аналитик извлекает требования к решению из ЗЛ, и это контекстно-уместно (“Давай заказчик, толкай мне, что за система нужна и как она должна работать“). Например, у вас что-то наподобие аутстаффинга, и свои аналитики есть на стороне клиента. Эти аналитики обеспечивают вашу команду спекой, пусть даже и не очень качественной, а вы, скорее, переводчик с иностранного для команды. Или же, например, когда заказчик сам уже обладает по какой-то причине спекой в голове и стремится всунуть вам ее в ухо: дает детальное описание того, что он хочет, языком решения; активно интересуется деталями реализации.
Но если (что гораздо чаще встречается) заказчик — бизнес-стейкхолдер и ждёт от вас полную качественную реализацию IT-услуги с минимумом своего вовлечения, то проблема выше — не ок, и ситуацию надо менять.
Пример, который я периодически я привожу на тренингах: представьте, что вы пошли постричься. А заодно представьте, что вы не эксперт в домене стрижки и вообще делаете это у данного мастера впервые. И вот вас спрашивают (требования извлекают, ага…): Вас машинкой с какой насадкой стричь? Сколько сантиметров оставить на висках? Под каким углом прикладывать ножницы к волосне? Если пример не близок, то представьте, что вы отдали машину в СТО, и там посыпались такого же плана вопросы.
Мотивация мастера понятна — человек хочет, чтобы вы спеку написали, а он её бездумно выполнил. Но только вот я лично от подобных вопросов чувствую себя глупым и мне некомфортно от того, что я не могу дать уверенный ответ. К чему это приведёт: хоть глупо и мне, но к этому мастеру я вряд ли приду снова, если будут альтернативы (просто потому, что мне было некомфортно).
А что он мог бы сделать? Как реализовать мои потребности — это требования к решению, его зона ответственности. Если у него есть переживания за них, он может у меня их зааппрувить (но моим языком). Но не извлекать из меня прямыми вопросами! А вот что ему действительно надо сделать, так это понять, что мне от него нужно (требования ЗЛ): “Расскажите, какую стрижку хотите; покажите на фотке; а вот наши фотки, кстати — тыкните пальцем, что нравится”. Его задача — активно помочь мне без своего проф. жаргона выдать мои хотелки.
Чем иногда аналитики жгут в этом плане:
- Э, пиу, заказчик! Смари, какой я словарь данных нафигачил. Проверь плз! (1)
- Какие эндпойнты апишки будем дергать? Мне нужна информация. (2)
- Какие есть ограничения дизайна/требования к операционной среде/атрибуты качества/…? (3)
Что объединяет все эти примеры? Попытка извлечь (прямыми вопросами или через “проверь мой черновик”) требования к решению. Эти требования описывают решение, а потому они часто формулируются языком домена решения (”классические” критерии приемки в US, кстати, избавлены от этой проблемы, именно поэтому есть рекомендации по языку их формулировки). И весьма велика вероятность, что бизнес-кастомеры не знают, как ответить на такое, и плачут. Просто представьте, что вы — не БА и не айтишник и вы обратились к ИТ-аутсорсингу: сайт мне для бизнеса запилите. Вы серьёзно ответите на такие вопросы от аналитика на той стороне?
А что же тогда делать (не считая исключений, описанных в начале)?
1) Примите за отправной факт, что ключевой источник требований к решению — вы. Стейкхолдеры — источники требований ЗЛ. Именно вы проектируете решение с позиции требований, основываясь на требованиях ЗЛ и бизнес-требованиях.
2) Очевидный вывод из предыдущего: извлекайте из ЗЛ именно требования ЗЛ (тут сделаю трассировку на видео, которое недавно постил: https://www.youtube.com/watch?v=4hU3CAkFJsQ). Осмыслите пример со стрижкой выше. Вам надо понять, каковы потребности у ЗЛ и что им нужно от решения (как они с ним хотели бы взаимодействовать и каким видеть), а не то, как решение должно себя вести — в этом, вероятно не очень ярком акценте, вся суть описанной ситуации.
Продолжим цикл ошибок, и сегодня — не всегда критичное, но часто раздражающее явление: общение с ЗЛ языком требований решению (#12).
Сразу очертим, когда эта претензия не применима: когда аналитик извлекает требования к решению из ЗЛ, и это контекстно-уместно (“Давай заказчик, толкай мне, что за система нужна и как она должна работать“). Например, у вас что-то наподобие аутстаффинга, и свои аналитики есть на стороне клиента. Эти аналитики обеспечивают вашу команду спекой, пусть даже и не очень качественной, а вы, скорее, переводчик с иностранного для команды. Или же, например, когда заказчик сам уже обладает по какой-то причине спекой в голове и стремится всунуть вам ее в ухо: дает детальное описание того, что он хочет, языком решения; активно интересуется деталями реализации.
Но если (что гораздо чаще встречается) заказчик — бизнес-стейкхолдер и ждёт от вас полную качественную реализацию IT-услуги с минимумом своего вовлечения, то проблема выше — не ок, и ситуацию надо менять.
Пример, который я периодически я привожу на тренингах: представьте, что вы пошли постричься. А заодно представьте, что вы не эксперт в домене стрижки и вообще делаете это у данного мастера впервые. И вот вас спрашивают (требования извлекают, ага…): Вас машинкой с какой насадкой стричь? Сколько сантиметров оставить на висках? Под каким углом прикладывать ножницы к волосне? Если пример не близок, то представьте, что вы отдали машину в СТО, и там посыпались такого же плана вопросы.
Мотивация мастера понятна — человек хочет, чтобы вы спеку написали, а он её бездумно выполнил. Но только вот я лично от подобных вопросов чувствую себя глупым и мне некомфортно от того, что я не могу дать уверенный ответ. К чему это приведёт: хоть глупо и мне, но к этому мастеру я вряд ли приду снова, если будут альтернативы (просто потому, что мне было некомфортно).
А что он мог бы сделать? Как реализовать мои потребности — это требования к решению, его зона ответственности. Если у него есть переживания за них, он может у меня их зааппрувить (но моим языком). Но не извлекать из меня прямыми вопросами! А вот что ему действительно надо сделать, так это понять, что мне от него нужно (требования ЗЛ): “Расскажите, какую стрижку хотите; покажите на фотке; а вот наши фотки, кстати — тыкните пальцем, что нравится”. Его задача — активно помочь мне без своего проф. жаргона выдать мои хотелки.
Чем иногда аналитики жгут в этом плане:
- Э, пиу, заказчик! Смари, какой я словарь данных нафигачил. Проверь плз! (1)
- Какие эндпойнты апишки будем дергать? Мне нужна информация. (2)
- Какие есть ограничения дизайна/требования к операционной среде/атрибуты качества/…? (3)
Что объединяет все эти примеры? Попытка извлечь (прямыми вопросами или через “проверь мой черновик”) требования к решению. Эти требования описывают решение, а потому они часто формулируются языком домена решения (”классические” критерии приемки в US, кстати, избавлены от этой проблемы, именно поэтому есть рекомендации по языку их формулировки). И весьма велика вероятность, что бизнес-кастомеры не знают, как ответить на такое, и плачут. Просто представьте, что вы — не БА и не айтишник и вы обратились к ИТ-аутсорсингу: сайт мне для бизнеса запилите. Вы серьёзно ответите на такие вопросы от аналитика на той стороне?
А что же тогда делать (не считая исключений, описанных в начале)?
1) Примите за отправной факт, что ключевой источник требований к решению — вы. Стейкхолдеры — источники требований ЗЛ. Именно вы проектируете решение с позиции требований, основываясь на требованиях ЗЛ и бизнес-требованиях.
2) Очевидный вывод из предыдущего: извлекайте из ЗЛ именно требования ЗЛ (тут сделаю трассировку на видео, которое недавно постил: https://www.youtube.com/watch?v=4hU3CAkFJsQ). Осмыслите пример со стрижкой выше. Вам надо понять, каковы потребности у ЗЛ и что им нужно от решения (как они с ним хотели бы взаимодействовать и каким видеть), а не то, как решение должно себя вести — в этом, вероятно не очень ярком акценте, вся суть описанной ситуации.
👍7
3) Если вам все-таки нужно требования к решению обсудить с ЗЛ не на стороне вашей команды (например, чтобы зааппрувить подход, выбрать подход из альтернатив, зааппрувить весь набор требований, чтобы получить sign off на них), подумайте, как это сделать так, чтобы ЗЛ все это поняли и не чувствовали себя идиотами.
Для примеров выше:
(1) А вам вот точно нужно получить от заказчика подтверждение требований к данным? Уверены? А зачем? Ему точно не все равно, какая у вас там модель и словарь данных? Может, одобрение надо получить на критерии приемки сторей, содержимое юз кейсов, макеты интерфейса, а требования к данным — это то, что под капотом обеспечивает функциональные поведенческие требования?
(2) Может, использование API — это то, как реализовать потребности стейкхолдеров, а не что им нужно? Точно стейкхолдеру нужно, чтобы вы использовали метод GetGeoData? Или ему все-таки нужно, чтобы на сайте на карте точкой была отображена локация? Обсудите с ним именно этот момент (что именно в плане отображения нужно), а API и методы выберите сами вместе с командой.
3) Да, упомянутая информация важна, но прямые вопросы из разряда “Какие у тебя есть требования к решению” не прокатят. “Смотри, заказчик, сегодня мы обсуждаем требования к операционной среде. Давай я поясню, что это такое: … Соответственно, давай подумаем, какие браузеры будем поддерживать? Предлагаю исходить из того, какие браузеры у нашей целевой аудитории. URL — это ссылка, по которой юзеры будут открывать систему. Есть предпочтения? Хостинг давай обсудим — есть вариант внешнего, есть еще вот такие варианты. Девайсы давай обсудим — пытаемся сделать красивенько на смартфонах?” И т. п.
4) И тут же надо затронуть такой момент, как высылка 100-страничной спеки голубем заказчику с посылом “Читай и подписывай!”. Да, такое часто нужно делать. Но как это сделать так, чтобы его этой спекой не придавило? Обдумайте такие варианты:
а) Обучить заказчика или иных ответственных ЗЛ тому, как это делать: поясните необходимость этого, методику изучения документа, порядок изучения (на что обратить внимание в первую очередь, какие детали можно просканировать, а в какие нужно аккуратно вчитаться).
б) Помогите ЗЛ: устройте ряд встреч по обсуждению спеки, где вы презентуете ключевые вещи и живым языком изложите содержимое.
в) Замените детальные около-технические артефакты на более живую выжимку (да, вы при этом берете риск самостоятельной проработки более мелочных требований). Например, оставьте раздел спеки c требованиями к UI- элементам за рамками изучения заказчиком и попросите изучить только UI-макеты, причем, допустим, в виде динамического кликабельного прототипа.
г) Склонитесь к более простым подходам к хранению требований (например, User Stories) или к активному разбавлению спеки визуальным контентом, который обычно легче воспринимается.
Для примеров выше:
(1) А вам вот точно нужно получить от заказчика подтверждение требований к данным? Уверены? А зачем? Ему точно не все равно, какая у вас там модель и словарь данных? Может, одобрение надо получить на критерии приемки сторей, содержимое юз кейсов, макеты интерфейса, а требования к данным — это то, что под капотом обеспечивает функциональные поведенческие требования?
(2) Может, использование API — это то, как реализовать потребности стейкхолдеров, а не что им нужно? Точно стейкхолдеру нужно, чтобы вы использовали метод GetGeoData? Или ему все-таки нужно, чтобы на сайте на карте точкой была отображена локация? Обсудите с ним именно этот момент (что именно в плане отображения нужно), а API и методы выберите сами вместе с командой.
3) Да, упомянутая информация важна, но прямые вопросы из разряда “Какие у тебя есть требования к решению” не прокатят. “Смотри, заказчик, сегодня мы обсуждаем требования к операционной среде. Давай я поясню, что это такое: … Соответственно, давай подумаем, какие браузеры будем поддерживать? Предлагаю исходить из того, какие браузеры у нашей целевой аудитории. URL — это ссылка, по которой юзеры будут открывать систему. Есть предпочтения? Хостинг давай обсудим — есть вариант внешнего, есть еще вот такие варианты. Девайсы давай обсудим — пытаемся сделать красивенько на смартфонах?” И т. п.
4) И тут же надо затронуть такой момент, как высылка 100-страничной спеки голубем заказчику с посылом “Читай и подписывай!”. Да, такое часто нужно делать. Но как это сделать так, чтобы его этой спекой не придавило? Обдумайте такие варианты:
а) Обучить заказчика или иных ответственных ЗЛ тому, как это делать: поясните необходимость этого, методику изучения документа, порядок изучения (на что обратить внимание в первую очередь, какие детали можно просканировать, а в какие нужно аккуратно вчитаться).
б) Помогите ЗЛ: устройте ряд встреч по обсуждению спеки, где вы презентуете ключевые вещи и живым языком изложите содержимое.
в) Замените детальные около-технические артефакты на более живую выжимку (да, вы при этом берете риск самостоятельной проработки более мелочных требований). Например, оставьте раздел спеки c требованиями к UI- элементам за рамками изучения заказчиком и попросите изучить только UI-макеты, причем, допустим, в виде динамического кликабельного прототипа.
г) Склонитесь к более простым подходам к хранению требований (например, User Stories) или к активному разбавлению спеки визуальным контентом, который обычно легче воспринимается.
❤8🔥2
А вот такое объявление от нас (вдруг тут есть желающие или желающие у уже прошедших обучение 😊)
Мы проводим сейчас набор на курс. Группу планируем стартовать с 11 марта. Тренер — Герман Шестеров. В группе есть места, плюс мы приятно обновили условия и формат (см. ниже):
📌 ~55 часов тренингов (мы увеличили количество и часов, и занятий), ориентированных на практику, разбор теоретического материала и разбор заданий.
📌 Вся теоретическая часть выдается в виде слайдкастов (записанный тренером голос + видео с камеры + презентация). Вы сможете изучать это в то время, той обстановке и динамике, которая Вам удобна
📌 100-200 часов внеаудиторной самостоятельной работы (часть которой — с проверкой тренером и разбором результатов)
📌 ~4 мес. основного курса + 2 мес. на дополнительный практический проект (в случае участия в нем). Формат: по будним дням, вечером, 1 или 2 дня в неделю, с 19 до 22, с периодическими свободными неделями для самостоятельной работы
Стоимость обучения – 799$ без участия в дополнительном проекте (цена снижена с 950$) + 299$ за дополнительный проект (он оплачивается отдельно, после прохождения основного курса). Оплата – в BYN, по курсу НБРБ на момент оплаты.
Узнать больше о курсе, а также оставить заявку на обучение можно на сайте. Вы также можете просто написать нам: @itmineby, info@itmine.by или позвонить по телефону +375 29 340-80-90.
Мы проводим сейчас набор на курс. Группу планируем стартовать с 11 марта. Тренер — Герман Шестеров. В группе есть места, плюс мы приятно обновили условия и формат (см. ниже):
📌 ~55 часов тренингов (мы увеличили количество и часов, и занятий), ориентированных на практику, разбор теоретического материала и разбор заданий.
📌 Вся теоретическая часть выдается в виде слайдкастов (записанный тренером голос + видео с камеры + презентация). Вы сможете изучать это в то время, той обстановке и динамике, которая Вам удобна
📌 100-200 часов внеаудиторной самостоятельной работы (часть которой — с проверкой тренером и разбором результатов)
📌 ~4 мес. основного курса + 2 мес. на дополнительный практический проект (в случае участия в нем). Формат: по будним дням, вечером, 1 или 2 дня в неделю, с 19 до 22, с периодическими свободными неделями для самостоятельной работы
Стоимость обучения – 799$ без участия в дополнительном проекте (цена снижена с 950$) + 299$ за дополнительный проект (он оплачивается отдельно, после прохождения основного курса). Оплата – в BYN, по курсу НБРБ на момент оплаты.
Узнать больше о курсе, а также оставить заявку на обучение можно на сайте. Вы также можете просто написать нам: @itmineby, info@itmine.by или позвонить по телефону +375 29 340-80-90.
🔥1