Как начинать работу на новом месте?
· 4 мин
Несколько недель назад у меня расширилась зона ответственности. Было интересно применить недавно полученные знания по тому, как начинать новую работу и задокументировать процесс.
Для начала надо отметить, что продакт менеджеры не работают на «проектах». Я отвечаю за развитие бизнеса, в основе которого лежит технологический продукт, и работа на нём бессрочна — она продолжается до тех пор, пока продукт существует. Результаты достигаются через запуски и другие проекты, для которых вместе разработчиками я задаю направление.
Так как я в синиор позиции, мне никто не говорит что делать. Мне просто говорят — ты теперь за это отвечаешь, иди разбирайся. До меня этой позиции не существовало, таким образом, мне не у кого перенимать дела и нужно выстроить вокруг себя и команды инженеров продуктовые процессы и структуру.
Первое, что я сделал — начал разговаривать с продакт менеджерами и руководителями разработки, которые хоть как-то причастны к этой части продукта. Я создал список вопросов к каждому из них с целью выудить как можно больше информации, ссылок на документы и контакты других людей. С каждым новым человеком с первой встречи я начинаю строить долгосрочные партнёрские отношения.
В какой-то момент начали складываться очертания того, куда я попал, и я начал документ под названием MVSR — Mission, Vision, Strategy, Roadmap. Миссия - это то, зачем мы существуем, высокая идея. Видение - цель на 3-5 лет. Стратегия - как мы достигаем видение и как это увязано со стратегией организации и Google Cloud. Roadmap - конкретные фичи, которые мы планируем сделать в ближайшее время.
Я расшерил черновик документа с разработчиками, менеджерами разработки и другими продактами и был готов к тому, что его разнесут на кусочки. Я получил много комментариев, понял, что двигаюсь в правильном направлении, и продолжил собирать информацию. В процессе стала образовываться «карта стейкхолдеров» — всех, кто зависит от нашего продукта и от кого зависим мы. Туда входят пользователи, опен-сорс проекты и с десяток других команд разработки в Гугле.
Получив неплохое высокоуровневое понимание моей новой области, я решил углубиться в детали, чтобы пощупать продукт поближе. Я взял на себя сложный проект, который начал один из коллег, и за три дня разобрался в релевантных для проекта деталях Node.js. Пообщался с несколькими разработчиками и создал стратегию того, как можно выстроить более эффективную систему для удаления фич из продукта.
Если вы думаете, что продакты только придумывают и создают - это не так. В enterprise IT большую роль играет жизненный цикл продукта и как фичи убиваются. От фич зависят большие бизнесы крупных компаний и убивать фичи очень сложно в отличие от приложений, рассчитанных на индивидуальных пользователей. В моём случае фичи убивать необходимо потому, что когда у языков программирования заканчивается период поддержки, их использование становится небезопасным.
Стратегия, которую я создал - это шести-страничный документ, который описывает цели, принципы, текущую ситуацию, то как её можно улучшить, необходимые для этого фичи и новый процесс. Следующий шаг - отдать документ на растерзание команде разработки, выработать общее понимание проблемы пользователей, понять технические ограничения, обсудить и начать искать пути решения этих проблем, полное внедрение которых займёт год, возможно, два.
Эти идеи пришли из трёх источников:
- Физик Ричард Фейнман практиковал письмо всего, что он знает о предмете, чтобы увидеть границы своих знаний.
- Мой бывший босс в Амазоне использовал документ MVSR, когда он пришёл в нашу организацию и наводил порядок.
- Книга «Первые 90 дней» хорошо описывает баланс между техническими знаниями и организационным ориентированием на новом месте.
Итак, когда начинаешь работу в новой для себя сфере/команде/проекте:
- Максимально быстро получи общее представление о продукте, процессах, людях и технологиях через общение с людьми, чтение внутренних документов, просмотр видео и т.п.
- Начни писать то, что узнал. Это поможет как тебе, так и другим, потому что теперь «племенные» знания (tribal knowledge) становятся задокументированными знаниями и их легко передавать дальше.
- Возьми какой-нибудь проект, чтобы окунуться в детали. Погрузись туда с головой. Это поможет понять технические проблемы и ограничения, а также построить отношения с коллегами и пользователями.
- Пока у тебя свежий взгляд, подвергай текущие процессы сомнению, но не переусердствуй, так как ты ещё многого не знаешь. Просто задавай вопрос «почему» и изучай ответы. У тебя есть шанс изменить мышление команды к лучшему.
- Документируй всё. Повторяюсь, но это важно. Человек, который способен излагать свои мысли и синтезировать информацию письменно, сразу же приносит пользу любой команде. Люди это оценят.
- Поставь на паузу другие интеллектуальные задачи. Я на время перестал читать книги не по теме ибо мозг опух так, что я даже не мог нормально разговаривать после рабочего дня. Был перегруз от интенсива. Отдых важен.