пара пакетов правок бесплатно, остальное за доплату - вариант с которым часто сталикавался в мск. Правки условно разделены на - мелкие, средние и крупные. В смете клиент выбирает вариант пакета (пример: 2 крупных, 3 средних, 4 мелких), там же внизу описание что такое средняя, крупная и мелкая правка. Все что свыше за под косты
Проблема такая: начинается проект, согласовывается общая структура сайта, потом дизайнер рисует макет, заказчик вносит правки чисто субъективные. И делается несколько макетов, вносятся правки, в общем такой омут. Правки зачастую делается субъективно, т.е что заказчику понравится, то и выбирают. Вопрос: как это решить?
Элементарно, товарищ!
Убедить грамотно заказчика в том, что нужно выбирать дизайн с точки зрения UX/UI, или как? Сейчас появилась возможность в разработке от начала до конца участвовать, не могу смотреть на то как затягивается все это.
Дорогой мой друг, ты вытянул счастливый билет, поэтому я хочу чтобы ты поступил так и только так на следующем проекте от начала и до конца.
Если твой процесс чуточку отличается от нижеследующего, возможно ты где-то да спотконешься и тебя затянет болото.
Удачи тебе в прохождении интересного пути!
Итак, процесс должен выглядеть следующим образом:
1. Формируется предмет договора.
Время - час-три. Одна встреча. Делать надо бесплатно (за свой счет это время).
Согласуется порядок целей и задач - все что клиент хочет от проекта, все что он вам излагает на первой встрече. Правила простые - все что говорит заказчик вы называете "целью", все что добавляете на схему вы (понимая что для этого нужно сделать это и это) вы называете "задача". Если у клиента есть матеиралы - не изучаете их "до встречи" а изучаете их во время встречи, об этом потом и отдельным вопросам если есть. Сейчас говорим о ситуации "без 120 страничного входящего PDF на оценку".
- Вы все записываете на визуальную схему, совместно. Проговаривая друг с другом. - называете все функции и продукты в каждой карточке (мобилка / бекенд / сайт = регистрация / авторизация / отправка писем). - расставляете между этими записями-карточками причинно следственные связи. - тратите сколько нужно время в рамках трех часов (за полтора часа обычной такой работы любой клиент физически "отключается"). Но делаете это одной встречей!
Вы должны принять совместное решение что на карте изложено все то, что хочет от продукта заказчик, а вы как специалист добавили на карту все то что он не знал но это надо будет сделать - показать все что скрыто, все тайное сделать явным.
Сделать в голове для себя оценку по бюджету и сроку (оценить можно в таком виде).
Сказать заклинание: "Все что указано на этой схеме, на основании моего технического опыта будет сделано мною (командой) в такой бюджет и в такие сроки."
Добавить к заклинанию: "Да, мы работаем по предоплате 30% от бюджета, но с фактической оплатой за полезный результат. Вы не оплачиваете часы, оплате подлежит только то, что вы себе полезного получаете от нас."
Добавялешь к заклинанию: "Да, все что написано на схеме - мною воспринимается как целостная картина проекта на который я назвал бюджет и срок. Добавление на схему новых данных или изменение текущих приведет к необходимости перерасчета бюджета".
Часто я тут сообщаю что я не совсем готов читать мысли, и если это не записано, то для меня этого нет. Ну и если человек говорит что он не знает что он может еще добавит, то говори - без проблем, конечно добавляй. (не надо два раза повторять что бюджет и срок изменится, ты уже это произнес). Держи процесс в руках.
Тут монтаж, но коротко - работать вам предстоит по элементному расчету, который доступен при детальном структурно-фукнциональной декомпозиции (делается это очень просто, предвкушая вопросы).
Ценообразование строится от полезной единицы. Одна единица - один полезный элемент. Расчет (замеры можно отдельно обсудил) из моей свежей таблички на фуллстек от компании - определенный, спроектированный, изготовленный, доставленный в приемку, задокументированный - ~300 рублей за элемент.
Ты проектируешь пошагово все сценарии по как будет работать продукт, нажимаю тут, открываю тут, вижу птичку синего цвета.
Это структурно функциональный анализ. Примеры документов конечно же могу дать.
Там должно быть зафиксировано четко - в каких местах каких продуктов какие должны быть элементы (наличие). Проектирование через сценарии использования "выявляют" для тебя все эти элементы.
На этом шаге один элемент - это один шаг сценария.
"На главной я нажав на синюю кнопку справа увидел попап с видосиком" - тут у тебя 1) продукт "Сайт", у него есть место 2) главная, на котором есть элементы 3) синяя кнопка; видеоролик;
Расчет грубый но достаточный для работы - 1 шаг, 300рублей.
Сколько ты напроектировал - такой бюджет на эту часть документации ты получил.
Бюджет должен быть "cписан" с предоплаты.
Полученную архитектуру можно у тебя забрать и пойти делать дальше с другими людьми.
Как объясняется что такие документы нужны в первую очередь клиенту, а не вам, вставляю текст из внутренней инструкции для моих аккаунт-менеджеров:
Успешным продуктом считается продукт который кто-то потребляет (использует) в своих целях, он для кого-то полезен. Для создания продукта выполняются целевые, результативные, продуктивные действия сотрудников компании (исполнителей). Что значит продуктивное действие? Во-первых, это то действие, результат которого учитывает другого: исполнитель что-то сделал, а кто-то другой (интересант) этим результатом воспользовался. В этом плане исполнитель производит результат, но он может не быть продуктом, им может никто не воспользоваться. Исполнитель действовал результативно с точки зрения своих намерений, целей и действий, но это никому не нужно. Но если этим кто-то воспользовался, то действие исполнителя становится продуктивным в первом смысле этого термина. Во-вторых, это то действие, результат которого может изменяться самим интересантом: если интересант осуществил некую пробу (обычно то, что получилось, не совпадает с тем, что он задумал), то он может отрефлектировать то, что получилось, сопоставить со своим замыслом и на следующем шаге запросить измененный результат действие. То есть действие по корректировке исполнителем продуктивно для него самого, потому что оно выявляет те расхождения, которые без этого действия он бы никогда не обнаружил. В-третьих, это то действие, которое создает время: повторяясь, оттачиваясь, обретая дополнительные характеристики искусности, в силу того, что человек учится в ходе выполнения действия, оно начинает экономить время. Как то время, которое нужно затратить для осуществления самого действия, так и чужое время, которое, если продукт исполнителя хорош, он не потратит на то, чтобы его ремонтировать, обслуживать или постоянно исправлять ошибки. И вот этот третий смысл не менее важен - продуктивное действие создает общественное время.
Обсуждать какие-то изменения сейчас и впредь вокруг продукта ты должен только "вокруг" этого документа.
Все изменения шагов этого документа фиксируются как новый шаг сценария.
На изготовление первичной архитектуры не понадобится больше недели, с моим трюком (об этом по желанию и не в этом каменте) - это делается за несколько часов.
На этом шаге ты получаешь такую фактуру:
Каждый шаг сценария теперь доступен для общей оценки, насколько ты "попадаешь в бюджет" и срок общей разработки.
Доставка одного элемента берется в пример на 20 минут (тут очень много всего заложено, поверь мне это хороший замер, тоже отдельно можно обсудить).
Итого показывая структурно-функциональную декомпозицию ты выдаешь точный срок и стоимость, сколько это будет стоит изготовить.
В указанном выше шаге в сумме вышло 4 элемента по 300 рублей и по 20 минут. Считай срок и стоимость.
Внимательно теперь, пайплайн твой же и как у всех не меняется.
1) UX дизайн элемента - раз 2) UI дизайн этого же элемента - еще раз 3) DEV+DEPLOY элемента - еще раз 4) TEST элемента - еще раз 5) Документация - еще раз
Сечешь о чем я? 5 по 300р. За каждое действие имеющее результат.
Что дальше?
Если нужно то вносятся правки в архитектуру одним путем:
- Клиент добавляет к каждому шагу комментарии, вы их фиксируете и вносите в документ. В счет добавляется почасовое время исполнение этой процедуры. - Вы вместе проектируя видите что не вылезаете за называнный бюджет. - Если клиент захочет много шагов, которые превышают бюджет - вы тут же ему это демонстрируете и говорите кто тут исполнитель и чья оценка. Любое изменение бюджета возможно, только по инициативе клиента.
Дальше согласуется Архитектура (подписывается и подшивается) вместе со сметой.
Либо клиент уходит от вас с результатом (архитектурой), вы возвращаете остаток от предоплаты (предоплата минус стоимость архитектуры) ему. Все в рамках баланса. Тут не бывает вопросов. Все ровненько.
В приложении к договору прописываете количество правок в каждый блок. Также описываете , что такое блок.
Убедить заказчика в том, как ему выбирать дизайн – плохая идея.
1. Либо просто ваш дизайнер не может сделать хорошо то, что хочет заказчик. 2. Либо заказчик в любом случае изгов***т все, что вы ему предложите независимо от того, сколько будет итераций и какое качество дизайна вы предложите. (такой риск есть, просто смиритесь).
В любом случае – грамотно составленный договор решит ваши проблемы (но отношения с заказчиками станут чуточку хуже)
Как у меня: на этапе отправки первого макета максимальная презентация: это кнопка здесь не от балды, а потому что согласно анализу ца и правилам юзабилити это максимально правильное место для нее (своими словами, но суть понятна, я думаю). Все эти элементы прописываем в дубликате макета, который клиент должен увидеть первым. Ну и прикладываем макеты без этих комментов. 2) в договоре указано кол-во итераций правок. В комменте выше уже написали подробно как это в выглядит в допнике.
пара пакетов правок бесплатно, остальное за доплату - вариант с которым часто сталикавался в мск. Правки условно разделены на - мелкие, средние и крупные. В смете клиент выбирает вариант пакета (пример: 2 крупных, 3 средних, 4 мелких), там же внизу описание что такое средняя, крупная и мелкая правка. Все что свыше за под косты
Проблема такая: начинается проект, согласовывается общая структура сайта, потом дизайнер рисует макет, заказчик вносит правки чисто субъективные. И делается несколько макетов, вносятся правки, в общем такой омут. Правки зачастую делается субъективно, т.е что заказчику понравится, то и выбирают. Вопрос: как это решить?
Элементарно, товарищ!
Убедить грамотно заказчика в том, что нужно выбирать дизайн с точки зрения UX/UI, или как? Сейчас появилась возможность в разработке от начала до конца участвовать, не могу смотреть на то как затягивается все это.
Дорогой мой друг, ты вытянул счастливый билет, поэтому я хочу чтобы ты поступил так и только так на следующем проекте от начала и до конца.
Если твой процесс чуточку отличается от нижеследующего, возможно ты где-то да спотконешься и тебя затянет болото.
Удачи тебе в прохождении интересного пути!
Итак, процесс должен выглядеть следующим образом:
1. Формируется предмет договора.
Время - час-три. Одна встреча. Делать надо бесплатно (за свой счет это время).
Согласуется порядок целей и задач - все что клиент хочет от проекта, все что он вам излагает на первой встрече. Правила простые - все что говорит заказчик вы называете "целью", все что добавляете на схему вы (понимая что для этого нужно сделать это и это) вы называете "задача". Если у клиента есть матеиралы - не изучаете их "до встречи" а изучаете их во время встречи, об этом потом и отдельным вопросам если есть. Сейчас говорим о ситуации "без 120 страничного входящего PDF на оценку".
- Вы все записываете на визуальную схему, совместно. Проговаривая друг с другом.
- называете все функции и продукты в каждой карточке (мобилка / бекенд / сайт = регистрация / авторизация / отправка писем).
- расставляете между этими записями-карточками причинно следственные связи.
- тратите сколько нужно время в рамках трех часов (за полтора часа обычной такой работы любой клиент физически "отключается"). Но делаете это одной встречей!
Вы должны принять совместное решение что на карте изложено все то, что хочет от продукта заказчик, а вы как специалист добавили на карту все то что он не знал но это надо будет сделать - показать все что скрыто, все тайное сделать явным.
Сделать в голове для себя оценку по бюджету и сроку (оценить можно в таком виде).
Сказать заклинание: "Все что указано на этой схеме, на основании моего технического опыта будет сделано мною (командой) в такой бюджет и в такие сроки."
Добавить к заклинанию: "Да, мы работаем по предоплате 30% от бюджета, но с фактической оплатой за полезный результат. Вы не оплачиваете часы, оплате подлежит только то, что вы себе полезного получаете от нас."
Добавялешь к заклинанию: "Да, все что написано на схеме - мною воспринимается как целостная картина проекта на который я назвал бюджет и срок. Добавление на схему новых данных или изменение текущих приведет к необходимости перерасчета бюджета".
Часто я тут сообщаю что я не совсем готов читать мысли, и если это не записано, то для меня этого нет. Ну и если человек говорит что он не знает что он может еще добавит, то говори - без проблем, конечно добавляй. (не надо два раза повторять что бюджет и срок изменится, ты уже это произнес). Держи процесс в руках.
Тут монтаж, но коротко - работать вам предстоит по элементному расчету, который доступен при детальном структурно-фукнциональной декомпозиции (делается это очень просто, предвкушая вопросы).
Ценообразование строится от полезной единицы. Одна единица - один полезный элемент. Расчет (замеры можно отдельно обсудил) из моей свежей таблички на фуллстек от компании - определенный, спроектированный, изготовленный, доставленный в приемку, задокументированный - ~300 рублей за элемент.
2. Архитектура.
Ты проектируешь пошагово все сценарии по как будет работать продукт, нажимаю тут, открываю тут, вижу птичку синего цвета.
Это структурно функциональный анализ. Примеры документов конечно же могу дать.
Там должно быть зафиксировано четко - в каких местах каких продуктов какие должны быть элементы (наличие). Проектирование через сценарии использования "выявляют" для тебя все эти элементы.
На этом шаге один элемент - это один шаг сценария.
"На главной я нажав на синюю кнопку справа увидел попап с видосиком" - тут у тебя 1) продукт "Сайт", у него есть место 2) главная, на котором есть элементы 3) синяя кнопка; видеоролик;
Расчет грубый но достаточный для работы - 1 шаг, 300рублей.
Сколько ты напроектировал - такой бюджет на эту часть документации ты получил.
Бюджет должен быть "cписан" с предоплаты.
Полученную архитектуру можно у тебя забрать и пойти делать дальше с другими людьми.
Как объясняется что такие документы нужны в первую очередь клиенту, а не вам, вставляю текст из внутренней инструкции для моих аккаунт-менеджеров:
Успешным продуктом считается продукт который кто-то потребляет (использует) в своих целях, он для кого-то полезен. Для создания продукта выполняются целевые, результативные, продуктивные действия сотрудников компании (исполнителей). Что значит продуктивное действие? Во-первых, это то действие, результат которого учитывает другого: исполнитель что-то сделал, а кто-то другой (интересант) этим результатом воспользовался. В этом плане исполнитель производит результат, но он может не быть продуктом, им может никто не воспользоваться. Исполнитель действовал результативно с точки зрения своих намерений, целей и действий, но это никому не нужно. Но если этим кто-то воспользовался, то действие исполнителя становится продуктивным в первом смысле этого термина. Во-вторых, это то действие, результат которого может изменяться самим интересантом: если интересант осуществил некую пробу (обычно то, что получилось, не совпадает с тем, что он задумал), то он может отрефлектировать то, что получилось, сопоставить со своим замыслом и на следующем шаге запросить измененный результат действие. То есть действие по корректировке исполнителем продуктивно для него самого, потому что оно выявляет те расхождения, которые без этого действия он бы никогда не обнаружил. В-третьих, это то действие, которое создает время: повторяясь, оттачиваясь, обретая дополнительные характеристики искусности, в силу того, что человек учится в ходе выполнения действия, оно начинает экономить время. Как то время, которое нужно затратить для осуществления самого действия, так и чужое время, которое, если продукт исполнителя хорош, он не потратит на то, чтобы его ремонтировать, обслуживать или постоянно исправлять ошибки. И вот этот третий смысл не менее важен - продуктивное действие создает общественное время.
Обсуждать какие-то изменения сейчас и впредь вокруг продукта ты должен только "вокруг" этого документа.
Все изменения шагов этого документа фиксируются как новый шаг сценария.
На изготовление первичной архитектуры не понадобится больше недели, с моим трюком (об этом по желанию и не в этом каменте) - это делается за несколько часов.
На этом шаге ты получаешь такую фактуру:
Каждый шаг сценария теперь доступен для общей оценки, насколько ты "попадаешь в бюджет" и срок общей разработки.
Доставка одного элемента берется в пример на 20 минут (тут очень много всего заложено, поверь мне это хороший замер, тоже отдельно можно обсудить).
Итого показывая структурно-функциональную декомпозицию ты выдаешь точный срок и стоимость, сколько это будет стоит изготовить.
В указанном выше шаге в сумме вышло 4 элемента по 300 рублей и по 20 минут. Считай срок и стоимость.
Внимательно теперь, пайплайн твой же и как у всех не меняется.
1) UX дизайн элемента - раз
2) UI дизайн этого же элемента - еще раз
3) DEV+DEPLOY элемента - еще раз
4) TEST элемента - еще раз
5) Документация - еще раз
Сечешь о чем я? 5 по 300р. За каждое действие имеющее результат.
Что дальше?
Если нужно то вносятся правки в архитектуру одним путем:
- Клиент добавляет к каждому шагу комментарии, вы их фиксируете и вносите в документ. В счет добавляется почасовое время исполнение этой процедуры.
- Вы вместе проектируя видите что не вылезаете за называнный бюджет.
- Если клиент захочет много шагов, которые превышают бюджет - вы тут же ему это демонстрируете и говорите кто тут исполнитель и чья оценка. Любое изменение бюджета возможно, только по инициативе клиента.
Дальше согласуется Архитектура (подписывается и подшивается) вместе со сметой.
Либо клиент уходит от вас с результатом (архитектурой), вы возвращаете остаток от предоплаты (предоплата минус стоимость архитектуры) ему. Все в рамках баланса. Тут не бывает вопросов. Все ровненько.
Комментарий недоступен
В приложении к договору прописываете количество правок в каждый блок. Также описываете , что такое блок.
Убедить заказчика в том, как ему выбирать дизайн – плохая идея.
1. Либо просто ваш дизайнер не может сделать хорошо то, что хочет заказчик.
2. Либо заказчик в любом случае изгов***т все, что вы ему предложите независимо от того, сколько будет итераций и какое качество дизайна вы предложите. (такой риск есть, просто смиритесь).
В любом случае – грамотно составленный договор решит ваши проблемы (но отношения с заказчиками станут чуточку хуже)
Комментарий недоступен
Как у меня: на этапе отправки первого макета максимальная презентация: это кнопка здесь не от балды, а потому что согласно анализу ца и правилам юзабилити это максимально правильное место для нее (своими словами, но суть понятна, я думаю). Все эти элементы прописываем в дубликате макета, который клиент должен увидеть первым. Ну и прикладываем макеты без этих комментов. 2) в договоре указано кол-во итераций правок. В комменте выше уже написали подробно как это в выглядит в допнике.