Pull to refresh

Comments 12

Если сделать изумительный сервис по работе с клиентами, можно ли немного начинать удовлетворять амбиции?
Ну, если сервис реально изумительный, то можно, конечно — клиенты простят любые интерфейсные навороты ))
Любой-любой интерфейсный наворот — есть нарушение Вашего дао.
Не ловите меня на слове :)
У меня в статье нарисован роскошный айсберг, поясняющий место спецэффектов в процессе создания сайта. Если Вы успешно прошли все предыдущие этапы — велкам к наворотам, если других проблем реально нет.
Здравствуйте!
Согласен с Вами. При общении с заказчиком необходимо погружаться в его бизнес, анализировать сайты конкурентов и предлагать свои идеи, которые уже опробованы и доказали не только работоспособность, но и эффективность и универсальность.

Так же согласен, что качественный и эффективный продукт — не обязательно сложный и «навороченный». Все технологические приблуды включить невозможно, да и не нужно зачастую. Их обилие перегружает проект и делает его непригодным для работы пользователя: увеличиваются отказы и падает конверсия.
Однако вопрос: если я всё правильно понял, поясните пожалуйста основной мессадж статьи? Какова её цель и ожидаемый Вами результат?
Заранее спасибо!
Месседж статьи прост: не надо забывать то, ради чего всё. Если мы делаем сайт, надо понять, какие задачи он решает, а не снимать с себя ответственность за результат, кивая на пункты ТЗ и доказывая заказчику, что он сам дурак.

А результат, который я ожидаю — дискуссия в комментах. Ну, и, судя по всему, минуса в карму от наиболее продвинутых юзеров Хабра, которые не хотят натыкаться на всем давно понятные простые истины ))
Для человека, который работает соло — это трудно выполнимо местами, но для команды разработчиков, имхо, вышенаписанное — обязательный пункт.
Соло (как минимум — без Вуки и «Тысячелетнего Сокола») никогда не сделаешь большой проект хорошо — не хватит знаний в предметной области. А в командах разработчиков очень часто бытует то, о чём я выше написал — «проект не взлетел, потому что заказчик дебил», хотя стоило бы потратить на понимание бизнеса заказчика хотя бы пару дней, и результат мог бы быть совершенно иным.
Весь проект самолично (тут должна была быть контр-шуточка задевающая тематику «звездных войн») — конечно, да, вряд ли. Я больше подразумевал про частичную работу над проектом, к примеру привлеченного со стороны работника по ui/ux. В таких случаях, мне кажется, это будет немного лишним.
Тут я даже спорить не буду: если болит одно конкретное ухо, иди к отоларингологу. А что делать, если болит голова? Там может быть более 9000 причин, поэтому сначала терапевт. Так вот плохой терапевт советует попить обезболивающее, а хороший — посылает на анализы, ЭКГ, ЭЭГ и т.п., чтобы найти причину. Вот я как раз призываю всех быть хорошими терапевтами )))
нуждается в изрядном изменении бизнес-процессов, сайтостроитель обязан на это указать
Консалтинг должен идти отдельной услугой. А то ты приходишь заказать сайт, а тебя начинают учить бизнесу.
Никто не говорит об «учить».
Все интернет-магазины, например, изрядно похожи друг на друга, ну, плюс-минус с учётом специфики товара. Поэтому и типовые проблемы у многих схожи, и, имея какой-то опыт, довольно просто увидеть определённые проблемы в бизнесе, которые уже имеют решение. Я, когда с таким сталкиваюсь, начинаю задавать аккуратные вопросы — «а вот это у вас как сделано», «а вот не кажется ли, что может быть такая проблема» и т.п.

Если заказчик свято уверен в своей правоте, его никто не собирается переучивать. Я просто постараюсь ему объяснить, что, во-первых, интернет-решение будет работать эффективнее, если кое-что «подправить в консерватории», а во-вторых, ему проще на старте проекта потратить какое-то время на апгрейд бизнес-процессов для того, чтобы не менять что-то на ходу, теряя деньги и позиции в рейтингах.
Sign up to leave a comment.

Articles