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

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

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



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

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

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

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

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

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

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

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

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

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

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

    Подробнее
    Реклама
    Комментарии 43
    • НЛО прилетело и опубликовало эту надпись здесь
    • 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 страницах, лучше потратить время на несколько встреч (ну или сеансов общения, если нет возможности встречаться), и понять, что за человек заказчик. Насколько он вменяем, зануден, зануден ли он по существу или просто от общего неудовлетворения миром, насколько он заинтересован в результатах работы (ведь не секрет, что часто начинается работа, которая, по сути, никому не нужна), насколько он понимает специфику работы, сколько этапов утверждения будет проходить работа, сколько человек принимают решения и т.д. То есть пробивать заказчика на общую вменяемость - это первое с чего надо начинать и самое важное.

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

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