Как проверить заказчика «на вшивость»

    При выполнении разных заказов я лично и много моих знакомых
    сталкивались с вопросом — как до начала работ определить, что после выполнения заказа все останутся довольны?

    Побывав лично с обеих сторон баррикад, и рассматривая именно фриланс, а именно короткие работы, а не заказную разработку (тут очень нечеткая грань, согласен), можно выделить следующие моменты и действия, требующие от фрилансера знаний основ управления проектами:



    — поробуйте поискать историю заказчика и информацию о нем в инете
    возможно, вы будете удивлены

    — посмотрите на своих конкурентов
    если вы предлагаете сильно худшие, чем они, условия — почему именно вы? если не знаете — спросите заказчика :)

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

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

    — заказчик говорит «давайте сначала сделаем прототип, а там посмотрим»
    вам лучше с самого начала выяснить — что будет «а там» и в каком объеме, хотя бы примерно

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

    — заказчик говорит «это нужно вчера»
    если честно, я перестал браться за такие работы вообще.

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

    — заказчик говорит «да тут все понятно»
    это значит, что задача понятна только богу и никому больше, включая заказчика

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

    дополнения в комментариях конечно же приветствуются
    Поделиться публикацией
    Комментарии 43
    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        заменил
        0
        Скажу про разработку сайтов: очень многие проблемы сразу отпадают при наличии правильно и грамотно составленного договора. Приходит заказчик к вам, вы обсуждаете и оговариваете все нюансы, подписывается договор, составляется ТЗ. Честно говоря, тут проблем никаких.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            А зачем соглашаться на работу без таких условий?
            0
            был прецедент (участвовал не я, но в курсе событий), когда договор был, но составлен так, что не подкопаешься и на (похоже что, сам я договор не видел) другое юр. лицо. как результат - недоплата половины суммы. так что наличие договора еще не дает гарантии. в случае с достаточно большими проектами, все-таки лучше привлекать юриста.

            ну и для начинающих полезно знать о таких вещах :)
            +6
            "это нужно вчера"
            Ну значит сегодня уже можно не делать (=
              +2
              Если сомневаетесь в заказчике, то разделите всю работу на 3-5 частей и просите оплату по окончании каждой. По крайней мере в деньгах не сильно потеряете, в случае чего.

              Ещё не разу не встречался с заказчиком, который бы «забивал» на проект свой.
              Гораздо более частый вариант — придирки к каждой мелочи, и поиск другого смысла в пунктах ТЗ.

              как до начала работ определить, что после выполнения заказа все останутся довольны?
              Никак. Вот к середине можно догадываться об этом, если с заказчиком на одной волне.
                0
                согласен. мало этого, если есть две части проекта, одна формализируемая, а вторая нет (или формализация сильно зависит от первой части), то деление проекта на части тоже удобно. это из практики :)
                  0
                  На примере создания сайта:
                  Дизайн, Разрезка шаблона под CMS, установка и настройка CMS, забивка контента (согласен, очень тесно с предыдущим пунктом), раскрутка.
                  0
                  увы, забивающие есть.
                  0
                  Предлагаю альтернативную тему - про разработчиков. Как найти ответственных и порядочных разработчиков, если у вас все же есть не ТЗ, но описание проекта и сториборды к нему, приемлимые сроки и бюджет. Недавно как раз искала )) Чуть было сюда не пришла искать, но темы создавать нигде не могу ))
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Небольшой офтоп был ) Я просто не о фрилансерах писала. Больше негде - пишу в комментах.
                      +3
                      Уже много сказано в блоге Управление проектами.

                      Так же, если не видели, рекомендую видео Управление проектами в реальной жизни — Правила Ашманова (Игорь Ашманов РИТ-2007).

                      Не нашёл от куда скачивал презентации, по этому выложил тут.
                        0
                        Большое спасибо, скачиваю.
                          0
                          Не за что, автору скажите спасибо: посмотреть профиль Ashmanov
                      0
                      Про ТЗ всеми руками и ногами поддерживаю. Уже задолбали эти "перламутровые пуговицы".
                        0
                        Рекомендую к договору подкалывать допсоглашение, по которому заказчик обязуется никогда не просить "поиграть со шрифтами" и\или "попробовать с цветами поэкспериментировать". :) Как вариант - за каждую просьбу увеличивать бюджет на 15% :)
                          –1
                          Ну, так это в договоре в отдельном пункте))) За отдельную плату: и по пунктам... Вот, например: «ЗАМОВНИК не має права вимагати від ВИКОНАВЦЯ внесення змін у вже прийняті етапи робіт. У випадку виникнення таких змін, умови їх виконання розглядаються та оцінюються окремо від умов даного Договору»
                            –2
                            это что за тарабарщина?
                              +3
                              Это один из пунктов реального договора. На укр. языке, могу перевести, если не понятно: «ЗАКАЗЧИК не имеет права требовать от ИСПОЛНИТЕЛЯ внесения изменений в уже принятые этапы работ. В случае возникновения таких изменений, условия рассматриваются и оцениваются отдельно от условий данного Договора»
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  Сам спросил — сам ответил?..
                                    0
                                    Извини, я не на того посмотрела((((
                            +1
                            А я с одной тётенькой уже два месяца копошусь вокруг договора. Вряд ли дело дойдёт до работы, но всё-таки прикольно.
                              +7
                              Переделав кучу заданий как во фрилансе, так и вне его утвердился в нескольких вещах

                              1. ТЗ надо делать самому. И брать за это деньги.
                              2. Прописать все ньюансы в договоре. Если невозможно все прописать - задирать сумму повыше
                              3. Дробить работу на этапы. Закрыли очередной этап: подписали акт и оплатили денежку, вот тогда начинаем следующий.
                              4. Если уже на первой встрече (никакого ТЗ нет и в помине) Заказчик требует назвать хоть примерный бюджет, то пользуюсь правилом - всплывающую в мозгу цифру (что уже всплыло после озвучивания всех требований вперемешку) умножить на 2, прибавить НДС и сообщить Клиенту.
                              5. Пословица "Ничто так не укрепляет веру в человека как 100% предоплата" при несоблюдении пунктов 1 - 4 позволяет Заказчику никогда не принять проект, требуя бесконечнеых бесплатных доделок.

                              Резюме: Каждый берет свою часть ответсвенности на себя. И как ни странно подчас для Клиентов это слышать - у них есть ответственность не только в финансовом плане.
                                0
                                Отличные 5 пунктов.
                                  +2
                                  Вот да, при чем сказано здесь куда больше чем в статье.
                                    0
                                    Все правильно. Хорошие пункты. Договор и ТЗ необходимы в любом случае.
                                    Без них мы как раз упираемся в бесконечное кол-во необходимых доработок.
                                    А стоимость и сроки я обычно озвучиваю только ориентировочные, пока не будет написанно ТЗ.
                                      0
                                      вы описали весь мой опыт работы с заказчиками...

                                      * утирает слезу умиления...
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • НЛО прилетело и опубликовало эту надпись здесь
                                          0
                                          Обычно делаю так:
                                          1. Цена от балды. Примерно можно понять, что хочет заказчик. Но обязательно обговаривается разбивка на этапы. И цена за первый этап. Если в качестве примера - разработка сайта, то цена за сайт визитку.
                                          2. Аванс обязательно (не менее 30 процентов).
                                          3. На первой неделе постоянный контакт с выяснением обстоятельств и деталей. Обычно за одну-две недели находится взаимопонимание.
                                          4. После выполнения первого этапа и получения всех обговоренных денег - переход к более "нестандартным" разработкам, всякие скрипты, продвижение, флеш и т.д. Далее цена и условия формируются в зависимости от оценки взаимодействий по первому этапу.

                                          ТЗ надо, но почему-то обычно заказчик не знает, что хочет. Часто приходится говорить не о самой работе, а о необходимых для сайта текстах и функциях. Но при этом можно установить хороший доверительный уровень взаимодействия. Для меня это очень важно!

                                          Чуть о сроках.. Не было случая, когда СРОЧНО действительно было срочно. :) Обычно укладываюсь в обговорённые сроки, но ВСЕГДА заказчик сам не готов предоставить нужные для сайта материалы!
                                          • НЛО прилетело и опубликовало эту надпись здесь
                                              0
                                              Да я и не спорю.. Будем считать, что мы хорошие :) Но есть и кто-то "плохой" :)
                                              У меня заказы попроще.. И "скоро" - это значит за 3-4 дня. Я так и делал.. Потом выяснялось, что заказчики специально сроки такие ставили, чтоб уж через две недели всё было! На следующих этапах сроки были адекватные..
                                              А что значит - "не приступили в течении 2-х дней"? Из-за этого, кстати, делаю сразу тестовый сайт и выкладываю первую шаблонную страничку сайта. И показываю заказчику. Оба понимаем - к выполнению задачи приступили :) Хотя.. на моих заказчиках приходится неделю думать, что же им надо? Как и писал выше - на первой неделе постоянный контакт.. Умный заказчик - мечта всех нормальных фрилансеров!
                                            0
                                            хе хе... да - заказчики бывают похлеще нечестных фрилансеров .)))

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

                                            тут сразу масса невинных вопросов типа "я вот папку открываю, а там не печатается" =))
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                XP и Agile методики не говорят о том, что все нужно пускать на самотек. Ето просто еще один инструмент, который имеет совершенно определенные границы применения, а не серебряная пуля.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                    0
                                                    тут, как вы понимаете, есть много нюансов, которые могут работать в случае заказной разработки и не работать в случае с фрилансом. я не имею ничего против XP, но в контексте данного топика (фриланс), имхо стоит более внимательно работать по таким технологиям.
                                                    а в остальном действительно в проектах с множеством планируемых изменений лучше присматриваться к XP, нежели к чему-то другому :)
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Комрады, несколько слов на тему договора

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

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

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

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

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

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое