GSA

Вроде парадоксальная ситуация получается. Зачем же ты платил, если оно тебе не нужно. Бывает менеджеры удачно продали, бывает конкуренты открыли сайт и ты себе сразу же захотел, а потом уже понимаешь, что оно собственно и не надо было.

Я просто обожаю людей, которые способны признать свои ошибки. В данной ситуации это значит, что клиент понимает “я заплатил 50%, сайт мне уже сделали, надо платить остальные 50%”. Самые шикарные клиенты. Периодически кто-то спрашивает “а дальше мне с ним что делать?”. Тут я пытаюсь посоветовать, чего реально с ним можно сделать, какую информацию лучше разместить и т.д. Read more

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

2. Короткое описание задачи, но уже на e-mail.
К сожалению ICQ, Skype – это не так надежно. В почте меньше вероятность отмахаться по типу “ой, а я не получил”, “ой, а оно мне дома пришло и я забыл” и т.д.
Если вас слушают и хотят понять, то это отличный способ. Вы не тратите много времени, а результат получают. В других случаях основная проблема это, то что задача короткая. Велик шанс быть неправильно понятым. Это и есть самая классическая отговорка, с которой я сталкивался: “тут ни ясно написано”. Очень удачно использовать, когда задача маленькая и не требует больших затрат времени, но сотрудника нет на работе (в поле досягаемости). Подразумевается, что такая задача должна быть выполнена, как можно быстрее.

3. Полное описание задачи в каком-то софте (таск-трекер / какой-то софт по совместной работе и т.д.).
Это самое нормальное, когда ты не знаешь, с кем ты работаешь или большая и сложная задача. Если ты работаешь с проверенными людьми, которые не первый раз видят этот проект, или проекты шаблонные, то можно не расписывать каждую новую задачу по полной. Если мозг detected, то они сами знают и сделают как обычно. Если же задача новая, то надо описывать всё и полностью. Опять же, если человек “свой”, то важно донести цель и задачу того, что он пишет. Всегда помните о том, что вы не самый умный, а специалист всегда может что-то подсказать. Но для этого специалист должен понимать зачем оно это все надо. Если же это просто исполнитель (в плохом смысле), то не утруждайтесь донесением целей. Все равно будет сделано ровно то, что написано.
Подобные задачи не могут быть выполнены “как можно быстрее”. Такие задачи всегда должны иметь срок. Задача без срока – не задача.

4. Readme – сделай файл и спи спокойно.
Очень интересный аспект. Если вы ставите задачу профи, то профи (глядя на дизайн/верстку и т.д.) на 80% уже знает, что делать. Особенно учитывая, что я описываю опыт работы в веб-студии, а это конвейер, то и на все 99% каждый знает, что делать. Так вот в редких случаях достаточно сделать файл readme и отравить вместе с psd/html/etc. Но так можно только с проверенными людьми.

Все любят работать с людьми, которые добросовестно выполняют свою работу. Я не исключение. Висеть над душой у человека круглосуточно это не очень веселое занятие. К тому же если видно, что человеку плевать на то, что он делает, то как можно ставить такому человеку задачу? С такими людьми лучше не работать.
Сейчас работаю с верстальщицей (всем рекомендую! за контактами обращайтесь лично) – все супер. У всех есть свои недостатки. Но для этого собственно и есть менеджеры, которые знают их и умеют с этим работать. Начинали мы с тех. заданий на верстку, потом ТЗ уменьшались в объеме, потом некий свод правил, а сейчас просто readme файлы периодически и все.

Выводы (аккуратно, чистое ИМХО!):

• если человек не хочет работать, не надо с ним работать;
• незаменимых людей нет и вы полный @&#$#$%$#%, если сотворили в своей команде незаменимого человека;
• донести зачем это надо важнее, чем донести детали чего непосредственно надо;
• не работайте с теми людьми, которые к вам относятся плохо (пусть даже они выполняют свою работу) или к которым вы относитесь плохо. Команда включает понятие “единомышленники”.

По сути только три человека могут сделать коммерческое предложение, контактируя с клиентом. Непосредственно менеджер по продажам, аккаунт-менеджер, и проект-менеджер.

Менеджер по продажам делает коммерческое предложение непосредственно при продаже – первый контакт. Далее, этот же человек может выполнять обязанности аккаунта и работать с клиентом дальше. Скорее всего сделать хорошее и правильное (в плане цифр и сроков) КП продажник сделать не сможет. Посудите сами. Откуда продажник или даже аккаунт знает, какие ресурсы сейчас свободны, какие будут свободны дальше, каким ресурсам можно дать эту работу, а каким нельзя. // Сорри всем кого обозвал ресурсами. :)

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

Как вывод. Коммерческое предложение составляется вместе с руководителем проектов и продажником/аккаунтом. Одни знают клиента и как лучше ему предложить и что ему предложить. Другие знают смогут ли они это сделать, за сколько и в какие сроки.

У некоторых компаний встречал темплейты для коммерческих предложений. Видел решения автоматической генерации. А учитывая открытость .docx такой генератор коммерческих предложений вполне может написать каждый.

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

Был, да и сегодня есть, у нас один клиент, который заказывал интернет-магазин довольно специфической тематики. Основное то, что товаров там уйма, десятки тысяч.

Клиента представляла девушка. Я не знаю, какую должность она занимает у себя в компании. Даже могу сказать, что девушка сама по себе хорошая и делала все что могла, что бы сайт сделали хорошо. Проблема заключалась в том, что она не принимала решений. Это еще пол беды. Основная проблема была в том, что замечания и пожелания поступали от высшего руководства. А руководство было достаточно умно и неплохо разбиралось в нюансах разработки сайтов.

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

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