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

  • 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.

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

Share post

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.