Статья удалена

Этот материал был удалён по просьбе автора.

0
15 комментариев
Написать комментарий...
Александр Фудин

пара пакетов правок бесплатно, остальное за доплату - вариант с которым часто сталикавался в мск. Правки условно разделены на - мелкие, средние и крупные. В смете клиент выбирает вариант пакета (пример: 2 крупных, 3 средних, 4 мелких), там же внизу описание что такое средняя, крупная и мелкая правка. Все что свыше за под косты

Ответить
Развернуть ветку
Alexander Pavlyut
Проблема такая: начинается проект, согласовывается общая структура сайта, потом дизайнер рисует макет, заказчик вносит правки чисто субъективные. И делается несколько макетов, вносятся правки, в общем такой омут. Правки зачастую делается субъективно, т.е что заказчику понравится, то и выбирают.
Вопрос: как это решить?

Элементарно, товарищ!

Убедить грамотно заказчика в том, что нужно выбирать дизайн с точки зрения UX/UI, или как? Сейчас появилась возможность в разработке от начала до конца участвовать, не могу смотреть на то как затягивается все это.

Дорогой мой друг, ты вытянул счастливый билет, поэтому я хочу чтобы ты поступил так и только так на следующем проекте от начала и до конца.

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

Удачи тебе в прохождении интересного пути!

Итак, процесс должен выглядеть следующим образом:

1. Формируется предмет договора.

Время - час-три. Одна встреча. Делать надо бесплатно (за свой счет это время).

Согласуется порядок целей и задач - все что клиент хочет от проекта, все что он вам излагает на первой встрече.
Правила простые - все что говорит заказчик вы называете "целью", все что добавляете на схему вы (понимая что для этого нужно сделать это и это) вы называете "задача".
Если у клиента есть матеиралы - не изучаете их "до встречи" а изучаете их во время встречи, об этом потом и отдельным вопросам если есть. Сейчас говорим о ситуации "без 120 страничного входящего PDF на оценку".

- Вы все записываете на визуальную схему, совместно. Проговаривая друг с другом.
- называете все функции и продукты в каждой карточке (мобилка / бекенд / сайт = регистрация / авторизация / отправка писем).
- расставляете между этими записями-карточками причинно следственные связи.
- тратите сколько нужно время в рамках трех часов (за полтора часа обычной такой работы любой клиент физически "отключается"). Но делаете это одной встречей!

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

Сделать в голове для себя оценку по бюджету и сроку (оценить можно в таком виде).

Сказать заклинание: "Все что указано на этой схеме, на основании моего технического опыта будет сделано мною (командой) в такой бюджет и в такие сроки."

Добавить к заклинанию: "Да, мы работаем по предоплате 30% от бюджета, но с фактической оплатой за полезный результат. Вы не оплачиваете часы, оплате подлежит только то, что вы себе полезного получаете от нас."

Добавялешь к заклинанию: "Да, все что написано на схеме - мною воспринимается как целостная картина проекта на который я назвал бюджет и срок. Добавление на схему новых данных или изменение текущих приведет к необходимости перерасчета бюджета".

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

Тут монтаж, но коротко - работать вам предстоит по элементному расчету, который доступен при детальном структурно-фукнциональной декомпозиции (делается это очень просто, предвкушая вопросы).

Ценообразование строится от полезной единицы. Одна единица - один полезный элемент. Расчет (замеры можно отдельно обсудил) из моей свежей таблички на фуллстек от компании - определенный, спроектированный, изготовленный, доставленный в приемку, задокументированный - ~300 рублей за элемент.

Ответить
Развернуть ветку
Alexander Pavlyut

2. Архитектура.

Ты проектируешь пошагово все сценарии по как будет работать продукт, нажимаю тут, открываю тут, вижу птичку синего цвета.

Это структурно функциональный анализ. Примеры документов конечно же могу дать.

Там должно быть зафиксировано четко - в каких местах каких продуктов какие должны быть элементы (наличие). Проектирование через сценарии использования "выявляют" для тебя все эти элементы.

На этом шаге один элемент - это один шаг сценария.

"На главной я нажав на синюю кнопку справа увидел попап с видосиком" - тут у тебя 1) продукт "Сайт", у него есть место 2) главная, на котором есть элементы 3) синяя кнопка; видеоролик;

Расчет грубый но достаточный для работы - 1 шаг, 300рублей.

Сколько ты напроектировал - такой бюджет на эту часть документации ты получил.

Бюджет должен быть "cписан" с предоплаты.

Полученную архитектуру можно у тебя забрать и пойти делать дальше с другими людьми.

Как объясняется что такие документы нужны в первую очередь клиенту, а не вам, вставляю текст из внутренней инструкции для моих аккаунт-менеджеров:

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

Обсуждать какие-то изменения сейчас и впредь вокруг продукта ты должен только "вокруг" этого документа.

Все изменения шагов этого документа фиксируются как новый шаг сценария.

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

На этом шаге ты получаешь такую фактуру:

Каждый шаг сценария теперь доступен для общей оценки, насколько ты "попадаешь в бюджет" и срок общей разработки.

Доставка одного элемента берется в пример на 20 минут (тут очень много всего заложено, поверь мне это хороший замер, тоже отдельно можно обсудить).

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

В указанном выше шаге в сумме вышло 4 элемента по 300 рублей и по 20 минут. Считай срок и стоимость.

Внимательно теперь, пайплайн твой же и как у всех не меняется.

1) UX дизайн элемента - раз
2) UI дизайн этого же элемента - еще раз
3) DEV+DEPLOY элемента - еще раз
4) TEST элемента - еще раз
5) Документация - еще раз

Сечешь о чем я? 5 по 300р. За каждое действие имеющее результат.

Что дальше?

Если нужно то вносятся правки в архитектуру одним путем:

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

Дальше согласуется Архитектура (подписывается и подшивается) вместе со сметой.

Либо клиент уходит от вас с результатом (архитектурой), вы возвращаете остаток от предоплаты (предоплата минус стоимость архитектуры) ему. Все в рамках баланса. Тут не бывает вопросов. Все ровненько.

Ответить
Развернуть ветку
Alexander Pavlyut

3. Изготовление.

После того как у тебя есть согласованная архитектура и структура, ты занимаешься производством по каждому процессу.

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

1. UX - элементы на каждом "месте" с композицией и описью
2. UI - тоже макет + опись
3. DEV - это комит в репу + автотесты (строго по сценарию) + деплой.
4. TEST - отметка тестировщика что эти все вот шаги работают, все элементы есть и ведут как задумано (никакой отсебятины что он увидел и решил что будет лучше). Ну и отчет о фактических багах (это чтобы завершить работу исправив баги).
5. Документация - человеческим языком, рерайт сценария для потребителя.

Все это подлежит приемке, если изготовлено в соответствии с архитектурой. Если есть несоответствия - от принимающего протокол с указаниями на несоответствия.

Для этого важен ваш шаг тестирования/проверки чтобы сдавать готовую работу.

4. Изменения.

Работая по данному порядку ты не страхуешься от того что будет поток правок или изменений. Более того ты особо не страхуешься, потому что работать все равно тебе, и сам порядок никак не отменяет того что исполнять работу нужно грамотно, нужно делать хорошие решения, стабильные, код или дизайн должны быть вменяемыми и тд. Процесс это ни разу не регулирует.

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

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

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

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

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

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

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

И в нашей сфере это очень сильно влияет и доставляет проблем, если за этим не следить.

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

Удачи братан!

Ответить
Развернуть ветку
Аккаунт удален
Автор

Комментарий недоступен

Ответить
Развернуть ветку
Alexander Pavlyut

У меня тут на vc есть три публикации - глянь в профиле недавнюю.

Можешь ее изучить и оттуда уже двигаться по интересующим ресурсам.

Ответить
Развернуть ветку
Аккаунт удален
Автор

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Богдан Сулагаев

В приложении к договору прописываете количество правок в каждый блок. Также описываете , что такое блок.

Убедить заказчика в том, как ему выбирать дизайн – плохая идея.

1. Либо просто ваш дизайнер не может сделать хорошо то, что хочет заказчик.
2. Либо заказчик в любом случае изгов***т все, что вы ему предложите независимо от того, сколько будет итераций и какое качество дизайна вы предложите. (такой риск есть, просто смиритесь).

В любом случае – грамотно составленный договор решит ваши проблемы (но отношения с заказчиками станут чуточку хуже)

Ответить
Развернуть ветку
Аккаунт удален
Автор

Комментарий недоступен

Ответить
Развернуть ветку
Лилия Новикова

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

Ответить
Развернуть ветку
Аккаунт удален
Автор

Комментарий недоступен

Ответить
Развернуть ветку
Лилия Новикова

Я считаю очень плохой идеей ныть клиенту - у вас уже много правок! Это за пределами разумного. (Даже если объективно вы правы, но клиенту пофиг на это по-большому счету).
Нужно составить договор один раз, прописав подробно про правки и юзать его.

Ответить
Развернуть ветку
Аккаунт удален
Автор

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
12 комментариев
Раскрывать всегда