Проектирование

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

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

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

ставлю Vanok, оценку  5+ ...

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

http://luckytoys.ru/journal/view/kak_pravilno_zadavat_voprosy__iskusstvo_obsheniya_582.html
http://constructorus.ru/samorazvitie/kak-pravilno-zadavat-voprosy.html
http://www.topsecret.ru/secret/iskusstvo-zadavat-voprosy

что же именно Вы хотите.

Я (с командой) любую задачу, связанную с программированием, выполняю только с согласованным техническим заданием (и с Заказчиком, и с командой). В ТЗ сроки, объем работы и собственно содержание.
Для модов это особенно имеет смысл по тому что разработка может длится годами и что бы не сбиться с изначальной идеи ТЗ жизненно необходимо (ИМХО).
Это позволяет ставить команде четкую цель и загонять в рамки (допустим по срокам что бы разработка не длилась вечность, как это с большинством любительских модов).
Что же я хочу: Оценить качество составления Тех. Задания. Что бы учитывать минусы и плюсы предыдущих при проектировании новых. Так, вот по каким критериям можно оценивать ТЗ? За что ему можно поставить плюс или минус?

Надеюсь мне удалось раскрыть суть вопроса 
 
Добавлено: 04 Июля, 2016, 09:24

всегда приятно когда тебя понимают

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

За что ему можно поставить плюс или минус?

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

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

фактический ТЗ должен писать исполнитель

Да, так и делаем. По тому что если брать проекты к примеру разработки сайта, то Заказчик как правило не знает что хочет. Верней знает, но слишком абстрактно. "Что бы было красиво..." или "Надо такую кнопку что бы я нажимал и она за меня всю работу делала...". По этому пишем сами

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

Благодарю за идею. Взаимоисключающие требования не предусматривал, хотя они есть
 
Добавлено: 04 Июля, 2016, 16:06

ТЗ -- обычное  такое планирование

ТЗ - это задание) и обычно ТЗ огромное кол-во в проекте (который и является планом, у него есть устав с плановыми затратами. сроками, объемом и прочее).
Ну, или теперь я вас не понимаю 

iSteelFelix, Если честно, я так и не понял, чего же вы, собственно, хотите от пользователей форума? 
По поводу критериев. Нельзя все моды оценивать по одной линейке, каждый чем-то своим уникален и интересен.

Без обид, но весь этот разговор (разговор?) напомнил мне анекдот

Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы - ответила женщина.
— Вы, должно быть, программист?
— Да, а как вы догадались?
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно говоря, вы мне совершенно ничем не помогли.
— А вы, наверное, менеджер?
— Да. А вы как догадались?
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнить, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я.

Кое-какие критерии для себя наметил, тему можно закрывать.