Всем привет!

Меня зовут Лариса. Я работаю в Google и веду блог на larrr.com, где я изначально и опубликовала эту статью.

Сегодня я предлагаю вашему вниманию статью, которая изначально была написана исключительно для внутреннего пользования Google. Мне очень понравилась, так что я связалась с автором, с ее разрешения я ее немного переделала, и получила разрешение от Google Press на публикацию. Перевод мой.

На всякий случай – это не официальный Google документ, и Google не несет ответственности за его содержание. Он субъективный, и написан сотрудником для сотрудников.

Советы для инженеров
15 апреля 2013
Отредактировано 21 мая 2014
Переведено 31 августа 2015
Gretta Bartels, Software Engineering Manager at Google

Уважаемый читатель,

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

Один из моих более опытных коллег научил меня тому, что для менеджера очень важно быть предельно предсказуемым. У менеджера должен быть какой-то набор простых правил, о которых знают все его подчиненные, и которым они могут следовать даже когда менеджера рядом нет. Поэтому моя цель – чтобы программисты в моей команде могли задать сами себе вопрос “Что бы на это сказала мой менеджер?”, и сами себе на него правильно ответить. Тогда команда сможет работать практически самостоятельно, без моего руководства. А я буду сидеть дома и кушать пирожные :).

Вот список моих основных правил:

1. Занимайтесь той работой, которая действительно важна

1a) Всегда задавайте себе вопрос “Почему мы это делаем?”

Что бы вы не делали, все всегда должны четко знать две вещи – 1) почему вы это делаете? 2) как вы поймете, что достигли нужного результата? Даже если вам кажется, что вы можете ответить себе за вопрос “почему?”, не останавливайтесь на первом подходящем ответе, смотрите глубже. Задавайте себе этот вопрос снова и снова, пока ответ не будет простым, очевидным и одновременно с этим довольно масштабным.

Это чем-то похоже на метод “5 почему”, когда техних несколько раз задает себе вопрос “почему?”, углубляясь в ответ чтобы найти причину неполадки. Но в нашем случае я предлагаю использовать этот метод для любой работы, а не только для нахождения причин проблем.

А вот вам и пример из жизни. Одна из моих команд сейчас работает над улучшением качества данных для Google Maps (а именно – находим и устраняем внутренние противоречия в данных). В это случае “почему”-цепочка может выглядеть примерно так:

Мы устраняем противоречия в данных
-> для того, чтобы мы могли проще и быстрее интегрировать существующие и новые данные
-> для того, чтобы мы могли обновлять данные быстрее
-> для того, чтобы Google Maps были максимально точными
-> для того, чтобы качество Google Maps соотвествовало очень высокому стандарту и требованиям пользователей
-> для того, чтобы люди активно пользовались и доверяли Google Maps (и продуктам Google в целом)

Выглядит довольно просто, не так ли? Но исходя из моего опыта, далеко не все инженеры задают себе эти вопросы и видят дальше конктретной и обособленной задачи над которой они работают.

На самом деле понимать “почему?” для своей работы очень важно. Кричитески важно, я бы сказала.

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

Кстати, ответов на ваши “почему?” может быть несколько. Это хороший знак – вероятно, ваш проект действительно важен.

И еще важное, особенно для менеджеров: используя “почему”-цепочку, вы не только сможете лучше понять зачем вы что-то делаете и как делать это лучше, но и увидеть другие стратегические области развития для ваших проектов. Просто пройдите с другого конца цепочки и задайте себе вопрос “как?”.
1b) Самое важное – это результат

Как менеджер, я оцениваю своих сотрудников по следующим параметрам: Знания и Опыт, Сложность, Лидерство и Результаты. Хоть и все они важны для профессионального развития и карьерного роста, один из параметров значительно важнее прочих. Это – Результат.

Большинство компаний – это не обучающе-развивающие площадки для программистов. Это – бизнесы, которые работают, и именно благодаря этому в них можем работать мы. Кстати, лично мне это сочетание – бизнес и технология – очень нравится. Мне нравится работать над вещами, которые изменяют мир. И многим инженерам с которыми я общалась на эту тему – тоже.

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

Кстати, насчет сложности. Бывает, что для достижения важного результата не надо делать ничего сложного. Это нормально. Всегда ищите и берите простые и одновременно важные проекты, когда вам предоставится такая возможность.

1c) Планы бесполезны, но важны

Я верю в OKR (сокр. Objectives and Key Results — цели и ключевые результаты — метод, используемый в современном менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль за реализацией поставленных задач. Wiki.). Я прошу всех инженеров в своих командах писать и оценивать их ежеквартально.

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

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

Еще более интересная проблема – это переоценка своих возможностей. Как менеджеру, мне регулярно приходится помогать инженерам быть более аккуратными в своих оценках – по моему опыту очень многие сильно переоценивают количество работы, которую они могут сделать за данный промежуток времени. Бывали случаи, когда люди ставили много целей, делали каждую на 30-50%, но не довели ни одной цели до запланированного результата. Намного лучше бы было сделать две или три цели на 100%.

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

2. Не теряйте время даром

2a) Ускоряйтесь (aka Как насчет парочки тестов?)

Во время моей учебы в университете, в качестве зачетной работы мне надо было написать игру Boggle с красивым интерфейсом и поддержкой для удаленной игры нескольких пользователей. Естественно, я даже пальцем не шевельнула до последнего дня перед сдачей. В 3 часа ночи я обнаружила что моя наскоро написанная программа содержит баг, который вылезал под самый конец игры.

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

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

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

Похожий принцип применим и к работе с людьми и продуктами. Когда вы находитесь в ситуации неопределенности, подумайте о том, как провести быстрый и простой эксперимент, который бы дал вам хоть какие-нибудь предварительные данные.

2b) Избавьтесь от проблемы раз и навсегда (aka Автоматизируйте)

Люди не должны тратить время на вещи, которые намного лучше получаются у компьютеров. Это даже не обсуждается.

Мы все занимаемся программированием, чтобы сделать жизнь проще и автоматизировать то, что можно автоматизировать. Казалось бы, инженеры будут пытаться максимально применить этот принцип к себе в том числе. Но оказывается, что вовсе нет!

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

Автоматизируя задачу:

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

2c) Развивайтесь

Не занимайтесь одним и тем же слишком долго. После того, как вы освоили какую-то область, либо автоматизируйте ее (см. выше), либо обучите другого инженера для этой работы и двигайтесь дальше. Растите профессионально, не позволяйте себя застояться.

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

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

Я постоянно советую инженерам в своих командах переключатся на новые задачи и развиваться профессионально.

3. Не работайте в вакууме (aka Общайтесь с другими)

Старайтесь описывать дизайн систем, над которыми вы будете работать, заранее (aka пишите design docs). Посылайте эти документы вашим коллегам и спрашивайте, что они думают. Делая это, вы:

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

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

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

Если статья вам понравилась, то заходите ко мне в блог. Возможно, там вы найдете для себя еще больше интересного. У меня уже почти 300 статей на тему Google, карьеры, саморазвития и продуктивности (некоторые из них когда-то были на Хабре). Я люблю писать, и, как мне кажется, у меня неплохо получается. Как минимум иногда.
Буду рада, если вам понравится!

Автор:

Источник