[225x42]
TechNet Home > TechNet Magazine > June 2007

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

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


Это странно, но разработчики смотрят на программное обеспечение не так, как администраторы. Разработчики имеют дело с кодом, проходами по стеку, XML-файлами настроек, идентификаторами GUID и сборками. Администраторы общаются со сценариями и оснастками консоли MMC (во всяком случае, хотели бы).

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

Я раньше думал, что Xcopy, Regedit и Notepad — лучшие средства для установки программного обеспечения. Теперь я знаю, что лучшее средство — установщик Microsoft (MSI), который можно настраивать, устанавливать и удалять. Я знаю, что было бы не лучшей идеей заставлять администратора настраивать веб-службу, редактируя XML «Блокнотом», и что оснастки MMC (или сценарии Windows PowerShell™) куда приятнее. Я знаю, что содержимое стека — не лучший способ представить администратору причину ошибки и возможные пути ее устранения, и что хорошо описанное событие в журнале приложения куда лучше. Я знаю, что для создания программного обеспечения, которым администраторы смогут пользоваться, нужно рассматривать их как пользователей.

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

Ладно, про яхту это я слишком. Но создание разработчиками более управляемых приложений — совсем не мечта, а вполне достижимая цель. И от вас это тоже зависит. В следующий раз, когда что-то пойдет не так, не надо просто посылать разработчикам электронное письмо и тихо говорить нехорошие слова. Вместо этого предложите им записывать событие в журнал приложения или завести счетчик производительности либо еще какой-нибудь индикатор неисправности. А лучше предложите возможную причину и решение. Попросите задействовать сценарий Windows PowerShell или консоль MMC для настройки приложения. На самом деле, разработчики не всегда знают, что вы вообще есть, не говоря уже о ваших нуждах. Просто дайте им знать.


http://www.microsoft.com/technet/technetmag/issues...ieldNotes/default.aspx?loc=ru/
Полевые заметки. Дэвид Айкен (David Aiken)