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