Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Спасибо. Уже в избранном.
Такой подход просто необходим для больших проектов. Т.к. если что-то не обговорить сначала, потом это может вызвать цепную реакцию ошибок и недочетов.
Но я считаю, что для небольших проектов главное в ТЗ это структура сайта (это могут схемы и просто названия разделов), кратнок описание функциональности каждого раздела и сроки.
Такой подход просто необходим для больших проектов. Т.к. если что-то не обговорить сначала, потом это может вызвать цепную реакцию ошибок и недочетов.
Но я считаю, что для небольших проектов главное в ТЗ это структура сайта (это могут схемы и просто названия разделов), кратнок описание функциональности каждого раздела и сроки.
Согласен. Полноценное ТЗ - это много времени и денег. Не всегда и то и другое есть в избытке.
Но, с другой стороны, хорошее ТЗ и проработанные требования снижают риски для обеих сторон. Но снижение рисков опять же стоит денег.
В общем, сплошные компромисы )
Но, с другой стороны, хорошее ТЗ и проработанные требования снижают риски для обеих сторон. Но снижение рисков опять же стоит денег.
В общем, сплошные компромисы )
В таком случае надо держать в прайсах строчку "Предпроектное исследование". По умному надо много вещей делать. Это большое подспорье и больша работа.
Строчка "предпроектное исследование" обычно пишется в столбце "Расходы" исполнителя.
Столь подробное исследование на предпроектном этапе, конечно, накладно, но многое изучать, рассчитывать и описывать все равно приходится на стадии переговоров, результат которых не всегда известен.
Столь подробное исследование на предпроектном этапе, конечно, накладно, но многое изучать, рассчитывать и описывать все равно приходится на стадии переговоров, результат которых не всегда известен.
Ммм... А как при этом выглядит весь проект в целом? С точки зрения трудоемкости написания ТЗ и последующей реализации?
Приходилось участвовать в проектах, где постановка задачи занимала в 2-3 раза больше ресурсов, чем реализация. И, соответственно, постоянно объясняться с клиентом, который видел только реализацию (т.е. 1/4 всей работы) - в том числе, объясняться и по финансовым вопросам...
Так вот, какие есть возможности составить более-менее полное ТЗ (и тем самым определиться с трудоемкостью проектных работ), при этом не вывалившись за какие-то разумные рамки (ну, скажем, в идеале 10-20% от реализации)?
Приходилось участвовать в проектах, где постановка задачи занимала в 2-3 раза больше ресурсов, чем реализация. И, соответственно, постоянно объясняться с клиентом, который видел только реализацию (т.е. 1/4 всей работы) - в том числе, объясняться и по финансовым вопросам...
Так вот, какие есть возможности составить более-менее полное ТЗ (и тем самым определиться с трудоемкостью проектных работ), при этом не вывалившись за какие-то разумные рамки (ну, скажем, в идеале 10-20% от реализации)?
На мой взгляд, затраты на составление ТЗ (с подробной проработкой функционала, определением средств реализации и бюджетированием) редко занимают 10-20% от общих затрат на разработку, обычно больше.
Всю работу менеджера проекта и аналитиков оцениваю в 40-60% затрат, а если вебсайт нестандартный, то и 80% сил/времени может уйти. Если после этого программисту работать будет легко и результат предсказуемым окажется, то затраты оправданы.
Клиенту обычно это преподносится как разработка концепции, аналитика, разработка архитектуры. Что из этого делать до заключения договора, а что после - каждый раз индивидуально надо смотреть. Можно много времени потратить на предпроектную подготовку, а потом клиент передумает. Это риски.
Под впечатлением этой статьи я свой опыт минимизации затрат на ТЗ описал, но он годится только для хороших, разумных клиентов. http://audioweb.ru/webdesign/mindmap-for…
Всю работу менеджера проекта и аналитиков оцениваю в 40-60% затрат, а если вебсайт нестандартный, то и 80% сил/времени может уйти. Если после этого программисту работать будет легко и результат предсказуемым окажется, то затраты оправданы.
Клиенту обычно это преподносится как разработка концепции, аналитика, разработка архитектуры. Что из этого делать до заключения договора, а что после - каждый раз индивидуально надо смотреть. Можно много времени потратить на предпроектную подготовку, а потом клиент передумает. Это риски.
Под впечатлением этой статьи я свой опыт минимизации затрат на ТЗ описал, но он годится только для хороших, разумных клиентов. http://audioweb.ru/webdesign/mindmap-for…
Другими словами, можно-таки документировать самые важные вопросы (чтобы хоть приблизительно увидеть размер проекта), и затем составлять смету с каким-то запасом на все остальное? В принципе, я и сам к этому склоняюсь понемногу...
Пардон, конечно, но 80% затрат на проектирование сайта... это какой-то анриал. Если опустить из ряда вон выходящие проекты, то вообще тратить на ТЗ больше 20% бюджета разработки сайта неоправдано.
Невозможно всего всегда предусмотреть. В проект всегда закладываются риски, чтобы успеть все сделать, даже если что-то оценили не верно изначально.
Вот у нас есть бюджет 10Х. На ТЗ потратили 8Х. Ну пусть даже 6Х. Где гарантия того, что на реализацию после получения ТЗ хватит 4Х?
А если пока писали это ТЗ на 6Х, скажем 6 месяцев, появился проект, который дублирует ваш, то что делать? Переписывать ТЗ и просить у заказчика еще минимум 2Х, чтобы что-то переделать? Когда не написано еще ни строчки кода. Заказчик будет счастлив. Мы описали несуществующую и ненужную систему.
А какой из этого выход?
Невозможно всего всегда предусмотреть. В проект всегда закладываются риски, чтобы успеть все сделать, даже если что-то оценили не верно изначально.
Вот у нас есть бюджет 10Х. На ТЗ потратили 8Х. Ну пусть даже 6Х. Где гарантия того, что на реализацию после получения ТЗ хватит 4Х?
А если пока писали это ТЗ на 6Х, скажем 6 месяцев, появился проект, который дублирует ваш, то что делать? Переписывать ТЗ и просить у заказчика еще минимум 2Х, чтобы что-то переделать? Когда не написано еще ни строчки кода. Заказчик будет счастлив. Мы описали несуществующую и ненужную систему.
А какой из этого выход?
Да, умножить оценку на 2.
Это "предпроектное исследование" и входит в цену ТЗ.
А что такое полноценное ТЗ? Оно везде разное.
ТЗ не должно описывать все. Оно должно описывать все, чтобы не сделать больше. :)
ТЗ не должно описывать все. Оно должно описывать все, чтобы не сделать больше. :)
Вообще ТЗ - такой расплывчатый документ и надо иметь общее понимание его предназначения.
Я ТЗ называю приложение к договору, в котором описываются границы проекта, чтобы исполнитель не сделал меньше, чем получил денег, а заказчик не требовал больше, чем заплатил. Т.е. это документ, который можно достаточно быстро разработать, без больших временных затрат со своей стороны и без финансовых затрат со стороны клиента.
Я в ТЗ включаю:
1) Общие сведения
2) Основание для разработки (ссылка на договор)
3) Назначение разработки (цели и задачи)
4) Требования:
- к функциональным характеристикам (для сайта - общее описание структуры и интерактивных элементов);
- к надежности;
- условия эксплуатации;
- к информационной и программной совместимости;
- к поставке;
- к документации.
5) Стадии и этапы разработки (этапы и содержание работ)
6) Порядок контроля и приемки
Структура сайта и шаблоны страниц с той степенью проработки, что у вас в статье, это уже скорее часть эскизных или технического проекта (по госту), или Functional Requirements, а может и Software Requirements (по RUP-у).
У вас получается, что ТЗ - это такой супер-документ про "все сразу". Не понятно, когда его разрабатывать: до подписания договора и подписывать вместе с договором, или уже после подписания договора, но тогда что приложить к договору, чтобы ограничить обе стороны?
Я ТЗ называю приложение к договору, в котором описываются границы проекта, чтобы исполнитель не сделал меньше, чем получил денег, а заказчик не требовал больше, чем заплатил. Т.е. это документ, который можно достаточно быстро разработать, без больших временных затрат со своей стороны и без финансовых затрат со стороны клиента.
Я в ТЗ включаю:
1) Общие сведения
2) Основание для разработки (ссылка на договор)
3) Назначение разработки (цели и задачи)
4) Требования:
- к функциональным характеристикам (для сайта - общее описание структуры и интерактивных элементов);
- к надежности;
- условия эксплуатации;
- к информационной и программной совместимости;
- к поставке;
- к документации.
5) Стадии и этапы разработки (этапы и содержание работ)
6) Порядок контроля и приемки
Структура сайта и шаблоны страниц с той степенью проработки, что у вас в статье, это уже скорее часть эскизных или технического проекта (по госту), или Functional Requirements, а может и Software Requirements (по RUP-у).
У вас получается, что ТЗ - это такой супер-документ про "все сразу". Не понятно, когда его разрабатывать: до подписания договора и подписывать вместе с договором, или уже после подписания договора, но тогда что приложить к договору, чтобы ограничить обе стороны?
Читайте выше: Мы будем следовать самому сложному пути.
В некотором роде может быть и есть пересечение с эскизным проектом, который может вообще не составляться, согласно тому же ГОСТу. Но технического точно нет. Там надо описывать алгоритмы решений.
Просто когда я работал с большими государственными структурами, то подобные документы были просто необходимы!
В некотором роде может быть и есть пересечение с эскизным проектом, который может вообще не составляться, согласно тому же ГОСТу. Но технического точно нет. Там надо описывать алгоритмы решений.
Просто когда я работал с большими государственными структурами, то подобные документы были просто необходимы!
Да с государственными структурами главное одно - побольше бумажек и с нужными людьми сходить в баню. :)
Думаю в составе и содержании проектной документации многое зависит от механизма продажи и клиента.
Думаю в составе и содержании проектной документации многое зависит от механизма продажи и клиента.
Чем больше потенциальных проблем от клинета, тем более внушительным и разноплановым должно быть ТЗ. Это своеобразная защита от клиента. Как в законе: шаг влево, шаг вправо "растрел".
Заключить договор и срубить бабок за халтуру - одно, построить систему - другое.
Система заключения договоров с госструктурами не повод делать плохие ИТ системы для государства.
Если, конечно, не работаешь на другое государство:)
Система заключения договоров с госструктурами не повод делать плохие ИТ системы для государства.
Если, конечно, не работаешь на другое государство:)
Всегда стараюсь делать сайты со свободной структурой, чтобы не зажимать владельца сайта заранее заданными разделами. Нужен новый раздел? Создай его и работай дальше.
Порадовал в статье пункт 3 - Опись контента. Табличное описание содержания каждой страницы сайта.
Ага, бегу-бегу. Сейчас переделываю сайты - ulgov.ru 6000 страниц, gz.ulgov.ru 4500 страниц, уже предчувствую опись контента.
Порадовал в статье пункт 3 - Опись контента. Табличное описание содержания каждой страницы сайта.
Ага, бегу-бегу. Сейчас переделываю сайты - ulgov.ru 6000 страниц, gz.ulgov.ru 4500 страниц, уже предчувствую опись контента.
думаю если категоризация есть - то можно описать только её.
статья же не о том как надо делать постоянно, а лишь пища для размышления, шаблон составления ТЗ и за шаг влево / вправо вас не расстреляют ;)
статья же не о том как надо делать постоянно, а лишь пища для размышления, шаблон составления ТЗ и за шаг влево / вправо вас не расстреляют ;)
Не опись контента это не про то.
Опись контента, это то, что вы будете создавать или набивать сами. Тут отношение должно быть как во фруктовой лавке: арбузы пордаются штуками, а изюм килограммами.
Описывать 6000 страниц подробно может быть страшно, но это же опять смотря какая информация м какой процесс. В процессе создания компьютерной игры люди порой создают 3000 анимаций. И ничего все описывают. ;)
Опись контента, это то, что вы будете создавать или набивать сами. Тут отношение должно быть как во фруктовой лавке: арбузы пордаются штуками, а изюм килограммами.
Описывать 6000 страниц подробно может быть страшно, но это же опять смотря какая информация м какой процесс. В процессе создания компьютерной игры люди порой создают 3000 анимаций. И ничего все описывают. ;)
к сожалению даже на небольших сайтах ТЗ необходимо.
у меня были случаи когда по пунктам сдаю проект, а мне говорят - пользователю неудобно делать так...
сделай. что бы было удобно пользователю. С одной стороны понятно что заказчику не нравится, но в основном маленькие проекты это фриланс, где оплата фиксированная и такой проект может затянутся на гораздо большее время работы за бесплатно :(
у меня были случаи когда по пунктам сдаю проект, а мне говорят - пользователю неудобно делать так...
сделай. что бы было удобно пользователю. С одной стороны понятно что заказчику не нравится, но в основном маленькие проекты это фриланс, где оплата фиксированная и такой проект может затянутся на гораздо большее время работы за бесплатно :(
пасиб, в мемориз!
Спасибо, очень полезная и ценная информация.
P.S. Вот только в форматировании... я бы поубирал лишние пустые строки. Но это так... пожелание, не более.
P.S. Вот только в форматировании... я бы поубирал лишние пустые строки. Но это так... пожелание, не более.
отлично, в избранное.
По моему опыту, ТЗ проходит некоторые эволюционные этапы:
- Этап переговоров и принятие решения заказчиком. Условия и критерии, принятые или озвученные заказчиком ни в коем случае не должны быть потеряны или искажены. Это по сути основа ТЗ. В терминах статьи это "Цели и задачи сайта", "Описание пользователей сайта, их цели и задачи", частично остальные пункты.
- Драфт. Первоначальный вариант ТЗ, который интенсивно обсуждается и исправляется.
- Рабочий вариант. Фактически старт боевых действий.
На первых двух этапах ТЗ у меня хранится преимущественно в текстовом виде и под управлением системы контроля за версиями. На третьем компилируется и становится красивым =)
- Этап переговоров и принятие решения заказчиком. Условия и критерии, принятые или озвученные заказчиком ни в коем случае не должны быть потеряны или искажены. Это по сути основа ТЗ. В терминах статьи это "Цели и задачи сайта", "Описание пользователей сайта, их цели и задачи", частично остальные пункты.
- Драфт. Первоначальный вариант ТЗ, который интенсивно обсуждается и исправляется.
- Рабочий вариант. Фактически старт боевых действий.
На первых двух этапах ТЗ у меня хранится преимущественно в текстовом виде и под управлением системы контроля за версиями. На третьем компилируется и становится красивым =)
в ссылочку на артикс добавьте http://
Доступно написано. Для пущей полезности можно статью дополнить информацией о том, почему ТЗ пишет исполнитель, как трансформировать входящие клиентские требования в ТЗ (и почему клиент не должен писать ТЗ) и про классическую иерархию документов ТТ->ТЗ->ТП.
Да интересная мысль.
Было дело я трансформировал в ТЗ штук 20 анкет от начальников отделов компании-клиента. Каждая анкета страниц по 10.
Было дело я трансформировал в ТЗ штук 20 анкет от начальников отделов компании-клиента. Каждая анкета страниц по 10.
Очень качественная статья. Порадовало то, что во многом я угадываю и двигаюсь в нужном направлении. Конечно есть спорные моменты, из них можно выделить два:
- Отрисовка типовых шаблонов. Считаю, что этим должен заниматься юзабилити-дизайнер. Со временем и ПМ может стать таким специалистом, было бы это время.
- Раздел «Требования». Если честно в большинстве подразделов я не знаю что писать, не Ваш уровень, наверное.
Отрисовка типовых шаблонов можно делать отдельным этапом работы. Я это делал в ТЗ. Т.к. сам занимался юзабилити и проработкой интерфейсов.
Требования надо научиться писать. Фактически получалось так, что с каждым новым проектом мы дописывали что-то в ТЗ. Возникала проблема, мы видели, что это не описано в ТЗ. И вносили исправления.
Требования надо научиться писать. Фактически получалось так, что с каждым новым проектом мы дописывали что-то в ТЗ. Возникала проблема, мы видели, что это не описано в ТЗ. И вносили исправления.
Отличный текст. Видимо автор перед написанием материала составил хорошее ТЗ на сочинение текста )))
Кстати, вы недалеки от истины:
http://yuri.shilyaev.com/archives/2005/0…
Там правда картинка была. Она пропала безвременно после падения сайта. :(
http://yuri.shilyaev.com/archives/2005/0…
Там правда картинка была. Она пропала безвременно после падения сайта. :(
"..Итак хорошее ТЗ на стай должно содержать в себе:..."
Рекомендую в состав ТЗ добавить check-list в котором описать последовательный сценарий работы с системой.
Пример:
1. Зайти на главную страницу
2. Перейти на страницу "Контакты"
3. Открыть схему проезда в новом окне.
Позже, по этому чек-листу сдавать работу заказчику. Он видел сценарий до, он воспроизвел его после разработки.
Рекомендую в состав ТЗ добавить check-list в котором описать последовательный сценарий работы с системой.
Пример:
1. Зайти на главную страницу
2. Перейти на страницу "Контакты"
3. Открыть схему проезда в новом окне.
Позже, по этому чек-листу сдавать работу заказчику. Он видел сценарий до, он воспроизвел его после разработки.
Спасибо. Исправил.
Кстати, о сценариях подобных мы тоже когда-то задумывались, но вот только я думаю, что для этого можно какой-то документ составить отдельный. Это же по сути тест-кесы. Поэтому в виде тест-кейсов и можно оформить.
Кстати, о сценариях подобных мы тоже когда-то задумывались, но вот только я думаю, что для этого можно какой-то документ составить отдельный. Это же по сути тест-кесы. Поэтому в виде тест-кейсов и можно оформить.
Очень полезное дополнение. Это называется use-case и обычно прорабатывается в самом начале проекта наряду с целями проекта. Описывает куда приходят пользователи, зачем, почему, что делают, куда переходят и т.д. После этих кейсов уже можно составлять структуру и писать тз дальше.
Очень хорошая и интересная статья. Большое Спасибо.
Огромное респектище! Всем заказчикам в руки.
Великолепный текст! Спасибо!
спасибо, полезная статья.
В "избранное"!
В "избранное"!
Спасибо автору! Очень полезная и хорошо поданная информация )
статья нормальная. описаны основные пункты ТЗ для клиентов/ПМ.
но для разработчиков такое ТЗ будет не очень информативным ;)
но для разработчиков такое ТЗ будет не очень информативным ;)
ТЗ есть часть договора между клиентом и компанией-разработчиком.
Для разработчиков должна ставить задача. Это для клиента распиывается: на сайте должен быть модуль новостей, куда добавляются... А для разработчика: "Вася, исталлируй модуль новостей на сайт, там надо картинки загружать к каждой новости, макеты у Наташи."
Для разработчиков должна ставить задача. Это для клиента распиывается: на сайте должен быть модуль новостей, куда добавляются... А для разработчика: "Вася, исталлируй модуль новостей на сайт, там надо картинки загружать к каждой новости, макеты у Наташи."
Отличная информация!
Срочно даю почитать всем друзьям, знакомым заказчикам сайтов и знакомымм девелоперам :)
Срочно даю почитать всем друзьям, знакомым заказчикам сайтов и знакомымм девелоперам :)
Почему-то при словах "Пишите ТЗ" люди энергично кивают головами, горячо прощаются и уходят, чтобы потеряться.
Спасибо. в мемориз!
Спасибо! Отличный текст!
А кто пишет/должен писать ТЗ?
Исправтье, если не прав.
Здесь вы рассматриваете ТЗ, как единственный документ в проекте, связывающий три звена: заказчик, менеджер проекта, разработчики. Возможно, для малых проектов этого достотачно, но для больших: я убежден, что Техническое Задание — документ исключительно для разработчиков. Зачем там "аудитория проекта"? Вы же не станете давать тех. задание каменщику, делающему карниз, с описанием всех пород голубей, которые на него вследствии слетятся. Видимо, имеет смысл разделять проектную документацию на отдельные элементы. Как-то: бриф,концепция проекта, ТЭО, ТЗ etc...Зачем все мешать в одном ТЗ?
Здесь вы рассматриваете ТЗ, как единственный документ в проекте, связывающий три звена: заказчик, менеджер проекта, разработчики. Возможно, для малых проектов этого достотачно, но для больших: я убежден, что Техническое Задание — документ исключительно для разработчиков. Зачем там "аудитория проекта"? Вы же не станете давать тех. задание каменщику, делающему карниз, с описанием всех пород голубей, которые на него вследствии слетятся. Видимо, имеет смысл разделять проектную документацию на отдельные элементы. Как-то: бриф,концепция проекта, ТЭО, ТЗ etc...Зачем все мешать в одном ТЗ?
Что это меняет в сущности? Надо один документ утвердить с заказчиком или 3? У одного заказчика на документе по проекту надо было поставить 12 виз. Если бы надо было провести 3 документа, то пришлось бы на всех собирать по 12 виз.
Это вообще вопрос не документа скорее, а процесса. Когда я писла ТЗ, то нам было удобно так работать. Иногда выделяли отдельно бриф и концепцию. Нельзя написать решения на все возможные задачи.
Это вообще вопрос не документа скорее, а процесса. Когда я писла ТЗ, то нам было удобно так работать. Иногда выделяли отдельно бриф и концепцию. Нельзя написать решения на все возможные задачи.
Спасибо за статью, очень помогла при написании ТЗ.
Спасибо!
Статья оказалось очень полезной!
Статья оказалось очень полезной!
где бы такое найти на английском языке?
как ТЗ вообще звучит по-английски?
как ТЗ вообще звучит по-английски?
Я, например, всегда отрывал руки менеджерам, которые планируют размещение информационных блоков на страницах сайта, т.к. не их это работа, вообщем-то. РМ не Бог, уж извините, и не знает, ни какой дизайн будет, ни какая информация является главной, ни какая - второстепенной. Про юзабилити я ничего не говорю, это вообще отдельная тема. Вывод: если вы пишете ТЗ для утверждения, то максимально оградите себя от представления визуальной части в адрес Заказчика. Схема сайта? - не вопрос, алгоритм? - согласен, дизайн?! - боже упаси.
Требования к дизайну сайта должны включать в себя:
Описание схемы верстки шаблонов типовых и заглавных страниц в текстовом.
Описание графических материалов, обязательных к использованию на странице шаблона. (Фирменный стиль)
Цветовое решение сайта. Основной цвет в RGB
Требование к размеру страницы в Kb
А вообще, я ограничился бы простой выкладкой всей серии 34 гостов и 50-го РД.
Как-то вот так...
Требования к дизайну сайта должны включать в себя:
Описание схемы верстки шаблонов типовых и заглавных страниц в текстовом.
Описание графических материалов, обязательных к использованию на странице шаблона. (Фирменный стиль)
Цветовое решение сайта. Основной цвет в RGB
Требование к размеру страницы в Kb
А вообще, я ограничился бы простой выкладкой всей серии 34 гостов и 50-го РД.
Как-то вот так...
1. Я описывал всегда страницы с позиции информационного архитектора, которым и являлся в проектах.
2. Есть вариант не описывать схему расположения четко. Иногда просто прорисовываются отдельные элементы, но не разрисовывается вся схема. Особо актуально для проектов креативного характера.
3. ГОСТы это конечно прикольно, но ладно я в них разобрался, но далеко не все заказчики и некоторые разработчики будут читать ГОСТы 80х годов на автоматизированные системы и пересматривать их на сайтостроение... Я вообще творчески переработал ГОСТы под использование для сайтов. В чистую использовать их это жесткого.
2. Есть вариант не описывать схему расположения четко. Иногда просто прорисовываются отдельные элементы, но не разрисовывается вся схема. Особо актуально для проектов креативного характера.
3. ГОСТы это конечно прикольно, но ладно я в них разобрался, но далеко не все заказчики и некоторые разработчики будут читать ГОСТы 80х годов на автоматизированные системы и пересматривать их на сайтостроение... Я вообще творчески переработал ГОСТы под использование для сайтов. В чистую использовать их это жесткого.
Однажды Заказчик позволил себе орать на моего менеджера на одном из совещаний. Смысл крика лежал в оформлении документа, который менеджер передал для ознакомления Заказчику ранее. После того, как я открыл ГОСТ Заказчику, показал ему правильно оформленный документ и спросил его, есть ли у него возражения относительно принятых государством, хоть и не законодательно, а лишь в форме рекомендации, правил? Заказчик почему-то заткнулся и ответил, что - нет, не имеет. Поэтому самостоятельное творчество - хорошо, но для междусобойчика, а с людьми, которые платят деньги надо действовать только в рамках государственных бумаг. В любом суде будет проще сказать: сделано по ГОСТу номер такой-то.
Вы уж меня простите, я, возможно, прав только для себя, и никоим образом не претендую на объективность. Каждый живет и работает в рамках тех принципов, которые придумал для себя он сам. По мне так ничего умнее и лучше, чем гос.бумага - нет, и никогда не будет.
Вы уж меня простите, я, возможно, прав только для себя, и никоим образом не претендую на объективность. Каждый живет и работает в рамках тех принципов, которые придумал для себя он сам. По мне так ничего умнее и лучше, чем гос.бумага - нет, и никогда не будет.
Ничего против гос.бумаг не имею.
В общем и целом все это понятно и правильно. Я всегда придерживался в этой связи рекомендациями, но не доводил их до четкому следованию букве. Т.е. по ГОСТу надо документы оформлять рамкой, как на конструкторской документации. Выглядит это может быть и солидно... но мне кажется что это уже перебор. Слишком уж по-советски, не по-корпоративному сделано... Вот что касается сквозной нумераций картинок и таблиц, нумераций абзацев, системности построения разделов, специальных листов с номерами версий, авторами, процессом утверждения документа и прочего что обычно рекомундует ГОСТ — это использовалось. Ну и работать с таким документом было понятно.
В общем и целом все это понятно и правильно. Я всегда придерживался в этой связи рекомендациями, но не доводил их до четкому следованию букве. Т.е. по ГОСТу надо документы оформлять рамкой, как на конструкторской документации. Выглядит это может быть и солидно... но мне кажется что это уже перебор. Слишком уж по-советски, не по-корпоративному сделано... Вот что касается сквозной нумераций картинок и таблиц, нумераций абзацев, системности построения разделов, специальных листов с номерами версий, авторами, процессом утверждения документа и прочего что обычно рекомундует ГОСТ — это использовалось. Ну и работать с таким документом было понятно.
Дайте пожалуйста ссылку на готовое ТЗ которое на ваш взгляд является образцовым ну или по крайней мере хорошим) заранее благодарен)
ps: гугл и прочее юзал, но все что мной было найдено мне показалось не исчерпывающим :)
ps: гугл и прочее юзал, но все что мной было найдено мне показалось не исчерпывающим :)
Ссылок у меня к большому сожалению нет. :( Все большие и серьезные документы относятся к какому-то проекту и не подлежат разглашению, поэтому в интернет в свободный доступ их никто не выкладывает.
Исчерпывающего ТЗ вообще наверное не существует. На то оно и исчерпывающее. Всегда остается то, что не учли.
Исчерпывающего ТЗ вообще наверное не существует. На то оно и исчерпывающее. Всегда остается то, что не учли.
где нить встречали выложенные ТЗ социальных сетей?
с интересом бы посмотрел...
с интересом бы посмотрел...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое «хорошее» ТЗ на сайт?