Методичка по работе с клиентами. Для начинающих менеджеров веб-студий. Часть 2. ТЗ и смета

    (2009 год, второе письмо старшего менеджера веб-студии — младшему)
    Итак, первоначальные переговоры c клиентом проведены. Смотрим первую часть методички здесь http://habrahabr.ru/blogs/studiobusiness/45543/.
    Теперь надо сориентировать клиента по цене. Если он с ней принципиально согласен — переходим к обсуждению Технического задания (ТЗ).
    Делаем смету

    Смета


    Смету обычно делим на две основные части:

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

    Тут важно помнить про следующие жизненные опыты:
    Клиент может сказать: "а че там, программирование — сделает мой системный администратор"
    Или: "Не ну а че, дизайн — сделает мой системный администратор"
    Или — "Знаете ли, эти и эти и эти модули — мне нахрен не нужны, мы решили сэкономить"
    То есть, смета должна быть сделана таким образом, чтобы дать клиенту возможность варьировать цену — но, по возможности, минимально.Критичные вещи надо жестко привязывать к разработке. Например, увеличить стоимость "Ядра CMS" и уменьшить стоимость модулей. Тоже самое касается цены за дизайн — по возможности, цена за дизайн и программирование сбалансированы должны быть.

    Смета — обычно простой Excel файл, желательно оформить поприличней. Ниже простой набросок.
     
    image
     
    Очень важно не забыть отдельно оценить работы по наполнению сайта. Контент — это соломинка, которая может превратится в "бревно в глазу".
    Не раз случалось, когда времени на наполнение было потрачено ВДВОЕ больше, нежели чем на разработку.
    Также в смету надо внести пункты про разработку ТЗ, тестирование, SEO и тд.
     
    Затем, если смета приблизительно одобрена — двигаемся дальше.
    Теперь задача написать техническое задание. На основе технического задания — подписать договор.
    (Или можно сначала подписать договор, потом делать ТЗ. Или подписать договор о намерениях разработки и работать с ТЗ. Тут лучше смотреть по клиенту. )
    Я обычно отдельно пишу ТЗ, потом на его основе подписываем договор.
     

    Написание ТЗ


    ТЗ для проекта делать крайне желательно. Это главный щит от неадекватного клиента.
    Например — крупный заказчик, вы общаетесь с отделом маркетинга и показываете макет и получает ответ в духе "вы знаете, наш директор посмотрел и он хочет разместить приветствие со своей фотографией под логотипом и изменить концепцию дизайна".
    В таком случае достаем ТЗ, говорим — "не было". Дорабатываем либо за дополнительную оплату либо отказываемся от доработки "так, как это противоречит первоначальному ТЗ". В договоре желательно четко зафиксировать эти моменты. Договор — это очень интересная тема. Если еще не видели — обязательно смотрите и берите пример с Теминого договора http://www.tema.ru/jj/RIBBA-sait-2009.doc. На хабре тоже мелькали размышления по договорам ( habrahabr.ru/blogs/studiobusiness/57151 )
    Важно, чтобы было несколько шаблонных ТЗ на типовые работы. Например, корпоративный сайт, инет-магазин или интранет-сайт. При хорошо сделанном шаблоне — подготовка реального ТЗ, например на интернет-магазин, занимает 30-60 минут — просто работаем скульптором, отсекаем лишнее из шаблона.
    Хорошее ТЗ должно быть понятно:
    -самому клиенту;
    -должно быть прозрачно — для дизайнера, — верстальщика;
    -должно быть прозрачно — для программиста;
    -неплохо бы еще, чтобы менеджер, который разрабатывает ТЗ -тоже разбирался по минимуму;

    В ТЗ на разработку сайта нужно обязательно учесть:
    -Требования к дизайну;
    -Требования к верстке;
    -Требования к функционалу сайта;

    Также еще интересны:
    -Требования к контенту;
    -Требования к серверу;
    -Требования к нагрузке;

    Но в 50% случаев они вряд ли понадобятся.

    Попробуем накидать рыбу для ТЗ для потенциального сайта автомобильного сообщества.
    я размещаю ее по ссылке , поскольку будет длинновато и скучно — любителям экшена и Чака Норриса не рекомендуется .

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

    После подписания договора — ведем работу над проектом.
    Добавляем клиента в систему ведения проектов.
    Здесь можно использовать бесплатные системы типа трека, мантиса. Плюсов много — бесплатно и гибко, если привыкнуть. Но у них один громадный минус — с точки зрения заказчика — сложный интерфейс — если клиент морально не готов к тому, что увидит — он заходит в систему, смотрит, выходит и… продолжает писать вам email-ы.
    Мы 4 года назад случайно начали вести какой-то проект в Бейскемпе (http://basecamphq.com). Через две недели уже не понимали, как работали до этого по почте. Реально экономит время. Из плюсов — это уже готовый сервис- не надо ничего настраивать, можно поставить свой логотип и поставить свой сабдомен. Половина клиентов при виде сабдомена типа МОЯ_СТУДИЯ.basecamphq.com думали, что это наша разработка и просили поставить им такую на фирму ). Самый главный плюс — простота. Пару минусов — не совсем гибкое ведение проектов. Последний год работаем с http://worksection.com, максимально приближенный к Бейскемпу аналог на русском. ( Егор Жилев из турбомилка написал хороший обзор).
    И напоследок по работе с удаленными сотрудниками и сотрудниками вообще. Пока родилась только одна мысль за несколько лет — "стараться работать только с хорошими адекватными профи". Минус — дорого и очень сложно найти вменяемых людей. Плюс — дороговизну закладываем в проект, к тому же качество отбивается в последующих заказах. И самый большой плюс: проблем при сдаче намного меньше. Стоимость может отличатся на 30-60%, а количество геморроя на порядок.
    Поделиться публикацией

    Комментарии 41

      –10
      Столбец одинаковых чисел в наброске сметы демонстрирует вопиющее незнание основ Экселя (в частности, абсолютных $ссылок). Это вызывает сомнения в уровне студии.
        +1
        бог с вами, ексель тестовый
          +4
          Не вник человек в суть таблицы.
          +1
          Рыба явно непроверенная в бою. Например «Сайт должен одинаково выглядет в последних версия браузеров Mozilla Firefox версия 2.0 и выше, Internet Explorer версия 6.0 и выше, Opera версия 9 и выше, последней версии MacSafari» — а Вы не сталкивались с тем что FF и Opera например сглаживают шрифты в зависимости от версии операционной системы, а вот IE — нет. И это повод заказчику сказать — а почему у меня выглядит не так как у соседа? И кстати будет прав, если следовать Вашей формулировке
            +1
            Уважаемый Воланд
            ну в общем-то и Вы правы и формулировку то особо не изменишь
            у людей не только разные операционки но и мониторы и глаза ), все случаи трудно предусмотреть необходимо «техническая допустимая погрешность»
              +2
              ну почему же не изменить? Например «Сайт должен корректно отображаться в следующих браузерах — Mozilla FireFox версий от 2.0 до 3.7, Opera версий 9.0 до 10.01, Internet Explorer версии от 6.0 до 8.0». Корректно и одинаково — это все таки разные вещи а так как HTML — формат в первую очередь текстовый, а не графический каждый браузер и ОС имеют право на свою интерпретацию, главное чтоб она была верной!
                +2
                Главное определить пределы этой погрешности, раз уж готовим юридический документ. Многие заказчики знают про сглаживание шрифтов (и даже про то, что, какой-то шрифт может быть не установлен в конечной системе) и не обращают внимания, но вот требуют кроссбраузерность «пиксель-в-пиксель» касательно позиционирования. То, что ФФ и ИЕ по разному отображают списки (пример абстрактный) — это ведь тоже «техническая допустимая погрешность» или нет?

                  0
                  Что-то у меня есть подозрение что они просто не догадываются что шрифты могут быть разными.
                    0
                    Если про сглаживание — то догадываются, обычно админы объясняют почему шрифты на разных машинах по разному выглядят, а вот про то, что шрифта вообще быть не может — приходиться объяснять, чаще всего когда выбирают что-то из поставки MS Office (вроде он, давно не сталкивался, кучу шрифтов ставит, которых по дефолту даже в винде нет)
                      0
                      Бывает встречаюсь в офисе с заказчиками… у некоторых на ЖК мониторах неправильное разрешение стоит. И ничего. работают.
              +3
              Как то вы не так ТЗ пишете.
              Должно быть
              1) Цели и задачи проекта — …

              Далее по полочкам(по средствам достижения целей) расписано как будете этих целей достигать.

              По вашему же описанию выходит, что цель — втюхать клиенту список услуг.
                0
                Первым требованием к верстке я пишу что-то вроде: На момент сдачи выполненной работы сайт должен быть свёрстан на языке разметки xHTML 1.0 Strict в соответствии со стандартом, рекомендованным Консорциумом World Wide Web, размещенными по адресу www.w3.org/TR/xhtml1/, и проходить валидацию (проверку синтаксиса языка) по адресу validator.w3.org/.

                Потом то же самое про CSS, иначе, по вашему варианту, просто непонятно откуда взялись требования к HTML и CSS, а не, например, к «чистому» XML и XSL :)
                  +1
                  что важнее? стандарты или кросс-браузерность?
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +1
                      Речь все таки об IE — пару раз былипроблемы с оперой, но как то все таки решались…
                      Кстати насчет Strict — а в админке каким редактором пользуются клиенты? Он генерит код именно в стандарте strict?
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                        +1
                        Клиенту решать, если я вдруг сообщу, что данный функционал я не смогу реализовать в рамках стандарта. Хотя такого еще не было, в конце-концов есть вполне валидные (по букве, а не по духу стандартов) способы обойти большинство встречающихся «расхождений во мнениях».
                    +2
                    Я бы IE 6.0 исключил из списка поддерживаемых браузеров. Его доля очень стремительно падает, а тратить время верстальщиков на подгонку верстки под мертвый браузер нерационально. Мы ставим заглушку с просьбой обновить браузер.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        клиенты бывают разные, кому то удается объяснить и на сайт вешается предупреждение, а для кого то приходится верстать и под 6ку
                          0
                          Знаете, мой клиент на вопрос об верстке для ие6 спросил меня, что с ним не так, кроме того, что он убогий? Я объяснил в двух словах, пояснил, что это главным образом отразится на сроках и цене. Он ответил так, как я не ожидал: те, кто используют ие6, едва ли будут пользоваться его сервисом. Я еще больше удивился, когда он сам начал прогнозировать, что мол «с выходом семерки все перелезут на нее с хр». Вот такая адекватность.
                          +9
                          почему бы не включить подгонку под ИЕ6 отдельной строкой в смете? :)
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Да еще под каждую версию ;)
                          +1
                          Как-то вы так круто объединили в один пункт весь графический дизайн: а где креативная концепция, где дизайн-концепция, где дизайн внутренних шаблонов и т.д.

                          И мы как-то стараемся разбивать проект на этапы, которые мы указываем в смете и сроки по каждому этапу, кстати.
                            0
                            да, конечно календарный план обязательно, допишу
                            скажите, вы дизайн на составляющие делите в каждом проекте или нет? в каком соотношении приблизительно приходиться?
                              0
                              Делим дизайн всегда по стандартной схеме: креативная концепция (2-3 варианта), дизайн-концепция (1-2 варианта), дизайн внутренних шаблонов ( шт.), технический дизайн (может разбиваться на подпункты). Единственное что может отсутствовать, это тех. дизайн, все остальное — наши требования. Мы не будем заставлять дизайнеров работать в «краске», если сама идея изначально не утверждена.
                            +1
                            Не пишу ТЗ — ленюсь. :-( Точнее, писать все-таки приходится (чтобы у заказчика с отчетностью все было в порядке), но постфактум и когда-нибудь потом — по сути в виде отчета «что сделал». И трекер проектов очень хочется использовать, но как слали все e-mail'ы и звонили по телефону — так и продолжают слать и звонить…
                            Что в итоге? А то что заказчики не любят даже под дулом пистолета морочиться со всякими ТЗ и тем более проджект-трекерами. И поэтому я могу выставлять им цену как минимум в полтора раза выше за предоставляемый сервис и они готовы платить за то, чтобы у них ничего этого не было. :-)
                            А что касается постоянно упоминаемых (в каждой статьей о менеджменте проектов это есть) ситуаций из серии «Нас попросили сделать то-то, а мы — ХА! — Этого не было в ТЗ!» — это, конечно, прекрасно, но что же я за менеджер буду, если не смогу без заранее кропотливо расписанного перечня действий разрулить ситуацию и развести клиента на дополнительные деньги??? Подобного менеджера надо тут же гнать в шею за банальное неумение работать с клиентами! А как показывает практика — даже при наличии ТЗ клиенты все равно «достают». А начинаешь им этим ТЗ в лицо тыкать — считай больше ты с ними работать не будешь — найдут других, кто цену скажет больше, но зато будет их «облизывать»…
                            Впрочем, все вышесказанное конечно лишь ИМХО и личный опыт, не претендующий на объективность и всеобъемлимость. :-)
                              –1
                              Статья для пиара workstation? :)
                                0
                                ну конечно
                                как вы сразу зрите в корень
                                правильно только worksection
                                (почти как его ворсейшество)
                                еще для пропаганды basecamp турбомилка хабрахабра, написания тз и здорового образа жизни
                                  0
                                  Турбомилк и бейскэмп не являются продуктами Пулы ;)
                                +1
                                Очень, очень огорчили слова об откатах в первой части методички.
                                Сколько можно способствовать воровству?
                                Автор, вы понимаете, что это фактически участие в краже?
                                Зачем начинающему менеджеру эта информация? Сразу взять старт в нужном направлении?
                                А вот мы не даем откатов, и поверьте, это совершенно не мешает работать!

                                В целом по материалу: профессиональный менеджер продаж и менеджер проектов, уж простите, но не понял о ком речь в материале, должен настолько ориентироваться в области своей работы, чтобы «на лету» генерировать и реализовывать индивидуальный план действий под любую ситуацию. Методички загоняют в рамки. Реальная задача: выстраивание отношений бизнес-клиент — это разовая работа и по методичке ее не сделаешь.
                                  0
                                  дорогой Nimax
                                  прошу заметить, я не проявляю эмоциональной окраски, не говорю «я-я-я натюрлих откат гут»
                                  я лично считаю что бизнес это минивойна
                                  использовать химическое оружие запрещено, но знать о нем неплохо бы, когда с долин поползет зеленый дым
                                  точно также и с откатами — я лично против, поскольку на длинной дистанции это все равно не поможет.
                                  но вот совсем зеленому чувачку, возможно, интересно будет как это бывает.
                                  Опять же, суперпрофи может конечно генерировать ТЗ и план продаж просто исходя из запаха клиента. В начале статьи я написал, что информации потенциальна интересна для начинающих.
                                    0
                                    Ок, Ваша позиция ясна.
                                    В любом случае стоит уточнить, что отбросив вопросы честности (хотя их нельзя отбрасывать) начинающий менеджер должен понимать психологию откатчика — такое контактное лицо теряет интерес к работе ровно в момент получения денег т.е. автоматом весь проект оказывается под угрозой срыва.
                                  +1
                                  Вообще не знаю, почему вошло в практику пугать заказчика ТЗ — ведь это должен быть внутренний документ студии. Многие заказчики не отличат Flash от Javascript, не говоря уже о таких страшных фразах, как «язык разметки xHTML 1.0 Strict». В документе, описывающем требования заказчика, должно быть все написано на понятном ему языке, иначе этот талмут будет утвержден для отчетности и положен на полку. В результате — потраченное время менеджера и заказчик не представляет, что же ему сделают.

                                  Я больше склоняюсь называть этот документ «спецификацией», в которой должны быть описаны функциональные особенности — как с точки зрения пользователя все должно работать (а никак не программиста), идеальный вариант — снабдить кликабельными макетами. И никакая рыба тут не поможет.
                                    0
                                    Мы например больше используем т.з. для описания структуры сайта, для того, чтобы заказчику не вздумалось добавить (убрать) парочку ключевых разделов.
                                      0
                                      согласен с вами
                                      схематические кликабельные макеты — отличный вариант
                                      в принципе для их построения я и рекомендовал посмотреть на axure
                                      0
                                      статья реально полезная… даже человеку, который вроде все так и делает, только вот… какие-то мелочи все же упускаю, клиенты же разные бывают… и приходится каждый раз изобретать все тот же велосипед
                                        0
                                        спасибо, рад если вам помогло
                                        0
                                        вполне адекватная статья. все правда банально, но правильно :)

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

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