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

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

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

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

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

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

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

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

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

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

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

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

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

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