О пользе технического задания

2301
31

«Генералы-победители обычно строят военные планы, которые будут работать не зависимо от того, что делает враг. Это суть хорошей стратегии.» Джет Траут

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

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

Практика да статистика

Практика разработки различных IT-проектов, в том числе и стартапов, ясно показывает, что заказчик и программист говорят на одном языке лишь в 5% случаев. А что уж говорить об одном языке с творческими дизайнерами!:)

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

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

Многие из руководителей на данном этапе всплеснут руками и наотрез откажутся работать по ТЗ еще и платно. Разумеется, продолжать работу можно и без него. Вопрос только в результате.

Альтернативные варианты: работа без ТЗ

Вариант 1:

Но рынок дешевой рабочей силы не дремлет: ушедший бизнесмен находит фрилансеров, веб-студии, конторы, где процесс идет совсем иначе. Техническим заданием называется бланк в 2-3 листика с полузаполненными полями, в который заказчик вписывает основные параметры заказа, обсуждая остальное лишь в устной форме. Результатом таких «юридически оформленных» отношений является, как правило, прорыв сроков, низкое качество конечного продукта либо несоответствие требованиям заказчика. И как «приятный» бонус для неопытного руководителя — тот бриф, который заполнялся, не имеет никакой юридической силы в суде, и взять с подрядчиков за такую работу тоже нечего. Никто не утверждает, что нет исключений. Это всего лишь правило, по-крайней мере, для Украины.

Вариант 2:

Заказчик пытается писать ТЗ сам. Такие руководители, как правило, делятся на две категории: те, кто был в прошлом системным аналитиком, архитектором, РМ или СТО, кто на самом деле знает и умеет составлять данного рода проекты, и те, кто считают, что лучше них этот проект никто не знает.

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

Вторая категория энтузиастов берет проект на себя и пишет его 3-4 месяца, плюс переписывает потом еще и еще. В результате: отказ от проекта или все же заказ у специалиста все того же ТЗ.

Вариант 3:

Креативщики: категория заказчиков, которые настолько плещут идеями, что писать такой документ, как ТЗ им просто не выгодно: на сменах задач во время написания документа уйдет еще половина бюджета. Тут все просто: они вносят n-ую сумму на счет, получают рейты (почасовые ставки) всех специалистов, их квалификации и занятость, и работают, пока есть средства на счету. Такие проекты если и доводятся до ума, то очень растянуты из-за того, что сам заказчик не знает точно, чего именно он хочет.

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

Что вам даст работа по ТЗ

Преимущества работы по техническому заданию, видению или брифу (в зависимости от сложности проекта):

1. Страхование риска срыва сроков: все сроки прописаны с реальным расчетом необходимого времени. За срыв срока в договоре можно прописать соответствующие санкции.

2. Гарантии того, что проект будет выглядеть так, как задумал изначально заказчик, а не как понял разработчик: все элементы прописаны и утверждены.

3. Гарантии постоянной суммы: цена за проект посчитана, утверждена, расписана детальная калькуляция. Вы видите куда тратиться каждый цент. Цена не изменяется, так как все прайсы — сроки — функционал, опять же, утверждены.

4. Созданное по ГОСТу ТЗ является полноценным продуктом, т.к. может использоваться любой командой разработчиков — Вы не привязываетесь к подрядчикам и можете их сменить в любой момент.

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

Еще пару слов о планировании

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

Хотите реальных подтверждений того, что техническое задание IT-проекта, — половина успеха? Количество реализованных проектов компанией АВ — 431 на данный момент. Около 90% из них создавалось именно по ТЗ. Те 10%, которые сюда не вошли, это модули низкой сложности (там хватает брифа) и сайты-визитки, где также хватает брифа.

В общем, мы только делимся опытом, оставляя конечные размышления самим читателям.

Оставить комментарий

Комментарии | 31

  • только ТЗ, только хардкор ))) созданное по ГОСТу ТЗ забавно

    про смену разработчиков по ТЗ тоже забавно

  • Сначала подумал что просто неудачный автоматический перевод, а потом увидел кто автор и успокоился
     

  • Это скорей не ТЗ, а обычный договор с оговоренными суммами.
    ТЗ в первую очередь уменьшает разбежность между тем, что хочет заказчик и тем, что сделал исполнитель.
    А они (разбежности) будут в любом случае.

    • Хорошо разработанное ТЗ исключает  «разбежности».

    • Ну да. Только сам договор по ТЗ как раз и призван уменьшить разбежности. 

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

      В ТЗ содержится детализированное описание проекта. Клиент, так как чаще всего не в состоянии корректно сформулировать спецификации сам, рассказывает все ПМу. Тот же, исходя из слов клиента пишет это все техническим языком в ТЗ. Если заказчик это утвержает, — переход к следующему этапу. Если нет, — переформулировка до удовлетворитльного результата.

      После ТЗ прикрепляется калькуляция, в которой:
      1. модуль/задача
      2. уровень специалиста, выполняющего проект
      3. его почасовая стоимость
      4. количество часов, необходимых для реализации данного модуля
      5. стоимость данного модуля

      В конце итого по сумме да срокам.

      Как результат: клиент видит, на что идет каждый доллар и сам может корректировать стоимость.

      Среднестатистический объем ТЗ — 40 стр в зависимости от сложности проекта.
      Вы хотите это назвать брифом, я правильно поняла?

      Разбежности будут, не поспоришь. Но нужно же хоть как-то пытаться минимизировать их влияние на выполнение проекта.

  • Мда… отныне ТЗ это и есть Договор?.. а я-то дурень думал, что ТЗ обычно является дополнением к Договору..
    Требую номер ГОСТа в студию!!!1 Интересно было бы взглянуть на ТЗ таких великих людей – неужто расписано все «пиксель в пиксель» и нет ни единого места с инакочтением?

    • Посмотрите на автора и поймете, почему ТЗ является договором =)

    • «Мда… отныне ТЗ это и есть Договор »

      ТЗ является приложением к договору.

      «Требую номер ГОСТа в студию!!! » 

      погулите ГОСТы (ISO, ДСТУ) для составления технической документации, разработке программного оебспечения, дизайн макетов и т.д.

      «нет ни единого места с инакочтением »

      Как говорят, хороший юрист найдет всегда где придараться если такая задача ставиться. Я же в своем материале описываю то, что «инакочтения» лучше обсуждать во время разработки самого ТЗ.

    • О_о
      я прям теряю нить Вашей мыли)

      Да, ТЗ — дополнение к Договору, ровно как и калькуляция и акт о выполненных работах. А где Вы увидели другое, подскажите плз

  • Ждем еще комментариев к материалу

  • комментарии как всегда ни о чем, да, Ярик?;)

    • ну конечно. как я мог пропустить очередной перл от Артема?)
      или это писала ты? если ты, то забираю свои слова обратно

      • Мда. Ты вообще читал статью? Если твой вывод зависит только от автора.

        Ах, ну да. Зачем читать, если про ТЗ ты и так все знаешь, да?)

        • конечно) я видел ТЗ, которые там) поэтому считаю эту статью откровенным бредом человека с сильно завышенным ЧСВ

          • Господи, ты же программист — где твоя логическая последовательность?
            Объясняю:
            1. если тебе не нравится ТЗ, то это претензия к РМ, у QA, к тех писателю, но никак не к руководителю и это логично.
            2. Качество ТЗ у нас нормальное. Не согласен — аргументируй.
            3. Судя по твоим комментариям, ты статью не читал вообще. Зачем комментишь тогда? 

          • 1) потому что это всё сказывается влияние Артема на то, как надо писать. Как будто он такой умный и знает, как и что надо делать
            2) посмотри примеры нормальных тз и нормальных дизайн-макетов. а потом посмотри на те, которые в аб
            3.1) читал и свое мнение я высказал выше
            3.2) не смог не удержаться, что бы не высказать свое мнение про MBA и «крутого» инвестора =)

          • 1. О_о завязывай с наркотиками. АЕ в это сроду не лез. А даже если я и не права, то скажи мне плз, откуда это простому бывшему пхп-шнику б знать?
            2. Я видела. Если ты видешь в чем-то конкретную ошибку — укажи. А то флуд лить мозгов не надо, а по-существу мало кто умеет говорить.  К тому же, если ты считаешь, что это легко, предлагаю спор:

            Берем какой-то проект, сайт для клоз-котчинг, ты помнишь о чем я;). Раз ты утверждаешь, что это легко — напиши ТЗ нашего уровня, которое будет читабельно для программистов. На оценку его адекватности можно привлечь тоже же моего Диму — ему явно плевать на наши с тобой разногласия. Срок, как у АВ, — 2 недели, то есть 10 рабочих дней. Если такое ТЗ сделать просто, — ты, как программист, справишься. Также, плод такого творчества я выложу в нете. Катит? 😉

            3. угу

            4. Вывод: единственная цель комментирования данного поста: флуд Артема Бабенко и все. Ну тут, может быть, еще кто-то читает. Ну как вариант. Чисто информативно, не?

  • Какой-то тут однако междусобойчик…

  • Все надеюсь увидеть комментарии по теме статьи, но тут, однако, все как прежде. 

    • Я лично ничего не имею против автора, но тут нечего комментировать по статье.

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

      Последий раздел статьи «Еще пару слов о планировании»… ТЗ — это не планирование. Это техническая документация. Планирование это сетевые графики. 

      • Как приятно вести диалог с адекватным человеком:)

        Никто не говорит, что это является единственной угрозой прорыва дедлайна (если не так, скопируйте где это есть). Но когда к вам обращается с проектом, к примеру, создания CRM системы, то ТЗ необходимо. Можно, конечно, работать и без него. Но тогда сроки/суммы — вообще загадка.

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

        «И подрядчиков нельзя менять в любой момент даже при идеальном ТЗ». О как. А если он, к примеру, помер. Что теперь, проект прикажете сворачивать? 

        Да и потом, детский сад в целом.

        Клиенты считают, что программисты тут магией занимаются, проводят телепатические сеансы по скайпу с заказчиками и и так все понимают, ведь «это логично». Посему приходится по сто раз на дню объяснять, что все необходимо уточнять. К тому же, если у Вас на руках утвержденное ТЗ, в котором все по проекту прописано, то это также является своеобразной страховкой с обоих сторон. Заказчик не может вить веревки, постоянно указывая на новые change-request, мол баги это, исправляйте, будьте любезны. Подрядчики не могут не выполнить какой-то модуль либо элемент, мол «забыли», «тут этого сделать нельзя», «первый раз слышу» — все прописано и подписано.

        Это не панацея. Это гарантия.

        • В статье 5 пунктов указаны после слов «Преимущества работы по техническому заданию», а я утверждаю, что только пункты 2 и 5 являются преимущетсвом, остальное к ТЗ не имеет прямого отношения. У ТЗ есть прямое назначение: снизить разбежности в понимани проекта и задокументировать результат работы. 

          Еще раз о фиксации цены. Цена фиксируется в договоре, а не в ТЗ. В смете, если угодно. Единственное отношение ТЗ к цене — это то, что по ТЗ оценивается плановый объем работ и квалификация специалиста на эти работы. И уже отсюда можно посчитать цену. Но! Методы планирования позволяют играть с ценой и сроками. Т.е. проект по ТЗ пожно сделать за 2 деньги и 1 срок, а можно и за 1 деньгу и 2 срока. Вывод: ТЗ не фиксирует стоимость.

          Если подрядчик «помер», значит Вы плохо его выбирали. Но это форсмажорная ситуация. У Вас просто выхода нет, кроме как искать другого. Часто бывают случаи, когда проект (проектная документация) разрабатывается одной фирмой, а исполняется другой. Так вот тут можно менять разработчика. Но это не «в любой момент», а на стыке этапов. 

          Последний Ваш абзац правда. Это прямое назначение ТЗ: снижение разбежностей в понимании. 

          «Это не панацея. Это гарантия.» — это даже не гарантия, к сожалению. Тут где-то было написано, что среднее ТЗ на веб сайт это 40 листов. Я соглашусь с таким средне больничным показателем. Так вот, Вы никогда не уместите на 40 листах (и даже на 100) абсолютно все, что должно быть и как оно должно быть. Много чего остается в двух зонах: «заказчику не принципиально как» и «заказчик считает это устаявшейся нормой». Ваше утверждение, как исполнителя «в ТЗ не написано, потому и не сделали», может сработать для суда, но Вы испортите отношения с клиентом и подпортите репутацию. А клиент не получит продукт согласно его ожиданиям, что равносильно одному из двух статусов проекта «незавершен» или «провален».

          • Мне, в принципе, нравится то, что спор аргументирован. Еще и тем, что у Вас, насколько мне известно, есть опыт в данной области. Но особенно с учетом второго фактора, Вы должны понимать, что данная статья написана, как разъяснение того, зачем ТЗ писать НАДО. Повторять данную тему сто раз в день, знаете, — труд не самый благодарный.

            Основной вопрос данной статьи «Заказать ТЗ или не заказать». И если человек, далекий от всего этого, после прочтения скажет «Да, надо», то цель достигнута.

            «Так вот, Вы никогда не уместите на 40 листах (и даже на 100) абсолютно все». А кто ж собирается?

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

            «может сработать для суда, но Вы испортите отношения с клиентом и подпортите репутацию.»
            Знаете, я лично всем своим клиентам всегда говорю, что делается строго по ТЗ, читайте внимательно. Не уверенны — говорите с проджектом. Если человек упустил — его проблемы. Ктото же должен нести ответственность в конце-концов. Не согласна, что «незавершен» или «провален».

          • Я тоже «за» ТЗ и поддерживаю подобные статьи. Но в статье потенциальный заказчик вводится в заблуждение. Когда я прийду к клиенту и скажу, что надо сделать ТЗ и план работ, он скажет мне, что «ТЗ — да, план работ — нет, т.к. на АИНе было написано, что ТЗ гарантирует сроки и стоимость, и план работ ему не нужен». Как мне потом объяснять клиенту, что написано не правильно?

            Если честно, мне крайне странно видеть как за статью по ТЗ отвечает на автор, а его подчиненные, к тому же менеджер по продажам (так у вас в fb профиле написано). На сколько помню, sales-manager не имеет отношение к ТЗ. 

          • Сергей, у меня на предприятии работает делегирование. А Иванна, как Директор по продажам имеет огромный опыт для подобных ответов, так как именно она убеждает заказчиков работать с Проектной документацией, с техническими заданиями, с тест планами и т.д.

          • «Если подрядчик «помер», значит Вы плохо его выбирали.»

            убило 🙂 +1

  • А вообще-то, раз столько несогласий относительно тех пунктов, давайте прокомментируем, че уж там

    1. Страховка прорыва сроков. «ТЗ не гарантирует, что срок не будет сорван». Ну ясное дело. Страховка машины тоже не гарантирует, что авто не разобъется. Это просто приводит в действие определенные события, раз такое случиться. В ТЗ описано, что и когда должно делаться. А если без него, то что можно прописать в договоре? «Ну короче после 35 % работы, +/- 30 %», так?)

    2. Гарант того, что проект будет выглядеть в соответствии с пожеланиями заказчиков. Ну само собой. А то устно, знаете ли, и прослушать можно, и ярлык не тот нацепить. И вообще, записывать — штука полезная)

    3. Гарантии суммы без изменений. Цена=(Себестоимость + Прибыль)*Налог.
    Если вы делали ТЗ, мы знаем Сб, соответственно цена является прокалькулированой. А если и происходят какие-то трраблы с разработчиком, руководителем, офисом, страной и т ж и т п — это НАШИ издержки.
    Если же заказчик работает без ТЗ, то никто на себя такую ответственность не возьмет.

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

    5. Гарантировано должно работать то, что прописано. Действительно, удобно. Если после реализации проекта вы заходите на сайт, к примеру, а у вас тут раздел не открывается, хотя должен — это баг. Компания исправляет за свой счет. А если клиент во время тестирования сайта, «вдруг» вспоминает, что еще ж было бы классно музычку при открытии страницы пустить — увольте, это чендж реквест. Дополнительная услуга.
    ТЗ четко показывает, что баг, что смена задачи.

    А вообще-то, ну КАК вы себе представляете работу БЕЗ ТЗ? Идиотизм чистой воды. Не везде необходимо все расписывать? Ну да. Готовить будем без рецептов, шить без выкроек, строить без чертежей, программы делать без ТЗ. Ну да, что нам, молодым красивым -_-

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

      По Вашим пунктам:
      1) В ТЗ не пишеться когда будет что-то делаеться — это пишеться в сетевом графике. В плане работ, если хотите. 
      2) с ним я был согласен с самого начала 🙂
      3) если Вы сделали ТЗ — Вы не знаете себестоимость. Выше я уже писал про деньгу и сроки.
      4) ТЗ ускоряет процес, но ТЗ не позволяет менять подрядчиков в любое время так легко, как хотелось бы.
      5)  см. п.2.

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

      • Рада, что на 4ом пункте Вы уже согласны с тем, что разработчиков можно менять в принципе.

        Тоже не против закончить спор. В любом случае, даже если кто-то скажет так, как Вы написали, то у Вас всегда будет возможность переадресовать их читать комментарии;)

Поиск