Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
Да, все по делу. Описать все — практически невозможно. Детализация зачастую ниже уровня, описывающего все и вся и не дающего возможности для халтуры. Справедливости ради — слишком высокая степень детализации не даст возможности и улучшить что-то. Просто скует и ограничит в строгих рамках.
Так как защитить себя от возможных проблем? Ведь все может скатиться до ковыряния в буквах и исполнения «на отвали», которое формально будет соответствовать требованиям? Вот на эти вопросы ответы были бы интересны.
Так как защитить себя от возможных проблем? Ведь все может скатиться до ковыряния в буквах и исполнения «на отвали», которое формально будет соответствовать требованиям? Вот на эти вопросы ответы были бы интересны.
Я думаю эта ситуация похожа на законодательство или договор – как ни опиши права и обязанности, порядочный человек останется порядочным, а негодяй — негодяем. В идеале, заказчик должен рассказать исполнителю о своих потребностях, а исполнитель — использовать свои знания и опыт для того, чтобы удовлетворить эти потребности в лучшем доступном ему виде.
Заказчик — эксперт в своей области, а исполнитель — в своей. Несмотря на это, многие заказчики пытаются заниматься микро-менеджментом проектов, что очень часто приводит к низкому качеству исполнения, либо к сорванным проектам.
По моему личному опыту, лучшие проекты были сделаны когда заказчик доверял мне и моей команде.
Заказчик — эксперт в своей области, а исполнитель — в своей. Несмотря на это, многие заказчики пытаются заниматься микро-менеджментом проектов, что очень часто приводит к низкому качеству исполнения, либо к сорванным проектам.
По моему личному опыту, лучшие проекты были сделаны когда заказчик доверял мне и моей команде.
Заказчик — эксперт в своей области, а исполнитель — в своей. Им им нужен посредник, который поймёт, что сказал заказчик и расскажет это на доступном исполнителю языке (в виде того же ТЗ). Таких посредников называют, кажется, аналитиками.
Без них очень велика вероятность конфликтов типа «Любой дурак знает, что при увольнении сотрудника ему начисляется компенсация за неиспользованный отпуск, даже если он один день проработал, а у вас программа вообще не считает её» или «Надо было писать в ТЗ „документ Word 2007 формата docx“, а не „документ в виде готовом для печати“»
Если говорить о программах, то ТЗ, описывающее вообще всё, само будет требуемой программой.
Да, пожалуй. Получается, что крайняя степень детализации задания — его выполнение.
Верно!
Даже самый опытный исполнитель всегда ограничен и ТЗ может быть идеально-полным только по факту исполнения. Замечательная мысль, спасибо!
Даже самый опытный исполнитель всегда ограничен и ТЗ может быть идеально-полным только по факту исполнения. Замечательная мысль, спасибо!
В такой трактовке программа будет скорее Техпроектом. :)
ТЗ описывает то, что должна быть сделано. А Техпроект — как должно быть сделано.
ТЗ описывает то, что должна быть сделано. А Техпроект — как должно быть сделано.
Кто-то из классиков, помнится, писал, что программист — это не человек, который пишет код, а человек, который формулирует задачу на основе пожеланий клиента.
Помимо тех. задания всегда прошу заказчика оочень детально рассказать о компании, рынке на котором она работает, её некоторых бизнес процессах и прочем.
Ключевые моменты в разговоре выписываю на листок. Так более четко проникаешься заказом и его спецификой. В тех. задании это конечно же не указывается. Так, больше для себя.
Ключевые моменты в разговоре выписываю на листок. Так более четко проникаешься заказом и его спецификой. В тех. задании это конечно же не указывается. Так, больше для себя.
Полностью согласен с вами. Знакомство с областью деятельности заказчика — совершенно верное и необходимое, на мой взгляд, действие для понимания того, что он хочет от продукта.
Но все ли разработчики вникают в нее, или в большинстве случаев делают «как в ТЗ», игнорируя область деятельности заказчика?
Но все ли разработчики вникают в нее, или в большинстве случаев делают «как в ТЗ», игнорируя область деятельности заказчика?
Про «не торопитесь с релизом» верно сказано.
Замечательная статья, кратко, не технично. Как раз пособие для клиентов!
ТЗ — это инструмент Исполнителя.
У Заказчика инструменты другие — бетономешалки, бетономешальщики и «сайт, продающий бетон», который Исполнитель обязуется ему сделать.
Будет правильно, если Исполнитель сам проработает или переработает ТЗ (стараясь максимально следовать интересам Заказчика). И будет всем бесспорное счастье)
У Заказчика инструменты другие — бетономешалки, бетономешальщики и «сайт, продающий бетон», который Исполнитель обязуется ему сделать.
Будет правильно, если Исполнитель сам проработает или переработает ТЗ (стараясь максимально следовать интересам Заказчика). И будет всем бесспорное счастье)
Если рассматривать термин шире, то общее тех. задание дает все-таки клиент («сайт, продающий бетон»).
Но, в наиболее часто употребляемом значении, ТЗ — да, это инструмент исполнителя.
Но, в наиболее часто употребляемом значении, ТЗ — да, это инструмент исполнителя.
Вообще, наверное, не стоит просить у заказчика готовое ТЗ, ничего хорошего точно не выйдет. Четко и полно сформулировать требования к продукту на основе пожеланий клиента — задача менеджера.
Формулировка требований к продукту — задача не абстрактно менеджера, а конкретно аналитика. Этот аналитик может быть у заказчика. В этом случае заказчику повезло либо это корпоративный заказчик и он знает что ему нужно. Заказчик может нанять независимого аналитика. Такого ещё поискать надо. Ну, или аналитик должен быть у исполнителя.
По мне, так ТЗ — это договор о намерениях между Заказчиком и Исполнителем. Один намеревается что-то такое сделать, а другой — как-то это использовать. :)
А то, что получится в итоге — это результат уточнений и компромиссов между Заказчиком и Исполнителем. И частенько бывает, что он не совсем похож на то, что первоначально описывалось в ТЗ.
А то, что получится в итоге — это результат уточнений и компромиссов между Заказчиком и Исполнителем. И частенько бывает, что он не совсем похож на то, что первоначально описывалось в ТЗ.
Тогда заказчик имеет право подать на исполнителя в суд, и привести его к такому виду, какое требовалось в ТЗ(если я ничего не путаю).
Так оно и происходит.
Легитимность ТЗ всегда обеспечена договором. Например, ТЗ является его приложением.
Естественно, несоответствие ТЗ = несоответствию договору.
Легитимность ТЗ всегда обеспечена договором. Например, ТЗ является его приложением.
Естественно, несоответствие ТЗ = несоответствию договору.
Если есть такой риск, то все изменения надо оформлять официально.
Но за 20 лет моей практики в IT на нас заказчик ни разу не подал в суд. А мы на заказчика 1 раз (выиграли :)). Так что ИМХО такие риски не велики. А вот если не учитывать пожеланий Заказчика, то проблем может быть много.
Но за 20 лет моей практики в IT на нас заказчик ни разу не подал в суд. А мы на заказчика 1 раз (выиграли :)). Так что ИМХО такие риски не велики. А вот если не учитывать пожеланий Заказчика, то проблем может быть много.
Договор о намерениях — это договор. И, кстати, у нас и в договорах обычно пишут лажу. Договор должен определять отношения сторон не когда всё хорошо. А когда всё плохо. Но из-за повальной юридической безграмотности мы имеем то что имеем.
«Выбрав одну – вы заработаете геморрой, выбрав другую – достигнете небывалых высот мысли.»
Юмор: как одно с другим связано? :)
«Возведение технического задания в принцип – разрушительно для продукта.
Однажды автор встречался с Заказчиком, который утверждал, будто описание его задачи не допускает никаких разночтений и от исполнителя не зависит ничего. На его столе лежали предложения от разных подрядчиков и он выбирал самого бюджетного. При этом одет он был, отчего-то, не в самую дешевую одежду и, сидя в удобном кресле, пил ароматный пуэр. „
Не юмор: можете пояснить подробнее? Недостаточно понял идею.
Юмор: как одно с другим связано? :)
«Возведение технического задания в принцип – разрушительно для продукта.
Однажды автор встречался с Заказчиком, который утверждал, будто описание его задачи не допускает никаких разночтений и от исполнителя не зависит ничего. На его столе лежали предложения от разных подрядчиков и он выбирал самого бюджетного. При этом одет он был, отчего-то, не в самую дешевую одежду и, сидя в удобном кресле, пил ароматный пуэр. „
Не юмор: можете пояснить подробнее? Недостаточно понял идею.
Я имел ввиду некоторую непоследовательность человека, который окружает себя качественными и не самыми дешевыми вещами, но на решения для бизнеса смотрит исключительно через призму цены :)
Да тут ничего удивительного нету: так везде у нас. Люди ездят на X5 и удивляются, почему сайт стоит дороже 6000 рублей. Бизнесмены, как правило, скупи и экономны )
Ну если переплачивать всегда непонятно за что — то и прибыли не будет )
Главное золотую середину найти, и понимать, за что платишь и как полученное решение в дальнейшем скажется на результате. А для этого в предметной области надо разбираться… А если компания небольшая и руководитель единолично принимает решения по самым различным аспектам деятельности — то сразу во всем хорошо он не может разбираться… Такая вот дилемма )
Главное золотую середину найти, и понимать, за что платишь и как полученное решение в дальнейшем скажется на результате. А для этого в предметной области надо разбираться… А если компания небольшая и руководитель единолично принимает решения по самым различным аспектам деятельности — то сразу во всем хорошо он не может разбираться… Такая вот дилемма )
Слушайте, ну бред же чуть ли не в каждом параграфе.
Если вам не встречалось нормальное ТЗ, это не значит, что его не существует. Это значит, что вам просто не повезло. И я не говорю о ГОСТах серий 19.* и 34.*. Вот у ТЗ по ГОСТу основная беда — приоритет формы над содержанием. Но и то, и в них можно втиснуться. Хотя и сложно. Почитайте что на эту тему писал, например, Бесков года 3 назад.
Хочется растащить по цитатам каждое предложение, но обойдусь избранным.
Вообще-то, ТЗ должен писать исполнитель. В вашем примере идиоты оба — и заказчик и исполнитель. Но проблемой почему-то объявляется ТЗ.
В исходной фразе акцент был совсем не на том. ТЗ или комплекс требований или Software requirements specification определяет что должна делать система. А также каким ещё требованиям она должна удовлетворять.
У вас есть функциональные требования к продукту — с его помощью необходимо вытирать задницу.
А кроме функциональных продукт должен удовлетворять например нефункциональным требованиям. Таким как сопротивление на разрыв по перфорации. А также требованиям к производительности — в данном случае это может быть число слоёв или впитываемость. А ещё требованиям к пользовательскому интерфейсу, например, цвету. И т.д.
Обычно, по ТЗ абсолютно фиолетово на каком языке программирования и какой БД разработчик будет реализовывать систему. До тех пор пока конечный результат удовлетворяет всему комплексу требований.
Если разработчику недостаточно ТЗ, он может до программирования написать техпроект — документ, который на каждое требование описывает как система будет ему удовлетворять. Но вот такой документ в природе встречается ещё реже, чем нормальное ТЗ.
Если вам не встречалось нормальное ТЗ, это не значит, что его не существует. Это значит, что вам просто не повезло. И я не говорю о ГОСТах серий 19.* и 34.*. Вот у ТЗ по ГОСТу основная беда — приоритет формы над содержанием. Но и то, и в них можно втиснуться. Хотя и сложно. Почитайте что на эту тему писал, например, Бесков года 3 назад.
Хочется растащить по цитатам каждое предложение, но обойдусь избранным.
Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!
Вообще-то, ТЗ должен писать исполнитель. В вашем примере идиоты оба — и заказчик и исполнитель. Но проблемой почему-то объявляется ТЗ.
Давая представление о том, что будет делать продукт, техническое задание совершенно не способно описать, насколько хорошо он будет это делать.
В исходной фразе акцент был совсем не на том. ТЗ или комплекс требований или Software requirements specification определяет что должна делать система. А также каким ещё требованиям она должна удовлетворять.
Возьмем, для примера, рулон туалетной бумаги. Простейший предмет с элементарным техническим заданием и понятным каждому функционалом. Тем не менее, на полке супермаркета можно обнаружить совершенно разную бумагу.
У вас есть функциональные требования к продукту — с его помощью необходимо вытирать задницу.
А кроме функциональных продукт должен удовлетворять например нефункциональным требованиям. Таким как сопротивление на разрыв по перфорации. А также требованиям к производительности — в данном случае это может быть число слоёв или впитываемость. А ещё требованиям к пользовательскому интерфейсу, например, цвету. И т.д.
Обычно, по ТЗ абсолютно фиолетово на каком языке программирования и какой БД разработчик будет реализовывать систему. До тех пор пока конечный результат удовлетворяет всему комплексу требований.
Если разработчику недостаточно ТЗ, он может до программирования написать техпроект — документ, который на каждое требование описывает как система будет ему удовлетворять. Но вот такой документ в природе встречается ещё реже, чем нормальное ТЗ.
Под «ТЗ» разные люди (и заказчики, и исполнители) часто понимают совершенно разные вещи. Мне близка позиция, озвученная выше. ТЗ — это набор требований (функциональных и нефункциональных). При этом часто заказчик совершенно, либо поверхностно, касается нефункциональных требований. В частности, к веб-проектам к ним относится время отклика при такой-то нагрузке, низкая стоимость аппаратного масштабирования, низкая стоимость редизайна, низкий уровень глючности, фреймворк, на котором будет написан проект (здесь скрывается целая пачка нефункциональных требований более низкого уровня) и т.д.
На нынешнем этапе развития нашей команды разработчиков мы оперируем документами трех видов:
1. Рамочное ТЗ. Документ, в котором поверхностно описаны требования к системе, без детализации. Как правило, именно этот документ предоставляется заказчиком с последующими вопросами: «Сколько $? Сколько дней?». По такому документу можно сделать оценку трудоемкости (плюс-минус 50-200%) и уровня общего понимания заказчиком чего он вобще хочет.
2. ТЗ. Этот документ мы составляем сами в процессе плотного взаимодействия с заказчиком. Выясняем и записываем все существенные требования (как функциональные, так и не функциональные). По этому документу можно сделать оценку трудоемкости (а следовательно, и стоимости) с погрешностью 10-20%. Именно этот документ тщательно согласовывается с заказчиком, именно он служит основой договора. Именно этот документ в дальнейшем декомпозируется на задачи, которые заносятся в трекер, а затем выполняются, тестируются и принимаются.
3. Задание на разработку. Это документ для исключительно внутреннего пользования. Содержит некоторые технические детали реализации тех или иных требований, а также описание общей архитектуры системы. Если быть точным, то это не один, а несколько документов. Как правило, мы составляем один небольшой документ с глобальными для проекта описаниями, а также по одному (также небольшому) документу на каждую из задач, полученных на этапе декомпозиции (см. п.2). В этот документ записывается конкретика: названия сущностей, атрибутов, связей, используемые алгоритмы, библиотеки и т.д.
На нынешнем этапе развития нашей команды разработчиков мы оперируем документами трех видов:
1. Рамочное ТЗ. Документ, в котором поверхностно описаны требования к системе, без детализации. Как правило, именно этот документ предоставляется заказчиком с последующими вопросами: «Сколько $? Сколько дней?». По такому документу можно сделать оценку трудоемкости (плюс-минус 50-200%) и уровня общего понимания заказчиком чего он вобще хочет.
2. ТЗ. Этот документ мы составляем сами в процессе плотного взаимодействия с заказчиком. Выясняем и записываем все существенные требования (как функциональные, так и не функциональные). По этому документу можно сделать оценку трудоемкости (а следовательно, и стоимости) с погрешностью 10-20%. Именно этот документ тщательно согласовывается с заказчиком, именно он служит основой договора. Именно этот документ в дальнейшем декомпозируется на задачи, которые заносятся в трекер, а затем выполняются, тестируются и принимаются.
3. Задание на разработку. Это документ для исключительно внутреннего пользования. Содержит некоторые технические детали реализации тех или иных требований, а также описание общей архитектуры системы. Если быть точным, то это не один, а несколько документов. Как правило, мы составляем один небольшой документ с глобальными для проекта описаниями, а также по одному (также небольшому) документу на каждую из задач, полученных на этапе декомпозиции (см. п.2). В этот документ записывается конкретика: названия сущностей, атрибутов, связей, используемые алгоритмы, библиотеки и т.д.
«низкая стоимость аппаратного масштабирования» — конечно, такой пункт можно включить в ТЗ… но как проверять, что он исполнен. Проверка — это ведь вопрос формальный.
Проверить легко. Исполнитель предоставляет инструкцию, следуя которой можно добавить еще один физический сервер баз данных. Либо обязуется добавлять еще один физический сервер баз данных по запросу заказчика в пределах 2 человеко-часов. Упомянутое требование — низкоуровневое (оно, скорее всего, взято из рамочного ТЗ). В подписываемом ТЗ необходимо записывать только такие требования, исполнение которых заказчик может проверить самостоятельно. Иначе как он будет подписывать акт приемки-передачи работы?
Спасибо за развернутый комментарий.
Мне показалось, что мы немного по разному интерпретируем ТЗ.
Еще мне кажется, что можно бесконечно детализировать, но тех. задание, предусматривающее все — это утопия и напоминает карту с масштабом 1 к 1. Но это только мое мнение — я вполне допускаю, что многим людям оно не близко.
Мне показалось, что мы немного по разному интерпретируем ТЗ.
Еще мне кажется, что можно бесконечно детализировать, но тех. задание, предусматривающее все — это утопия и напоминает карту с масштабом 1 к 1. Но это только мое мнение — я вполне допускаю, что многим людям оно не близко.
Естественно, всегда надо знать где остановиться. Но когда я вижу документ, называемый ТЗ, объёмом 5-10 страниц на систему стоимостью 100 тыр., я уже начинаю подозревать неладное. Начиная его читать, я предполагаю что этот документ — бессистемное изложение никак не связаных между собой пожеланий. И знаете что? В 100% таких случаев мои подозрения подтверждаются.
Нет ничего ужасного в документе объёмом 100-150 страниц на локальную систему или подсистему. Обычно у аналитика уже есть масса готовых наработок, которые он использует. Начиная от плана-проспекта до разделов целиком.
Если делается ТЗ на систему, содержащую несколько подсистем, то у вас должны быть комплексные документы. Скажем, вам надо написать требования к системе интеграции чего-то своего с чем-то сторонним. На выходе получается следующий набор документов:
Глоссарий, требования к протоколу и схему сообщений можно безболезненно передать исполнителю, не раскрывая существенных подробностей функционирования самой системы интеграции.
Нет ничего ужасного в документе объёмом 100-150 страниц на локальную систему или подсистему. Обычно у аналитика уже есть масса готовых наработок, которые он использует. Начиная от плана-проспекта до разделов целиком.
Если делается ТЗ на систему, содержащую несколько подсистем, то у вас должны быть комплексные документы. Скажем, вам надо написать требования к системе интеграции чего-то своего с чем-то сторонним. На выходе получается следующий набор документов:
- Глоссарий
- Спецификация протокола
- Схема сообщений протокола
- Требования к серверу
Глоссарий, требования к протоколу и схему сообщений можно безболезненно передать исполнителю, не раскрывая существенных подробностей функционирования самой системы интеграции.
У нас в одном из многостраничных документов, с которым по идее должны были ознакомиться все разработчики, в середине было предложение: «Кто это прочитает, тому я поставлю ящик пива».
Так вот ящик пива был целый год невостребованным. Объёмный текст — это ужас.
Так вот ящик пива был целый год невостребованным. Объёмный текст — это ужас.
Как же хорошо работать с заказчиками которые читают предлагаемое вами ТЗ. Мне таких заказчиков пока не доводилось встречать за 8 лет работы в айти.
«Давая представление о том, что будет делать продукт, техническое задание совершенно не способно описать, насколько хорошо он будет это делать.»
Почему же? Есть масса измеримых параметров качества продукта, которые излагаются в ТЗ. Скорость обмена данными, время реакции на внешнее воздействие, время наработки на отказ — критериев качества можно придумать очень много.
«Даже самое подробное ТЗ содержит массу мест для вольной интерпретации – мест, которые исполнитель часто трактует в сторону уменьшения усилий. „
Вопрос качества написания ТЗ. Другое дело, что записывая каждый его пункт надо сразу понимать, как предполагается проверять исполнение. То есть, по-хорошему, одновременно с ТЗ пишется черновик программы-методики испытаний (ПМИ), по которой будет выполняться приемка работ.
Почему же? Есть масса измеримых параметров качества продукта, которые излагаются в ТЗ. Скорость обмена данными, время реакции на внешнее воздействие, время наработки на отказ — критериев качества можно придумать очень много.
«Даже самое подробное ТЗ содержит массу мест для вольной интерпретации – мест, которые исполнитель часто трактует в сторону уменьшения усилий. „
Вопрос качества написания ТЗ. Другое дело, что записывая каждый его пункт надо сразу понимать, как предполагается проверять исполнение. То есть, по-хорошему, одновременно с ТЗ пишется черновик программы-методики испытаний (ПМИ), по которой будет выполняться приемка работ.
Безусловно, что конечный продукт, почти наверняка, будет отличаться от ТЗ, хотя бы потому, что в процессе разработки станут видны какие то не учтенные моменты и дополнительно будут согласовываться и реализовываться (в идеале, на практике на них часто забивается болт и все всплывает в момент сдачи проекта, приводя к конфликту и бешенному затягиванию сроков сдачи).
Для разработчика выход один — закладывать в стоимость проекта риски. Причем хорошие такие риски.
Как это будет сделано — открыто или нет — зависит уже от разработчика.
В этом случае всегда есть бюджет на внеплановые работы (конечно, если разработчик благополучно не про… т все бабки еще не начав делать проект), улыбка на лице и дружба с клиентом.
Косяк — это может серьезно увеличить смету проекта, что может привести к отказу…
А если демпингуете собственные расчеты — будьте готовы к геморрою и, возможно, корявому продукту на выходе.
Хотя отказаться от проекта на, скажем, 200 т.р. достаточно сложно, сразу забывается, что он стоит все 300, главное срубить хоть это, а там разберемся. Вот это проблема…
Для разработчика выход один — закладывать в стоимость проекта риски. Причем хорошие такие риски.
Как это будет сделано — открыто или нет — зависит уже от разработчика.
В этом случае всегда есть бюджет на внеплановые работы (конечно, если разработчик благополучно не про… т все бабки еще не начав делать проект), улыбка на лице и дружба с клиентом.
Косяк — это может серьезно увеличить смету проекта, что может привести к отказу…
А если демпингуете собственные расчеты — будьте готовы к геморрою и, возможно, корявому продукту на выходе.
Хотя отказаться от проекта на, скажем, 200 т.р. достаточно сложно, сразу забывается, что он стоит все 300, главное срубить хоть это, а там разберемся. Вот это проблема…
Кстати, последний свой проект я недавно делал руководствуясь парой принципом, что ТЗ надо придерживаться и делать с душой, но по ТЗ, а вот все крупные изменения, предложения и т.п. сразу записывать в таск-лист на версию 2.
Таким образом мы не отклоняемся по времени от изготовления проекта по ТЗ, что должно радовать клиента. А по окончании проекта, у нас уже есть предложение для клиента по версии 2.
По моему это выгодно и клиенту (проект в срок, по ТЗ и можно все пощупать) и разработчику (есть еще дополнительный заказ на версию 2).
Таким образом мы не отклоняемся по времени от изготовления проекта по ТЗ, что должно радовать клиента. А по окончании проекта, у нас уже есть предложение для клиента по версии 2.
По моему это выгодно и клиенту (проект в срок, по ТЗ и можно все пощупать) и разработчику (есть еще дополнительный заказ на версию 2).
Не согласен с автором.
По сути всё, что тут красочно расписано, является следствем неприменимости waterfall к некритичным коммерческим проектам.
А ТЗ в реальной жизни можно и нужно оформлять, но на это есть свои ритуалы, трюки и хитрости, которые превращают его в полезный инструмент.
Кстати, картинка выбора богатым джентльменом дешёвой реализации искуственна — выбрать дешёвое можно за 60 секунд, вместо того, чтобы находиться в процесе выбора целый день. И вообще, он потому и богат, что аккуратно относится к деньгам.
По сути всё, что тут красочно расписано, является следствем неприменимости waterfall к некритичным коммерческим проектам.
А ТЗ в реальной жизни можно и нужно оформлять, но на это есть свои ритуалы, трюки и хитрости, которые превращают его в полезный инструмент.
Кстати, картинка выбора богатым джентльменом дешёвой реализации искуственна — выбрать дешёвое можно за 60 секунд, вместо того, чтобы находиться в процесе выбора целый день. И вообще, он потому и богат, что аккуратно относится к деньгам.
о необходимости ТЗ — habrahabr.ru/blogs/pm/5556/
Неверно. Исходная фраза звучит так: "Верблюд — это лошадь, разработанная комитетом"
Больше картинок с котэ в технические задания!
Если серьезно, человеки часто путают ТЗ с его величеством Брифом, пытаясь все функциональные и технические требования максимально формализовать, получая максимально формальный подход в разработке, который в принципе не способен породить продукт класса HiEnd.
Если серьезно, человеки часто путают ТЗ с его величеством Брифом, пытаясь все функциональные и технические требования максимально формализовать, получая максимально формальный подход в разработке, который в принципе не способен породить продукт класса HiEnd.
В статья написана хорошо, но в данном случае, на мой взгляд, есть некоторые неточности:
1. У заказчика ТЗ требовать безполезно. Максимум, что может предоставить заказчки — это требования, которые нужно переработать и соглдасовать
2. В статье ТЗ оторвано от контекста. Потому как, например по ГОСТ, есть требования, ТЗ, рабочий проект..., которые связаны между собой. И ТЗ — это далеко не первый продукт, с которого начинается разработка.
3. Когда пишется ТЗ нужно думать не как его написать или как создать продукт, а как проверить, что создано то, что требовал заказчик. Люблю приводить ссылку на презентацию Сергея Мартыненко «Написание тестов, как вид тестирования требований» vimeo.com/13803733.
Тогда, в самом начале, при написании требований или ТЗ все (заказчик и исполнитель) зают что в результате получится и какого качества.
1. У заказчика ТЗ требовать безполезно. Максимум, что может предоставить заказчки — это требования, которые нужно переработать и соглдасовать
2. В статье ТЗ оторвано от контекста. Потому как, например по ГОСТ, есть требования, ТЗ, рабочий проект..., которые связаны между собой. И ТЗ — это далеко не первый продукт, с которого начинается разработка.
3. Когда пишется ТЗ нужно думать не как его написать или как создать продукт, а как проверить, что создано то, что требовал заказчик. Люблю приводить ссылку на презентацию Сергея Мартыненко «Написание тестов, как вид тестирования требований» vimeo.com/13803733.
Тогда, в самом начале, при написании требований или ТЗ все (заказчик и исполнитель) зают что в результате получится и какого качества.
Как говорила моя преподавательница по управлению IT-проектами (по PMBOK), требования должны отвечать на вопрос «что?», а техническое задание — на вопрос «как?», а у нас (в России) принято соединять это всё в единую кашу и называть «ТЗ». По идее, заказчик пишет требования, описывая что он хочет получить, а ТЗ пишет заказчик, описывая как это будет реализовано.
Что то по делу, с чем то не согласен. В любом случае сколько работаю, то ТЗ для меня как отправной пункт, все равно на этапах показываешь работу и по ходу вносим правки, но у меня работа связана с артом тут немного проще, уйма описаний и т.д. мне не нужны. До этого занимался веб дизайном и графическим дизайном в принципе тоже ТЗ было просто как вспомогательный инструмент а не схема. Но в моем случае все ТЗ умещалось в одно письмо по мылу. Когда присылали ТЗ на несколько страниц то становилось очень утомительно его читать и как правило к концу уже забывал что в начале и запутывался) В итоге киш миш мог быть. Зачастую кстати в таких километровых ТЗ сам заказчик путается и забывает. На мой взгляд ТЗ должны быть как можно меньше по объему и понятно написаны а не с витиеватыми выражениями.
Оффтоп: если кому-то вдруг понравился нож с картинки с 85 инструментами, то он — настоящий и продается, например, тут.
Ну, пункт в тз вида «чтобы развивала гемморой» я ещё могу представить и реализовать его тоже можно. Но вот «чтобы с ее помощью достигать небывалых высот мыслей» — нет. Так что темно-серая, вполне возможно, разработана по четкому тз. пример с бумагой неудачный
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Согласно техническому заданию