10 правил и немного занудства / Хабр

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия

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

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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM. Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ— позже.

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

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

Сбор и анализ требований

Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.

Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик

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

Есть очень простая схема сбора требований.

1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.
   

После того, как требования собраны, проанализированы и согласованы с сотрудниками и руководством, можно приступать к созданию технического задания. Вы можете попросить форму у вендора или составить его самостоятельно — в любом случае есть несколько железных правил, соблюдение которых избавит от головной боли и вас, и вашего поставщика CRM.

Анатомия технического задания

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

• Выявление — определение требований, поиск проблем, которые необходимо решить.
• Анализ — разбор требований, выделение ключевых потребностей, обобщение.
• Адаптация — оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
• Документирование — формальное и подробное описание требований, согласование ТЗ.
• Общение с вендором (разработчиком) — итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
• Реализация — работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком — так продукт на выходе будет наиболее точно соответствовать видению клиента.
• Тестирование — проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.
  

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

Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail.

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

Уровень функциональности. Зачастую его трудно отделить от предыдущего, здесь работает формальный критерий — доработка не на уровне отображения чего-либо в интерфейсе, а на уровне доработки логики системы. Сюда можно отнести требования к различного рода сортировкам, интеграциям с чатом, возможностям телефонии.

Уровень сервиса — на самом деле, требования этого уровня должны первыми попадать в новые сборки с фиксами. Это задачи по скорости отклика системы, работе под высокой нагрузкой, безопасности. В идеальном варианте у вендора не должно быть таких доработок — корпоративный софт не должен тормозить, терять данные, схлопывать формы и раздавать права доступа одного уровня. Но если требование появилось, и оно не связано с персональной паранойей заказчика или проблемами на стороне аппаратного обеспечения, стоит уделить ему повышенное внимание.

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

Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.

Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

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

Параметры технического задания — сроки, этапы реализации, ответственные от всех сторон, необходимые контакты и проч. Фактически это совокупность важных формальных вещей, делающих документ техническим заданием. Техническое задание обязательно должно быть согласовано и подписано сторонами во избежание многочисленных изменений по ходу разработки (они всё равно будут, но в меньшем объёме).

В идеальном варианте техническое задание составляется при активном участии вендора, и его итог представляет собой примерно такую структуру:

1. Описание требования каждого механизма и каждой функциональности
   
2. Описание реализации данной функциональности
   
3. Стоимость работ по каждому из этапов в отдельности
   
4. Общая стоимость работ по данному техническому заданию
   
5. Сроки исполнения работ с разбивкой по этапам и указанием очерёдности
   
6. Описание условий установки и тестирования доработки
   
7. Оговорки об исчерпывающем характере технического задания и иные условия
   

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку, а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией — скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) — возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

Техническое задание должно быть реалистичным и выполнимым — как по требованиям, так и по срокам. Здесь важно прислушиваться к мнению вендора, поскольку он точно знает, какое время уйдёт на ту или иную задачу. Поверьте, разработчику не выгодно тянуть время и накручивать срок — ему выгодно завершить как можно больше проектов и сделать это хорошо, чтобы не получить удар по репутации. Что касается реалистичности, то избежать просьб допилить CRM до уровня системы управления коллайдером просто: следует включать в требования то, что действительно нужно на данный момент и в обозримом будущем.

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

Не нужно путать с ситуацией, когда речь идёт о заказной разработке и в корне меняется идея и логика работы приложения, фактически спонсируется создание нового программного обеспечения «под себя». Но это другая история.

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

Техническое задание должно быть однозначным и точным. Расплывчатые формулировки, варианты реализации, нечёткие требования — всё это путь в тупик. Бывает, что клиент из благих намерений пишет в ТЗ несколько вариантов поведения системы, близких, но не равнозначных. В этом случае он уверен, что помогает, подсказывает программисту, но на самом деле благими намерениями устлана дорога в ад разработчик должен понимать, что именно нужно, а как это сделать он выберет сам, исходя из особенностей системы и стека используемых технологий.

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

Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.

1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.
   

И ещё — не используйте редакторы типа Microsoft Visio и UML-диаграммы, если вы в них не разбираетесь. То, что кажется красивым и деловым, на взгляд разработчика оказывается адской путаницей. Если хочется вставить схему или картинку — нарисуйте её человеческими методами, не утруждайте себя, это нам, разработчикам, ничем не поможет.

Техническое задание не должно быть жалобной книгой. Нужно решать проблему, а не описывать её, уделяя внимание шрифтам и забывая об описании требований. ТЗ должно содержать не только саму проблему, но и её решение на уровне осмысления — далее разработчик уже решит её на уровне кода. Сравните «отдел продаж плохо планирует, теряет цифры, уже год боремся» и «необходимо создать отчёт, который будет сохранять значения плана и факта продаж ежемесячно, в разрезе групп номенклатуры».

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

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

Техническое задание должно быть техническим заданием. Звучит парадоксально, но часто вместо ТЗ мы читаем письма, жалобы, договоры, заново написанную инструкцию к CRM или протокол совещания. Конечно, работать по такому документу невозможно. Для того, чтобы не уйти от формы и содержания, воспользуйтесь старой школьной уловкой: рассмотрите термин по словам. Техническое — значит, диктует доработку, технику, направлено на решение задачи посредством изменения ПО. Вот о задаче в контексте ПО и нужно говорить. Задание — значит, постановка вопроса, проблемы, без советов, подсказок и предварительных оценок. Просто формулировка задачи.

Заповеди закончились, теперь отповедь

Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.

Техническое задание нужно писать быстро, даже если перед вами стоит задача автоматизации процессов сотового оператора или крупного гипермаркета. Это связано с тем, что технологии развиваются с огромной скоростью и даже та система, которую вы внедряете, за полгода-год может пережить мажорный релиз (а иногда и два), получить новую функциональность. Возможно, придётся пересмотреть необходимость доработок и начать процесс заново.

Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

Оценить бюджет и избежать неприятных сюрпризов — едва ли не совместная задача номер один. Не стоит дёргать вендора и требовать от него примерной оценки работ (ну хоть приблизительно, навскидку, на глазок, а как у других, ну в проектах такого типа, а по опыту, ну так, в пределах погрешности). Полная оценка бюджета возможна только после прочтения, анализа и окончательного утверждения технического задания. Если ваш разработчик поступает иначе — готовьтесь к тому, что доработка обойдётся минимум в два раза дороже.

Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.

---

Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

---

Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт, там много о CRM, её преимуществах и прочем корпоративном софте.

И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]

Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

Системы управления знаниями – обзор зарубежного опыта

Что из себя представляет система управления знаниями? Поскольку сама концепция зародилась за рубежом, за ответом на этот вопрос мы обратились к зарубежным источникам. Перед вами перевод популярной статьи “What is KM? Knowledge Management Explained” Майкла Е.Д. Кёнига — профессора и бывшего декана Колледжа информационных технологий и информатики Университета Лонг Айленда.

В этой статье мы рассмотрим:

• Что такое управление знаниями?
• Состав системы управления знаниями в IBM
• Явные, потенциально явные и неявные знания
• Составляющие систем управления знаниями
• Базы извлеченных уроков
• Определение местонахождения компетенций
• Сообщества специалистов-практиков
• Стадии развития систем управления знаниями
• Проблемы систем управления знаниями
• Есть ли будущее у концепции управления знаниями?

Что такое система управления базами знаний?

Управление знаниями (knowledge management) — это концепция, которая появилась примерно два десятилетия назад, где-то в 1990х. Пожалуй, можно сходу дать определение термину “управление знаниями” — это организация и систематизация информации и знаний в компании. Однако это определение звучит как-то расплывчато и слишком широко, но при этом — как ни странно — не дает увидеть полной картины. В самом начале становления систем управления знаниями Томас Давенпорт предложил определение, которым пользуются до сих пор:

«Управление знаниями — это процесс сбора, распространения и эффективного использования знаний».

Несколько лет спустя Gartner Group предложила более подробное определение:

«Управление знаниями — это система, которая предполагает интегрированный подход к поиску, сбору, оценке, восстановлению и распространению всех информационных активов предприятия. В состав таких активов могут входить базы данных, документы, политики, процедуры, а также знания и опыт отдельных работников, которые ранее не фиксировались».

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

Состав системы управления знаниями на примере IBM

Чтобы наиболее наглядно изобразить, что входит в состав системы управления знаниями, рассмотрим таблицу для консультантов по управлению знаниями, разработанную в IBM. Она основывается на разграничении процессов сбора информации и объединения людей. Мы приводим ее с небольшими изменениями:

	Сбор информации и кодификация	Соединение людей и персонализация
Прямой поиск и использование информации и знаний	Внутренние и внешние базы данных Архитектура контента Поддержка информационной службы (необходимо обучение) Сбор данных о лучших практиках (best practices)/ вынесенных уроках (lessons learned) и анализе проделанной работы	Сообщества и обучение Указания, система “желтых страниц”, менеджеры компетенций (expertise locators – специалисты, которые владеют информацией о знаниях и навыках каждого члена коллектива и могут подбирать подходящих людей для выполнения поставленной задачи. Это актуально для крупных компаний с большими штатами сотрудников – прим. перев.) Инструменты, облегчающие поиск информации, программы для коллективного использования Команды реагирования на запросы
	СОБИРАЕМ УРОЖАЙ (HARVEST)	ЗАПРЯГАЕМ (HARNESS)
Интуитивное исследование и изучение	Культурная поддержка Повышение осведомленности о существующих профилях и базах данных Сбор информации, которая пригодится в чрезвычайных ситуациях или в условиях сильного давления Поиск информации о лучших практиках	Культурная поддержка Пространство — физическое и виртуальное: библиотеки, комнаты отдыха; культурная поддержка и программы для коллективного использования Путешествия и посещение встреч и мероприятий
	ОХОТИМСЯ (HUNTING)	СТРОИМ ГИПОТЕЗЫ (HYPOTHESIZE)

Источник: Том Шорт, старший консультант по управлению знаниями в IBM Global Services

Явные, потенциально явные и неявные знания

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

Явные: информация или знания, зафиксированные на материальных носителях.

Потенциально явные: информация или знания, которые еще не зафиксированы в материальной форме, но могут быть преобразованы в явные.

Неявные: информация или знания, которые сложно зафиксировать на материальных носителях.

В предметной литературе распространен классический пример “неявных” знаний от бизнесменов Нонака и Такеучи: для разработки и запуска в производство домашней хлебопечки требовались такие “кинестетические” знания, которые инженеры могли получить только работая рука об руку с пекарями и изучая ощущения от замешивания настоящего хлебного теста (Нонака и Такеучи, 1995).

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

Составляющие систем управления знаниями

Из чего состоит система управления знаниями? Очевидный ответ: из информации и данных, которые доступны всем членам организации через специальные порталы и системы управления контентом (content management systems). Система управления контентом — это наиболее очевидная и оперативная составляющая системы управления знаниями. Однако существуют еще три очень важных составляющих:

Базы извлеченных уроков (lessons learned)

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

Ранее в управлении знаниями использовался термин “лучшие практики” (best practices), но “извлеченные уроки” вскоре пришли на смену этому термину. Почему? Термин “извлеченные уроки” шире и содержательнее, в то время как “лучшие практики” ограничены по значению и явно подразумевают наличие какой-то одной “лучшей практики” для каждой ситуации. То, что в Северной Америке является лучшей практикой, может быть совершенно неуместным в контексте другой культуры. По инициативе ведущих международных консалтинговых фирм термин был заменен. Тем не менее, “лучшие практики”, а позднее “извлеченные уроки” стали отличительной чертой системы управления знаниями на ранних этапах развития.

История происхождения “извлеченных уроков”

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

Военные являются ярыми сторонниками концепции извлеченных уроков. Они обозначают уроки специальным термином: “отчет по результатам операции” (after action report). Суть концепции очень проста: не стоит полагаться на то, что сам участник операции подготовит отчет. Скорее всего, по завершении операции будет множество других дел, требующих его внимания. Должна существовать система, в рамках которой выделенный специалист по управлению знаниями проведет опрос участника операции, “отделит зерна от плевел” и обеспечит сохранение и распространение извлеченных уроков.

Современные примеры использования “извлеченных уроков”

Концепция извлеченных уроков ни в коем случае не сводится только лишь к военной отрасти. Лэрри Прусак (2004) описывает одно из самых слабых (по его мнению) мест корпоративных систем управления знаниями: зачастую по мере завершения проекта не проводится “разбор полетов” и не создается “отчет по результатам операции” — проектные команды быстро расформировываются, а члены команды назначаются на другие проекты. Организациям, которые работают по принципу проектных команд, необходимо уделять больше внимания сбору информации об извлеченных уроках и выделить ответственного за проведение такого рода работ.

Отличный пример “извлеченного урока” приводит консультант по управлению знаниями Марк Мацци (2003). История произошла, когда он работал в отделе управления знаниями в фармацевтической компании Wyeth. Компания Wyeth только что выпустила на рынок новый препарат для детей. Предполагалось, что продажи нового препарата будут выше, чем предыдущих: новое лекарство нужно было принимать раз в день, благодаря чему родителям было проще обеспечить соблюдение режима лечения.

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

Недостатки системы извлеченных уроков

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

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

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

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

Определение местонахождения компетенций (expertise location)

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

Назначение системы местонахождения компетенций очевидно: поиск сотрудников организации, которые обладают знаниями в той или иной области. Такие системы раньше называли системами “желтых страниц”, но позднее появился более точный термин: expertise location — определение местонахождения компетенций.

Информационное обеспечение системы местонахождения компетенций происходит по трем каналам. Первый канал — это компетенции, указанные в резюме работников. Второй канал — это компетенции и области знаний, которые работники указывают в ходе самостоятельной оценки своих навыков (обычно это происходит посредством онлайн-анкетирования). И, наконец, третий канал — информация, автоматически полученная путем анализа входящих и исходящих коммуникаций работника. В состав анализируемых коммуникаций обычно входит email-переписка, а также активность в социальных сетях, таких как Twitter и Facebook.

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

Сообщества специалистов-практиков (communities of practice, CoPs)

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

Разговоры и обсуждения у кулера с водой в компаниях воспринимаются как должное, но если компания находится в разных географических регионах, необходим некий виртуальный “кулер с водой”. По тому же принципу, когда работники компании переходят с офисной работы на удаленную, необходимо создать им определенную виртуальную среду общения. В контексте систем управления знаниями под сообществами специалистов-практиков обычно понимаются группы специалистов, связанные посредством электронных каналов коммуникации. Преимущественно электронная природа связей объясняется тем, что сами системы управления знаниями зародились как способ обмена знаниями между географически удаленными подразделениями организации.

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

Организация и обслуживание сообществ специалистов — не такое уж простое дело. Как отмечает Мери Дарем (2004), необходимо наличие как минимум трех ключевых ролей: менеджер, модератор и идейный лидер. Это не обязательно должны быть разные люди, но иногда это предпочтительно. Вот несколько вопросов, которые нужно продумать при формировании сообщества специалистов:

• Кто будет выступать в роли менеджера/модератора/идейного лидера?
• Каким образом будет осуществляться управление сообществом?
• Каждый ли сможет делать публикации в сообществе или предусмотрена система проверки/утверждения постов?
• Как планируется поддерживать сообщество живым и интересным?
• Когда и как (по каким правилам) удаляются посты?
• Каким образом архивируются удаленные посты?
• Кто проводит проверку активности сообщества?
• Кто ищет новых членов сообщества или выступает критиком степени полезности сообщества?

Как построить систему управления знаниями: опыт российских компаний

Paolo Conte Компания запустила смешанное обучение для директоров региональных магазинов. Программа рассчитана на три года. В основе очные тренинги: сотрудников учат подбирать персонал, управлять KPI подчиненных. Дистанционно директора закрепляют пройденный материал: проходят электронные курсы по теме, решают тесты. Благодаря подходу за два года компания вдвое повысила профессиональный уровень директоров магазинов, значительно увеличила дополнительные продажи и базу постоянных покупателей. Читать подробнее →

Inventive Retail Group Компания дистанционно обучает продавцов из 333 магазинов по всей России при помощи электронных курсов, диалоговых тренажеров и электронных тестов. Сотрудники могут открыть материал с телефона, планшета или компьютера в любое время. Многие учатся на рабочем месте, пока нет клиентов. Результат: качество сервиса в магазинах увеличилось на 40%, продавцы досконально выучили свойства каждого продукта и могут грамотно рассказать о его преимуществах клиенту. Читать подробнее →

Стадии развития систем управления знаниями

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

Первая стадия: Информационные технологии

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

Термин “управление знаниями” впервые запустила консалтинговая компания McKinsey. Они быстро поняли, что создали отличный новый продукт, и в 1992 году Эрнст и Янг организовали первую конференцию по управлению знаниями в Бостоне. Главным результатом первой стадии развития систем управления знаниями стало то, что для повышения эффективности обмена знаниями и информацией стали использоваться новые технологии.

Первую стадию развития систем управления знаниями хорошо характеризует известное высказывание бывшего генерального директора Texas Instruments: “Если бы мы только знали, что мы знаем!» Именно на первой стадии в системах управления знаниями появились “лучшие практики” и “извлеченные уроки”.

Вторая стадия: Человеческие ресурсы и корпоративная культура

Развитие систем управления знаниями вступило во вторую стадию, когда стало понятно, что простое использование технологий не обеспечивает достаточно эффективного обмена информацией и знаниями. Необходимо было задействовать самих людей и культурные аспекты их взаимодействия. Вторую стадию можно было бы описать фразой про бейсбольное поле из старого фильма “Поле чудес”: “Если ты построишь его, они придут”. Хотя, если не уделить достаточное внимание человеческому фактору, такой подход легко может привести к быстрому и очень обидному провалу.

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

На второй стадии в системах управления знаниями появляются “сообщества специалистов-практиков”. Ключевым событием, ознаменовавшим переход от первой стадии ко второй, стала конференция The Conference Board 1998 года, которую посетило значительное количество специалистов из HR-подразделений. А в 1999 году количество специалистов по управлению человеческими ресурсами среди посетителей конференции впервые превысило количество IT-специалистов.

Третья стадия: Систематика и управление контентом

Осознание важности контента, а точнее его систематизации (то есть упорядочения, описания и структурирования) положило начало третьей стадии. Организации осознали, что в информации нет никакого толку, если нет возможности быстро отыскать нужные данные при необходимости. Так на третьей стадии в системах управления знаниями появились термины “систематика” и “управление контентом”. Тема управления контентом впервые была затронута на конференции KMWorld в 2000 году, а в 2001 на той же конференции управление контентом стало одной из самых обсуждаемых тем. В 2006 году на конференции был учрежден двухдневный мастер-класс, посвященный систематике, который проводится и в настоящее время.

Проблемы систем управления знаниями

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

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

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

Есть ли будущее у концепции управления знаниями?

Ответ очевиден: есть. Возьмем хотя бы результаты библиометрического анализа: просто посчитаем количество статей в бизнес-литературе, которые описывают те или иные концепции бизнеса. Большинство таких концепций быстро набирают популярность, достигают ее пика примерно за 5 лет, а потом их показатели почти так же стремительно падают.

Ниже приведены графики популярности трех модных в последние годы концепций:

Круги качества, 1977-1986 Источник: Abrahamson, 1996	Всеобщее управление качеством, 1990-2001 Источник: Ponzi & Koenig, 2002	Реинжиниринг бизнес-процессов, 1990-2001 Источник: Ponzi & Koenig, 2002

Ситуация с управлением знаниями обстоит совершенно по-другому:

График показывает количество статей в бизнес-литературе с фразой “Knowledge Management” в заголовке.

Если добавить к этому списку статьи с аббревиатурой “KM” в заголовке, получим следующий график:

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

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

Записаться на вебинар →

14-дневная пробная версия

Если вам понравилась статья, дайте нам знать  —  нажмите кнопку Поделиться.

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

Что такое вариант использования?

Качество программного обеспечения

К

• Кейт Браш

Что такое вариант использования?

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

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

Каждый вариант использования содержит три основных элемента:

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

Характеристики варианта использования Варианты использования

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

Вариант использования должен:

• Организация функциональных требований.
• Моделирование целей взаимодействия системы и актора.
• Пути записи — называемые сценариями — от триггерных событий к целям.
• Опишите один основной поток событий и различные альтернативные потоки.
• Быть многоуровневым, чтобы один вариант использования мог использовать функциональность другого.

Как написать вариант использования

Существует два разных типа вариантов использования: бизнес-варианты использования и системные варианты использования.

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

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

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

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

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

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

Наглядный пример методологии вариантов использования, показывающий пошаговый процесс написания варианта использования.

Процесс записи включает в себя:

1. Идентификация всех пользователей системы и создание профиля для каждого из них. Это включает в себя каждую роль, которую играет пользователь, взаимодействующий с системой.
2. Выбор одного пользователя и определение его цели — или того, чего пользователь надеется достичь, взаимодействуя с системой. Каждая из этих целей становится вариантом использования.
3. Описание курса, пройденного для каждого варианта использования системы для достижения этой цели.
4. Рассмотрение каждого альтернативного хода событий и расширение вариантов использования — или различных путей, которые можно выбрать для достижения цели.
5. Выявление общих черт в путешествиях для создания общих вариантов использования курса и написания описаний каждого.
6. Повторение шагов со второго по пятый для всех остальных пользователей системы.

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

Преимущества варианта использования

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

Другие преимущества разработки вариантов использования включают:

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

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

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

Пример использования и история пользователя

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

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

Кроме того, пользовательские истории часто менее документированы, чем варианты использования, и в них намеренно игнорируются важные детали. Пользовательские истории в основном используются для создания бесед, задавая вопросы во время собраний scrum, тогда как варианты использования используются разработчиками и тестировщиками, чтобы понять все шаги, которые система должна предпринять, чтобы удовлетворить запрос пользователя.

Примеры варианта использования

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

Водитель хочет добраться из Бостона в Нью-Йорк. В этом сценарии действующее лицо — водитель, цель — добраться до Нью-Йорка, а система — сеть дорог и автомагистралей, по которым они будут добираться. Вероятно, между Бостоном и Нью-Йорком есть один распространенный маршрут, по которому водители ездят — это обычный вариант использования трассы. Тем не менее, есть различные объездные пути, которые водитель может выбрать, которые в конечном итоге все равно приведут в Нью-Йорк. Эти разные маршруты являются расширяющимися вариантами использования. Целью маршрутов движения является определение каждого поворота, который должен совершить водитель, чтобы добраться до пункта назначения.

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

.

• заказчик;
• система выполнения заказов; и
• биллинговая система.

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

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

Примечание редактора: Эта статья была написана Кейт Браш в 2020 году. Редакторы TechTarget переработали ее в 2022 году, чтобы сделать ее более удобной для читателей.

Последнее обновление: ноябрь 2022 г.

Продолжить чтение О сценарии использования

• Просмотрите эти 9 сценариев использования с малым кодом и отраслевые примеры

• 6 вариантов использования контейнеров Docker — и когда следует пройти

• Распространенные варианты использования наблюдаемости

• 10 основных вариантов использования периферийных вычислений и примеры

• Диаграммы вариантов использования UML: советы и часто задаваемые вопросы

Углубитесь в методологии Agile, DevOps и разработки программного обеспечения

• Распространенные техники боковых движений и способы их предотвращения

  Автор: Рави Дас

• Как создать профиль угроз с помощью шаблона

  Автор: Карен Скарфоне

• Lapsus$ для SharePoint, VPN и виртуальных машин

  Автор: Пейтон Дойл

• Китай становится лидером по эксплуатации уязвимостей

  Автор: Алекс Скрокстон

Облачные вычисления

• 6 разработчиков вариантов PaaS с открытым исходным кодом, о которых следует знать в 2023 году

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

• 10 лучших провайдеров PaaS 2023 года и что они вам предлагают

  PaaS — хороший вариант для разработчиков, которым нужен контроль над хостингом приложений и упрощенное развертывание приложений, но не все PaaS …

• Интерпретация и применение рекомендаций AWS Compute Optimizer

  Трудно найти правильный баланс между производительностью, доступностью и стоимостью. Узнайте, как включить и применить AWS Compute…

Архитектура приложения

• Учебник по основным концепциям структуры команды разработчиков

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

• 10 учебных курсов для подготовки к сертификации по микросервисам

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

• Признаки антипаттерна «Золотой молот» и 5 способов его избежать

  Антипаттерн «Золотой молот» может подкрасться к команде разработчиков, но есть способы его обнаружить. Изучайте знаки, а также некоторые…

ИТОперации

• Dish Media меняет возможности наблюдения на Elastic Stack SaaS

  Благодаря меньшему количеству инструментов и репозиториев данных, с которыми приходится сталкиваться, а управление эластичным кластером передано на аутсорсинг SaaS, операционные группы Dish Media …

• Оптимизация рабочих нагрузок кластера с помощью планирования емкости Kubernetes

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

• Лучшие инструменты наблюдаемости на 2023 год

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

TheServerSide.com

• Скрам против Канбана: в чем разница?

  Когда вы сравниваете Scrum и Kanban, вы понимаете, что между ними столько же общего, сколько и различий. Здесь мы поможем вам выбрать …

• Различия между Java и TypeScript должны знать разработчики

  Вы знаете Java? Вы пытаетесь изучить TypeScript? Вот пять различий между TypeScript и Java, которые сделают …

• Владелец продукта и менеджер продукта: в чем разница?

  Работа менеджера по продукту в компании сильно отличается от роли владельца продукта в команде Scrum. Узнать ключ…

ПоискAWS

• AWS Control Tower стремится упростить управление несколькими учетными записями

  Многие организации изо всех сил пытаются управлять своей огромной коллекцией учетных записей AWS, но Control Tower может помочь. Сервис автоматизирует…

• Разбираем модель ценообразования Amazon EKS

  В модели ценообразования Amazon EKS есть несколько важных переменных. Покопайтесь в цифрах, чтобы убедиться, что вы развернули службу…

• Сравните EKS и самоуправляемый Kubernetes на AWS

  Пользователи AWS сталкиваются с выбором при развертывании Kubernetes: запускать его самостоятельно на EC2 или позволить Amazon выполнять тяжелую работу с помощью EKS. См…

Веб-отношения | NCUA

Уважаемый Совет директоров:

Совет Национальной администрации кредитных союзов (NCUA) недавно утвердил Правила и положения NCUA, Часть 721, Случайные полномочия. Категории деятельности, предварительно утвержденные в качестве дополнительных полномочий, необходимых Федеральным кредитным союзам (FCU) для ведения бизнеса, включают:

• Электронные финансовые услуги (Часть 721.3(c)) — разрешает FCU предлагать с помощью электронных средств любые услуги, продукты, функции или деятельность, которые кредитный союз мог бы в ином случае выполнять, предоставлять или доставлять своим членам.
• Деятельность по поиску (Часть 721.3(f)) — разрешает FCU представлять или иным образом привлекать внешних поставщиков со своими членами для переговоров и заключения сделок. В это разрешение включена возможность кредитного союза предоставлять информацию членам о продуктах и ​​услугах третьих сторон.

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

Риски

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

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

Методология создания ссылок

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

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

Отказ от ответственности

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

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

Соответствующие политики

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

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

Соглашения

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

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

Обучение

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

• Выбор отношений с третьими лицами
• Мониторинг активности сторонних веб-сайтов
• Проведение постоянной комплексной проверки третьих сторон

Ссылки

К вашему ознакомлению прилагается недавно выпущенный Управлением контролера денежного обращения (OCC) Бюллетень OCC 2001-31, Веб-ссылки . В бюллетене OCC обсуждаются риски и связанные с ними механизмы контроля, которые кредитные союзы должны учитывать при установлении отношений по веб-ссылкам.

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

1. Письмо NCUA кредитным союзам № 01-CU-11 (август 2001 г.), основное внимание уделяет электронным аспектам безопасности данных членов;
2. Письмо NCUA кредитным союзам № 01-CU-09 (сентябрь 2001 г.), руководство о том, как кредитные союзы должны защищать информацию о членах от кражи личных данных и звонков под предлогом;
Письмо
3. NCUA кредитным союзам № 01-CU-04 (март 2001 г.), призывающее кредитные союзы рассмотреть преимущества предложения электронных финансовых услуг через Интернет членам вашего кредитного союза;
4. Письмо NCUA кредитным союзам № 01-CU-02 (февраль 2001 г.), предлагающее рекомендации по конфиденциальности финансовой информации потребителей;
5. Письмо NCUA кредитным союзам № 109 (1 сентября 1989 г.), в котором обсуждаются риски, связанные с определенными компьютерными операциями;
6. Письмо NCUA кредитным союзам № 97-CU-5, касающееся электронных финансовых услуг;
7. Письмо NCUA кредитным союзам № 00-CU-11 относительно управления рисками аутсорсинговых технологических услуг; и
8. NCUA Интерпретирующее постановление и Заявление о политике 85-1, распространяющееся на доверительных управляющих и хранителей пенсионных планов.