Как писать ТЗ (техническое задание) для разработчиков ПО?
Запись от Jin X размещена 27.11.2021 в 00:54
Показов 4618
Комментарии 13
|
Как писать ТЗ (техническое задание) для разработчиков программного обеспечения? Зачем? Давайте я напишу в чате! Есть такая поговорка: "без нормального ТЗ результат будет х/з". И заказчик, и разработчик заинтересованы в том, чтобы всё было сделано так, как задумывалось. Но к сожалению, даром телепатии разработчики обычно не обладают, и читать мысли заказчика не могут (по крайней мере, я – точно). Если заказчик что-то не описал, значит либо это неважно (т.е. делать этого не нужно, а если нужно, то делай как хочешь), либо важно, но сказать забыл (тогда за это потом придётся доплачивать отдельно, т.к. не было оговорено при согласовании задания). Часто бывает так, что заказчик описывает задачу "в общих чертах", не вдаваясь в детали. Это происходит потому, что либо он не хочет тратить на это время (а разработчик если и хочет, то уж точно не бесплатно), либо не совсем чётко представляет, что ему нужно (не пытался углубляться в детали). И то, и другое нехорошо, потому что в первом случае время потратить всё равно придётся, т.к. нормальный разработчик будет задавать 100500 вопросов о деталях, либо отправит писать ТЗ. Другой же просто сделает всё на своё усмотрение, и потом уже, извините, без претензий, вы не говорили, что надо делать вот так, а не эдак. Во втором случае в процессе работы может всплыть столько нюансов, что либо вас попросят доплатить за то, что вы забыли о них упомянуть, либо вы поймёте, что вам нужно совсем не то, что вы заказали. Написание подробного ТЗ заставит вас углубиться в детали, более чётко понять, что вам нужно, и сэкономит время разработчика и ваши финансы. Что касается "описания задачи чате", то это годится только для совсем простых заданий (с бюджетом, как правило, до 2000-3000 рублей). Если задача более или менее объёмная, то длинные описания в чатах, во-первых, неудобно читать (плохое форматирование, нет иллюстраций, нельзя распечатать). Во-вторых, в чате помимо описания задания будет много лишних сообщений, а собирать по всему чату крупицы ТЗ – занятие не самое весёлое, да и так можно чего-то упустить. Особенно, если ТЗ записано голосом или тем более рассказано по телефону (без записи). Всё должно быть зафиксировано в тексте! И в-третьих, как показывает практика, задание в чате описывается не слишком подробно. Поверьте, очень сильно напрягает долгое выяснение нюансов, и очень хочется заложить в бюджет этот час (два, три, пять) диалога с выяснением деталей задания. Ок. Как же нужно? Создайте документ MS Word, OpenOffice или т.п. А ещё лучше – документ Google Docs, доступ на редактирование которого нужно дать разработчику, чтобы вы вместе могли вносить туда правки (разработчик, например, сможет записать детали, выяснившиеся в процессе общения в чате). В документе должно быть:
Если вы не указали, что приложение должно использовать какой-то конкретный метод решения, библиотеку или версию библиотеки и пр., подразумевается, что можно использовать любой метод/библиотеку/версию. Если вы не указали, что приложение должно быть кроссплатформенным (работать под Windows, Linux, macOS, да ещё и на ARM), обычно подразумевается, что оно должно работать только под Windows на процессорах x86 (если это, конечно, не веб-разработка). Если вы не указали, что приложение должно быть многопоточным, подразумевается, что оно должно быть однопоточным. Если вы не описали какие-то функции (например, что некий список можно пополнять, удалять, сортировать), подразумевается, что такие функции реализовывать не требуется. И т.д. Я, конечно, задаю вопросы, чтобы прояснить вышеобозначенные моменты, но бывают ситуации, когда что-то действительно кажется очевидным, однако по факту нужно совершенно другое. Например, если заказчик говорит: "Пользователь вводит с клавиатуры число N, а программа должна вывести кол-во простых чисел, не превышающих N", – то вопрос о многопоточности может даже и в голову не прийти. Хочу ещё раз сакцентировать внимание на том, что проект в представлении заказчика и разработчика может выглядеть совершенно по-разному, если задание к нему описано недостаточно подробно. И если добросовестный разработчик сделал не совсем то, что ожидал заказчик, скорее всего это будет по причине того, что заказчик предоставил недостаточно подробное ТЗ. Если в задании что-то не указано, значит это несущественно. А как же иначе? Это важно понимать, во избежание конфликтов и лишних расходов! Финальный вариант документа отправляется в чат (или на почту) при окончательном утверждении заказа. И напоследок... Будьте добры, перед тем, как отправить ТЗ, прочтите его. Нет ли ошибок? А может, что-то уже перестало быть актуальным? Всё ли понятно (по возможности, дайте почитать кому-то ещё, чтобы выяснить это)? Что откуда берётся и куда отправляется? Достаточно ли подробно описаны различные сценарии работы? Если сказано, что нужно прочитать файл – понятно ли какой файл (с каким именем)? Что в нём хранится и в какой формате? Приведён ли конкретный пример содержимого этого файла? Если что-то нужно удалить, понятно ли что делать с данными, зависимыми от удаляемых? Если изображение должно вписаться в какую-то область, указано ли – с сохранением пропорций или без? Если мы работаем со звуковыми/графическими/видео файлами, то какие форматы должны поддерживаться (например, wav и mp3, png и jpg, avi и mp4)? И т.д. Избегайте фраз вроде "берётся некоторый файл" (какой именно?), "можно сделать такую функцию" (решите уж – нужно или нет... если же вы хотите уточнить бюджет с этой функцией и без неё, так и напишите) и т.п. Помните, что если вас можно понять неправильно – вас скорее всего поймут неправильно. Если вы не программист, вам может быть сложно учесть все детали или понять, как лучше сделать что-то – это нормально. Так и напишите: "сделайте это на своё усмотрение" или "я не знаю, как лучше это сделать, посоветуйте что-нибудь". Как бы хорошо и подробно вы не составили ТЗ, у разработчика, скорее всего, всё равно возникнут некоторые вопросы и потребуется уточнение какие-то нюансов. Однако, их будет значительно меньше, чем при описании задания в чате "в общих чертах"  Разумеется, углубляясь в детали, не нужно доводить всё до абсурда. Т.е. описывая программу деления двух целых чисел, необязательно детализировать всё настолько подробно: Нажмите сюда, чтобы посмотреть...
 В данном случае это будет чрезмерным усложнением и только увеличит стоимость, т.к. разработчику придётся обрабатывать все описанные вами случаи именно так, как вы указали.
И, пожалуйста, проявите уважение к читателю и потратьте время на форматирование документа: заголовки, отступы, выделения и пр. Не помешает и проверка на ошибки правописания (клавиша F7 в MS Word). Возможно, вам придётся показать его не одному человеку. Поверьте, хорошее ТЗ вызывает уважение и даже немного удивление, т.к. к сожалению, встречается не так часто, как хотелось бы 
|
Размещено в Фриланс
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Всего комментариев 13
Комментарии
-
Почему к сожалению? К счастью! Только представьте, что кто-то может читать мысли другого человека. Это значит он может прочитать информацию ему не предназначенную.Запись от wer1 размещена 27.11.2021 в 09:23 
-
Достаточно установить Brain Defender
Сообщение от wer1
Запись от Croessmah размещена 27.11.2021 в 17:33
-
ИМХО, сроки, бюджет и поддержка нужна/нет это не из ТЗ. Это должно быть "рядом". Точнее это "характеристика" уже именно заказа. В задаче уже на одном уровне: желаемое ТЗ, некое описание бюжета... В техническом задании только технические моменты. Вот уже на основании ТЗ можно говорить о сроках и бюджетах.
Все равно написание ТЗ процесс с итерациями. На него и ограничения по бюджету будут влиять и по времени... Но тем не менее.
Кроме того уж коли речь об универсальных рекомендациях по составлению тз.
Если ПО должно что то считать но не только входные данные, но и,при возможности, выходные данные по которым можно контролировать корректность расчета.
Если что то ГОСТИруется, регулируется внутренними и внешними документами - ссылки на них или, что еще лучше, в приложении.Запись от voral размещена 27.11.2021 в 17:44 
-
Хорошо подогревает более ответственный подход заказчика к написанию ТЗ - фраза в договоре "все что не указано в ТЗ явно, разрабатывается на усмотрение Исполнителя"
Запись от voral размещена 27.11.2021 в 17:46
-
В том числе и для того, чтобы проверить на грамотность, а еще лучше в спеллчекер его засунуть.
ТЗ без грамматических и стилистических ошибок в наше время вообще вызывает шоковое состояние.Запись от vantfiles размещена 27.11.2021 в 20:50
-
Возможно, это, конечно, логичнее по структуре. Но лично мне было бы удобнее видеть всё в одном документе.
Сообщение от voral
Пардон, перечитал несколько раз, но смысла фразы так и не понял
Сообщение от voral
Запись от Jin X размещена 28.11.2021 в 23:05
-
Добавил
Сообщение от vantfiles
Запись от Jin X размещена 28.11.2021 в 23:13
-
Но к сожалению, даром телепатии для разработчики обычно не обладают, и читать мыслей заказчика не могут (по крайней мере, я – точно).
Cлово "для" - лишнее, в правильном падеже "мысли", а не мыслей.Запись от vantfiles размещена 29.11.2021 в 05:35
-
Thanks, fixed (вероятно, в начале первого слова должна была быть другая буква, ну да ладно
Сообщение от vantfiles
)Запись от Jin X размещена 29.11.2021 в 12:13
-
Если есть возможность и вообще имеет какой то смысл в рамках конкретной задачи, то предоставлять эталонные результаты для различных входных значений... Т.е. если делаем калькулятор. то приложить:
Сообщение от Jin X
Пардон, перечитал несколько раз, но смысла фразы так и не понял
2+2 = 4
2+3 = 5
и т.п. особенно если этот калькулятор с "поправкой на ветер"
Правда тут тоже бывает подвох. Как правило если и предоставляют, то "типовые" случаи. А гораздо интереснее когда входные параметры "редко встречающиеся".
Сразу пример из опыта (правда его утрирую, чтоб лишними деталями не перегружать). В ходе разработки пришли что выходной параметр будет считаться по определенной формуле, и при всех предоставленных данных получилось все красиво и правильно. При этом один из входных параметров был например в диапазоне от 50 - 100... И так бывает в 99% случаев. И вот прилетает случай из оставшегося процента. и входной параметр 120. а формула, почти как "экспонента"
ну и все улетело в космос.
И вот такие ситуации когда клиент на этапе ТЗ вообще ни как не обозначает такие ситуации - обычное дело.... Причем вообще не зависит от сферы проекта... Уже с опытом начинаешь сразу такие места выявлять, и все равно когда говоришь, в ответ "да ну нафиг, не может быть" (хотя если поднажмешь) "теоретически может быть".... в общем "не делаем", а потом уже в боевом режиме "караул у нас все пропало"
Но, опять же, написание ТЗ штука итерационная, по этому некую долю способностей предсказывать программист должен иметьЗапись от voral размещена 30.11.2021 в 12:50
-
Кстати, хорошее дополнение. Добавил.
Сообщение от voral
Запись от Jin X размещена 01.12.2021 в 11:13
-
Писать ТЗ на ПО строго по ГОСТам ЕСПД! ГОСТ на ТЗ определяет чёткие разделы и их содержание! Читаем и пишем. Начальство и согласующие службы редактируют, исправляем, утверждаем и вперёд!
Запись от ngturey размещена 01.12.2021 в 12:15
-
Зачем?
Сообщение от ngturey
Может быть, это и полезно, когда нужно показать начальству, представить комиссии или какой-то гос. структуре. Но лично мне, к примеру, нужно для собственного удобства и понимания задачи.
Кто в здравом уме будет штудировать ГОСТ, чтобы заказать программу, скажем, за 10 т.р.? Ну или за 50 т.р.
Или это сарказм?Запись от Jin X размещена 02.12.2021 в 20:31
Сообщение от wer1
Может быть, это и полезно, когда нужно показать начальству, представить комиссии или какой-то гос. структуре. Но лично мне, к примеру, нужно для собственного удобства и понимания задачи.
