Правила технического задания

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

Одним из способов разрешения такого конфликта является написание задания на проект – технического задания, которое предполагает полное и точно изложение требований внутрифирменного заказчика и является своеобразной инструкцией для IT -специалиста. Однако не каждый пользователь способен изложить свои мысли грамотно и доходчиво.
Приведу несколько советов для написания корректного задания пользователем, по которому можно работать и которое ложится в основу отношения между заказчиком решения и специалистом.

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

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

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

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

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

6. Обсудить написанное задание с непосредственным исполнителем, попытаться разрешить все вопросы, внимательно прислушиваясь к мнению собеседника. Не стоит забывать, что вы свою сферу деятельности знаете лучше и только вы можете точно объяснить, какой инструмент вам необходим для эффективно работы. IT-специалист знает свое дело и не обязан знать нюансы работы каждого отдела в организации.

7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

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

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

Комментарии 42

    +2
    О наболевшем?)
      +3
      О наболевшем. Удалось побывать и в роли «исполнителя» и в роли «заказчика», барьер в понимании редко преодолим. Иногда приходится работать чисто по проектной документации и разбираться в чужой для себя сфере — это отнимает и силы, и время.
        +3
        Не всегда получается сформулировать задание в таком объеме, в котором вы указали. Зачастую все дописывается, договаривается по мере возникновения вопросов. При этом, эту работу должен выполнять даже не проджект менеджер, а аналитик, который будет учитывать мнение всех заинтересованных лиц в данной команде разработки. Иначе, если составлять все документы, которые вы говорите, можно потратить год(-ы), в то время как другие уже начали работать над продуктом, а не документацией.
        Тоже пример из личного опыта.
          0
          Совершенно верно. Однако следует учитывать масштаб реализуемого проекта. Как правило, в большинстве рабочих вопросов и некрупных проект-отчетов такой схемы достаточно. Более того, в любом случае пользователь (при крупном проекте — каждый член рабочей группы) должен сначала понять, что ему надо, а затем транслировать это аналитику или исполнителю непосредственно.
            0
            Ну и своего опыта написания бизнес-требований хочу сказать, что все верно в статье изложено. Порой было сложно изложить на бумаге, что конкретно хочется. Просто шёл от обратного — обсуждал детали, а там уже вырисовывалось и обобщенное описание.
            Но всё равно, уже по ходу реализации приходится вмешиваться и уточнять-уточнять-уточнять. Хотя это нормально: полная вовлеченность в процесс рождает новые идеи и указывает на движение проекта.
            ;)
              0
              Хорошо, когда уточнения идут по ходу реализации. Хуже, когда сделаешь все, запустишь, пользователь радуется. А в момент непосредственной работы завляет, что это и то он «видел по-другому» и «исправить всего ничего». А по сути — менять все в проекте :)
            +1
            Ну да, а потом можно потратить ещё год (ы) на «допиливание» системы. Работал я как-то в одной конторе, где была мсамописная CRM-система. Процесс разработки выглядел крайне занятно, скажу я вам — программист со слов писал доработки. Качество результата было никаким. Сроки разработки тоже были впечатляющими — за 5 лет написали базовый функционал, который есть в любой покупной (а то и бесплатной) CRM.
              –1
              О, это отдельная песня! Особенно «радует», когда покупаешь продукт и начинаются внешние доработки, то есть речь не о программисте из соседнего кабинета, а о каждом «допиливании» внешним исполнителем за отдельную плату. Тот случай, когда требования пользователей, которые они сами не понимают, требуют еще и денег. Особенно актуально это для служб маркетинга, которым вечно недостает очередного аналитического модуля, который при желании любой грамотный пользователь сотворит в MS Access из уже существующих массивов данных.
                0
                Требования требуют денег??? Ну это уже совсем беспредел :)
            +3
            Все это просто слова, а не инструкция к действию. Чтобы пользователь смог составить ТЗ ему нужен хорошо проработанный шаблон, желательно активный, с подсказками и консультант в придачу.

            Помнится, кто-то на хабре рекламировал свой шаблон для составления ТЗ на сайт. Для некоторых задач его можно использовать. А для бизнес приложений мне шаблоны не встречались. Может уже есть.
              +1
              Кстати, о шаблонах. Для каждой организации они опять-таки свои. Более того, удалось поработать с разными шаблонами. Некоторые включают в себя лишь пункты: цель, пользователь, входные данные, выход отчета, особенности. Не каждый пользователь способен так кратко емко описать задачу.
              А на дополнительные консультации зачастую у пользователей не хватает времени. Приходилось даже сталкиваться со страхом обсуждения.
                0
                Возьмите шаблон любой курсовой работы. Проблема, цель, задачи, теоретическая часть, практическая часть, ссылки. Этого всего более чем достаточно для старта.
              +4
              Из своей практики могу сказать, что пользователи никогда не знают, что хотят. Только активная работа аналитика и создание прототипов помогает пользователям осознать требования к системе.
                0
                Баян, но все же:

                image
                  –1
                  Был случай когда на сайте, производились переделки одной страницы более 5 раз. И все разы разнообразны. Самое, что интересно, так это то, что заказчик конкретно ставит задачи, а толи мы тупим, толи заказчик выеживается… Я сейчас перечислю эти задачи дословно (копи-паст из почты).

                  Задача 1: На странице партнеры сделать перчень партнеров
                  Решение: Создается страница с текстовым списком партнеров

                  Задача 2: Создать описание каждого из партнеров
                  Решение: Создается отдельный документ под каждого партнера и там вводится детальное описание. Название партнера является ссылок на описание полное.

                  Задача 3: Добавить логотипы в список партнеров
                  Решение: Добавляется логотип фирмы партнера на страницу с перечнем партнеров

                  Задача 4: Сделать ярче, выровнять, подвинуть, поменять цвет, добавить отсутп и т.п.
                  Решение: Все выполняется на месте показывая заказчику

                  Задача 5: Убрать список партнеров. Имя партнера сделать заголовком и под заголовок поместить описание.
                  Решение: Вместо динамически формируемой страницы партнеры (лого, заголовок) создаем статичную страницу с текстом и под название партнера помещаем описание.

                  Задача 6: Поменять описания, т.к. они не устраивают партнеров
                  Решение: Тексты меняются

                  Так-то, а вы говорите аналитик… Толи ваш аналитик должен быть эксрасенсом, толи аналитик должен ваш рисовать протатип каждой страницы… Самое что интересное, данные задачи можно было выполнить по схеме Задача 1 + Задча 6, но нет ведь, нафига тогда Задача 4 делается перед заказчиком и он ее принимает? Видимо мы лохи и не умеем составлять договор (в ТЗ подобное не оговорить, ведь сами понимаете размер, положение элемента, шрифт, и т.п.).

                  З.Ы. Никому не советую попадаться на подобные уловки заказчиков. И страхуйте себя в договоре «порогом исправлений».
                    0
                    Я говорю про проекты, которые длятся больше года и стоят больше 10 млн. Сначала аналитик выясняет, как устроена компания и как решить проблемы заказчика, потом делается прототип системы в Mockup или любой другой среде для разработки прототипов.
                  +2
                  Грустно, но это утопия.
                    0
                    В своем опыте удалось пользователей приучить к порядку в ТЗ, но только в плане некрупных задач.
                    Как дело доходит до масштабных проектов, сразу «в друзьях согласья нет», сталкиваешься прежде всего с проблемой конфликта интересов и пожеланий даже внутри рабочей группы одного направления.
                    +3
                    Разве не лучше, когда техзадание составляет исполнитель (аналитик, программист) со слов заказчика?
                    Тогда заказчик, перечитав, может указать те места, где исполнитель просто его не понял.
                      0
                      Такой путь тоже справедлив и был испробован. Однако пользователи не понимают профессиональных тонкостей разработчика и начинают приписывать совершенно бесполезные и «перегружающие» требования, настаивая на необходимости данных, которые потом ни разу не используют.
                      Самое удачное решение — совместное написание ТЗ в рабочей группе, с лояльными пользователями этот опыт дал хорошие плоды, появилось понимание. Однако у подавляющего большинства менеджеров по их словам не хватает времени на обсуждение — оно уходит на препирания по поводу реализации задачи :)
                        0
                        Со слов тоже не то. Во-первых, исполнитель может понавставлять в ТЗ технических терминов, даже сознательно их избегая (ну не в сантиметрах же ширину формы указывать, учитывая, что «сантиметры» иной раз даже на одном мониторе под одной осью разные), заказчик не переспросит или спросит, ему на словах объяснят, а он поймёт неправильно. Во-вторых, против аргумента «а же я вам говорил, а вы не записали» (естественно, когда проект уже почти готов) даже диктофон не помогает. Заказчик тоже человек и вот так сходу описать все детали и нюансы (которые раз в год случаются, а сейчас как раз полгода прошло) автоматизируемых бизнес-процессов вряд ли кто безошибочно сможет. По-моему, наиболее эффективны частые интенсивные диалоги с показом прототипов и письменным резюме разговора.

                        +1
                        Забыли очень важную вещь — прототипирование.

                        Что касается отчетов — тут вообще идеально. Пользователь обычно может нарисовать отчет который он в точности хотел бы получить, это уже готовое задание на 90%.
                          0
                          Обычно бывает полезно разбить задание на этапы:
                          * на первом этапе создаётся нефункциональный прототип интерфейса
                          * на втором этапе создаются функции, обеспечивающие минимальную работоспособность
                          * на третьем добавляются расширенные функции
                          * затем остальные «хотелки» пользователей

                          Это позволяет лучше контролировать срок работы, быстрее обнаруживать недосказанность в задании.
                            +1
                            С этими проблемами на ура справляется XP (экстремальное программирование, а не версия Windows).

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

                            Рядовые пользователи понятия не имеют, что они хотят. У них есть регламент и процедура выполнения определенных действий. Настоящий профессионал будет придерживаться данного регламента изначально, постепенно меняя мышление с новыми прототипами, если можно предложить что-то более удобное. Пользователь может описать свои пожелания только на самом примитивном уровне, и не заставляйте его писать развернутые ТЗ, он напишет все равно самым примитивным языком. Собрать документацию порой нереально, а тонкостей по каждому документу найдется столько, что документы по описанию этих тонкостей будут больше, чем исходный документ
                              –4
                                0
                                //Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится//

                                Вот именно, принцип работы его не интересует, Любую задачу можно решить несколькими способами, поэтому нагрузку на сервер вызывает не но то хочет пользователь, а то как вы реализовали это желание.
                                  0
                                  Пользователь требует все наимельчайшие данные, полагая, что они ему дадут какие-то особые возможности. Зачастую реализуется агрегация и детализация. Затем детализация подавляющим большинством пользователей либо «снимается» и не используется, либо не снимается вообще.
                                  0
                                  Главное — не увлекаться написанием ТЗ. Я видел докуметацию на крупные проекты по 100 страниц. Надеяться на то, что это кто-то прочитает не приходится, а потому эффективность такого документа близка к нулю
                                    0
                                    100 страниц для крупного проекта, особенно, если есть схемы и макеты, — это даже мало.
                                      0
                                      Это убийственно много, чтобы прочитать обычному человеку.
                                        0
                                        Встречались ТЗ от 1 до 300 листов. Лучше прочитать 100 подробных листов и не пожалеть время в них разобраться, чем потом «допиливать» и менять все заново. Но в таком объеме, как правило, уже много лишней информации и описаний, особенно в экономической аналитики, например. А для технического проекта 300 листов не предел.
                                          0
                                          Безусловно, но лучше сократить максимально количество страниц и сделать прототип
                                          0
                                          100 страниц — убийственно много, чтобы прочитать обычному человеку? если не ошибаюсь, средняя скорость чтения — 10 страниц в час. имеется ввиду стандартная книжная страница. А4, написанная 14 шрифтом и 1,5 интервалом содержит меньше информации. вобщем получается не больше 1 рабочего дня на ознакомление с тз — по-моему не так много.

                                          так дальше пойдет и ТЗ в твиттере писать будем, не больше 140 знаков на одно функциональное требование ))
                                      0
                                      В таких статьях не хватает примеров под каждый пункт. Как было — как надо делать.
                                        0
                                        Прям мечта всех технократов — «пользователь должен, пользователю нужно».

                                        Поделитесь плс, какому проценту и количеству пользователей вам удалось навязать эти правила и каким образом?
                                          0
                                          как говорилось в одном бородатом опусе: что пользователю нужно, ему объяснит отдел маркетинга ))
                                            0
                                            После полутора лет упорной работы и «наколов» с реализацией проектов в виде постоянных исправлений четко формулировать свои мысли и грамотно излагать их в ТЗ у меня научилось 12 человек — это 2/3 моих внутренних клиентов.
                                              0
                                              А какая у вас при этом должность, если не секрет? И как происходил процесс «обучения» — их руководитель спустил им шаблон, вы в разработке стали принимать в работу заявки на доработку только в форме с обязательными полями, как-то ещё?
                                            0
                                            Звучит красиво, но на деле такая схема работать в большинстве случаев не будет.

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

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

                                            Подробное описание в ТЗ, конечно, замечательно, но может занять слишком много времени. Опять-таки, тут нужен аналитик, который знает достаточно и бизнеса, и технологии, чтобы определить необходимый уровень.

                                              0
                                              Если в нашей конторе люди станут вместо обычной заявки в аля «не запускается excel» заполнять анкету, то когда придет время проверки СМК у админов не останется времени на «текучку», да и не каждый юзер в состоянии заполнить подобную анкету.

                                              По моему, данную схему нужно упростить до банальной записи «не запускается прога ....», т.к. пока юзер будет заполнять вашу анкету опытный админ уже устранит причину.
                                                0
                                                Еще необходимо в письменном виде получить согласие от пользователя / заказчика о том, что текст ТЗ его устраивает, а то часто бывает что после написания ТЗ, и его половины реализации, пользователь вдруг просыпается и говорит: ой уже не нужно, или меняет суть всего, и хочет все по-другому.
                                                А еще во время реализации лучше держать в курсе своего заказчика, по мере готовности показывать, спрашивать мнение, чтобы к финалу реализации на выходе получилось действительно нужный функционал.
                                                  +1
                                                  ТЗ — не только инструмент разрешения конфликтов между заказчиком и исполнителем.
                                                  Это еще и способ прогнозирования затрат, ведь бизнесу часто требуется не просто реализация проекта: ему требуется понимать сроки и бюджеты, чтобы оценить эффективность вложения денег.
                                                  А более-менее точные сроки и бюджеты невозможно дать без предварительной формализации работ в виде ТЗ.

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

                                                  Но я полноценные большие ТЗ не очень люблю: слишком негибко получается :-)
                                                  Лучше разбивать проект на как можно более мелкие составляющие и двигаться к достижению целей итерациями.

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое