От разработчика до руководителя. Менеджмент для IT-специалистов - Камиль Фурнье

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

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

Не жалейте времени на разъяснения

Один из последних этапов на пути к докторской степени — защита диссертации. Именно здесь вы, кандидат в доктора, представляете результаты своей многолетней исследовательской работы. Вы делаете это перед научным советом, состоящим из экспертов в вашей области. Они оценят ваши результаты и решат, достаточны ли они для присуждения вам научной степени доктора наук (PhD). Много лет назад мне повезло: я получил докторскую степень по математике от одной из самых престижных программ по прикладной математике в США. Одним из членов научного совета, оценивавшим мою работу, был известный математик — специалист в области численного анализа. То, что он сказал мне после моей (успешной) защиты, прошло красной нитью сквозь всю мою рабочую карьеру (не в области математики!). Он сказал тогда: «Ваша диссертация была одной из самых прозрачных и ясных работ, прочитанных мною за многие годы. Благодарю вас!» Разумеется, я был польщен его словами, но одновременно с этим и удивлен. Я предполагал, что этот ученый, математик мирового уровня, будет все знать о моем предмете и просто наблюдать, чем обернется защита моей диссертации. На самом деле, как объяснил он, он действительно смог это сделать, но только благодаря тому, что я потрудился объяснить базовые понятия и мотивацию возникновения моих собственных идей. Я никогда не забывал этот урок. Проработав после этого в области создания программного обеспечения в больших организациях, я не раз смог оценить его слова.

Мы полагаем, что руководство легко схватывает то, что мы делаем как инженеры-программисты. «Эй, парень, ты просто читай код!» Среди программ мы живем каждый день, и ведь они должны быть понятны любому, кто работает в области IT, не так ли? Нет, не так. Технические менеджеры приглашают на работу лучших специалистов (во всяком случае, надеются, что они лучшие), и те решают сложные проблемы. Но менеджеры схватывают далеко не всё. Я всегда удивлялась, насколько благодарны были мне старшие технические руководители, когда я мог объяснить им некоторые основополагающие идеи (например, что собой представляет штуковина под названием «хранилища NoSQL» и что с этим делать) не в угрожающем или снисходительном тоне.

Недавно один старший бизнес-руководитель в нашей организации попросил меня объяснить ему в частном порядке, почему для нас важно перенести «Толстого клиента»7 в архитектуре клиент-сервер на платформы провайдера. На этого руководителя сильно давили, чтобы он разрешил финансирование перехода, но он не понимал, зачем это нужно. Судя по всему, ему было неудобно спрашивать об этом публично. Я провел два очень плодотворных часа, объясняя ему (без PowerPoint!) суть проблемы. Теперь я никогда не боюсь разъяснять базовые принципы и мотивации тех или иных решений и старшим, и младшим сотрудникам организации. Это дает им знания, не принижая их, они учатся доверять моим суждениям и советам, и так мы обеспечиваем в организации необходимые изменения. Не жалеть времени на объяснения — это очень важно.

Майкл Маршалл

Управление проектом

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

Разбивайте работы по проекту. Возьмите крупноформатную (электронную) таблицу, ленточную диаграмму (график) Гантта и начните разбивать вашу главную цель (например, рерайтинг билинговой системы). Начните с крупных элементов, затем разбивайте их на более мелкие и, наконец, на совсем мелкие компоненты. Вам не нужно делать все самому. Если есть части системы, известные вам не очень хорошо, попросите о помощи того, кто разбирается лучше. Разделите проект на достаточно крупные составляющие и сразу же приступайте к заказам на работы. Что можно начать немедленно? Передать проблемы тем, кто в состоянии выполнить каждый свой отдельный кусочек.

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

Управляя проектом, корректируйте план по мере продвижения работ. Ценность хорошего планирования проекта в том, что оно помогает вам представлять, насколько он продвинулся вперед и сколько еще осталось до завершения. Когда происходят отклонения в исполнении проекта (а они всегда имеют место), доводите до всех членов команды сведения о реальном состоянии. В этом случае вместо гадания, сколько еще осталось до завершения работ, вы можете точно указать уже преодоленные вехи и описать оставшуюся часть.

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