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