Конференция Software People 2009

Здравствуйте!

Недавно меня пригласили на конференцию Software People 2009, которая проходила 21-22 мая.

Если кратко, то лично я ожидал от этого мероприятия большего.

Мне понравился доклад, описывающий возможности Windows Azure для разработчиков, а так же перспективы использования Windows Azure для бизнеса.

После рассказа про возможности интеграции TFS с MS Project я понял для себя, что пока точно не буду использовать эти два продукта в связке – сыровато и неудобно.

Из доклада по Continues Integration узнал несколько полезных штук. Например, о том, что в систему автосборки можно вставить модуль от BlackDuck по проверке кода, используемых модулей и библиотек на предмет их лицензии – полезно для тех, кто разрабатывает коммерческие продукты при этом используя open source. Подробнее смотри на http://www.blackducksoftware.com/. Из того же доклада я почерпнул идею о т.н. fly builds. Идея в том, что перед тем, как система хранения кода разрешает разработчику сделать check in в общий репозиторий, проводится билд модуля, в который внесены изменения и в случае, если билд не прошёл, код не чекинится.

Доклад под названием “Эффективное определение и описание требований как необходимое условие успеха проекта” оказался обычной (по правде говоря, скучноватой) демонстрацией продукта IBM Rational Requirements Composer, который позволяет собирать требования и прототипировать GUI будущего приложения.

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

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

С программой конференции, некоторыми материалами и презентациями можно ознакомиться на сайте http://www.softwarepeople.ru/

PMBOK Guide 4th Edition уже доступен в виде PDF файла для участников PMI

Привет!

Всем зарегистрированным участникам PMI доступен полный PMBOK Guide четвёртого издания на английском языке. На русском – только часть.

Я уже скачал и уже читаю. Примечательно, что скаченный PDF-файл именной и запаролен моим паролем от сайта PMI.

Да, чуть не забыл, PMBOK Guide 4th Edition на английском, русском и других языках можно скачать отсюда:

http://www.pmi.org/Resources/Pages/Members/Library-of-PMI-Global-Standards-Projects.aspx

Скачивайте и наслаждайтесь (те, у кого есть доступ =)

SCRUM и XP - успехи внедрения и планы на будущее

Привет!

Прошедшие два месяца занимались с командой переходом на “методологию” SCRUM. Не забавы ради, а по необходимости.

Основное ядро системы мы уже выпустили в прошлом году, и последние полгода занимаемся наращиванием функциональности по требованиям наших заказчиков. При этом представителей заказчика достаточно много – это и маркетологи, и аналитики, и люди от бизнеса, и внешние эксперты по UI и usability, и субподрядчики и кого только нет! И всеми этими людьми, их требованиями на изменение системы и на её доработку нужно управлять. Чем я и занимаюсь по сей день =)

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

Проанализировав сложившуюся ситуацию мы решили – SCRUM спасёт отца русской демократии!

Начал я с того, что разослал всем членам команды на прочтение замечательную книгу “Scrum и XP: заметки с передовой”. Сам прочитал её три раза. Вообще говоря, эта книга в первый месяц была моей настольной и очень мне помогла не наступить на различные грабли, которые валялись то тут, то там на нашем пути ) Спасибо авторам и переводчикам!

В итоге мы успешно завершили два спринта, и я начал приучать наших заказчиков к периодичности выпуска версий – раз в три недели. Сейчас получается так, что я являюсь и SCRUM-мастером и product-owner’ом в одном флаконе. Собираю требования со всех стейкхолдеров, аккумулирую их, организую серию встреч на которых проставляется Важность каждого требования (user story). Затем, всё по писанному…

Более того, мне, наконец, удалось подвести команду к тому, что бы они сами предложили внедрить две замечательные, на мой взгляд, практики из экстремального программирования – парное программирование и TDD. Верите или нет, но у нас получилось внедрить парное программирование! =) Сам до сих пор поверить не могу =) С TDD тоже дело идёт на лад.

Следующая задача для меня – внедрить SCRUM в головы членов команды. Вот что я имею в виду. Раньше, при прежнем процессе, в команде было очень чёткое распределение ролей – дизайнеры, тестировщики, аналитики, архитектор, разработчики, менеджер. В случае, если аналитики что-то не успевали описывать для разработчиков или описывали не полностью, то разработчики кивали на аналитиков, дескать, они нам не подготовили, и сидели, ждали, когда будет обновлена спецификация (ТЗ). По SCRUM’у – вся команда ответственна за результаты спринта. Разделение ролей у нас сохранилось, пока сохранилось и отношение, с чем я всеми силами борюсь. Т.е. не должно быть ситуации, когда на мой вопрос (как product owner’a =) “почему до сих пор не готова эта user story в самой большой важностью” дев лид отвечает “тестировщики поганцы, не протестили! Иди (менеджер) попинай их!”. Я глубоко уверен в том, что за тестирование должен нести ответственность главный тестировщик, за архитектуру – архитектор, за аналитику – аналитик, за весь проект в целом – менеджер (это убеждение как-то глубоко во мне укоренилось и расставаться с ним я пока не спешу =). Но вот отношение к своим обязанностям, я считаю, нужно менять. Если нужно – я сам сижу и занимаюсь аналитикой, пишу техническую документацию для разработчиков, обсуждаю архитектуру, тестирую, помогаю с простой вёрсткой. Но со мной понятно – я менеджер. А вот когда внутри команды разработчики, видя прорехи в тестировании, самостоятельно предлагают помощь тестировщикам или, зная о системе больше юзабилити аналитика, подкидывают ему идеи, как можно реализовать то или иное требование более изящно и просто – это есть счастье для любого менеджера!

Вот к этому и идём =)

Конференция «Сложности внедрения проектного управления»

Привет.

Краткий анонс.

27 октября 2008 года состоится конференция «Сложности внедрения проектного управления», организуемая компанией “Богданов и партнеры”. Участие в конференции бесплатное, по предварительной записи.

Краткое описание целей конференции с сайта компании:

“Развивайте Ваши навыки управления проектами!

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

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

Ознакомиться со списком докладов и зарегистрироваться вы сможете со страницы на сайте компании “Богданов и партнёры”: Конференция «Сложности внедрения проектного управления».

Почему важно понимать бизнес заказчика.

Привет!

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

Уже больше года я руковожу рядом проектов в рамках одной программы, реализуемой для крупной российской компании, услугами которой пользуется, наверное, пятая часть населения страны. Один из проектов в рамках этой программы – разработка web-сайта для миллионной аудитории клиентов данной компании. Бизнес заказчиков этого сайта несколько: отдел маркетинга, отдел продаж, отдел работы с партнёрами компании и верхушка в лице нескольких заинтересованных лиц. И у всех этих заказчиков свои бизнес цели и, соответственно, свои требования к сайту и его функционалу. На выявление и документацию только бизнес требований всех заинтересованных сторон ушло два месяца очень и очень плотной работы – постоянные встречи, опросы, интервью, формулировка всего услышанного на бумаге и согласование. Я, как менеджер этого проекта, старался присутствовать на всех подобных встречах. Когда, наконец, все требования бизнеса были документированы и согласованы начался этап сбора функциональных и нефункциональных требований, но это отдельная история.

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

Через пару дней представитель отдела работы с партнёрами компании нашего заказчика звонит и говорит, что 1 ноября сайт должен работать кровь из носу и (внимание!!!) содержать новую функциональность, которая критична для партнёров. И сделать это нужно именно к 1 ноября, т.к. уже заключены ряд договоров с партнёрами компании. И в этих договорах прописаны пункты, согласно которым компания заказчика должна 1 ноября предоставить определённые сервисы клиентам партнёров посредством web-сайта, иначе – штрафы. С таким подходом (сначала заключаем договоры с указанием сроков, потом ставим в известность исполнителей), я думаю, встречались многие.

Что тут началось… Спонсор проекта со стороны заказчика звонит моему руководству и говорит, что 1 числа сайт должен работать и точка! Моё начальство звонит мне, предлагает взять в команду ещё людей, порвать тельняшки, ни шагу назад, за нами Москва и т.д. и за оставшийся месяц реализовать новую функциональность, провести полный цикл тестирования и установить сайт на пока отсутствующее железо =) Одним словом, запахло управленческим беспределом.

На предложение добавить людей в команду разработки сайта я сразу сказал “НЕТ!”. Согласно правилу Брукса, уже подтверждённому и моим опытом тоже, инъекция “неподготовленных” людей в проект разработки программного обеспечения, находящийся в завершающей фазе, лишь усугубляет ситуацию со временем окончания проекта. Это факт! Предложение “порвать тельняшки” в данном случае меня тоже не вдохновило, т.к. тельняшки рвать имеет смысл тогда, когда и менеджер и команда на 100% уверены в том, что после трёх недель работы по 14 часов в сутки они наверняка успеют и сделают то, что удовлетворит и их (команду разработки) и заказчика. Иначе, если три недели пота и крови заканчиваются разочарованием заказчика из-за нереализованных требований и неудовлетворённостью команды, общий моральных дух команды резко падает, желания работать и мотивация снижается ниже плинтуса. Хороший PM, на мой взгляд, никогда не должен допускать такой ситуации, т.к. люди в конечном итоге всегда важнее любых сроков.

Я сел и стал думать, что можно сделать, имея жёсткие временные ограничения, новые требования к функционалу и свободные ресурсы, не занятые на разработке сайта, но и не имеющие представления о проекте. В итоге, двигаясь в своих размышлениях снизу вверх, я дошёл до того, с чего, по-хорошему, нужно было начинать с самого начала. С бизнес требований данного конкретного заказчика. И подумав о бизнес целях, ещё раз их проанализировав, я понял, что отделу работы с партнёрами нужен на самом деле не сам сайт целиком, со всем его наполнением и возможностями, а только небольшая часть функционала, покрывающая потребности данного бизнес заказчика. Я прикинул, что если собрать, как пишет ДеМарко, “команду тигров” (команда из двух-трёх человек, способных “порвать” всё что угодно – реализовать любое сложное техническое решение в кратчайшие сроки =), то вполне можно реализовать до нужного срока отдельный сайт с ограниченным функционалом, который полностью покроет требования заказчика. Таким образом, минимизируются риски срывов сроков разработки, риски связанные с дальнейшими возможными проблемами с поставкой оборудования (т.к. этот небольшой сайт можно будет развернуть на существующем железе) и с переутомлением команды, занимающейся разработкой основного сайта. Красота =)

Сделав предварительную оценку трудозатрат и сроков, я позвонил заказчику и рассказал ему своё предложение. Заказчик был в восторге от такого решения, т.к. его полностью устраивало такое решение с учётом того, что на уровне БД и сервисов этот отдельный сайт будет совместим с основным и в будущем нам будет легко мигрировать все данные и функционал.

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

Лишь понимание того, для чего именно в конечном итоге нужен web-сайт отдельно взятому бизнес заказчику, позволило мне принять оптимальное, на мой взгляд, решение.

Подача заявки на сдачу экзамена PMP. Часть 1.

Привет!

Мне уже не в первый раз приходят письма от читателей, в которых меня спрашивают как я подавал заявку на сдачу экзамена PMP, что собой представляет подтверждение опыта работы и подтверждение необходимого числа PDU (personal development units).

В этой заметке отвечаю на часть вопросов.

После регистрации на сайте http://pmi.org/ у вас появляется возможность подать заявление на сдачу экзамена PMP (см. стр. https://www.pmi.org/certapp/). Для этого необходимо перейти по ссылке “Apply for PMP Credential”, как показано на рисунке:

Затем в соответствующих разделах необходимо указать всю необходимую информацию:

Вам сразу предлагают ввести контактные данные (разделы “Contact Address” и ”Contact E-mail, Phone”). Тут всё просто и понятно. Заполнили данные на странице и нажимаете кнопку “Next” для перехода к следующему шагу. После того, как вы ввели свои контактные данные, e-mail и телефон, в разделе “Attained Education” необходимо указать ваше образование, год, когда получили диплом, название учебного заведения, его адрес и предметную область, в которой вы получили образование.

Далее, в разделе “Requirements” на первой странице “ PMP Requirements Overview” вам подробно рассказывается о требованиях, которые предъявляет институт PMI к кандидатам на сдачу экзамена. Данные требования делятся на два раздела: “Project Management Experience” и ” Project Management Education” – требования к опыту работы в области управления проектами и требования к образованию в области управления проектами. На странице всё очень подробно и понятно написано. Я намеренно не пишу, сколько часов и месяцев требует PMI в данный момент от кандидатов, т.к. данные требования могут измениться.

На странице “Worksheet” представлена таблица, в которой вы всегда сможете посмотреть, сколько часов опыта и образования необходимо для подачи заявки и сколько часов вы уже подтвердили:

“PM Experience Months” – это длительность, а “PM Experience Hours” – это трудозатраты =) К примеру, вы могли последние три года работать в области управления проектами (PM Experience Months = 36), но т.к. совмещали должность менеджера проектов с должностью аналитика, то “PM Experience Hours” может быть значительно меньше необходимых 4500 часов или, если вы все три года на 100% работали PM’ом, то “PM Experience Hours” будет превышать 4500 часов.

Переходим к странице “PM Experience” и нажимаем на кнопку “Add Experience”. Далее для каждого проекта, в котором вы учувствовали, необходимо указать некоторые данные, которые вы будете вводить поэкранно, на каждом экране нажимая кнопку “Next” для перехода на следующий экран.

На первой открывшейся странице заполняем все поля, а именно: название вашей должности, даты начала и окончания проекта, ваша роль в проекте, предметная область проекта. Это просто =) Нажимаем “Next”. На следующей странице необходимо указать данные о компании, в которой вы работали над данным проектом: ваша должность в компании, название компании, адрес и телефон. Опять нажимаем кнопку “Next”. Настало время ввести контакты человека, с которым вы работали в этом проекте и который в случае необходимости (звонка из PMI) сможет подтвердить ваше участие в данном проекте. Необходимо указать имя человека, проектные “отношения” (заказчик, менеджер, участник и т.д.), контактные данные этого человека. Опять нажимаем кнопку “Next”.

И тут начинается самое утомительное: необходимо для каждого проекта заполнить часы, потраченные вами на каждую группу процессов и на каждую из перечисленных задач в каждой группе. Лично я, что бы не запутаться, сначала сделал таблицу в Excel для всех своих проектов в которой расписал промежуток времени в течении которого я работал над каждым проектом и количество часов, потраченных мной на каждую группу процессов. У меня получилось, что на каждую группу процессов в каждом проекте я в среднем тратил следующее количество времени (в процентах) от всего времени проекта:

Initiating	Planning	Executing	Monitoring and Controlling	Closing
12%	26%	29%	23%	10%

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

Я описывал шесть своих проектов, некоторые из которых перекрывались во времени. В случае перекрывающихся по времени проектов, необходимо следить за тем, что бы по ошибке не вписать по 100% времени на каждый проект (получится, что в сутки вы работали по 16 часов, такое конечно бывает, но не на протяжении года =) Одним словом, нужно быть очень внимательным при заполнении часов по проектам, т.к. (как мне лично кажется) небрежно заполненные часы с явными несоответствиями могут привести к тому, что ваша заявка попадёт под аудит PMI и тогда всё значительно усложнится (об аудите я расскажу в отдельной заметке, если это будет интересно – пишите в комментариях).

Итак, когда вы внесли всю информацию по всем проектам, можно перейти к разделу “PM Education”, в котором необходимо указать название курса, имя провайдера обучения (компании, в которой вы проходили обучение – она должна быть зарегистрированным провайдером обучения в PMI), даты начала и окончания курсов, количество фактических часов обучения (Hours) и количество часов, которые идут в зачёт PDU (Qualifying Hours). Я проходил курсы в компании PMExpert и в поле “Course Title” указывал не только название курса, но и его код, который указан на выданном сертификате.

После того, как вы закончили вносить информацию об образовании в области управления проектами, вам осталось совсем немного: раздел “ Optional Information” можно в принципе пропустить, можно и заполнить, на ваше усмотрение; в разделе “ Certificate” необходимо указать своё имя в точности так, как оно потом будет указано на вашем будущем сертификате; в разеделе “Agreement” вам предлагают ознакомиться и согласиться (или не согласиться) с соглашением; в разделе “Review & Submit” вам покажут сводную таблицу по всем предыдущим разделам и в случае, если что-то осталось незаполненным – укажут на это.

Если всё заполнено и вся введенная информация верна, ставьте галку “All information that I have provided is accurate and complete” и нажимайте кнопку “Submit Application”. Ваша заявка уходит на рассмотрение.

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

Стоит отметить, что заполнение данных заявки может происходить не в один присест. Т.е. сегодня вы можете заполнить данные об образовании, завтра внести данные об одном проекте, на следующей неделе о другом и т.д. Все данные, которые вы указываете, после нажатия на кнопку “Next” или “Submit” сохраняются на сайте, и вы в любое время можете их изменить или дополнить. Так что пока вы не поставили галку на пункте “All information that I have provided is accurate and complete” и не нажали кнопку “Submit Application” – всё можно отредактировать.

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

Удачи!

PMBOK Guide 4ое издание – как оно влияет на ваш экзамен

Привет!

В этой заметке привожу свой вольный перевод статьи “The PMBOK Guide 4th Edition - What it means for your Exam”, которая опубликована в блоге Корнелиуса Фихтнера, PMP (Cornelius Fichtner, PMP). Оригинал статьи можно прочесть здесь.

Автор: Cornelius Fichtner, PMP
Перевод: Алексей Павлов, PMP

PMBOK Guide 4ое издание – как оно влияет на ваш экзамен

Ранее в этом году Project Management Institute (PMI) выпустил предварительный вариант PMBOK® Guide 4th edition. Вот что PMI пишет о данном предварительном варианте: “Все глобальные стандарты PMI были выработаны общими усилиями, учитывая знания, мнения и опыт типичных проектных команд, экспертов и других профессионалов в области управления проектами. Период публичного обсуждения предварительного варианта является критичным для достижения консенсуса”. Сразу после выпуска предварительного варианта PMBOK® Guide 4th edition PMI по всему миру начал собирать обратную связь от менеджеров проектов. Эта обратная связь будет (или не будет) включена в новый вариант руководства.

Я ожидаю, что официальный выпуск четвёртого издания PMBOK® Guide произойдёт в декабре 2008 года. Для меня, как для PMP-тренера, это означает, что я начинаю получать письма, содержащие два типа вопросов. Первый тип вопросов приходит от моих действующих студентов, которые обеспокоено спрашивают о том, как выход новой редакции PMBOK® Guide повлияет на предстоящий экзамен PMP. Они хотят знать придётся ли им сдавать экзамен, основываясь на выходящем PMBOK® Guide 4th edition. Второй тип вопросов поступает от моих бывших студентов, которые совсем недавно стали PMP. Они задают один из двух вопросов: “Придётся ли мне пересдавать экзамен?” либо “Значит ли выход новой редакции руководства то, что у меня будет “устаревший” сертификат PMP?”

Ответ на все три вопроса: Нет. Далее приведены детальные ответы:

Вопрос: “Придётся ли мне сдавать экзамен на PMP по новому PMBOK сразу после его выхода?” Ответ: Нет. Оглядываясь назад мы видим, что всякий раз, когда PMI выпускает новую версию PMBOK Guide, они устанавливают некоторый временной интервал, в течении которого экзамен на степень PMP основывается на предыдущей версии руководства. Это период составляет 8-10 месяцев. Я бы ожидал вступления в силу “нового” экзамена на PMP где-то между августом и сентябрём 2009 года. Точнее будет известно, когда PMI объявит официальную дату. Всем, кто подал заявку на экзамен до официальной даты вступления в силу “нового” экзамена, будет позволено сдавать “старый” экзамен.

Вопрос: “Придётся ли мне пересдавать экзамен?” Ответ: Нет. Вам не требуется пересдавать экзамен PMP до тех пор, пока не пройдёт трёхлетний срок после которого необходимо подтверждать степень PMP, как это указано в PMI's Continuing Certification Requirements Program. Ваша степень PMP продолжает быть действительной.

Вопрос: “Значит ли выход новой редакции руководства то, что у меня будет “устаревший” сертификат PMP?” Ответ: Нет. Текущая версия PMBOK Guide никак не влияет на статус вашей степени PMP. Я сдавал экзамен на степень PMP в 2004 году, и я не являюсь “PMP второго издания”. Я просто PMP. Вы можете сравнить это со своим университетским дипломом. Вы получили диплом несколько лет назад, а учебная программа много раз поменялась с тех пор. Ваш диплом и степень PMP действительны сейчас так же, как были действительны после того, как вы сдали экзамен.

Короче говоря… если вы уже записались на экзамен, вы будете сдавать его по текущей версии PMBOK Guide. А если вы уже сдали экзамен, то никаких изменений вашего статуса не будет, только потому, что вышла новая версия руководства.

Архитектура есть всегда!

Анекдот из жизни.

Сегодня на обеде слышу разговор разработчика и архитектора - обсуждают небольшой недавно начатый проект:

<Разработчик встревоженно>: У нас на проекте нет ни одного документа, описывающего архитектуру! У нас и архитектуры никакой нет!

<Архитектор филосовски>: Архитектура есть - просто она очень простая...

Думаю, IT-шники шутку поймут =)

А у вас есть usability-аналитик?

Привет!

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

Сейчас, принимая запрос на изменение (change request) от заказчика, я сам занимаюсь usability-анализом, постановкой задачи дизайнерам (раньше с дизайнером взаимодействовал usability-аналитик), аудитом результатов его работы и конечной приёмкой работ дизайнера.

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

Что происходит, когда программисты проектируют интерфейс взаимодействия человек-машина хорошо и печально известно. Когда этой работой занимается менеджер проекта – результат не столь плачевен, т.к. менеджер ориентирован (должен быть) на удовлетворение заказчика. Но менеджеры всё же не аналитики и результат моих трудов, как usability-аналитика тоже на мой взгляд не удовлетворителен, даже не смотря на то, что мне часто приходилось выступать в роли не только бизнес- но и usability-аналитика. Проектирование взаимодействия, так же как и проектирование архитектуры системы, требует от человека сосредоточенности, погружения в т.н. “поток”. Только в таком состоянии приходят по-настоящему блестящие идеи и решения.

У руководителей проектов, так же как у программистов, дизайнеров и аналитиков, так же есть состояние “потока”, в котором их производительность и результативность сильно возрастает, но это совсем не тот “поток”, который нужен для работы над одной конкретной задачей. У меня в ежедневнике на каждый день записано десяток задач, каждую секунду в голове крутится ещё 3-4 и ежечасно возникают задачи, которые невозможно запланировать, но нужно решать прямо сейчас, не откладывая. В таком режиме, когда переключение между задачами происходит иногда по три раза в минуту, спроектировать действительно хороший сценарий взаимодействия невозможно.

Я знаю, что во многих компаниях считается, что иметь аналитика пользовательского интерфейса и usability-аналитика – это роскошь. Я сам работал в таких компаниях, где менеджерам приходилось самостоятельно проводить бизнес-анализ, затем анализ функциональности, затем usability-анализ и анализ внешнего вида системы, прорисовкой прототипов рабочих экранов и написанием спецификаций. Я сам всем этим занимался и знаю, что все эти задачи менеджер может сделать хорошо… но не блестяще. Сейчас мне крайне некомфортно, если в команде проекта нет выделенного аналитика, т.к. я точно знаю, что удобство использования будущего продукта, будь то сайт или десктопное приложение, значительно ухудшится при отсутствии такого рода эксперта. А значит, понизится лояльность конечного пользователя и заказчика, что с финансовой точки зрения гораздо “дороже” для компании, чем один эксперт в области usability в штате или на контракте.

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

Вопрос к тем, кто дочитал до конца – как у вас в компании обстоят дела с разного рода аналитикой? Кто ей занимается – специально обученные люди (эксперты-аналитики) или те, на кого падёт перст начальства или у кого есть время?