У нас же есть техническое задание на систему / сайт / приложение / проект…

  • Tutorial

Ситуация


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


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

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



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

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


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



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

  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. Эксплуатация -> сервис работает, конверсии растут, кеш заходит в кассу.


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



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

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

image

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

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

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

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

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

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

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

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

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


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

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


О требованиях



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

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

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


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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Чуть подробнее на поиск решения через Job Stories я писал тут deppkind.livejournal.com/3259.html.

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

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

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

Где брать требования?


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


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

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

Only registered users can participate in poll. Log in, please.

Какова сейчас средняя температура по больничке

  • 17.9%Не фиксируем требования, не пишем тз, работаем на живую по тз или со слов клиента.10
  • 44.6%Не фиксируем требования, работаем по тз которое сами написали вместе с клиентом. Не разделяем ТЗ и требования.25
  • 37.5%Фиксируем требования, разделяем от тз (производственного документа), работаем как надо.21

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    0
    требования можно заказать,… я делаю это только в студии и за деньги
    Как я понял — вы это делаете в своей студии за деньги заказчика.
    Очень интересно: как вам удается заманить заказчика к себе в студию и как вы оцениваете свою работу по составлению требований (сколько денег и за что берете)?
      0
      Кратко — это консалтинговая услуга, и обычно таблицу с требованиями люди пишут сами.

      Если кто-то хочет что-то сделать и не понимает что именно — это уже проблемный клиент. Скорее всего не будет с ним работы.

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

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

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

      Суммы сильно зависят от проекта и идут как консалтинг.
        0
        Важно разделить
        • Написать (изложить извлечь) — сами, или за деньги мы
        • Уже работать с ними — это часть проекта и не идет отдельными расчетами, тут работа пошла и мы ее делаем
      0
      Все что присылает клиент — это требования (как бы он это не называл)
      Первый этап работы — пишем ТЗ, на основании требований и/или встречи с клиентом.
      Все остальные этапы оцениваются на основании ТЗ.

      Но вообще, опытный ПМ, тупо по тексту заявки на 85% сможет сказать какой в итоге у проекта будет бюджет, по этому, во многих случая можно назвать вилку цен сразу.
        0
        Ну вот у вас и утечка и ввод в заблуждение клиента — что вы работаете по любому его запросу без оплаты. Много у вас времени отказные тз писать?

        Как можно написать ТЗ (задание в произдство) — без проработки взаимодействий сначала (в базовом варианте воздействие-реалкция)?

        Что делаете если требование «допишут» — по кругу тз переписываете? Или по принятому у многих методу «склоняете» клиента к нужному вам решениею (не переписывать сто раз) а сразу под ограниченный процесс работать?

        У вас тут дичайшая потеря качества — многие клиенты готовы оплачивать и платят за грамотную проработку, а вы сразу самогонные аппарты в производство пускаете.

        Супер крутой менеджер может что угодно называть — он должен это обосновать.

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

        Зачем так работать вообще?
          0
          Откуда такие выводы?
          Первый этап работы — очевидно уже за деньги.
          Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.
          После принятия, дописать ТЗ естественно нельзя.
          Супер круто менеджер может обосновать что угодно.

          — да это все очевидно в целом, в статье эти простые вещи как то безумно усложнены. «Жизненный цикл требования» — зачем это нужен? Встречавшийся, спрашиваешь что нужно, анализируешь, предлагаешь вариант решения. Естественно вся эта работа оплачивается клиентом. Излишняя бюрократия только снижает качество и способствует потери сути.

            0
            > Откуда такие выводы?

            На одно и то же требование можно соорудить варианты формата «жигуль», «vw», «bmw», «bentley».

            Обосновать = доказать. Доказательства должны быть подшиты с пометкой почему, иначе это пустые слова и цифры «из головы».

            > Первый этап работы — очевидно уже за деньги.

            Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.

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

            > Клиент приходит со своими требованиями — говоришь окей, но нужно нормальное ТЗ, написать его — 200к.

            ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.

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

            Остальное это ваша работа и ваша часть отвественности.

            > После принятия, дописать ТЗ естественно нельзя.

            Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.

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

            Спасибо за вопросы по существу.

              +1
              > Не всегда требования надо писать за деньги — нужно просто помочь изложить их — это листок один или два формата А4 в котором на первой же встрече можно поставить ярлык клиента — да, это вот все что мне нужно.

              Да, это называется бриф )

              > ТЗ это чертежи в работу на вашем участке производства — это ваша проблема и ваша работа. Выставлять в отдельную стоимость это нельзя. Точно так же как нельзя согласовывать тз с клиентом — ему его только нужно передать и спросить вопросы + / -.

              И что? Почему он не должен за это платить? Клиент хочет проект без тз? пусть наймет фрилансера. Если он делает проект за лям+ то прекрасно понимает что за это нужно платить.

              > Ну вот и приплыли. А что такое визуальное мышление вы как раз узнаете в самом конце — когда показали детали и человек увидел что ему еще надо это и это требование. Закрыли вопрос по качеству от него и уперлись — платите за новое тз.

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

                Все верно излагаете, только не надо бежать вперед клинту фразой «плати за тз» — ему не нужно тз, ему нужен результат.

                Тут дело в терминологии просто — у меня тз проходит через несколько этапов как тут написано, где каждый подтверждается, и на каждом этапе полно возможностей «повизуализировать» и пофантазировать не попадая в копеечку.

                Самое же дорогое в тз это как раз прописать все и прорисовать уже as is с кликами и view стейтами как это и куда, закрыть юз кейсами и тд.

                А для начала мы просто пишем воздейсвтия реакции — их очень достаточно для понимания как будет работать конечный продукт у клиента.

                Нельзя продать часть внутреннего процесса как услугу, если это не самостоятельная услуга со всеми ее жизненными циклами — начало, производство, доставка, закрытие.

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

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

                Бриф брифом, а на требования есть стантарты инженирии, и все же рекомендую им прислушиваться. Клиент может напсать все что хочет — но лучше это переписать и дать ему на подпись по двум причинам:
                1) Пояснить где он заблуждается или уточнить детали
                2) Получить взаимную синхронизацию на понятном списке, уничтожив любые отсылки к «я вам присылал письмо там с комментарием в ворде в котором ссылки на три сайта я хотел как эти сайты».

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

                  0
                  Ну вы тогда бы как-нибудь конкретизировали бы вашу статью что ли. Вроде «чеклист вопросов клиенту для определения стоимости» а то очень много философии, а практической пользы мало.
                    0
                    Это отдельные темы, а тут вопрос про присалыные писульки и разворот их в требование вместе с отделением от тз.

                    Если вам практической информации не хватает — специально в конце статьи базовый чек лист что делать дальше — сесть и писать.

      Only users with full accounts can post comments. Log in, please.