Контрпродуктивная тайна переписки
Почту постоянно стараются сделать более функциональной, сделав работу с письмами проще и осмысленнее. Так, Inbox от Google или новое приложение Alto Mail от AOL добавляют Swipe-жесты для быстрой архивации ненужных сообщений, фильтры для сортировки и автоматическое извлечение важных деталей, к примеру, даты и времени вылета, в отдельные карточки. То есть появляется подход к почте как к инструменту управления задачами.
Эти нововведения, безусловно, помогают лучше структурировать работу с входящими сообщениями и избавиться от таких типичных проблем, как потерянные в переписке файлы или вылетевшие из головы дела. Недавно такой подход взяли на вооружение и мы, переделав работу с уведомлениями из системы управления задач в своих мобильных приложениях. Когда в Wrike для Android и iPhone появилась возможность обрабатывать поток уведомлений как список дел, число пользователей, работающих с уведомлениями, подскочило с 30% до 70%.
Это, однако, помогает только с личной продуктивностью, а более фундаментальные проблемы email лежат в плоскости совместной работы. Недавний опрос, проведенный нами, показал, что в топ причин, снижающих продуктивность работы на командном уровне, входят ожидание ответа других людей и трудности с доступом к необходимой для работы информации.
Переписка по почте — крайне непрозрачный канал коммуникации. Прогресс по задачам обсуждается в отдельных цепочках писем, куда входят разные группы людей. У команды нет быстрого доступа к акутальной информации по всему проекту и к последним версиям всех нужных файлов. Значит, сотрудникам приходится тратить время и каждый раз заново запрашивать эту информацию друг у друга.
По идее, эти проблемы на раз решаются системами для совместной работы, цель которых — обеспечить общий контекст работы, доступный для всех. Там можно собрать воедино все описания, обсуждения и файлы по задачам, обеспечить быстрый доступ к информации, сразу понять над какой стадии все находится, в конце концов.
Но, как уже упоминалось, немногие готовы отказаться от почты. А раз нельзя победить, можно возглавить, то есть правильно интегрировать email в более продвинутый набор инструментов для управления проектами. В принципе, мы не только думали над тем, как это могло бы выглядеть, но и реализовали кое-какие идеи такой связки в Wrike.
Эффективное сосуществование
Во-первых, правильная интеграция почты с сервисом не должна затрагивать сложившиеся привычки пользователей. Никто ничего не блокирует и не запрещает. Сотрудники могут вести переписку по старинке. Что важно, так это обеспечить быстрый и комфортный способ экспорта этой информации в единое облачное хранилище, где сосредоточены все ресурсы и обсуждения задачи. И мы решили, что самый простой способ — просто переслать важное письмо в рабочее облако на wrike@wrike.com, где на его основе сразу будет создана новая задача.
Во-вторых, интеграция должна быть двухсторонней. Поклонники email также должны быть в курсе всех изменений в Wrike по задачам, которые их интересуют. Поэтому все уведомления об обновлениях по проектам автоматически высылаются сотрудникам на почту. При этом мы не заставляем человека переходить из почты в Wrike, чтобы оставить там комментарий в обсуждении. Это можно сделать просто ответным письмом. Можно даже прикрепить к этому ответу файлы.
В-третьих, нужно позаботиться о рабочем окружении. В случае с почтой это приложение, в котором пользователь ее читает. Мы сделали несколько плагинов для популярных клиентов: Outlook, Mac Mail, Gmail, которые делают примерно одно и то же — позволяют более продуктивно использовать окно просмотра сообщения. По сути, плагин позволяет превратить письмо из Wrike в полноценный рабочий экран, где вы можете исправить описание и статус задачи, добавить файлы и комментарии, назначить исполнителя и т. д.
Стоит отметить, что мы не призываем ставить Wrike. В той или иной степени над приданием большего смысла электронной почте работают и наши конкуренты. Главное, что наш опыт показывает, что и email можно поставить на службу продуктивности. Главное уметь его приготовить — то использовать в нужной пропорции и в сочетании с нужными продуктами.
Комментарии (6)
hzs
18.02.2016 22:47+4Для разработчика, особенно разработчика-одиночки, чего бы то ни было, электронная почта может являться самым оптимальным средством общения.
Конечно, существуют случаи, когда надо что-то обсудить, что-то уточняя с собеседником, тогда на помощь придёт телефон.
Для меня электронная почта — это лучший способ коммуникации, когда сосредоточен на работе, обмозговываешь код, не должно абсолютно ничего отвлекать и мешать, ведь стоит отвлечься и всё, потерял мысль, потом снова полчаса настраиваться на нужный ритм.
Почта не требует ответа сразу, можешь прочитать, когда у тебя есть время, ну и не забудешь чего-то, так как можно потом посмотреть архив.
MiXaiL27
19.02.2016 04:50+1Итого проблема почты в том, что её пытаются использовать не для отправки писем, а каких-то левых целей. CRM или таск-трекер с рассылкой уведомлений по почте о смене статуса или постановке новой задачи вполне подойдет для мобильного сотрудника.
Zzzuhell
19.02.2016 09:45раз нельзя победить, можно возглавить
Правильная цитата: "Если пьянку нельзя предотвратить, ее надо возглавить".
По теме — мне известна компания, в которой официальных каналов коммуникации с клиентами два — email и телефон. Аська/скайп не запрещена, но активно не приветствуется.
При этом звонки дополнительно пишутся и заносятся в CRM. Удобно, хотя и немного архаично.
airosa
19.02.2016 16:59+1То что вы описали — не проблемы почты, а особенности вашего рабочего процесса. К почте, как к каналу общения, это все имеет мало отношения, ну а то что вы встроили обработку почтовых сообщений в свою систему — ну это здорово.
Просто название и содержание статьи выглядит так: Конкретно нам не подходит почта — поэтому мы её не любим в принципе!
Не понимаю почему так хотят закопать электронную почту? Это оптимальное средство для корпоративного общения. История есть, вложения файлов есть, доступ оффлайн есть, шифрование и подтверждение что письмо пришло от того от кого должно было прийти есть (можно прикрутить), универсально — есть практически у всех. надежно и известно. Можно поднять свои почтовые сервера, что важно для многих.
Coriander
20.02.2016 01:08А что такого сложного в использовании почты? Вы напоминаете мне опытного пользователя фреймворков, который настолько привык к сложностям, что у него вызывает затруднения сложения сложение двух целых чисел — он не уверен, какой из трёх фреймворков для этого стоит использовать.
Чтобы понять, как и для чего использовать почту стоит просто отмотать полоску времени на десяток-другой лет назад. В те времена народ не особо сомневался для чего пользоваться почтой. Антагонизм веба и почты из тех времён, сегодня он стал совсем незаметным. Но вы ещё помните, что он был, хотя и забыли зачем.
Сейчас почта не соревнуется с вебом, потому что веба считай что не осталось. Вместо паутины данных появилось проста куча портабельных приложений. Веб приложения сейчас — это ява десять лет назад. Изначально, конечно, javascript не мог заменить java, но народу почему-то очень-очень хотелось. И вот сегодня javascript имеет доступ к сокетам, opengl и файловому хранилищу. Фактически, внутри браузера на javascript вы можете написать полноценное пользовательское окружение, как будто ОС, включая браузер и почтовый клиент. Согласитесь, конфликт почты и веба в этом случае — это очень странная постановка вопроса, ведь на нынешний день веб включает в себя всё остальное.
Забудем на минутку, что у нас есть javascript. Чем тогда будут отличаться веб и мейл? Многим. Но принципом запрос-ответ пользуются оба, а значит возможности у них совпадают: почтовый ящик можно эмулировать на http и отсылать письма через http post, и когда-то вполне существовали программы, которые заворачивали веб страницы в тело письма и отсылали по требованию через почту. Популярны были, когда интернет был дорогой, а почта — бесплатной. А веб был вебом, а не джавой и мог работать оффлайн без скриптов. Отличие почты и классического веба в том, что при равенстве сценариев использования, разнится их удобство. Веб предназначен для разглядывания статики и REST, а мейл ориентирован на event-driven архитектуру.
В старые добрые времена ценили обе эти возможности, и согласно принципам unix комбинировали обе, чтобы на базе простых сервисов поднять более сложный концептуально, где веб сервисы, почтовые боты, и клиентские скрипты создавали цельный опыт взаимодействия для пользователя. Вот как вы сейчас хотите сделать. Правда вы уже отказались от unix принципов, и email вам мешает как телеге пятое колесо.
Так вот, вы жалуетесь на пользователей ретроградов, которые по-прежнему предпочитают электронную почту единому интерфейсу вашей прекрасной системы, содержащей всю функциональность почты и даже больше, лучше, красивее. На самом деле я не проверял, но поверю, что так оно и есть. Что же заставляет клиентов продолжать использовать почту?
Функциональность у вас не слабее, так что методом исключения приходим к тому, что удобство ниже. Возможно это шокирует современных дизайнеров, что отсталая грубая почта может быть удобнее для кого-то, но факт наличия таких пользователей вы сами признали.
Подобные неприятные открытия вообще характерны для разработчиков огромных громоздких программ-комбайнеров. Казалось бы, у них всё замечательно, цельный интерфейс в едином стиле, полное окружение, из которого пользователю вообще не нужно выходить. Но не надо себе льстить, вы не можете сделать действительно полного окружения. Подобные программистские ресурсы есть всего у нескольких компаний вроде аппла и майкрософта, но даже хотя они способны собрать полное окружение, пользователи всё равно половину их программ заменяют на программы сторонних разработчиков.
Составить действительно удобное и полнофункциональное рабочее окружение для пользователя — задача не подъёмная для одной компании, только совместной работой, где каждый делает свою небольшую часть, можно построить такое окружение.
Почта — это не какой-то конкретный убогий клиент, это протокол. Общий для многих, очень многих применений. И значит пользователь, может подобрать идеально подходящий именно для него почтовый клиент, который будет работать как ему удобно, сверяться с расписанием, выводить нотифаи поверх окон, и что ещё его душе угодно. Опять же почтовый ящик — это обычная директория на диске, по ней можно искать с помощью файлового менеджера, и вообще автоматизировать разбор почты с помощью батч скриптов.
Это всё, конечно, на любителя, кто-то использует одни фичи почты, кто-то другие, и каждый будет настаивать, что именно его способ работы с почтой уместен и удобен. Но есть одна общая фича, которой, я уверен, пользуется каждый, и которую не может предоставить ваша программа по определению. Это возможность одним почтовым клиентом читать письма от всех контактов. Единообразно можно работать с деловой перепиской, системами автоматизации, мониторинга и т.д. Единожды потратив время на настройку клиента, пользователь повышает удобство работы сразу со всеми остальными системами, способными работать через почту. Какой бы хороший клиент не предоставляли эти системы, почта имеет своё неотъемлемое преимущество общности.
Вы написали, что пошли на встречу пользователям почты и предоставляете плагины для работы с почтой. Мне вот любопытно, до какой степени. Используют ли они возможности почты для организации протокола связи, шлют ли команды и принимают апдейты через почту, или это тупо веб страничка, обманом протащенная в почтовый клиент по принципу каши из топора? В первом случае, я рад за ваших пользователей, потому что они смогут построить взаимодействие с вашей системой через любой почтовый клиент, даже тот, который вы не поддерживаете напрямую. А во втором случае мне их жаль, потому что всячески пытаетесь вытеснить их рабочий инструмент тем, что вам удобнее программировать.
Приведу простой сценарий использования. Допустим, у клиента нет доступа к интернету за исключением почты, которую по какой-то причине специально разрешили. Не важно как, возможно даже почтовые порты тоже закрыты, а почту доставляет какой-то особый прокси время от времени. Было бы крайне желательно, чтобы в этом случае он мог продолжать пользоваться системой, посылая команды внутри писем. И если вы реализовали почтовые плагины честно, то у него будет такая возможность. Как в старые добрые времена.
EmmGold
Так почему вы не любите email? Очень удобно. Не нужно дёргаться и отвлекаться. Можно почитать офлайн, конечно если «креативный дизайнер» не напичкал письмо элементами из внешней сети. Нет обязательного подтверждения при прочтении.