Comments 42
О наболевшем?)
О наболевшем. Удалось побывать и в роли «исполнителя» и в роли «заказчика», барьер в понимании редко преодолим. Иногда приходится работать чисто по проектной документации и разбираться в чужой для себя сфере — это отнимает и силы, и время.
Не всегда получается сформулировать задание в таком объеме, в котором вы указали. Зачастую все дописывается, договаривается по мере возникновения вопросов. При этом, эту работу должен выполнять даже не проджект менеджер, а аналитик, который будет учитывать мнение всех заинтересованных лиц в данной команде разработки. Иначе, если составлять все документы, которые вы говорите, можно потратить год(-ы), в то время как другие уже начали работать над продуктом, а не документацией.
Тоже пример из личного опыта.
Тоже пример из личного опыта.
Совершенно верно. Однако следует учитывать масштаб реализуемого проекта. Как правило, в большинстве рабочих вопросов и некрупных проект-отчетов такой схемы достаточно. Более того, в любом случае пользователь (при крупном проекте — каждый член рабочей группы) должен сначала понять, что ему надо, а затем транслировать это аналитику или исполнителю непосредственно.
Ну и своего опыта написания бизнес-требований хочу сказать, что все верно в статье изложено. Порой было сложно изложить на бумаге, что конкретно хочется. Просто шёл от обратного — обсуждал детали, а там уже вырисовывалось и обобщенное описание.
Но всё равно, уже по ходу реализации приходится вмешиваться и уточнять-уточнять-уточнять. Хотя это нормально: полная вовлеченность в процесс рождает новые идеи и указывает на движение проекта.
;)
Но всё равно, уже по ходу реализации приходится вмешиваться и уточнять-уточнять-уточнять. Хотя это нормально: полная вовлеченность в процесс рождает новые идеи и указывает на движение проекта.
;)
Ну да, а потом можно потратить ещё год (ы) на «допиливание» системы. Работал я как-то в одной конторе, где была мсамописная CRM-система. Процесс разработки выглядел крайне занятно, скажу я вам — программист со слов писал доработки. Качество результата было никаким. Сроки разработки тоже были впечатляющими — за 5 лет написали базовый функционал, который есть в любой покупной (а то и бесплатной) CRM.
О, это отдельная песня! Особенно «радует», когда покупаешь продукт и начинаются внешние доработки, то есть речь не о программисте из соседнего кабинета, а о каждом «допиливании» внешним исполнителем за отдельную плату. Тот случай, когда требования пользователей, которые они сами не понимают, требуют еще и денег. Особенно актуально это для служб маркетинга, которым вечно недостает очередного аналитического модуля, который при желании любой грамотный пользователь сотворит в MS Access из уже существующих массивов данных.
Все это просто слова, а не инструкция к действию. Чтобы пользователь смог составить ТЗ ему нужен хорошо проработанный шаблон, желательно активный, с подсказками и консультант в придачу.
Помнится, кто-то на хабре рекламировал свой шаблон для составления ТЗ на сайт. Для некоторых задач его можно использовать. А для бизнес приложений мне шаблоны не встречались. Может уже есть.
Помнится, кто-то на хабре рекламировал свой шаблон для составления ТЗ на сайт. Для некоторых задач его можно использовать. А для бизнес приложений мне шаблоны не встречались. Может уже есть.
Кстати, о шаблонах. Для каждой организации они опять-таки свои. Более того, удалось поработать с разными шаблонами. Некоторые включают в себя лишь пункты: цель, пользователь, входные данные, выход отчета, особенности. Не каждый пользователь способен так кратко емко описать задачу.
А на дополнительные консультации зачастую у пользователей не хватает времени. Приходилось даже сталкиваться со страхом обсуждения.
А на дополнительные консультации зачастую у пользователей не хватает времени. Приходилось даже сталкиваться со страхом обсуждения.
Из своей практики могу сказать, что пользователи никогда не знают, что хотят. Только активная работа аналитика и создание прототипов помогает пользователям осознать требования к системе.
Баян, но все же:
Был случай когда на сайте, производились переделки одной страницы более 5 раз. И все разы разнообразны. Самое, что интересно, так это то, что заказчик конкретно ставит задачи, а толи мы тупим, толи заказчик выеживается… Я сейчас перечислю эти задачи дословно (копи-паст из почты).
Задача 1: На странице партнеры сделать перчень партнеров
Решение: Создается страница с текстовым списком партнеров
Задача 2: Создать описание каждого из партнеров
Решение: Создается отдельный документ под каждого партнера и там вводится детальное описание. Название партнера является ссылок на описание полное.
Задача 3: Добавить логотипы в список партнеров
Решение: Добавляется логотип фирмы партнера на страницу с перечнем партнеров
Задача 4: Сделать ярче, выровнять, подвинуть, поменять цвет, добавить отсутп и т.п.
Решение: Все выполняется на месте показывая заказчику
Задача 5: Убрать список партнеров. Имя партнера сделать заголовком и под заголовок поместить описание.
Решение: Вместо динамически формируемой страницы партнеры (лого, заголовок) создаем статичную страницу с текстом и под название партнера помещаем описание.
Задача 6: Поменять описания, т.к. они не устраивают партнеров
Решение: Тексты меняются
Так-то, а вы говорите аналитик… Толи ваш аналитик должен быть эксрасенсом, толи аналитик должен ваш рисовать протатип каждой страницы… Самое что интересное, данные задачи можно было выполнить по схеме Задача 1 + Задча 6, но нет ведь, нафига тогда Задача 4 делается перед заказчиком и он ее принимает? Видимо мы лохи и не умеем составлять договор (в ТЗ подобное не оговорить, ведь сами понимаете размер, положение элемента, шрифт, и т.п.).
З.Ы. Никому не советую попадаться на подобные уловки заказчиков. И страхуйте себя в договоре «порогом исправлений».
Задача 1: На странице партнеры сделать перчень партнеров
Решение: Создается страница с текстовым списком партнеров
Задача 2: Создать описание каждого из партнеров
Решение: Создается отдельный документ под каждого партнера и там вводится детальное описание. Название партнера является ссылок на описание полное.
Задача 3: Добавить логотипы в список партнеров
Решение: Добавляется логотип фирмы партнера на страницу с перечнем партнеров
Задача 4: Сделать ярче, выровнять, подвинуть, поменять цвет, добавить отсутп и т.п.
Решение: Все выполняется на месте показывая заказчику
Задача 5: Убрать список партнеров. Имя партнера сделать заголовком и под заголовок поместить описание.
Решение: Вместо динамически формируемой страницы партнеры (лого, заголовок) создаем статичную страницу с текстом и под название партнера помещаем описание.
Задача 6: Поменять описания, т.к. они не устраивают партнеров
Решение: Тексты меняются
Так-то, а вы говорите аналитик… Толи ваш аналитик должен быть эксрасенсом, толи аналитик должен ваш рисовать протатип каждой страницы… Самое что интересное, данные задачи можно было выполнить по схеме Задача 1 + Задча 6, но нет ведь, нафига тогда Задача 4 делается перед заказчиком и он ее принимает? Видимо мы лохи и не умеем составлять договор (в ТЗ подобное не оговорить, ведь сами понимаете размер, положение элемента, шрифт, и т.п.).
З.Ы. Никому не советую попадаться на подобные уловки заказчиков. И страхуйте себя в договоре «порогом исправлений».
Грустно, но это утопия.
Разве не лучше, когда техзадание составляет исполнитель (аналитик, программист) со слов заказчика?
Тогда заказчик, перечитав, может указать те места, где исполнитель просто его не понял.
Тогда заказчик, перечитав, может указать те места, где исполнитель просто его не понял.
Такой путь тоже справедлив и был испробован. Однако пользователи не понимают профессиональных тонкостей разработчика и начинают приписывать совершенно бесполезные и «перегружающие» требования, настаивая на необходимости данных, которые потом ни разу не используют.
Самое удачное решение — совместное написание ТЗ в рабочей группе, с лояльными пользователями этот опыт дал хорошие плоды, появилось понимание. Однако у подавляющего большинства менеджеров по их словам не хватает времени на обсуждение — оно уходит на препирания по поводу реализации задачи :)
Самое удачное решение — совместное написание ТЗ в рабочей группе, с лояльными пользователями этот опыт дал хорошие плоды, появилось понимание. Однако у подавляющего большинства менеджеров по их словам не хватает времени на обсуждение — оно уходит на препирания по поводу реализации задачи :)
Со слов тоже не то. Во-первых, исполнитель может понавставлять в ТЗ технических терминов, даже сознательно их избегая (ну не в сантиметрах же ширину формы указывать, учитывая, что «сантиметры» иной раз даже на одном мониторе под одной осью разные), заказчик не переспросит или спросит, ему на словах объяснят, а он поймёт неправильно. Во-вторых, против аргумента «а же я вам говорил, а вы не записали» (естественно, когда проект уже почти готов) даже диктофон не помогает. Заказчик тоже человек и вот так сходу описать все детали и нюансы (которые раз в год случаются, а сейчас как раз полгода прошло) автоматизируемых бизнес-процессов вряд ли кто безошибочно сможет. По-моему, наиболее эффективны частые интенсивные диалоги с показом прототипов и письменным резюме разговора.
Забыли очень важную вещь — прототипирование.
Что касается отчетов — тут вообще идеально. Пользователь обычно может нарисовать отчет который он в точности хотел бы получить, это уже готовое задание на 90%.
Что касается отчетов — тут вообще идеально. Пользователь обычно может нарисовать отчет который он в точности хотел бы получить, это уже готовое задание на 90%.
Обычно бывает полезно разбить задание на этапы:
* на первом этапе создаётся нефункциональный прототип интерфейса
* на втором этапе создаются функции, обеспечивающие минимальную работоспособность
* на третьем добавляются расширенные функции
* затем остальные «хотелки» пользователей
Это позволяет лучше контролировать срок работы, быстрее обнаруживать недосказанность в задании.
* на первом этапе создаётся нефункциональный прототип интерфейса
* на втором этапе создаются функции, обеспечивающие минимальную работоспособность
* на третьем добавляются расширенные функции
* затем остальные «хотелки» пользователей
Это позволяет лучше контролировать срок работы, быстрее обнаруживать недосказанность в задании.
С этими проблемами на ура справляется XP (экстремальное программирование, а не версия Windows).
Пользователь понятия не имеет, что ему нужно, пока вы не сделаете хоть что-то, на основании чего он сможет сделать для себя выводы, подходит это для него или нет. Показал прототип — есть мгновенный фидбэк. Не показал прототип — два месяца переставлял кнопочку с левого угла в правый и наоборот.
Рядовые пользователи понятия не имеют, что они хотят. У них есть регламент и процедура выполнения определенных действий. Настоящий профессионал будет придерживаться данного регламента изначально, постепенно меняя мышление с новыми прототипами, если можно предложить что-то более удобное. Пользователь может описать свои пожелания только на самом примитивном уровне, и не заставляйте его писать развернутые ТЗ, он напишет все равно самым примитивным языком. Собрать документацию порой нереально, а тонкостей по каждому документу найдется столько, что документы по описанию этих тонкостей будут больше, чем исходный документ
Пользователь понятия не имеет, что ему нужно, пока вы не сделаете хоть что-то, на основании чего он сможет сделать для себя выводы, подходит это для него или нет. Показал прототип — есть мгновенный фидбэк. Не показал прототип — два месяца переставлял кнопочку с левого угла в правый и наоборот.
Рядовые пользователи понятия не имеют, что они хотят. У них есть регламент и процедура выполнения определенных действий. Настоящий профессионал будет придерживаться данного регламента изначально, постепенно меняя мышление с новыми прототипами, если можно предложить что-то более удобное. Пользователь может описать свои пожелания только на самом примитивном уровне, и не заставляйте его писать развернутые ТЗ, он напишет все равно самым примитивным языком. Собрать документацию порой нереально, а тонкостей по каждому документу найдется столько, что документы по описанию этих тонкостей будут больше, чем исходный документ
//Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится//
Вот именно, принцип работы его не интересует, Любую задачу можно решить несколькими способами, поэтому нагрузку на сервер вызывает не но то хочет пользователь, а то как вы реализовали это желание.
Вот именно, принцип работы его не интересует, Любую задачу можно решить несколькими способами, поэтому нагрузку на сервер вызывает не но то хочет пользователь, а то как вы реализовали это желание.
Главное — не увлекаться написанием ТЗ. Я видел докуметацию на крупные проекты по 100 страниц. Надеяться на то, что это кто-то прочитает не приходится, а потому эффективность такого документа близка к нулю
100 страниц для крупного проекта, особенно, если есть схемы и макеты, — это даже мало.
Это убийственно много, чтобы прочитать обычному человеку.
Встречались ТЗ от 1 до 300 листов. Лучше прочитать 100 подробных листов и не пожалеть время в них разобраться, чем потом «допиливать» и менять все заново. Но в таком объеме, как правило, уже много лишней информации и описаний, особенно в экономической аналитики, например. А для технического проекта 300 листов не предел.
100 страниц — убийственно много, чтобы прочитать обычному человеку? если не ошибаюсь, средняя скорость чтения — 10 страниц в час. имеется ввиду стандартная книжная страница. А4, написанная 14 шрифтом и 1,5 интервалом содержит меньше информации. вобщем получается не больше 1 рабочего дня на ознакомление с тз — по-моему не так много.
так дальше пойдет и ТЗ в твиттере писать будем, не больше 140 знаков на одно функциональное требование ))
так дальше пойдет и ТЗ в твиттере писать будем, не больше 140 знаков на одно функциональное требование ))
В таких статьях не хватает примеров под каждый пункт. Как было — как надо делать.
Прям мечта всех технократов — «пользователь должен, пользователю нужно».
Поделитесь плс, какому проценту и количеству пользователей вам удалось навязать эти правила и каким образом?
Поделитесь плс, какому проценту и количеству пользователей вам удалось навязать эти правила и каким образом?
как говорилось в одном бородатом опусе: что пользователю нужно, ему объяснит отдел маркетинга ))
После полутора лет упорной работы и «наколов» с реализацией проектов в виде постоянных исправлений четко формулировать свои мысли и грамотно излагать их в ТЗ у меня научилось 12 человек — это 2/3 моих внутренних клиентов.
Звучит красиво, но на деле такая схема работать в большинстве случаев не будет.
Прежде всего, как правило, пользователь не может сам определить, что именно ему нужно — во многом потому, что он не знает, а что именно можно сделать. Определение того, что нужно заказчику — это долгая и непростая работа, анализ.
С документацией тоже могут быть проблемы — её может толком не быть, или она может быть очень сложной, так что разобраться с карандашом не получится (представьте себе, например, документацию на систему биржевой торговли....)
Подробное описание в ТЗ, конечно, замечательно, но может занять слишком много времени. Опять-таки, тут нужен аналитик, который знает достаточно и бизнеса, и технологии, чтобы определить необходимый уровень.
Прежде всего, как правило, пользователь не может сам определить, что именно ему нужно — во многом потому, что он не знает, а что именно можно сделать. Определение того, что нужно заказчику — это долгая и непростая работа, анализ.
С документацией тоже могут быть проблемы — её может толком не быть, или она может быть очень сложной, так что разобраться с карандашом не получится (представьте себе, например, документацию на систему биржевой торговли....)
Подробное описание в ТЗ, конечно, замечательно, но может занять слишком много времени. Опять-таки, тут нужен аналитик, который знает достаточно и бизнеса, и технологии, чтобы определить необходимый уровень.
Если в нашей конторе люди станут вместо обычной заявки в аля «не запускается excel» заполнять анкету, то когда придет время проверки СМК у админов не останется времени на «текучку», да и не каждый юзер в состоянии заполнить подобную анкету.
По моему, данную схему нужно упростить до банальной записи «не запускается прога ....», т.к. пока юзер будет заполнять вашу анкету опытный админ уже устранит причину.
По моему, данную схему нужно упростить до банальной записи «не запускается прога ....», т.к. пока юзер будет заполнять вашу анкету опытный админ уже устранит причину.
Еще необходимо в письменном виде получить согласие от пользователя / заказчика о том, что текст ТЗ его устраивает, а то часто бывает что после написания ТЗ, и его половины реализации, пользователь вдруг просыпается и говорит: ой уже не нужно, или меняет суть всего, и хочет все по-другому.
А еще во время реализации лучше держать в курсе своего заказчика, по мере готовности показывать, спрашивать мнение, чтобы к финалу реализации на выходе получилось действительно нужный функционал.
А еще во время реализации лучше держать в курсе своего заказчика, по мере готовности показывать, спрашивать мнение, чтобы к финалу реализации на выходе получилось действительно нужный функционал.
ТЗ — не только инструмент разрешения конфликтов между заказчиком и исполнителем.
Это еще и способ прогнозирования затрат, ведь бизнесу часто требуется не просто реализация проекта: ему требуется понимать сроки и бюджеты, чтобы оценить эффективность вложения денег.
А более-менее точные сроки и бюджеты невозможно дать без предварительной формализации работ в виде ТЗ.
Кроме того, ТЗ — это еще и способ организации работ программистов. Часто бывает удобно обсудить проект с заказчикам и сделать ТЗ, чтобы быстро передать формализованную задачу программистам.
Но я полноценные большие ТЗ не очень люблю: слишком негибко получается :-)
Лучше разбивать проект на как можно более мелкие составляющие и двигаться к достижению целей итерациями.
Это еще и способ прогнозирования затрат, ведь бизнесу часто требуется не просто реализация проекта: ему требуется понимать сроки и бюджеты, чтобы оценить эффективность вложения денег.
А более-менее точные сроки и бюджеты невозможно дать без предварительной формализации работ в виде ТЗ.
Кроме того, ТЗ — это еще и способ организации работ программистов. Часто бывает удобно обсудить проект с заказчикам и сделать ТЗ, чтобы быстро передать формализованную задачу программистам.
Но я полноценные большие ТЗ не очень люблю: слишком негибко получается :-)
Лучше разбивать проект на как можно более мелкие составляющие и двигаться к достижению целей итерациями.
Sign up to leave a comment.
Правила технического задания