Разработка требований к автоматизированным системам

Сегодня я буду делиться с вами накопленным опытом в этом вопросе. В статье я хотел бы донести до читателей следующую мысль:

• Первое, на что я хотел бы обратить внимание – это переосмыслить вообще роль требований в тех проектах, которыми мы с вами занимаемся
• А также постараться дать информацию для того, чтобы у тех, кто этим занимается, мог наметиться какой-то путь и шаги к действиям, чтобы эти требования можно было улучшать и более эффективно реализовывать IT-проекты

  Я разделил весь материал на четыре части.

• Первая часть – вводная. Касается роли требований вообще. Чтобы немножко погрузиться в тему – разобраться, на что они влияют. На самом деле, они влияют на все процессы, протекающие в управлении проектами – от самоинициации до самозавершения. Поэтому я, может быть, периодически буду касаться вопросов управления проектами в целом.
• Вторая часть – более конкретная, касается такого интересного вопроса, как предназначение документов требований. Разные есть взгляды у разработчиков на это, — одни говорят, что вообще не надо уже никакую документацию разрабатывать в принципе. Другие – наоборот,  говорят, что все нужно расписывать как можно подробнее. Это во многом спорный вопрос. Мы об этом тоже поговорим.
• Третья часть – она будет достаточно практическая. Я попробую очень структурированно рассказать о требованиях, какие они бывают, как с ними работать, как их формулировать.
• Четвертая часть – небольшая. О жизненном цикле требований.

Первая часть. Роль требований в управлении проектом

Начну с самого начала. Сегодня уже говорили про важность ожиданий заказчика. Действительно, любой проект начинается с того, что все начинают думать, что же этот заказчик хочет и как сделать так, чтобы в течение проекта не оказалось, что то, что мы делаем – совсем не то, что он ожидает.

Проблема конфликта интересов внутри фирмы-заказчика

Что касается ожиданий заказчика – первое, на что тут нужно обратить внимание – это то, что конфликт интересов может быть не только между заказчиком и исполнителем. Этот конфликт интересов начинается еще и внутри самого заказчика и связан этот конфликт интересов с тем, что автоматизируется предприятие заказчика – в большинстве своем – это большая иерархически подчиненная организационная структура. И часто бывает, что, допустим, директор (руководитель предприятия заказчика) решил, что их предприятие будет автоматизироваться, и издал приказ о том, что начинается проект – озвучил какие-то громкие цели. А после этого тихо самоустранился от проекта (наблюдает за ним со стороны), убежденный в том, что его подчиненные будут честно и добросовестно трудиться над тем, чтобы достичь этих великий целей. Как показывает практика, в 98% случаев эти подчиненные ничего делать не будут, кроме того, каждый организационный уровень этой организационной структуры будет пытаться удовлетворить свои интересы (если вообще будут что-то пытаться). Руководители подразделений будут что-то делать только ради своих подразделений, а конечные сотрудники будут думать только о том, как удобнее работать им. 

Если не выявить истинных инициаторов проекта с самого начала, то процесс развертывания проекта будет пущен на самотек и это 100% приведет к проблемам – либо со сроками, либо с бюджетом, либо еще к каким-то проблемам.

Что с этим можно сделать?

Можно сделать три простых шага:

Сверху вниз указана последовательность этих шагов, а справа отображен уровень компетенций, который нужен для того, чтобы это получилось.

• В первую очередь нужно выявить, кто же эти реальные инициаторы? Под инициаторами нужно в первую очередь подразумевать тех людей, кто будет принимать результаты работ. Потому что бывают ситуации, что инициатором чуть ли не весь проект называют руководителя, а принимать работу он доверяет какому-то иному лицу, которое в принципе в проекте могло вообще и не участвовать. Заканчивается это – понятно чем.
• Итак, нужно выявить инициаторов, понять, какие ключевые требования от этих инициаторов поступают, и суметь эти ключевые требования декомпозировать – разложить их до конечных функциональных требований.

Теперь, когда мы уже начинаем работать, нужно стремиться реализовывать эти требования именно в определенных границах. Потому что иначе проект будет раздуваться до неимоверных масштабов, что снижает его рентабельность.

Классификация групп требований в зависимости от инициаторов

Я разделяю требования на основные четыре группы, зависящие от видов инициаторов:

• Собственник (ТОП-менеджмент). В этом случае каждый раз, когда он будет платить деньги, будет задавать себе вопрос, за что платит. Необходимо четко контролировать ожидания собственников. Скорее всего, ему нужна информация для принятия решений.
• Руководители отдельных структур компании (направлений, отделов и пр.). Такие проекты могут быть направлены на автоматизацию именно этих подразделений. Особое внимание следует уделить тому, кто будет принимать работы и оценивать результаты. Что думает об этом собственник (полностью ли он делегировал задачу такому руководителю?) Не скажет ли он потом: «мне это было не нужно».
• IT-служба заказчика. В этом случае проект может быть число технологической направленности (например, интеграционный). Цели бизнеса и пр. имеют меньшее значение. Принимать такие работы тоже должна ИТ-служба.
• Инициатива «снизу». Бывает и такое. Когда пользователи постоянно жалуются о недостатках имеющихся систем и настаивают на автоматизации. При этом человека, способного выполнять роль руководителя проекта нет, а цели непонятны. Лучше такие работы выполнять в режиме сопровождения, т.к. это не проект.

Работы, основанные на требованиях четвертой группы – даже нельзя назвать проектом, потому что руководителя там нет, четких целей тоже. Такие работы нужно сразу переводить в режим сопровождения или вообще не связываться. Остальные виды требований формулируются в проекты, но это проекты разного типа.

Составляющие удовлетворенности заказчика

Из чего может складываться путь к удовлетворенности заказчика?

Кроме знаний о владельцах требований, необходимо также обеспечить условия, чтобы вообще это процесс мог продвигаться:

• со стороны заказчика был какой-то руководитель,
• была возможность обеспечить технические условия, аппаратное обеспечение…

На что я еще хочу обратить ваше внимание – часто этот перечень ограничен только первыми тремя пунктами (заканчивая на функциональности) и называют это системой. Но дело в том, что система – это не только программный код, который, может, даже идеально разработан и отлично работает. Не надо забывать о том, что именно подразумевается под созданием организационных и технических условий работы:

• люди должны быть обучены,
• среди них должен быть проведен инструктаж, должны быть разработаны четкие методики того, как они должны работать,
• и, конечно же, должна быть обеспечена вся требуемая функциональность системы.

Если не будет тщательно продуманных методик работы в системе, регламентов работы в этой системе, и каких-то аппаратных средств, которые позволяют этой системой пользоваться, то системы не получится. Исключение любого из пунктов, которые здесь представлены, скорее всего, будет препятствовать тому, чтобы все завершилось успешно.

Необходимо определить границы проекта

До этого мы с вами обсуждали ожидания заказчика. Теперь переходим к обсуждению влияния требований заказчика на границы проекта и на вопросы приемки-сдачи работ.

Здесь я ограничился одной такой маленькой картинкой:

Если нет требований (требования нечеткие, «размытые»), то очевидно, что нельзя определить границы проекта. Отсюда следует, что – поскольку нельзя определить границы, то это, в общем-то, и не проект. А поскольку это не проект, то и завершить его будет невозможно.

Выхода из этой ситуации два:

• либо все остановить (прекратить),
• либо умудриться каким-то чудом убедить заказчика, что это был не проект, а это было все-таки какое-то сопровождениеи перейти к дальнейшему сопровождению. Психологически это очень сложно, так как проектная команда в условиях подобной ситуации может выглядеть примерно как на этом рисунке – быть уставшей и измученной, а заказчик будет счастлив и доволен – все работают бесплатно, долго, хорошо и не могут остановиться.

Проблема «размытых» требований

Я хочу привести примеры формулировок поставленной задачи (я их взял из различных проектов), которые как раз и «убивают границы проекта»:

•  «Система должна обеспечивать поддержку эффективной системы продаж»
• «Программа должна обладать простым пользовательским интерфейсом»
• «Способствовать поддержанию оптимальных складских запасов»
• «Система должна быть интегрирована со всеми системами Заказчика, имеющимися на момент запуска новой системы»

Это реальные формулировки из технических заданий. Автором одной из этих формулировок был я. (Это пункт насчет простого пользовательского интерфейса). Там была такая история. Директор был очень активный, конструктивный, хорошие с ним были отношения. Он сам лично активно участвовал в проекте (ничто не предвещало проблем). Он мне говорит – давайте в ТЗ один пункт и будем работать. Он еще хотел его сформулировать: «Чтобы программа была простой и имела защиту от дурака». Я все-таки, сформулировал этот пункт вот так. В результате – месяца три разработки – а потом пришлось еще работать (бесплатно, в общем-то). Я это к тому, что не надо принимать решения на эмоциональном уровне и думать, что если сейчас отношения с заказчиком такие хорошие-красивые-чудесные, то они будут такими всегда. В общем-то, ровным счетом, как и наоборот. Действовать нужно строго конструктивно.

На примере первого пункта – про эффективную систему продаж я и хотел разобрать пример – как привести эти требования к тому состоянию, при котором можно было бы с ними хоть как-то работать.

Необходимо распланировать работы по проекту

Что касается сроков, трудоемкости, бюджетов и планирования, то вы должны понимать, что эти вопросы связаны.

Здесь ситуация такая:

Мне нравится, как сказал о планировании Эйзенхауэр – отсюда вывод какой? План – это не Библия, на которую нужно молиться или повесить его на стенку и постоянно ходить, всех тыкать о том, что план не исполняется. План нужен для того, чтобы суметь своевременно его перепланировать – только тогда он может дать полезные результаты.

Поскольку мы рассматриваем вопрос, как требования вообще влияют на проект, то — из чего складывается план работ? Очевидно, что план работ складывается:

• из самих работ,
• из сроков исполнения этих работ,
• отсюда следует уже возможность оценки трудоемкости этих работ.

Когда мы все это вместе совокупно обдумаем, то тогда уже мы можем придти к некоему бюджету проекта.  Опять же, все это взаимосвязано и источником плана работ у нас – по традиции уже – являются требования. 

Проблемы доверия и компетенций в проектной команде

Что касается персонала и возможности привлечения аутсорсеров, то это будет влиять на ту квалификацию, которая требуется от того персонала, который мы хотим привлечь. Не важно, собственный это персонал или не собственный. Проекты разные и персонал тоже нужен разный и нужно понимать – есть у нас таки люди или нет у нас таких людей.

Из этого я вам советую запомнить одну только простую формулу:

Если мы при формулировании требований отдаем какие-то задачи на сторону аутсорсерам и думаем, что они сделают то же самое, что и те люди, которые сидят рядом с нами – которых мы знаем, то мы не правы. Это не так.

Резюмируя…

Итак, нас интересует ответ на главный вопрос:

Вторая часть. Документы требований

На этом мы переходим ко второй части и будем говорить о документах требований. 

Наш бизнес автоматизации существует уже десятилетие. Мы всю нашу жизнь сталкивались с тем, что существовали какие-то документы (техническое задание, проект, концепция и пр.).

Все это время у людей постоянно возникают вопросы: а те ли документы мы делаем? Не пора ли пересмотреть подходы? Почему раньше это работало, а сейчас это работать перестало (я имею в виду сами подходы)? Эти вопросы периодически возникают, даже у меня.

Какие документы требований нужны в проекте?

С годами у меня сформировалось определенное видение этого вопроса, которым я сейчас с вами и поделюсь. 

Здесь картинка разделена на две части.

• Слева – это различные виды никак не связанных между собой документов. Просто накиданы названия, которые встречаются в тех или иных проектных командах,
• Справа – это люди, которые должны этими документами пользоваться. По крайней мере, эти документы для этих людей предназначаются.

Проблемы несоответствия содержания документов требований техническому уровню инициаторов проекта

Основная проблема здесь заключается в том, что некоторым специалистам хочется запихать вообще всю информацию, которая имеется по проекту в один документ, либо хочется разделить эту информацию на множество других документов. Либо – сделают один какой-нибудь очень сложный, большой технический документ и, скажем, отдают его на согласование генеральному директору заказчика какого-нибудь крупного холдинга, который в этом документе вообще ничего не понимает. В таких ситуациях что происходит обычно?

  Либо этот генеральный директор начинает очень долго думать, привлекая для согласования своих специалистов – месяца два они этот документ пытаются согласовать. Либо этот генеральный директор вообще не думает и сразу – не читая, этот документ согласовывает. Ни там, ни там особой пользы нет. Понятно, почему. Потому что не факт, что этот документ кто-то изучал. Даже если мы все сделаем так, как там написано, не факт, что заказчик хотел именно это, потому что он на самом деле не разобрался. Когда заказчик согласовывает документ, в котором ничего не понял – это должно очень настораживать.

Что обязательно должно содержаться в документации, формирующей требования

Вся документация, которая на проектах создается (не важно, на каких проектах), должна отвечать всего на пять вопросов:  

• Чего требуется достичь?
• Как это будут использовать?
• Что нам нужно сделать для достижения цели?
• Как разделить нашу работу на задачи?
• Как нам потом проверить то, что мы получили?

Если та документация, которую мы разработали, на эти пять вопросов отвечает, то, скорее всего, все должно быть успешно.

По каким принципам собирать информацию в эту документацию?

Остается вопрос – как эту документацию группировать? Допустим, мы знаем ответы на эти пять вопросов, а что с этими ответами делать?  

Дело в том, что когда мы эти документы оформляем, то информацию туда нужно собирать по принципу тех лиц, которые будут эти документы согласовывать, либо этими документами будут пользоваться.

Если, скажем, инициаторами проекта является IT-служба заказчика и проект носит какой-нибудь интеграционный сложный технический характер, то наверняка они захотят увидеть какой-нибудь детализированный технический документ, чтобы все реквизиты были прописаны, их все устраивало и пр. Но и принимать работу в этом случае тоже будут они. Здесь все понятно.

Если такой же документ принести высшему руководству, то – я уже об этом говорил – ничего им будет не понятно. Либо наоборот – сформировать требования какими-то общими словами – и отдать их программистам в разработку. Они будут что-то делать, но – опять не понятно, что из этого получится.

Какой отсюда можно сделать вывод? При разделении всей информации по документам нужно обязательно думать о том, кто их (эти документы) будет согласовывать. И здесь абсолютно не важно, как эти документы будут называться. Важен результат.

Что дает «оформление по ГОСТу»?

Скажу два слова о ГОСТах.  

Когда заходит речь о программной документации, часто сотрудники заказчика говорят – зачем что-то изобретать, давно все написано в ГОСТах, все это уже 30 лет отработано, и пр. По факту – все это не совсем так. Если кто-нибудь с этим сталкивался, то ни один ГОСТ не решает проблемы с документацией.

Максимум, что он дает – это структурированный документ, и не более того.

Третья часть. Разработка требований

Сейчас мы переходим к самому главному – это непосредственно разработка требований. Как получить хорошие требования? (или хотя бы приближенно похожие на хорошие).  

Категории классификации требований

Я для себя разделил классификацию требований на три категории – по уровню требований, по видам требований и по свойству (качеству) требований.  

Уровни требований. Трансформация требований

Уровень требований – это очень важно. Потому что, когда инициаторы требований (руководство заказчика) что-то там изрекает такое общее – на уровне позывов каких-то целей, чего мы хотим достичь. Логично, что пока мы эти требования не проработаем, у нас проекта не получится.

• Первое, что нужно сделать – это требования верхнего уровня (который я назвал уровнем позывов) – привести к формулировкам ключевых требований (для начала). Чтобы было понятно, какие ключевые требования существуют, кто за них отвечает (кто был их инициатором) и что нужно сделать для того, чтобы эти люди увидели, что эти требования достигнуты. Но достичь их без дальнейшей декомпозиции будет невозможно. Очень часто на проектах бывает, что эти требования сразу спускаются на уровень исполнителей и отдаются им в работу. Исполнители, естественно, начинают фантазировать, что-то изобретать и ничего хорошего из этого опять не получается.
• Следующий уровень (я его называю «Уровень конкретики») – это когда ключевое требование раскладывается на конкретные функции (оформление документа продажи, оформление отчета по остаткам на складе и пр.).
• Правда, этого опять же – не совсем достаточно для того, чтобы можно было по этим функциональным требованиям работать – нужно двигаться дальше: раскладывать эти функциональные требования на конкретные работы, конкретные действия системы – именно их должны нам запрограммировать наши разработчики.

Виды требований. Оптимизация работ по требованиям

Что касается видов требований – самое главная группа – это, конечно, функциональные требования. Правда, она далеко не единственная. Есть еще и другие требования.  

Какой смысл вообще группировать требования по видам?

Самое главное, что это связано с оптимизацией распределения работ потом.

Потому что, например, нет смысла в том, чтобы один разработчик делал какой-то документ, потом настраивал систему прав под этот документ, другой разработчик делал другой документ и тоже потом настраивал систему прав под этот документ. Один разработчик хорошо разбирается в системе распределения прав, другой не очень хорошо разбирается в правах. Это неправильно.

Логичнее, что кто-то быстрее и лучше делает одни задачи, другой – другие. Кто-то разбирается, допустим, в оборудовании, кто-то совсем не разбирается. Это просто для удобства и для оптимизации работ.

Свойства и качества требований

Самое важное в требованиях – это как раз свойства и качества требований. Потому что любое требование должно соответствовать четырем пунктам:

• Быть понятным,
• конкретным,
• проверяемым,
• иидентифицируемым.

Если первые три пункта выполняются, то нет никаких сложностей к тому, чтобы требование стало еще и идентифицируемым.

Зачем нужна идентифицируемость требованию – я чуть позже расскажу.

Кроме того, что нужно понимать, что такое требование – нужно, конечно же, еще и суметь собрать информацию о том, чтобы эти требования вообще сформулировать. Вот этот сам процесс сбора и анализа информации не должен выглядеть хаотично. Он должен быть четко структурирован.

Как организовать работу по сбору требований?

Здесь у меня нарисована цепочка сбора и анализа требований. Под каждым из блоков этой цепочки сбора и анализа требований должна скрываться отдельная методология (технология) со своими подходами, документооборотом и т.д.  

• Начинается все с того, что выявляются цели самого высшего руководства.
• После этого – совершенно необходимо каким-то образом организовать рабочую группу
• Обучить рабочую группу тем правилам и методикам работы, по которым мы хотим с ними работать, а они могут по этим методикам работать с нами.
• Процесс анкетирования, перед тем, как мы вообще приступим к анализу информации – он очень удобен и эффективен (хотя есть люди, которые говорят, что вообще не надо никого анкетировать). Практика показывает, что как минимум 50% информации как раз извлекается при нормальном походе к процессу анкетирования (при дальнейших опросах эта информация просто уточняется, классифицируется). Просмотреть анкету иногда достаточно для того, чтобы, в общем-то, сразу понять, что же людям требуется. Все зависит от того, как процесс анкетирования организован.

Порядок проработки каждого ключевого требования

Но это еще не все. Дойдя до формулировки ключевых требований, мы поняли цели, критерии успешности, как заказчик собирается оценивать результат – мы все поняли, но что делать с этим дальше, как этого достичь – нам еще не известно. Так вот, при определении списка ключевых требований нам необходимо каждое из найденных ключевых требований проработать по следующей цепочке:

Берем требование, моделируем это требование в информационной системе. Берется тот программный продукт, который внедряется. Делается в нем пример. Еще лучше, если этот пример будет документироваться и сопровождаться в виде какого-то документа с описанием методики, потому что эта информация может пойти дальше – и в пользовательские инструкции, и в другую документацию.

Производится демонстрация. Согласуется с заказчиком, что да – действительно, мы хотим примерно вот это. Обязательно для каждого требования нужно убедиться в том, что оно вообще реально проверяемое.

Потому что если не договориться с заказчиком о том, как он это требование будет проверять, то, когда мы будем эти работы сдавать, мы будем их сдавать долго: заказчик может долго тянуть со словами « я еще не проверил».

Заканчивается все соответственно уже фиксацией требований в виде какого-то документа (Технического задания) – не важно, как вы его назовете.

Александр Белов вообще говорит, что он никогда технического задания не делает – но он делает Протокол требований. Протокол требований – тоже документ.

Четвертая часть. Жизненный цикл требований

В заключение – три слова скажу о жизненном цикле требований. Я уже говорил, что требование проникает во все процессы управления проектом, и во все этапы работ. В идеальном случае – нам нужно понимать, где это требование находится. Что с ним происходит с самого начала – с того момента, как мы его выявили и по всей цепочке, находится ли это требование сейчас в разработке или оно сейчас находится в тестировании… Включено ли это требование в программу обучения, находится на этапе внедрения, или, может, оно уже находится в эксплуатации….

Конечно же, нужно стараться, чтобы требования были идентифицируемые. Идентификация может осуществляться по-разному. Самый простой способ – это просто сквозная нумерация (1,2,3,4…). Чтобы всегда можно было сослаться на то, что «требование № 526 не сделано». В этом случае процесс приемки-сдачи работ будет протекать гораздо более гладко и не будет таких проблем.  

Как решать проблемы раздувания требований?

Важный момент по управлению требованиями:

Вот этот треугольник – это границы нашего проекта. Эта картинка предназначена для понимания проблемы раздувания требований.  

Все мы знаем, что, когда идет проект, все начинают накидывать какие-то требования со всех сторон. Директор говорит – нам нужно еще вот это, начальники кричат – что чего-то еще у них не хватает, а пользователи начинают говорить про разные кнопки, колонки и т.д.

Что с этим можно делать? Если это требование верхнего уровня, которое, в принципе, расходится с изначальными целями, то тут два варианта. Первый – сразу объяснить заказчику, что мы это выносим в новый проект. Второй – то же самое, объяснить заказчику, что мы это выносим в новый этап (с расширением, естественно, границ бюджета, сроков и т.д.)

Если уже какие-то конкретные функциональные требования выдвигаются (например, использование торгового оборудования – на этапе формулирования задачи не было, а потом – решили добавить), то самое логичное – это просто расширить требования, либо, как альтернативный вариант – делегировать эту задачу на IT-службу заказчика (тем самым, границы проекта остаются в тех же самых своих рамках).

А вот когда у нас начинается раздувание за счет потока пользовательских задач и там 200 человек и каждый из них что-то говорит, — то в этом всем можно просто «зашиться», потому что все, что они говорят, может вообще мало иметь отношение к тем самым ключевым требованиям. Тут какие есть варианты: можно использовать свои внутренние резервы, которые у нас должны были быть изначально на проект заложены, как раз для вот таких вот пользовательских доработок в части интерфейса, удобства и так далее. Но если эти пожелания явно уже вылезают за рамки проекта, либо у нас резерв не предусмотрен, то у нас есть два варианта. Либо мы объясняем, что мы реализацию этих пожеланий переносим за рамки проекта на какой-то уровень сопровождения, либо – в крайнем случае, когда больше ничего не остается – проще от них тогда отказаться. Это редко бывает, конечно. Можно, конечно, пытаться все реализовать, но этот процесс может быть бесконечным.  

*************

Приглашаем вас на новую конференцию INFOSTART EVENT 2024 INCEPTION.