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

Однако я отвлекся. Здравствуйте.

Тут как-то раз greesha высказал мысль, что в теории оно может и бывает, но на практике совсем иной получается компот. Компот, естественно, получается в том случае, когда компот в голове, компот в практике, компот в управлении. Но что забавно, даже при таком вот компоте порой дело движется и довольно уверенно.

К чему это я. Да все о требованиях родимых. Пишем требования по ТЗ, пишем списками, пишем фичами, пишем вариантами использования, пишем как придется.

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

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

Такой вопрос. Скажите у Вас такая же практика? Вы примерно также устраиваете свой процесс разработки? Это вполне нормально? Если ненормально, то как лучше строить процесс?

Читаешь книги, статьи, слушаешь гуру - как много всего придумано и предложено. Однако на практике видишь совершенно собственные изобретения, которые совершенно противоречат написанному. Может дело в том, что идет это с Запада, а наша азеоповская душа устроена иначе?

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

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

Но стремиться к хорошему несомненно надо :-)

Тут как-то раз greesha высказл мысль, что в теори оно может и бывает, но на практике совсем иной получается компот. Компот, естественно, получается в том случае, когда компот в голове, компот в практике, компот в управлении. Но что забавно, даже при таком вот компоте - дело движется и довольно уверенно.

Это не я высказал. Это цитата из книги Роберта Гласса.

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

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

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

И вот в такой момент возникает некоторый суррогат таких требований, совмещенных с проектными решениями. В результате основной проектный Такой вопрос. Скажите у Вас такая же практика? Вы примерно также устраиваете свой процесс разработки? Это вполне нормально? Если ненормально, то как лучше строить процесс?

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

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

Все эти задачи не приносят дохода в краткосрочной перспективе. Но при этом требуют глубокой концентрации, а значит, много времени. И всё время оказываются оттеснёнными какими-то "более срочными" задачами.

Я уже пару лет безуспешно пытаюсь добиться от директора какой-то стратегии развития. Ладно, чёрт с ней, со стратегией, но хотя бы планов развития на ближайший год. И буквально сегодня я сделал открытие. А ему, по-моему, и не нужны эти планы. Он продавец, а цель продавца - получить свои комисионные. То есть ему нужно начать проект и показать заказчику что-то худо-бедно работающее, чтобы продать ему оборудование. А продолжение проекта, сопровождение, техническая поддержка - это только досадные помехи на пути к окучиванию новых заказчиков и новым продажам. В результате у нас с ним возникает огромное напряжение при назначении приоритетов: я считаю своим долгом в первую очередь выполнить обязательства перед существующими заказчиками, а для него важно как можно быстрее реагировать на бредовые гениальные идеи потенциальных заказчиков, звонящих ему ежечасно и обещающих купить 50 000 терминалов уже до конца этого года.

Читаешь книги, статьи, слушаешь гуру - как много всего придумано и предложено. Однако на практике видишь совершенно собственные изобретения, которые совершенно противоречать написанному. Может дело в том, что идет это с Запада, а наша азеоповская душа устроена иначе?

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

Формулировать требования в любом случае стоит, как мне кажется, хотя бы для себя лично. Даже если вы автор эссе/разработчик, все нюансы постоянно в голове держать трудно. Лучше, когда они где-то описаны, и в случае возникновения вопросов можно сослаться на какой-либо документ. Разработчик, конечно, может и по коду логику восстановить (да частенько так и делается). К сожалению, у такого подхода есть по крайней мере два недостатка:
 1) получение информации о том, как работает система, может быть занять много времени, если, скажем, код чужой;
 2) получить информацию о том, как работает система, может только человек, обладающий навыками разработки.
А вообще нужно стремиться к тому, чтобы все участники процесса разработки и иные заинтересованные в успешном внедрении системы лица все-таки с требованиями знакомились - во избежание недоразумений на более поздних этапах разработки.

А Вам еще более умный вещь скажу ...
Даже после того как описал требования в текстовом виде и далее по нему составил схему, то видишь какой бред ошибки написаны в тексте

Все эти задачи не приносят дохода в краткосрочной перспективе. Но при этом требуют глубокой концентрации, а значит, много времени. И всё время оказываются оттеснёнными какими-то "более срочными" задачами.
А ему, по-моему, и не нужны эти планы. Он продавец, а цель продавца - получить свои комисионные. То есть ему нужно начать проект и показать заказчику что-то худо-бедно работающее, чтобы продать ему оборудование. А продолжение проекта, сопровождение, техническая поддержка - это только досадные помехи на пути к окучиванию новых заказчиков и новым продажам. В результате у нас с ним возникает огромное напряжение при назначении приоритетов: я считаю своим долгом в первую очередь выполнить обязательства перед существующими заказчиками, а для него важно как можно быстрее реагировать на бредовые гениальные идеи потенциальных заказчиков, звонящих ему ежечасно и обещающих купить 50 000 терминалов уже до конца этого года.

Подпишусь под каждым словом!
Пока при текущем процессе прибыль растет на десятки процентов, рост прибыли на 3-5% за счет оптимизации процесса производства владельцев бизнеса интересовать не будет.

ИМХО надо стремиться к хорошему, одному тебе систему не сломать

Ой, Саня, нет у меня такой задачи и роли. Никто не уполномачивал, да и кто я такой? Препод с 14 летним опытом, исследователь с 17 летним опытом. Я же по определению только и могу - учиться, изучать. А в бизнесе, что нужно? Велью и сразу!

Цинично добавлю: очень многое зависит от руководства. Если руководство устраивает текущий процесс

А если не устраивает? А если проблема в ранее принятом стиле работы, инерции, ошибках проблемах архитектуры? Хотя тут слышал такое высказывание: "да причем тут архитектура, не в архитектуре дело, у всех эти архитектуры одинаковые"

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

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

Разработчик, конечно, может и по коду логику восстановить (да частенько так и делается). К сожалению, у такого подхода есть по крайней мере два недостатка:

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

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

Если ты в пример ставишь присланный как-то тобой документ, то я тебя оччень понимаю. Но, однако ёопытрст получаешь:)

А если не устраивает? А если проблема в ранее принятом стиле работы, инерции, ошибках проблемах архитектуры? Хотя тут слышал такое высказывание: "да причем тут архитектура, не в архитектуре дело, у всех эти архитектуры одинаковые"

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

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

Irr, НИЧЕГО подобного я тут не говорил (исключая архитектуру), я не перехожу на конкретику, я говорю об общем. Я не говорю о чем-то моем. Тем более я не могу знать мысли начальства. Т.е. don't be hurry in your conclusions.

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

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

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

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

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

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

Но требуют больших временных затрат на первоначальном этапе

Но требуют больших временных затрат на первоначальном этапе

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

Заказчик говорит "ДА", у нас это работает именно так, т.е. бизнес-процессы верны, правила, ограничения и т.д. поняты

Это не заказчик, а просто какой-то ангел.