«Директор информационной службы»
Обсуждая постановку процесса управления проектами, нередко забывают, что выполняют проект люди
О стандартных проблемах, возникающих в проектах, — формулировке требований, планировании, распределении ресурсов и времени, анализе рисков и управлении изменениями, — а также о существенном влиянии «человеческого фактора» говорил один из самых признанных за рубежом консультантов по управлению проектами Скотт Беркун на авторском семинаре «Искусство управления проектами», организованном IT-Online Group.
Беркун в течение девяти лет работал в корпорации Microsoft, начав свою деятельность с дизайнера пользовательских интерфейсов. Основу его знаний составляли «компьютерные науки», частью которых являлась эргономичность интерфейсов. Готовность и способность принять больше ответственности на себя и знания в области управления проектами привели его к участию и руководству проектами, связанными с разработкой операционной системы Windows, браузера Internet Explorer, Internet-портала MSN. Беркун, в настоящее время независимый консультант, ответил на вопросы редактора журнала «Директор информационной службы» Марины Поляковой.
Методологий управления проектами много. На которой из них остановить выбор? Какие ошибки здесь обычно допускаются?
Многие менеджеры выбирают самостоятельно, какую методику следует применить при решении той или иной задачи. Однако будет ошибкой, познакомившись с одной методологией, сразу остановиться именно на ней, не рассмотрев другие варианты. Хороший менеджер должен обдумать ситуацию, посмотреть на команду, заказчиков и для каждой задачи выбрать свой подход. Жизнь разнообразна, и универсального решения на все случаи не существует.
Вы утверждаете, что следует больше времени уделять людям в проектах и их взаимоотношениям. Означает ли это, что нет нужды строго следовать рекомендациям РМВoК?
Думаю, здесь нет противоречия. Все, о чем я говорю, не противоречит рекомендациям этого свода знаний. Это просто два разных способа думать об одном и том же. Что же касается важности управления коммуникациями в проекте, то в проектах разработки программных систем программисты работают в одиночестве 30% времени, 50% времени проводят с еще одним человеком и 20% — с двумя и более людьми. Таким образом, 70% времени они общаются, поэтому коммуникации в проекте — самая важная составляющая. Схожая картина и в других областях.
Планирование — один из самых сложных процессов. Как составить хороший план?
Часто бывает, что нет ясного видения проекта, задачи проекта не определены, нет четких направлений работы. Когда я работал в Microsoft, многие считали, что хороший план — это тот, который тщательно проработан. Я же считаю, что основной признак хорошего плана — его гибкость, многовариантность. Другими словами, хороший план, несмотря на неожиданности, должен сохранять актуальность. Главное — уверенность в себе и в коллегах, в их квалификации: чем уверенность больше, тем выше вероятность закончить проект в срок и в полном объеме.
Чем характеризуется «человеческий фактор» в проектах, на что следует обратить особое внимание?
Сотрудники, с которыми вы работаете, в первую очередь инженеры и дизайнеры, любят свое дело. Поэтому важно учитывать их амбиции, стимулировать к работе. Но не следует забывать, что порой ввиду тех же амбиций они готовы взвалить на себя больше, чем могут выполнить, особенно если приходится заниматься сразу несколькими проектами. При составлении графиков проектов руководитель должен уяснить, работали ли люди раньше вместе и умеют ли они работать в команде. Ели они уже работали сообща, то какие ошибки допускали, как над ними работали, удалось ли устранить ошибки. Вообще при составлении графиков проектов нужно всегда учитывать негативный опыт предыдущих проектов.
Что обычно не учитывают, планируя коммуникации в проекте?
Чаще всего проблемы связаны с информированностью участников проекта — получением необходимой информации о ходе проекта вовремя и ознакомлением с нею. Рассылка заданий и обмен информацией по электронной почте — простейший вариант, нужно лишь уметь наладить адекватный контроль. Ходить и спрашивать, получили ли письма подчиненные, — не лучший вариант; правильнее не забывать проставлять флажок отправки подтверждения о прочтении или делать это автоматически. Кроме того, запрос может быть получен, но не понят; очень часто сказанное вами не соответствует тому, что было услышано. Не забывайте позвонить и спросить, все ли понятно. Таким образом должна быть реализована цепочка: передача сообщения или задания, контроль получения, проверка понятности требований, согласование, реализация задачи.
Какие рекомендации в связи с этим можно дать менеджерам проектов?
Чем лучше установлены отношения, тем проще коммуникации в проекте. Мой подход — «управление на ходу» (management by walking around) — опирается на следующие принципы. Встречи с сотрудниками проводите неформально, на их рабочих местах, а не в вашем кабинете. Не забывайте спрашивать, как вы можете помочь им в работе, чтобы достичь цели быстрее. Слушайте их, по крайней мере, столько же, сколько говорите сами, и не забывайте, что ваши сотрудники — обычные люди со своими жизненными проблемами, не забывайте интересоваться ими. Прежде чем принять решение, спросите о возможных вариантах у участников проекта.
Начиная проект, обсудите со всеми, что может пойти не так, выясните, какие проблемы появятся с высокой вероятностью, и задайте коллегам вопрос о том, что бы они сделали, став руководителями проекта, для снижения выявленных рисков. Это заставит их думать и затем действовать по-другому, понимать, почему было принято то или иное решение. Но главное — учиться на ошибках, допущенных в проекте, думать, как их можно было бы избежать изначально. Правда, реализовать это сложно, если сотрудники считают, что «разбор полетов» производится только для того, чтобы найти виновного и наказать его. Так случается, когда участникам проекта не удалось стать командой, то есть научиться доверять друг другу.
В нашей стране Вы известны как менеджер по управлению проектами в области разработки программного обеспечения. Какие методологии можете рекомендовать своим клиентам?
Иногда, когда мне приходится налаживать в компаниях управление проектами, я рекомендую eXtreme Programming и Scrum как наиболее подходящие методики. Хотя в первую очередь проблемы заключаются в людях. Главное — контролировать ход реализации проекта. Например, методики быстрой разработки подразумевают ежедневные встречи для контроля того, что сделано, прежде чем двигаться дальше. Но если вы, как руководитель, будете ходить и у каждого ежедневно спрашивать о проделанной работе, ни на что другое у вас не останется времени. Все должно быть сбалансировано. При разработке программного обеспечения обычно бывает достаточно еженедельных оперативных совещаний для определения статуса проекта. Основные вопросы, на которые при этом нужно получить ответ: какие задачи выполнены, к каким новым следует приступить, какие работы следует прекратить и готовы ли к новой рабочей неделе.
Вам приходилось работать с междисциплинарными проектными командами. В чем заключалась Ваша основная роль?
В проектах, в команду которых входят аналитики, дизайнеры интерфейсов, программисты, инженеры по управлению качеством, менеджер выступает как переводчик. Однако стоит отметить, что при разработке следует воспользоваться рекомендациями SWEBoK; этот сборник знаний по программной инженерии является гидом для устранения разногласий.
Одна из основных проблем разработки — определение качества. Как, например, измерить качество разработки ориентированных на пользователя интерфейсов? Как понять, что проект близок к завершению, что достигли желаемого?
Процесс разработки, как и любой проект, делится на этапы, каждый из которых заканчивается исследованием пользовательских свойств: измеряется возможность для людей закончить процесс (решить задачу, предусмотренную в продукте, проекте), и в конце можно увидеть, какой процент пользователей справляется со всеми задачами. При этом состав тестирующих людей в каждом следующем тесте должен быть другой — тестировщики не должны видеть предыдущую версию интерфейса. Это нужно для чистоты тестирования. Иногда сменятся три-четыре версии продукта, прежде чем он будет сдан.
Не противоречит ли подобное тестирование usability (стандарт ISO 9241-11 определяет usability, или «практичность программного обеспечения», как степень эффективности, продуктивности и удовлетворенности, с которой продукт может использоваться определенными пользователями для достижения определенных задач в определенном контексте. — М. П.) естественной потребности компаний сохранить инвестиции, сделанные в программное обеспечение ранее? Не дешевле ли обучить сотрудников, вместо того, чтобы заниматься тестированием и выпуском очередных версий?
Однозначного ответа здесь нет. Скажем, о продуктах Apple сложилось мнение, что их «легко использовать». Однако на то, чтобы обеспечить эту «легкость использования», компания израсходовала немало средств, зато теперь у нее нет необходимости в разработке инструкций пользователям и документации. Microsoft, напротив, тратит много денег на документацию и инструкции. Ответ на вопрос, что дешевле, зависит от бизнес-стратегии компании, от того, что в ней считают «высшим качеством». Например, если говорить о качестве разработки сайтов, то далеко не все обращают на него внимание. Для многих важнее цена; качество сайта для них не является критическим фактором успеха — они используют другие пути достижения успеха в бизнесе, и для них нет необходимости в тестировании эргономичности интерфейса.
Вы утверждаете, что тестирование позволит сэкономить средства, если его провести с самого начала при разработке вместо того, чтобы выпускать новые версии. Но мнения об удобстве пользования меняются со временем. Так зачем сразу тратить средства на тестирование, если потом все равно будут вноситься изменения и можно улучшить интерфейс?
Во-первых, нужно быть уверенным, что всем удобно пользоваться. Создать сайт очень дорого, и прежде, чем он будет закончен и сдан клиенту, он должен быть «доведен до ума». Тестирование поможет сделать это правильно. Во-вторых, тестирование поможет заранее выявить ошибки, упущения и неудобства. Это лучше, чем обнаружить их в процессе эксплуатации.
На интерфейс и удобство пользования им влияет много факторов. Что следует учитывать при разработке пользовательского интерфейса?
К примеру, стул создан для людей разного роста, и сидят на нем как высокие, так и низкие люди. Создавая его, мы должны думать о людях с разными параметрами. Невозможно создать Web-сайт, который был бы удобен всем, нельзя учесть пожелания всех и сделать так, чтобы всем было удобно. Но если клиент настаивает на другом решении, заведомо неверном, надо объяснить, почему это неудобно, и что ваше экспертное мнение поможет получить удовлетворение от проекта, то есть предлагаемое решение даст ему максимум преимуществ. Вы должны объяснить, почему все так, а не иначе. С самого начала должно быть установлено, что является наиболее удобным, и что решение, которое вы предлагаете, является лучшим.
Но это означает, что usability — результат обучения. В таком случае, зачем тратить средства на тестирование, ведь можно просто обучить пользователей?
Испытание с помощью пользователей может выявить проблемы и пути их разрешения. Понять, чем невозможно воспользоваться, с чем люди борются в созданном вами продукте. Тестирование позволит выявить проблемы использования того же сайта в работе. И потом, это поможет каждому в компании понять, насколько опыт его работы отличается от стандарта.