От разработчика до руководителя

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

Позволяет ли гибкая методология разработки программного обеспечения избавиться от необходимости проектного менеджмента? Нет. Agile-методы — это отличный способ организации работы, потому что итеративные подходы автоматически заставляют вас разбивать задачи на небольшие блоки и выдавать результат постепенно, а не сразу. Но это ни в коем случае не отрицает того, что вы должны понимать принципы управления проектами. Вы можете столкнуться с проектами, по ряду причин не поддающимися завершению за один или два рывка. Вы должны будете представить руководству свою оценку сроков выполнения проекта и детально разъяснить, почему указываете именно такие сроки. Существуют проекты, объединенные под общими категориями инфраструктуры, платформы или системы, и они требуют разработки архитектуры или значительного объема предварительного планирования. Имея дело с ними, можно встретиться с трудностью исполнить заказ в срок: вы поймете, что они не очень хорошо вписываются в стандартные аgile-процессы.

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

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

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

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

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

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