Отточенное искусство оценки - вот что исключает риск и хлопоты при планировании проекта
Том Смит, президент фирмы по разработке программного обеспечения и консультациям The SyllogisTeks (Сент-Луис), настолько верит в святость предварительных оценок, что неоднократно выходил из проекта, лишь бы не назвать нереалистичного срока или не дать неверную смету. Пока Смит не поработает над проектом столько, сколько нужно для уверенной оценки, дату завершения он не назовет. По его утверждению, "дату нам задают клиенты, а мы, уже имея представление о проекте, решаем, можем ли сделать работу к этой дате".
Потенциальные клиенты, которым такой подход не нравится, могут заниматься бизнесом в другом месте.
"Нам не так уж редко приходится отказываться от сделок, - поделился Смит. - Для нас всегда главное - наша собственная честность".
Конечно, Смиту легко идти по такой правильной дороге - он ведь консультант и может выйти из-за стола переговоров, когда захочет.
А менеджерам внутренних проектов по информационным технологиям такая роскошь в оценке сроков недоступна. Во многих компаниях менеджеры ИТ-проектов должны просто стискивать зубы и соглашаться со сроками, поставленными внутренним клиентом. В больших корпорациях особенно часто можно налететь на проект, который сильно выбивается из сроков или выходит далеко за рамки сметы. Кстати, Смит именно это подобие старой игры в угадайку называет как причину своего ухода из отдела ИТ корпорации в консультационную деятельность. Статистика провалов ИТ-проектов остается все такой же мрачной (см. врезку), и потому менеджерам ИТ придется оттачивать свои способности к предварительным оценкам - только при таком условии их проекты будут гарантированы от провала.
Большая часть оценок проектов создается с самыми лучшими намерениями. Сидит эдакий менеджер отдела ИТ в розовых очках и планирует стратегию своего поведения в совершеннейшем мире, в котором пользователи имеют многолетний опыт работы с ГИП и СУБД, требования пользователя записаны раз и навсегда золотом по мрамору и никто никогда не уходит в отпуск.
Но, играя по таким правилам в реальной жизни, вы сильно рискуете, что через несколько месяцев крайние сроки уже настанут и пройдут, деньги будут израсходованы, а конца проекта еще не видно.
Предлагаю вашему вниманию описание трех самых распространенных ошибок, допускаемых менеджерами отделов ИТ в черновых оценках проекта, и советы, как этих ошибок избежать
ЗАПАДНЯ НОМЕР ОДИН: ЭТО НЕ ТОЧНАЯ НАУКА
"Дорога в проектный ад вымощена точными оценками, - считает Гопал Капур, президент консультационной фирмы Center for Project Management (Сан-Рамон, шт. Калифорния). - Точная оценка - это оксюморон"*.
Менеджеры проектов вне области информационных технологий редко связывают себя точными оценками. Вместо этого они дают клиентам диапазон ожидаемых дат завершения проекта, а также спектр цифр, выражающих стоимость проекта по его завершении, - таково мнение Капура.
Полоса препятствий
Когда, например, строители собираются возводить дом, они не указывают покупателю дату вселения до того момента, пока не выкопан котлован. Капур советует менеджерам проектов точно так же дать в своих оценках диапазон значений вместо точных цифр.
Один из способов избегнуть соблазна точных оценок - ограничение горизонта оценки. Таково мнение Джейн Керри, старшего консультанта из консультационной фирмы Project Management Mentors (Сан-Франциско). Она считает, что первая фаза проекта должна занимать от двух до пяти месяцев.
Разбивая проект на обозримые фрагменты и проводя детальные оценки каждый раз только по одной фазе, менеджеры отделов ИТ получают более ясное представление о продвижении проекта и могут легко перестраиваться при. любых отклонениях от предварительных оценок.
ЗАПАДНЯ НОМЕР ДВА: ПОИСК ПОДТВЕРЖДЕНИЯ ОЦЕНОК
Оценки должны основываться на процессе, который можно продемонстрировать, - будь то формальное сравнение алгоритмов или случайный обмен данными. Это нужно, чтобы показать, что оценка взята не с потолка и что она достаточно обоснована для того, чтобы служить основой для обсуждения между участниками проекта.
По словам Капура, в оценке проекта должны быть учтены такие переменные, как уровень подготовки его участников, время работы и перерывов в ней, а также число проектов, в которых заняты сотрудники. При этом он добавляет, что "работники ИТ соглашаются на нереальные оценки так же неохотно, как другие специалисты, но быстрее, поскольку у них нет способов проверки".
Фред Ричардсон, менеджер по программной инженерии из фирмы по разработке ПО BDM Federal (Мак-Лин, шт. Вайоминг), твердо держится этого правила, но практикует более структурированный подход, используя для подтверждения своих оценок пакет Checkpoint фирмы Software Productivity Research.
Пакет Checkpoint содержит обширную базу данных с информацией, собранной по реальным, законченным проектам. Как говорит Ричардсон, "вы закладываете туда все переменные, и пакет выплевывает оценки для типовых проектов с такими параметрами".
На следующем этапе данные из Checkpoint вводятся в измерительную часть Process Engineer - пакета высокого уровня для ведения проектов фирмы LBMS. Ричардсон говорит: "За несколько минут мы с помощью Process Engineer разносим полученную из Checkpoint информацию по всему проекту и приходим к полному анализу и оценке стоимости проекта".
ЗАПАДНЯ НОМЕР ТРИ: СОХРАНЯЙТЕ ПОДРОБНЫЕ ЗАПИСИ
Если вы не ведете записей своих оценок и реальных цифр, то вам никогда не удастся улучшить свои оценки - так считает Капур: "У профессионалов ИТ не очень богатая история сбора такой информации".
Ричардсон из фирмы BDM согласен с тем, что протоколирование подробной истории проекта - момент ключевой. "У пас, - сказал он, - ведется подробная история сравнения реальных цифр с плановыми, поэтому мы учимся па своих ошибках вместо того, чтобы их повторять". Смит из фирмы SyllogisTeks использует карты PERT в пакете Project корпорации Microsoft для описания отклонения реальных дат от проектных. Он согласен, что "сотрудники отделов ИТ не начинают работу с уже готовым навыком построения оценок. И никто не посылал меня на курсы по оценке проектов, пока я не оказался в состоянии сам оплатить свое обучение. И это окупается".
| На той же странице Вот что надо спрашивать для проверки реальности сроков Предполагается ли - высокий уровень профессионализма - опыт в подобных задачах - малое количество перерывов - полная загрузка сотрудников этим проектом - адекватный ресурс - адекватные архивные данные - адекватные соглашения в области применения задачи Источник: Project Management Mentors |
Оценки для разработок клиент-серверных проектов, возможно, более подвержены ошибкам, считает Керри из Project Management Mentors, так как компании в большинстве своем имеют мало опыта в таких разработках. Если вы имеете дело с новыми технологиями, то имеет смысл скорректировать оценки в сторону увеличения, оставив какой-то процент на непредвиденный риск.
| Данные по развитию систем
"Иногда я просто жду следующего отказа. Настоящее тестирование начинается, когда касаешься сути" - Бад Хэтфилд, соучредитель и председатель корпорации Kwik Кору
Медленная поступь Согласно недавнему докладу фирмы Forrester Research (Кембридж, шт. Массачусетс), преимущество Fast Ethernet как технологии для ЛВС перед АТМ (асинхронный режим передачи) сохранится еще по меньшей мере лет десять. Пол Каллахен, директор службы сетевых стратегий этой фирмы, заявил, что, поскольку пользователи не требуют, чтобы на ЛВС работали видеоприложения, АТМ займет какую-то менее важную нишу рынка. В докладе говорится, что при отсутствии необходимости строить видеоЛВС пользователи будут, избегая риска, покупать то, с чем они уже знакомы. |
Как сказала Керри, "люди, как правило, в своих оценках исходят из здравого смысла и логики, но в рисках нет ни того, ни другого".
Всплеск роста
С Лорен Гиббонс Пол можно связаться lie электронному адресу: lpaul@)pcweek.ziff.com.
Лорен Гиббонс Пол
* Оксюморон - греч. "глупая шутка," в риторике - сочетание противоположных по значению слов. - Прим. ред.
