{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Как мы наладили обмен информацией между отделами

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

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

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

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

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

Первое, с чего мы начали - внедрили систему фиксации задач, которая была бы делала процесс их поставки и выполнения абсолютно прозрачным всем сотрудникам компании. При этом, система должна быть максимально простая, чтобы снизить время, затрачиваемое на обучение ее использованию. Мы выбрали Trello.com. Написали регламент ее использования, который уместился в половину страницы А4, и уже через пару дней беготня людей между отделами снизилась, крики "Я уже сто раз говорил, чтобы поправили текст на кнопке" прекратились. Общение перешло на более конструктивный уровень: "Я поставил задачу в Трололо, проверь" и "Задача висит уже 3 дня, расскажи, что мешает ее взять в работу".

Через несколько дней мы обнаружили, что скорость выполнения задач при таком подходе снова снизилась. Отдел разработки у нас работает удаленно и просто саботировал использование Трелло. Исполнение задач снова встало под угрозу. Нужно было новое решение - живой человек, который бы был в постоянном контакте с разработчиками и держал руку на пульсе, разъясняя непонятные задачи, выставляя для них приоритет и разгребая оперативные "грабли". И такой же человек - со стороны разработчиков.

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

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

Все это мы прописали в регламенте и сделали обязательным. Процесс пошел!

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

Комментарий удален модератором

Развернуть ветку
-3 комментариев
Раскрывать всегда