Словарь проекта между бизнесом и ИТ: как договориться о терминах, которые все понимают по-разному
На встрече заказчик говорит, что после согласования заявка должна перейти в статус «Исполнена». Аналитик записывает это в требования, разработчик реализует переход, а во время тестирования выясняется, что бизнес под словом «исполнена» имел в виду только завершение работы сотрудника, после которого заявку еще должен проверить руководитель. Все участники несколько недель пользовались одним и тем же термином и были уверены, что понимают друг друга.
Сложные профессиональные слова в этом смысле даже безопаснее, потому что незнакомый термин обычно сразу вызывает вопрос. Гораздо чаще проблемы возникают с обычными «заявками», «договорами», «клиентами», «согласованиями» и «статусами», смысл которых кажется настолько очевидным, что никто не считает нужным его уточнять. На проекте с несколькими подразделениями и информационными системами один привычный термин при этом вполне может обозначать три разных объекта.
Поэтому словарь проекта нужен не как энциклопедия определений, а как место, где зафиксированы именно спорные понятия, способные изменить требования. Если неправильное понимание слова может привести к другому маршруту, другой структуре данных или другой логике программы, значение лучше договорить заранее.
Сначала стоит искать не термины, а места, где люди перестают понимать друг друга
Собирать словарь со списка всех существительных, которые звучат на обследовании, смысла нет. А вот обращать внимание на моменты, когда один сотрудник поправляет другого: «у нас это не заявка, а обращение», «согласованным мы считаем только после директора», «для бухгалтерии клиентом считается уже контрагент», «в старой системе это называлось проектом, хотя по сути это заказ», намного полезнее.
Именно такие фразы показывают, что за названием скрывается разный смысл. Иногда спор можно закрыть за несколько минут прямо на встрече, а иногда выясняется, что два подразделения годами используют один термин по-разному и эта разница уже отражена в их процессах. Во втором случае недостаточно выбрать формулировку, которая больше нравится аналитику, потому что сначала придется определить, какое значение должно использоваться в рамках нового решения.
«Документ» - хороший пример того, как быстро начинается путаница
На проектах по внедрению 1С:Документооборота слово «документ» особенно показательно. Для обычного пользователя документом часто является файл Word или PDF, для делопроизводителя - зарегистрированная карточка с номером, датой и файлом, а разработчик 1С вполне может услышать в этом слове конкретный объект метаданных.
Пока обсуждение идет на общем уровне, разница почти незаметна, но стоит появиться требованию «после подписания документ нужно передать в ERP», и сразу возникает несколько вариантов: передается файл, реквизиты карточки, электронная подпись, ссылка на объект или в ERP вообще создается новый объект на основании данных из 1С:ДО. Если оставить исходную формулировку без расшифровки, разработчику все равно придется возвращать вопрос аналитику.
По той же причине нужно аккуратно обращаться со словами «карточка», «договор», «письмо», «заявка», «заказ» и «обращение». Например, бизнес может называть договором всю историю взаимоотношений с поставщиком, тогда как в системе существуют основной договор, дополнительные соглашения, приложения и отдельная карточка контрагента. Пока в требованиях используется просто «договор», каждый участник будет дорисовывать недостающий смысл самостоятельно.
В словаре полезно фиксировать именно рабочее значение. Не «Договор - соглашение сторон о возникновении гражданских прав и обязанностей», а, например, «Договор - внутренний документ определенного вида в 1С:ДО, который содержит основной файл договора и связан с контрагентом; дополнительные соглашения оформляются отдельными связанными документами». Второй вариант не претендует на юридический словарь, зато помогает проектной команде одинаково читать требования.
Со статусами проблема обычно обнаруживается слишком поздно
«Согласован», «Утвержден», «Исполнен», «Закрыт» выглядят настолько понятными состояниями, что на обследовании им часто уделяют меньше внимания, чем они заслуживают. Потом оказывается, что для одного подразделения договор считается согласованным после завершения маршрута согласования, для другого - только после окончательного решения руководителя, а кто-то вообще использует это слово для предварительного подтверждения по почте.
Если статус существует только для удобства пользователя, расхождение еще можно пережить, но как только от него зависит автоматическое действие, интеграция или отчетность, название уже нужно связывать с конкретным условием. Вместо определения «Согласован - договор согласован всеми участниками» полезнее зафиксировать, кто именно должен завершить какие действия и что происходит после последнего согласования.
То же относится к переходам назад. Если документ уже утвержден, можно ли вернуть его на доработку, остается ли старое утверждение действующим и какой статус при этом получает объект? Такие вопросы относятся уже не столько к словарю, сколько к требованиям, однако именно спор о значении термина часто помогает их обнаружить.
Согласование, утверждение и ознакомление лучше развести еще на обследовании
В разговорной речи эти действия часто смешиваются, особенно если в текущем процессе все происходит через почту. Сотрудник говорит, что директор должен «согласовать» инструкцию, хотя на самом деле решение директора окончательное и после него документ вводится в действие, то есть речь идет уже об утверждении. Ознакомление тоже иногда называют согласованием только потому, что пользователь получает задачу и должен нажать кнопку ее завершения, хотя его мнение никак не влияет на документ.
Если потом эти слова без изменения переходят в ТЗ, команда начинает спорить уже вокруг конкретных настроек. Поэтому достаточно один раз договориться, что именно в этом проекте считается согласованием, что утверждением, а что ознакомлением, после чего использовать выбранные термины одинаково в требованиях, протоколах, схемах и карточках задач. Особенно это полезно при внедрении 1С:ДО, где эти действия действительно ведут себя по-разному.
На стыке нескольких систем одно слово может обозначать совершенно разные объекты
Интеграционные проекты особенно быстро выявляют терминологические расхождения. Например, отдел продаж говорит о «заказе», имея в виду всю работу с клиентской потребностью, в CRM этому соответствует сделка, в ERP появляется заказ клиента, а в 1С:Документообороте с той же историей могут быть связаны договор и пакет внутренней документации. Требование «при изменении заказа передать информацию в 1С:ДО» в такой ситуации нельзя реализовать, пока не определено, о каком объекте речь.
Удобно разделять бизнес-термин и его представления в информационных системах. Например: «Проект» для бизнеса - инициатива по выполнению работ для заказчика; в ERP ему соответствует такой-то объект, а после старта работ в 1С:ДО создается проект с тем же внешним идентификатором. Тогда участники могут продолжать пользоваться привычным бизнес-языком, но разработчик понимает, с какими конкретными сущностями он работает.
Отдельного этапа «теперь составим словарь» обычно не требуется
Полезные определения появляются прямо во время обследования, поэтому собирать их задним числом по готовым протоколам неудобно. Если на встрече выяснилось, что бухгалтерия и коммерческий отдел по-разному понимают «клиента», этот термин сразу попадает в список на уточнение; если все одинаково употребляют понятие «подразделение» и оно соответствует одному понятному справочнику, отдельной работы с ним не требуется.
Особенно внимательно нужно относиться к словам, которые компания унаследовала от предыдущей информационной системы. Пользователи могут еще несколько лет говорить «карточка КС», «лист согласования» или «задача архива», хотя после перехода на новую систему прежнего объекта уже не существует. Иногда старое название без проблем остается пользовательским синонимом, но бывают случаи, когда оно начинает вводить новых сотрудников в заблуждение, потому что напоминает совсем другой механизм.
Если во время обследования значение остается спорным, его нельзя молча трактовать в ту сторону, которая кажется очевидной. Нужно зафиксировать вопрос, определить владельца процесса и добиться решения до того, как спорное понятие начнет повторяться в десятках требований.
Сам словарь лучше сделать коротким
Для большинства проектов не требуется отдельный многостраничный документ с формальными определениями. Достаточно термина, рабочего значения, при необходимости синонимов и соответствия объектам системы. Если понятие особенно часто путают с соседним, можно одной фразой указать отличие.
Например: «Заявка на закупку - внутренний запрос подразделения на приобретение товара или услуги, который создается до заказа поставщику. Не является заказом поставщику. В 1С:ДО соответствует документу вида “Заявка на закупку”». Такой записи вполне достаточно, чтобы аналитик, разработчик и сотрудник заказчика обсуждали один объект.
Не нужно добиваться академической точности там, где она ничего не дает проекту. Хорошее определение может звучать довольно просто, если оно однозначно объясняет, что участники имеют в виду.
Если подразделения используют разные значения, это тоже нужно показать
Иногда единого определения просто нет. Для отдела продаж «клиент» может включать потенциальную компанию, с которой пока не заключен договор, тогда как бухгалтерия вообще не использует этот термин и работает с контрагентами. Искусственно заставлять всех изменить привычный язык ради словаря необязательно.
В таком случае достаточно зафиксировать, какое значение используется в конкретном процессе и что ему соответствует в системе. Главное, чтобы в самих требованиях не происходило незаметного переключения между двумя значениями одного слова.
Определение подтверждает бизнес, а не аналитик
Аналитик собирает формулировки, замечает противоречия и показывает, чем они могут закончиться, однако назначать компании новую терминологию только потому, что она кажется более логичной, не стоит. Если от определения зависит бизнес-правило, его должен подтвердить владелец процесса или другой сотрудник, который вправе принять такое решение.
Предположим, два подразделения по-разному определяют момент, когда обращение клиента считается закрытым. Это уже не спор о словах: выбранное значение повлияет на расчет сроков, отчетность и, возможно, KPI. Сначала нужно согласовать само правило работы, и только после этого словарь фиксирует результат.
После договоренности термин нужно использовать одинаково
Словарь быстро теряет смысл, если один объект в нем называется «заявкой», а дальше в ТЗ тот же объект превращается то в «обращение», то в «запрос». Синонимы можно оставить для поиска и пояснений, но в проектной документации лучше выбрать основное название и придерживаться его.
Это касается не только текста требований, но и схем, протоколов, карточек задач и, если возможно, интерфейса будущей системы. Чем дольше проект и чем больше людей в нем участвует, тем полезнее единый язык, потому что исходный контекст постепенно забывается.
Какие вопросы стоит задавать на обследовании
Отдельное интервью ради словаря обычно не требуется, однако несколько вопросов полезно держать в голове во время разбора процессов:
- Какие основные объекты участвуют в процессе и как их называют разные подразделения?
- Есть ли понятия, которые сотрудники используют в нескольких значениях?
- Чем отличаются близкие термины: заявка и заказ, клиент и контрагент, согласование и утверждение, исполнение и закрытие?
- Какие названия пришли из старой информационной системы и что стоит за ними сейчас?
- Какие состояния проходит объект и какое событие означает переход в каждое состояние?
- Есть ли одинаковые термины в CRM, ERP, 1С:ДО и других системах, за которыми скрываются разные объекты?
- Какому объекту системы соответствует каждый значимый бизнес-термин?
- Кто принимает решение, если подразделения не могут договориться о значении?
- Какие синонимы можно оставить в обычной речи, но не стоит использовать в требованиях?
Словарь нужен не ради словаря
На небольшом проекте отдельный глоссарий иногда действительно не нужен, потому что пять ключевых определений можно разместить прямо в спецификации. На крупном внедрении, где участвуют несколько подразделений и информационных систем, отдельный словарь уже намного удобнее, особенно если он обновляется по мере появления новых понятий, а не создается однажды на старте и забывается.
Проверка его пользы довольно простая: если после фиксации определения больше не приходится на каждой встрече уточнять, какую именно заявку, статус или договор имеют в виду участники, значит документ выполняет свою работу. Если же словарь разросся до нескольких страниц очевидных терминов, но команда продолжает спорить о тех же словах, значит в него попало слишком много справочной информации и слишком мало реальных договоренностей.
В конечном итоге речь вообще не о терминологии как таковой. Разработчик реализует не слова, а смысл, который за ними стоит, поэтому задача аналитика состоит в том, чтобы этот смысл не менялся в зависимости от того, кто сегодня участвует во встрече. Несколько вовремя уточненных определений иногда снимают больше вопросов, чем дополнительная страница подробного ТЗ.