Технические решения
Если такой документ как «Технические решения»? Если есть , то по какому ГОСТу следует его делать?
Заранее спасибо
- Войдите на сайт для отправки комментариев
- 2720 просмотров
Втр, 06/05/2007 — 13:59Не в сетиЗарегистрирован: 12/18/2006Технические решения
Наш заказчик в одном ТЗ сам составил список того, что должно быть в Технических решениях. Эти ТР идут в качестве составного элемента (раздела) к пояснительной записке. Вот что там должно быть (по мнению заказчика):
— структура АС
— описание функций АС
— описание организационного обеспечения
— описание программного обеспечения
— описание организации информ.базы
— описание тех.обеспечения
Хорошо, что заказчик сам это предложил.
WordExpert.ru — профессиональная работа с текстом.
- Войдите на сайт для отправки комментариев
Втр, 05/22/2007 — 10:20Не в сетиЗарегистрирован: 03/03/2005Технические решения
Все-таки пришлось составить документ «ТР». самое интересное, что заказчик — НИИ АС. Судя по названию, этот НИИ, как никто другой, должен работать В РАМКАХ 34-ых ГОСТов, но нет, однако.
Тем не менее, примеры дали посмотреть.
Просмотрев пару десятков, так называемых, Технических (иногда встречается Типовые) решений, а также воспользовавшись чьей-то лекцией по техническим решениям, составила одобренную структуру документа:
1 Введение
Настоящий документ представляет собой описание конструктивных решений, физического принципа действия и функциональной структуры аппаратно-программного комплекса, предназначенного для.
1.1 Краткая характеристика области применения
Комплекс автоматизированного управления . (далее – Комплекс или .
) предназначен к применению на объектах . и обеспечивает автоматизацию процессов .
Комплекс располагается в зоне .
Один комплект аппаратуры обеспечивает получение, хранение и обработку .
Конструкция Комплекса обеспечивает возможность работы.
1.2 Функциональные возможности
.
2 Технические решения
2.1 Перечень основных элементов
.
2.2 Расположение элементов
(Взаимное расположение элементов в пространстве)
2.3 Соединения и связи
(Способы и средства соединения и связи элементов между собой)
2.4 Взаимодействие элементов
(Последовательность взаимодействия элементов во времени)
2.5 Конструктивное исполнение
(Особенности конструктивного исполнения элементов — геометрическая форма, материал и т.д.)
2.6 Соотношения параметров
(Принципиально важные соотношения параметров для технического объекта в целом или отдельных элементов)
2.7 Перечень дополнительных элементов
.
3 Заключение
(Здесь пишем, чем отличается ваше техническое решение от аналогов и хвастаемся, насколько оно лучше )
Суть документа — в определение ОСНОВНЫХ компонентов, узлов и т.д., их взамодействия и построения. Не сильно детализировать, описывать БЕЗРАЗМЕРНО. Почти.
Размеры применять там, где это жизненно необходимо.
Кроме того, если есть на одно изделие несколько тех. решений (например, базовая и основная комплектация), можно описать их здесь же, применив весь второй пункт к каждому решению по отдельности.
Можно этот же пункт применить к техническому и программному обеспечению по отдельности.
Но — еще раз! Это не регламент, это просто опыт отдельно взятого технического писателя на отдельно взятом предприятии.
к содержанию ↑Техническое задание и техническое решение + шаблон
Часто возникает проблема между Заказчиками и Разработчиками в понимании друга друга и задачи.
- Как задать вопрос или описать задачу? Методы WWH и 5W1H в WordPress
- ТЗ и ГОСТ
- ТЗ и Бритва Оккама
- Техническое решение или ТР
- Почему ТР важно?
- Когда можно без ТР?
- Шаблон
- Еще проще – идем через спецификацию
- Итого
Чтобы решить эту проблему обычно Разработчики говорят Заказчику – напиши ТЗ (техническое задание). Чтобы понять что нужно.
Чаще всего это приводит лишь к усугублению проблемы Потому что обычно вместо ТЗ пишется некий документ содержащий сочинение на тему желаний. Который затем достаточно сложно реализовать.
Почему так происходит? Смею предположить причина в том что стороны не понимают что такое ТЗ, в чем его смысл, как оно выглядит и что должно быть после него
Как задать вопрос или описать задачу? Методы WWH и 5W1H в WordPress
Одна из ключевых проблем в разработке – это умение задавать вопросы и описывать задачи. Правильно заданный вопрос – это половина успеха. Причем тут WWH и WordPress? Существует сотни методик формулировки вопросов и описания…
- ТЗ и ГОСТ
- ТЗ и Бритва Оккама
- Техническое решение или ТР
- Почему ТР важно?
- Когда можно без ТР?
- Шаблон
- Еще проще – идем через спецификацию
- Итого
ТЗ и ГОСТ
Чаще всего люди идут гуглить что такое ТЗ, налетают на ГОСТ и пытаются делать по нему Вот только они не учитывают что ТЗ по ГОСТ было придуман для проектов на 1000 человек, и только одна подготовка такого ТЗ если делать ее правильно может стоить 1-2-10 млн. руб. Не считая работ по его реализации.
А пытаются это применять для проектов где работает 1-2-3 человека Делается это все без понимания особенностей такого документа и получается как раз то самое собрание сочинений. Бессмысленное и беспощадное.
ТЗ и Бритва Оккама
Бритва Оккама в данном случае говорит о том что наиболее простое решение – наиболее верное. Если нет веских причин для усложнения.
Какое самую простую форму ТЗ можно придумать? Ответ – простой список задач (требования, пожеланий). Чаще всего именно эта форма наиболее адекватна.
Иногда она может расширяться некоторыми полезными артефактами (разделами):
- Цели – описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
- Снимки, фото, звуки, примеры – бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.
Да, если проект реально большой, у вас есть 10-20 человек заинтересованных в результате, ТЗ согласовывается с ними пол года, а потом есть 100-200 человек, которые будут реализовать этот проект – тогда можно взять ГОСТ или сделать какой-то большой документ. Иначе – у вас не хватит ресурсов сделать качественную постановку задачи, а потом те кто будут делать – не осилят изучение. И один лишь контроль приемки работ по такому ТЗ превратится в ад.
к содержанию ↑Техническое решение или ТР
А вот та самая часть, которую многие совсем не понимают. Кроме технического задания (в котором может быть просто 3-4 пункта пожеланий на салфетке из кафе), может быть еще техническое решение. Оно чаще всего гораздо важнее чем ТЗ и сильнее влияет на конечный результат.
Техническое решение – пишет как раз Разработчик, где описывает то как он видит решение, что предлагает.
Зачем это нужно? Чтобы исключить разное понимание условий и снизить риски расхождения ожиданий.
Пример для понимания. Заказчик дает ТЗ “Я хочу есть”, а Исполнитель предлагает ТР “На вот яблоко”. Далее может быть 3 сценария: Заказчик соглашается, корректирует/просит предложить что-то еще или отказывается от дальнейшего общения
Чаще всего Заказчик либо принимает решение, либо просит что-то поправить и затем принимает решение.
к содержанию ↑Почему ТР важно?
ТР важно по ряду причин:
- Только Разработчик реально знает как решать задачу (по этой причине Заказчик обычно к нему и обращается), а значит только он может описать детали того как можно получить ожидаемый результат
- У любой задачи может быть 3-4 варианта решения (а часто больше), и тут Заказчик должен убедиться что Разработчик может предложить нечто адекватное
- Задача одна, но несколько вариантов решений часто означает разные цены. причем вилка цен может быть условно от 100 000 руб до 10 000 000 руб. ТР позволяет составить список условий и сузить разброс цен – уложиться в нужный бюджет и срок.
По ходу составления списка решений, предложений и условий – Разработчику надо будет задавать вопросы, обсуждать детали, он просто начнет понимать задачу
Именно составление ТР – позволяет Разработчику понять Заказчика. А Заказчику убедиться что Разработчик понял задание. Именно отсутствие этой части в проекте – зачастую приводит к недопониманию и конфликту.
Когда можно без ТР?
Есть некоторые ситуации когда ТР не нужно. С ходу могу назвать 2 условия:
- Если между Заказчиком и Разработчиком есть полное взаимопонимание и доверие, большой успешный опыт совместной работы. Когда Заказчик целиком доверяет Разработчику и полагается на его знания.
- Если мы работаем по Agile и у нас мелкие простые задачи
Исключение из п.2 – даже в Agile, если есть большая задача (Epic-project), у которой как правило 3-4 стейкхолдера, ее будут делать 2-3 разработчика на 5-6 месяцев, то не помешает сформулировать ТЗ и потом прописать/согласовать ТР. Чтобы убедиться что Стейкхолдеры (Заказчики) и Разработчики (Исполнители) – поняли друг друга.
к содержанию ↑Шаблон
Еще проще – идем через спецификацию
В целом все это можно упростить до 1го простого документа – спецификация.
Но писать этот документ нужно через метод WWH.
- создаем документ и называем его – Спецификация
- далее 3 ключевых раздела: Что нужно? Почему это нужно и чтобы что? Как это планируем делать?
- После того как сделали документ и описали 3 ключевых вопроса – можно докинуть еще другие разделы по вкусу и по ситуации.
В качестве доп. разделов могут быть дизайн макеты, какие то детали реализации и прочая аналитика.
Важно тут учитывать что докидывать информацию имеет смысл если есть причины. Усложнение без причины – признак дурачины. Избыточная информация также вредна как и ее недостаток.
Следующая