Archive for the ‘Требования к продуктам и системам’ Category
January 28th, 2009
Я начал писать книгу под условным названием «Идеальное ТЗ: Для программы, информационной системы, веб-продукта».
О чём в ней пойдёт речь?
Идеальное ТЗ
на программу, информационную систему, веб-продукт
1. Для кого эта книга
2. Предисловие
Методы, методы, методы!
3. Каким бывает успех?
Проект, продукт, система
Бизнес, пользователь, разработчики
January 28th, 2009
Книги и прочие источники перечисляются в порядке, рекомендованном к изучению.
1. Разработка и управление требованиями
Стандарты
Своды знаний
2. Основы системного анализа
3. Моделирование
4. Бизнес-моделирование
Стандарты
5. Проектирование интерфейсов
6. Системное проектирование
Стандарты
7. Процессы разработки ПО
Стандарты
Своды знаний
November 16th, 2008
Следующий набор документов используется для заказных проектов по автоматизации бизнеса.
Для проектов по созданию публичных веб-продуктов предварительно делается ещё ряд документов, описывающих модель потребностей аудитории (спрос на этом рынке), результаты конкурентного анализа (предложение на рынке), технологические тенденции, принципы работы сообщества (для проектов с сообществом).
October 5th, 2008
Участники дискуссии: Борис Тылевич, Яна Москвина, Алишер Хасанов, Александра Лаврентьева
На кого похож Менеджер Продукта?
Зачем он нужен?
Чем он занимается?
Чем не занимается?
Что знает?
Что умеет?
Где его искать?
Оставшиеся вопросы:
July 23rd, 2008
Чтобы писать ТЕХНИЧЕСКОЕ задание, надо обладать ТЕХНИЧЕСКИМИ же компетенциями.
Большинство того, что я читаю под лейблом ТЗ на самом деле является ХЗ или ГЗ — художественным или гуманитарным заданием. Да и пишется, что интересно, гуманитариями — маркетологами, политологами, рекламщиками, продавцами, операционными менеджерами, бизнес-аналитиками.
January 28th, 2008
Роли и системы автоматизации бизнеса
В системах автоматизации бизнеса функциональные требования пользователей практически целиком обусловлены производственными задачами, которые, в свою очередь, определяются бизнес-процессами, частью которых они являются. Бизнес-процессы обычно достаточно стабильны, а следовательно стабильны и пользовательские требования.
С другой стороны, поскольку пользовательские требования определяются задачами, которые зависят от процесса, то их разумно соотносить с ролью пользователя, которая соответствует одной или нескольким должностным позициям.
Так выглядит цепочка зависимостей и влияния:
Поскольку роли позволяют взаимозаменяемость, то учитывать личные особенности пользователей практически не нужно, кроме разве что возрастной категории, особенностей восприятия и т.д. – но все они приписываются целиком роли.
Расплывчатость и податливость аудитории массовых сервисов
В публичных массовых веб-системах на первое место в качестве определяющих пользовательские требования факторов выходят потребности, связанные с ними задачи, интересы и ожидания:
Поскольку действие происходит в открытой среде, с учётом бурных изменений в вебе потребности и ожидания могут серьёзно плыть в результате действий конкурентов и изменения профиля пользователя.
Т.е. задача построения модели потребностей усугубляется задачей постоянного мониторинга удовлетворённости и корректировки модели.
В принципе для группировки потребностей можно использовать те же самые роли, однако тут есть одно но.
Огрубление модели потребностей до системных ролей приводит к утере контекста, а значит – специфики потребностей, что, на самом деле, очень критично для высококонкурентной среды.
Специализация пользовательских задач хорошо видна на примере сервиса beta.ya.ru и прочих сервисов, предлагающих более специфическую терминологию («ответить фоткой»), а следовательно, онтологию пространства действий.
Скажем, модель пользовательских ролей и задач вида «Роли: Пользователь, Редактор, Администратор», «Задачи: Просмотреть страницу, Оставить комментарий, Добавить объект» практически бесполезна для обеспечения успешности продукта.
Нужна какая-то другая модель и пока в её качестве я не видел ничего существенного, кроме модели «Персоны» Алана Купера.
Разработка персон
Разбиение аудитории пользователей на набор персон – это типичная задача разложения функции по гармоникам, вектора по ортам осей, минимального покрытия – если бы объекты исследования (пользователи) имели чёткую формализацию 
Возникает интересная задача – как выбрать такой набор персон, который бы достаточно хорошо описывал потребности аудитории?
Видятся следующие подходы:
January 8th, 2008
Взаимные обвинения
В ИТ-разработке, а сюда можно включить как разработку ИС, так и ПО и, возможно, СКС, часто можно встретить такие высказывания программистов и администраторов:
Т.е. разработчики обвиняют заказчика в нечёткости, неполноте и изменчивости требований.
Ну а заказчики, как вы сами понимаете, зачастую обвиняют «программистов» в том, что «мягкая оснастка» не такая уж мягкая, если на доработку уходят месяцы, что программа не делает очевидных вещей, те вещи, которые проговаривались и описывались, делаются в системе совсем не так и т.д. и т.п.
Взгляд со стороны
Давайте разыграем небольшую сценку.
Пациент приходит к врачу:
Пациент: Здравствуйте, доктор! Вы знаете, у меня что-то плечо болит. Я хочу, чтобы оно перестало. Дайте мне пожалуйста рецепт на что-то типа Бисептола.
Доктор: Ага, так и запишем — «Иванов А.Е., болит у него нечто». Вот вам рецепт.
Спустя несколько дней:
Пациент: Добрый день. Вы знаете, ни черта не помог этот Бисептол, только сильнее болеть стало. Дайте мне пожалуйста какой-нибудь Фервекс.
Доктор: Ну что ж, Фервекс так Фервекс, держите.
Проходит ещё несколько дней, новая сцена с похожим паттерном.
Что думает пациент? «Вот идиот этот доктор, даёт всё время что-то бестолковое»?
Что думает доктор? «Вот идиот этот пациент, сам не знает, чего хочет»?
Очевидное-невероятное
Насколько возможна такая сценка? Только при том условии, что доктор — никакой не доктор, а в лучшем случае — лаборант, и даже не врач. Почему? Потому что мы понимаем, что для успешного излечения нужно:
Причём это обязанности врача, в широком смысле – медицинского учреждения.
Почему заказчик не работает аналитиком
Ошибка номер 1 — Полагать, что Заказчик в принципе может полно и качественно сформулировать целевые свойства системы, достаточные для её проектирования и реализации.
Заказчик знает, чего хочет. Вот только знание это в своих формулировках «решить такую-то проблему; чтобы налоговая не могла привязаться; поднять уровень продаж за счёт интернета» явно недостаточно для начала проектирования. И это не его проблема, и это не повод для обвинения его.
Потому что, в очередной раз – типичный заказчик не эксперт в IT-области, он не знает с достаточной для качественной постановки не только технических, но и функциональных требований о возможностях, свойствах и ограничениях ПО как такового и отдельных его полуфабрикатов как следствие.
Типичный заказчик — не эксперт в формулировке требований к продуктам, системам и ПО. Его этому никто никогда и нигде не учил.
Дай бог, чтобы заказчик был экспертом хотя бы в своей предметной области (!), хотя опять же требовать от него этого нельзя.
Зрелость IT-инженерии
Проблема не в том, что заказчик не умеет и не понимает, как и какие требования выдвигать к продукту.
Проблема в том, что IT-разработчики, с удовольствием соглашаясь, когда их называют «инженерами”, не владеют дисциплиной Software Requirements (в более широком контексте – Requirements Engineering), входящей в набор Software Engineering Body of Knowledge (SWEBOK), выполнение процесса которой ложится на них в малых проектах. Индустрия придумала для таких проектов workaround для дисциплины «Требования к ПО» в виде RAD и Agile-практик, но в России ими в основном пользоваться не умеют.
Проблема в том, что IT-компании в лице их менеджеров не умеют и не могут поставить процесс разработки промышленным образом в средних (а иногда — и больших) проектах, выделить роль бизнес/системного аналитика и ресурсы на её отработку.
В результате получается, что «лечение» заказчика производится на основе как-то задокументированных отзывов, впечатлений заказчика о своих проблемах и возможностях развития, без исследования, постановки диагноза, выбора методов «лечения». Т.е. имеет место так ненавистный мне «процесс исполнения желаний» (волюнтаризм в выдвижении и исполнении требований), а не зрелая инженерная деятельность. Немудрено, что желания меняются, т.к. меняется настроение, меняется понимание истинных проблем (т.к. исследование проиходит неявно в ходе реализации и убеждения неработоспособности реализованного).
Бизнес и ИТ как Сцилла и Харибда
В отличие от врачевания человеческого тела, где предметная область, какой-бы сложной она ни была, всё-таки одна, в IT-разработке чаще всего мы имеем как минимум 2 предметные области конкретную сферу традиционного или инновационного бизнеса и собственно IT. Поэтому в случае нетрививальной предметной области бизнеса обязательно надо потратить время на понимание устройства бизнеса, идентификацию настоящих проблем (Root Cause Analysis) и возможностей, выработку принципиальных способов решения проблемы на уровне бизнеса (автоматизация, расширение, скупка активов, реорганизация процессов, свёртывание бизнеса), выработку концептуального способа решения бизнес-задач на уровне системы, определение требований как системных свойств, их приоритезацию и постановку процесса управления изменениями (которые неизбежны).
И тут действительно нужны разные навыки и квалификация — как для 1) исследования и моделирования на уровне бизнеса, так и 2) на уровне формулировки требований к системе. Далеко не каждый системный архитектор способен хотя бы на второе, как минимум — потому что эта деятельность требует другой точки зрения на систему, как максимум — потому что его этому просто нигде не учили.
Пиррова победа работы «с проектирования»
Поэтому когда я слышу «заказчик не знает толком, чего он хочет» то мне тут же становится понятно, что кто-то в окружении говорящего (возможно, он сам), экономит на обучении и персонале, создавая себе в лучшем случае Пиррову победу — проект сдан, деньги получены, но бизнес-эффект нулевой, заказчик несчастен, бюджет превышен, разработчики вымотаны переработками. Как вариант — IT-компания не хочет делиться бюджетом с консультантами, способными выполнить работу по качественной постановке задачи на проектирование и курировать её реализацию.
P.S. Забавно, что Business Analysis Body of Knowledge тоже в основном требованиям посвящён, а совсем не анализу бизнеса, как хотелось бы.
August 26th, 2007
Коллега прислал на рецензирование ТЗ на очередной поток доработок одного муниципального веб-ресурса.
Проблемы, как обычно — с головы, с целей. В качестве оных идут «повышение уровня информированности посредством повышения удобства использования, модернизации существующих и создания новых сервисов».
Ну т.е. ладно я понимаю, что цели совсем не SMART, ну ладно, когда в качестве Целей пишут Задачи («автоматизация»), но писать в качестве оных ДЕЯТЕЛЬНОСТЬ («модернизация») — это имхо уже слишком
Люди! Умоляю вас, ТЗ не должно высасываться из пальца. ТЗ — это взвешенная качественная обоснованная постановка задачи, сделанная на основе АНЛИЗА ПРОБЛЕМЫ, а ПРОБЛЕМА выявляется в ходе ОБСЛЕДОВАНИЯ, либо как отдельного проекта, в случае новой системы, либо в ходе МОНИТОРИНГА, в случае существующей.
И цели проекта, поставленные в ТЗ, очень тесно связаны с целесообразностью, соответствием целям более высокого уровня. В этом смысле МОДЕРНИЗАЦИЯ отвечает цели более высокого уровня ПОТРАТИТЬ ДЕНЬГИ, СОЗДАВ ВИДИМОСТЬ РАБОТЫ, а цели типа ПОВЫСИТЬ ИНФОРМИРОВАННОСТЬ и УДОВЛЕТВОРЁННОСТЬ РЕСУРСОМ ЖИТЕЛЕЙ РЕГИОНА остаются вне фокуса, в пролёте.
А ведь казалось бы, что может быть проще — возьмите в качестве метрики показатель «Процент жителей региона, удовлетворённых качеством ресурса», далее составьте список потребностей-задач из 20-30 пунктов, согласуйте его и расширьте через механизм опроса на сайте, сделайте анализ удовлетворённости, получите цифру. Затем эту цифру увеличьте в N раз, получив абсолютную и относительную величину прироста удовлетворённости и постулируйте в качестве цели достижение этой величины в течении заданного времени. Тогда и проверить достижение целей проекта можно будет, и увидеть расход ИТ-бюджета на одного жителя, а следовательно — рост эффективности расходования тоже.
Тогда показатель «Процент жителей региона, удовлетворённых качеством ресурса» можно свести к произведению 2-х: а) Процент жителей региона, пользующихся интернетом прямо или опосредованно; б) Процент жителей региона, пользователей интернета, довольных качеством ресурса. И ставить задачи, исходя из целей увеличения на некоторую величину как первой так и второй составляющей. Потому что если всего в регионе интернетом пользуются 1-5% населения, то высокое качество ресурса не спасёт.
December 22nd, 2006
Нашёл хороший вопрос на форуме SQL.ru – “Какие вопросы задавать Заказчику, Экспертам предметной области, IT-экспертам и пользователям перед проектированием системы? Есть ли какие-то стандарты описания предметной области?”
Фактически речь идёт о фазах “Постановка бизнес-задачи”, “Бизнес-моделирование” (Обследование AS-IS, Проектирование TO-BE), “Определение требований” и “Анализ и проектирование системы”.
Постановку бизнес-задачи надо обсуждать с Заказчиком, или будущим Владельцем системы.
Вопросы, которые ему стоит задать, это:
В качестве “Стандарта” на вопросы такого рода смотрите шаблон документа “Stakeholder Request”, например, из RUP. Бизнес-требования может выразить Заказчик или Эксперты предметной области. Они обычно фиксируются в виде списка из 10-30 ключевых свойств продукта – в качестве шаблона см. Vision из RUP.
Бизнес-моделирование надо проводить на основе информации от, а лучше совместно с экспертами предметной области. Вопросы по сути сводятся к “Что, почему, когда, как и кем происходит в предметной области и как оно взаимосвязано?”:
Существует российский стандарт функционального моделирования P 50.1.028-2001, созданный на основе IDEF0.
Определение требований – частично Бизнес-требования и Требования, проистекающие из предметной области вы уже определили выше, теперь осталось исследовать Пользовательские требования и Системные требования и ограничения к отдельным аспектам качества системы. Пользовательские требования, как можно понять, нужно выявлять из общения с потенциальными пользователями системы. Вопросы:
Результаты анкетирования/интервьюирования обычно представляют в виде пользовательских историй (User Story, Agile) или Пользовательских сценариев (Use-case), также возможно их диаграммное представление средствами диаграмм потока работ (IDEF3), ARIS, Activity/State UML Diagram. Подробнее про работу с Пользователями могут рассказать специалисты по Проектированию взаимодействия, интерфейсам и эргономике.
Системные требования нужно выяснять у IT-специалистов Заказчика, если таковые имеются, из специфики контекста использования системы, опыта построения аналогичных систем (у IT-Экспертов-Архитекторов) и Специалистов по отдельным аспектам системы, значимым для данного проекта (Юристы, Эргономисты, и т.д.) и Заказчика:
Переработанный результат оформляется в виде Системных требований (Software Requirement Specification, стандарт IEEE-STD-830-1998, или ТЗ ГОСТ 34-602-89 или неформально в виде Supplementary Specificaion из RUP).