Рабочий процесс как важная часть договорённостей с клиентом

    Написать эту статью нас побудила отличная статья Данила Снитко «Как хороший договор спасает нервы и монетку».

    К этой статье мы бы хотели добавить, что ооочень полезно дополнять договор так называемыми Правилами работы над проектом.

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

    Правила решают следующие задачи:
    1. Информировать клиента о процессе работы: как будет проходить работа, что от него потребуется в процессе и когда. В результате мы получим более образованного клиента и необходимые для работы материалы вовремя.
    2. Информировать клиента об ограничениях, которые мы на него накладываем в процессе работы, чтобы они не были для него сюрпризом. В результате мы получим более спокойного и удовлетворённого клиента.
    3. Юридически зафиксировать договорённости, чтобы потом на них можно было сослаться. Если клиент пытается сказать, что дизайн-концепция — это свёрстанный HTML-прототип, нам есть, на что сослаться.
    Правила исключительно полезны, потому что они организуют процесс с самого начала, что позволяет избежать потерь времени и ресурсов.

    Мы лично оформляем эти правила как приложение к договору. И в этом приложении мы, как правило, описываем следующие моменты:
    1. Взаимодействие: кто участвует в проекте с каждой стороны, каковы их права и обязанности, как мы общаемся и по каким правилам.
    2. Алгоритм работы: что в какой последовательности делается, каков результат каждого этапа, что от кого требуется на каждом этапе.

    Взаимодействие


    Здесь мы описываем, как правило, три момента:
    1. Представители сторон,
    2. Средства связи,
    3. Правила общения.

    Представители сторон и зоны их ответственности


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

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

    Что делать в таком случае? Мы, благодаря правилам, имеем полное право, если нам этого человека не представили ранее, сказать: «Очень приятно с вами познакомиться, но мы не можем взять в работу ваши комментарии. Пожалуйста, попросите вашего руководителя проекта выдать их нам».

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

    Пример:

    Коммуникации между Заказчиком и Исполнителем происходят через уполномоченных ответственных лиц:
    1. От Исполнителя: _______________________ (перечисляем всех, кто будет участвовать в коммуникации и их зоны ответственности).
    2. От Заказчика: __________________________(перечисляем всех, кто будет участвовать в коммуникации, и их зоны ответственности).
    Руководством к действию для каждой из Сторон являются только поручения и вопросы от вышеуказанных лиц. Обращения от иных представителей Заказчика или Исполнителя должны подкрепляться подтверждением вышеуказанных лиц.

    Прямые обращения к представителям Исполнителя не являются руководством к действию, если это не обговорено в настоящем Договоре.

    Средства связи


    Здесь мы указываем, какими средствами связи мы пользуемся и для чего, с указанием контактных данных людей, участвующих в коммуникации.

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

    Пример:

    В процессе работы над проектом будут использоваться следующие формы общения:
    1. Для обсуждения проектного задания: личные встречи или телефон +7-ХХХ-ХХХ-ХХ-ХХ.
    2. Для обсуждения дизайн-макетов: личные встречи или телефон +7-ХХХ-ХХХ-ХХ-ХХ.
    3. Для обсуждения результатов тестирования сайта: личные встречи или телефон +7-ХХХ-ХХХ-ХХ-ХХ.
    4. Для обсуждения мелких деталей, уточнения сроков предоставления промежуточных результатов, общих вопросов: телефон +7-ХХХ-ХХХ-ХХ-ХХ, skype YYYYYYYY или электронная почта ast@example.ru.
    При изменении каких-либо контактных данных Сторонам надлежит уведомить об этом друг друга любым доступным способом.

    Собственно, правила общения


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

    Пример:

    Общение по проекту осуществляется в рабочие дни с 10 до 19 по московскому времени.

    Переписка в электронной почте является документальным подтверждением достигнутых договоренностей.

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

    Для предотвращения увеличения срока создания сайта Сторонам рекомендуется реагировать на обращение другой Стороны в течение 1 рабочего дня.

    Алгоритм работы


    Это очень важная часть, который отлично позволяет понять и организовать рабочий процесс помимо коммуникации. В этом разделе мы описываем:
    1. Что мы делаем и какой получим результат — вообще и на каждом этапе;
    2. Примерные сроки на каждый этап и от чего это зависит;
    3. Что нужно от клиента на каждом этапе.
    Что мы получаем от этого:
    1. Клиент осведомлён и готов к работе: вы вовремя получаете всю необходимую информацию и материалы.
    2. У клиента не будет вопросов типа «я утвердил макеты, в понедельник запустим сайт?» или «А почему мы не можем одновременно рисовать и программировать?».
    Пример описания алгоритма для создания сайта «под ключ» вы можете посмотреть, скачав подготовленный нами пример «Правил работы над проектом».

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

    Некоторые работают иначе, поэтому описание вашего рабочего процесса может существенно отличаться от нашего. Обязательно пропишите его и проговорите его с клиентом как устно, так и в «Правилах работы».

    Резюме


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

    Не жалейте времени на обучение клиента: это позволит вам избежать множества проблем и повысит его удовлетворённость. Помимо этого, известен эффект от процесса обучения: когда вы кого-то учите, вы проверяете и закрепляете свои собственные знания.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 21
    • 0
      Сколько раз каждому из нас приходилось слышать «Даю трубочку своей помощнице/секретарю/сисадмину, он сейчас вам скажет, что необходимо подправить»!
      • +1
        По результатам личных встреч и телефонных разговоров, на которых обсуждаются важные вопросы, Исполнитель готовит письменное резюме, которое высылает Заказчику по электронной почте.
      • 0
        Мы сделали так:
        Поставили Mantis Bug Tracker и сказали клиентам, что бы свои хотелки писали туда. Было достаточно сложно первое время заставить людей писать, но мы устные хотелки отправляли в долгий ящик, а то что в мантисе стрались реализовать быстро, через некоторое время в результате такого подкрепления правильных действий у пользователей выработался рефлекс, что проще и быстрее написать в мантис. После этого посыпалось куча заявок на доработки существующего софта и написание новых модулей (мы внедряем учетные системы). Т.к. каждый такой чих оплачивался клиентом отдельно — мы достаточно неплохо увеличили свою выручку. Одному клиенту счет вырос где то в 6 раз, по сравнению с предыдущими. Директора это заинтересовало, он начал разбираться и выяснил, что больше половины наших доработок, вошедших в этот счет — вещь ненужная. После чего попросил делать только те доработки, которые санкционированы определенными лицами (при этом счет оплатили без проблем). Сейчас так и работаем:
        — Сотрудник создает инцидент в мантисе
        — Инцидент назначается одному из ответственных сотрудников
        — Если инцидент нужный, то далее он назначается на нашего сотрудника, который его назначает исполнителю

        • 0
          Вы учили клиента на его собственных ошибках. Этот способ наиболее распространённый, но, на наш взгляд несколько негуманный :) Хотя, есть такие люди, которых иначе не научишь, что уж там.
          • 0
            Честно говоря — учить клиента данному не было нашей задачей, так уж само собой получилось. До этого случая мы с этим клиентом работали лет 8, честно говоря даже и не думали, что внедрения мантиса приведет к таким последствиям.
          • 0
            Мы тоже поставили Мантис. Так некоторые клиенты умудряются отвечать на автоматические письменные уведомление, которые Мантис и рассылает =)
            • 0
              У меня был случай, клиентка утверждает с пеной у рта, что пишет в мантис, а ей ни кто не отвечает. Ни одного инцидента от нее в мантисе не было зарегистрировано. Вообщем когда ситуация наколилась, начали разбираться и выяснили, что она посылает письма на адрес мантиса (с которого он шлет уведомления). Было смешно и грустно
              • 0
                Просто у нас настроено, что если шлют на несуществующий ящик домена, то все приходит на info@… Вот так вот спалили, как они пишут.
            • 0
              Мы в свое время, наоборот, всеми силами держали подальше заказчика от мантиса. В качестве прослойки использовали basecamp. Там общались менеджеры с клиентами, которые фильтровали все пожелания и в мантис складывали готовые и четко сформулированные тикеты для разработчиков.

              А мантис был для разработчиков. Далеко не каждый программист или дизайнер будет в мантисе разбираться, что там придумали. На мой взгляд, это задача менеджера.

              А в остальном — да.
              • 0
                У нас организация маленькая — такой способ не подходит
                • 0
                  А это вопрос не количества, а разделения зон ответственности. Да, иногда бывает нужно, например, дизайнеру напрямую с заказчиком обсудить дизайн концепцию. Но это не должно быть перманентно.

                  Если говорить о размерах, то попробуйте для начала масшабировать этот подход на рабочую группу, а это, в среднем, 5-10 человек.
                  • 0
                    Зачем?
                    • 0
                      Ну во-первых, когда каждый выполняет именно свою работу. то работа команды получается гораздо эффективнее. Управление очень любит тратить время программистов, дизайнеров на всякие совещания, как пример. Всегда ли только это оправдано?

                      Основная эффективность работы каждого человека измеряется именно его работой. На мой взгляд, порядка 80% времени совещаний для дизайнеров, программистов и других непосредственных исполнителей является пустой тратой времени, которое они смогли бы провести более эффективно.

                      Это же можно отнести и к встречам с заказчиком например. Для встречи по проекту не обязательно вести весь свой штат.

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

                      У каждого свое мнение на то, каким должно быть эффективное управление. Кто то применяет те или иные методы на практике, кто то является сугубо теоретиком. Тут сложно говорить, что кто-то не прав. К сожалению, нет единственной верной инструкции на все случаи жизни.
                      • 0
                        У нас нет совещаний
                        • 0
                          Я это привел как пример.

                          Абстрагируйте это на прямое общение исполнителей с заказчиком.

                          А также определите зону ответственности менеджера проекта.

                          Собственно, продолжение дискуссии, мне кажется, не имеет смысла. Если у вас так и это работает — значит это здорово.

                          Я высказал свое видение и то, как я это вижу и применяю на практике. У каждого работают свои методы. Главное — чтобы они работали :)
                          • 0
                            так я сразу и сказал, что у нас не так много людей что бы их делить
            • 0
              > Переписка в электронной почте является документальным подтверждением достигнутых договоренностей.
              Это значит, что в суде переписка по мылу будет являться весомым аргументом или нет? Просто считается, что если нет электронной подписи, то электронное письмо можно подделать.
              • 0
                Это, скорее означает, что она будет принята судом в качестве доказательства.
                • 0
                  А опыта судебного не было связанного с этим? У меня просто недавно как раз был случай, когда в суде надо было доказать, что задержка сроков была по вине клиента (который писал на мыло новые и новые доделки), а электронную почту нельзя было предоставить в качестве доказательства.
                  • 0
                    Судебного опыта (к счастью или сожалению) такого нет.
                  • 0
                    Увы, не означает, если не было электронной цифровой подписи.

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

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