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

[Sla]

Хочется и свои пять копеек вставить

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

Идеальный вариант, к которому нужно стремиться.

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

Это уже вторично

пользователь даже не знает зачем ему программа и что она должна делать …

Тогда зачем он ее заказывает

Принимал участие в некоторых НИРах, начиная с самого начала. Первое место в договоре на разработку занимало «Разработка и согласование ТЗ. Причем, время на это выделялось больше чем половина всего срока.  Т.е. разработчик выступает в лице Заказчика. Это могло занимать несколько этапов. Естественно, работы начинали вестись до появления готового ТЗ, читай СПЕЦИФИКАЦИЯ. В результате – все работы выполнялись в срок и в соответствии с ТЗ. Ни на одну выполненную работу рекламаций не поступало, за исключением мелких! доработок, и все по «вине Заказчика».
Была ситуация, когда Заказчик пришел уже с готовым ТЗ, которое было составлено по «невыполненному» проекту (даже исходники нам давал). В результате Исполнителем было разработано (переработано) и согласовано ТЗ и выполнены работы. Просто время на разработку оного ушло вдвое меньше. Надо заметить, что функционально оба проекта друг от друга не отличались.
С тех пор, все ТЗ разрабатываем самостоятельно, естественно посылкой является клиент которому нужно ВСЕ.

Очень плохо, когда «системный архитектор» не понимает Заказчика, и хочет посадить Заказчика «на  иглу». Ни к чему хорошему это не приведет.

[Alf]

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

 

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

[Hooter]

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

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

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

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

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

[Sla]

Это концепция.
Заказчик формулирует заказ типа "хачу шоб було". Разработчик говорит "Будет так", и Заказчик при этом соглашается. Естесвенно, проходит несколько этапов согласования, утрясания, но, повторюсь, никаких проблем не возникало. И не вижу ничего здесь такого "криминального"

[REM]

Это концепция.
Заказчик формулирует заказ типа "хачу шоб було". Разработчик говорит "Будет так", и Заказчик при этом соглашается. Естесвенно, проходит несколько этапов согласования, утрясания, но, повторюсь, никаких проблем не возникало. И не вижу ничего здесь такого "криминального"

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

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

[Dimka]

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

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

Мне кажется, что позиция "это в теории хорошо, а у нас..." заложенным в ней противопоставлением заранее настраивает программистов против любых улучшений процесса. Видимо, работает известный лозунг "Лучшее - враг хорошего!" И этот консерватизм означает, что программисты сами не желают ничего менять в своей работе - их всё устраивает, хотя на словах они могут декларировать поддержку "теории" и всячески одобрять её... Hooter? Или это позиция "маленького человека", за которого всё решают "большие менеджеры и архитекторы", а уж как и что они там решают - "не наше дело"?

Добавлено через 20 минут и 21 секунду:

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

Вот это хотелось бы прокомментировать в свете вышеприведённой ссылки на статью.

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

Первые, хотят они того явно или лишь подсознательно, но всегда стремяться подогнать своё готовое решение к бизнес-процессам, а то и бизнес-процессы под решение. И их мало заботит реальная потребность заказчика. Именно для таких аналитиков подходит фраза "рассмотреть возможность их (бизнес-процессов) автоматизации".

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

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

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

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

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

[Alf]

С таким подходом и не поспоришь. Жаль, что это теория.

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

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

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

Теперь буду бегать к нашему архитектору за ответами. Ой, не обрадуется он

Да вроде в должностные обязанности программиста и не входит обеспечение непрерывной эйфории архитектора

Не слишком напрягался на ранних этапах - значит, на поздних мало поводов для радости будет...

[Alf]

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

Это концепция.

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

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

Разумеется, перед тем как приступать непосредственно к разработке програмного продукта надо всё согласовать с заказчиком и обязательно задокументировать.

Пардон, но согласно нашей концепции,

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

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

Невольно вспомнился Толкиен:

- А он кто такой, моя  прелес-с-сть?  -  прошипел  Голлум  (он  привык обращаться  к  самому себе, потому что больше ему не с кем было разговаривать).
...
-  Не  присес-с-сть  ли  тебе,  моя прелес-с-сть, не побес-с-с-седовать ли с ним немнож-ж-жко?

Боюсь, что "моя прелес-с-сть" в лице заказчика слишком легко договорится с собой же в качестве исполнителя.

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

А куда он денется, если сам же его и делает?

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

Еще бы ему при этих-то условиях не понять...

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

А смысл менять требования на то, что сам себе заказал, если принято будет в любом случае?

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

[REM]

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

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

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

[PooH]

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


немного офтопика:
есть такие законы:

Законы  машинного  программирования




    1. Любая действующая программа устарела.
    2. Любая программа обходится дороже  и  требует  больших
 затрат времени, чем предполагалось.
    3.  Если  программа  полностью  отлажена, ее нужно будет
 скорректировать.
    4. Любая программа стремится занять  всю  доступную  па-
 мять.
    5. Ценность программы прямо пропорциональна весу ее 'вы-
 дачи'.
    6. Сложность программы растет до тех пор, пока не превы-
 сит способности программиста.

              Постулаты Трумэна по программированию.
             =======================================
    1.  Самая грубая ошибка будет выявлена, лишь когда прог-
 рамма пробудет в производстве, по крайней мере, полгода.
    2. Контрольные перфокарты, которые  не  могут  стоять  в
 неправильном порядке, будут перепутаны.
    3.  Если  назначен  специальный  человек для контроля за
 чистотой исходной информации, то  найдется  изобретательный
 идиот,  который придумает способ, чтобы неправильная инфор-
 мация прошла через этот контроль.
    4. Непечатный жаргон - это тот язык, которым  решительно
 все программисты владеют в совершенстве.

                Законы ненадежности Джилба.
               ============================
    1. Компьютеры ненадежны, но люди еще ненадежнее.
    2.  Любая система, зависящая от человеческой надежности,
 ненадежна.
    3. Число ошибок, которые нельзя обнаружить,  бесконечно,
 в  противовес  числу ошибок, которые можно обнаружить - оно
 конечно по определению.
    4. В  поиски  повышения  надежности  будут  вкладываться
 средства  до тех пор, пока они не превысят величину убытков
 от неизбежных ошибок или пока кто-нибудь не потребует, что-
 бы была сделана хоть какая-то полезная работа.

                      Закон Брука.
                     =============
    Увеличение числа участников при подготовке  опаздывающей
 программы только замедляет процесс.

                Закон мира ЭВМ по Голубу.
               ==========================
    1.  Неточно  спланированная программа требует в три раза
 больше времени, чем предполагалось; тщательно  спланирован-
 ная - только в два раза.
    2.  Работающая над программой группа питает отвращение к
 еженедельной отчетности о достигнутых результатах, посколь-
 ку она слишком явно свидетельствует об отсутствии таковых.

                       Принцип Шоу.
                      =============
    Создайте систему, которой сможет пользоваться  дурак,  и
 только дурак захочет ею пользоваться.

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

Есть еще следствие из "закона прикладной неразберихи"

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

Практика показывает, что эти следствия и законы работают.

[Dimka]

REM, смотри внимательно, что ты говоришь:

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

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

автоматизировать процесс хранения информации о клиентах.

Хранение не автоматизируется! Хранение - это не процесс! Можно лишь говорить о замене бумажной картотеки на электронную. При этом (если речь не идёт о потребности в CRM), обычно обходятся Excel'ем (для малого предприятия) или примитивной БД с приложением по вбиванию в неё данных.

аналитики фирмы "А" проводят собственную оценку бизнеса фирмы "Б" и на основании этой оценки и выдвинутых ранее требований составляют ТЗ, которое затем согласуется с заказчиком.

Речь идёт о том, что аналитики фирмы "А" - люди заинтересованные в том, чтобы "проавтоматизировать" решительно всё на как можно большую сумму. А заказчику требуется не автоматизация, а решение проблемы низкой эффективности работы.

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

[REM]

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

Чёрт подери, ребят, вы что - сговорились? Да я о том как раз и талдычу, что задача фирмы "А" решить проблемы клиента, а не тупо проделать то, что он тебя просит. Не нравится слово "автоматизировать" - ради бога, буду говорить "реорганизовать".

Хранение не автоматизируется! Хранение - это не процесс! Можно лишь говорить о замене бумажной картотеки на электронную.

Согласен, слова я подобрал плохие.

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

Но эта твоя фраза доказывает, что мы говорим ОБ ОДНОМ И ТОМ ЖЕ!!! Не надо придираться к словам, главное разобраться в сути!

[Sla]

2 Alf.  Я высказал свое видение в " Разработка технических заданий и спецификаций программных продуктов", которое, к моей прелес-с-сти, работает. Что же мне делать если Вы, уважаемый, эту концепцию не приемлете? Вступать  с Вами в дискусию не желаю и не вижу необходимости. А то что Вы надумали - это Ваша проблема.

[Dimka]

Чёрт подери, ребят, вы что - сговорились? Да я о том как раз и талдычу, что задача фирмы "А" решить проблемы клиента, а не тупо проделать то, что он тебя просит. Не нравится слово "автоматизировать" - ради бога, буду говорить "реорганизовать".

А я говорю о том, что: 1) пока не определена причины проблемы, говорить о методе (например, автоматизации) нельзя; 2) фирма "А", если это фирма разрабатывает ПО, всякую проблему будет "решать" внедрением своих продуктов - "Если твоим единственным инструментом является молоток, то все твои проблемы выглядят как гвозди." Это в корне неверный подход для решения проблем заказчика, а не своих собственных.

Не надо придираться к словам, главное разобраться в сути!

Да как же точно и однозначно понять суть, если её внятно словами не выражают?

[Alf]

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

Чем конкретно?

Неужели я выражаю свои мысли столь непонятно?

Предельно понятно. Если бы были какие-то неясности, я бы попросил прояснить.

Как иначе объяснить ваш менторский тон?

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

В конце-концов, вы сами подняли эту тему, а значит вам должны быть интересны различные мнения. Истина рождается в споре, не так ли?

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

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

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

Такой подход напоминает мне старый анекдот, когда человек ищет ключи не там, где их обронил, а под фонарем, потому что там светлее.

[REM]

пока не определена причины проблемы, говорить о методе (например, автоматизации) нельзя;

Не надо придираться к словам, главное разобраться в сути!
Да как же точно и однозначно понять суть, если её внятно словами не выражают?

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

[Alf]

2 Alf.  Я высказал свое видение в " Разработка технических заданий и спецификаций программных продуктов", которое, к моей прелес-с-сти, работает. Что же мне делать если Вы, уважаемый, эту концепцию не приемлете? Вступать  с Вами в дискусию не желаю и не вижу необходимости.

Не вижу проблемы. Работает - чудесно. Все, что работает,следует использовать. Мое неприятие особого ущерба не нанесет, не я же за это плачуденьги. До дискуссии со мной при этом снисходить вовсе не обязательно. Колхоз - дело добровольное.

А то что Вы надумали - это Ваша проблема.

ОК, буду жить со своей проблемой дальше.

[PooH]

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

[Dimka]

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

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

[REM]

Чем конкретно?

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

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

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

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

Боюсь, что полного понимания мы всё же не достигли. В вашем примере фирма "А" делает не то, что нужно клиенту, а то, что она умеет делать. Разумеется, ситуации, о которой я говорю, сложно добиться на практике (действительно, человеку проще убедить себя, что клиенту нужен notepad, чем осознать, что ему на самом деле нужен Word). Но, на мой взгляд, это есть некий идеал, к которому нужно стремиться. Очень много здесь, как и в любой другой профессии, зависит он настроя работника. Одно дело, если он относится к своим обязанностям спустя рукава, другое - если он загорится желанием помочь клиенту, применив для этого все свои навыки.

[Alf]

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

Боюсь, или я где-то неправильно выразился, или мои слова все же неверно истолкованы.

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

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

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

Как следствие, считаю приведённые вами утрированные примеры весьма некорректными.

Следствие ез заведомо неверной предпосылки (см. выше) вряд ли является верным. Хотя, конечно, против IMHO мне возразить нечего.

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

Увы, все мы несовершенны, - можете. Хотя немного приблизиться к совершенству все же реально, воспользовавшись толковым словарем: http://slovari.yandex.ru/art.xml?art=dal/dal/03110/37400.htm&encpage=dal&mrkp=http%3A//hghltd.yandex.com/yandbtm%3Furl%3Dhttp%253A//encycl.yandex.ru/texts/dal/dal/03110/37400.htm%26text%3D%25EC%25E5%25ED%25F2%25EE%25F0%26reqtext%3D%25EC%25E5%25ED%25F2%25EE%25F0%253A%253A9016873%2B%2526/%25280%2B0%2529%2B!%2525%25EC%25E5%25ED%25F2%25EE%25F0%253A%253A1819103916%26%26isu%3D2 (ради бога, не сочтите за менторство; впрочем, тут уже рекурсия получается).

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

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

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

[REM]

Боюсь, или я где-то неправильно выразился, или мои слова все же неверно истолкованы.

Я исходил из этих ваших слов:

Предельно понятно. Если бы были какие-то неясности, я бы попросил прояснить.

Увы, все мы несовершенны, - можете. Хотя немного приблизиться к совершенству все же реально, воспользовавшись толковым словарем:

Спасибо за ссылку Радует, что термин я толковал правильно. В тех ваших словах я увидел  попытку снизойти до уровня "ученика" и втолковать ему истину на простом примере. В любом случае, было это менторством, или нет - не суть важно: есть более интересные предметы для обсуждения(ИМХО).

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

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

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

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

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

[Dimka]

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

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

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

Так что, IMHO, разработчик должен заниматься своим делом - писать программы, а не решать проблемы клиента. (Кстати, это одна из центральных идей наших ЛЕСов.) Это клиент должен решать свои проблемы так, как сумеет.

[Alf]

[В тех ваших словах я увидел  попытку снизойти до уровня "ученика" и втолковать ему истину на простом примере.

Разумеется, каждый волен видеть то, что он хочет, разубеждать тут сложно. Во избежание будущих недоразумений хочу заранее сказать следующее.

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

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

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

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

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

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

Не факт. Не любой продукт он хочет приобрести, а тот, который позволяет решить конкретные задачи, которые без него либо сложно решаются, либо вовсе не решаемы. Например, у меня на полке завалялся нераспечатанный лицензионный дистрибутив Windows for Workgroup V3.11, вполне качественный продукт, достаточно функциональный, и отдал бы совсем недорого. Только вряд ли выстроится очередь желающих его приобрести.

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

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

[PooH]

Объясните мне причем тут проблемы заказчика и ТЗ
Третий раз предлагаю, давайте вместо абстрактных проектов обсудим пример очень простого: Допустим тривиальную ситуацию, есть заказчик и хочет видеть на экране надпись "Hello, word!". Вы - исполнители. И далее по пунктам первого поста... От кого программист (именно, программист) должен получить ТЗ? Разве от заказчика? Всем ясно, что должно быть обсуждение деталей и т.д. Вопрос в том, что конкретно вы хотели бы увидеть в ТЗ по данному проекту?

[REM]

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

Alf, я уже попытался замять эту тему. Но на такое не ответить просто не могу. Всё, что я пишу на этом форуме может быть без каких-либо предуведомлений подвергнуто самой жестокой критике. Более того, ради этого я здесь и нахожусь - слушать "да, да, я согласен" мне просто не интересно. Просьба одна, чтобы эта критика была конструктивной.

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

А я - не считаю. Поверьте мне на слово, мне не так уж трудно придумать пример, когда бездумное следование пожеланиям заказчика приведёт к курьёзным последствиям. Ключевое слово здесь - "бездумное". Конечно, придумывать ТЗ самому себе, не задумываясь о последствиях - нелепо. Так можно легко извратить любую, даже самую изящную концепцию. Так что изъян, на мой взгляд всё-таки закрался в логику выводов. Мне гораздо более по душе критика dimkи. Повторюсь, были ли ваши слова сказаны менторским тоном или нет - для меня не принципиально; более того, это здорово отвлекает нас от основной темы обсуждения. Постарайтесь воспринять мои слова ... как доброжелательную критику И, соответсвенно, проигнорировать её, если она, в свою очередь, не покажется вам конструктивной.

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

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

[Dimka]

Третий раз предлагаю, давайте вместо абстрактных проектов обсудим пример очень простого: Допустим тривиальную ситуацию, есть заказчик и хочет видеть на экране надпись "Hello, word!". Вы - исполнители.

Вопрос в том, что конкретно вы хотели бы увидеть в ТЗ по данному проекту?

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

Вот это то, что я захочу узнать у заказчика, если он попросит: 1) видеть (а не слышать), 2) на экране (а не в напечатанном виде), 3) надпись (а не рисунок, фотографию, фильм), 3) "Hello world!" (на английском языке, именно эти буквы, в таком их регистре, с такими знаками препинания).

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

[PooH]

dimka, ты считаешь, что тебе всех этих данных хватит, для полной реализации и сдачи проекта? Или в зависимости от ответов, быдут еще вопросы?

[Alf]

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

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

[Dimka]

dimka, ты считаешь, что тебе всех этих данных хватит, для полной реализации и сдачи проекта?

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

К "техническим условиям" можно ещё добавить вопрос о желаемом hardware, если будет заявлена особо примитивная операционная система.