core team
Смотреть что такое «core team» в других словарях:
Core-Team — Als Kernteam (englisch core team) bezeichnet man die Personengruppe in einem Unternehmen oder Projekt, die die Hauptarbeit am Fortschritt trägt und koordiniert. Für Softwareprojekte gilt: Im Gegensatz zu der meistens viel größeren Zahl an… … Deutsch Wikipedia
CORE — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) den Reaktorkern eines Kernkraftwerks den früheren Namen der Band Core22 einen Film: The Core – Der innere Kern die deutsche Kitefirma … Deutsch Wikipedia
Core — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) eine innere Proteinstruktur bei Viren, siehe Kapsid Core = Fondsmanagementstil im Bond Bereich den Reaktorkern eines Kernkraftwerks… … Deutsch Wikipedia
team roles — Modeling is a team effort. Each USPS BPR team member must be assigned one or more roles to ensure that the team meets its objectives. Some of the roles require a full time effort; they are called the core team roles. Other roles require part time … Glossary of postal terms
core — [[t]kɔ͟ː(r)[/t]] ♦♦♦ cores, coring, cored 1) N COUNT: oft n N The core of a fruit is the central part of it. It contains seeds or pips. Someone threw an apple core. Peel the pears and remove the cores. 2) VERB If you core a fruit, you remove… … English dictionary
Core self-evaluations — (CSE) represent a stable personality trait which encompasses an individual’s subconscious, fundamental evaluations about themselves, their own abilities and their own control. People who have high core self evaluations will think positively of… … Wikipedia
Core Design — Former type Defunct Industry Computer and video game industry Fate Acquired by Eidos Successor … Wikipedia
Core Security Technologies — Core Security Type Private Industry Computer Security Vulnerability Management Security Consulting Services Founded 1996 Headquarters … Wikipedia
Core — may refer to: Contents 1 Science and Academics 2 Computers and Technology 3 Media … Wikipedia
Core Design — Limited Rechtsform Limited Gründung 1988 (aus Gremlin Derby) Auflösung … Deutsch Wikipedia
core team
костяк команды
Так обычно называют немногочисленную основную группу, которая возглавляет работу над определенным проектом или же управляет оперативной деятельностью.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
core team
Usually refers to a small central group of people who either manage a specific project or are key managers for an operation.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
Тематики
Смотреть что такое «core team» в других словарях:
Core-Team — Als Kernteam (englisch core team) bezeichnet man die Personengruppe in einem Unternehmen oder Projekt, die die Hauptarbeit am Fortschritt trägt und koordiniert. Für Softwareprojekte gilt: Im Gegensatz zu der meistens viel größeren Zahl an… … Deutsch Wikipedia
CORE — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) den Reaktorkern eines Kernkraftwerks den früheren Namen der Band Core22 einen Film: The Core – Der innere Kern die deutsche Kitefirma … Deutsch Wikipedia
Core — ist das englische Wort für Kern und bezeichnet: den hydrophoben Kernbereich eines Proteins, siehe Core (Protein) eine innere Proteinstruktur bei Viren, siehe Kapsid Core = Fondsmanagementstil im Bond Bereich den Reaktorkern eines Kernkraftwerks… … Deutsch Wikipedia
team roles — Modeling is a team effort. Each USPS BPR team member must be assigned one or more roles to ensure that the team meets its objectives. Some of the roles require a full time effort; they are called the core team roles. Other roles require part time … Glossary of postal terms
core — [[t]kɔ͟ː(r)[/t]] ♦♦♦ cores, coring, cored 1) N COUNT: oft n N The core of a fruit is the central part of it. It contains seeds or pips. Someone threw an apple core. Peel the pears and remove the cores. 2) VERB If you core a fruit, you remove… … English dictionary
Core self-evaluations — (CSE) represent a stable personality trait which encompasses an individual’s subconscious, fundamental evaluations about themselves, their own abilities and their own control. People who have high core self evaluations will think positively of… … Wikipedia
Core Design — Former type Defunct Industry Computer and video game industry Fate Acquired by Eidos Successor … Wikipedia
Core Security Technologies — Core Security Type Private Industry Computer Security Vulnerability Management Security Consulting Services Founded 1996 Headquarters … Wikipedia
Core — may refer to: Contents 1 Science and Academics 2 Computers and Technology 3 Media … Wikipedia
Core Design — Limited Rechtsform Limited Gründung 1988 (aus Gremlin Derby) Auflösung … Deutsch Wikipedia
Зачем разделять продуктовую команду на Core и Growth: оргструктура для Rusprofile
Команда TYPICAL вместе с клиентом рассказывает, почему важно правильно выстроить продуктовую команду, зачем разбираться в культуре компании, в чем отличия core и growth-команды и почему штатный дизайнер — эффективное решение.
На фото основатели Rusprofile, Илья Мошин и Дмитрий Стрелков
Мы создали сервис, где собрали всю доступную информацию о действующих юридических лицах в России: их текущий статус, бухгалтерскую отчетность, анализ финансового состояния, связи с другими юрлицами.
Изначально наша экспертиза — наращивание посещаемости сайта и оптимизация для поисковых систем. На Rusprofile заходят 700 тысяч человек в день. Это все бизнес-аудитория. Мы монетизировали проект по рекламной модели: рекламодатели приходят к Яндексу и Google, а мы уже работаем с ними. Проект рос и развивался достаточно хорошо: с октября 2016 года по октябрь 2019 месячная посещаемость выросла в 3 раза — с 6 до 18 миллионов пользователей. Но модель нас ограничивала.
Дело в том, что рекламный рынок сейчас консолидируется вокруг крупных игроков. Также меняется формат размещения: все чаще рекламу закупают по программатик технологиям, но денег здесь значительно меньше. При росте аудитории в два раза наши доходы остались прежними. Окончательным приговором стала пандемия, она почти уничтожила имеющиеся рекламные бюджеты компаний. Наши доходы от рекламы упали на 30-40% и все еще не восстановились до старых значений.
Встал острый вопрос — что делать и как развивать проект дальше. Мы выдвинули несколько гипотез. И летом запустили одну из них — платную подписку на расширенные сведения об организациях. Как работает наш продукт: мы берем информацию по юрлицам от минимум десяти ведомств, упорядочиваем ее, делаем легкой для восприятия и собираем на одной странице. То есть клиент платит, чтобы получить данные в одном месте, а не самостоятельно искать их в разных источниках. Это экономит время.
Сначала мы запустили подписку в виде фейк-фичи. На этапе запуска протестировали две разных модели, получили интересные инсайты, выбрали лучшую. Также тестировали разные цены во время запуска.
Проверка гипотезы превзошла наши ожидания по росту выручки, причем кратно. И мы решили развивать ее. Если все пойдет успешно и дальше, то совсем откажемся от рекламы на сайте.
Мы поняли: подписка приносит деньги даже на сделанном в базовом виде сервисе, но можно его улучшить. У нас есть собственная экспертиза, и мы знаем, какую еще пользу могут принести наши данные, как развиваться на фоне крупных конкурентов, которые реализовали много интересных идей. Для этого, конечно, нужна сильная продуктовая команда, которая бы справилась с таким объемом работы.
Фото из офиса Rusprofile
Наша команда на тот момент была небольшая, но сильная: тимлид, четыре-пять разработчиков и один-два тестировщика. На аутсорсе работала дизайн-студия. Роли продакт-менеджеров выполняли мы с Димой Стрелковым, другим основателем сервиса. Но необходимого опыта у нас не было, приходилось самим набивать шишки.
Я проходил курс «Product Heroes», он дал много открытий. Например, я узнал о современных инструментах принятия продуктовых решений. Разобрался на практических примерах, как и какие данные эффективно использовать при разработке продукта. Обучение показало, что мы делали немало лишнего. Наверное, во многом оно и подтолкнуло к тому, чтобы изменить модель монетизации.
Мы находились в заблуждении, думая, что можно найти человека, который придет и расскажет, как все делается. Сейчас понимаем, что так не бывает. Еще мы думали растить команду самостоятельно, но это долгий и сложный путь.
Так удачно случилось, что мы познакомились с Валерией. Помню, что то ли в чате No Flame No Game, то ли в [UNCRN] Product Hunter кто-то рекомендовал TYPICAL. Я посмотрел, почитал статьи Валерии и оставил заявку на сайте.
Мы пришли к TYPICAL с таким запросом: хотим продуктовую команду, но не знаем, кто должен в нее входить. Было непонятно, какие нужны продакт-менеджеры и сколько? как поделить продукт? нужен ли нам свой дизайнер? Наша внешняя студия говорила, что нанимать дизайнера в штат — неэффективно: он будет выгорать, а в студии много специалистов и разноплановая экспертиза. Плюс мы думали, что при неравномерном потоке задач дизайнер будет сидеть без работы.
Фото из офиса Rusprofile
Кого я опрашивала. Когда мы строим оргструктуру продуктовой команды, то общаемся с людьми, которые дальше будут больше всего с ней работать. Это руководитель проектного офиса, СТО/тимлид. Если СМО или СОО будут работать с командой, то с ними тоже обязательно нужно поговорить. Всегда акцент должен быть на интервью с СЕО и с фаундерами: именно они носители стратегии.
Для Rusprofile я провела пять интервью: два — с основателем Ильей Мошиным, одно — с его партнером Димой, далее — с тимлидом разработки и проджектом.
Какие задавала вопросы. Их у меня больше 50, и они построены по такой логике: про бизнес, про команду в целом, про продуктовую команду, про культуру в компании. В зависимости от должности собеседника я акцентирую разные части. Например, мне достаточно рассказа о команде от СЕО и от фаундеров, но я должна убедиться, что остальные видят команду так же. То же самое с бизнесом: я могу сразу понять модель, стратегию, планы, но мне важно проверить еще и то, что все одинаково смотрят на вещи.
Зачем я изучала культуру компании. Это понятие включает в себя следующее: каков процесс найма в компании, как мотивируют сотрудников и ставят цели, как организована коммуникация, как работает топ-менеджмент. Оценивать культуру очень важно, потому что она определяет профиль кандидата — для конкретной культуры приоритетнее определенные навыки. Например, для бюрократичной — важнее умение работать со стейкхолдерами, для бережливой — с экономикой продукта.
Помимо скиллов культура помогает определить личностные характеристики, которые усилят портфолио кандидата для компании. Rusprofile нацелены на лидерское мышление, они энергичные и амбициозные — у них нет проблем, у них есть задачи. Это мощный аспект, который мы ищем в кандидатах на нашем «культурном» интервью. В целом понимание амбиций компании помогает привлечь и замотивировать соискателя. И ему не придется ждать собеседования, чтобы узнать про культуру, он может все спросить у нас на первых этапах знакомства и сэкономить время нашего клиента.
С Ильей мы детально обсуждали, на каком этапе развития сейчас находится продукт, куда ребята собираются двигать его дальше. Мы говорили и про конкретные задачи, про то, что сейчас есть в бэклоге, Илья приводил много примеров. Так, компания собиралась провести исследования по 12+ разделам информации на сайте, выявить потребности разных сегментов и перепроектировать разделы с нуля.
Когда я структурировала проблемы и цели клиента, то выделила два направления работы.
Изначально решили нанять по одному core и growth-продакту. Во-первых, сразу онбордить больше двух человек — тяжелая работа. Во-вторых, первые продакты могли бы разобраться в продукте глубже, чем я, и уже из опыта сформировать требования к тем, кто им нужен в команду.
Также я ответила на вопрос, нужен ли Rusprofile свой дизайнер — да, нужен. Ребят из новой продуктовой команды могло бы демотивировать отсутствие дизайнера, который понимает продукт изнутри. Ведь эта связка необходима, чтобы разрабатывать полноценную дизайн-систему продукта. Кроме того, штатный дизайнер одновременно сэкономит ресурсы клиента. И будет работать качественнее, понимая, как устроен продукт.
Оказалось, что взять в штат дизайнера эффективнее, чем работать со студией. Если раньше задачи появлялись нерегулярно и были необъемные, то после смены бизнес-модели их стало больше. И уже было непросто давать их людям, которые не погружены полностью в процесс: внешние подрядчики забывали, что делали для нас раньше. Много времени и сил уходило на то, чтобы контролировать работу «рук», которые выполняли, что мы просили. Намного легче взаимодействовать с человеком, который находится в контексте и может работать самостоятельно.
Зачем нужна выделенная Frontend Core команда и как мы внедряли дизайн систему
Всем привет, меня зовут Ростислав, я занимаю должность Front Lead в компании ДомКлик. Хочу поделиться с вами опытом создания Web Core команды и сразу ответить на следующие вопросы:
После года существования команды Web Core, у всех сложилось понимание, что в больших компаниях это необходимо, а в стартапах — не обязательно.
Безусловно. Изначально было сложно измерить и спрогнозировать выгоду от её создания, все расчеты, P&L были на словах, в цифрах — только примерные предположения. Спустя год мы можем посчитать сэкономленное время, профиты, и все расчеты говорят о том, что это было не зря.
Если у вас одна цель — создать дизайн систему и выпустить библиотеку компонентов под ключ, то возможно. Если же вы хотите это всё динамически развивать и расширять зоны ответственности команды, то это точно надолго.
Основное направление — дизайн система, но по ходу её разработки у нас появилось еще много интересных задач.
Предыстория
Создание Web Core команды началось с потребности разработать дизайн систему и библиотеку компонентов с последующей поддержкой и развитием, а также внедрить стандарты для frontend — разработки.
У нас в компании немало продуктовых команд, в каждой по несколько продуктов, состоящих из одного или нескольких веб-клиентов, которые могут содержать в себе виджеты и компоненты. Все веб-клиенты собираются в огромную экосистему ДомКлик, и, естественно, возникает вопрос о единообразии дизайна и UX-поведения всех элементов на страницах, чтобы клиент, переходя из продукта в продукт, понимал, что он в одной системе. И еще стоит вопрос об избыточных трудозатратах при разработке новой или доработке старой функциональности.
За всю историю ДомКлик было много попыток собрать библиотеку компонентов для их переиспользования во всех командах. Сначала пытались это делать в лояльном режиме: выделяли из своих проектов компоненты, которые можно переиспользовать, в отдельный репо и публиковали в npm-репозиторий. Затем компания энтузиастов решила собрать базу лучших компонентов в один проект со storybook, с единообразным API, и, по возможности, её поддерживать и дополнять. Но все эти попытки были тщетны до создания выделенной команды Web Core, у которой есть свои цели, обязанности и компетенции.
Дизайн-система и UI-KIT
Какие цели мы хотели достичь при создании дизайн системы:
Наша дизайн система будет состоять из таких элементов:
Дизайн
В ДомКлик уже было несколько версий дизайн систем, и теперь перед нашим дизайнером стояла непростая задача собрать самую актуальную и полноценную дизайн-систему. Самой большой проблемой было собрать все потребности использования каждого элемента, учесть все возможные состояния и условия, в которых он применяется. Про дизайн и проблемы, решавшиеся на этапе проектирования, нужно писать отдельную статью. Обозначу вкратце атомарность нашего UI-KIT.
Основа всей дизайн системы — гайдлайны.
На основе гайдлайнов строятся базовые элементы. А на основе базовых элементов строятся более сложные элементы.
По такому же принципу мы будем выстраивать нашу библиотеку компонентов, начиная с гайдлайнов и заканчивая сложными элементами.
Разработка
А теперь перейдём к проектированию. Библиотеку компонентов мы разрабатываем на React — стандарте ДомКлик. Будем использовать Typescript для статической типизации, что помогает удобно использовать наши компоненты. Почему нельзя взять готовую библиотеку компонентов и просто интегрировать в нее нашу дизайн-систему? Во-первых, это тяжеловесные библиотеки, которые повлияют на производительность ваших продуктов. Во-вторых, вам постоянно будет не хватать их функциональности и придется их постоянно дорабатывать.
Перед началом разработки мы задали себе несколько задач:
Версионирование
Мы будем итеративно разрабатывать наши компоненты, улучшать их, добавлять новую функциональность. Вероятно, у нас будет меняться дизайн. Работаем мы по SemVer, т.е. фиксы и улучшения производительности мы выпускаем в патч-версии; добавления нового API и возможностей — в минор-версии; смена API для работы с компонентом, дизайна и его поведения — в мажор-версии.
Есть несколько способов поставки библиотеки компонентов конечному потребителю — продуктовым разработчикам.
Самый популярный вариант: один пакет UI-KIT, который ставишь целиком в проект и в дальнейшем обновляешь его при появлении новой версии. В этом случае должен безукоризненно работать tree shaking, иначе при сборке проекта мы получим даже те зависимости, которые не используем.
Достоинства:
Недостатки:
Второй вариант — каждый компонент UI-KIT как отдельный пакет. В этом случае каждый отдельно взятый компонент версионируется по SemVer.
Достоинства:
Недостатки:
Мы выбрали второй вариант, потому что это менее болезненный путь для наших продуктов. В дальнейшем мы планируем выпустить один npm-пакет, который включает в себя все пакеты для тех команд, которым не страшно обновлять всё и сразу.
Мы будем работать в монорепозитории, потому что одни компоненты переиспользуют другие компоненты. Как мы будем управлять версионированием? Мы решили сравнить два наиболее подходящих инструмента для данной задачи: Lerna и RushJS.
Если смотреть на статистику, то Rush — наименее популярная библиотека. Так почему же мы выбрали её? Lerna была очень непредсказуемой и магической, нигде не было нормально описано, как она работает. Процесс релиза был недетерминирован. В Rush это сделано более системно: благодаря change-файлам ты всегда видишь, что поедет в релиз, и библиотека автоматически генерирует читабельные changelog, на основе которых бампит версии так, как тебе нужно. Также Rush работает с Git как надо. В целом эта библиотека показалась более зрелым инструментом, поэтому мы выбрали её.
Вот как мы работаем с Rush:
Сборка
Для сборки наших компонентов в формате ESM и ESNext с поддержкой tree-shaking мы используем Rollup, и ожидаем релиза Webpack 5, в котором нам обещают отличную поддержку этой функциональности. Чтобы у нас во всех пакетах была идентичная сборка и мы могли бы ее поддерживать и улучшать, мы можем везде ссылаться на один файл с конфигурацией. Но мы пошли дальше: создали библиотеку, которая этим занимается. Она гибкая, масштабируемая, и её можно использовать в других проектах для своих нужд. В ней уже соблюдены некоторые стандарты нашей компании: browserlist со списком поддерживаемых браузеров, сборка стилей, оптимизации для сборки библиотек и многое другое. Наши компоненты можно использовать в SSR-приложениях, при этом мы расширили поддержку старых версий NodeJS, собирая наши пакеты еще и в CommonJS-формате.
Стили
В наших компонентах мы используем CSS-модули и Sass как препроцессор.
О чем стараемся не забывать при этом подходе:
Переиспользуемые правила. Стараемся дедуплицировать стили и выносить переиспользуемые правила в пакет styles-framework, который включает в себя цвета, типографику, брейкпоинты, сброс стилей и много полезных миксинов. Другие команды могут его использовать в отрыве от библиотеки компонентов.
Вы можете сказать, что для этих целей отлично подойдет CSS in JS. Не буду спорить, возможно, мы к этому придем.
Иконки
Многие задаются вопросом, каким способом предоставлять SVG-иконки. Изначально мы попробовали выгружать их на CDN по отдельности, но в этом случае получали перерисовку контента и много потоков скачивания. При использовании спрайта потребитель получает огромную (и тяжеловесную) портянку иконок, из которых он может использовать только несколько. Поэтому мы решили предоставлять React-компонентами, которые содержат в себе инлайново SVG-иконки. При сборке релиза запускается скрипт, который перегоняет SVG-файлы в IconComponent, заменяя все свойства fill на currentColor и применяя SVG-oптимизацию, поэтому нашим иконкам легко изменить цвет, задав его родителю.
Кроссбраузерность
Если вы поддерживаете старые версии браузеров и у вас десятки продуктов, вы тоже можете озадачиться такой проблемой, как полифилы. Их вы можете встретить везде: в используемой open-source библиотеке, в пакете, разработанном коллегой из другой команды, и, конечно же, в библиотеке компонентов. В итоге получается, что есть много веб-клиентов, собирающихся с полифилами для стабильной работы во всех браузерах.
Некрасиво, верно? Поэтому мы создали сервис полифилов, который не только позволит убрать их из приложений, но и в зависимости от сегмента браузеров отдавать набор тех полифилов, которые необходимы для стабильной работы приложения.
В зависимости от заголовка user-agent сервис отдает тот или иной набор полифилов. Мы выделили три набора для трех сегментов браузеров.
Размеры наборов составляют непосредственно:
В итоге мы получаем:
Внедрение
Чтобы ваша библиотека компонентов удовлетворяла все потребности потребителей, нужно учесть следующие моменты:
Витрина компонентов
Вся полезная информация о наших компонентах будет представлена на витрине компонентов.
Здесь мы можем увидеть список всех наших компонентов, информацию по ним, показать все их состояния и возможности.
Тут мы можем увидеть нашу историю изменений. Эта информация берется из файлов CHANGELOG.md, которые генерируются с помощью Rush.
В секции Readme выводится информация из файла Readme, там можно увидеть информацию об установке компонента и перечисление всех его свойств.
Численность и состав
Изначально наша команда состояла из двух frontend (React)-разработчиков, одного дизайнера и одного product owner’а. Сразу хочется пояснить необходимость PO в команде. Человек с этой ролью не только выстраивает процесс и координирует работу команды, но и формирует позиционирование всей дизайн-системы, собирает потребности от других команд для дальнейшего внедрения в UI-KIT и исследует пользовательский опыт с интерфейсами, построенных на наших компонентах, для улучшения UX/UI. С увеличением кодовой базы, численности и масштабности компонентов мы расширились до пяти разработчиков, и не планируем на этом останавливаться.
Заключение
На дизайн системе список активностей команды Web Core не заканчивается. Мы также создаем омниканальные виджеты, такие как навигация по сайту, выбор региона и т.д. Стараемся выработать правила для стандартизации всей кодовой базы в нашей компании. Разрабатываем библиотеки для сбора метрик, авторизации и регистрации. И этот список можно дополнять и дополнять. Я надеюсь, что вы почерпнули что-то новое для себя и своей команды. Очень буду рад обратной связи! Всем спасибо!
