Кстати, есть одна хорошая мысль про ТЗ и иже с ним:
Лучшая постановка задачи, - это написать заранее инструкцию пользователя.
И в конце инструкция автоматом есть и не паришься на тему компромиссов с тем как уже сделано и сразу видишь как система будет выглядеть в использовании.
=DeaD= писал(а):Кстати, есть одна хорошая мысль про ТЗ и иже с ним: Лучшая постановка задачи, - это написать заранее инструкцию пользователя.
Мысль в правильную сторону, но далеко не всегда верная. Как правило пользователь не должен знать технических данных. А идеальная инструкция пользователя звучит примерно так: 1. Включить. 2. Наслаждаться.
Даже если инструкция будет такая это как минимум указывает разработчикам на то, что ни в коем разе нельзя заставлять пользователя задавать 50 мутных опций. Если с такой инструкции не начать, а начать с технических требований, то в конце легко получить типичный копир из эпохи до ксерокса, вырвавшегося в лидеры, потому что он первым сделал копирование нажатием 1 кнопки
по-моему, если ТЗ нужно конкретно для того, чтобы исполнитель сделал все так как хочет заказчик (а это далеко не всегда так), то шаблоны тут не очень уместны.
По-моему, 1. В ТЗ должна быть описана суть работы, ее смысл и цель в терминах понятных исполнителю. 2. Написанию ТЗ должен предшествовать этап технической проработки проекта. 3. ТЗ должно писаться под конкретного специалиста и вместе с ним. 4. В ТЗ не должно быть воды. 5. В ТЗ по возможности не должно быть ссылок на другие докменты. Если они есть, то эти документы должны прилагаться. 6. В ТЗ должны быть расставлены приоритеты по требованиям (например: эту точность нужно обеспечить "кровь из носа", цену минимизировать "если получится" и т.п.)
Скорее к договору, а не ТЗ: 0. Должен быть жестко зафиксирован объем работ. Что является зоной ответственности исполнителя, а что нет.
Эд, под "честное слово о нераспространении" пришлю ТЗ в том виде, как я их пишу для программиста. Выкладывать не хочу. Вероятно оно неидеальное и абсолютно бесшаблонное, но зато это реальная живая работа.
Последний раз редактировалось Michael_K 23 дек 2010, 18:45, всего редактировалось 1 раз.
Что должно быть в ТЗ написано на каждом углу. А вот реальных ТЗ нигде нет. Выложите ТЗ которое можно в вашей точки зрения назвать эталоном и к чем нужно нам все стремится.
Ну, если говорить формально, то есть ТТ (технические требования), есть предпроектная проработка, в результате которой получается ПЗ (пояснительная записка), есть ТЗ (техническое задание), в конце получаются ТУ (технические условия)... И может быть я еще чего-то забыл ))
Это если формально подходить...
А если конкретно, ставить вопрос так "как мне объяснить исполнителю, что я хочу" (насколько я понимаю, именно этого хочет Эд), то все немножко (или даже не "немножко") по-другому.
Например, не имеет смысла писать в ТЗ на разводку платы фразы типа "Корпус должен не иметь сколов и царапин и должен быть окрашен в соответствии с ГОСТ12.345678 в желтозеленый цвет"... Это глупо. И таких пунктов в формально написанных ТЗ обычно "чуть менее чем все".
Michael_K писал(а):Эд, под "честное слово о нераспространении" пришлю ТЗ в том виде, как я их пишу для программиста. Выкладывать не хочу. Вероятно оно неидеальное и абсолютно бесшаблонное, но зато это реальная живая работа.
Присылай. Гарантирую не распространение. Но вообще-то я чего бучу-то поднял, есть большое желание научиться делать заказы фрилансерам на нашей робофорумовской площадке. Да и "студетнам" будет и полезно и прибыльно делать заказы на нашей площадке, глядишь быстрей стандартизируем хотя бы элементарные вещи в робототехнике.
2EdGull, тогда начинать надо не с ТЗ, а с постановки задачи. В ТЗ уже должен быть проект решения какой-то задачи. А проблемы начинаются обычно тут с фрилансом как раз на этапе постановки задачи - хочется 100% вероятности определения к примеру
Типичный образец "формального ТЗ". Оно наводнено пунктами типа "Климатические условия эксплутатации программы" или "Системный администратор должен иметь высшее профильное образование"