Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Вопросы Проекты Вакансии
Причиняю добро путем нанесения пользы
Рекомендуем
Продвинуть свой проект
Лучшие проекты за неделю
28
Битрикс24

Битрикс24

www.bitrix24.ru

20
Отследить-посылку

Отследить-посылку

B2B-сервис трекинга посылок

16
myPreza

myPreza

mypreza.ru

13
WebResidentTeam

WebResidentTeam

webresident.agency

12
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Expresso

Expresso

www.expresso.today

9
Reader

Reader

Интернет-журнал о современных технологиях.

7
ADN Digital Studio

ADN Digital Studio

adn.agency

7
Frutra

Frutra

design.frutra.ru

Показать следующие
Рейтинг проектов
Подписывайтесь на Спарк в Facebook

В чем разница между требованиями и техническим заданием

187 0 В избранное Сохранено
Авторизуйтесь
Вход с паролем
У нас же есть техническое задание на систему / сайт / приложение / проект … на самом деле нет!

Ситуация

  1. На входе в студию клиент (виртуально / реально не важно).
  2. Клиент хочет что-то заказать у нас - систему, сайт, приложение, аппу, что угодно - все что можно разработать и даже потом скрестить бульдога с муровьедом например (1С битрикс, просто 1С, другие системы и наша разработка).
  3. Высылает он нам нечто (как мы это видим), называя это "тз" (как он это видит) и говорит - оценить / посчитать / задать вопросы и далее везде, ожидая в ответ как правило получить вполне конкретную точную цифру и срок (беру пример крайней клиники) когда это будет готово.
  4. Ждет.

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

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

Соглашение о терминологии

  1. Артефакт - физическое представление в реальном мире чего либо сотворенного человеком.
  2. Замысел - то что находится в голове или головах клиентов.
  3. Пожелания - артефакт замысла.
  4. Требования - согласованные с реальностью пожелания.
  5. Физика окружения - в случае с сайтом это все компоненты из которых он может быть изготовлен согласно консорциому w3c. В случае с мобильным приложением - это apple developer program или andriod development и тд
  6. Архитектурное решение - словесно сформулированное предложение о реализации требования, без применения элементов физики конечного окружения (мы говорим про экраны, не говорим про экраны айфона или андроида конкретно).
  7. Техническое задание - подробная конфигурация сооружаемой системы с описанием свойств характеристик назначений каждого элемента и компонента, документ задание в производство, а также документ для приемочного тестирования.

Мухи отдельно - котлеты отдельно.

Рассмотрим очень коротенько жизненный цикл любого замысла и его реализации в реальность:

  1. Замысел (что) -> хотелось бы вина
  2. Пожелания (сформулировано зафиксировано) -> не послать ли нам гонца за бутылочкой винца
  3. Требования (контрольная точка) -> красное сухое французское
  4. Архитектурное решение -> будем потреблять дома из бутылок а не в розлив из бочки в ресторане.
  5. Техническое задание -> в магазине номер 5, выкупить 2 бутылки французского за 5 рублей каждую.
  6. Сооружение (производство, выполнение) -> сходили купили привезли показываем
  7. Получение (верификация) -> приняли по требованию, детали сверили с тз по необходимости.
  8. Ввод в экспулатацию -> открываем бутылки
  9. Эксплуатация -> разливаем по бокалам, потребляем блага.

Еще раз с сайтом или мобильным приложением:

  1. Замысел (что) -> хотелось супер сервис который может делать дело
  2. Пожелания (сформулировано зафиксировано) -> нам нужен сервис который делает это дело X, Y, Z
  3. Требования (контрольная точка) -> сервис должен делать X, Y, а Z не возможно при наличие X и Y, давайте лучше H. ОК.
  4. Архитектурное решение -> X мы сделаем как страницу. Y будет как игра, а H будет как запрос через форму.
  5. Техническое задание -> X 5 экранов (нарисовано), 24 элемента (отмечены, описаны все данные), назначение каждого (выход от работы), сценарии поведения каждого (нажал увидел победил), действующие лица эксплуатирующие (менеджер, домохозяйка на айпеде), результаты от выполнения такие-то (информация получена, ачивка пройдена, письмо отослано, информация о товаре передана в сборку на систему склада и тд ...)
  6. Сооружение (производство, выполнение) -> кодинг, сборка, тестирование по тз, прогон сценариев.
  7. Получение (верификация) -> деплоймент (развертывание в эксплуатационное окружение, appstore, amazon ...)
  8. Ввод в эксплуатацию -> принята работа, пошли баннеры реклама, регистрации.
  9. Эксплуатация -> сервис работает, конверсии растут, кеш заходит в кассу.

Кто кому что должен?

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

Для наглядности я изложил одному из клиентов схемку жизненного цикла одного(!) требования и по сей день показываю для ответа на вопрос что делать:

639_900.pngЕсли есть замысел то его необходимо извлечь из головы чтобы начать работу - поняли что хотим и записали. Это пожелания. Артефакты замысла клиента - это может сделать только клиент, замысел это его часть работы.

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

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

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

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

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

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

Вот простые правила предъявляемые мною к любому техническому заданию:

Требования к техническому заданию

  1. Техзадание должно быть
  2. Оно пишется исполнителем в противовес на согласованные требования и подписывается сторонами.
  3. Техническое задание содержит полное и исчерпывающее описание создаваемой системы в терминологии физики решения, в ее эксплуатационном окружении и четко недвусмысленно дает ответы на вопросы:
    • как именно по шагам отвечая на конкретные воздействия пользователя будет работать любой элемент системы.
    • как при этом он будет выглядеть
    • каково его назначение в рамках всей системы
    • как будет обслуживаться данный элемент в процессе эксплуатации и кем
    • и тд.
  4. Содержит критерии приемки результата - что именно в рамках физики системы дает ясное понимание что конкретный элемент или сценарий системы работает корректно и успешно.
  5. Написано в паре со специалистом (с подтверждаемой квалификацией) в области системной инженерии требований и специалистом по проектированию взаимодействию с системой.

О требованияхТребования - это описание (модель) системы к которому сбоку мы приписываем деонтическую модальность. (Анатолий Левенчук)

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

Требования отличаются от пожеланий по простому принципу: требование = пожелание + обоснование.

Для того чтобы обосновать требование необходимо предоставить артефакты подтверждений что требования определены реальной потребностью и своим выполнением перекроют (согласуется с) миссию всего проекта (http://deppkind.livejournal.com/1863.html)

Все требования записываются списком в одну большую таблицу в три колоночки:

| 1. требование | 2. для чего нужно | 3. возможное решение |

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

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

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

Примеры требований из реальных проектов:

  1. Каталог должен показывать (в глаза) товары
  2. Логистическая система должна выдавать маршрут (на бумаге, в электроном письме опять же в глаза и мозг) - чтобы выполнение доставки шло согласно плану.
  3. SMS о тренировках должны приходить на телефоны (устройства) - чтобы не звонить каждому.
  4. Страница товара должна передавать конкретную информацию x y z (в глаза) - для принятия решения о ...

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

Если какое-то пожелание из видения решения становиться крайне важным - оно перекачивает в раздел документа под названием "Ограничения на решение".

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

Все это позволяет синхронизировать онтологию мира клиента и нашу для более ясного взаимопонимания.

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

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

Трассировка требований - это инструмент, позволяющий показать степень проработки и влияния требования на компоненты системы.

В этот момент можно понять степень влияния требований. Требования поменялись - конфигурация поменялась - еще и указывает трассировку и степень влияния.

Требования подписываются сторонами. Требования легко меняются и дополняются постоянно в процессе работы, это фиксируется и не мешает работе. Требования пишутся клиентом - согласуются исполнителем, подписываются сторонами.

Если говорить о распространенных заблуждениях о том что нужно всегда формулировать выгоду от создания продукта или функции, всегда нужно иметь ввиду что мы говорим только о части работ по возведению системы в жизнь и эксплуатацию, и ни разу не говорили о бизнес стратегоровании или требованиях к бизнесу.Чуть подробнее на поиск решения через Job Stories я писал тут http://deppkind.livejournal.com/3259.html.

Поэтому когда мы говорим про требование и техзадания мы всегда говорим - не выгода а выдача.

Стоит понимать что назначение технического задания - это контрольная точка на вход в производство и выход из него.

Назначение документа-требований - проработка пожеланий и контроль результата.

Если у вас тз на самом деле всего лишь ожидания или непроработанные пожелания - задайте себе вопрос - каким образом вы проконтролируете выход из производства достаточно комплексного продукта?Где брать требования?

  1. Сесть и писать - ничего в этом сложного вообще нет. Требования это ваши же ожидания.
  2. Если совсем сложно - требования можно заказать, кто сколько берет за это (это интервьюирование вас, где и как это делать каждый решает сам - я делаю это только в студии и за деньги), тут помесь работы секретаря + машинистки. Ну и контрольные вопросы конечно же от нас )
  3. На собранные требования можно давать решения - а только на каждое решение может быть уже цена и сроки. Можно за 5 рублей а можно и за 50 лямов. Тут кто что вам предложит на рынке, каковы ваши потребности и ситуация.
  4. Ждать и требовать подробнейшее тз от исполнителя.
  5. Только после четкого понимания пускать в сооружение (разработку) систему.

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

Вопросы, комментарии приветствуются.

Найденные опечатки исправляются, добавляются новые.

Оригинал - http://deppkind.livejournal.com/3449.html

+1
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Комментариев еще не оставлено
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать