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

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

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

Энергичный руководитель

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

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

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

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

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

Я ощутил подъем и ответил: «Да!» Я подумал, что смогу привести этот проект в надлежащий вид и покажу всем, что может сделать настоящий руководитель. Разработку системы надо было выполнить за три месяца и закончить ее к открытию специализированной отраслевой выставки. Я взялся за работу.

Что я делал правильно

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

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

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

Система стала работать лучше чем прежде, но все-таки не вызвала большого энтузиазма. Значения времени отклика системы улучшились более чем наполовину, но все равно при этом для выдачи некоторых отчетов требовалось от 5 до 10 минут. И некоторые результаты все еще вызывали сомнение у клиентов.

Почему не все шло как надо

Несколькими неделями позже проект был закрыт. Прошло еще несколько месяцев и я задался вопросом, что же я сделал неправильно. И понял, что совершил такую же ошибку, как и моя Биби. Несмотря на всю свою энергию, она не могла принести мне то, чего не было. Я взялся реабилитировать проект, не подлежащий реабилитации. Меня не упрекали в плохом руководстве. Проект был обречен на неудачу, потому что двигавшая его стратегия была нежизнеспособна, отказ от унаследованной системы отчетности в угоду некому передовому ПО был ошибкой. Увлекшись своей руководящей ролью, я не учел того, что известно всем: нестандартное передовое ПО требует большого объема тестирования и тонкой настройки. Поэтому для ответственного критического проекта использовать такое обеспечение рискованно.

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

Майк Хьюгос — бывший ИТ-директор компании Network Services и автор двух книг «Building the Real-Time Enterprise», «Essentials of Supply Chain Management», www.michaelhugos.com

MIKE HUGOS. Why Leaders Fail. CIO MAGAZINE. JULY 1, 2006