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

Эбиа

www.ebia.ru

16
Enlite

Enlite

enlited.ru

16
Amarket

Amarket

amarket.io

15
likearea

likearea

smm.li

14
Relap

Relap

relap.io

12
RockinRobin

RockinRobin

www.rockinrobin.co

12
E-Commerce and Venture projects

E-Commerce and Venture projects

Продажа товаров от производителей оптом и в розницу

11
Perezvoni.com

Perezvoni.com

perezvoni.com

11
Cookiezz

Cookiezz

cookiezz.com.ua

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

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

201 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
Добавить в избранное Сохранено
Авторизуйтесь
Вход с паролем
Комментариев еще не оставлено
Выбрать файл
Читайте далее
Загружаем…
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать