И не надо Alexsas'у минусы ставить - он дал абсолютно достойный ответ на поставленный вопрос. Alexsas, поддерживаю! То, что кто-то редко вводит даты, не означает, что поля ввода должны быть убогими, как во многих продуктах и UI компонетах.
В основном мы сами позволяем заказчику так вести переговоры. Просто из-за утвердившейся мысли - кто платит - то и правит бал. Но стоит только вспомнить о том, (это полное ИМХО) что ни одна зарплата/гонорар в мире не стоит моего личного времени - сразу же возникает вопрос о том, кто кому еще одолжение делает? И как-то становится легче на переговорах оперировать вполне конкретным объемом работ за конкретную сумму.
Да, конечно Вы не можете быть 100% защищены от "непроходимых" заказчиков. Но как правило они очень хорошо понимают, что такое контракт/договор. Поэтому, если он меняет всё в последний момент, но в договоре прописанна стоимость такого изменения - это же Вам только на руку - вы получили дополнительный заказ :)
Я так понимаю. что вся проблема как раз в том, что бы довести заказчика до подписания договора с прописанной ценой. Главное помнить - до этого момента он может городить любую чушь про (очень понравилось) "Я уверен, Вы можете включить бассейн в Ваш дизайн без каких-либо изменений в смете.". Можно просто улыбаться ему и очень вежливо настаивать на том, что смета - результат анализа дизайна в плоскости человеко-часов и других затрат. Повторять это 20-30-40 раз, пока заказчику станет просто неудобно в очередной раз поднимать этот вопрос.
Я лично выставляю смету как раз ПО типовому или разработанному для конкретного случая дизану (в данном случае он стоит денег, назначается как чать работ и имеет свой собственный "мини"-договор.). Но никак не перед. Выставляю - имеется ввиду то, что прописывается в договор. Опять же - до этого момента в вашем общении могут называться совершенно разные суммы - это имеет только "прикидочное" значение.
Да вроде не так :)
Мне кажется, что заказчик не(!) должен быть профессионалом (во всяком случае не обязан, т.к. удобно это нам или нет - он профи в своем бизнесе). Часто он ведь оказывается почти всегда в положении "перед пустым прилавком" - вы скажите чего вы хотите, а мы вам это достанем. Но если ему дать из чего выбрать - разговор пойдет проще. Дайте портфолио с 2-мя десятками работ - и просто укажите стоимость. При таком подходе есть что пощупать, и понять - за что берется дополнительная оплата, и куда (и почему) растёт бюджет проекта.
С одной стороны разработчики безусловно правы - вся работа должна оплачиваться, и "несколько вариантов" не исключение.
С другой стороны - заказчик не должен оплачивать обучение разработчиков, их эксперименты.
Как в случае "большого стола" решить проблему митингов и телефонных конференций? Во-первых - это часто шумно. Во-вторых они содержат часто конфиденциальную информацию.
Если у Вас американский босс - он всем заказчикам конторы будет говорить, что Вы в состоянии сделать это. Даже если он не понимает - что именно сделать. По моим наблюдениям у них такая культура ведения бизнеса.
Просто они как-то мысляд индуктивно. Т.е. вот мы что-то делаем, и тут по ходу дела появилась какая-то призрачная перспектива, но надо для нее 20% кода перелопатить - и так и выходит - очередной ближайший статус-митинг, .... и: "Ув. разработчики, мы приняли решение добавить в нашу систему еще и подсистему управления шаттлом....".
А еще на следующем митингей они-с идеей перегорели-с, и все - подсистема управления шаттлом работает только на 20% но все-равно будет включена в релиз - не выкадывать же ее!
Вы бесспорно правы! Но - есть один нюанс :)
Мне показалось, что ценность данной книги как раз в том, что в ней "банальные истины" сформулированны в предложения и записанны на бумаге. Это очень приятно.
Ты читаешь книгу и думаешь - ёлы-палы - да я же знаю это и так, без всякого Купера. Однако, я так много всего знаю о "простых правилах" "создания юзабилити", что никак не могу вспомнить - что же именно я знаю. И в своей повседневной работе я эти правила не использую, потому, что зная их я их не помню или не могу сформулировать.
Я когда читал эту книгу (в электронном виде) - сделал себе реферативную "шпору" из ее содержания - >150-ти страниц превратил в 12 страниц основной сути, избавив книгу от литературных оборотов - теперь ее можно быстро перечитывать хоть каждый день и вбивать себе некоторые вещи в привычку.
Все выше описанное по-моему есть различие между подходом к образованию запада и востока. В конечном итоге это приводит к сасому основному отличию - массовость обучения на западе и индивидуальность на востоке. Хотя стоит заметить, что так или иначе в последние 10-15 лет начала происходить некоторая диффузия этих двух подходов.
Спасибо за информацию. Я не видел никогда подобного. Покажу завтра своим босам-пендосам (фром юэса), которые никак не могут научится тому, что свет и воду за собой нужно выключать, а выкидывать из холодильника салат только потому, что он вчерашний - (не)много глупо.
Я так понимаю. что вся проблема как раз в том, что бы довести заказчика до подписания договора с прописанной ценой. Главное помнить - до этого момента он может городить любую чушь про (очень понравилось) "Я уверен, Вы можете включить бассейн в Ваш дизайн без каких-либо изменений в смете.". Можно просто улыбаться ему и очень вежливо настаивать на том, что смета - результат анализа дизайна в плоскости человеко-часов и других затрат. Повторять это 20-30-40 раз, пока заказчику станет просто неудобно в очередной раз поднимать этот вопрос.
Я лично выставляю смету как раз ПО типовому или разработанному для конкретного случая дизану (в данном случае он стоит денег, назначается как чать работ и имеет свой собственный "мини"-договор.). Но никак не перед. Выставляю - имеется ввиду то, что прописывается в договор. Опять же - до этого момента в вашем общении могут называться совершенно разные суммы - это имеет только "прикидочное" значение.
Мне кажется, что заказчик не(!) должен быть профессионалом (во всяком случае не обязан, т.к. удобно это нам или нет - он профи в своем бизнесе). Часто он ведь оказывается почти всегда в положении "перед пустым прилавком" - вы скажите чего вы хотите, а мы вам это достанем. Но если ему дать из чего выбрать - разговор пойдет проще. Дайте портфолио с 2-мя десятками работ - и просто укажите стоимость. При таком подходе есть что пощупать, и понять - за что берется дополнительная оплата, и куда (и почему) растёт бюджет проекта.
С одной стороны разработчики безусловно правы - вся работа должна оплачиваться, и "несколько вариантов" не исключение.
С другой стороны - заказчик не должен оплачивать обучение разработчиков, их эксперименты.
А еще на следующем митингей они-с идеей перегорели-с, и все - подсистема управления шаттлом работает только на 20% но все-равно будет включена в релиз - не выкадывать же ее!
Вобщем-то правильно говорит. Стоит просто прислушаться и частенько себе повторять. ИМХО
Мне показалось, что ценность данной книги как раз в том, что в ней "банальные истины" сформулированны в предложения и записанны на бумаге. Это очень приятно.
Ты читаешь книгу и думаешь - ёлы-палы - да я же знаю это и так, без всякого Купера. Однако, я так много всего знаю о "простых правилах" "создания юзабилити", что никак не могу вспомнить - что же именно я знаю. И в своей повседневной работе я эти правила не использую, потому, что зная их я их не помню или не могу сформулировать.
Я когда читал эту книгу (в электронном виде) - сделал себе реферативную "шпору" из ее содержания - >150-ти страниц превратил в 12 страниц основной сути, избавив книгу от литературных оборотов - теперь ее можно быстро перечитывать хоть каждый день и вбивать себе некоторые вещи в привычку.
Где-то так :)