- PVSM.RU - https://www.pvsm.ru -
За годы работы я пришел к работающей конструкции в данной части воронки моих продаж — я всегда отвечаю на такие письма — отлично, получил, я вижу ваши пожелания к решениям в письме и, а тз вы забыли приложить?
В такой конструкции диалог не выглядит слишком агрессивным и всегда случается плавный переход в следующий шаг воронки — позитивный диалог что такое тз и что там должно быть, что еще необходимо изложить именно клиенту, а особенно что не нужно излагать клиенту, а делать это должны мы.
Соглашение о терминологии
Рассмотрим очень коротенько жизненный цикл любого замысла и его реализации в реальность:
Еще раз с сайтом или мобильным приложением:
Говоря о том что обычно может изложить клиент — это всегда пожелания, даже какие-то из них (малая часть) — потому как описать все пожелание человек не специалист не в состоянии просто по определению — не его контекст, и не должен он его понимать.
Для наглядности я изложил одному из клиентов схемку жизненного цикла одного(!) требования и по сей день показываю для ответа на вопрос что делать:
Если есть замысел то его необходимо извлечь из головы чтобы начать работу — поняли что хотим и записали. Это пожелания. Артефакты замысла клиента — это может сделать только клиент, замысел это его часть работы.
Обычно замысел в виде пожелания и высылают на почту ошибочно называя это техническим заданием, а это даже не требования.
Клиент начинает изложение пожеланий в любом формате — мы не рекомендуем в этот момент рисовать много чего-то и присылать огромные проекты — все они все равно пойдут в проработку начиная с простого списка требований, и поэтому не стоит просто тратить на это время.
Хозяйке на заметку: ожидания что какая-то компания подрядчик возьмет в производство без переработки ваше тз (если вдруг к примеру есть хорошо проработанное на детали тз — к себе в процесс) всего лишь говорит о качестве процесса в этой компании — если они могут его так извне менять, значит работают они хаотично, на глаз.
Практика показывает что в сложных (от слова сложение, комплексных) проектах (а это любая разработка или внедрение любой бизнес системы — от сайта компании, до комплексных внедрений множественных систем) — именно качество и отлаженность процесса у исполнителя является не только гарантией качества результата, а и в целом получения итогового результата а не зарывания бюджета в провода.
В целом техническое задание это документ по сути своей не такой важный для работы над проектом со стороны клиента, сколько важна возможность в любой момент времени обратиться к любому из элементов системы и посмотреть как он будет работать, а также принять его готовность по заявленному документу.
Куда важней этот документ для производства внутри компании подрядчика, а также для контроля выходного продукта на соответствие всем заявленным требованиям и ограничениям — так мы получаем качество.
Вот простые правила предъявляемые мною к любому техническому заданию:
Требования — это описание (модель) системы к которому сбоку мы приписываем деонтическую модальность. (Анатолий Левенчук)
Отдельно стоит отметить что Бизнес требования — это тербования к тому как должна протекать деятельность системы.
Требования отличаются от пожеланий по простому принципу: требование = пожелание + обоснование.
Для того чтобы обосновать требование необходимо предоставить артефакты подтверждений что требования определены реальной потребностью и своим выполнением перекроют (согласуется с) миссию всего проекта (http://deppkind.livejournal.com/1863.html)
Все требования записываются списком в одну большую таблицу в три колоночки:
| 1. требование | 2. для чего нужно | 3. возможное решение |
Не существует требований второго порядка, или вложенных — требования это конкретное требование к выдаче от системы во внешний мир — что система должна выдать в конкретный момент времени и места.
Требования располагаются всегда на выходе результатов работы функции системы и входе в реальный мир — в котором пользователь системы ее эксплуатирует.
Самое главное что нужно указать чего это делается (я прошу это указать во второй колонке, и это самое важное что может быть) — так как требования пишутся вместе с клиентом — всегда помогаем это сформулировать, иногда это сложный процесс для многих.
Примеры требований из реальных проектов:
В третьей колонке я прошу указать видение решения — как клиент видит что его решение могло бы работать, своими словами — пусть у нас это будет как на этом сайте (обычно так бывает), или мы хотели бы чтобы эта часть открывалась в отдельном окне. Все должно быть синим.
Если какое-то пожелание из видения решения становиться крайне важным — оно перекачивает в раздел документа под названием «Ограничения на решение».
Стоит отметить что ограничения всегда усложняют процесс создания решения и не всегда продиктованы потребностями внешнего мира, поэтому мы их пишем в третьей колоночке и стараемся указать на то что это некая подсказка для нас как бы клиенту было приятнее или удобнее решать ту или иную задачу.
Все это позволяет синхронизировать онтологию мира клиента и нашу для более ясного взаимопонимания.
Когда у нас есть требования — дальше все отрабатывается на автомате — процесс просто выполняется. Тут уже дело техники — за хорошим исполнителем как правило не заржавеет.
Требования обязательно и всегда согласуются друг с другом, формулируются обоснования, проверяется их выполнимость, делается трассировка и тд.
Требования надо обосновать — что вы все не высосали из пальца. Документы, решения и прочие артефакты всегда кстати.
Трассировка требований — это инструмент, позволяющий показать степень проработки и влияния требования на компоненты системы.
В этот момент можно понять степень влияния требований. Требования поменялись — конфигурация поменялась — еще и указывает трассировку и степень влияния.
Требования подписываются сторонами. Требования легко меняются и дополняются постоянно в процессе работы, это фиксируется и не мешает работе. Требования пишутся клиентом — согласуются исполнителем, подписываются сторонами.
Если говорить о распространенных заблуждениях о том что нужно всегда формулировать выгоду от создания продукта или функции, всегда нужно иметь ввиду что мы говорим только о части работ по возведению системы в жизнь и эксплуатацию, и ни разу не говорили о бизнес стратегоровании или требованиях к бизнесу.
Чуть подробнее на поиск решения через Job Stories я писал тут deppkind.livejournal.com/3259.html [2].
Поэтому когда мы говорим про требование и техзадания мы всегда говорим — не выгода а выдача.
Стоит понимать что назначение технического задания — это контрольная точка на вход в производство и выход из него.
Назначение документа-требований — проработка пожеланий и контроль результата.
Если у вас тз на самом деле всего лишь ожидания или непроработанные пожелания — задайте себе вопрос — каким образом вы проконтролируете выход из производства достаточно комплексного продукта?
Вопросы, комментарии приветствуются.
Найденные опечатки исправляются, добавляются новые.
Оригинал deppkind.livejournal.com/3449.html [3]
Автор: deppkind
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/96222
Ссылки в тексте:
[1] мозг: http://www.braintools.ru
[2] deppkind.livejournal.com/3259.html: http://deppkind.livejournal.com/3259.html
[3] deppkind.livejournal.com/3449.html: http://deppkind.livejournal.com/3449.html
[4] Источник: http://megamozg.ru/post/18588/
Нажмите здесь для печати.