Я встречался со многими веб-разработчиками на протяжении многих лет, и общая тема заключается в том, что они, как правило, специализируются на конкретном аспекте веб-разработки. Они либо дизайнеры, JavaScript-кодеры, серверные эксперты или, может быть, чуть-чуть из них. Редко я встречаю кого-то, кто невероятно хорошо разбирается в полном стеке, обладает удивительной дизайнерской проницательностью и способностью принять видение и воплотить его в жизнь, спереди назад.
Джонатан Снук — одна из тех редких пород, а также влиятельный человек в мире веб-разработки. Его навыки сделали его востребованным оратором и писателем и предоставили большие возможности в таких компаниях, как Yahoo! и Shopify. Сейчас он решается заняться управлением продукцией, и мы догоняем его, чтобы посмотреть, как идут дела, и его совет для тех, кто хочет взяться за эту роль.
Q Начнем с обычного. Не могли бы вы кратко рассказать о себе?
Конечно, вещь. Меня зовут Джонатан Снук, я веб-разработчик из Оттавы, Канада. Я занимался веб-разработкой еще до того, как Netscape достиг 1.0. Я имел удовольствие работать над сотнями проектов как профессионально, так и лично. Я также выступаю на конференциях, устраиваю семинары и являюсь автором или соавтором трех книг на сегодняшний день, самая последняя из которых — « Масштабируемая и модульная архитектура для CSS» (или SMACSS для краткости). В настоящее время я менеджер по продукту в Shopify, расположенном здесь, в Оттаве.
В Недавно вы перешли на роль управления продуктом. Что вызвало переключение?
Возможность и недоразумение! До начала этого года у Shopify никогда не было команды разработчиков. Я работал в команде дизайнеров, сосредоточенных на нашем основном продукте. Как компания, у нас традиционно был очень эгалитарный подход, который позволял любому работать над идеей. Shopify быстро росла, и ей действительно нужно было владеть продуктом, чтобы сосредоточиться на команде и продукте. Команда разработчиков собиралась. Если вы представляете, что это как Лига Справедливости, это просто так.
Роль, как мне ее описали, очень напоминала работу, которую я выполнял как дизайнер. Поговорите с клиентами, службой поддержки и другими заинтересованными сторонами, чтобы оценить, какие проблемы мы должны решать, и протестировать нашу работу, чтобы убедиться, что мы хорошо решаем наши проблемы. Это звучало фантастически, и я ухватился за эту возможность. Я неправильно понял, сколько на самом деле было работы, чтобы определить четкое направление продукта и иметь возможность эффективно обмениваться информацией как внутри компании, так и за ее пределами. В результате я не выполнил практически столько практических разработок, сколько ожидал, что смогу продолжать заниматься этим.
Q Как новая роль повлияла на ваш набор навыков? Вы все еще кодируете или теряете преимущество?
Переход к управлению продуктом означает обучение новым навыкам. Я много читал. Я исследовал, что делает хорошего менеджера по продукту. Я исследовал, что должно произойти для команды (или нескольких команд, действительно), чтобы создать хороший продукт. Для меня это была прекрасная возможность вырасти, и это было очень увлекательно.
Я все еще пишу, когда могу, но не так много, как раньше. Тем не менее, я все еще читаю блоги и посты в твиттере. Я стараюсь оставаться на вершине отрасли, и я все еще могу выступать и посещать отличные конференции, где я могу расширить свои знания. Я все еще участвую в опросах и технических обсуждениях. Я все еще чувствую, что я «получил это», по крайней мере, на техническом концептуальном уровне. С другой стороны, потратить день на написание кода может оказаться немного сложнее. Только не говори никому об этом!
В: Изменилась ли новая роль в том, как вы работаете со своей командой разработчиков, теперь, когда вы находитесь на другой стороне уравнения? Если да, то каковы хорошие и плохие стороны взаимодействия?
Мне повезло, что у меня была прекрасная карьера: дизайн, фронт-энд и бэк-энд разработки. Одним из преимуществ наличия такой широты навыков является способность глубоко понимать требования на всех уровнях. Я был бы потерян без способности понять дизайн и технические препятствия. Я не смог бы привлечь моих коллег на одном уровне. Они очень умные люди, которые могут кодировать вокруг меня, но, по крайней мере, я могу понять, что они делают, и почему они делают это так, как есть. Я думаю, что это очень полезно.
С другой стороны, это не то, что вы не видите, выходящее из любой команды. У людей разные представления о том, на чем мы должны сосредоточиться. Иногда я недостаточно хорошо представляю свое видение и направление, и это может привести к путанице и конфликту. Это те навыки, над которыми я работаю, чтобы улучшить их.
Q Как вы уравновешиваете желание разработчиков реализовать новые блестящие функции или технологии по сравнению с управлением реалистичными целями продукта?
В Shopify мы имеем дело с 7-летней базой кода. Команда часто хочет работать над рефакторингом вещей вместо новых блестящих функций. Я тот, кто хочет реализовать новые блестящие функции.
Конечно, во всех отношениях баланс является ключевым. Одна из вещей, которая мне понравилась, когда я работал в команде дизайнеров в Yahoo! был регулярный цикл обслуживания, который был встроен в их процесс. Очистите файлы, исправьте названия, избавьтесь от лишнего. По мере роста Shopify мы знаем, что должны продолжать сохранять этот баланс. Я думаю, что мы на правильном пути, даже если иногда мы не согласны с тем, когда нам следует заниматься разработкой функций или заниматься рефакторингом и обслуживанием.
Q Я знаю много разработчиков, которые в конечном итоге хотели бы перейти к управлению продуктами. Не могли бы вы рассказать нам о своем переходе и о том, что, по вашему мнению, поможет другим успешно перейти?
Хотя у нас были менеджеры по продуктам в Yahoo !, я редко общался с ними. Роль была в значительной степени чужой для меня, пока я не решил сначала прыгнуть в голову.
Если вы хотите быть хорошим менеджером по продукту для технологической компании, то я думаю, что хорошо иметь разносторонний опыт. Опять же, я думаю, что для почти любой роли вы могли бы взять. (И я считаю, что работа в веб-агентстве — отличный способ получить этот опыт. Хотя, вероятно, я предвзят, поскольку именно на этом пути я и остановился.) Хороший менеджер по продукту должен уметь хорошо общаться. Хороший менеджер по продукту должен иметь сочувствие. Например, в Shopify я управляю магазином. На самом деле я продаю свою книгу SMACSS на Shopify. Это помогает мне понять некоторые проблемы, с которыми наши клиенты сталкиваются каждый день. Я не думаю, что смогу управлять продуктом, в который не верил.
Для тех, кто хочет перейти от разработки к управлению продуктом, страсть к продукту станет ключевым фактором. Для меня это была возможность получить более полную картину всей экосистемы и больше влиять на направление всей системы. Я хотел этого, потому что хочу, чтобы Shopify был потрясающим. Я хочу, чтобы люди наслаждались этим каждый день.
Если вы хотите стать менеджером по продукту, не позволяйте слову «менеджер» напугать вас. Не беспокойтесь о потере своих навыков. Отрасль меняется быстро, но не так быстро. Такое ощущение, что это так. Если я решу, что хочу уйти из управления продуктом и вернуться к программированию на полный рабочий день, я уверен, что это будет разумный легкий переход обратно. (Опять же, прошло всего 6 месяцев. Посмотрим, думаю ли я то же самое через 2 года.)
Q SMACSS — это ваш ребенок. Что пытается решить то, что CSS-фреймворки еще не делают?
Фреймворки не кодируют весь ваш сайт. Возьмите любой фреймворк, и вам все равно придется добавить свой код поверх него. Это была проблема, которую я пытался решить. Какие проблемы пытаются решить фреймворки и как код, который вы пишете, вписывается во все остальное.
Вот почему SMACSS написано так, как оно есть: это не фреймворк. Он предназначен для описания процесса. Описывает способ создания сайта. Это документация по процессу обучения, который я прошел при создании больших проектов с большими командами.
В С точки зрения реального развития, как SMACSS адаптируется к динамическим потребностям разработки UI & UX?
SMACSS вышел из реального развития. Это не размышление, а не подход одинокого волка. Это объединение многих идей, которые уже витали вокруг.
Как индустрия, мы видим, что все больше дизайнеров и разработчиков рассматривают дизайн сайта как модульную систему, а не как серию страниц в стиле брошюр, которые не меняются. Модульный подход означает, что детали можно перемещать. Чем автономнее детали, тем легче их перемещать и добавлять новые или удалять другие.
SMACSS, будучи масштабируемой и модульной архитектурой для CSS, ориентирована на динамические потребности разработки пользовательского интерфейса и UX.
В Поскольку SMACSS содержит рекомендации по структурированию вашего CSS, насколько он жизнеспособен для проектов, которые уже выполняются? На каком этапе процесса разработки SMACSS является жизнеспособным?
Конечно, всегда легче писать все с нуля, но это не всегда происходит. У меня была такая привилегия в Yahoo !. Но, зайдя в Shopify, я внес свой вклад в существующий проект, который уже находился в стадии разработки. «Если это не сломано, не чините это» — знакомая мантра, но рефакторинг должен быть тем, для чего проекты находят время. Рефакторинг удаляет техническую задолженность, которая позволяет быстрее разрабатывать новые функции. Как говорится, «нет времени, как настоящее», чтобы начать реализацию модульного подхода к проекту. Просто делай это по одной штуке за раз. Это подход, который мы использовали в Shopify, и который мы продолжаем применять.
Q Другие CSS-фреймворки имеют тенденцию указывать свой собственный способ действий. Работает ли SMACSS в сценарии, в котором существующие структуры диктуют процесс?
Это зависит от процесса! Когда я писал SMACSS, я хотел представить ряд концепций, которые можно было бы принять частично или полностью, так как я в том, что касается разработки. Я вряд ли возьму чужой проект оптом. Я собираюсь взять кусочки, которые работают для меня, и оставить все остальное.
В: Последний вопрос, что, черт возьми, случилось с клиентом Snitter Twitter ?!?
Вы видели клиентскую экосистему Twitter ?! Да, я думаю, что я в порядке, позволив этому умереть. Я доволен небольшим успехом, который у него был (который на самом деле был не такой уж и большой), и мне понравился процесс создания приложения. Увы, мое время было лучше сосредоточено на других проектах.
Спасибо Джонатан
Джонатан, спасибо, что нашли время поговорить с нами и за отличный совет по переходу на управление продуктом. Если вы хотите узнать больше о Джонатане, обязательно посетите его блог и подпишитесь на него в Twitter . Вы также можете узнать больше о SMACSS на сайте проекта .