Как начинать работу на новом месте?

· 4 мин

Несколько недель назад у меня расширилась зона ответственности. Было интересно применить недавно полученные знания по тому, как начинать новую работу и задокументировать процесс.

Для начала надо отметить, что продакт менеджеры не работают на «проектах». Я отвечаю за развитие бизнеса, в основе которого лежит технологический продукт, и работа на нём бессрочна — она продолжается до тех пор, пока продукт существует. Результаты достигаются через запуски и другие проекты, для которых вместе разработчиками я задаю направление.

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

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

В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.

Я расшерил черновик документа с разработчиками, менеджерами разработки и другими продактами и был готов к тому, что его разнесут на кусочки. Я получил много комментариев, понял, что двигаюсь в правильном направлении, и продолжил собирать информацию. В процессе стала образовываться «карта стейкхолдеров» — всех, кто зависит от нашего продукта и от кого зависим мы. Туда входят пользователи, опен-сорс проекты и с десяток других команд разработки в Гугле.

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

Если вы думаете, что продакты только придумывают и создают - это не так. В enterprise IT большую роль играет жизненный цикл продукта и как фичи убиваются. От фич зависят большие бизнесы крупных компаний и убивать фичи очень сложно в отличие от приложений, рассчитанных на индивидуальных пользователей. В моём случае фичи убивать необходимо потому, что когда у языков программирования заканчивается период поддержки, их использование становится небезопасным.

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

Эти идеи пришли из трёх источников:

  • Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
  • Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
  • Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.

Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:

  1. Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
  2. Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
  3. Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
  4. Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
  5. Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
  6. Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.
View this post on Instagram

A post shared by Илья Безделев | Чувак из Гугла (@ilya.bezdelev)