Bogdanov Andrey PL99Пока нет ТЗ просто разговаривать не о чем.

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

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

Bogdanov AndreyА получив готовый продукт быстро понимает, что технолоигю можно и нужно изменить.В какой момент возникает "готовый продукт"? Каким документом регламентируется, что и Вы, и заказчик понимают пож этим словосочетанием одно и тоже?

Bogdanov AndreyИ наоборот я видел немало примеров, когда написание ТЗ приводило либо к полному параличу процесса, либо к выпуску совершенно негодного продукта. Мы же сейчас не обсуждаем квалификацию конкретных аналитиков.

Bogdanov AndreyПричем обвинить кого-то в "умышленном" вредительстве было нельзя - все хорошо исполняли свою работу.

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

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

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

Bogdanov AndreyНо я к сожалению, достаточно часто сталкиваюсь с тем, что процедура согласования ТЗ (а при измнении ТЗ требуется согласование) настолько "геморройна", что разработчики вынуждены плюнуть на очевидные возможные улучшения и писать "по ТЗ".Гм... Разработчики, IMHO, не должны инициировать изменения в согласованной документации.

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

No_ТЗСчастливые вы. Вам хотя бы есть , что обсуждать. Я, вот,
например, вообще всю жизнь без ТЗ работаю, по 10 раз
программы переписываю, и ничего.

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

mcureenab PL99Разработчики, IMHO, не должны инициировать изменения в согласованной документации.

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

mcureenabПроктологические заболевания каждый лечит как может.:-)

Bogdanov Andrey PL99Вероятно мы с Вами по разному понимаем понятие "эффективность". Для меня это разработка большего количества функционала, требуемого заказчику, за меньшее время. Какой именно функционал следует разрабатывать определяется в ТЗ.

Bogdanov AndreyДля меня эффективность это удовлетворение потребностей заказчика в автоматизации за минимальное время. А перечень потребностей заказчика Вы, вероятно, определяете телепатически.

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

Bogdanov Andrey Bogdanov AndreyНо на самом деле программа может оказаться даже более адекватной, PL99А может и не оказаться.
Bogdanov AndreyМожет и не оказаться. Ровно также как и в случае когда есть ТЗ.Только вот в случае с ТЗ адекватность программы можно оценить, сравнивая то, что получилось с тем, что было запланировано. А как Вы это делаете без ТЗ?

Bogdanov Andrey PL99В какой момент возникает "готовый продукт"? Каким документом регламентируется, что и Вы, и заказчик понимают пож этим словосочетанием одно и тоже?
Этот документ называется "Акт о приемке в промышленную эксплуатацию".Это немного не в ту степь. Подобный документ подтверждает то, что заказчик принял разработанную программу и несет обязательства по окончательным расчетам с разработчиком. Я рядом веду вялотекущую дисскуссию о том, что подобный документ при вменяемом менеджменте со стороны исполнителя будет подписан заказчиком всегда. А вот обоснованием для принятия решения о готовности продукта к приемке в промышленную эксплуатацию служит соответствие разработанного софта тем требованиям, которые описаны в ТЗ.

Bogdanov AndreyЗначит мне еще ни разу (из тех трех-четырех десятков ТЗ, с которыми я работал) не попадалось хороших аналитиков.Гм... Мой опыт разработки учетного софта позволяет сделать некоторые прикидки. На первичную проработку требований уходит от одного до трех месяцев. На написание и согласование ТЗ еще один-два месяца. Разработка по ТЗ редко занимает меньше полугода. Еще некоторое время уходит на внедрение и опытную эксплуатацию. IMHO, один проект занимает около одного календарного года. Вам уже под 60?

Bogdanov AndreyМожет быть хороших в природе не существует?Существуют, я лично знаком с несколькими :-)

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

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

Bogdanov AndreyИ опять вы плохо прочитали мои предыдущие высказывания. Я как раз и писал, что ТЗ может быть очень полезно если стоит задача получить деньги с заказчика, несмотря на то, что итоговый продукт его не устраивает.Нет, как раз этот Ваш тезис я прекрасно запомнил.
Формализую вопросы к Вам. По каким критериям Вы определяете, устраивает заказчика итоговый продукт или нет? Как разрешаются спорные моменты? Заказчик расплачивается с Вами по завершению работ или как-то иначе?

Bogdanov Andrey Но задача получения денег и задача написания качественного продукта - две большие разницы.Ваше понимание качественного продукта я уяснил по примеру с самолетами. Но, к сожалению, я не могу себе позволить подобные упражнения. Могу только порадоваться за Вас, раз Вы можете позволить себе заниматься rocket science за счет заказчика.


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

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

Bogdanov AndreyЯ активно участвовал примерно в десятке проектов с объемом работ, похожим на то что описываете вы. Из них в 4 случаях могу с уверенностью сказать, что имелось ТЗ. В остальных случаях подобных документов не помню. Из этих четырех только один завершился успешно с небольшой задержкой по сроку. В случаях же когда ТЗ не бло успешный исход был гораздо более частым. По крайней мере пять проектов в которых я участвовал как "отец-основатель" успешно продолжают радовать пользователей уже несколько лет.Ок. Нарисуйте красивую девушку

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