Все это верно ровно до тех пор, пока не звучит фраза "выбираем-то мы между несколькими компаниями с похожей ценой, а у вас получается 18% потерь". Вполне может стать камнем преткновения.
Тактильные ощущения при использовании устройств для Apple всегда имели значения. Именно поэтому логично предполагать что Аймак Мини действительно выйдет в свет.
А что является проектированием в ПО и ИС, спецификации? А ТЗ уже более конкретно описывает как именно интерфейсно будут выполняться вещи, описанные в спецификации?
Ну дак как быть с изменением приоритетов-то? Большая часть диалога с вашей стороны лично мной была понята как "мы не реагируем на изменение требований в процессе работы над длинным проектом". Если я понял не верно — давайте просто сойдемся что я был невнимателен либо вы не очень точны и закончим бессмысленный диалог. Похоже все-таки наши точки зрения больше схожи чем различны.
Может быть мы говорим вот о чем. Факт номер 1: любое изменение ТЗ в процессе работы над ним вносит зачастую непреодолимый разлад в работу над проектом. Факт номер 2: большие проекты на практике подразумевают изменяющиеся требования, предугадать так это или нет практически нереально. Вывод: нет смысла описывать ТЗ на весь проект, имеет смысл писать ТЗ на конкретные участки работ, при этом, не допуская никаких изменений в ТЗ поскольку нормальный ход работ более ценен чем незначительная сумма "переработки" за которую заплатит заказчик.
Если мы оба об этом, то вы не были поняты сразу, но теперь взаимопонимание налаживается :)
У нас ТЗ + концепция дизайна (т.е. дизайн без имиджевых частей, вместо которых вставляются эскизы либо клипарты) это тоже один этап. Теперь понятно о чем вы (когда говорилось "проектирование" было неясно).
Разговор идет о том, что пункт 1 на практике очень часто оказывается пунктом 2. Если ваш опыт в крупных проектах показывает что это не так, значит вы на удивление везучий человек.
Интересно, как вы с таким подходом справляетесь с ситуациями, подобными этой: цена проекта $100 тыс. Сделана половина. От второй половины заказчик хочет отказаться (модуль оцененный в половину проекта потерял актуальность, т.к. нашли готовый инструмент для этих целей). Задача ставится так: написать (небольшой по объему работ) модуль интеграции нового (стороннего инструмента) с разрабатываемой (готовой, по сути) системой. Осмелюсь предположить, что ничего приятного в ответ на предложение сначала завершить разработку в рамках ТЗ вы от заказчика не получите.
Было неочевидно, что дизайн входит в проектирование. В моем понимание это далеко не всегда так, поскольку в дизайне могут встречаться достаточно трудоемкие вещи, непосредственно к проектированию отношения не имеющие.
Какая работа? "Реализация"? Т.е. и программирование и верстка и все-все-все считается выполненной?
Если да, то почти 100% пункт про "деньги не возвращаются" противоречит действующему законодательству.
В таких случаях, обычно, верят на слово все-таки. Т.е. начинают работу после поступившей оплаты и фразы "мы отправили, вот копия факсом". Иногда из-за этого приходится останавливать начатую работу, но других вариантов я не знаю.
ЗЫ: хоть вопрос и не ко мне, но рассказал как делается у нас.
Ну т.е. вы, готовя ТЗ, сразу оговариваете, что ТЗ сделано не на весь проект, а только на его часть. Краткосрочную и не подлежащую изменениям. Именно об этом вам и говорят: на весь проект сразу ТЗ не сделать. Факт. А как уж быть конкретно, называть это "I, II очереди" либо "еженедельные сборки" — вопрос конкретного проекта и удобства\навыков работы команды в рамках конкретных методологий.
Что делать? Ждать оплаты. В конечном счете, оперируя сухими фактами это проблема исключительно заказчика.
В жизни, конечно, все сложнее и бывают нюансы: степень доверия, срок отношений, платили ли вовремя ранее, загруженность людей (т.е. ситуация "либо делаем неоплаченное либо балду пинаем") и т.п.
Щебенку не продаем, ага.
Может быть мы говорим вот о чем. Факт номер 1: любое изменение ТЗ в процессе работы над ним вносит зачастую непреодолимый разлад в работу над проектом. Факт номер 2: большие проекты на практике подразумевают изменяющиеся требования, предугадать так это или нет практически нереально. Вывод: нет смысла описывать ТЗ на весь проект, имеет смысл писать ТЗ на конкретные участки работ, при этом, не допуская никаких изменений в ТЗ поскольку нормальный ход работ более ценен чем незначительная сумма "переработки" за которую заплатит заказчик.
Если мы оба об этом, то вы не были поняты сразу, но теперь взаимопонимание налаживается :)
Интересно, как вы с таким подходом справляетесь с ситуациями, подобными этой: цена проекта $100 тыс. Сделана половина. От второй половины заказчик хочет отказаться (модуль оцененный в половину проекта потерял актуальность, т.к. нашли готовый инструмент для этих целей). Задача ставится так: написать (небольшой по объему работ) модуль интеграции нового (стороннего инструмента) с разрабатываемой (готовой, по сути) системой. Осмелюсь предположить, что ничего приятного в ответ на предложение сначала завершить разработку в рамках ТЗ вы от заказчика не получите.
Если да, то почти 100% пункт про "деньги не возвращаются" противоречит действующему законодательству.
ЗЫ: хоть вопрос и не ко мне, но рассказал как делается у нас.
В жизни, конечно, все сложнее и бывают нюансы: степень доверия, срок отношений, платили ли вовремя ранее, загруженность людей (т.е. ситуация "либо делаем неоплаченное либо балду пинаем") и т.п.