Подскажите методику составления ТЗ для выполнения небольших работ в 1С (2-4 в неделю). Дело в том что иногда случаются недопонимания и приходиться переделывать. Есть предположение что составление ТЗ по сторогой методике могло бы решить данную проблему. Но как составлять ТЗ для таких работ чтобы не закопаться в этой рутинной работе и чтобы оно могло устранить все проблемы недапонимания? Есть у кого опыт?

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

Эта тема в разных ракурсах с завидным постоянством появляется не реже раза в неделю на форуме.
НЕТ ТАКОЙ МЕТОДИКИ.
Есть только экстремальное программирование, и тебя ждет эта участь.

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

Ничего не подписывай. Деньги бери вперед. Оплата за фактически отработаное время. Исправление косяков за счет заказчика.

(4) Уточню. Есть группа программистов, которая на штатной основе занимается поддержкой и расширением системы. Заказчик здесь сотрудники этой же компании.

(5) То есть собрались собственными сотрудниками воевать? Во кретины.

(6) Почему воевать? Наоборот - помочь им избежать ошибок, переделок и потерь времени. И хочу узнать как это можно сделать оптимально, как это сделано в других компаниях.

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

И это все? Все идеи сводятся к "пиши человеческим языком"? Неужели все так и работают?

Я тут начала как-то требовать ТЗ. Надоело по 5 раз переделывать. Они и человеческим-то не могут сформулировать. И тут-же началось - а вот тот програмер у нас не требовал ТЗ. Ну и все понятно...

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

Делюсь опытом как не надо делать, но я так делаю.
Приходит клиент, начинает разводить руками и что-то невнятное говорить.
После часа беседы, и кстати на тему что водка паленая, начинаешь друг друга понимать. Берешь лист бумаги и куриным почерком записываешь, что удалось понять. Со временем эти листы копятся, и их я скрепляю степлером.
Вот ОНО РОДНОЕ ТЗ.
Но самое прикольное, что клиент к этому относится так серьезно как будто это правительственный документ. Не дай бог мне эти листики потерять, врагом буду на всю оставшуюся жизнь, и я уже это точно знаю.

У меня еще прикольнее. Есть у меня одна контора на постоянной обслуге. Решили ввести штрихкодирование. Хотели меня напрячь. Но поразмыслили и решили что б дело заспорилось пригласить стороннюю навороченную фирму. Прошло около 2 месяцев разговоров. И тут вдруг обращаются ко мне с просьбой помочь в написании ТЗ. Я естесно в позе. Говорю типа парни я же не при делах. Ну вроде как люди порядочные говорят типа ну памаги дарагой. Ок. Встретились все кроме исполнителя и что я вижу они даже между собой не могут договориться что им нужно.)))) Завтра в стречаюсь с исполнителем уверен услышу новую историю. Вот так. Так что наверное не надо впереди тепловоза бежать. Не готов у нас народ к четкой системе. Не тот менталитет.

Да уж... обычно происходит как в (12) :), но потом все же лучше аккуратненько оформить это дело и чтобы заказчик подписал - и всем хорошо
Если неправильно рассказали что к чему - носом в бумажку и заявочку на доработку

(14) Это смотря какой заказчик. Один позвонил мне и говорит на сколько можно протянуть сеть. Для чего? Зачем? Не говорит. Ну я типа выпалил 105 метров. Ну думаю верняк 100МБ. А мне потом предъява. Он квартиру купил в ста метрах что б сеть была. И ему нашелся умник сказал что сеть можно на километр протянуть. Я конечно не такой умный)))). Но про интернет слышал. Да и умнику тому тоже сказал)))).

 
            Справочное руководство как основа разработки ПО
 
[o] Справочное руководство описывает интерфейс взаимодействия
 пользователя с программой включая снимки пользовательских экранов
 описание кнопок на клавиатуре, данные ввода и данные вывода из
 программы. то есть справочное руководство описывает ЧТО именно делает
 программа. справочное руководство _не_описывает_ КАК именно работает
 программа, какие алгоритмы в ней используются или КАК она работает с БД.
[o] Справочное руководство является ничем иным как
 набором аксептанс тестов для клиента.
 Договором с клиентом является описание протокола
 взаимодействия с клиентом. В нем должно быть описано
[k] следующее: все что есть в справочном руководстве является
 фактическими функциями программы и за которые клиент заплатил
 свои деньги. все что в справочном руководстве явно не описано
 не является функциональными возможностями программы и может быть
 исключено из нее в следующей версии программы. За работу таких
 недокументированных особенностей фирма поставщик не несет ответственности,
 покупателю не рекомендуется пользоваться данными свойствами программы.
[k] Если какая либо документированная возможность программы не функционирует
 так, как описано в справочном руководстве то пользователь имеет право
 требовать безвозмездного устранения ошибки и приведения функциональности
 программы к тому виду, как это описано в справочном руководстве.
[k] В случае если пользователь желает дополнить программу дополнительными
 функциями то изначально исполнителем (на основании письменных и утвержденных
 пользователем требований) создается дополнение к справочному руководству
 где описываются все дополнительные возможности в виде не отличающемся
 от основного руководства (экраны пользователя, данные ввода, данные вывода)
 Данная работа осуществляется итерационно в связке с пользователем и
 оплачивается по времени (часам, дням, неделям) После завершения дополнения
 к справочному руководству оно утверждается пользователем заказчиком и
 исполнителем в письменном виде и с этих пор является неотъемлимой частью
 справочного руководства. Приведение основной программы к тому виду, как это
 описано в справочном руководстве осуществляется исполнителем безвозмездно
 за время не превышающее время создания дополнения к справочному руководству.
-----------------------------------------------------------------------------
[k] Оригинал справочного руководства всегда в письменном виде утвержден и
завизировано обеими сторонами в двух экземплярах (у заказчика и исполнителя)
Электронные копии последней версии справочного руководства у каждого
пользователя системы. Электронная версия справочного руководства у
индивидуального пользователя может быть неполной (только в рамках полномочий
этого пользователя, выданных руководством заказчика)
[k] Все дополнения к справочному руководству в письменном виде утверждены и
завизированы обеими сторонами в двух экземплярах (у заказчика и исполнителя)
Электронные копии дополнения к справочному руководству у каждого пользователя
системы. Электронная версия дополнений у индивидуального пользователя
может быть неполной (только в рамках полномочий этого пользователя, выданных
руководством заказчика)
(c) reminder

12 прикольно
неужто сам писАл ))

Писать ТЗ по ГОСТ-у и его составление оговаривать отдельной ценой.

 у меня просто табличка
раздел I - поля: объект, изменения, описание_функционала, предв_оценка_ времени
раздел II - поля: дата_сдачи_по_плану, стоимость, "согласовано"(подпись)
так вот второй_раздел.количествоСтрок(unlimited) )))

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

(23) Сорри проблемы 1 и 2 поменять номерами :)

Из личного опыта.
Вопросы к заказчику:
1) Как бы Вы это делали вручную на бумаге?
2) Как бы Вы это делали в ёкселе?
3) Как Вы определите, что работа выполнена?
(придумываем исходные данные, берем бумагу, карандаш, калькулятор,
пишем, считаем, рисуем, чертим и т. п.)
4) Все это записывается/зарисовывается слово в слово,
можно даже диктофон использовать, если большой объем,
потом читается что получилось, непонятное/неправильное исправляется, ставится подпись.
Определяются сроки и оплата.
5) Претензии принимаются если работа не соответствует подписанной бумаге.
6) Интерфейс как правило вылизывается при общении с операторами,
здесь можно не записывать/подписывать, поначалу сделать как сам считаешь лучше.
6) Получаем денюшку.
7) Если появляется претензия, не отраженная в бумажке, перейти к п.1
8) п.7 только после п.6, даже если заказчик говорит "я передумал, мне это не надо".

(25) :) Вы правы. Сферические кони в абсолютном вакууме соударяются абсолютно упруго...

(28) основы риск менеджмента. риск менеджмент для идиотов. альтернативные ветки будущего. учиться, учиться, учиться. тогда наконец не будем встречать перлы виды "_Единственный_ физиологический смысл" :)

(28) Нет, я просто позавидовал

(18) Писать по госту нас не устраивает: продолжительность работ 1-3 дня, и написание ТЗ по госту будет несоответствовать проводимым работам по затрате времени.
(19) А как вы заполняете первый раздел?
(20) Почта не решает проблем недопонимания, т.к. они обычно вскрываются уже при предъявлении работы заказчику.
(22) любопытно, Thanks
(23) Ну это все общие слова. Моя проблема описана в (0) и (5), мне кажется что довольно подробно - если нет скажите что уточнить - напишу.
(26) Вот это уже ближе к телу. Мне как раз и интересно узнать "как составляется ТЗ", т.е. какие задаются вопросы (особенно), что и в какой последовательности заполняется, рисуется. И все это желательно с опорой на опыт ваш или чужой - не важно.

(31) Отменяю ответ для 18. Просто ботать госты не хочется, а потом еще придумывать как их присобачить к конкретной проблеме. Хочется обратиться к существующему конкретному опыту людей, которые уже применяют какую-то методику.

(33) Просто БТР в рамках теории риск менеджмента описывает полную картину рисков, а не наиболее или наименее вероятных, как ты в 25. Риск есть риск, если все делать по уму - рисковых случаев вообще не должно случаться :))
Но ведь случаются же. Вывод простой: надо с ними работать, а не просто выражать эмоции в стиле "НЕ ДОЛЖНО БЫТЬ ПОТОМУ ЧТО НЕ ДОЛЖНО БЫТЬ НИКОГДА", как ты в 25. Ибо это просто НЕКОНСТРУКТИВНО.

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

Что-то дельное без каши в голове только в 16, и именно на этот пункт 0 реакции 1024 грамма презрения.

Вот это для полезно дать бухгалерам:
.
Правила поведения бухгалтера при работе c 1C
1. Если вы не знаете, какие проводки нужно сделать в 1С, смело обращайтесь к программисту - он их все знает наизусть.
2. Если вы не знаете как заполнить документ, то придя к программисту ни за что не признавайтесь в каком документе у вас затруднения, на то он и программист, чтобы обо всем догадаться самому. Особенно эффектно задать вопрос типа "А почему сумма не считается правильно?" - он же должен знать, что вы сидите в Экселе и не можете нажать автосумму. Также эффектны вопросы: "А почему у меня количество в конце отрицательное?", "А почему у меня вчера другая сумма была", "А какой датой мне аванс поставить?" - ведь нужно быть редким идиотом, чтобы не понять о чем речь. А еще лучше постарайтесь придумать какой-нибудь универсальный вопрос типа: "А у меня там это, не могу, потому что программа не дает сделать" - ваша миссия выполнена - о проблеме вы сообщили, а в чем проблема - это дело программиста, пусть исправляет. Hу в крайнем случае первый вопрос должен быть "А знаешь о чем я тебя хочу спросить?".
3. Если по вашему мнению документ делает неправильные проводки по документу ни за что не говорите об этом программисту - не пройдет и 3 месяцев, как это обнаружится само. И само исправится.
4. Если программа вам не дает выписать партию, явно имеющуюся на складе - срочно сообщайте об этом программисту - не могли же вы выписать неправильно, это врет программа. Особое удовольствие программист испытывает, когда копается в отгрузке за последний месяц.
5. Если вы внесли исправления задним числом - например в приходной накладной, по которой потом были отгрузки, изменили цену ни кому в этом не признавайтесь - что это за программист, который не может написать процедуру на обработку неправильных действий пользователя, а то, что это повлияет на отчетность - вам наплевать - вы за отчетность не отвечаете. Со временем вы войдете во вкус и будете так делать постоянно - на крики программиста, что надо предупреждать и что отчетность сформирована, резонно заметьте - "Hельзя оставлять ошибки".
6. Если вам надо задать вопрос, то заглянув к программисту убедитесь, что у него минимум два человека - у него гораздо лучше получается разговаривать одновременно с тремя.
7. Если вы знаете, что в программу нужно вносить три последовательных изменения, то никогда не говорите программисту все три, пусть хоть немножко сам подумает - это ведь так очевидно.
8. Если вы в своих проводках используете субсчет - никогда не используете тот же, что и другой бухгалтер, который например оприходовал на этот счет - программисту сильно нравится наблюдать кредитовое сальдо на активном счете, но еще больше дебетовое на пассивном.
9. Если вы пытаетесь изложить что-то на бумаге, то потом ее обязательно уничтожьте, а то программист скажет, что сделал так, как ему написали - он придурок, и не понимает, что написано одно, а подразумевается совсем другое.
10. Если вы попросили внести изменения в программу, а потом обнаружили, что это неправильно, то смело обвиняйте в этом программиста - "Это ты так сделал, а у меня не идет", вы тут не при чем, мог бы и догадаться, что делает неправильно.
11. Если программист говорит о каком-то сторнировании - не слушайте его - вы не обязаны понимать компьютерную терминологию, смело исправляйте документы за три прошедших месяца - больше он с вами ругаться не будет - на него насядут те, чьи счета в результате ваших действий поменялись - так ведь они не ваши и вам на них наплевать.
12. Если хозяйственные операции проводятся в нарушение общепринятых правил - требуйте от программиста, чтобы он все переписал в соответствии с нарушениями, но чтобы отчетность была правильная - это его забота, как совместить две противоречащие вещи.
13. Если вы не знаете, как что-нибудь сделать в программе, потому что не представляете, как это делается в бухгалтерии, скажите, чтобы это сделал программист - зачем он тогда, если такие вещи не знает, приучите себя ничего не записывать, а если записали, тут же уничтожайте,- ваше дело на кнопки нажимать, вам работать надо, а не думать и бумажки писать.
14. Hикогда ничего не формулируйте точно. Hапример, если вам надо справочник субконто заполнить - говорите - "У меня счет не заполняется", но не разглашайте, в каком документе у вас возникло затруднение - программист балдеет, когда разгадывает такие шарады.
15. Если программист дает вам какие-нибудь печатные инструкции - тут же при нем выбросьте эти инструкции и скажите - "Это твое дело сделать, как надо объяснить, а инструкцию я читать не буду - я не тупая".
16. Если вы чего-то добились от программиста, и документ формируется нормально, то постарайтесь сразу же забыть правила его заполнения - программисту доставляет огромное удовольствие все объяснять по пятнадцать раз.
17. Если программист говорит, что проводка неправильная - все валите на корреспондирующий счет, тем более, что вы за него не отвечаете - вы же не можете ошибиться - ошибаются только программисты и другие бухгалтера.
18. Постарайтесь не ходить к программисту - кричите прямо из кабинета - пусть разминается.
19. Перед тем как задавать вопрос ни в коем случае не пытайтесь анализировать проблему - ни смотрите ни какую отчетность - программист на то и есть, чтобы отчетность правильная была, а то что документы неправильно оформлены, так это он же и виноват - неправильно написал.

(37) мдя. ок. допустим (0) именно такой разработчик - плохо понимающий предметную область, не умеющий внятно вести диалог с пользователем. и что теперь ? пойти его застрелить ? навесить на него ярлык "не повар" ?
ок. что дальше ? уволить его ? нанять другого ? обучить предметной области ?
любой из ответов это _ЧАСТЬ_СИСТЕМЫ управления процессом автоматизации.
А не нечто вне это системы. Конечно плохо, когда разработчик тупица, но увы это встречается не реже чем ситуация "юзер - тупица", а НАМНОГО ЧАЩЕ.
И с этим надо что то делать. В рамках _системы_, а не как бог на душу положит. Цель то наша в конце концов не заключается в том, чтобы провести атестацию девелопера, а в том, чтобы автоматизировать предприятие. Не находишь ? Именно поэтому я и говорю - что твой пост 25 является тупиковым, неконструктивным в рамках достижения поставленной цели.
Ибо сказать что такой то риск это плохо это ничего не сказать. Чем по сути 25 пост и является. Просто эмоциональным высказыванием, не имеющим никакого отношения к решению проблемы. Именно на этот пост ты получил от БТР совершенно адекватное замечание про сферических коней :)) Сколько раз еще нужно разжевывать ?

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

(34) panov_e@runa.ru
(36) "Болезнь" в основном заключается в том что после того как происходит обсуждения задачи между заказчиком и исполнителем они считают что достигли понимания, но после реализации оказывается что это не так. Другими словами из их беседы не ясны подводные камни и неясности и исполнитель их делает так как в голову взбредет а не так как хочет заказчик.
Иногда недопонимания возникают даже в том как каждый воспринимает некоторые бизнес-объекты.

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

(42) Все же попробуй обсуждение свести к рисованию на бумаге диалоговых окон программы и данных которые будут внесены в систему и выведены обратно. Очень многое прояснится. На самом деле 16 это законченая и самое главное - сбалансированная система, хотя и не единственная возможная :)))
Но 10 лет опыта в автоматизации все таки чего то стоят :))

2(43) Не согласен
"Когда заказчик дает тебе задание значит он уже знает предметную область, посему тебе её знать необязательно" - это не всегда так
"Знание предметной области безусловно плюс" - скорее необходимость
Я уж наслушался всякого такого, что если бы пошел это кодировать, то никому бы не было радостно

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

Благодарю DeusIrae за высланные материалы.

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

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

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

(54) Нет, я в разговорах с заказчико вообще не оперирую понятиями подчиненный справочник и т.д., если непонятно что он имеет ввиду или что-то имеет неоднозначный смысл - переспрашиваю.
=====================
Да, предлагаю застрелиться, из двустволки, чтобы сразу оба полушария.

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

2(55) Эти двое так увлеклись, что нас игнорируют :(
Слова типа "подиненный спр-к" можно выразить по-другому.....
Например, заказчик скажет: "хочу иметь набор чего-то для того-то вот так и так"
А пустографки тоже проходили, какие уж тут беседы на одном языке
Приходится иногда и ломать их разум и организовывать работу иначе

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

2(60) Пришли, плиз, документацию.... интересно же! Мыло в (51)

(60) Про "застрелиться" ты начал, я просто отSHOOTился, чтобы не отвечать на риторический вопрос, а не учитывать больной мозг в подобных вопросах я не могу. К тому же про тебя только в (53), да и то ради наглядного примера, так что не обижайтесь и не принимайте слова про больной мозг на свой счет, считайте что я сказал про себя. К тому же в этом не должно быть ничего обидного, просто очередной фактор.

2(65) Извиняюсь, два письма уже :) Я просто подумал, что не заметил :(
Это российское все? Но все равно полезно почитать
Спасибо
Тема интересная выдалась... сюда бы Нуралиева

2(68) Ну, он бы пояснил генеральную линию партии...
Кстати, бумажки 1С приветсвует, так что на каждое действие нужна бумажка, вплоть до сдвигания кнопки

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

2(70) Люди все разные... одни не поймут этого никогда (отчасти и потому, что не хотят засорять себе голову - дома муж, дети и т.п.)... а другие
Вот на старой работе была девушка - гл. бух. - молодец! Чуть ли кусками кода говорила :)

(42) Окей. Определяется ли перед беседой критерий проверки того, что значит "взаимопонимание"? Беседа ведется на конкретных связанных примерах или путем моделирования заказчиком отдельных фрагментных пожеланий?

(57) Одним из ярких черт _начинающих_ НЛПишников является
тотальное применение мета модели, употребление слов
типа _номинализация_, квантификатор, генерализация и
так далее и тому подобное и САМОЕ ОПАСНОЕ - ПОЛНОЕ,
ПОВТОРЯЮ ПОЛНЕЙШЕЕ ИГНОРИРОВАНИЕ РАППОРТА (Подстройки).
В профессиональных кругах это называют мета-издевательство :)
Подобные "герои" зачастую очень быстро разрушают контакты с
окружением и родственниками находясь на самом деле в некотором вакууме.
Со стороны это выглядит как тотальное непонимание простых вещей и
жуткое занудство. Особенно подобными страдают программеры, которые
считают что метамодель это "еще один язык программирования". :)
Лечится исключительно техниками Милтона Эриксона.

(73) У-хх... Я так не умею. "тотальное применение мета модели..."

Вот, когда то писал: http://metaprog.km.ru/uprpred/avtsysup/index.htm#_52