Комментарии 18
Нельзя слишком ограничивать вариативность, так как это не позволит получить результат, который точно понравится клиенту.
Не соглашусь, можно и нужно при проектной работе. Собственно, это и есть «техническое задание» — когда вариативность сведена к минимуму и каждому участнику понятно, что будет сделано.
Ну есть оно (что еще тот геморрой, смотри ниже), решение задачи полностью ему соответствует, но клиенту оно не подходит в деталях. И что дальше? Вы правы, клиент нет. Деньги у вас, клиента вы потеряли.
Поймал негр золотую рыбку. — Отпусти меня, — говорит золотая рыбка, — Любое твое желание исполню. Подумал негр и говорит: — Сделай меня белым, и чтобы вокруг меня одни женщины были. Махнула рыбка хвостом… и превратила негра в унитаз в женском туалете.
Да, иногда с некоторыми клиентами проще расстаться, но большинство клиентов хотят решить свои проблемы в бизнесе, а не писать тех. задание. И они готовы платить за решение деньги. А автор описывает свой опыт, с моей точки зрения весьма полезный.
Хотя я склоняюсь к почасовой оплате, так таких проблем нет вообще.
Хотя я склоняюсь к почасовой оплате, так таких проблем нет вообще.
Где клиент внезапно вспоминает об аутенфикации и авторизации, и некий Вася в вакууме говорит - ну, это часов 80 работы (рил кейс, кстати, был хуже -чел потратил месяц).
Ну да, так всё и есть. Только я стараюсь разбить все на меньшие куски и хотя бы раз в неделю (обычно чаще) выкатывать законченные изменения на DEV. Время, затраченное на работу, заказчик видит в Jira.
Угу, обидно проработать месяц и выяснить, что всё что ты сделал не соответствует ожиданиям заказчика. TЗ один из вариантов защиты от этого. Не могу сказать, что идеальный, но иногда единственный, особенно на этапе, когда продукта еще нет. Дальше проще, вы уже знаете бизнес, чтобы адекватно понимать требования заказчика, заказчик доверяет вам. Задачи почти всегда можно разбить на части. Оплата может идти за часы. Всё это ведёт к тому, что уже не надо писать ТЗ на каждый чих, а у вас есть уверенность, что все переделки и исправления будут оплачены.
Но даже в случае нулевого продукта, можно жить без ТЗ и иногда это не плохой вариант, потому что не вы не заказчик изначально, не знаете, что хотите. К счастью, программирование — это не строительство и всегда можно скорректировать ход разработки, при минимальных затратах.
А что такого не так с 80 часами на авторизацию?
По сути, он сажает школьника за квалифицированную работу, в какой-то момент высокие риски от этого реализуются и не очень понятно, как фрилансер должен покрыть эти риски? Вот просто финансово эту схему вы как себе представляете? Как нужно повысить оплату, чтобы учесть эти риски? Повысить для всех? Ну тогда вы заставляете одних клиентов (как раз заказывающих предпроект) платить за других (не заказывающих) — странная методика получается, хорошие клиенты платят за плохих.
Вы не поняли, решение не подходит, после того как его сделали. Неужели сами с таким никогда не сталкивались в реальной жизни?
Ну посадили вы команду, ну потратила она неделю, две. Подписали ТЗ. Еще три месяца прошло. Выкатили продукт. А клиент смотрит и видит - не то. И ТЗ оно соответствует, и вроде сам дурак. И что?
А ведь вместо этого можно обсудить с клиентом все его хотелки. Примерно оценить время (несколько месяцев в нашем случае). И предложить ему максимально урезанный вариант на неделю или две. После этого у Вас будет более чёткое понимание процессов клиента, у него будет понимание что от вас ждать. Будет готовое приложение с минимумом функциональности. Возможная коррекция планов на остальную функциональность со стороны клиента.
Да, по времени до полной функциональности это займёт больше. Но только если вам в самом деле удастся создать идеальное ТЗ и идеальную реализацию. В реале некоторые фичи могут отвалится по мере наращивания функционала. И клиент может понять, что продукт уже прямо сейчас можно запускать, а не ждать 100% реализации.
Что касается оплаты, то я уже говорил - повременная. К чему там закладывать риски? Хочет заказчик месяц переделывать, будем месяц переделывать.
хорошие клиенты платят за плохих.
В этом месте на вас с улыбкой смотрят страховые бизнесы )))
Частенько из десяти комментариев исполнители отрабатывали семь-восемь, а остальные пропускали то ли из-за невнимательности, то ли в надежде на то, что я не замечу.
Это опять же возвращаясь к тому, что сдал работу в последние дни. Клиент вынужден всё быстро смотреть, поэтому пишет тут же что видит, а не сидит и обдумывает. Ты как исполнитель тут же отвечаешь на все запросы, и в потоке комментариев не мудрено что-то не заметить. Тут скорее виновата не невнимательность, а большой поток обратной связи, в которой по сути виноват сам исполнитель.
На фрилансе не работаю и услуги не рекламирую, но некоторые люди обращаются за разработкой того или иного продукта. Я стараюсь назначать сроки, которые были бы комфортны клиенту, но при оставляли мне огромное пространство для маневра. Запросил месяц, сделал за неделю, и еще неделю убил на правки.
И вы правы, фрилансеру полезно смотреть на весь процесс с точки зрения клиента.
в мире существует слишком мало людей с садистскими наклонностями
Ложка дёгтя портит бочку мёда. Если не принимать контрмер заранее, то один такой кадр обеспечит Вас психосоматическими проблемами на годы вперёд
Если контракт Time&Material - то пусть присылает как можно больше правок :)
Когда клиент мучает бесконечными правками