Разработка технических заданий и спецификаций программных продуктов.

[PooH]

dimka, я не имел ввиду условия выполнения... только ТЗ.
Попробую навскидку найти не рассмотренные ситуации.

Например, на вопрос

Как заказчик хочет запустить сей просмотр и как намеревается завершить этот просмотр, намерен ли переключаться на другие задачи во время просмотра.

В ТЗ будет написано:
Как заказчик хочет запустить сей просмотр: Комбинацией клавиш Alt+F3;
Как намеревается завершить этот просмотр: Комбинацией клавиш Alt+F4;
Намерен ли переключаться на другие задачи во время просмотра: Намерен.

Все требуемые данные указаны. Ситуация - заказчик запустил полноэкранную игру и нажал Alt+F3. Вопрос: Как должна отреагировать заказанная программа?


Добавлено через 4 минуты и 38 секунд:
2. Внешний вид надписи (шрифт, цвет, размер, спецэффекты, анимания)
шрифт: Arial, цвет: 0xFF0000 (RGB), размер:10pt, спецэффекты: полупрозрачность, анимания: нет.

3. Предпочитает ли заказчик какую-либо операционную систему, может быть какой-то оконный менеджер.
OS: Windows XP Home Edition (SP2). Менеджер: стандартный.

я так понимаю, данных достаточно, чтобы клиент остался доволен?

[REM]

Alf, REM, а давайте из вас кто-нибудь первый перестанет, а потом и другому тоже ничего другого не останется.

Молодец! Спасибо.

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

Согласен. Каждый остался при своём мнении, как это обычно и бывает. В любом случае, отдельные мысли, прозвучавшие в ходе этой дискуссии показались мне достаточно интересными. Надеюсь, что у вас не осталось неприятного осадка. Честно признаюсь, что появляюсь на этом форуме во многом благодаря тому, что здесь можно найти таких интересных и зрелых собеседников, как вы.

[Dimka]

PooH, ты сам заметил, что резервирование указанных горячих клавиш чем-то чревато (хотя я не знаю, что ты под Alt-F3 понимал - практически не играю в игрушки). Если требование заказчика чем-то ему самому грозит, я его предупрежу.

Полупрозрачность имеет значение, которое ты не указал.

P.S. Ты про экран забыл ответить: fullscreen или как-то ещё, в каком месте должна быть надпись?

[PooH]

 Должна ли надпись занимать весь экран: нет.
его часть (и какую часть): верхний левый угол.

на то она и полупрозрачность... 50%

Я сам не знаю, чем грозит комбинация... просто ответил на вопрос поизвращенней.

Итого: это все необходимые требования (условия, данные) необходимые для кодирования проекта?

Если, да - то скажи, на каком основании (по какому принципу) лично ты определяешь полноту ТЗ.

А я в свою очередь придумаю ситуации не предусмотренные в ТЗ. И будем обсуждать варианты выхода из этих ситуаций, согласен?

[Dimka]

Если, да - то скажи, на каком основании (по какому принципу) лично ты определяешь полноту ТЗ.

Принцип простой - всё прочее не является заботой заказчика. Это принцип инкапсуляции.

[Hooter]

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

Всё-таки хотелось бы услышать мнение автора темы по перечисленным вопросам...

[PooH]

dimka, а как опредедить, что касается заказчика, а что нет?

[Dimka]

dimka, а как опредедить, что касается заказчика, а что нет?

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

P.S. Конкретная форма вопросов зависит от конкретного содержания задачи. И если бы у меня была внятная методика, ответил бы ранее.

P.S.S. На самом деле всякие "интуитивные" постройки зиждутся на большом числе допущений, истинность которых определяется не путём логического обоснования, а принимается интуитивно, и описание которых займёт много места без какой-либо пользы дела в практических ситуациях. Это так называемый "здравый смысл". Единственно, что "здравый смысл" - не священная корова, и нужно понимать условия его применимости - когда на него полагаться можно, а когда нельзя.

Например, я сформулировал вопросы так, что ты, PooH, начал мыслить по шаблону GUI интерфейса для современных ОС. (Что, в принципе, являлось моей целью ) В то же время сам я думал как о GUI, так и о "пользовательском интерфейсе" (если его так можно назвать) старых машин, MDA-адаптеров, о средствах их программирования (были смутно помянуты "примитивные ОС" - представь программирование вывода полупрозрачного текста определённого шрифта и цвета на VGA,.. а CGA ), так и о мобильных устройствах, о будущих возможных ОС с пользовательским интерфейсом, где GUI не ограничивается экраном и мышкой, а может включать звук или что-нибудь ещё. И даже, сменив контекст обсуждения, о телевизионной программе, в которую можно прописать показ "Hello world!" по телевизору - тоже "программирование". Но среди всего этого многообразия возможностей показать заказчику "заветные слова" я выбрал такой вариант, вероятность соответствия которого замыслу заказчика максимальна.

Сами же методики формирования различных решений могут иметь разные основания: от обычной логики и математических приёмов до полуформальных ТРИЗ и неформальных "дезн-медитаций".

[Alf]

Всё-таки хотелось бы услышать мнение автора темы по перечисленным вопросам...

Вопросов много, и все достаточно емкие... Буду отвечать постепенно, по вопросу за раз.

Прежде всего скажу, что мне повезло с заказчиком, поэтому мой пример может оказаться неприемлемым в более суровых условиях. Я разрабатываю программное обеспечение для нужд частной телекоммуникационной компании, владеющей телефонными станциями различных типов в нашем регионе. У руля стоят выпускники физического и механико-математического факультетов университета, то есть люди эрудированные и умеющие работать с формализмами. От сохи или станка нет никого. Поэтому мне не составляет особого труда внедрять в практику отдела программного обеспечения любые технологии, которые я считаю полезными для дела. Возможно, поэтому мне порой не очень понятны проблемы, возникающие в менее благоприятной рабочей среде, - у меня просто нет опыта борьбы с ними.

Итак, к делу.

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

Происходит это примерно в такой последовательности.

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

2. Построение моделей.
На основании материалов, полученных в п.1, Исполнитель строит модели, в которых пытается отразить свое
понимание бизнес-процесса. Прежде всего строится функциональная модель (IDEF0), в которой основная функция процесса претерпевает декомпозицию на несколько более простых, те, в свою очередь, еще на несколько, и так до тех пор, пока каждая из них не станет достаточно простой, чтобы можно было охватить ее в целом. Кроме функций, на диаграмме присутствуют также объекты, принимающие участие в бизнес-процессе в одной из ролей ICOM (в качестве входа, управления, выхода либо механизма).
Для уточнения функциональной модели используются также диаграммы описания процессов (IDEF3) и потоков
данных (DFD). Диаграммы IDEF3 позволяют детализировать функции подобно блок-схемам, а DFD больше
ориентированы на описание циркуляции данных (поскольку нотации IDEF разрабатывались, вообще говоря, не для программистов, а для специалистов по реинжинирингу бизнес-процессов, поэтому носят более универсальный характер).
Важной частью модели является также словарь предметной области, в котором Исполнитель фиксирует для себя значения специфических для данной области терминов. Использование словаря помогает избежать различного толкования одних и тех же слов Исполнителем и Заказчиком.
Пример: небольшой фрагмент словаря одного из реальных проектов.

Зачетная длительность разговора
Определяет продолжительность разговора, подлежащую оплате. Зависит от фактической продолжительности разговора и метода тарификации.

Метод тарификации
Задает совокупность правил, в соответствии с которыми производится расчет с данным провайдером для звонков в данном направлении.
Например: первые 10 сек – бесплатно, далее – поминутное округление в большую сторону.

(курсивом выделены термины, также определенные в данном словаре).

3. Уточнение моделей.
Вооружившись построенными моделями, Исполнитель устраивает вторую встречу с Заказчиком. Но на этот раз он уже играет активную роль: комментирует модели и задает вопросы типа "верно ли, что ...". (Следует отметить, что диаграммы IDEF достаточно наглядны и интуитивно понятны, поэтому Заказчик быстро к ним привыкает и перестает их бояться).
Если Заказчик обнаруживает упущения и неточности, он указывает их, после чего Исполнитель вносит необходимые коррективы и устраивает очередную встречу. После нескольких таких итераций стороны должны прийти к взаимопониманию, после чего Заказчик визирует правильность моделей своей подписью.

4. Составление ТЗ.
На основании результатов моделирования совместными усилиями Заказчика и Исполнителя составляется ТЗ, в котором фиксируется:
- название разработки;
- назначение разработки;
- кто является Заказчиком;
- кто является Исполнителем;
- краткое описание сути разработки;
- особые требования к программе (не вытекающие явно из ее назначения);
- календарные сроки высполнения;
- поэтапный график выполнения с ожидаемыми результатами и отчетностью по каждому этапу (если работа достаточно длительная);
- результаты завершения (исполняемые модули, скрипты, файлы, руководства, ...), подлежащие передаче Заказчику;
- порядок приемо-сдаточных испытаний;
- приложения (диаграммы моделей, эскизы экранных форм, описание и примеры исходных данных, описание входного языка (БНФ), ссылки на внешние документы и т.д.).
Почти каждый пункт ТЗ, как я уже говорил, является предметом торговли между Исполнителем и Заказчиком. Заказчик желает поскорее получить результат в возможно большем объеме, а Исполнитель - увеличить сроки и снизить объем. Поэтому протащить ТЗ в одностороннем порядке практически нереально.

Собственно, с момента подписания сторонами данного документа он вступает в силу, и можно приступать к воплощению замысла в жизнь.

P.S. Писал урывками, второпях, поэтому мог упустить что-то важное или, наоборот, написать глупостей. Кто заметит, просьба сообщать, не стесняясь. Эта тема не для самолюбования.

Приложение. Фрагмент функциональной модели бизнес-процесса (IDEF0).

[Sla]

Задача, прошедшая фильтр, принимается отделом к исполнению. Первым делом приступаем к составлению ТЗ.

Ну, звыняйте! Так кто же все-таки составляет ТЗ?

Да меня тут чуть ногами не запинали

[Alf]

Ну, звыняйте! Так кто же все-таки составляет ТЗ?

Да меня тут чуть ногами не запинали

А каков вариант пинателей?

[Sla]

Т.е. разработчик выступает в лице Заказчика.

 

Это опечатка? Или все же концепция?

Напоминаю

[Alf]

Разумеется, в предложенной мной схеме ТЗ совместно составляется Заказчиком и Исполнителем. Может несколько сбить с толку активность Исполнителя при составлении моделей, но она неизбежна, поскольку Исполнитель должен как можно раньше прояснить детали, чтобы понять, во что он ввязывается.

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

Кроме того, нередки ситуации, когда Заказчик объявляет тендер при подборе Исполнителя для своего ТЗ. Тут вообще ситуация с подменой Заказчика Исполнителем исключена, поскольку неизвестно наперед, кто будет Исполнителем.

Оформлять ТЗ действительно может Исполнитель, вряд ли у Заказчика найдутся подготовленные специалисты для рисования диаграмм IDEF и прочих формальностей. Но между оформлением и составлением - огромная разница. На всех этапах ТЗ - от первоначальной постановки задачи до утверждения документа - главенствует Заказчик. Исключим его из процесса - получим изложение задачи в кривом зеркале понимания ее Заказчиком. Что при этом получается в итоге, говорили и dimka, и я - вместо автоматизированной системы получается автоматизированная картотека, а вместо бумаг, отпечатанных на машинке, по конторе гуляют те же самые бумаги, отпечатанные на крутейшем лазерном принтере. Затраты - многие тысячи баксов, результат близок к нулю (если не считать счастливых лиц разработчиков и поставщиков оборудования, к которым перекочевали эти самые баксы). Блеск исключительно внешний: вроде как свежая крахмальная сорочка, под которой - прежняя давно не мытая шея.

Впрочем, я бы с удовольствием выслушал альтернативный процесс в деталях, подобно тому, как я обрисовал свой вариант: вот разработчик решил выполнить некоторую работу и объявил, что в дальнейшем он выступает в лице Заказчика; что происходит после этого момента? Каковы его действия, какие документы появляются в их результате, на каком этапе настоящий Заказчик вновь вступит в игру?

[Dimka]

вот разработчик решил выполнить некоторую работу и объявил, что в дальнейшем он выступает в лице Заказчика; что происходит после этого момента? Каковы его действия, какие документы появляются в их результате, на каком этапе настоящий Заказчик вновь вступит в игру?

Попробую изобразить промежуточное состояние.

1) Приходит (именно этот случай, а не случай, когда его находят продавцы) заказчик и говорит, что вот "мы хотим программу ..." далее следует в наиболее общих выражениях тематика (учётная система (разной сложности), комплекс автоматизации, ПО под конкретное железо (софтовая часть программно-аппаратного комплекса), какой-нибудь компилятор, рассчётно-моделирующее приложение, веб-портал и т.д.).

2) Исходя из тематики принимается первичное решение: "мы этим не занимаемся", "сейчас все профильные специалисты заняты, обратитесь попозже", "давайте обсудим подробнее". В последнем случае переход на шаг 3.

3) Далее 2 варианта. Первое: заказчик приносит/присылает то, что по его мнению можно назвать ТЗ. Второе: представитель заказчика на словах объясняет, чего ему хочется. Здесь делается грубейшая оценка объёма работ (лучше даже сказать "масштаб"), "вменяемость" заказчика. После этого, если нужно, наводятся справки о заказчике (его возможностях, ответственности и серьёзности намерений) - оценка партнёра. (Понятно, что о Газпроме справки не наводятся, а вот какой-нибудь ЧП Вася Пупкин вызывает интерес.) Если решается, что заказчик - не надёжный партнёр, ему отказывают. Так называемое ТЗ заказчика, если оно имеется, тоже влияет на принятие решения. Например, если отделение некой госструктуры в ТЗ предлагает написать "базу данных из 15 справочников и 20 отчётов за 2 недели и подешевле" (и ничего более) - это не интересно, потому что а) много не заплатят, б) заказчик "невменяемый" - 2 месяца уйдёт на выяснение, чего ему надо, в) вести support такого решения - сплошные убытки, г) заказчик не будет доволен ни стоимостью, ни сроками. Важен масштаб проекта: проект может быть такой, который нереально потянуть (не Microsoft всё же), тогда тоже следует отказ.

4) Далее самое слабое место во всём процессе - составление ТЗ, разработка архитектуры и спецификаций. Если заказчик "вменяемый" - проблем нет (далее, примерно как описал Alf). Если заказчик "невменяемый", но добрался до этого пункта, значит денежный. И вот тут начинает работать концепция "разработчик выступает в лице заказчика". Что это такое.

К заказчику выезжает представитель (или целая бригада, в зависимости от масштаба деятельности). Они сидят у заказчика и пытаются выяснить, чего, собственно, заказчику нужно. Если на самом деле заказчику никакой программы не нужно, процесс выяснения "какая же вам нужна программа?" сродни "division by zero". И чтобы этот процесс в конце концов как-то чем-то завершился, заказчику предлагают некое решение, и говорят, что именно оно ему нужно (это уже работа продавца). Естественно, этот крайний случай особо "невменяемого" заказчика редок, и кое-что полезное для себя заказчик всё же заказывает. Т.е. между двумя крайностями белым "заказчик выступает в лице заказчика" и чёрным "разработчик выступает в лице заказчика" существует сумеречная зона, напрямую зависящая от "вменяемости" заказчика. В этой сумеречной зоне у разработчика есть пространство для манёвра тем большее, чем глубже сумрак: если заказчик или его проект очень интересны, разработчик предельно расширяет своё предложение, в противном случае - предельно сужает. Мерой здесь являются: а) экономическая целесообразность, б) возможности обучения/испытания новых технологий, считаемых перспективными, в) репутация (банально "кидать" заказчика - это уже зависит от совести разработчика и средств сохранения доброго имени). Хотя пункты б) и в) находят своё отражение в пункте а).

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

Затем в процессе приёмки ситуации различны:

1) Если заказчик опытный - приёмка нормальная, с тестами заказчика, по букве и духу спецификаций.

2) Если заказчик неопытный, но имеющий мнение - приёмка концентрируется на соответствии изделия мнению. Здесь уже различно: где убеждают, где разбираются по букве подписанных документов, часто возникают предложения тут же внести какие-то изменения или сделать доработки (по отдельному договору). Если доработки выгодны - заказчика склоняют к ним, если не выгодны - убеждают, что именно то, что есть, ему и нужно.

3) (Практически нереальный в чистом виде.) Если заказчик совершенно "невменяемый", его можно убедить в чём угодно: что изделие - именно то, что он и заказывал.

[Alf]

К заказчику выезжает представитель (или целая бригада, в зависимости от масштаба деятельности). Они сидят у заказчика и пытаются выяснить, чего, собственно, заказчику нужно.

То есть, если я правильно понял идею, картина примерно следующая.

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

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

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

[Dimka]

Поскольку непосредственное общение Заказчика с Исполнителем затруднено

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

Затем он выявляет действительные (а не кажущиеся Заказчику или глубоко не вникнувшему Исполнителю) проблемы, решение которых поддается решению при помощи компьютерной программы и потенциально может быть реализовано силами Исполнителя в разумные сроки и за разумную цену (т.е. порядок цены и срока устраивают как Заказчика, так и Исполнителя).

Нет, особого стремления разделить действительные и мнимые проблемы нет, сконцентрировавшись лишь на действительных. Потому что (см. 1-й пункт) это случай, когда заказчик сам приходит и желает, чтобы ему что-то написали. Что он хочет - то и пишут. А насколько это ему нужно - это совместная проблема. В основном - Заказчика. Но если Исполнитель "ощущает", что Заказчик в результате может остаться недовольным - тогда и проблема Исполнителя. Исполнитель не будет делать того, что не понравится Заказчику. Естественно, Исполнитель смотрит и за соблюдением своих интересов. Разницу между "нравится" и "действительно нужно" обсуждали выше в этой теме.

Схема выглядит вполне разумной. Вот только я бы не ставил знак тождества между Аудитором и Исполнителем. Лично я бы, оказавшись в такой ситуации, постарался прибегнуть к услугам третьей стороны, получив какие-то гарантии непредвзятости

Скорее это вопрос опыта ведения дел с "невменяемыми" заказчиками - так называемой ушлости. Лично я о массовой практике привлечения сторонних консультантов для софтовых проектов не слышал. Следует различать проекты разработки софта и проекты типа автоматизации бизнеса. Последние включают в себя ещё много всяких действий, к разработке софта не относящихся - в этих случаях возможно общение с Заказчиком через Аудитора. Я же в данном случае говорю только о разработке софта.

[Hooter]

Наверное, глупо поддакивать , но никаких возражений к таким подходам нет: имхо, абсолютно нормальный и правильный подход. Единственное, что хотелось бы уточнить - это макеты. Играют ли они какую-то роль в описанных процессах формирования ТЗ? Используются ли вообще в процессе разработки? И уточняется ли ТЗ уже после согласования с Заказчиком? Думаю, что макетирование - достаточно важный пункт. Существенно помогает в утоонении требований и расстановке приоритетов.

ЗЫ. Хочу в тот замечательный мир, где на стороне заказчика адекватные и технически подкованные люди.

ЗЗЫ. Хочу просто расставить все точки над i и пояснить, что я имел в виду под этим:

Т.е. разработчик выступает в лице Заказчика.

Это опечатка? Или все же концепция?

К сожалению, концепция. Я тоже с этим сталкивался.

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

[Dimka]

Надо ли говорить, что на этапе сдачи возникают, мягко говоря, разногласия в оценке качества и функциональности продукта.

Это случай неопытного заказчика, имеющего своё мнение. Если углубиться в структуру Заказчика, то его мнение определяют те самые "технические специалисты", которые в начале старательно избегали участия в составлении ТЗ. Схема поведения технического представителя Заказчика:

1 - составление ТЗ) Я тут занят своими должностными обязанностями, а ко мне приходят какие-то люди с дурацкими вопросами и мешают работать.

2 - внедрение или развёртывание для испытаний) Я тут занят должностными обязанностями, а ко мне приходят люди, копаются в моих компьютерах, что-то там ставят - мешают работать.

3 - переход к эксплуатации) Начальство сказало использовать эту программу - да здесь вообще ничего непонятно, как чего делать, ничего не сделать - доложу руководству, что созданы невыносимые условия для работы, всё плохо.

Естественно, опытный заказчик (да где их взять в нужном количестве) должен:

1) Освободить или снизить загрузку тех своих специалистов, которые привлекаются к проекту со стороны заказчика.

2) Объяснить им цели проекта и поставить перед ними задачи, объяснить их роль в деле, убедить в важности и необходимости дела (ещё б тот "большой босс" сам понимал цели...).

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

В пункте 2) миссия особо деликатна. Был у меня 4 года назад случай, когда заказчик (в лице руководства) заказал разработать конфигурацию "1С:Предприятия" с целью повысить эффективность работы бухгалтерии, в коей пребывало 8 женщин предпенсионного возраста. В результате автоматизации их должно было остаться 4. Когда "представители заказчика" знают, что участием в проекте "роют себе могилу", думаю, не сложно догадаться, что их действия описываются словом "саботаж". Alf, как ты думаешь, как в таких условиях должен себя вести Исполнитель, составляющий ТЗ?

[Alf]

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

Мне тоже такое развитие сюжета представляется наиболее вероятным и логичным. Именно поэтому и усомнился в концепции, переспросил, не опечатка ли...

[Alf]

...
Когда "представители заказчика" знают, что участием в проекте "роют себе могилу", думаю, не сложно догадаться, что их действия описываются словом "саботаж". Alf, как ты думаешь, как в таких условиях должен себя вести Исполнитель, составляющий ТЗ?

Я так думаю, в таких условиях нужно подняться на один уровень выше, где интересы противоположны. В данном случае - наладить контакт с главбухом, который только выиграет от внедрения системы. Если одного уровня мало - подниматься по лестнице до тех пор, пока не наладится нормальный рабочий контакт. Если на самой вершине контакта все еще нет, нужно искать более полезное занятие, толку здесь все равно не будет.

Мне доводилось реально работать в таких условиях. Разрабатывали систему учета продукции (конкретно - подсолнечного масла, которое в штуках не посчитаешь), причем приходилось работать непосредственно с людьми, которое на этом самом масле и грели руки. Можешь представить себе их восторг по поводу нашей системы и дружелюбие по отношению к нам. Нет, конечно, в темных закутках не били... Пришлось переходить на контакт с главным инженером, и все пошло как по маслу (пардон за каламбур). По результатам внедрения самый активный луддит, мешавший нам больше всех, был уволен по статье, большинство разбежались по собственному желанию, ибо кормушка закрылась.

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

[Dimka]

Я так думаю, в таких условиях нужно подняться на один уровень выше, где интересы противоположны. В данном случае - наладить контакт с главбухом, который только выиграет от внедрения системы. Если одного уровня мало - подниматься по лестнице до тех пор, пока не наладится нормальный рабочий контакт.

Мы же обсуждаем ТЗ, его содержание. Пусть гендиректор всеми руками за проект, но он не владеет всеми мелочами бухучёта этого предприятия. Директор может лишь поставить наиболее общие цели проекта, типа: "В результате прохождение документов должно ускориться за счёт замены ручного труда автоматическими вычислениями." Для конкретики нужны именно те люди, которые владеют предметом. Поэтому поднятие по уровням может увеличивать нормальность контакта, но лишь уменьшает содержательность этого контакта.

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

В моём случае много ньюансов. В частности, у бухгалтеров был сильный коллектив "один за всех и все за одного". Это была сельская местность - небольшой посёлок, где все друг друга знают, и утаить грядущие увольнения нельзя. Сельхозпредприятие было "посёлкообразующим" - т.е. уволенным некуда деваться, а новых набрать просто неоткуда. И т.д., и т.п.

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

[PooH]

По-моему, "технари" заказчика и исполнителя, никоим образом не дожны контактировать. Просто с каждой стороны должен быть представитель через которого проходит всё общение. Есть у меня пара примеров именно такой работы.

Хочу напомнить про тему: https://forum.shelek.ru/index.php/topic,8205.0.html (там есть ссылки на документы).

[Alf]

Мы же обсуждаем ТЗ, его содержание. Пусть гендиректор всеми руками за проект, но он не владеет всеми мелочами бухучёта этого предприятия. Директор может лишь поставить наиболее общие цели проекта, типа: "В результате прохождение документов должно ускориться за счёт замены ручного труда автоматическими вычислениями." Для конкретики нужны именно те люди, которые владеют предметом.

В данном случае, действительно, до уровня директора подниматься бессмысленно. Если на уровне главбуха (который обязан владеть предметом) контакта нет, затея обречена - тут уж "бери шинель, пошли домой". Чтобы внедрять бухгалтерскую систему при противодействии главбуха, нужно ангельское терпение, бесконечное время и сторонний источник финансирования, чтобы не помереть с голоду. Тем, кто не собирается жить вечно, лучше поискать другую задачу.

[Alf]

ГОСТ разработки 1978 года проглядеть, конечно, забавно, но не более того.

ТЗ - основной документ, которым разработчик руководствуется при реализации задачи. И мне, как разработчику, совершенно безразличны требования к окружающей температуре, направлению ветра и расположению планет при эксплуатации программ. Также мне глубоко пофиг

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

Кто заказывает программу, пусть сам определится со своей годовой потребностью.

Еще меньше меня интересуют

условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

Где хотите, там и складывайте.

Стандарты хороши, когда они помогают работать, а не нагружают дурной работой. Поэтому стандарты IDEF для меня хороши, а вот ГОСТ 19.201-78, мягко говоря, не очень.

[PooH]

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

[Alf]

А зачем следовать стандарту, в котором самые нужные разработчику сведения приведены в разделе "и др."? Зато для грузчика, кладовщика и гидрометеоролога есть все.

[PooH]

тогда, нужно сначала определиться с термином "Техническое задание", а также "Задание на разработку", "Требования к проекту", "Спецификация".

[Hooter]

Скажите, а мой вопрос о создании макетов на этапе формирования ТЗ был проигнорирован или не замечен?

[PooH]

ИМХО, макеты нужны далеко не всегда, но думаю никогда не помешают. Но вопрос в том - зачем они нужны вообще: чтобы скорректировать ТЗ?

[Alf]

Скажите, а мой вопрос о создании макетов на этапе формирования ТЗ был проигнорирован или не замечен?

Скорее, как на экзамене: если не знаешь точного ответа на вопрос, постарайся перевести разговор в другое русло

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

Когда туман рассеивается, задача ставится по уже описанному пути - конкретное задание, конкретные сроки и т.д.

Как приспособить эту неформальную схему к случаю стороннего Исполнителя - ума не приложу.