Техническое задание: какие элементы должны быть прописаны, а какие – в уме

    Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:

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

    2. Проект – «вещь» живая и, само собой, во время его выполнения, возникнут новые веяния и цели/задачи, которые клиент захочет сразу же реализовать. Опять же, если не прописаны все данные вещи в задании, то вы будете много работать, а самые главное – бесплатно. Ведь если вы откажете, то клиент откажется платить даже за ту работу, которая уже сделана и в такой момент все делается, чтобы получить «хоть что-нибудь». При этом имея грамотное задание, вы можете не только отказать, но и мотивировать клиента на дополнительные оплачиваемые работы.

    Рассмотрим, на примере компании РБК СОФТ, что и в каком формате нужно описывать в техническом задании.
    Наша компания разрабатывает проекты на собственной CMS, и практически весь типовой функционал уже реализован в стандартных модулях. Все данные модули имеют техническое описание функционала модуля. И для разработки типовых проектов, нет смысла писать все с нуля. Поэтому, вместе с клиентом при обсуждении проекта, сразу определяется весь функционал будущего проекта, выбираются нужные модули и их описание сводится в техническое задание. При нестандартном функционале, тщательно описывается новый функционал в формате данного документы. Далее, готовы документ согласовывается с клиентом, подписывается и является неотъемлемой частью договора.

    Далее вводится новый документ – Художественное задание описывающий всю структуру и художественную составляющую проекта. После 2-3 часового брифинга клиента, аналитик и арт-директор разрабатывают данный документ, где описывают структуру, визуальные блоки, фирменные цвета, цепочки следования пользователя, портреты целевой аудитории, цели и бизнес задачи проекта. Опять же, данный документ согласовывается с клиентом и подписывается. На основе художественного задания разрабатывается дизайн будущего проекта и клиент в 99% случаев принимает работу, так как при презентации у него не возникает вопрос, почему именно так, а не по-другому. Все согласовано и описано в художественном задании и при желании что-либо изменить, задайте вопрос: «Зачем? Что изменит данная правка в предложенном решении бизнес задачи, которая была сформулирована в задании?». Не имея похожего документа, можно впасть в этап «двигания» картинок и «увеличения» логотипа, который может продлиться до бесконечности и в итоге родится мертворожденный проект, не решающий ни одной задачи с точки зрения бизнеса, а, как известно, любой коммерческий проект призван решать бизнес-задачи.

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

    Напоследок, правило работы с клиентом: Больше бумаги – чище попа!

    Игитян Тачат,
    Директор направления интерактивных коммуникаций,
    РБК СОФТ
    Digital Professionals Hub
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 13

      +2
      И вы все таки не ответили на вопрос (по технической части). Вот неясно что значит «всё»: описывать ли необходимые технологии? AJAX, Flash (HTTP, RFC-...). Как насчет рамок скорости работы страницы (каждой определенно страницы?), кол-во серверов (кол-во запросов), проверка на безопасность — SQL injections, XSS, CSRF (или раз клиент не вспомнил, то можно это в уме держать?), валидность/семантичность верстки, тип валидации форм (JS ли, PHP ли, оба ли, сообщения об ощибках), наличие функциональных и юнит-тестов, короче вся та внутренняя кухня которая для заказчика «черный ящик». Обычно всё это часто держится в уме (т.е. на совести подрядчика).
        0
        Ответ в том, что чем больше прописано и подписано заказчиком — тем лучше. Если заказчик в брифе не в состоянии прописать необходимые технологии, то это должен сделать разработчик (обсудив с заказчиком задачи, и выявив потребности). Но потом нужно прописать, что сайт будет разработан на с применением определенного флеш-аякса, нацеленого на такую-то скорость перезагрузки страниц и с такой-то нагрузкой на сервер. И это все прописывается в ТЗ уже вами, и подписывается…

        А то выяснится внезапно, что заказчик планировал на своем корпоративном сайте через год сделать отраслевую социальную сеть, и ваш движок к этому как-то не приспособлен… Кто будет виноват? ;)
          0
          В идеале ок, лучше записать всё. Но очень долго писать, плюс не факт что заказчик подпишет (без адвоката ;)
        0
        Необходимость визуальных технологий описывается в Художественном задании. Если в рамках нестандартного проекта ведется работа еще и разворачиваением системы на нескольких серверах, то все это конечно же описывается. Безопасность так же описана в ТЗ. По многим вопросам, на рынке есть внегласные стандарты, которых все крупные компании придерживаются. Но это отдельная статься про стандарты :)
          0
          Согласен, в крупных проектах техническое задание стандартизировано, и даже ГОСТы есть на эту тему.
          А в ваше рабочее ТЗ какие пункты входят?
          0
          ГОСТов нет, каждая компания вводит свои внутренние стандарты, но ГОС стандартов нету.

          практически все требования входят, данный документ в среднем около 100 страниц, описано максимально все.
            0
            Хочу уточнить что, нет ГОСТов на разработку именно сайтов. Есть ГОСТ на разработку программного обеспечения. У нас имеется опыт разработки документации по ГОСТ для сайта, подразумевая, что сайт является программным обеспечением (софтом), что является, в глубине своего понятия, правдой, но не всем клиентам это нужно, в большинстве случаев, они не хотят получить ГОСТовую документацию на сайт, так как она получается очень громозткой.

            +4
            Больше бумаги – чище попа!

            У автора ТЗ — да. У менеджера проекта и у студии целиком — нет. Давайте не будем кривить душой, ваше ТЗ из «многобумаги» на 99% есть копипаста из ТЗ предыдущих неудачзаказчиков, описывающее не то что нужно клиенту, а то что удобно вам (то есть, уже сделано за чей-то чужой счет). Разобраться с этим потоком копипасты ни сил, ни времени, ни даже IQ у заказчика часто нет. Он просто не понимает, о чем идет речь в большинстве положений, он видит ТЗ на сайт первый и возможно последний раз в жизни. Поэтому он подписывает ваш так сказать «труд» как есть.

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

            И тут ловким движением руки вы достаете подписанный заказчиком талмуд, на 891-ой странице которого русским по белому написано, что «к оформлению заказа допускаются только пользователи, подтвердившие адрес электронной почты», то есть, прошедшие процедуру регистрации. В этот момент ваша попа становится мягкой и шелковистой. Зато она начинает болеть у ваших юристов, которые вынуждены составлять исковое заявление в суд, потому что заказчик не хочет оплачивать почти готовый сайт по 1000-страничному скопипасченному ТЗ. Сам заказчик тоже недоволен — он потерял деньги, время, силы и нервы, и в итоге его еще и выставили козлом. Короче кроме вас лично — все в минусе.

            ТЗ на типовой интернет-магазин должно занимать одну, максимум две страницы. Не надо заморачиваться на мелочах, пока вы не можете показать наглядно, о чем идет речь. После утверждения макета и верстки ставится CMS с максимально «дефолтными» настройками, на неё вешается дизайн и вносится пробный десяток товаров. И уже в этот «недосайт» запускается клиент. Пусть он делает покупки разными способами, пусть учится добавлять товары, принимать заказы, размещать текстовые страницы и так далее. Всё хотелки и предложения — не описываются где-то там в 1000-страничной теории, а понятны тут же, на месте, и через пару часов можно посмотреть результат. Если какая-то хотелка требует слишком много времени — ну, объясняется, что это обойдется во столько-то времени и денег, решайте. У всех заказчиков бюджет и сроки ограничены и заранее известны вам, так чт количеством этих хотелок вы очень легко можете управлять) В-общем, как-то так. ИМХО разумеется, но…
              0
              у нас тз занимает одну страницу. в нем сформулировано лишь резиновость или нерезиновость, требования к кросбраузерности, движок на котром выполняется работа и последовательность работ.

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

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

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

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

                  правда есть еще одна ообенность — а откуда заказчик знает что ему нужно…
                0
                Спасибо за вашу позицию!
                Вы совершенно правы, что ТЗ не стоит превращать в формальность!

                И вы вдвойне правы, что нельзя исключать этап тестирования и отладки из процесса разработки сайта. В нашей практике этот этап собирает наибольшее количество вопросов, и позволяет решить «все эти мелочи и детали».

                Важно, чтобы на этом этапе не возникло внезапного вопроса о смене CMS, например, или требований к нагрузке… Это не мелкое допиливание, а полная переделка. И именно от таких ситуаций защищает ТЗ!
                0
                Читать Ваш текст невозможно. Работайте над стилистикой и орфографией. А ценность самого материала равна нулю.

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