Коммуникация с клиентами. Формальное ТЗ. Протокол общения

Здравствуйте,

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

Больше всего интересует вопрос формальностей. А именно

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

2. В каком формате или нескольких форматах представлять это ТЗ. Заказчику иногда даже Use Case диаграммы не понятны. А обычно Use Case диаграммы отображают бизнес процессы и чуть домена самого. Функциональные, пользовательские, бизнес, финансовые требования все важные при обсуждении проекта и составлении этого «ТЗ»

3. Непосредственно самый главный пункт вопроса, какие использовать инструменты, типы диаграмм, формальное описание и т.д. То есть как представить идею и требования в каком-то виде.

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

Спасибо

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ИМХО:
Сложно ответить одним абзацем, да и наверное нет той «серебряной пули» которая поможет всем.
Некоторые предлагают поменьше оформлять...возможное такое и подходит, когда круг участников с обеих сторон очень не велик. Когда информация циркулирует легко, все ее понимают и быстро согласовывают. Но даже в таком случае, наступает момент когда все это уже не держится в голове, и снова происходит возврат к ситуации «Подождите! Мы же договаривались!?!? Помнишь ....?».
Если речь идет о более менее правильном подходе, то должна быть построена система документирования которая в целом будет давать больше пользы, хотя и требовать больше затрат (т.е. времени и усилий). И здесь конечно очень важен масштаб: чем больше в проекте участников, чем он больше по трудоемкости, чем он длительней по времени — тем более полезно (а возможно и необходима) будет выработка правил, стандартов, форматов документирования.
Для меня лично это признак профессионализма, если подрядчик/исполнитель ИТ услуг начиная работу на проекте — уже привносит с собой эти проработанные, и проверенные временем и опытом вещи. Можно сделать исключение наверное если каждый новый проект каждый раз связан с новым бизнес-доменом, платформой, тех.стеком и т.д.
Если же это проекты одного «направления», и у исполнителя «на коленках» происходит формирование подхода к документированию проекта и разработки....то это — "прискорбно..."©
Собственно к делу: конечно основная сложность это понимание и передача информации. Какой выбрать способ, что бы такие разные стороны — все таки более менее понимали друг друга?
У меня нет правильного ответа. Для описания процессов мне импонирует BPNM и IDEF0. С помощью них можно как то верхне-уровнево описать процесс. Use Case — диаграммы мне кажутся не интуитивно понятными например. Также у схем и диаграмм есть существенный недостаток — трудоемкость создания и внесения изменений.
И да — они только очерчивают основные процессы, элементы и компоненты системы. Дальше необходимо как то описывать суть технических решений: ТЗ/спецификации. Но они очень непонятны обычному заказчику, он или их не принимает вообще или согласовывает бездумно. И то и другое оборачивается плохо для проекта. Самой правильной стратегий было бы подобрать такой вариант этих документов которые бы стали понятны заказчику на этапе обследования/проектирования.
Нужно пробовать и получая фидбек, искать формат такого документа.
Мне лично очень понравились сценарии использования (UseCases). Мощная штука при ее простоте. Во первых это просто текст на свободном языке с возможностью быстро их создавать и переделывать. Можно идти по верхне-уровневому процессу, постепенно декомпозируя его. Можно не погружаться сразу в детали, или не погружаться в некритичные\ несложные вещи, а уделять время важным вещам — углубляя их — описывая как это будет происходить, добавляя альтернативные сценарии. Можно делать переходы на другие сценарии — таким образом уже выделяя компоненты/блоки функциональности.
Небольшие по объему сценарии легко читаются заказчиками, если они описаны простым языком и используют реальные примеры из предметной области заказчика. Такой формат позволяет описывать например, какими сущностными оперируем, какая есть логика обработки, как строится процесс, какие участники/роли участвуют в сценарии. Этот же документ может читать
ся разработчиками помогая им погрузиться в проект, и сократить время аналитикам на передачу информации в другую сторону.
Для описания каких то важных технических решений, можно использовать формат верхне-уровневой спецификации\решения. Что является важным, это конечно сфера ответственности и интуиции бизнес-аналитика — увидеть это, выделить, описать и донести до заказчика что именно эта вещь важна и она будет реализована примерно вот-так вот, и она влияет на то-то и там-то.
Дополнительно, можно еще использовать элементы классики — входные запросы и исходящая информация, в самом общем виде. Т.е. промоделировать основные требования: что нужно сделать что бы получить/сделать то то, как я смогу получить такую вот информацию. Это поможет понять хватает у системы компонентов/элементов и не пропустили/забыли что то важное.
Чисто технические документы, предназначенные для разработки — крайне сложны и не понятны. Да и скорость/трудоемкость их создания не позволяет им помочь на этапе обследования\проектирования\согласования проекта.
Как то так :)

заведи анкету для клиента,так хоть будет понятно что нужно

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

Бюрократия — это очень плохая идея. Она неминуемо приведёт к тому, что руководство начнёт слышать то, что оно хочет слышать, а голос клиента утонет в «формальном общении».

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

Как обычно, надо разделить на 47 :) но по сути верно: формализовать приходится коммуникацию на тех проектах, которые катятся в задницу :(

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

Підписатись на коментарі