Главное Свежее Вакансии Образование
0 23 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Насколько детальным и вообще каким должно быть хорошее ТЗ?

Мне кажется, я этот вопрос уже задавала. Или не здесь, или не я. Словом, заранее извините, если повторяюсь.

Как вы лично считаете, до какой степени следует прописывать детали ТЗ? Представим себе веб-приложение. У него есть фронтэнд, бакэнд, база данных, какие-то дополнительные сервисы. В принципе даже несложное одностраничное приложение требует достаточной обдуманности. А если там две страницы, три, пять? А если бакэнд на самом деле достаточно сложен, требует защиты, сложной бизнес-логики, дополнительных библиотек и т.д.? А если это ТЗ фактически ты создаешь для себя (хотя и надеешься на дополнительных разработчиков в будущем)? А если технология, которую ты собираешься использовать, нова для тебя? А если, наоборот, не нова? И так далее.

Это тут ребята рассказали о своем логистическом сервисе, ТЗ для которого они создавали 4 месяца, и результатом был 200-страничный документ. И тут я поняла, что эта сторона дела была всегда моим слабым местом. Обычно я делала несколько набросков в тетради или каком-нибудь бесплатном приложении, и этого в принципе хватало, но может быть, это я только так думала, что хватало, а на самом деле нет. Потому что по факту всегда приходилось все переделывать. Моим принципом было "сделаю черновик, набросок, все равно потом все изменять". Так может, надо было продумать все как следует на этапе создания ТЗ?

Какой подход лично вы нашли для себя полезным? (Ну и заодно, какие инструменты используете для создания ТЗ). Всем спасибо!

ЗЫ Техническое задание рассматриваем исключительно как список правил, функциональности и т.д. для всех, кто участвует в проекте (исключая юридическую сторону вопроса).

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
ТЗ - это не архитектура приложения. Это список желаний клиента: хочу это, это и это. С учётом того, что всё, что может быть искажено и не так понято, будет искажено и не так понято.

Для себя вообще не вижу смысла делать ТЗ. ТЗ делают для тех, кому вы не очень доверяете.
Ответить
Екатерина К
Спасибо за ответ. Я в курсе, что ТЗ - это не архитектура.
Вопрос был о другом.
Даже если вы делаете собственный продукт, необходимо предствлять, какую именно функциональность вы хотите. Причем очевидно, что все сразу не сделать. Значит, надо выставить очередность.
Многие придуманные фишки забываются, если их не отметить хоть где-то. Именно для этого и делается ТЗ (хоть для себя, хоть для кого) - чтобы прописать все фичи и затем сделать продукт в соотсвтствии с этим документом.

Я всегда делаю ТЗ для себя, даже когда мне надо разработать одну фишку (это может быть просто чеклист, что не забыть, или набросок интерфейса). И да, даже себе я не доверяю! Забыть что-нибудь так легко, а если делаешь ТЗ для других исполнителей, они-то вообще ничего не знают о твоем продукте, не представляю, как можно обойтись без ТЗ в этом случае.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
Хорошие исполнители задают нужные вопросы, чтобы понять, что вы хотите получить.

Фишки, которые забываются просто не нужны. Вероятность, что ими не будут пользоваться в пределах 99%. Если даже вы про них забыли, то пользователи забудут ещё быстрее.

Функциональность не имеет значения. У продукта есть цель - задача, которую он решает. Он либо решает её хорошо, либо плохо. Собственно путь решения проблемы клиентом - это и есть продукт. Если вам нужно ТЗ, чтобы не запутаться в этом пути, то что-то не так. Будьте проще.

Есть принцип, когда меньше 10% дополнительной мощности стоит больше, чем 100% от цены. Новый процессор за 800 долларов мощнее тех, которые за 100 долларов вовсе не в 8 раз, а раза в 1.5.
Ответить
Екатерина К
О как.
Любопытный подход. Даже не знаю, что сказать на это.

Давайте рассмотрим какой-нибудь конкретный пример. Ну допустим, нам надо разработать спарк - сообщество людей, которые желают общаться на околостартапные темы. Вы правда думаете, что здесь можно без ТЗ обойтись?
Ответить
Симулятор бизнес-процессов
Сервис имитационного моделирования и оптимизации бизнес-процессов
Prolis Labkk
Планируемые фишки приложения не надо ни в ТЗ, ни в бизнес-требованиях прописывать (в случае одного постановщика требований и исполнителя). Обычный to-do лист.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
Если вы сами разрабатываете это сообщество, то зачем вам ТЗ? Начинайте сразу с архитектуры проекта: описывайте сущности (юзеры, проекты, вопросы, вакансии...) и отношения между ними.

ТЗ придуманы как способ разрешения конфликтов между разработчиками и клиентами. В случае любых разногласий обращаются к ТЗ. Большего смысла, чем прикрыть чью-то задницу, в нём нет. А вы уж сами решайте нужно прикрывать свою задницу от конкретных разработчиков или нет. Они также решат схожий вопрос по отношению к вам.
Ответить
Екатерина К
Не соглашусь. Возможно, под ТЗ мы понимаем разные вещи. Для меня ТЗ - это просто документ, описывающий концепт продукта, его детали. Это нужно. Смотришь на это спустя какое-то время и понимаешь - надо по-другому, это не сработает. Бывает, меняешь в процессе.

Продукт типа спарка уж куда как непрост. Три слоя как минимум. Сразу кидаться все это делать в коде? Нет уж, лучше сначала подумать, какие именно сущности, какие между ними связи, промежуточные сущности. Начнете рисовать интерфейс - добавите еще десяток сущностей. Вот вам и ТЗ.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
ТЗ - это юридический документ, а вовсе не технический, как следует из названия.
Ответить
Екатерина К
С чего это вдруг юридический?
Ну как я и думала - о разных вещах говорим.
Для меня ТЗ - это набор правил для разработчиков, да и для всех.
Ответить
Екатерина К
Подкорректировала вопрос. Вот теперь точно не юридический. По крайней мере в контексте данного вопроса.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
Для составления ТЗ есть ГОСТ. Берите и пользуйтесь. Там полностью отвечено на все ваши вопросы: что писать и насколько подробно.

Всё равно остаётся вопрос: зачем? Чтобы структурировать ваши мысли бюрократия не нужна. Уделите внимание архитектуре. Она обычно в картинках на досках делается. Это гораздо более важно, чем ТЗ.

Отличное детальное ТЗ + плохая архитектура = много геморроя в будущем при отладке, при кодировании и при поддержке. Отличная архитектура + нулевое ТЗ = минимум проблем при отладке, кодировании и наращивании функциональности.
Ответить
Екатерина К
По-моему, вы все смешиваете в кучу. Причем еще тут гост, какие могут быть госты вообще для стартапа? Нет никаких стандартов, и быть не может, так как все проекты разные и все требуют разной детализации подхода. Опять же, под ТЗ - я лично - подразумеваю некий документ, который позволяет увидеть картину в целом и покажет всем участникам, что от них требуется. Архитектура может быть описана в ТЗ (частично, или полностью, если писал архитектор). И это уже совсем другой вопрос, так же, как и вопрос об организации базы данных, интерфейса и user experience. Я здесь спрашивала только о ТЗ. Опять же, если я архитектор, я предпочту написать ТЗ для себя - чтобы видеть, что я жду от системы, потому что без такого понимания хорошую архитектуру не сделать. А уж как это ТЗ будет выглядеть - в картинках, на салфетках, в диаграммах - неважно (в том смысле, что важно, но не принципиально).

Отличная архитектура + нулевое ТЗ - так не бывает. Если только речь не идет о чем-то суперпростом.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
Вы пользуетесь вполне себе официальным термином, закреплённым в законодательстве, но подразумеваете под ним нечто своё. Ещё раз повторяю, ТЗ - это юридический документ, фактически часть договора между заказчиком и исполнителем. Можете продолжать удивляться, что вас не понимают.

"некий документ, который позволяет увидеть картину в целом и покажет всем участникам, что от них требуется" - это архитектура. Все части вашей системы, объединённые в систему. При правильно разработанной архитектуре порядок реализации этих частей не имеет значения. Берёте людей и раскидываете между ними все эти части.

Обычно делают в том порядке, который позволяет увидеть результат на экране как можно раньше. Либо сверху вниз, либо снизу вверх.

"чтобы видеть, что я жду от системы, потому что без такого понимания хорошую архитектуру не сделать" - это требования к системе. Хочу это, хочу то. На их основании потом пишут ТЗ, на основании которого разрабатывают архитектуру. Этап ТЗ можно пропустить, если вы не рассматриваете возможность судебного разбирательства.

Возможно, вы, как в случае с термином "ТЗ" не понимаете термин "архитектура", а возможно вам нужна методика управления проектами. Scrum, Agile - самые популярные. Гуглите и нагуглится.
Ответить
Екатерина К
Слушайте, не пудрите мне мозги, пожалуйста :)))

Я прекрасно понимаю, что такое ТЗ, архитектура и требования. Знаю и общий порядок - требования -> ТЗ ->
архитектура.

>>>Можете продолжать удивляться, что вас не понимают.
Кто это меня не понимает?
Я неоднократно создавала ТЗ, причем самые разные, создавала и документировала архитектуру, а также собирала требования. Никаких проблем с заказчиками и другими участниками процессов разработки у меня не было.

Да, ТЗ может являться юридическим документом, но этот аспект меня сейчас совершенно не волнует. Вот, из википедии "Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования."

Именно это я и понимаю под ТЗ.

Архитектура - это способ реализации изделия, протокол связей между компонентами, набор правил, если хотите. Дизайнеру совсем не надо знать архитектуру, но ему надо знать, что конкретно от него требуется, ТЗ в руки (ТЗ в данном случае может совпадать с требованиями). Программисту надо знать и архитектуру, ТЗ, и требования (которые также могут пересекаться с ТЗ).

В данном случае (если речь идет о сайте и дизайнере, например) - он получает ТЗ в виде например скриншотов. Ему надо реализовать разметку и графические элементы и его не интересует архитектура (хотя для лучшего понимания организации и работы системы неплохо с ней ознакомиться). Тот факт, что требования также могут быть реализованы в виде тех же скриншотов или набросков, не играет в данном конкретном случае никакой роли, равно как и тот факт, что ТЗ - юридический документ.
Ответить
Пора за дело!
Проект решающий проблемы начинающих бизнесменов
Юра Римский
Web-разработка - это самая низкокачественная отрасль в плане разработки в силу её дикой популярности и низкого порога вхождения.

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

Чтобы стать дизайнером сайтов нужно освоить фотошоп.

Сложность многих программных продуктов гораздо выше, чем у чайника, есть даже сложнее самолёта или атомной подлодки.

Архитектура - это ПОЛНЫЙ чертёж будущей системы. Вы не можете сделать хороший дизайн UI, если не знаете, как устроена система. Разметка и графические элементы - это не дизайн. Это малярные работы.
Ответить
Екатерина К
Ну и к чему этот комментарий?

>>>Web-разработка - это самая низкокачественная отрасль в плане разработки в силу её дикой популярности и низкого порога вхождения.

Абсолютно несогласна. Все зависит от самого продукта. Веб-сервис может очень сложным, иметь разветвленную логику, как на серверной стороне, так и на стороне клиента. Человек, который безапелляционно утверждает, что веб-разработка - это всегда легко и просто, ничего в ней не смыслит, уж извините.

Даже более того, я разрабатывала как программы для десктопа, так и для веба, и могу сказать, что программы для веба практически всегда сложнее десктопных, хотя бы в силу 2-слойной (как минимум) архитектуры, особенностей взаимодействия пользователя с браузером и ограничений, который сам браузер и интернет-среда накладывают на это взаимодействие.
Ответить
Наталья Носенко
Там, где одна команда будет писать требования в жестко утвержденном шаблоне на нескольких сотнях страниц, - другая может обойтись списком эпиков и юзерстори, которые надо релизовать.
Но вообще, на практике, в небольшом проекте, который не зажат в рамки корпоративной бюрократии, толщина документа часто зависит от того, а есть ли в вашем проекте уже какие-то артефакты (документы), которыми при необходимости можно дополнить это ТЗ. Например, термины и понятия - важная часть, обеспечивающая точность документа, но ведь где-то уже может лежать страничка в базе знаний, где все эти слова уже перечислены.
Серебряной пули, естественно, нет, и стандартов и шаблонов не один и не два. Но очень полезный и относительно короткий пример - это стандарт IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications (переводы на русский легко гуглятся).

Если какие-то из общепринятых практик вам не подходят - (например, вы непременно хотите описать структуру БД в том же документе, что и функционал для пользователя) - опирайтесь на свой личный опыт и здравый смысл.
Возможно, именно вам подойдет не заморачиваться по поводу названия документа, а просто выписать в столбик основные проблемы и претензии, которые именно у вашей команды были с ТЗ (у постановщика задачи с формулировками, у программистов - с их пониманием), и подумать, в каком формате и какому процессу следовать, чтобы именно эти проблемы закрыть.
>Так может, надо было продумать все как следует на этапе создания ТЗ?
Вообще, наиболее дорогостоящие переделки - именно те, которые возникли на поздних стадиях проекта из-за пробелов требованиях.
Ответить
Екатерина К
Спасибо за развернутый комментарий.
Посмотрю, что за стандарты.
Понятно, что в каждом конкретном случае ТЗ будет разное - это я, собственно, и хотела узнать - что сами люди используют в своих проектах, так как лично я еще не нашла золотую середину.
Ответить
GlobalNetwork.pro
Advertising platform to buying Ads Inventory programmatically via RTB auction.
Кир Солдаткин
В ТЗ пишут всё, что надо сделать. Есть специально обученные люди, которые описывают сущности (юзеры, сообщества, новости и тд) и взаимодействия с ними. А так же реакцию и возможности интерфейса. Мол, нажал сюда, появилось это, сюда - это, здесь кликнул - произошло вот это.

ТЗ - дает возможность распределить задачи на команду: один делает этот блок, второй - этот, третий - вот это. Четвертый - собирает в кучу все.

ТЗ - помогает держать картину всего перед носом, тк.. бывает проект через месяц может измениться, может потребоваться что-то иное. Разработчики и ПМ забудут в конце-концов то, что надо и как должно быть. Память имеет свойство забывать.
Ответить
Екатерина К
Все правильно, да. Вопрос в том, насколько подробным должно быть ТЗ, в какой форме его лучше описать, особенно когда нет особо времени, разработчик - ты сам (ну и возможно, фрилансеры какие-нибудь), и пишешь ТЗ ты тоже сам себе.
Ответить
GlobalNetwork.pro
Advertising platform to buying Ads Inventory programmatically via RTB auction.
Кир Солдаткин
пишите подробно и избегайте двусмысленного толкования. Нажал тут, произошло это или это. Все.

На более глубоком уровне есть архитекторы, они это все проектируют и описывают.

Если какой-то простой сайт, 2 кнопки, 2 стейтмента - писать ничего не надо, делов на 15 минут. А если есть больше 1 кнопки и 1го поля, тогда пишите все, что куда и зачем. Иначе потом будет ад и придется переделывать с нуля. И писать ТЗ снова, учитывая допущенные ошибки
Ответить
Екатерина К
Спасибо за совет, но как это вы себе практически представляете? Вот есть программа (мобильное приложение, допустим, скринов на 15), и что, ее словами просто описывать? Чокнешься писать все это.
Я пока делаю так - создаю прототип, который показывает наглядно, что после какого клика показывается. На бумаге также рисую схемы и скрины условно, с пояснениями. Но почти на 100% уверена, что когда дойдет до кодирования, будет много вопросов.
Если просто описывать словами, это и сложно, и трудно оценить юзабилити.
Ответить
GlobalNetwork.pro
Advertising platform to buying Ads Inventory programmatically via RTB auction.
Кир Солдаткин
Прототипы - хорошая и нужная вещь. Она помогает сократить ТЗ.

Если есть интерактивный прототип, тогда в ТЗ описываем какие данные можно вводить, какие нет, условия работы с ними, форматы отображения (дата, суммы, валюты и пр).
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.