Comments 108
UFO just landed and posted this here
Суть как раз в том, что студия должна уметь работать с "вредным" заказчиком, а заказчик может просто-напросто найти другую студию и париться ему особо не нужно.
а разве заказчик не может налаживать доброжелательные отношения с уже существующей фирмой? например по тем же принципам(заключение договоров, в которых прописано все и т.д.)
UFO just landed and posted this here
вот об этом я и хотел сказать. гораздо лучше найти причину, почему они не уложились в определенные в договоре сроки и высказать свои претензии. Ведь в непонимании между компаниями не может быть виновата одна сторона.
ЗЫ: Дед-лайны никто не отменял,и то, что можно нарваться на просто динамящую студию, состоящую из студентов 3-4 курса тоже. Однако причины стоит искать всегда.
ЗЫ: Дед-лайны никто не отменял,и то, что можно нарваться на просто динамящую студию, состоящую из студентов 3-4 курса тоже. Однако причины стоит искать всегда.
UFO just landed and posted this here
Вы сейчас говорите именно о фирме, с которой у вас никак не получится вести адекватные переговоры, однако такие нужно отлавливать еще на стадии выбора. и не доводить до срыва сроков. (Желаете сделать что-либо подешевле, так учитесь управлять рисками)
Я говорю о том, что нужно анализировать свое поведение и поведение этой фирмы, и учится: даже из сорванных проектов можно вынести массу полезного для себя.
Я говорю о том, что нужно анализировать свое поведение и поведение этой фирмы, и учится: даже из сорванных проектов можно вынести массу полезного для себя.
UFO just landed and posted this here
Про это тоже можно написать, так как ни раз видел "вредных" исполнителей, и даже в начале своей деятельности им был. :)
И от себя добавлю пункт 7: Умножать стоимость по договору на коэффициент пропорциональный вредности клиента ;)
Хорошие люди должны общаться с хорошими людьми.
Вредным в этой схеме нету места.
Вредным в этой схеме нету места.
В теории звучит неплохо. Вот только насколько помогает "усиленный" договор, когда возникают проблемы? Я так понимаю, что легче бросить проблемного клиента, чем судиться с ним... или тут имеет место быть психологический фактор?
Здесь на 100% практика, а не теория. "Усиленный" договор помогает, когда заказчик полностью его понимает и знает, что подписывает.
Что бы кто не думал, даже самые отмороженные клиенты придают вашим аргументам при требовании оплаты либо отказе от доп. работ, если слова подтверждены документом, который они подписали.
Не раскрыта вот какая сторона дела:
бывают ВРЕДНЫЕ, но ой как полезные клиенты: имею ввиду работа с которыми прямо или косвенно сулит большие материальные выгоды или серьезное развитие для студии.
Также как есть супер лояльные, но совершенно бесполезные с вышеописанной точки зрения.
а вообще, требовать лояльности от клиента можно только после серьезного становления студии на рынке услуг.
бывают ВРЕДНЫЕ, но ой как полезные клиенты: имею ввиду работа с которыми прямо или косвенно сулит большие материальные выгоды или серьезное развитие для студии.
Также как есть супер лояльные, но совершенно бесполезные с вышеописанной точки зрения.
а вообще, требовать лояльности от клиента можно только после серьезного становления студии на рынке услуг.
Спасибо за статью.
Хорошо написано и доступно.
Хорошо написано и доступно.
По своему опыту могу сказать, что совсем невменяемые редко встречаются. А вот крайне требовательные сплошь и рядом. Так это же наоборот хорошо: воспитывают они просто замечательно. А строгие условия контракта дисциплинируют.
Вообще, считаю, что строгие условия контракта не мешают во всех случаях. Вреда от них ноль, если только не сомневаешься в своих силах выполнить обязательства.
Фактически исключение одно: лояльный клиент, которому на юридическую экспертизу и согласование договора надо около месяца. Тут можно уменьшить договор, чтобы сократить этот срок.
Не верю, что договор можно "уменьшить" настолько, чтобы срок реально сократился.
Мое решение: предоплата каждого этапа работ (лояльный ведь?) + месяц на юр. экспертизу + договор задним числом.
Мое решение: предоплата каждого этапа работ (лояльный ведь?) + месяц на юр. экспертизу + договор задним числом.
Проблема в том, что в организациях, где юридическая экспертиза проводится месяц, договоры задним числом не подписывают, например, в госструктурах.
Уточню свою мысль: можно не упрощять договор (тз, доверенности, сметы и прочее), а взять документы заказчика, которые уже утверждали. Такой опыт тоже был.
Уточню свою мысль: можно не упрощять договор (тз, доверенности, сметы и прочее), а взять документы заказчика, которые уже утверждали. Такой опыт тоже был.
Меня один воспитал, так другим, теперь общаться со мной сложно. И договора на 9-ти листах многие страшатся =)
Мне вот в отношениях заказчика и студии непонятен один момент. Как согласуется дизайн? Ведь для того, чтобы заказчику что-либо показать, нужно потратить время дизайнера, а значит - оплатить. А заказчик может просто уйти безотносительно качества дизайна, и получается, что от него только убыток.
Как тут поступают мудрейшие?
Как тут поступают мудрейшие?
выход: закладывать издержки на такие проекты в стоимость других "рабочих" проектов
Так тоже можно поступить, но это не совсем правильно. Лучше всего получить предоплату.
не-не-не. Не согласен.
работа дизайнера должа быть оплачена, даже если она не понравилась заказчику. Это - вина заказчика, т.к. он неответственно подошел к выбору исполнителя. предоплата не возвращается.
Конечно это все в идеале. возможны отступления
работа дизайнера должа быть оплачена, даже если она не понравилась заказчику. Это - вина заказчика, т.к. он неответственно подошел к выбору исполнителя. предоплата не возвращается.
Конечно это все в идеале. возможны отступления
Я в статье написал по поводу эстетических потребностей заказчика их не надо удовлетворять, надо руководствоваться профессиональными знаниямия.
Не согласен. Бывает, что дизайнер, в пользу эстетики, забывает о бизнес-задачах исполнителя (либо просто не успевает разобраться в реалиях его бизнеса). Видел пару таких случаев, когда заказчик, в описанной ситуации, брал руль в свои руки. При том, что заказчик был мега-адекватен, он "пробил" фактически "свой" дизайн и получился отличный для его бизнеса продукт. А вот дизайнер был не рад) бывает...
Не понятно с чем вы не согласны :) Я говорил, об эстетических предпочтениях ("мой любимый цвет ярко-салатовый", "здесь должен быть красный это мой цвет по фэн-шуй"), а не о бизнес-задачах или качестве работы.
Не согласен вот в чем: забивать на чисто эстетические предпочтения без аргументов(!) на мой взгляд нельзя. Только вот, зачастую, дизайнерская трактовка "эстетических предпочтений" заходит дальше моего (личного) понимания этого вопроса. В таких ситуациях я и не согласен. И заказчика понимаю и дизайнеров наших. Заказчика, иногда, понимаю лучше/больше/сильнее)
Аргументировать решения надо это одна из главных обязанностей МП. Я с вами опять же согласен, что если дизайнер нарушает стандарты, делает что-то реально плохо это некачественная работа, но когда заказчик выбирает студию, он должен рассчитывать на их профессионализм, а не на то, что ему придется вмешивать причем в ту область, которая для него не является знакомой.
Мудрейшие делают дизайн после подписания договора и перечисления преподлаты + в договоре прописывается количество вариантов дизайна, который предоставляется заказчику.
Как в таком случае заказчику защититься от недобросовестного исполнителя, согласовавшего, скажем, три варианта дизайна и представившего три отстойнейших варианта?
Уточните понятие "отстойнешие вариант дизайна". В техническом задание прописывается соответствие тематика, веб-стандартам и эргономике и прочее.
защищаться надо заранее, просматривая портфолио исполнителя
Плюсадин. Когда вы выбираете исполнителя, вы должны рассчитывать на его профессионализм, иначе надо выбирать другого или делать самому.
Вот, блин, идеалисты какие. Кто же спорит... надо, конечно. Только нужно еще понять заказчика, который на профессионализм рассчитывает, но в формулировке задачи волен творить все что угодно. Даже "учтите, я люблю этот цвет, им мой сынишка какает". Его бизнес, его задача, его ответственность при формулировке.
А так-то, конечно, все мы были бы в шоколаде, если это не было б так важно.
А так-то, конечно, все мы были бы в шоколаде, если это не было б так важно.
Если бы заказчик знал, что ему надо сделать он бы сам и сделал. :)
Вы ремонт дома сами делаете? А что надо сделать знаете? Что и Как это, простите, очень разные вещи.
Продолжая аналогию: вас волнует, что дизайнер интерьера говорит "оранжевый вариант прекрасен", когда вас от него тошнит? Аналогия на грани фола, но, по-моему, вполне уместна.
Продолжая аналогию: вас волнует, что дизайнер интерьера говорит "оранжевый вариант прекрасен", когда вас от него тошнит? Аналогия на грани фола, но, по-моему, вполне уместна.
Ну, тут главное далеко не то, что заказчика "тошнит от оранжевого", главное чтобы от оранжевого не тошнило потенциальных посетителей. Часто очень сильно расходится то, что клиенту действительно надо, и что он думает, что ему надо. В подобных рассуждениях часто приводят пример со врачом и пациентом: пациент (заказчик) знает, что у него болит, и может быть даже знает, какие надо пить лекарства, но окончательное лечение лучше пусть всё-таки назначит врач (исполнитель).
Если вести речь о мнениях из разряда "тошнит от ораньжевого", то, я думаю, вы столько-же об этом знаете сколько и клиент.
Вообще я стараюсь в первую очередь изучить аудиторию проекта, прежде чем браться за работу, и считаю это единственно правильной последовательностью. Изучить, тошнит ли аудиторию от оранжевого моя работа, а не заказчика. Поэтому я знаю об этом больше, чем он. Хотя бывают и заказчики, очень хорошо знающие свою аудиторию.
Ну ваш пример прямо против утверждения же играет. Вы правда считаете, что в рамках проекта сможете изучить аудиторию ресторатора лучше чем он за несколько лет? Я правда спрашиваю. Про себя наверняка знаю что мы не сможем. Еще наверняка знаю, что в 90% случаев "исследование" аудитории у дизайнеров сводится к применению ряда стереотипов, не более. Да и вообще в исследования верю на 50%) как-то так.
Вы знаете, в ряде случаев вообще уже большим прогрессом становится переход от утверждения заказчика "мне нравится" к "моим клиентам нравится". Конечно, полноценное исследование провести не удастся, но зачастую и простых стереотипов бывает достаточно. Стереотипы ведь не плохи сами по себе. Главное зачастую вообще начать думать об аудитории проекта. Пока что приходилось сталкиваться только с тем, что заказчик всё оценивает со своей колокольни.
Звиняюсь :) не ваш пример был про кафешку
Какие методы исследования?
Более точная аналогия будет не ремонт дома, а ремонт скажем кафе важно не то, что нравится заказчику, а сколько народу будет его посещать и понравится ли посетителям.
Иногда имеет место такая логика: заказчик, компания которого успешна хотя бы настолько, чтобы сайт у нас(вас, них) заказать достаточно много знает о своих клиентах и их предпочтениях. Особенно хозяин кафе. А мы(вы, они) как повезет. М.б. разобрались, а м.б. и нет. Его мнение имеет большое значение. Я так думаю.
Интерьер квартиры Вы делаете для себя и Вам в нем жить. Дизайн сайта, в основном, для клиентов/партнеров.
О! Я понял как объяснить!
Прочитайте последние каменты на эту тему и ответьте на вопрос: велики ли шансы, что клиент, который на своем нелепом языке говорит "клиентов тошнит от фиолетового" будет услышан? Настрой очень сильный: клиента хочет говна по умолчанию, тем более не указал в тз значит просто выёживается.
Прочитайте последние каменты на эту тему и ответьте на вопрос: велики ли шансы, что клиент, который на своем нелепом языке говорит "клиентов тошнит от фиолетового" будет услышан? Настрой очень сильный: клиента хочет говна по умолчанию, тем более не указал в тз значит просто выёживается.
как быть с дизайнерами у которых в портфолио конфетки, а тебе присылают унылое говно, склёпаное за пару часов?
а предоплата уже уплачена.
несколько раз такое было, всегда добивался возврата предоплаты. но потеряное время то не вернёшь
а предоплата уже уплачена.
несколько раз такое было, всегда добивался возврата предоплаты. но потеряное время то не вернёшь
А если портфолио супер, а дизайны на утверждение говно, например уволился тот дизайнер?
У нас примерно так.
В договоре или в техническом задании, который является неотъемлемой частью, делается детальная разбивка на этапы работ, в том числе: создание концепции, эскиза и дизайна сайта. Эти два предварительных этапа хорошая подстраховка + прописываются условия: клиент должен написать мотивированный отказ. Мотивированный отказ очень многих почему-то пугает. Нюанс один только есть: вы должны лично привести макет эскиза или дизайна на встречу к клиенту, что бы он его подписал, что видел. Если что в суде это будет одно из доказательств того, что работа была выполнена.
И проблема в 98% случаев решена.
В договоре или в техническом задании, который является неотъемлемой частью, делается детальная разбивка на этапы работ, в том числе: создание концепции, эскиза и дизайна сайта. Эти два предварительных этапа хорошая подстраховка + прописываются условия: клиент должен написать мотивированный отказ. Мотивированный отказ очень многих почему-то пугает. Нюанс один только есть: вы должны лично привести макет эскиза или дизайна на встречу к клиенту, что бы он его подписал, что видел. Если что в суде это будет одно из доказательств того, что работа была выполнена.
И проблема в 98% случаев решена.
Йо, коллега) аналогично. Дальше уже начинается правда жизни: поленились привести, не смогли застать, выслали по почте и бла-бла-бла...
Мотивированный отказ кого хочешь испугает :) Как должен некомпетентный в вопросе заказчик мотивированно хаять ваш дизайн? :)
Меня тут в тупик поставил хостер, который на запрос предоставления доступа по SSH попросил мотивировать это чем-нибудь более существенным, нежели удобством работы...
Меня тут в тупик поставил хостер, который на запрос предоставления доступа по SSH попросил мотивировать это чем-нибудь более существенным, нежели удобством работы...
Мотивированный отказ это юридическое понятие, нужное на случай ядерной войны, т.е. суда. Заказчик должен понимать (это прописывается в тз), что дизайн решает поставленные задачи, а не удовлетворет его личные эстетические потребности или вкусы. Он к вам не просто так пришел, а за профессиональными услугами.
Соотвественно, заказчик в мотивированном отказе должен написать: "почему дизайн сайта не решает поставленные в техническом задании задачи". Когда доходит до дела, оказывается что ничего кроме эмоций и ощущений нет. Мотивированный отказ страхует от таких комментариев, как "просто не нравится", "не лежит душа" и "как-то так" или же когда заказчик отказывается оплачивать отрисованный полностью дизайн, потому что он ему не нравится.
P.S. С хостингом я думаю им просто лень и они решили выпендриться :)
Соотвественно, заказчик в мотивированном отказе должен написать: "почему дизайн сайта не решает поставленные в техническом задании задачи". Когда доходит до дела, оказывается что ничего кроме эмоций и ощущений нет. Мотивированный отказ страхует от таких комментариев, как "просто не нравится", "не лежит душа" и "как-то так" или же когда заказчик отказывается оплачивать отрисованный полностью дизайн, потому что он ему не нравится.
P.S. С хостингом я думаю им просто лень и они решили выпендриться :)
секурность для хостера тоже важна, раздавать ssh налево и направо на шаред хостинге, гиблая практика
Спасибо большое, многое возьму на вооружение.
В целом же получается что ключ к работе с любыми клиентами – это правильно и четко составленный договор + тз.
В целом же получается что ключ к работе с любыми клиентами – это правильно и четко составленный договор + тз.
Добавлю из своего опыта:
Техзадание должно быть составлено как можно более подробно, а регламент его изменения должен быть прописан в договоре.
С заказчиком должен общаться только менеджер, непосредственные контакты заказчика с дизайнерами или программистами нужно исключить или минимизировать.
Техзадание должно быть составлено как можно более подробно, а регламент его изменения должен быть прописан в договоре.
С заказчиком должен общаться только менеджер, непосредственные контакты заказчика с дизайнерами или программистами нужно исключить или минимизировать.
По техзаданию согласен: лучше всего прописать, что техзадание без согласия исполнителя (и соответственно пересмотра стоимости) менять нельзя.
По общению не совсем согласен: с клиентом по хорошему должны общаться все, разумеется, в присутствии МП. Это повышает мотивацию и делает компанию клиенто-ориентированной.
По общению не совсем согласен: с клиентом по хорошему должны общаться все, разумеется, в присутствии МП. Это повышает мотивацию и делает компанию клиенто-ориентированной.
Добавлю только, что очень многое зависит от конкретных дизайнеров\программистов. Бывает же, что менеджеру говорят одно, а в лицо заказчику боятся сказать что "гавно идея". Вот и создается у человека впечатление, что он услышал мнение профессионала и все в порядке, а менеджер чего-то там мутит в своих интересах.
Нечасто, но бывает. Нужно принимать во внимание.
Нечасто, но бывает. Нужно принимать во внимание.
Мы же говорим о "вредных" клиентах :). Матёрый менеджер может поставить такого клиента на место, а обычному дизайнеру это бывает сделать сложно. А наглые клиенты ("быдло", спортсмены, братки и т. п.) часто пытаются давить на исполнителей, убеждать их сделать больше, чем положено по договору, пытаться выходить на них вне компании, угрожать и т. д.
Ещё добавлю. Дизайнеры, программисты, водители, плотники (профессия и сфера деятельности здесь не важна) должны заниматься своей непосредственной работой, а задача менеджера - обеспечить им эту возможность, иначе происходит снижение производительности труда, срыв сроков, падение прибыли.
Вспомнилась реклама "Альфа-банка" со слоганом "С каждым клиентом мы найдём общий язык", где сотрудники банка общались с чукчей, работягой-матерщинником и гламурной блондинкой на их языке. Вот таким должны быть профессиональные менеджеры, только где их найти... ;)
Вспомнилась реклама "Альфа-банка" со слоганом "С каждым клиентом мы найдём общий язык", где сотрудники банка общались с чукчей, работягой-матерщинником и гламурной блондинкой на их языке. Вот таким должны быть профессиональные менеджеры, только где их найти... ;)
>С заказчиком должен общаться только менеджер, непосредственные контакты заказчика с дизайнерами или программистами нужно исключить или минимизировать.
Почему? я, как дизайнер, терпеть не могу работать через третьи руки. Просто неоднократно была ситуация, когда я отдавал менеджеру макеты, а он потом приходил с длиннющим списком, что, по мнению заказчика следовало изменить. Половина списка ничем не обоснованная глупость, о чём я ему и говорил, на что получал ответ: "Вань, я конечно понимаю, что тебе лучше знать, но я уже договорился с ними, что будет вот так". Менеджеры в большинстве случаев недостаточно компетентны в специфических вопросах, не смогут подобрать аргументов чтобы убедить клиента в правильности решения исполнителя.
Почему? я, как дизайнер, терпеть не могу работать через третьи руки. Просто неоднократно была ситуация, когда я отдавал менеджеру макеты, а он потом приходил с длиннющим списком, что, по мнению заказчика следовало изменить. Половина списка ничем не обоснованная глупость, о чём я ему и говорил, на что получал ответ: "Вань, я конечно понимаю, что тебе лучше знать, но я уже договорился с ними, что будет вот так". Менеджеры в большинстве случаев недостаточно компетентны в специфических вопросах, не смогут подобрать аргументов чтобы убедить клиента в правильности решения исполнителя.
а может кто поделится темплейтом такого "усиленного" договора? )))
По моему опыту, если вести речь о разработке сайтов и дизайне, то очень помогают юристы, занимающиеся авторским правом.
Как насчет IT-юристов не знаю. Никогда даже не видел их живьем, если честно.
Как насчет IT-юристов не знаю. Никогда даже не видел их живьем, если честно.
По авторскому праву общался обязали вписать в договор пункт о передачи сайта на диске, потому что "надо что-то передать". Потом общался с человеком, который имел дело с договорами связанными с продажей ПО, так был уже более качественный подход. Сейчас пользуюсь договором сделанным полностью под себя и проверенный юристом.
Вывод отсюда, возможно, такой: больше зависит от квалификации человека, чем от направления все-таки. Есть важный момент: юрист должен быть "договорник", т.е. человек, который часто и много готовит договоров на смежные темы и имеет опыт защиты от претензий по этим договорам, вплоть до судебной. Это фактически идеал, на мой взгляд, для "первичной" оценки человека непрофессионалом в данном вопросе (руководителем).
можете выложить для ознакомления?
хотелось бы подчеркнуть значение оценки коэффициента полезного действия перед началом работы с вредным клиентом. а именно, стоят ли нажитые болячки тех денег? так, как автор описывает подготовку к заключению сделки и работу, сумма сделки должна обеспечить всю оставшуюся жизнь. иначе смысла связываться нет.
Спасибо за статью.
"Перво-наперво необходимо «вредного» клиента определить до появления проблем".
Иногда бываю такие хорошие клиенты по началу и такие вредные в конце, что диву даёшся)
"Перво-наперво необходимо «вредного» клиента определить до появления проблем".
Иногда бываю такие хорошие клиенты по началу и такие вредные в конце, что диву даёшся)
Если клиент с лояльного становиться "вредным" возможно вы себя не совсем правильно ставите или его не устраивает качество работы (именно так, как он его себе представлял). ИМХО, конечно.
Я о том, что иногда сложно определить, по первым общениям, какой перед тобой клиент, лояльный или "вредный".)
Для заключения договора нужна не одна встреча, а понимать людей это обязанность МП. Плюс вы можете навести справки о потенциальном заказчике у его партнеров, подрядчиков, клиентов, в отраслевой прессе. Можно также посмотреть, какие проекты реализовал партнер. Если МП достаточно грамотный он может эффективно пообщаться с сотрудниками заказчика для получения информации.
Недавно, кстати, в «Секрете Фирмы» был по этому поводу отличный развернутый материал.
Спасибо за статью. А где нибудь можно нейти пример такого договора?
Хоть область применения немного отличается (компьютерная розница) но идея та же.
http://forum.ixbt.com/topic.cgi?id=42:18339
http://forum.ixbt.com/topic.cgi?id=42:18339
Кое-что из статьи натолкнуло на рассуждение.
"Следующим этапом будет составление технического задания. Оно будет приложением к договору, и должно быть составлено до подписания договора. Техническое задание должны быть очень подробным, чтобы было не к чему в итоге придраться."
По опыту оказалось крайне неверно и привело нас к тому, чтобы сменить бизнес-модель и использовать адаптивный подход.
Грубо говоря, оказалось, что лучше не тратить драгоценное время на написание бесполезной документации типа "очень подробного ТЗ", т.к. даже если в один момент времени заказчик это утвердит, то потом у него у самого будут претензии к результату (и неважно, что он сам подписал это) - это уже станет неактуальным! Не стоит терять время на написание системы (или, скажем, создание сайта) на бумаге - это может занять столько же времени, сколько может уйти на подготовку "опытного образца".
Разумеется, при старой бизнес модели так работать нельзя, ибо получается конфликт двух моментов:
1. Заказчик хочет застолбить сумму, объем работ и сроки и прописать их в договоре (скажем, в виде приложения "ТЗ");
2. Необходимо увеличивать бюджет на то, что заказчик "хочет еще" или снижать на то, что ему перестало (гипотетически) быть нужно уже во время разработки проекта.
Пример:
Допустим, увидев первые наработки, клиент решает, что ему этого достаточно, остального по начальному ТЗ не надо, но надо что-то вообще новое.
Итог:
- К чертям летит договор - все равно требуется доп. соглашение, в котором уточняются измененные виды (или объемы) работ, регламенты, условия и т. д., и т. п.
- Сложности с тем, что нужно как-то аргументировать клиенту необходимость менять бюджет (при изменении в высшую сторону). Вот этот момент большинство почему-то не берет в расчет, считая, что "на месте разберемся". В итоге - многие срабатывают себе в минус и долго ругаются на клиента, который часто в общем-то и не обязан досконально все понимать.
Лично нам помогло грамотное обдумывание ооочень большого количества возможных моментов и изменение бизнес-модели от ориентированной на "конечный продукт" к ориентированной на "постоянное обслуживание".
Чтобы было понятно о чем речь - работа представлена не в виде "компания создает сайт".
Все исходит из другого. Для чего клиенту сайт? Для презентации своей продукции? Так вот, в данном случае "компания решает задачу по поддержке клиента в презентации своей продукции", применяя для этого любые доступные компании-исполнителю методы (которые могут меняться по мере проекта, ровно как и пожелания клиента).
Попробуйте изначально подходить к объяснениям клиенту именно с этой стороны, сразу сделав любые, даже самые значительные изменения "штатной ситуацией", к которой готовы все, включая клиента!
И не тратьте время на создание всесторонне суперпуперпродуманных договоров - лучше обдумайте грамотный подход к созданию соглашений об уровне сервиса (SLA) для своей области деятельности.
P.S. Вышесказанное не претендует на абсолютную объективность, так как нельзя утверждать, что нами были рассмотрены все ситуации, и возможно, кому-то эта модель не подойдет. Однако, я лично (пусть даже субъективно) считаю, что для студий, которые умеют работать, но не имеют такого актива, как "бренд и имя на рынке" - это будет идеальным решением и выживать будут те, которые наиболее "адаптивные", "гибкие".
Кстати, такая бизнес-модель отлично соотносится с Agile-подходами к разработке ПО и является, по сути, реализацией метода "Getting Real".
"Следующим этапом будет составление технического задания. Оно будет приложением к договору, и должно быть составлено до подписания договора. Техническое задание должны быть очень подробным, чтобы было не к чему в итоге придраться."
По опыту оказалось крайне неверно и привело нас к тому, чтобы сменить бизнес-модель и использовать адаптивный подход.
Грубо говоря, оказалось, что лучше не тратить драгоценное время на написание бесполезной документации типа "очень подробного ТЗ", т.к. даже если в один момент времени заказчик это утвердит, то потом у него у самого будут претензии к результату (и неважно, что он сам подписал это) - это уже станет неактуальным! Не стоит терять время на написание системы (или, скажем, создание сайта) на бумаге - это может занять столько же времени, сколько может уйти на подготовку "опытного образца".
Разумеется, при старой бизнес модели так работать нельзя, ибо получается конфликт двух моментов:
1. Заказчик хочет застолбить сумму, объем работ и сроки и прописать их в договоре (скажем, в виде приложения "ТЗ");
2. Необходимо увеличивать бюджет на то, что заказчик "хочет еще" или снижать на то, что ему перестало (гипотетически) быть нужно уже во время разработки проекта.
Пример:
Допустим, увидев первые наработки, клиент решает, что ему этого достаточно, остального по начальному ТЗ не надо, но надо что-то вообще новое.
Итог:
- К чертям летит договор - все равно требуется доп. соглашение, в котором уточняются измененные виды (или объемы) работ, регламенты, условия и т. д., и т. п.
- Сложности с тем, что нужно как-то аргументировать клиенту необходимость менять бюджет (при изменении в высшую сторону). Вот этот момент большинство почему-то не берет в расчет, считая, что "на месте разберемся". В итоге - многие срабатывают себе в минус и долго ругаются на клиента, который часто в общем-то и не обязан досконально все понимать.
Лично нам помогло грамотное обдумывание ооочень большого количества возможных моментов и изменение бизнес-модели от ориентированной на "конечный продукт" к ориентированной на "постоянное обслуживание".
Чтобы было понятно о чем речь - работа представлена не в виде "компания создает сайт".
Все исходит из другого. Для чего клиенту сайт? Для презентации своей продукции? Так вот, в данном случае "компания решает задачу по поддержке клиента в презентации своей продукции", применяя для этого любые доступные компании-исполнителю методы (которые могут меняться по мере проекта, ровно как и пожелания клиента).
Попробуйте изначально подходить к объяснениям клиенту именно с этой стороны, сразу сделав любые, даже самые значительные изменения "штатной ситуацией", к которой готовы все, включая клиента!
И не тратьте время на создание всесторонне суперпуперпродуманных договоров - лучше обдумайте грамотный подход к созданию соглашений об уровне сервиса (SLA) для своей области деятельности.
P.S. Вышесказанное не претендует на абсолютную объективность, так как нельзя утверждать, что нами были рассмотрены все ситуации, и возможно, кому-то эта модель не подойдет. Однако, я лично (пусть даже субъективно) считаю, что для студий, которые умеют работать, но не имеют такого актива, как "бренд и имя на рынке" - это будет идеальным решением и выживать будут те, которые наиболее "адаптивные", "гибкие".
Кстати, такая бизнес-модель отлично соотносится с Agile-подходами к разработке ПО и является, по сути, реализацией метода "Getting Real".
Sign up to leave a comment.
«Вредные» клиенты