Что плохого в почтовых программах

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

Те, кто впервые начинает пользоваться электронной почтой, восторгаются ранее неведомой возможностью коммуницировать с другими напрямую, легко и просто, и к тому же асинхронно. Но просто решить задачу коммуникации не значит помочь пользователю достигнуть его целей, поэтому обмен электронными сообщениями все еще функционирует на самом примитивном уровне. Проблемой является неверное понимание того, для чего применяется электронная почта на самом деле. Двадцать лет назад получение каждого электронного сообщения считалось великим событием. Но возвеличил сообщения сам способ их передачи – фактически ничего ценного они собой не представляли. На деле это был просто отдельный файл без каких-либо особых параметров и взаимосвязей, содержащий неформатированные символы из набора ASCII.

В настоящее время всем нам приходит множество как нужных, так и бесполезных электронных писем. Каждый человек, активно использующий электронную почту, быстро понимает, каким мощным и полезным инструментом она является, и начинает применять его все чаще и чаще, пока на него не приходится значительный объем деловых и личных сообщений. Ежедневно на электронные ящики большого количества пользователей поступают десятки и сотни писем. Значительная часть из них приходит в ответ на прошлые сообщения либо в ожидании отклика. Такие связанные сообщения, иначе называемые «цепочками», курсируют туда-обратно между двумя и более собеседниками. Количество цепочек писем на моем компьютере по отношению к одиночным сообщениям составляет приблизительно 50 к 1. И все еще ни один почтовый клиент из доступных на текущий момент не увязывает такие сообщения в последовательность^[9]. Все это выглядит так, словно связанных сообщений не существует в принципе или же это несущественный атрибут небольшого количества отдельных писем.

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

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

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

Программа для работы с электронной почтой – не единственный пример программного обеспечения, которое не позволяет эффективно выполнять простые и очевидные базовые задачи. Мы так зачарованы пляшущими медведями, что не замечаем неадекватности всей ситуации. Приведу еще несколько примеров.

Что плохого в программах-планировщиках

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

С точки зрения разработчика управление проектом сводится к задаче планирования, да еще, возможно, к дополнительным ухищрениям вроде анализа методом критического пути, при котором начало каждой следующей задачи зависит от завершения предыдущей. Все имеющиеся на сегодня программы управления проектами основаны на этом чисто теоретическом предположении^[10]. Проблема состоит в том, что такой взгляд на управление проектами имеет мало общего с действительностью.

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

Чтобы от таких программ управления ресурсами была польза, в них должна осуществляться интеграция трех плоскостей проблемы: времени, проектов, ресурсов. Но мы взамен получаем программы, которые учитывают только две плоскости – ресурсы и время, при этом разработчики таких программ настойчиво убеждают нас, что этих плоскостей нам вполне достаточно. Как бы ни называли подобные программы – «менеджеры трафика», «программы управления проектами», «программы распределения ресурсов», – такой жизненно необходимый сегмент на рынке приложений не представлен.

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

Что плохого в календарях

Практически каждый человек так или иначе пользуется электронным календарем для планирования рабочих задач. Нам доступен выбор из множества программ, но при этом почти все из них упрямо игнорируют самые простые способы, как человек обычно использует календарь. Проще говоря, в календаре должно отражаться то, как люди распределяют время для контроля своей жизни. В целом все объекты, зависимые от времени, можно разделить на две категории: текущие дела и дедлайны. К дедлайнам относят крайние сроки, до которых часть проекта или дела должна быть исполнена; иными словами, это некая контрольная точка хода проектирования. Текущие дела – это, например, командировка на двое суток. А в ходе этой двухдневной поездки в Чикаго у меня, скажем, назначено три встречи с разными клиентами.

Все существующие программы-календари устроены так, что дедлайны и текущие дела в них не учитываются, а вместо этого все построено на встречах. Но встреча представляет собой однократное событие с определенным временем начала. Встреча – неотъемлемый компонент тайм-менеджмента, но далеко не единственный. И дело не ограничивается отсутствием других типов записей для календаря, даже эти встречи имеют искаженное представление.

Обозначать время начала встречи куда как более важно, нежели ее окончание, но календари не делают разницы между этими двумя моментами. За последние тридцать лет я участвовал или назначал сам тысячи встреч. Невероятно важным является именно время начала встречи. А вот время окончания в большинстве своем такого значения не имеет, его не указывают и часто оно даже неизвестно. Но в каждой календарной программе, что мне попадалась, у всех встреч был атрибут времени окончания, который требовалось обозначить с той же тщательностью, точностью и усердием, что и время начала. Это значение времени окончания используется для вычисления точных часов и минут, в которые вы будете доступны для связи, что на самом деле не может быть обозначено достоверно и значительно искажает действительность. Представим, что вы отправите мне приглашение на встречу на три часа дня при помощи стандартной программы-календаря. Если у меня уже назначена другая встреча, к примеру, на 14:30, длительностью 35 минут, то программа отклонит ваше приглашение. На деле же я всегда могу улизнуть с предыдущей встречи на пять минут пораньше.

Помимо этого, ни в одной из подобных программ не учитывается время, за которое я должен добраться до назначенного места. Если у меня назначена встреча на другом конце города в 14:00, то мне нужно выехать на нее в 13:30. Какое время в этом случае мне внести в календарь – 14:00 или 13:30? Хорошо спроектированная программа должна учитывать этот момент и следить, чтобы я вовремя попадал куда нужно.

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

Массовая интернет-истерия

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

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

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

Однако стоит нам отвлечься от вопросов установки, и мы увидим, что браузеры слабы, словно новорожденные котята. Их язык, на котором они говорят с пользователем, напоминает доисторический диалект. Их архитектура похожа на чью-то злую шутку. И они столь же гибкие, как сосульки. Любому приложению, заключенному в рамки браузера, непременно приходится жертвовать своими возможностями и невероятной мощью. Меня разрывает от ярости, когда я вижу, что творят руководители со своими программами: портируя приложение под Веб в стремлении освободиться от процесса установки, они тем самым просто вырывают ему сердце. Тогда как они могли бы достигнуть того же результата, если бы просто сказали своим разработчикам: «Будьте так добры, избавьте это приложение от процесса инсталляции!»

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