Я расскажу о практическом примере того, как мы формулировали требования к задаче машинного обучения и выбирали точку на кривой точность/полнота. Разрабатывая систему автоматической модерации контента, мы столкнулись с проблемой выбора компромисса между точностью и полнотой, и решили ее с помощью несложного, но крайне полезного эксперимента по сбору асессорских оценок и вычисления их согласованности.
Читать полностью »
Не раз задавалась вопросом: как бы так комфортно организовать входящие требования к системе — на этапе, когда требования только собираются, когда формируются вопросы и озвучиваются ответы, а ещё всё постоянно меняется и пересматривается, а ещё когда в реализации задействовано несколько систем, а ещё, а ещё…
При этом очень бы хотелось:
Да и вообще.
Читать полностью »
Это статья о том, как организовать требования на крупном проекте с кучей подпроектов, которые постоянно изменяются; организовать требования так, чтобы читателям было счастливо и уютно их читать (насколько это возможно для технической документации), а писателям — писать.
Речь идёт об организации готовых требований (требования уже получены и сформулированы, и теперь с ними ведётся работа). И в данном контексте требование — это описание некой функциональности (в моём случае — к сайту), на языке, понятном разработчику, заказчику, простому смертному, дающее представление о том, «как это должно работать».
То, что написано ниже, — не есть истина в последней инстанции, это лишь описание проблем, с которыми команда разработки сталкивается в работе с требованиями ежедневно, и инструменты, с помощью которых можно их решить.
Читать полностью »
О user-centered design, или процессе проектирования информационных систем, ориентированном на потребности конечного пользователя, сказано уже столько, что кажется, будто бы добавить ничего и нельзя (да и не надо). На каждой завалящей конференции, симпозиуме, митинге, профессиональной тусовке 99% всех слов что будут произнесены – будут так или иначе касаться важности внутреннего мира пользователя, его желаний, потребностей, ожиданий, привычек и т.д.
Мне же этот подход кажется слишком поверхностным, таким «для начинающих», по двум причинам: Читать полностью »
«Но я же хотела зеленое большое кислое яблоко» — стенала я, держа в руках маленькое яблочко с красным боком. «Ты сказала, чтобы я купил яблоко, я купил яблоко» — сурово отрезал муж.
В начале разработки клиенты всегда довольны, недовольными они становятся в конце, когда их ожидания не совпадают с тем, что разработано. Вроде бы говорили заказчик и менеджер разработки об одном, вроде употребляли умные слова вроде «план» и «риски», а не в восторге клиент от готового продукта. Как так?
Александр Александр — «дедушка тестирования» в СНГ делал докладна юбилейной 15-ой SQA Days в Москве.
Слайды:
www.slideshare.net/VLDCORP/ss-33747358?ref=http://sqadays.com/ru/talk/18189
Видео выступления:
Читать полностью »
Системный аналитик, он же постановщик, он же тот, кто работает с требованиями и проектирует систему, во многом определяет жизнеспособность будущей или сопровождаемой системы. Хорошо, если он работает не просто как трансивер, передавая требования от заказчика к разработчикам, но и вносит в продукт «добавленную стоимость» — преобразует «хотелки» в систему требований, концентрируя в ней суть разработки.
Чем выше квалификация системного аналитика, тем ниже производственные затраты. Системный аналитик должен свободно плавать не только в предметной области заказчика, но и процессах проектирования, т.е. проще говоря, осознавать, что именно он делает.
Поэтому предлагаю небольшой crash-тест для тех, кто хочет стать системными аналитиками или для тех, кто хочет взять себе системных аналитиков. Безусловно он не исчерпывающий, но такие точечные «удары», позволяют быстро оценить «глубину проникновения» в процесс проектирования и узнать много нового от собеседника.Читать полностью »
За 3 года существования летнего аналитического фестиваля мы накопили большое количество записей интересных выступлений. И сегодня хотим поделиться с вами подборкой:
Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.
Читать полностью »
Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:
В системе должно отображаться уровень заполненности склада за счет отображения количества товаров каждого типа. При отгрузке/приеме товаров значение должно обновляться.
В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!
Читать полностью »
