Пользовательский интерфейс (часть 1)


«Встречают по одежке…» — именно так звучит народная поговорка. Сложно спорить с народной мудростью. Да и зачем? Все мы знаем, какие у нас ощущения вызывают неопрятные и неаккуратные люди, с которыми иногда приходится пересекаться или по работе, или в быту. А вспомните «вонючек» в общественном транспорте… Неопрятный кандидат на должность менеджера по продажам вряд ли будет успешен при поиске работы. В конце концов, как правило, красивые люди по жизни имеют больше поклонников и поклонниц. На красивых людей приятно смотреть. Внешний вид — это первое впечатление. И только потом ты будешь разбираться, а кто красавец или красавица по сути. Но первое впечатление зачастую предопределяет отношение к человеку в будущем или даже вообще определяет решение, будешь ли ты иметь дело с человеком или нет.

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

Как разработать аккуратный и удобный интерфейс? Существует множество литературы по проектированию пользовательского интерфейса, по его эргономике, интуитивности и юзабилити. Свои концепции предлагают все кому не лень. Но думаю, начинать нужно с того, что предлагают «законодатели мод» в индустрии программного обеспечения. Я имею в виду Apple и Microsoft. Эти авторы наиболее популярных ОС (Mac OS и Windows) и программ предлагают разработчикам все, что нужно для разработки программного обеспечения — начиная от технических возможностей (API, Фреймворки, среды разработки…) и заканчивая технической документацией, правилами и руководствами. Пользовательский интерфейс не является исключением — обе компании предлагают разработчикам фундаментальные документы с рекомендациями и правилами по разработке пользовательского интерфейса, а именно: «Apple Human Interface Guidelines» и «Windows User Experience Guidelines».

Почему важно следовать этим правилам и рекомендациям:

— Пользователю будет легче освоиться в программном обеспечении, интерфейс которого будет похож на интерфейсы других программ, которыми пользователь уже пользовался. Пользователь сможет перенести свой опыт работы на ваш продукт. Нет ничего плохого, если вы подсмотрите интерфейсные решения в программах Microsoft или Apple.

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

— Программа будет выглядеть так же современно и элегантно, как и другие программы от Apple или Microsoft.

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

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

Характеристики хорошей программы

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

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

— Привлекательная внешность. Пользовательский интерфейс программы должен выглядеть профессионально. Используйте высококачественные графические элементы, такие как иконки для панелей инструментов, иконки программы и документов. Используйте расположения элементов дизайна (диалоговые окна, панели инструментов, сообщения, вид документа и т.д.) в соответствии с «Apple Human Interface Guidelines» и «Windows User Experience Guidelines». Используйте стандартные элементы дизайна, которые предлагает ОС, такие как, меню, элементы интерфейса, диалоговые окна. Например, если система предлагает стандартный диалог для печати, то не нужно разрабатывать свое собственное диалоговое окно для печати.

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

— Адаптивность. Программа должна работать в переменчивой среде. Скажем, если программа работает в сетевом режиме, и сеть неожиданно пропадает, программа должна разрешить пользователю работать дальше вне сети. Если какие-то ресурсы или данные заблокированы, программа не должна прекращать работу. Убедитесь, что программа отрабатывает ситуации, когда пропадает носитель данных. Не предполагайте, что компьютерные устройства будут всегда доступны. Конфигурации меняются от компьютера к компьютеру. Скажем, не все компьютеры оборудованы видеокартами определенной модели или не на всех устройствах есть беспроводный БлюТус интерфейс или видеокамера. Убедитесь, что программа нормально работает с разнообразными интернациональными настройками, такими как, формат даты, времени, десятичного разделителя. Убедитесь, что программа нормально работает с разными экранными разрешениями.

— Взаимодействие. Под «взаимодействием» имеется в виду способность программы обмениваться данными (то ли своими внутренними, то ли пользовательскими) через разные среды и окружения. Речь идет о поддержке буфера обмена данными между программами, чтения и записи разных форматов файлов на разных платформах, перетаскивания объектов программы (drag-and-drop), OLE, системных скриптовых языках и инструментах (AppleScript, MSI). Избегайте уникальных форматов файлов. Если этого избежать не возможно, используйте экспорт и импорт в стандартные форматы, чтобы пользователь мог обмениваться данными с разными программами. Используйте стандартные протоколы для передачи и обмена данными.

Так, например, можно использовать возможности ОС (например, OLE на Windows и AppleScript на Mac OS) для отправки данных из вашей программы прямо в слайд программы для подготовки презентации (MS PowerPoint или Apple Keynote). Т.е. пользователь нажимает кнопку в вашей программе, в результате запускается программы для подготовки презентаций, а в ней автоматически создается слайд с вашими данными. Для пользователя это горазда удобней, чем копировать данные, запускать программу, создавать слайд, вставлять данные. Или разработайте формат файлов документа вашей программы на базе унифицированных и стандартных технологий (HTML, XML), в результате ваши файлы можно будет открывать другими программами (скажем Internet Explorer или Safari).

— Мобильность. Хорошая программа учитывает мобильность устройств и оборудования. Особенно это важно, когда все больше и больше устройств становятся мобильными. Программа, учитывающая мобильность, не загружает нерационально процессор и не разряжает зря батарею устройства, без нужды не обращается к периферическим устройствам, не меняет разрешение экрана, не «будит» компьютер из «спящего» режима. «Мобильные» программы отрабатывают присоединение и отсоединение периферических устройства. Не требуйте от пользователя держать диск в приводе для работы программы. Используйте современные сетевые интерфейсы (печать через Bonjour). Адаптируйте пользовательский интерфейс программы под малые разрешения (скажем, 1280х600 на нетбуках).

Принципы пользовательского интерфейса от Apple

Принципы я перечисляю так, как они описаны в документе с рекомендациями и правилами по разработке пользовательского интерфейса от Apple («Apple Human Interface Guidelines»). Однако, я возьму на себя смелость добавить некоторые примеры пользовательского интерфейса для лучшего понимания сути того или иного принципа.

— Метафоры. Используйте пользовательские понимания и представления из жизни (и быта) для передачи концепций и функциональности вашего программного обеспечения. Типичные примеры метафор: папка, файл, мусорник, фотография, камера, альбом.

— Отражайте пользовательские ментальные модели. Наверняка пользователи уже имеют ментальную модель, которая описывает функционал вашей программы. Такая модель возникла из жизненного опыта или в результате опыта пользователя с другим программным обеспечением. Например, как и в реальной жизни, так и на компьютере, вы наверняка отправляли почту. Соответственно, процесс подготовки и отсылки почты предопределен и ожидаем пользователем именно в таком виде. Другой пример: если вы разрабатываете программное обеспечение с элементами электронных таблиц, то наверняка пользователи будут ожидать, что поведение ваших таблиц будет похожим на поведение популярных электронных таблиц от других разработчиков (MS Excel, Numbers). Другой пример ментальной модели — это работа с фотоматериалом. Пользователи будут ожидать, что в процессе работы с фотографиями нужно будет фотографировать изображения, добавлять картинку в альбом, сортировать альбомы и фото. Если программа воспроизводит музыку, то пользователь будет ожидать возможность поставить воспроизведение на паузу и возобновить, перейти к следующему произведению, перемотать вперед или назад, составить список воспроизведения, посмотреть обложку альбома и т.д. При этом пользователи могут ожидать, что процесс будет представлен так, как это организованно в других популярных программах. Необходимо, чтобы ваша программа отвечала пользовательской ментальной модели в таких аспектах:

+ Узнаваемость. Устоявшиеся ментальные модели базируются на прошлом опыте.

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

+ Доступность. Удобный пользовательский интерфейс важен, однако также важно, чтобы пользователь имел легкий доступ к существенному функционалу программного обеспечения.

+ Обучение. Предоставляйте пользователю подсказки о том, как использовать ту или иную функциональность.

— Конкретные и подразумеваемые действия. Конкретные действия четко определяют результат манипуляции с объектом. Пример: меню содержат команды, которые могут применяться к выбранному объекту. Название команды четко указывает, какое будет действие, а текущее состояние объекта (активное или неактивное) указывает, актуально ли то действие в текущем контексте. Подразумеваемые действия доносят до пользователя информацию о результате действия посредством визуальных подсказок и контекста. Пример: перетаскивание (drag-and-drop) иконки файла в мусорную корзину, подразумевает, что файл будет удален с компьютера.

— Прямое манипулирование. Согласно этому принципу объекты на экране должны оставаться видимыми, пока пользователь производит действия над ними, и результат действия также должен быть видимым. Пример прямого манипулирования:

+ Изменение размера графического объекта в графическом редакторе.

+ Позиционирование объекта или камеры в трехмерной сцене.

+ Перетаскивание текста в/из документа

— Пользовательский контроль. Дайте пользователю, а не компьютеру, инициировать и контролировать действия. Собственно, необходимо предоставить пользователям возможности, которые им необходимы, и вместе с тем помочь пользователям избежать опасности и необратимых действий.

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

+ Мигающий курсор. Программа готова к вводу данных.

+ Диалоговое окно с индикацией прогресса. Актуально для длительных действий (экспорт, импорт, математические вычисления, трансформации). Имеет смысл указывать, когда процесс закончится, процент выполненного действия или количество итераций, и т.п.

+ Крутящееся колесо или песочные часы. Индикация, что программа выполняет какую-либо команду. Актуально для коротких действий.

+ Мигающая панель задач (Windows) или прыгающая иконка в Доке (Mac OS X). Программа требует внимание пользователя.

+ Анимационный эффект, когда документ сворачивается в панель задач (Windows) или Док (Mac OS X).

+ Сообщения об ошибках.

+ Желтая, появляющаяся подсказка на панели задач.

— Согласованность. Согласованный пользовательский интерфейс позволяет пользователю переносить свой опыт с одной программы в другую. Используйте стандартные элементы дизайна (меню, команды, иконки и кнопки, радиогруппы, чекбоксы, и т.д).

Программа должна быть согласована:

+ с рекомендациями и правилами по разработке пользовательского интерфейса на данной платформе.

+ сама с собой. Используйте единую терминологию, названия команд, иконки, диалоговые окна.

+ с предыдущими версиями программы. Пользователи старых версий программ должны минимально переучиваться при переходе на новую версию программы. Обеспечьте совместимость форматов файлов.

+ с ожиданиями пользователей.

— WYSIWYG («What You See Is What You Get», «Что видишь, то и получаешь»). Убедитесь, что в программе, в которой пользователь может форматировать текст для печати, публиковать в сеть или записывать видео на диски, пользователь не заметит существенных различий в том, что он/она видит на экране и в том, что получится в результате работы программы. На распечатке, в сети или на диске, должны быть одни и те же данные, одна и та же форма и стиль из представления. Пользователь должен мгновенно видеть изменения, которые он/она делает в программе. Пользователь должен иметь доступ ко всем командам программного обеспечения. Все команды программного обеспечения должны быть доступны в главном меню — не добавляйте команды только в контекстное меню или в панель инструментов.

— Снисходительность. Работая с программным обеспечением, пользователи должны ощущать, что они могут пробовать разные действия и команды в программе без опасности для системы, программы или данных. Этим вы упростите пользователям процесс обучения. Поддерживайте в вашем программном обеспечении команду «Отменить» («Undo»). Сделайте эту команду многоуровневой. Если пользователь делает действия, которые приведут к потере данных, проинформируйте об этом пользователя в специальном сообщении. Обеспечьте пользователю достаточно информацией для того, чтобы пользователь мог делать правильные решения, работая с программным обеспечением.

— Ощущаемая стабильность. Ощущаемая стабильность обеспечивается предсказуемой средой и тем, что программное обеспечение выглядит знакомо и понятно. Достигается это за счет использования стандартного вида и поведения элементов дизайна.

— Эстетическая целостность. Эстетическая целостность означает, что пользовательский интерфейс хорошо организован и соответствует принципам хорошего визуального дизайна. Программное обеспечение должно приятно и аккуратно выглядеть. Используйте простую графику в вашем программном обеспечении. Не перегружайте окна и диалоги иконками и кнопками. Не используйте произвольные символы для отображения концепций. Разработайте иконки для вашей программы в едином стиле и в высоком качестве. Используйте стандартные системные шрифты и размеры.

— Модальность. Модальность — это способность программного обеспечения обеспечить пользователя возможностью в любой момент делать в программе то, что пользователь хочет. Избегайте режимов, когда работа пользователя в программном обеспечении блокирована какими-то процессами. Однако есть некоторые исключения:

+ Краткосрочные режимы, когда пользователю нужно делать что-либо для поддержания некоторого режима. Пример: удерживать кнопку мышки для того, чтоб пролистать текст или удерживать кнопку Шифт для выделения текста.

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

+ Программы-установщики, созданные в виде поэтапных шагов, цель которых провести пользователя по важным этапам установки программы.

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

Примеры:

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

+ Опции программы. В опциях пользователь делает наиболее типичные установки для своей работы.

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

+ Команды «вставка» и «специальная вставка». Команда «специальная вставка» предлагает дополнительные возможности, скажем, вставить картинку со связью или вставить как независимый объект.

to be continued

Техническая поддержка: сделай пользователя счастливым


Тема технической поддержки довольно-таки обширная. Условия предоставления, принципы, подходы, процессы и системы ПО для технической поддержки, зависит от сложности и качества продукта, от категории пользователей, на которых рассчитан продукт (бизнес, частные пользователи, техническая подготовка и т.д.), от популярности продукта, от компетенции персонала в вопросах тех поддержки и ряда других факторов.  
Я же хочу поделиться своим опытом и рассказать, как можно организовать техническую поддержку на небольшом проекте (до 30 человек), где производится и поддерживается "коробочный" продукт для конечных пользователей. Например, простенький графический редактор, просмотрщик картинок, почтовый клиент, или другой продукт, которым пользуется рядовые пользователи персонального компьютера или же специалисты из какой-либо отрасли.  
В этом контексте под технической поддержкой я понимаю процесс обработки обратной связи пользователей, в частности, сложности в использовании ПО. 
Далее я опишу критерии успешной технической поддержки, ответственность сторон в этом процессе, опишу некоторые подходы и технику ответов на жалобы пользователей, опишу особенности тех поддержки по почте и с помощью мгновенных сообщений (по чату). 
Почему правильная тех поддержка важна? Правильная тех поддержка: 
— минимизирует негативный опыт пользователей ПО 
— позволяет избежать возврата ПО 
— увеличивает удовлетворенность пользователей и заказчика 
— это положительный пиар вашего продукта 
— это важный источник информации для улучшения продукта 
Схематично процесс тех поддержки со своими входами и выходами будет, выглядит так: 
Вход: 
— Сообщение от пользователя 
Методы и инструменты: 
— Исследование 
— Техническая экспертиза 
— Проектная база знаний  
— Часто задаваемые вопросы 
— Поиск в сети, и др. 
Выход: 
— Уточняющий вопрос пользователю или заказчику (если нужно) 
— Решение для пользователя  
— Запись о проблеме ПО в багобазе  
— Исправление проблемы в ПО 
Критерии успешной тех поддержки 
Когда пользователь говорит что-то вроде "Лучшей тех поддержки я не встречал!" или "Я приятно удивлен как Вы быстро и, по сути, отвечаете!", это означает что, техническая поддержка организована правильно. Помимо этого, вне зависимости от каналов тех поддержки, критерии успешной тех поддержки могут выглядеть так: 
— пользователь ПО быстро получает от вас ответ 
— ответ является конкретным решением пользовательской проблемы 
— пользователь удовлетворен ответом 
— пользователь может продолжать использовать ПО 
— пользователь не возвращает ПО 
— минимизирован негативный опыт пользователя с вашим ПО 
— предприняты все действия по улучшению продукта 
Ключевыми критериями считаю первые 2 пункта — оперативность и полнота ответа. Когда вы обращаетесь за ремонтом автомобиля, вы хотите, чтоб вам помогли "здесь и сейчас" и чтоб в будущем ваш авто не приносил проблем. Вряд ли вас будет интересовать, как производитель авто изменил производственный процесс для улучшения модели в будущем. Улучшение процесса производства — это интерес производителя авто. 
Каналы технической поддержки 
Среди каналов тех поддержки можно выделить: 
— Телефон 
— Электронная почта 
— Мгновенные сообщения (чат) 
— "Часто задаваемые вопросы" (на сайте производителя или в документации пользователя) 
— База знаний 
— Веб-форумы 
Большая часть тех поддержки находится в сеть. Поэтому нужно иметь как минимум 1 канал, по которым Вы будете решать проблемы — э-почта. Со временем, создайте веб-поддержку в виде FAQ (часто задаваемые вопросы), knowledge base, форумы. Эти каналы помогут Вам более эффективно решать типичные и наиболее распространенные проблемы. 
Далее я буду рассказывать про особенности тех поддержки по почте и чату.  Конечно, если у вас есть корпоративные и ВИП клиенты, то нужно непосредственное общение при решении проблем.  
Кто учувствует в тех поддержке? 
В тех поддержке могут участвовать все подразделения проекта по разработке ПО. В первую очередь это менеджмент, программисты, тестировщики. Если объем тех поддержки велик, то возможно понадобится помощь отдельных членов команды — специалистов по тех поддержке, которые будут заниматься исключительно вопросами тех поддержки. Если речь идет о типичных проблемах, то участие программистов и тестеров может и не понадобиться — специалист по тех поддержке или же менеджер проекта вполне сможет решить проблему самостоятельно. Однако если речь идет о какой-то неизвестной, новой, специфичной проблеме, то без помощи программистов и/или тестеров не обойтись. Именно тестеры смогут восстановить конфигурация и окружение, отработать множество сценариев, для воспроизведения проблемы, внести проблему в багобазу. Если же тестеры безуспешно пытались воспроизвести проблему, то никто кроме программиста не сможет посмотреть в код, и возможно выяснить проблему "изнутри". 
Техническая поддержка — это командная работа, вовлеченность конкретных специалистов в которую зависит от сложности проблемы. 
Оперативность технической поддержки 
Скорость, с которой команда реагирует на пользовательские сообщения, отосланные в техническую поддержку, в первую очередь зависит от: 
— квалификации и компетентности персонала, который участвует в технической поддержке 
— правильная приоритетность в решении вопросов тех поддержки 
Компетентность и квалификация специалистов 
Персонал должен знать продукт досконально. Если есть возможность пользоваться продуктом для своей же работы, все должны им пользоваться. Это позволит команде выучить и понимать наиболее реалистичные и частые сценарии работы с продуктом. 
Заведите список типичных проблем и их решений, так чтоб можно было сразу же скопировать в почту. Заведите раздел "часто задаваемые вопросы" на сайте продукта.  
Организуйте процесс тех поддержки так, что персонал, который занимается технической поддержкой, имел доступ к техническому персоналу фирмы, на тот случаи, если вопрос сложный и требует детального технического исследования "внутренностей" продукта.  
Приоритеты 
Не редко отделы тех поддержек гарантируют письменный ответ в течение 8 рабочих часов. Но стремиться ответить "сразу" нужно всегда. Если же команда перегружена технической поддержкой или другими задачами, то полезно будет работать согласно приоритетам, отвечая на самые критические проблемы в первую очередь.  
Пример классификации проблем: 
— Критическая. Пользователь не может установить или запустить продукт. Не может пользоваться продуктом, так как сломана основная функциональность продукта. Потеря данных. Проблему не возможно обойти. 
— Очень серьезная. Не работает функциональность, описанная в документации. Пользователь ограничен в пользовании продуктом. Потеря данных. Но есть временное решение, которое позволяет выполнить необходимую работу. 
— Серьезная. Частичная, некритическая потеря функциональности. Проблема раздражает. Но проблему можно просто обойти. 
— Минорная. "Косметические" проблемы. Проблемы, не влияющие на использование продукта. Ошибки в документации или интерфейсе. Общие вопросы работы продукта. 
Иногда тех поддержка гарантирует определенную скорость ответа, в зависимости от критичности проблемы. Например: 
Критическая — 2 часа
Очень серьезная — 4 часа
Серьезная — 8 часов
Минорная — 12 часов 
Подходы и техника ответов  
  
В общем и целом отвечать нужно, так как бы вы хотели, чтоб отвечали вам. Будьте на стороне пользователя. 
Вот некоторые приемы и правила для повышения качества ответов и удовлетворенности пользователя или заказчика: 
Правило 1: Если Вам недостаточно информации от пользователя или информация не четкая, попытайтесь найти аналогичную проблему в вашем или чужом продукте. Поищите ответ в сети, FAQ, базе знаний. Попробуйте разные сценарии воспроизведения проблемы. Возможно, вам повезет, и вы найдете пользовательский шаги для воспроизведения проблемы. В противном случае, у вас будет подготовлен ответ для пользователя о том, что вы пытались делать для выяснения проблемы. В итоге, пользователь сможет подсказать вам в каком направлении вы должны исследовать проблему. Ну, как минимум, что не маловажно, заказчик или пользователь увидит, как вы стараетесь воспроизвести проблему, как серьезно вы относитесь к проблеме.  
Правило 2: Если исследование проблемы займет значительный промежуток времени, сообщите пользователю, что вы получили жалобу и работаете над ней. Важно, чтоб пользователь знал, что он/она услышан, и вы побеспокоитесь о проблеме.
Правило 3: Если вам нужна дополнительная информация от пользователя, спрашивайте конкретно. Попросите прислать проблемный файл, текст ошибки, или текст лог файла, если таковой создается программой. Избегайте вопросов типа: "Расскажите подробней о вашей проблеме". Лучше 5 конкретных вопросов, чем 1 общий. При этом вопросы должны иметь отношение к проблеме и не выглядеть глупыми. Не исключено, что пользователь, отвечая на конкретные вопросы, самостоятельно найдет решение или действительно уточнит проблему. 
Правило 4: Когда вы отвечаете по существу, Вы должны выйти к пользователю с предложением или гипотетическим решением проблемы, даже если Вы не уверены в правильности решения и вам необходима дополнительная информация. Опять-таки, возможно Вы угадаете с решением. Возможно, в ходе того, как пользователь будет пробовать Ваше решение, проблема сама по себе решится, или пользователь найдет правильное решение самостоятельно. В крайнем случае, пользователь скажет "нет, не получается" и даст уточнения. 
  
Правило 5: Старайтесь, чтоб одного пользователя "вел" один представитель технической поддержки. Если так не получается, то другой представитель должен войти в курс дела до того, как пользователь в очередной раз обратится за помощью. Вспомните, когда вы обращались с вопросом на горячую линию своего банка или интернет провайдера. Вы в сердцах рассказывали о проблеме сотруднику тех поддержки (или просто оператору), а потом этот сотрудник вас переключал на другого сотрудника компетентного в этом вопросе и вы заново должны были рассказать всю вашу историю. Это раздражает, не говоря о трате времени. 
Правило 6: Если Вы видите, что это проблема не вашего продукта, или не совсем вашего продукта (скажем, проблема системы или же другого продукта), то не посылайте пользователя в тех поддержку другой компании. Сперва убедитесь, что Вы действительно не знаете, как решить проблемы другого продукта. Отсылайте в другую тех поддержку только в крайнем случае, когда у Вас вообще нет идеи.  
Вспомните, как у вас пропал интернет, и как вы реагировали, когда ваш интернет провайдер сообщает вам, что у них "с сетью все ОК, обратитесь к вашему системному администратору", которого у вас нет. А проблема могла быть пустяковой — скажем, можно было бы просто посоветовать включить/отключить сервис системы "wireless zero configuration". Да, по умолчанию все должно было бы работать, но специалисты (если они специалисты), могли бы и сами подсказать вам об этом сервисе операционной системы. 
Покажите свой профессионализм, и ваше усердие будет замечено и оценено пользователем или заказчиком.  
Правило 7: В общении с пользователем, используйте простой, понятный язык. Если у пользователей нет технических знаний и опыта, избегайте сложных технических деталей.  Где имеет смысл, используйте скриншоты, демонстрируюше решение для пользователя. 
Помимо этих правил: 
  
— К проблемам, поступающим в тех поддержку можно относиться как к ошибкам в программе, которые находят тестеры. Если ошибка описана правильно, то программист исправляет ошибку сразу. Если ошибка описана не четко, то потребуется уточнения. И чем менее итераций во время уточнения, тем продуктивней работает команда. 
— Не навязывайте пользователям сложные требования к оформлению проблем. Не заставляйте заполнять сложные формы. С одной стороны Вам было бы лучше, если бы пользователи предоставляли исчерпывающую информацию. Но с другой стороны, практика показывает, что в лучшем случае сложные требования пользователь просто проигнорирует, в худшем — не обратится за помощью в тех поддержку, а потом еще и вернет продукт. 
Это приблизительно так же как иногда интернет-магазины требуют зарегистрироваться, заполнив десяток обязательных полей в форме, для покупки товара. Я такие магазины избегаю. 
Далее привожу пример того чего не надо требовать от пользователя, что может отпугивать пользователя. Это часть реальных инструкций по технической поддержке для пользователей, который я нашел в сети. 
2.4 How to submit issues to technical product support 
We ask that you perform the following steps before contacting technical product support to ensure that 
you can provide us with the information we need to resolve your issues: 
1. Gather information on your issues 
2. Save your application 
3. Log new case 
4. Use Case Management to manage your cases 
2.4.1 Gather information on issue 
Before submitting a case,gather the information needed to provide technical product support with data to reproduce and investigate the issue.It is very important to thoroughly prepare the description and supporting data to avoid delays in resolving your issue.We may need and request additional information depending on the nature of the issue. 
When you log a case,the following information is needed: 
• Priority of the problem based on the error classications presented earlier in this document. 
• Product name and version, e.g.Epic Editor 4.3. 
• Hardware platform and operating system version, e.g.Windows 2000. 
• Version of software, e.g.Epic Editor 4.3. 
• Exact full text of any error message and the error number. 
• Simple example of the conditions that trigger the error message.If your sample document is large or you have a complex application,we ask that you attempt to duplicate the problem with a smaller sample document, a distributed document type,or without your application .les. 
• The exact steps required to reproduce the problem.After documenting the steps,try them again before sending them to ensure that the steps are correct. 
•Other explanatory notes regarding the problem.For example,can you reproduce the problem or does it happen intermittently? Does the problem happen to all users or a select few?Does it happen on all workstations or only selected workstations? Does it happen with only one document or many? 
Конечно, это идеальный сценарий того как пользователь должен подавать свои проблемы в тех поддержку. Но цель тех поддержки — не обучить пользователя как обращаться в тех поддержку, а решать пользовательские проблемы. 
A вот такая форма для обращений пользователей на сайте тех поддержки выглядит уже лучше: 
Personal help from 
Which program and version do you need help with? 
Your name: [   ] 
Your email: [   ] 
Your phone (optional): [   ] 
Question topic: [   ] 
Please attach a program file (or other) that demonstrates the problem, if applicable. Click 'Browse' below to select the file to include with your question.(You can only attach one file. If you need to submit multiple files please zip/stuff them into one file.) 
Describe the technical support problem. Be as specific as possible. 

[Submit Request] 
During business hours, we usually answer within a few hours. 
If you have any problem with this form, send an email directly to [mail]  
— Избегайте нескольких адресов э-почты для службы тех поддержки. Не надо вынуждать пользователя присылать заказы на функциональность на zakazy@firma.ua , простые комментарии — на comments@firma.ua , а проблемы на support@firma.ua. Не надо усложнять процесс. Все равно присылать будут куда попало, и у вас будет риск пропустить важную информацию. Пусть пользователи все сообщения присылают на support@firma.ua. 
  
— Добавьте в свой продукт команду в меню "Помощь" — "Техподдержка". При выборе команды создается сообщение и автоматически в тело сообщения вставляется версия продукта, платформа, система и другая информация, которую важно получать от всех кто обращается в тех поддержку. 
  
— Убедитесь, что в ходе тех поддержки не теряются полезные советы по улучшению продукта. Особенно это актуально, когда техподдержкой занимаются отдельные специалисты или департамент по техподдержке.  Техподдержка — это, наверно, главный источник по улучшению продукта. Затраты на техподдержку, в какой-то степени, можно представить как стоимость исследований по улучшению продукта. Если пользователь жалуется "я не могу экспортировать TIFF c цветовой моделью CMYK", и это не просто ошибка, то в проекте требований к новой версии продукта, должна появится запись "Добавить возможность экспорта TIFF файла c цветовой моделью CMYK". 
  
— Проблема, поступившая от пользователя, считается закрытой только тогда, когда об этом сказал сам пользователь. Или если пользователь не отвечает определенный промежуток времени. 
Вот несколько примеров неудачных и удачных ответов на проблемы пользователей. 
Пользовательское сообщение о проблеме: 
"Я пытаюсь установить продукт на Windows 2000. Установка происходит нормально, но когда я ввожу серийный номер, я получаю сообщение "Невозможно сохранить серийный номер. Только администратор может установить продукт". Но я зашел под администраторской учетной записью. Что делать?" 
Вариант плохого ответа от технической поддержки: 
"Система или программа выдает сообщение? 
Вы уверены, что вы под администратором зашли в систему? 
Какой серийный номер вы вводите?" 
Почему этот ответ плох? 
1. Программисты сами могут выяснить, что выдает сообщение об ошибке — система или программа. Не составляет большого труда сделать поиск в исходном коде продукта по тексту сообщения.  
2. Пользователь четко дал понять, что он зашел в систему под администратором. Зачем еще раз спрашивать? 
Хороший ответ на проблему пользователя: 
"Сообщение, которое вы видите, указывает на то, что у вас старая версия продукта (3.0). Если это так, то сделайте бесплатное обновление до новой версии (3.1). Если обновление не поможет, убедитесь, что на системные папки установлены правильные права доступа. Инструкции как сделать такую проверку находятся в FAQ #123.  Сообщите нам, если вы не сможете разрешить проблему. Мы вам поможем." 
В результате пользователь ответил: "Спасибо! Обновление до последней версии помогло." 
Ответственность 
  
Вот пример распределения ответственности на проекте где нет отдельных специалистов по техподдержке и техподдержкой занимаются руководитель проекта, программисты и тестеры. 
  
Руководитель проекта: 
— Отвечает за работу технической поддержки 
— Организовывает и контролирует процесс тех поддержки на проекте 
— Получает сообщения по тех поддержке и отсылает их команде на обработку 
— Редактирует или составляет финальную редакцию ответов на вопросы тех поддержки 
  
Тестеры: 
— Вносит жалобу в багобазу как обычный баг 
— Исследует и воспроизводит жалобу 
— Если проблема ясна, предлагает временное решение для пользователя 
— Если проблема не ясна, описывает, что было предпринято для воспроизведения и составляет список вопросов заказчику 
  
Программисты: 
— Программист исследует жалобу с технической точки зрения — исследует код. Это позволит получить более широкую картину о том, когда проблема происходит, как ее обойти. 
— Если же тестеры не смогли воспроизвести проблему, то у программистов есть шанс выяснить проблему по коду и помочь тестерам воспроизвести и описать проблему. 
— Исправляет ошибку или улучшает продукт, чтоб по данному вопросу не было больше жалоб в техподдержку. 
 
*** 

Работаем с заказчиком в условиях форс-мажора


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

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

Речь пойдет о разработчиках программного обеспечения. А именно, об особенности коммуникации с иностранными заказчиками в условиях "революции". Как показали события 2004 года, заказчики могут быть заметно обеспокоенными революционными событиями. Я как раз имел опыт общения с американскими заказчиками в "революционные" дни.

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

Зная события "оранжевой революции", многие могут сказать: "Ну зачем так сгущать краски?! Ведь все происходило мирно. Американские и другие западные СМИ давали взвешенную инфо… " Все это так, но есть важные детали: заказчики — американцы (к тому же бизнесмены и менеджеры) и они за океаном. С их колокольни ситуация может выглядеть по-иному.

Америка — стабильная страна. Какое-либо отклонение от нормы, то ли демократической и социальной, то ли экономической, является для американцев тревожным событием. И события в Украине для них были тем самым тревожным сигналом. Естественно, в такой ситуации они начинали уделять особое внимание новостям из Украины, для того чтобы взвесить свои риски. Более того, не всегда заказчики успокаивались после получения официальных новостей, скажем, от CNN. Заказчиков интересовали тенденции и информация с "линии фронта", чтобы предупредить негативные последствия. Были случаи, когда заказчики шли дальше и искали альтернативную информацию от непосредственных участников революционных действий или от других неофициальных источников, для того чтобы понять тенденции.

В моем случае от заказчика я получил такое сообщение:

 интересный блог [ссылка] с киевского "фронта"  interesting blog from the "front lines" of kiev

Это частный блог. Автор блога, похоже, американец, был на Майдане во время "революции". И выкладывал новости с "линии фронта", прямо с Майдана, с палаточных городков. Кроме своих сводок автор выкладывал информацию, подготовленную жителями палаточных городка, были сообщения от разных общественных организаций. Есть информация с других частных блогов на тему "оранжевой революции", авторами которых были добровольцы Корпуса Мира (Peace Corps volunteers).

На первый взгляд, блог был интересный, и, в основном, отражал мирный характер акций. Тем не менее, на блоге встречались слова: убийство (a murder), химическая атака (acid attacks), акты насилия или обмана (acts of fraud or violence).

Естественно, что такие детали звучали тревожно для заказчиков. Хоть и не было вопросов типа "У вас действительно творится насилие?", именно эти слова (убийство, химическая атака, акты насилия или обмана) необходимо было сразу прокомментировать и опровергнуть.

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

Я прочитал блог, о котором вы говорили. Для меня странно слышать новости о насилии и российских войсках в Киеве. Лично я не видел никакого насилия. Местные СМИ также не сообщали о таковых. В центре города происходят достаточно мирные демонстрации. Другая же часть Киева, также как и наша компания, продолжит жить как обычно.   Well… I've read the blog you sent me.
I am confused with the news about violence and Russian troops in Kiev. I personally did not see any violence, nor local mass media reported any. Fairly peaceful demonstrations happen downtown, rest of the city continues living in usual pace, so does our company.

Более того, через несколько дней автор блога (о котором говорил заказчик) опроверг информацию про насилие. Я, в свою очередь, немедленно сообщил об этом заказчику, дабы ему стало еще спокойней:

Если вы посмотрите на БЛОГ, вы увидите, что автор блога забрал обратно свои слова о насилии в Киеве: "Несколько исправлений… Во-первых, информация от 24 числа о столкновении милиции и демонстрантов является неточной. Оказывается, там просто были некоторая толкучка и кто-то перестараться в лозунгах. Извините."

 "A couple of corrections. . . First, the report of 24 Nov that the militia was clashing with protesters was inaccurate. It seems now that there was some pushing and shoving, and someone overreacted with their reporting. I apologize for that."

Вот еще несколько примеров дискуссии с заказчиком про "оранжевую революцию".

ЗАКАЗЧИК: Только вот прочитал новости из Киева. Захватывающие времена!
РП (РУКОВОДИТЕЛЬ ПРОЕКТА): Да!
ЗАКАЗЧИК: Пугающие времена?
РП: Не такие уж и пугающие
РП: Верю, что все будет нормально.
ЗАКАЗЧИК: Ваши новости на первых полосах тут  

ЗАКАЗЧИК: Как дела в Киеве? Чем все закончится по твоему мнению?
РП: Пока все нормально. Насилия на улицах Киева нет. Мы работаем как обычно.
ЗАКАЗЧИК: Разделение [страны]?
ЗАКАЗЧИК: Новые выборы?
РП : Верховный суд сейчас рассматривает дело о результатах второго тура выборов. Касательно разделения… Сложно судить на данный момент, но я лично не думаю, что произойдет разделение. Посмотрим.

ЗАКАЗЧИК: Just read the news about Kiev. Exciting times!
РП (РУКОВОДИТЕЛЬ ПРОЕКТА): Yes!
ЗАКАЗЧИК: Scary times?
РП : Not so scary actually
РП : I believe all will be fine.
ЗАКАЗЧИК: It's made front page of all the papers here.  

ЗАКАЗЧИК: How are things in Kiev? What do you think will be the outcome?
РП : So far so good. No violence on Kiev streets, we are working at our usual pace.
ЗАКАЗЧИК: Partition?
ЗАКАЗЧИК: New elections?
РП : Supreme Court reviews election case this minutes. As for partition… difficult to judge at this point, but I, personally, don't think that partition will happen. We'll see.

Если обобщить информацию, то вот какими принципами и правилами я пользовался при общении с заказчиком во время "революции":

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

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

— В своих ответах опирался на факты. Надо было быть осторожным со своими заключениями, выводами, прогнозами. Личное мнение это хорошо, но не к месту в том случае. Я мог чего-то не знать, что-то не так понимать, в конце концов, мое мнение могло отличаться от мнения заказчика, что тоже могло быть не очень хорошо. В результате мое видение могло отличаться от официальной (CNN) информации. Поэтому…

— Я сверял концепцию своих ответов заказчику с авторитетными (для заказчика) СМИ. Если бы мой меседж концептуально отличался от авторитетных новостей, это вряд ли успокоило заказчика. И даже наоборот.

Тезисы, которые надо было донести заказчику:

— Демонстрации за честные выборы исключительно мирные.

— Остальная часть города живет своей жизни, равно как и наша компания.

— Цель демонстраций — разрешить фальсификации мирным путем.

— Главные ожидания демонстрантов — это поворот Украины в сторону настоящей демократии.

— Команда работает как обычно, а события существенно не влияют на ее производительность.

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

Типичные вопросы и ответы:

Q: Надеюсь, что результаты выборов не повлияют на вашу повседневную жизнь. [имеется ввиду не вообще, а конкретно тогда, когда страсти накалились]
A: Пока что все происходит мирно. Люди демонстрируют свою волю к демократии. Думаю, что только недавно многие начали понимать, что их голоса имеют значение.

Q: Как дела в Киеве?
A: Если вкратце, то народ положительно возбужден. Все события происходят в центре Киева, однако остальная часть Киева и Украины, как и наша компания, живет своей обычной размеренной жизнью.

Q: Надеюсь, до агрессии не дойдет.
A: Пока что ситуация захватывающая. Я не увидел признаков агрессии. 

Q: Мы ту по ТВ смотрим события из Киева и думаем о вас, ребята.
A: Спасибо! Надеюсь, мы идем к настоящей демократии. И это вдохновляет. 

Q: Hope that the results of the elections in Ukraine do not affect your daily life…
A: Well, it has been rather peaceful. People are showing there vote for democracy. I think only recently many started to understand that their single vote can make a difference.

Q: How are things in Kiev?
A: Well, in brief, it's excitement in the air. Though, all events are happening in the downtown, while the rest of Kiev and Ukraine keeps working in usual pace, so does our company.

Q: I hope it won't get aggressive.
A: It has been rather exciting and encouraging. I did not notice any sign of aggression so far.

Q: We have been watching Kiev events on TV and thinking of you guys.
A: Thanks! I hope we are heading to the country of the true democracy. And it encourages me very much.

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

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

Планируем отпуск на проекте


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

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

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

Если Ваша фирма производит программу для внутреннего пользования или это свой собственный коммерческий продукт, то тут, в принципе, подход ясен — включили отпуск в план работ и выпускаете продукт позже (на количество дней в отпуске). Так как Вы в этом случае сам себе хозяин, то Вы более гибки и свободны в принятии решения об отпуске.

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

Планируйте отпуска команды наперед. До начала проекта или до начала сезона отпусков, который начинается в мае-июне и заканчивается в сентябре-октябре, попросите всех членов команды прикинуть, когда они идут в отпуск. Причем попросите делать это сообща, чтоб не получилось, что полкоманды идет в отпуск одновременно. Объясните команде важность равномерного движения проекта и соответственно равномерного распределения отпусков. Сведите все даты отпусков в MS Project, FastTracker или другую программу для планирования. Сделайте этот документ доступным всем членам команды, чтоб каждый мог знать даты отпусков своих коллег. Если возникают конфликты между отпусками, обсудите с командой, попросите передвинуть. Практика показывает, что во многих случаях отпуска получается утрясти.

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

Постарайтесь спланировать отпуска так, чтоб во время выпуска продукта (или других важных вех) вся команда была на месте.

Когда дни отпуска уже точно известны (путевки и/или билеты куплены), убедитесь, что члены команды информируют вас о своем уходе в отпуск наперед. Согласно трудовому кодексу заявления на отпуск нужно писать как минимум за две недели.

Когда член команды уходит в отпуск, убедитесь, что его/ее часть работы передана другому члену команду. Ясное дело, человек не может делать двойную работу — "за себя и за того парня" — в течение 8 часов рабочего дня. Если есть возможность платить сверхурочные, и инженер согласен работать больше, то проблема решена. В противном случае, имея человека на подстраховке, вы как минимум будете уверены, что в случае срочности — скажем нужно срочно исправить ошибку в области, которой занимается программист, ушедший в отпуск — задача будет выполнена.

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

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

Что, если на Вашем проекте есть уникальные программисты? Пытайтесь избегать подобных случаев. Иногда это сложно (или дорого), а иногда нереально в ограниченные сроки. Например, уникальными инженерами для проекта могут считаться математические/статистические программисты, специалисты по специфическим технологиям и языкам программирования. Приглашать на замену других узконаправленных специалистов на 2-3 недели, как правило, никто не будет, так как это может быть дорого или не реально в принципе (отдел кадров просто не сможет найти такого специалиста в ограниченные сроки). Это один из случаев, когда Вам придется согласовывать отпуск программиста с заказчиком. Вероятно, Вам придется компенсировать заказчику время отсутствия такого программиста (или программисту придется перенести свой отпуск).

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

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

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

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

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

В некоторый случаях, если инженер запланирован на год и более, то Вы можете отпускать его/ее в отпуск без замены, сверхурочных работ и даже согласования с заказчиком. На длительных проектах — более года — человеко-часы оплаченные заказчиком частично покроют отпуска если:
— заказчик оплачивает как минимум 160 часов за инженера в месяц — это 1920 часов в год
— фактические часы на вашем проекте составляют не менее 40 часов в неделю. В год это более 1920. Например, в 2008 — это 2011 часов в год.

Таким образом, например, на 2008 получается такой расчет:

2011 Фактические рабочие часы на вашем проекте в 2008 году
1920 Рабочие часы оплаченные заказчиком (12 месяцев х 160 часов в месяц)

91 час на покрытие отпусков, а это около 2,3 календарных недель отпуска
===
Т.е. вам не нужно будет покрывать заменами или сверхурочными 2.3 недели отпуска инженера. Это время (2.3 недели) оплачено заказчиком. При этом остальное время отпуска приходится оплачивать компании за свой счет, и, следовательно, нет необходимости согласовывать и даже ставить в известность заказчика (конечно, если речь не идет о сдаче проекта или другом важном событии).

Я считаю, что на длительных проектах оплата заказчиком отпуска инженера — это вполне нормальным явлением, равно как вполне естественно, что программист имеет законное право на 24 календарных оплачиваемого отпуска. Особенно если заказчик оплачивает конкретного человека. Если же заказчик не понимает этого, то политика по отпускам может быть приблизительно такой: "Если Вы хотите, чтоб работа не прекращалась во время отпуска программиста, нам необходимо будет привлечь других программистов на замену. Это в свою очередь может замедлить работу, так как 1) необходимо будет вводить нового человека в курс дела, 2) разбираться в чужом коде сложнее, чем создавать с нуля или разбираться в своем коде".

 

Спецификация — это просто!


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

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

Параметр Значение
Дата 4 ноября, 2004
Идентификатор 5
Цвет Красный
   
   

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

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

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

Чтобы отредактировать таблицу, также надо было дважды кликнуть на ячейку и изменить значение в отдельном диалоге редактирования.

Я же в свою очередь не согласовал метод ввода данных в таблицу с заказчиком. Таким образом, мы, как разработчики, были виноватыми. Нам тогда даже пришлось вернуть заказчику где-то 1.5 ч-м (в деньгах).

После этого случая мы приняли решение обговаривать с заказчиком каждую деталь новой функциональности. Очевидно! Если что-то не ясно, плохо прописано, не прописано вообще, мы не догадывались, а согласовывали с заказчиком в духе "Мы предлагаем АБЦ. Согласен?" или "Вот тут не совсем ясно. Ты имел ввиду АБЦ?". Подобные коммуникации происходили неформальным образом (не в официальном документе, спецификации), т.е. каждая проблема отдельно, в отдельном сообщении. Часто высылали демонстрационные версии продукта, чтобы заказчик мог вовремя показать, что не правильно с его точки зрения. В общем, все стало на свою колею, и мы успешно выпустили ту версию продукта.

Со следующей версией того же продукта мы пошли дальше. Мы решили формализовать процесс работы со спецификацией. Теперь мы прописывали все детали функциональности в отдельном документе — функциональной спецификации.

Об этом и пойдет речь.

Как же лучше всего составлять спецификации? Как сделать спецификацию рабочим документом, понятным и для вас, и для заказчика? Что должна охватывать спецификация? Как должно выглядеть описание конкретной функциональности?

Информации, всяческих рекомендация и стандартов о том, как правильно составлять спецификации — много. Очень часто встречаются «фундаментальные труды» по спецификациям, в которых охватывается все (ну, почти все), со сложной структурой, всеми возможными нюансами и деталями. Спецификации, в итоге, могут разрастись в несколько толстых томов. Возможно, это все нужно на сложных и трудоемких проектах или для сложной и емкой функциональности программы.

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

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

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

Ничего сложного в написании функциональной спецификации нет. Главное начать, а также понимать, зачем нужна спецификация. В первую очередь, функциональная спецификация необходима для согласования продукта с заказчиком, чтоб у команды и заказчика было одно понимание продукта. Функциональной спецификацией впоследствии будет пользоваться программист для разработки функции, как военный пользуется картой для ориентации. Не путать с технической спецификацией или задачей! Далее отдел тестирования будет использовать функциональную спецификацию для разработки документации для тестирования.

А когда вы начнете писать спецификации, работа пойдет сама по себе, — главное начать.

Я лично при написании функциональной спецификации пользуюсь несколькими простыми принципами: 1) простота изложения, 2) лаконичность, 3) полнота, 4) самодостаточность документа.

1) Простота. Ни для кого не секрет, что заказчики, как правило — занятые люди. И это не должно являться оправданием тому, что заказчик не отвечает на вопросы и не утверждает спецификации. Это реальность, с которой надо жить и под нее подстраиваться. Таким образом, спецификация должна быть простой. А именно:

— должна быть написана простым человеческим языком, не нужно формулировок в духе "согласно принципу банальной эрудиции каждый индивид…"

— не иметь сложную структуру,

— по возможности, спецификацию нужно делать, чем меньше, тем лучше.

В итоге, заказчик, начав читать вашу спецификацию, не должен отложить ее на потом из-за того, что ему сложно "въехать" в суть дела в короткие сроки.

2) Лаконичность. "Вода" в спецификации не нужна. Также не нужны в спецификации размышления. Нужны только выводы и руководство к действиям.

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

Лучше: "Команда Печать будет неактивна для XY графиков."

Если ваше решение поставят под сомнение, вот тогда вы можете привести свои аргументы в отдельной переписке. В противном случае спецификация увеличивается и становится менее читабельной.

Не нужно пунктов в духе "Безопасность: не применима". Если вы следуете какому-то чеклисту для написания спецификации, и если пункт не применим, лучше ничего не писать.

Не надо писать о стандартном поведении программы. Например, не надо указывать, что выпадающий список будет содержать 5-12 элементов. Это стандарт, прописанный в руководстве по пользовательскому интерфейсу.

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

4) Самодостаточность. Спецификация, как единый документ, должна быть самодостаточна. Не стоит наполнять документ ссылками. Пользователь документа не должен лезть в какие-то другие источники, чтобы получить полное представление о том, как должна работать "фишка". Надо упростить работу с самим документом.

Вот каким простым шаблоном я пользуюсь:

Функциональная спецификация
[название функциональности, функции]
[дата создания]
[дата модификации]
История изменения:
[дата] [Имя] [краткое описание изменений и дополнений. Пример: Добавлена поддержка NTSC в разделе "Форматы"]

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

Требования (если есть таковые)
Требования к программному обеспечению. Тут указываются библиотеки, которые необходимы для работы или разработки функциональности. Программы, которые необходимо установить для работы функции. Требования к минимальной операционной системе, необходимой для работы функции.

Примеры:
— Библиотека (.dll) для экспортирования графических файлов.
— MSXML для экспорта и импорта файлов формата XML.
— Internet Explorer 5 для правильной адресовки панели инструментов.
— Quick Time для Windows для проигрывания видео.

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

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

— команды меню
— кнопки на панели инструментов
— диалоговые окна
— новые элементы в существующих диалогах
— элементы документа программы, и т.д.

Очень хорошая идея здесь — показать эскизы. Эскизы очень упрощают восприятие информации.

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

Пример: "Кнопка "Плот" будет доступна только в том случает, если вы выбираете 2 или три сегмента в списке "Сегменты".

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

— перечисляете тексты сообщении об ошибках для каждой противоречивой ситуации

— перечисляете проблемы, которые вы будете просто игнорировать (если вероятность и эффект проблемы очень малы, а решить проблему очень сложно)

— автоматическое исправление ошибки без сообщения об ошибке. Пример: "Если уравнение полностью не описано в диалоге "Определение Уравнения", то остальные элементы диалога остаются неактивными."

Оценки
Здесь вы указываете оценки на:
— программирование
— тестирование
— дизайн
— функции.

Оценки необходимо пересматривать каждый раз, когда вы вносите изменения в спецификацию.

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

Ниже я привожу примеры реальных спецификаций, которые успешно работали.

***

SPECIFICATION
===========
Date: May 21, 2001
Feature: Plotting single value

A. INTERFACE

1. Look of the "Range and tick interval" group when user wants to plot a single X {Y} value:

———-Range and Tick Interval————-
Plot: [Single X {Y} value]
Value: [input field]
Label: [input field]
—————————————————

2. Look of the "Range and Tick Interval" group when user wants to plot a range of X {Y} values:

———-Range and Tick Interval————-
Plot: [Range of X {Y} values]
Minimum: [input field]
Maximum: [input field]
Interval: [input field]
Starting at: [input field]
—————————————————-

B. BEHAVIOR

* Plot is dropdown with two choices: "Single X {Y} value" and "Range of X {Y} values". "Plot: [Range of X {Y} values]" is default.

* The "Plot" dropdown will be available only when two or three segments are chosen in the "Gaps and Direction" dropdown and only for one segment. So that if user defined "Single X {Y} value" for one segment, on the rest segments the "Plot" dropdown will be grayed out with "Range of X {Y} values" selected.

* "Value: [input field]" will contain by default: minimum X{Y} for the first segment and maximum for the last segment. This input field will be grayed out (with default value inside) for the first and the last segments. For the middle segment (in case of 3 segments) the "Value" field will be enabled, so that user can enter the value, the default in this case will be the median of X range.

* "Label: [input field]" will contain by default: minimum X{Y} for the first segment and maximum for the last segment. This input field will be always enabled.

* Behavior and defaults of "Minimum:", "Maximum:", "Interval:", "Starting at:" when "Plot: [Range of X {Y} values]" is selected we leave the same as in program 1.

* In case user opens old file, program will set the "Plot" dropdown to default value — "Range of X {Y} values".

C. IMPLICATIONS AND OTHER COMMENTS

This feature will not change file format.

D. EVALUATION

N days

***

SPECIFICATION
===========
Date: February 15, 2001

B. ERROR TRAPPING

— If equation is not completely described in the "Equation Definition" tab, disable all controls for "Initial Values" and "Constraints".

— Check constraints violation only if user chooses from the dropdown in the "Initial Values" tab. Don't let user leave dialog with constraints' violation of initial values.

— In case of inconsistent constraints, clear the checkboxes in the bottom group of constraints starting from the lowest.

C. IMPLICATIONS AND OTHER COMMENTS

Feature will affect file format. We'll make sure old files are opened correctly after we implement this feature. For old files all parameters will be not constrained in the new "Constraints" tab.

D. EVALUATION

N days.

***

SPECIFICATION
============
PROJECT: File viewer
August 23, 2002

OVERVIEW

It will be application that allows to review and print Program files. Supported file formats:
— v 1
— v 2
— v 3

Viewer will support "Normal" and "Compact" file formats.

Viewer will ignore user's input (mouse click or keyboard input) for all the Program sheets — if user clicks the sheet then just system beep.

SYSTEM REQUIREMENTS

— Windows 98, Me, 2000, NT, XP (version 4.0 or later)
— Any Intel compatible CPU, 100 MHz or higher
— 32 MB or more of RAM
— 2 MB or more of free hard disk space
— a monitor supporting 800×600 resolution or higher

PRINTING

File viewer will allow to print current sheet, current section or entire project.

Always print grids on tables (wysiwyg) and never print the header (wysiwyg, and the printer header is only useful if you are working on a project and need to keep track of dates and files, not an issue if you are printing from a viewer).

STARTUP DIALOG

On launching, instead of the Welcome dialog, Viewer will show a dialog:

—Welcome to the Program viewer —

[text]

[OK]

——————————————————————————

Clicking OK will close the dialog and open File Open dialog (unless they double clicked on a file, so the file is already selected).

MENUS AND COMMANDS

Menus will be the same as in full program.

All menu commands will be the same as in program and grayed, with exception of the following commands:

File: Open, Print Setup, Print, Exit.

Edit: Preferences (See details in PREFERENCES section.)

View: [list of commands]

Change: [list of commands]

Window: [list of commands], [the list of the currently opened documents]

Help: [list of commands]

PREFERENCES

Preferences will be located in the Edit menu.

Preferences content will be the same as in full program, but with all controls grayed with exception of following controls: [list of controls]

TOOLBARS, DOCUMENT NAVIGATION

The toolbars content will be the same as in full program, but all grayed with exception of the following buttons:

Shortcut toolbar: Open, Print

Navigation toolbar: [list]

Formatting toolbar: [list]

Toolbar buttons will have the same tooltips as in full program.

Navigation panel will be the same as in full program, but not editable.

Guide will be off, with no way to turn it on.

Program title bar will contain "…Viewer".

DOCUMENT EXTENSION REGISTRATION

Viewer registers Program files of versions not installed on the computer, so that by double-clicking Viewer opens those files that cannot be opened by program.

DESIGN

"Viewer" will have program icon different from Program.

INSTALLER

Viewer will be installed by InstallProgram to folder "Program Files…Viewer". Installer will create shortcuts on the desktop [name] and in the Start menu [name]. Installer will create uninstalling utility in the Viewer folder and in the "Add/Remove Program" Control Panel.

Сообщения для всех и проверка текстов


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

Почему возникают такие тупиковые ситуации? Кто-то скажет: "Так научись пользоваться программой, прочитай руководство пользователя, а потом пользуйся программой!". Или, как вариант: "Изучи технологию сперва и все станет ясно". Некоторые "умники" могут даже сказать: "Что ж тут не ясно?! Надо установить дополнительный модуль Х и только потом выполнять эту команду. Эх, ламер!". Такая установка разработчиков ПО — это демонстрация непрофессионализма.

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

Вот один из характерных, но не самых ужасных, примеров. При попытке открыть определенный (не все) PICT файл в Adobe Illustrator 7 for Macintosh, программа сообщает:

"The MPS parser is unable to parse the file. [OK]"

При этом:

PICT файл успешно открывается в других программах (Picture Viewer, PowerPoint).
PICT файл успешно открывается в новых версиях Illustrator.
Есть вероятность того, что программа У, которая создала PICT файл, не совсем корректно записала определенную информацию, так как другие PICT файлы (с другими наборами объектов на изображении), открываются в Illustrator нормально.
В любом случае, вне зависимости от того, правильный ли PICT или нет, Illustrator (равно как и другие программы) должны выдавать адекватные и понятные сообщения. А что мы видим в данном случае?

"MPS parser". Что такое MPS? Я думаю, что большинство читающих эти строки не знают, что это такое. При этом, так или иначе, пользовались или как минимум запускали Illustrator. Я не являюсь исключением в этом отношении. Подозреваю, что MPS parser — это какой-то Adobe'вский модуль, предназначенный для интерпретации PICT команд. Поверхностный поиск определения "MPS" в Google ничего не дал. Но при этом я встретил много пользователей Illustrator на форумах, которые пытались выяснить, как обойти это сообщение. По большому счету, не так уж и важно обыкновенному пользователю знать, что такое MPS. Но я думаю, многие согласятся, что сокращение "MPS" просто конфузит большинство пользователей, и не дает никакой подсказки или идеи, что ж это за парсер.

"unable to parse". Это уже что-то! Тут Вам уже ясно, что в PICT файле есть что-то, что Illustrator не понимает. Но что? Об этом Adobe почему-то умалчивает. Но ведь эта информация является ключевой для того, чтобы подсказать пользователю, что делать дальше.

Далее… Ну и что, что "unable to parse"? Что это означает? Файл не будет открываться вообще? Или же файл откроется, но без определенных объектов? Не ясно… Не ясно, пока Вы не нажмете ОК в сообщении. А может, для кого-то вызывать это сообщение и нажимать ОК придется несколько раз, чтобы понять, что файл не будет открыт вообще. И, наконец, самое главное…

Что Вам теперь делать? Я думаю, для многих пользователей такое сообщение — это тупик, если не связаться со службой технической поддержки Adobe… или производителя программы У. Это выбор и еще одна неуютная ситуация для пользователя. Особенно если еще учесть, что не часто техподдержка бывает понятной и оперативной, при этом пользователю надо срочно закончить работу с этим PICT файлом… Короче, получаем несчастного пользователя, который недоволен и Adobe, и PICT файлом, и программой Х, и техподдержкой. В итоге, как минимум, у пользователя остается негатив о работе с программой, пользователь жалуется своим коллегам на программу. Или чего хуже — возвращает программу производителю. В любом случае производитель теряет пользователей и деньги.

Вот еще несколько примеров реальных плохих сообщений:

Sorry, the operation could not be completed due to a system error: (Access Denied)
[OK]

Unable to open a required temporary file. Please verify that you have the proper permissions for your system.
[OK]

А вот совсем курьезные сообщения:

CPU not found! Sorry.
[OK] [Report]

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

Неопределенная ошибка.
[Закрыть] [Подробности]

А чего стоят сообщения типа "Ошибка №45876 [OK]" ?!

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

Как должны выглядеть информативные и понятные сообщения?

По-моему, самые интересные и полезные советы и рекомендации можно найти в руководствах по разработке пользовательского интерфейса от Apple, в частности, в "Руководстве по разработке пользовательского интерфейса Аква" (Aqua Human Interface Guidelines). Я (да и не только) считаю Apple законодателем мод в разработке пользовательских интерфейсов. Также соответствующие разделы по разработке сообщений можно найти в документации от Microsoft, в частности, "Vista UX Guide".

Я следую следующим принципам и приемам в написании сообщений:

1. В общем случае сообщения должны содержать 3 условные части:
    1) Утверждение о том, что произошло. Как правило, это утверждение того, чего не удается сделать, что не будет сделано программой.
    2) Причина проблемы.
    3) Рекомендации как решить, или обойти проблему
    В отдельных простых и очевидных случаях можно комбинировать или опускать эти составляющие.
2. Избегайте сокращений.
3. Сообщения должны быть написаны простым человеческим языком.
4. Сообщения должны быть лаконичными, без лишних технических деталей (если того не требует аудитория).

Таким образом, Адобовское сообщение про "unable to parse" я бы переписал следующим образом:

Cannot open the file.
Adobe Meta Picture Series parser cannot handle data in the file you try to open.
Make sure:
— the file is not corrupted
— Adobe Illustrator is properly installed. You may want to reinstall it.
— You have the latest version of Meta Picture Series parser installed. Check www.adobe.com for it.
Then try to open file again.
[OK]

Сразу уточню, я не знаю, как расшифровать MPS. "Meta Picture Series" — это моя выдумка. Я не знаю всех случаев, когда должно появляться оригинальное сообщение. Я только знаю, что этот парсер "загибается" на определенных последовательностях PICT команд. И это не только ошибка PICT файла, так как новые версии Illustrator открывают этот файл.
Я надеюсь, Вы понимаете, что мои предположение не столь важны для этого примера. В любом случае, обладая полной информацией, можно написать отличное сообщение.

Или как вариант:

Сannot open the file.
The file requires a bigger canvas to display than the maximum canvas size of Illustrator.
Decrease the picture size and try to open the file again.
[OK]

А вот как бы я переписал сообщение про "unable to open a required temporary file":

[Program] cannot run because it cannot create a temporary file.
Either the temporary folder does not exist or it exists but [program] cannot write a file in it (probably the file is write protected).
Location [program] is trying to access: [path]
Check that this folder exists, and that its properties are set to allow programs to create new files within it.
[OK]

Как обеспечить Вашу программу качественными сообщениями?

Вы, как руководитель проекта, должны организовать процесс написания, проверки, корректировки и утверждения сообщений и контролировать его. Сообщения должны соответствовать правилам и рекомендациям по написанию сообщений, таким как, AHIG, APPLE Publications Stye Guide, Vista UX Guide.

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

Если же текст составлен на чужом языке, то вам еще понадобиться помощь носителя языка. Ну и в конечном итоге, заказчик должен утвердить или исправить ваше сообщение.

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

Тексты на чужом языке

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

Проверять нужно не только новые тексты, но и изменения в уже существующем тексте.

Какие тексты следует проверять помимо текстов сообщений:

— Тексты в окне документа (панели инструментов, панель статуса, и т. д.)
— Подсказки на кнопках панели инструментов, подсказки в диалоговых окнах
— Любые тексты в диалогах
— Окно "О программе"
— Тексты в руководстве пользователя
— Пункты меню
— Тексты на картинках (splash screens)
— Названия папок программы
— Названия файлов программы
— Тексты в шаблонах, примерах и других модулях, поставляемых с программой.
— Тексты, которые автоматически генерируются программой.
— Техническая документация, которую может увидеть заказчик

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

Проверка и корректировка текстов

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

Проверять и корректировать текстов можно как по ходу разработки программы (по мере возникновения необходимости в сообщении), так и все тексты сразу в конце разработки.

Проверка текстов по мере возникновения необходимости имеет смысл, если вы отсылаете регулярные сборки программы заказчику. Если заказчик требует утверждения текстов, то до отсылки программы с новыми текстами заказчику вам следует проверить (в том числе у носителя языка) и откорректировать все новые тексты для конкретной сборки ПО.

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

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

Если же Вы проверяете все тексты сразу, то Вы можете быть более уверенным, что не пропустите какой-либо текст. Второй подход (все сразу) имеет смысл, когда программисты пишут сообщения более-менее нормально, так что вам нужно будет просто пробежаться по тексту и откорректировать мелочи. В реальности следует комбинировать два подхода — "по ходу" и "все сразу". Это позволит сразу писать хорошие сообщения, а потом отловить сообщения, которые проскользнули мимо Вашего внимания.

Защищаемся от вирусов


Очевидно, что информация на проекте по разработке программного обеспечения (далее ПО) требует защиты, в частности, защиты от вирусов и вредоносных программ. Какой бы не был у вас продукт, какой бы не был счастливый у вас заказчик, и какие бы не были профессиональные инженеры у вас на проекте — все вмиг может рухнуть, если вы "отгрузите" заказчику вирус вместе с продуктом, или, что не менее фатально, вы потеряете исходный код продукта. Представьте, что заказчик узнает, что он потерял оплаченные человеко-дни, месяцы или даже годы работы… Я думаю, это ваш страшный сон. Репутация строится годами, а теряется за мгновение. Но как лучше организовать антивирусную защиту? На первый взгляд все вроде как ясно — установил антивирус на компьютеры и все. Однако, не все так просто. Сам по себе антивирус не гарантирует отсутствие вируса на проекте…

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

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

Даже если речь идет о больших компаниях-разработчиках ПО с портфелем проектов, то проект — это основная производственная единица, где в первую очередь важно организовать процесс антивирусной защиты или же "заточить" общекорпоративные процессы защиты под потребности и реалии проекта. Например, было бы неправильно в обязательном порядке производить проверку на проекте в 12-00. Это привело б к понижению производительности труда. Член команды должен сам определятся, когда именно он или она сможет проверить свой компьютер. Или же, если производится централизованная удаленная проверка компьютеров, то это также не должно тормозить работу. Но я не об этом…

Вы, как руководитель, отвечаете за свой проект, и вы должны сами убедиться, что все ОК с защитой информации у вас в хозяйстве. Именно вам следует обеспечить процесс защиты и проверки информации на проекте. Целью процесса защиты и проверки, соответственно, должны быть:
1. Минимизация риска проникновения вируса на проект
2. Минимизация потерь, если вирус таки попал на Ваш проект

Вам необходимо определится с такими вопросами (и не только):
— Информационные ресурсы и информационные каналы, которые нужно защитить
— Антивирусное ПО для защиты
— Распределение ответственности в процессе защиты и проверки
— Действия, которые нужно предпринимать для защиты и проверки информации
— Действия, которые нужно предпринимать, если вирус найден
— Отчетность о проверке и контроль

Все участники вашего проекта должны знать и следовать правилам по антивирусной защите. Обязательно новых сотрудников нужно проинформировать об антивирусной защите на проекте. Вы должны организовать контроль над выполнением антивирусных правил. Хорошо, если команда состоит из 2,3…10 человек. В этом случае, процесс можно построить на доверии и достаточно будет просто получать от членов команды подтверждение о том, что компьютеры проверены и не содержат вирусов. А если в команде десятки человек? Большинство людей самосознательны, но вы не застрахованы от того, что кто-то пропустит мероприятия по защите, то ли по не знанию, то ли по халатности. Поэтому, простых подтверждений может и не хватить — нужно вводить процедуру аудита. Как правило, такой аудит проводят "независимые органы", например, сотрудники отдела ИТ. Они могут проводить плановые или внеплановые проверки… Но не об этом речь.

Что защищать?

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

Как вирусы могут попасть на проект?

— По почте и программам мгновенных сообщений. То ли это внутренняя проектная почта, то ли это внешняя корпоративная почта — любую почту нужно защищать. Приложения к почте от неизвестных отправителей лучше не открывать.
— Веб. По ходу работы участники проекта могут забредать в такие уголки всемирной путины, лазить по таким сомнительным веб-страницам, что сложно себе представить, что там можно подхватить.
— ФТП, торренты и другие файлообменники. Не редко приходится обмениваться данными с заказчиком с помощью его, ваших или публичных ФТП-серверов. Также по ходу разработки наверняка понадобится загружать программы, библиотеки, код и другую информации с торрентов и файлообменников. Все эти ресурсы могут быть (и чаще всего являются) разносчиками вредоносных программ и вирусов.
— Устройства для хранения и переноса данных, такие как CDs, DVDs, флеш-память, ZIP и гибкие диски, фото-видео камеры, mp3-плееры, USB часы, сотовые телефоны и другие устройства для хранения и переноса данных, которые могут быть присоединены к компьютерам. Эти устройства как личные, так и корпоративные могут использоваться на проекте, как в производственных целях, так и в частных.

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

Чем защищать и проверять?

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

Убедитесь, что команде всегда доступны последние антивирусные базы и обновления АВ-программам. Установите на проекте процесс обязательного и регулярного (скажем, раз в месяц) обновления вирусных баз.

Если говорить о конкретных АВ-программах, то по опыту могу сказать, что бесплатными АВ-программами лучше пользоваться как дополнительным, но не как основными средством защиты. Я имею ввиду не условно бесплатные антивирусы — взломанные, а бесплатные по определению. "Бесплатный сыр — только в мышеловке". Не думаю, что бесплатный антивирус обеспечит более высокий уровень защиты, чем популярный и платный. Также избегайте параноидальные АВ-программы, которые "ругаются" на все по их мнению подозрительное, включая абсолютно чистое, коммерческое ПО. Был у меня случай, когда популярный платный антивирус начал ругаться на нашу программу. Проблема была в чересчур чувствительной эвристической проверке. Производитель АВ-программы вскоре после нашей жалобы исправила проблему.

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

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

Как проверять?

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

— Автоматическое лечение файлов
— Карантин, если лечение не возможно
— Сканирование архивов
— Проверка всего диска по требованию
— Автоматическое сканирование внешние диски

Если компьютер подсоединен в Интернет, то имеет смысл установить файрвол, и автозащиту.

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

Устройства для хранения и переноса данных

Вопрос об устройствах для хранения и переноса данных — деликатен. Очевидно, что команде не запретишь приносить на рабочее место фото камеры, mp3-плееры, USB часы. Но с другой стороны эти устройства являются потенциальными хранителями вирусов и вредоносных программ, которые случайно (а может и специально) могут попасть на проектное оборудование.

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

Что можно сделать, чтоб избежать таких и более серьезных форс-мажоров? Тут нет серебряной пули, и подходить нужно комплексно. Среди мер могут быть:
— Разрешить пользоваться CDs, DVDs, флеш-памятью, ZIP и гибкими дисками и другими носителями информации, только с вашего разрешения.
— Если необходимо использовать на проекте носитель информации, в обязательном порядке проверять носители антивирусами.
— Установить на компьютере автопроверку носителей информации АВ-программой.
— Запретить создавать соединения между передатчиками (например, bluetooth модем в телефоне) и проектными компьютерами в личных целях.

Можно обязать сотрудника подписать договор о неразглашении, в котором изложить правила поведения с носителями и передатчиками информации.

Однако большинство таких мероприятий послужат только барьером от случайного проникновения вирусов на проект или от проникновения вирусов по халатности. Но если кто-то сознательно решил нанести вред информации, то эти барьеры вряд ли будут действенными. Не буду рассматривать такие драконовские методы контроля как камеры для слежения за сотрудниками, тотальный мониторинг компьютеров разработчиков, какие-либо физические барьеры (досмотров на входе/выходе) и другие параноидальные меры. Разработчики ПО — это творческие и интеллектуальные люди, которые просто не будут эффективно работать в таких условиях. А этого вы, как руководитель проекта, определенно не хотите.

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

Когда проверять?

Возьмите за правило регулярно проверять все проектные компьютеры. Пусть каждый участник вашей команды, скажем, раз в месяц проверяет свой компьютер. Убедитесь, что каждый компьютер закреплен за членом команды. На проекте не должно быть "бесхозной" техники. Запускайте проверку на ночь, чтоб работа не тормозилась в течение дня. Вряд ли вы хотите, чтоб в рабочее время член команды запустил проверку и пошел на двухчасовой перекур. С другой стороны, если ставить проверку на ночь, то нужно убедиться, что проверка на остановиться, скажем, из-за того, что антивирус спрашивает пароль на архив или спрашивает, что делать с зараженным файлом. Должны быть соответствующие установки АВ-программы. Организуйте систему отчетности о проверке на вирусы. Пусть каждый член команды отрапортует, что сканирование на вирус пройдено и вирусы не найдены (или найдены). "Подпись" сотрудника под отчетом "заставит" сделать проверку компьютера на вирусы вовремя.

Что делать когда когда обнаружен вирус?

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

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

Очевидно, нужно провести анализ ситуации и:
— Выяснить название и описание вируса. Эту информацию можно найти в сети на сайтах производителей антивирусов. Учтите, что один и тот же вирус у разных производителей АВ-программ может называться по-разному. Как правило, описание вируса содержит оценку угроз вируса, описание того, что именно делает вирус на компьютере, какие файлы инфицирует, какие ОС заражает, инструкции по удалению вируса, и другую техническую информацию.
— Выяснить, как попал вирус на проектное оборудование, дабы избежать проблему в будущем. Выяснить источник вируса не всегда легко. Человек может бояться признаться, что инфицировал компьютер. Поэтому если источник не очевиден, и никто не признается, то, возможно, необходимо провести дополнительный ликбез, тренинг, напомнить об антивирусных правилах. Самое главное, чтоб люди не чувствовали, что вы "охотитесь на ведьм". До людей нужно донести важность сохранности информации на проекте. Конечно, если ситуация повторяется и виновник один и тот же, то тут уже должен быть другой разговор …
— Удалить вирус. В воспитательных целях можно "попросить" виновника очистить проектные компьютеры от вирусов. Очистка от вирусов может быть длительной процедурой, особенно если заражено несколько компьютеров, поэтому по идее должен запомнить урок. Однако, ваша задача тут убедиться, что вирус все-таки удален с проектного оборудования. Возможно, нужно будет привлечь специалиста, который проконтролирует, что вирус таки удален.

Приобретение программного обеспечения


Наверняка перед вами возникал вопрос о приобретении 3-партийного программного обеспечения для разработки или тестирования вашего продукта. Для большинства украинских компании, особенно для тех, которые работают на внутренний рынок — это пока не большая проблема. Вышел в переход (или на Петровке) и купил себе за 7-15 гривен то, что в цивилизованных страхах стоит сотни и тысячи "вечно зеленых".

(Петровка — это большой книжный рынок в Киеве, где также продается пиратский софт.)

"Бесплатный" софт наряду с более дешевой рабочей силой являются большим конкурентным преимуществом украинских компании на мировом рынке разработки программного обеспечения.

Например, возьмем минимальный набор программиста:

$150 MS Windows XP Professional
$799 MS Visual Studio .NET 2003
$364 MS Office XP Professional
$299 File Maker Pro 7 (база данных для учета ошибок, далее баго-база)
$1612 ИТОГО
А если учесть, что рабочих мест несколько? Скажем 10. С учетом скидок на многолицензионные пакеты у нас получится до $16120. Рабочих мест может быть еще больше…

Теперь, посмотрим на то, что может понадобится ДОПОЛНИТЕЛНО для разработки полноценного продукта средней сложности (трудоемкостью в ХХ.Х человеко-месяцев) для конечного потребителя.

$1399 InstallShield 10.5 Professional (продукту нежен инстолер)
$999 File Maker Server 7 (для баго-базы)
$1199 MSDN Professional (программисты должны быть всезнайками)
$649 Adobe PhotoShop CS (для продукта нужны иконки, эскизы…)
$299 Adobe Acrobat 7 Standard (для продукта нужна документация)
$499 Adobe Page Maker 7 (…"документация" говорю)
$39 Antivirus Kaspersky Personal (вирусов нам не надо)
$599 MS Project Standard 2003 (ну и чтоб управлялось хорошо)
$5682 ИТОГО

Итого, из расчета команды из 10 человек, у нас получается до $21694.

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

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

И вы, как руководитель проекта, должны исходить из предположения, что у вас на проекте все должно быть легально (даже если ваша компания не всегда может себе позволить легально покупать программы).

Поэтому поговорим о правильных вещах…

Итак, мы увидели, какими могут быть расходы на программное обеспечение, если действовать легально. Следовательно, вопрос закупки программ становится особой заботой менеджеров и владельцев компании.

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

Если же речь идет о специфических программах или новых версиях базовых программ, то руководству регулярно приходится решать вопросы: "А действительно ли нам нужен продукт Икс?", "А может, достаточно Демо или Триал (Trial) версии продукта Икс?", "А нужен ли продукт Икс нам или заказчику?", "Если заказчику, то может пусть сам возьмет и купит?", "А может, все-таки Петровка?"

Как мы определились, по последнему вопросу у вас, как у руководителя проекта, должна быть однозначная позиция — "Ганьба! Ні пиратству! Пиратство геть!". Если высшее руководство настаивает, то это будет их решение. И с вас ответственность снимается в случае чего. Особенно такая позиция актуальна в компаниях, которые работают на зарубежных цивилизованных заказчиков. Если вы работаете в честной компании, то читайте дальше…

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

Очевидно, если заказчик просто требует, или ваш продукт может использоваться совместно с другим продуктом, или, не дай Бог, пользователи уже начали жаловаться, что ваш продукт не совместим или плохо совместим с другим продуктом, то вам просто необходим этот 3-партийный продукт. Это абсолютно веские аргументы в пользу необходимости проверки на совместимость. Но тут надо решать: можно ли обойтись демо или триал версиями. Что может и ответить ваше руководство: "А зачем нужна полная версия продукта?! Возьми демо или триал".

Почему Демо или Триал не всегда подходят?

Пример: Мы разрабатываем продукт, который строит графики по неким данным. При этом, программа не приспособлена к подготовке презентаций. Не редко для презентаций потребители используют MS PowerPoint.

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

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

Затраты на переустановку зависят от:

а) длительности работы триал версии.

б) срока, на который нужен продукт. Если на несколько дней, а триал работает месяц, то вопрос закрыть.

в) времени на переустановку продукта на одном рабочем месте.

г) количества рабочих местах, на которых нужно переустанавливать программу.

д) стоимости рабочего часа программиста или тестера.

Рассмотрим наш пример с PowerPoint. Предположим, проблема заключается в том что, графики нашей программы выглядят плохо на экране в новой версии PowerPoint.

а) Триал версия PowerPoint работает 1 месяц.

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

в) Мы не можем взять так сразу и переустановить PowerPoint. PowerPoint записывает регистрацию глубоко в реестре и каталогах. Надо переустанавливать ОС. А это, как мы знаем, дело небыстрое. А если учесть, что еще необходимо время на установку всех необходимых программ, установок, опций… то есть полностью восстановить рабочее окружение, то на переустановку PowerPoint может уйти до 1 дня.

г) Скажем, у нас команда из 4 человек: 2 тестера и 2 программиста.

д) Думаю, в компании, которая покупает официальный софт, программисты дорогие. Предположим, $4 в час.

Итого, посчитаем затраты 2 программистов в течение 2х лет на переустановку PowerPoint:

24 (месяца) х 8 (часов на переустановку) х 2 (программиста) х $4 (в час) = $1536

Посчитаем тестеров:

24 (месяца) х 8 (часов на переустановку) х 2 (тестера) х $1 (в час) = $384

Вся команда — $1920.

Итого, за два года переинсталяции PowerPoint фирма потеряет $1556 ($1920 — $364 стоимость Офиса). Даже если учесть, что одна переустановка может занять в 2 раза меньше (часа 4), то затраты на переустановку все равно больше ($960), чем стоимость MS Office ($364).

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

"Если это нужно для заказчика, то пусть он сам и покупает."

Иногда причина противодействия высшего руководства и владельцев компании по поводу покупки софта может заключаться в политике компании. Вы должны это знать и понимать. Когда вы доказали, что программа действительно нужна, ваше начальство может ответить "Ну, если это надо заказчику, то пусть он и покупает этот продукт. Проси заказчика." По идее это правильно, и так должно быть в принципе, но не всегда. Представьте себе, вы говорите заказчику: "Мы профессионалы по разработке программных продуктов на платформе Windows". Заказчик думает: "О! Наконец-то я нашел спецов! Буду разрабатывать свои продукт у них". А потом вы ему говорите. "Знаешь, Боб, нам нужен MS Office XP!". И тут заказчик думает: "Как так?! Профессионалы… нужен MS Office XP… ?!?!?". Политически не корректно. И вы должны объяснить это руководству.

Ах, да, еще… все эти расчеты должны делать вы, как руководитель проекта. Если у вас в компании предусмотрен человек по закупке софта, он не всегда будет самостоятельно считать и усердно отстаивать ваши интересы. Еще бы! Не ему же Офис нужен! А именно такие расчеты могут убедить топ менеджмент (и владельцев) в актуальности покупки. К тому же, вы Бог и Царь на вашем проекте и вы вправе (если вы на 100% уверены,что ваш проект страдает) поднимать вопрос на самом высшем уровне.

24/2/2005

Роль менеджера в оценке задач


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

Как правило, на этом этапе руководителю проекта необходимо составить предложения, которое будет 1) понятно заказчику, 2) содержать то, что нужно и ничего лишнего для принятия решения заказчиком, 3) актуальным и реальным.

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

Возможно, вам придется согласовывать работу или консультироваться с экспертами, которые никаким образом не будут нести ответственность за свои оценки вашего проекта. Скажем, будет сидеть какой-нибудь CTO (Главный технический директор) перед вами, пускать пузыри, дуть губы, играть в "большого босса". Вам повезло, если Ваш документ (предложение) не требует "печати" такого деятеля. Но в любом случае, из подобных бесед нужно выудить максимум полезной информации, нужно включить "фильтр" и "локатор" и ловить рациональное зерно среди "потока сознания".

Также, кто-то может выдать оценку, за которую заведомо не будет полностью нести ответственность, если работа будет не сделана. Например, такие оценки иногда могут выдавать инженеры по тестированию. Инженер учтет все, что только можно: и разработку тестовой документации, и учет всех тестовых конфигураций, и количество "проходов" по продукту, и работы по обработке ошибок в базе, и исследование ошибок от заказчиков, и техническую поддержку, и ожидания по количеству найденных ошибок, плюс сделает кучу допущений. В итоге выдаст оценку с разбросом в разы — 3 — 6 человеко-месяцев. Понятное дело народ будет страховаться. А потом, если спросить, почему что-то не сделали из запланированного, тебе ответят, мол, "получили больше ошибок, чем ожидали", "добавили больше функциональности, чем ожидали", "кто-то заболел, ушел, не пришел". Т.е. всегда будет "веский" аргумент, который собственно могут иметь некий смысл. Собственно тут нет смысла винить инженера по тестированию — не редко оценка носит субъективный характер, хоть и учитывает кучу деталей. Однако, за 3-6 ч-м отвечать будете вы, руководитель проекта. И если вы подстрахуете сами себя максимальной оценкой 3-6 ч-м, то заказчик испугается такой оценки и откажется от работ. В конце концов, на фиксированом проекте (fixed-price) заказчик не может оплатить счет в "$20-$30K". Заказчик должен заплатить 20 или 25 или 30.

К подобным интервальным оценкам с большим разбросом необходимо подходить с головой — вашей головой. Возможно, воспринимать оценку нужно как "порядок цифр", если речь идет о почасовом проекте (labor hours or T&M) и не нужна точные человеко-часы, за которые заказчику нужно заплатить вам конкретную сумму денег, а нужна "прикидочная" оценка, если заказчик не имеет представление о трудоемкости вообще.

Что можно сделать, чтоб получить реалистичное предложение и оценку, которую примет заказчик, ну, или как минимум скажет "о, как тщательно вы изучили проблему, но пока я делать это не буду, вернемся к вопросу потом"?

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

2. Пусть задачу оценивают профессионалы или специалисты, которым вы доверяете. Привлеките человека оценки, которого совпадают (или почти совпадают) с фактическими данными. Привлеките специалиста, который делал аналогичные или такие же задачи. Если он не имеет времени сделать оценку самостоятельно, то пусть курирует человека, который непосредственно будет оценивать и выполнять работу. Тут могут возникнуть трудности связанные с тем, что внешний эксперт может быть полностью занят на других проектах. Возможно, вам понадобится взаимодействовать с руководством, чтоб согласовать межпроектные приоритеты. А может даже придется оплачивать часы эксперта. Поэтому до того, как эксперт начнет исследование вашего вопроса вам необходимо максимально эффективно организовать его/ее работу, обеспечить необходимыми материалами, рабочим местом, техникой.

3. Учитывайте исторический опыт на других аналогичных проектах. Если вы знаете об аналогичном проекте, поднимите фактические материалы. Посмотрите материалы сами и дайте ознакомится с материалами людям, которые оценивают задачу. Учитывая разницу между старым и новым проектами, фактические данные по старому проекту, грубую оценку нового проекта, можно как минимум определиться с реалистичностью проекта и порядком цифр. Например, если вы когда-то разработали десктопную версию продукта, а теперь переносите продукт на веб-технологии, то оценка, скажем, разработки фронт-энда вашей веб-программы может приближаться к фактическим данным по разработке пользовательского интерфейса десктопного приложение (если вы будете использовать схожие технологии).

4. Убедитесь, что отдельные оценки и документ в целом — само-согласующиеся и последовательны. Если документ содержит противоречия, то для заказчика это будет первый признак нереалистичности оценки и плана. Дальше заказчик может даже не вдаваться в подробности. Собственно и для вас самих противоречия в документе должны быть сигналом того, что что-то не доработано. Убедитесь, что документы с оценками, которые присылают вам оценщики, также является само-согласующимися и последовательными. Обращайте внимание на детали документов.

5. Используйте терминологию понятную заказчику. Учитывайте технический уровень подготовки читателя вашего предложения. Если ваше контактное лицо у заказчика технически "не подковано", не нужно рассказывать про API и функции. Избегайте аббревиатур. Не поленитесь указать "Google Web ToolKit", вместо "GWT", или "Integrated development environment" вместо IDE. Не должно быть дискуссии "немого с глухим". Недопонимание порождает дискомфорт, а это последнее, что вы хотите для заказчика.

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

— Оценка. Собственно человеко-часы по всем необходимым ресурсам.
— Беглый обзор. Собственно сама суть предложения. "Что? Где? Когда? Чем? Кем?"
— Технологии. Наверняка заказчик захочет в общих чертах знать, какой базовой технологией вы захотите пользоваться. Что-то в духе: "Мы будем использовать Microsoft Foundation Class Library" или "Мы реализуем это на JavaScript".
— Совместимость. Отразите разные вопросы совместимости, а именно, совместимость: со старыми версиями продукта, с другими продуктами, форматами файлов, и т.д.
— Требования. Могут включать (но не ограничиваться) требования к продукту со стороны пользователей и со стороны заказчика. Например, минимальные системные требования продукта, требования к установленным ПО (скажем PDF-reader), требования для конфигурации и ПО сервера заказчика, требования к заказчику купить лицензию на 3-ти партийное ПО, среду разработки, и т.д.
— Предположения. Отразите предположения, такие как предположения по скорости реакции заказчика на ваши вопросы, по толкованию требований, по проектным решениям, по условиям работы, по характеристикам исходных данных.
— Вопросы и проблемы, требующие внимания заказчика. Например, обратить внимание, что вам нужно получить 3-ти партийную библиотеку (или другие материалы) до определенного числа. Рискованные работы и задачи, которые нужно дополнительно исследовать для уточнения оценки, и т.д.

Антивирусная защита или стремный и параноидальный NOD32


Недавно во время выпуска программного продукта, который мы разрабатываем, возник казус. Мы обнаружили подозрение на вирус в исполняемой программе программного продукта.

Продукт наш — коммерческий, нацеленный на промышленный и образовательный рынки. Стоит продукт несколько сот долларов. Обнаружение вируса для нас — это ЧП. Так как под угрозой репутация и наша и нашего заказчика. Поэтому мы очень тщательно относимся к регулярной проверке всех компьютеров проекта на вирусы. Пользуемся мы Нортоном. Перед выпуском продукта мы решили проверить еще и NODом. Нашему удивлению не было предела, когда NOD32 выдал «подозрение на «win32/genetik». Сразу же по проекту была объявлена боевая тревога. Помимо внеочередной проверки всех компьютеров проекта, мы начали отрабатывать несколько вопросов:

1. Что такое «win32/genetik»? Что делает «win32/genetik»? Насколько он опасен? Нужно было найти описание «вируса».
2. Источник «win32/genetik» и как побороть «вирус».
3. Как объясниться с заказчиком.

1. Что такое «win32/genetik»? Что делает «win32/genetik»? Насколько он опасен? 

Базы вирусов на сайте NODа я не нашел. ESETу (разработчику NOD32) стоило бы сделать такую же базу, как сделал Symantec у себя на сайте. Однако описание «win32/genetik» я все-таки нашел на сайте NODа. Описание «вируса» было спрятано в документе «Mid-Year Global Threat Report» от ESET.

В документе сказано:

«The label Win32/Genetik is used to indicate files that have been detected as being malicious by a technique implemented in NOD32 and ESET Smart Security, using advanced heuristics to take advantage of the knowledge accumulated over years in our database of generic signatures. Files flagged by this name are detected proactively: once they have been analyzed by our virus lab, labeling may be updated to a more specific name.»

Если говорить простым языком, то это означает, что в файле нет конкретного известного вируса, и ESET определил файл как вредоносный с помощью своего эвристического алгоритма, который базируется на опыте компании ESET. Таким образом, достоверно неизвестно, что делает и насколько вреден файл, в котором обнаружен «Win32/Genetik».

Для более широкого изучения проблемы мы воспользовались сервисом: virustotal.com. virustotal.com в режиме реального времени проверяет конкретный файл на вирусы 39-тю антивирусными программами, среди которых: Norton, McAfee, Microsoft, AVG. Как и в случае с коробочным вариантом NODа, NOD на virustotal.com показал: «probably a variant of Win32/Genetik «. Все другие антивирусы ничего не нашли.

Забегая вперед… вообще этот эвристический алгоритм ESET — ошибочный. И компания ESET бьет по своей репутации, когда NOD32 напрасно ругается на «чистый» и популярный коммерческий продукт. Думаю, это вполне может стать поводом для судебного иска. Ведь ложно-позитивная тревога может отпугнуть пользователей продукта, что скажется на доходах разработчика, на его деловой репутации.

2. Источник «win32/genetik» и как побороть «вирус».

Мы еще раз проверили все компьютеры на проекте. Вирусов нет, за исключением разных билдов нашей программы, где NOD32 также находил Win32/Genetik. Учитывая, что это только подозрение и результат эвристического алгоритма, мы начали разбираться с внутренностями файла. Методом исключения и исследования кода, мы выяснили проблему. Проблема заключалась в использовании в программе функций WinAPI для работы с процессами. Причем, если использовать эти функции по-другому, то NOD32 не ругается. Мы внесли соответствующие изменения в следующую версию продукта.

3. Как объясниться с заказчиком.

Собственно еще до того, как мы выяснили причину «вируса», нам нужно было принять решение, сообщать заказчику о подозрении на вирус или нет. Дилемма. Если мы сообщаем, что мы выпустили продукт с вирусом, то это подпортит нашу репутацию, усложнит отношение с заказчиком, ну, и все вытекающие последствия. Если мы не сообщим заказчику о подозрении на вирус, и вирус обнаружат пользователи продукта, то это будет еще хуже, чем, если бы мы сказали сами. В любом случае у нас оставался достаточно большой шанс, что это не вирус, а ложная тревога. У нас не было конкретной информации о причинах появления вируса, как вылечить программу, какие шаги заказчику предпринимать. У нас не было времени, так как заказчик должен был через несколько часов анонсировать выпуск продукта. Поэтому учитывая все факторы, мы все-таки решили сообщить заказчику о проблеме. Заказчику я рассказал все как было: подозрение на вирус у NOD32 в результате эвристической проверки, что не дает 100 уверенности что это таки вирус, другие антивирусные программы (АВ-программы) вирус не находят, мы работает над окончательным выяснением ситуации. Заказчик воспринял наше сообщение вполне нормально, начал дополнительно проверять другими АВ программами, отослал файл с подозрением в ESET, virustotal.com и еще куда-то. Заказчик сразу написал FAQ для пользователей. Когда мы выяснили источник проблемы и сообщили заказчику, он был поражен нашей профессиональной работой. В этой ситуации мы показали оперативность и профессионализм, причем, это заметил заказчик и похвалил.

Через несколько дней ESET отреагировал на нашу/заказчика жалобу и выпустил обновление базы, которая уже не ругалась на наши файлы.

Уроки. Лучше перебдеть, чем недобдеть

1. Регулярная антивирусная проверка необходима и критично важна. Вы минимизируете риск инфицирования данных и сможете заказчику сказать, что вы регулярно проверяете его информацию, данные, продукт, что в свою очередь будет свидетельствовать о вашем профессионализме относительно безопасности.

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

3. Дополнительные проверки лучше делать до того как файлы попадут заказчику. У нас так получилось, что мы делали дополнительную проверку уже после того как файл был отослан заказчику. Собственно, дополнительная проверка NODом была произведена случайно — программист просто решил проверить файл именно NOD32. Если бы мы проверили файл до отсылки заказчику, то у нас было бы время на то чтоб исследовать нашу вирусную тревогу, исправить проблему и отослать стерильный файл заказчику. В этом случае не нужно было бы тревожить заказчика, и выпуск прошел бы гладко. Правда, тогда возможно пользователи начали бы жаловаться на сообщения NODа о «win32/genetik» в файле…

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

1) Сказал, что одной из АВ-программ был обнаружено подозрение на вирус. Все остальные программы вирусы не обнаружил. Перечисли АВ-программы.
2) Показал официальное описание «вируса» от разработчика АВ-программы. Описание вируса позволило несколько разрядить обстановку. Ведь выясняется, что нет 100% уверенности в том, что в программе есть вирус.
3) Сообщил, что мы в процессе выяснения причин возникновения проблемы и ее решений.

Конечно, заказчик не будет рад вашим сюрпризам, но у него будет шанс предпринять какие-то действия и не засветить проблемный продукт пользователям. Пусть лучше заказчик узнает о проблеме от вас, чем от пользователей. Тут даже не важно, реальный это вирус или нет. Ведь пользователи, которые часто не имеют компетенции в «вирусологии» и не понимают, что вируса в файле реально нет, 100% будут жаловаться на то, что АВ-программы ругаются. Если вы сообщили о подозрениях, у заказчика есть возможность отослать самому или поручит вам отослать файл разработчикам АВ-программы для аудита. Также заказчик сможет отменить выпуск, снять файл с загрузки, сообщить пользователям и т.д. Вообще, скрывать информацию плохо. Это рано или поздно приводит к неприятным сюрпризам. «Все тайное становится явным».