Привет, меня зовут Кирилл Васильев и я PM в Питерском офисе компании 4xxi. Здесь мы реализуем сложные IT проекты и стартапы. При этом мы всегда стараемся применять самые современные IT-технологии.

Успешность моей работы напрямую зависит от моей команды. И главной философией моей работы я выбрал доверие как инструмент общения с членами моей команды.

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

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

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

Это моя первая работа на подобном ресурсе, так что рассчитываю на вашу поддержку!

Как завоевать доверие?

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

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

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

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

Что мы упускаем?

Для повседневной работы у менеджера должен быть определенный набор скиллов, который каждый работодатель описывает в вакансии:

• Соблюдать сроки проектов
• Работа с рисками
• Высокая самостоятельность
• Поиск решения трудных вопросов
• Коммуникативные навыки и многозадачность

От себя добавил бы, что более важным является понимание основных психологических скиллов. Быть менеджером значит работать с людьми, а это невозможно без понимания того, как мыслят люди.

Быть менеджером значит работать с людьми

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

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

Менеджер одновременно и дирижер, и балансир интересов

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

• Тестировщик пропустил критичный баг
• Разработчик упустил важное архитектурное условие
• Дизайнер не обсудил с коллегами возможность реализации дизайна
• Оценка задач спустя рукава
• Нежелание оперативно реагировать на срочные задачи

Причиной таких ошибок является отсутствие положительного ресурсного состояния у команды.

С чего нам следует начать?

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

Закройте глаза и представьте ситуацию:

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

Какие чувства вы испытали?

Во время вашей акклиматизации в коллективе вам не помогут факты и аргументы. Это основная сложность данного этапа. Подойти к этому процессу в команде можно несколькими способами:

• Попросить команду забыть обо всём, что было при прошлом менеджере (но по факту никто не забудет).
• Можно уволить всех несогласных и нанять новых сотрудников, разделяющих ценности нового руководителя, но в мировой истории есть показательные примеры к чему это может привести.
• Но лучше / разумнее / вернее / адекватнее — строить команду в текущем коллективе.

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

И тут возникает главный вопрос, который нужно задать:

А как из незнакомых тебе людей сделать команду? Это как из 10 разных наборов Lego собрать Вольтрона.

Для продуктивной работы необходимо выстраивать взаимовыгодные и долгосрочные отношения. А первый и главный строительный материал отношений — Доверие.

Главный строительный материал отношений — Доверие

Каким должен быть первый шаг и какого результата мы хотим добиться?

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

Шаг 1 — Исследование

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

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

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

Шаг 2 — Обещание

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

В моем случае я пообещал, что не назначу ни одного дедлайна без учета мнения команды.

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

После небольшого обсуждения я аргументированно предложил дату дедлайна и задал несколько вопросов команде:

“Все ли я учел по вашему видению? Нужно ли нам что-то еще, перед тем, как мы примем решение?”

И при двух положительных ответах на эти вопросы я задал финальный:

“Мы согласны с датой дедлайна?”

Ответ был да.

Я потратил на 2 часа больше времени для установки дедлайна, чем обычно — час на подготовку к собранию и час на собрание с командой. Главное — я выполнил обещание, что позволит мне продолжить выстраивать доверие в команде.

Вы же, к примеру, можете пообещать:

• Я никогда единолично на приму решение релизить в пятницу, только если решим это вместе
• Я всегда сначала буду спрашивать оценку фичи у команды и только потом согласовывать с клиентом
• Помогать в трудной ситуации и максимально брать весь негатив клиентов на себя

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

Так что это дает?

Менеджер формирует мысли людей, что скоро он совершит поступок, благодаря которому на счету у доверия появится первый взнос.

Шаг 3 — Обратная связь

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

“Правильно ли я всё сделал? Соответствует этот поступок его ожиданиям? Могло быть что-то лучше?”

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

Процесс обратной связи вынуждает людей дать оценку

В случае успешной обратной связи вы заложите важную мысль в голову сотрудника:

“Круто, ко мне прислушиваются!”

Это уже эмоциональная составляющая, которая позволит в дальнейшем отслеживать состояние сотрудника. Он без опасений будет делится с вами всем, что накипело.

Человек находится под влиянием людей из своего окружения. Для качественной работы команды необходимо синхронизировать эти мысли, чтобы процесс разработки шел в унисон. Это непростая задача, ведь у каждого человека свой бэкграунд. Это лишь первый шаг, завязка детективного фильма. Мы только заслужили вести это “дело”, теперь предстоит настоящая тонкая работа детектива. Но об этом в следующей части.

Что почитать?

Стивен Кови — “Скорость доверия. То, что меняет все”.

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

Начнем прокачивать скиллы доверия:

• Захотеть построить доверительные отношения с командой (или персоной)
• Определить первый объект взаимодействия
• Узнать о проблемных или просто важных ситуациях, которые были в работе
• Назначить время и место первой встречи
• Подготовить рассказ о себе и трудностях
• Подготовить обещание
• Выполнить обещание
• Собрать обратную связь

Recommend to watch

ДОВЕРИЕ В КОМАНДЕ was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

О работе над качеством продукта

Раньше, когда я занимался разработкой, у меня были отдельные отделы тестирования. Все было четко — программисты программируют, потом они идут и … программируют дальше. То, что они сделали, уже тестеры пытаются решить эксклюзивно, а потом опять по кругу. На самом деле в Google большей частью тестирования занимаются именно сами программисты. Они проверяют друг друга, оставляют сами себе комментарии.

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

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

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

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

Когда программисты работают, они подготавливают еще и процесс описания, потому что, если затем что-то непонятно из самого кода, это придется обсуждать. Изменение возвращается обратно к первому программисту. Спрашивают: «Я не понимаю, что здесь происходит. Можешь прокомментировать?» Этот человек опять пишет.

Вот эти комментарии и объяснения о том, что ты “архитектуришь” у себя в продукте и какое изменение ты сделал в большей степени описывается “до”, чем “после”.

Делая свой проект (Zimad Games) до Google, наши программисты часто что-то писали, ничего не комментируя. Как итог, архитектуры были слабенькие, тестеры мучились, зато все было очень быстро.

Так что, в принципе, ради качества мы жертвуем временем.

Об особенностях работы с миллиардной аудиторией

Еще один момент, который мы не делали раньше, но на этом масштабе я понимаю, что иначе не получится: мы больше заботимся о качестве — у нас есть очень четкий процесс roll out обновлений.

Потому что у Google миллиарды пользователей, мы не можем просто включить кнопочку, и сразу все миллиарды пользователей получают новую фичу. Мы делаем очень медленный roll out и постоянно экспериментируем. Вот мы сделали — 0,5% аудитории по всему миру, автоматически выбирается население в разных странах или каких-то разных конфигурациях в зависимости от того, какие технологические требования и девайсы у разных пользователей. Для этих пользователей выкатывается обновление и наблюдается, что происходит с метриками.

Во-первых, у нас есть все метрики, которые называются product health.

Мы отлично знакомы с ними: количество тикетов, скорость, стабильность — куча вещей, которые вам дадут информацию о том, что продукт работает нормально, проблем нет. Очень осторожно следим за этим. Прошел день, два, три, нет изменений.

Иногда подключаются аналитики и говорят: «Окей, изменения, которые мы ожидаем, еженедельные — это нас не касается. А есть изменения base line? Нет изменений. Идем дальше: 2%, 3%. И прямо постоянно у нас идет это бета-тестирование на выбранном количестве пользователей. Оно идет медленно-медленно конечно: вначале мы делаем супер-альфу, где выбираем конкретно пользователей.

Мы говорим: «Можем включить вам вот такую фишку. Вы будете альфа или бета, но могут быть вот такие проблемы». Они говорят «о, да-да», «нет-нет». Подписываются, и мы начинаем.

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

Там мы можем просто прислать и сказать: «Окей, мы сделаем вот такое изменение такого-то числа. Если хотите, напишите».

Потом начинается — включили бету, проанализировали результаты, проговорили cross functional. Все нормально? Если есть какие-то нюансы, обсуждаем. Нас устраивает, что падение — вот тут, а подъем здесь? Это ожидаемо?Мы на это не рассчитывали? Хорошо, идем дальше. Дальше включаем 20%, 40% аудитории.

Внимательно смотрим и видим результаты, все идет хорошо или нет?Так вот этот trade off надо обсудить, получить подтверждение от трех директоров, что это все нормально. Потому что эти цифры, которые изменились, для нас хорошо, а другой команде плохо — называется counter metrics.

Вы как бы следите за вашей метрикой: у вас все хорошо, а в соседней кампании, в соседнем отделе что-то плохо.

Или у всей компания главная сounter metrics — Facebook обожает это делать, кстати.

Вы-то себе помогли, а в другом месте стало гораздо хуже — за этим надо следить.

Потом дальнейший roll out, и потихоньку уже на 100% аудитории продукт идет.

Следим за тикетами постоянно и продакт-менеджеры с инженерами решают: «Окей, у нас там N-ное количество тикетов. Мы делаем roll back или что мы делаем? Мы чиним это? Оставляем? Говорим, мы выпускаем больше custom reservice? Может быть, больше коммуницируем, объясняя, что происходит?»

Вот такой процесс. Он такой “give and take”, туда-сюда.

Любая фича работает по roll out.

Нельзя просто прийти и: «Я включил».

О тестировании продуктов

Есть же много разных вариаций тестирования: естественно, мы проверяем регрессию, автоматизирование, практически всё пытается быть на автомате.

Когда программист пишет код, этот программист обычно сразу же пишет тест-кейсы и 70–80% автоматизированную проверку на этот код. Кто лучше понимает код, чем этот программист? В принципе никто. Поэтому этот программист сам и пишет эти тест-кейсы. Естественно, они потом тоже проверяются.

Есть много разных важных типов тестирований, которые надо сделать.

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

Но это не обязательно будет работать во всех компаниях.

Так что не спешите говорить своим программистам, чтобы они писали тест-кейсы :)

О том, как принимаются решения о новом продукте

Насчет “решений” громко сказано. Я раньше принимал очень много решений, выделяя все. Один человек единолично решение не принимает.

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

Это все уникальные кейсы, их надо рассматривать отдельно.

Желательно исходить опять же из твоей цели, цели пользователя и цели компании.

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

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

Им нравится этот продукт? Они пользуются этим продуктом?

С этого можно начинать.

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

Если ты решаешь проблемы для пяти миллиардов человек, ты всегда найдешь пользователя.

Если ты решаешь проблемы для пяти миллионов человек в мире, то тебе тяжело будет найти эти пять миллионов.

Хотя Facebook и Google тебе здесь помогут очень сильно.

Но опять же, чем меньше проблемы, тем тяжелее это будет скейлить.

А чем больше компания, тем важнее стоит этот вопрос scale.

О коммуникации внутри компании

Начать стоит со взаимоуважения.

В принципе, можно на этом и закончить. :)

Слушайте что вам говорят, и услышьте это.

Люди обычно отстаивают свою точку зрения: «А вот у нас…», но я старался так не делать. A в top-tech компаниях — это прямо культура. Нет такого, что тебя кто-то прерывает. Просто нет. Если прерывают, сразу извиняются: «Извини, не хотел прерывать, закончи мысль, потом вернемся». Что-то говоришь — тебя слушают, пытаются услышать, что и почему ты сказал. Потому что это — стандарт.

Предполагайте, что когда общаетесь с кем-то, что там все умнее, чем вы!

Когда вы что-то говорите, поверьте — человек услышит вас. И вы точно так же должны относиться к этому человеку. Когда вам что-то говорят, послушайте: «Окей, что я здесь не понимаю?» Не ищите путей, как сразу ответить и сказать: «А нет-нет-нет, и вот почему». А ищите пути, как услышать: «А что из этого я на самом деле не понял? Может быть, этот человек действительно мне помогает?».

А потом остальное — уже тактически. Как часто вы встречаетесь, как ведете учет. Естественно, организация очень важна.

У вас должен быть человек, который понимает, что вы здесь делаете и что вообще решается. Чтобы не было такого, что дискуссия на полчаса и непонятно что решили. Что мы решаем? Что нам надо в конце? Кто должен следить за временем?

Чтобы не было такого, что вы все проговорили, но не ответили на главный вопрос.

Это такие тактические проблемы организации. Лично у меня с этим была куча проблем.

Про тайм-менеджмент я прочитал все, что существует и все равно не получается — я окружен этими бумагами и календарями. Это постоянная работа.

Самоорганизация — это очень важно, но уважение превыше всего.

Все остальное — тактическое.

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

Это философский ответ, но так оно и есть.

О первых эмоциях от работы в Google

В первый год работы я думал: “Куда я вообще попал? Почему все такие вежливые, приятные и умные?” Такая странная комбинация.

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

Когда это произошло второй раз (потому что первый раз я был просто в шоке), я подошел к человеку и говорю: «Знаешь, когда ты так делаешь, я вот так себя чувствую. Другие себя, наверное, так чувствуют тоже. Я не думаю, что ты вот это хотел сделать, но вот так получилось. Не мог ли ты это по-другому сделать?»

Он говорит: «Знаешь, я даже это не заметил. Давай я попробую». Даже этот человек, который сильно нагрубил, все равно осознал. И в следующий раз реально стало лучше. То есть эта культура работает.

О книгах.

1. Если конкретно продакт-менеджмент, — Практичный продакт-менеджмент.

2. Есть огромная книга Tools продакт-менеджера. Там говорится о roadmap, как это делается, разные графические элементы, презентации и так далее.

3. Но в принципе я люблю читать бизнес-книги, может быть, вы слышали, Zero to One, Piter Thiel. Это такая классика, рекомендую.

4. Потом все, что касается организации, Lean Startup.

5. Потом Blue ocean

6. И из коммуникации я люблю, тоже популярная книжка Crucial conversations, написана. Кстати, полезная не только в бизнесе, но и в жизни.

7. Есть вот такая, Thinking fast and slow. Тоже больше о коммуникации и стиле мышления. Есть два процесса мышления, fast and slow.

Вся книга о том, как если мы думаем и отвечаем сразу, то это совершенно другое, чем если мы думаем и даем длительный ответ после какого-то раздумья.

Много о том о человеческой психологии, нестандартном мышлении.

8. Кстати, об этом есть еще книжка Predictably irrational. Кто не читал еще, она старая, лет 10–15. Но просто фантастика. Predictably irrational для тех, кто работает с пользователями.

Экономисты считали, что люди — человек разумный, ведет себя логично, имеет рациональное мышление. И всегда будет вести себя логически. А на самом деле оказалось, что вообще не так.

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

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

Кроме этого, биографии великих людей — это вообще классное дело.

Много всякого можно узнать.

9. Если про технологию, естественно, Билл Гейтс, Стив Джобс, есть хорошие биографии.

10. Билл Гейтс написал книгу, по-моему, лет 20 назад. Называется, по-моему, Speed of thought. Книжка про менеджмент.

Вообще не слушайте меня, пойдите и посмотрите, что Билл Гейтс рекомендует читать.

Один из самых умнейших людей в мире читает по 300 книг в год.

Величайший человек и в бизнесе, и в жизни. Он не подведет.

Эти книжки тоже можете почитать, но лучше Билла Гейтса послушайте :)

Как в Google управляют проектами? was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

В чем особенность создания продуктов в таких IT-гигантах, как Google, Apple, Microsoft или Facebook?

Они не просто создают так называемые “social-impact” продукты — через них специалисты стараются менять восприятие современного мира.

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

Команда 4xxi не является исключением — мы учимся у лучших мировых компаний и регулярно общаемся с топовыми экспертами из различных областей в сфере IT.

Именно поэтому наша последняя Q&A сессия с Александром Речевским была настолько сногсшибательно полезной, что мы решили поделиться видео и текстом сессии со встречи.

Кто не знает, Александр Речевский — Senior Product Manager в Google (Сан-Франциско), он играет одну из важнейших ролей в компании.

Алекс согласился выделить нам час своего времени и ответить на те вопросы, которые ему не удалось осветить в своих предыдущих интервью и на собственном YouTube канале.

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

А после диалога с Алексом мы получили и крутые инсайты, и ценный опыт из самого сердца Google — как нужно мыслить, неся ответственность перед миллиардной аудиторией и как управлять сотнями тысяч сотрудников внутри организации, выпуская шикарные продукты!

Поехали!

В одном из последних интервью для Паши Хегая (создателя лучшего Network сообщества в России, в котором состоят топовые специалисты из ИТ-гигантов) Алекс поделился собственной дилеммой, которая нас сильно зацепила:

в больших гигантах как Google, Facebook, Apple необходимо учиться работать в рамках множества степеней свободы. С одной стороны это хорошо, а с другой — тебе никто не говорит, что нужно делать.

Поэтому наше общение началось именно с этого вопроса, передаем слово Алексу:

Что делать, если тебе никто не говорит, что делать?

На самом деле самый сложный вопрос — придумывать, что делать и чем заниматься. В Google, по факту, решать приходится те задачи, которые ты сам себе ставишь.

Однако, стоит отметить, что это касается именно product-ов. Ведь если говорить о Google или такого рода других компаниях, то именно product-менеджеры говорят, что нужно делать. Грубо говоря, это они стратегические лидеры компании.

Именно они выбирают, что и зачем нам делать. При этом они не решают, как это делать. За этот момент отвечают инженеры, программисты и т.д. Конечно, некоторые product-менеджеры еще и определяют, как это делается, при этом иногда не хотят решать, что и зачем делать.

Структура у всех этих фирм более-менее похожа. Ведь они друг у друга берут идеи и нововведения. Например, в Facebook и Google очень похожа культура, вплоть до того, как устроены кухни и конференц-залы, как проходит митапы, как строится бизнес и так далее.

Так что, возвращаясь к теме, все зависит от внутреннего уровня product-менеджера, исходя из его мнения и решается вопрос или задача.

Кстати, уровни у product-ов такие: 3–4–5–6–7–8, директор, вице-президент, VP, SVP и Сундар Пичаи. Сундар — великий вождь для Google, как Марк [Цукерберг] в Facebook.

К примеру, если ты только начинающий product-менеджер, тебе обычно дают конкретную фичу или часть конкретного продукта.

Окей, вот фича, по типу Google Maps или какого-то другого продукта.

Теперь нюансы этой фичи — как это делается, какие сервисы нужно подключать/отключать, какое должно быть решение у пользователя, зачем это делается, как можно упростить для пользователя и так далее.

Далее, если твой уровень немного выше, ты начинаешь думать о какой-то части продукта или о продукте в целом. Это может быть рекламный отдел или конкретная сфера рекламной области.

Потом ты начинаешь думать сразу о нескольких продуктах или о большом массивном продукте с десятками или сотнями миллионов пользователей.

Дальше ты думаешь об одном центральном или о нескольких центральных продуктах. За это уже отвечают VP, SVP и так далее.

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

О принятии решений и как на них влияет ДНК компании

“Что делать” — в крупной компании всегда исходит из пользователя, что он хочет и зачем это ему вообще надо.

Вопрос «как нам заработать денег?» вообще не озвучивается.

Хотя, может быть в Amazon больше думают как раз об заработке, в Facebook и Google в первую очередь думают о пользователе.

Просто если ты знаешь ДНК своей компании, ты и исходишь из этой ДНК.

К примеру, у Google ДНК четкое — взять всю информацию во Вселенной и организовать её, чтобы она была полезна людям.

Все задачи исходят из этой цели.

Получается, когда начинаешь решать, что делать, твои мысли крутятся вокруг того, а кто вообще наши пользователи, что они делают и зачем мы вообще нужны им? Что за проблему они пытаются решить за счет наших продуктов?

А потом ты начинаешь думать дальше — окей, это вот проблема пользователя, а вот это их микро-проблемы.

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

Потом представляешь первый, второй, третий, четвертый шаг. Вот они подошли к нашему продукту, чтобы решить какую-то проблему. Что эта за проблема? Она может быть и частной, и общей.

Например, если мы берем тот же Google Maps, то трудно сказать, какую одну проблему он решает. Можно, конечно, сказать — навигация, прокладывание маршрута, поиск адреса. А если ты хочешь перекусить где-нибудь поблизости? Найти рядом клинику, сказать своему другу, где ты находишься? Или вы с друзьями/коллегами хотите где-то встретиться, создать маршрут?

Миллион решений!

И все зависит от того, в какой области ты находишься, в каком разрешении ты хочешь думать — высоком, низком или четко выбранном.

Начинаешь продумывать выбранное направление.

Что конкретно хочет человек сделать? Почему, как, где и так далее.

Когда начинаешь понимать конкретно, то начинаешь рассматривать свой продукт и думать, где в нем есть проблема, а где — потенциальная возможность улучшения. Где можно улучшить чуть-чуть, а где радикально. А где, например, можно предложить что-то, о чем сам пользователь даже не думал?

Решая боли пользователя у него появляется внутренняя мотивация пользоваться продуктом, даже не поверхностная!

О том, как добраться до реальной проблемы пользователя

Как вы думаете, зачем нам нужны игры на компьютере или телефоне? По факту, они нужны нам не для того, чтобы разово развлечься. Если смотреть глубже, то они помогают нам бороться со скукой. Мы начинаем играть в игры, когда нам становится скучно.

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

Решение проблемы — не «развеселить».

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

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

Потом сидишь, размышляешь, весь день философствуешь, делаешь огромный список и выбираешь то, что может действительно помочь с улучшением продукта. Что конкретно и существенно повлияет на взаимодействие пользователя с продуктом?

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

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

Если мы работаем не в Google, а в других более-менее стандартных компаниях малого или среднего бизнеса, тогда ты учитываешь не только эти моменты. Тебе также необходимо просчитывать, что эти изменения сулят твоему бизнесу: как изменится прибыль, эффективность работы, на какой период времени.

Потом ты смотришь, сколько это все будет стоить, как ты будешь это делать, какие у тебя будут сложности.

Обо особенностях процессов в ИТ-гигантах

В Google и больших компаниях все гораздо сложнее. В другом бизнесе придумал и, условно, на следующий день уже сделал. А тут сам процесс займет года три! Тебе надо говорить с сотнями людей.

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

Какие задачи приходится решать — на моем уровне это надо четко придумывать. Приходишь в офис — задач нет в принципе.

Кто-то там уже что-то напридумывал — давайте сделаем такой репорт. Мы уже год его делаем, сделали, а что из этого вышло? Кто виноват?Саша виноват, не продумал.

От личной ответственности никуда не уйдешь.

О балансе свободы и командной работы

Это касается и серьезных изменений, радикальных даже — во всех топовых компаниях процесс более демократичен. В принципе, ты можешь сделать все, что хочешь: запустить любой продукт, никто не останавливает! Процесс полностью органический: тебе не нужно рассказывать о своей идее какому-то дяде или тете — такого нет вообще.

Ты просто начинаешь обсуждать свою идею или предложение с людьми, с которыми ты работаешь и которым доверяешь. Потом общаешься с теми, кто работает в нужных сферах. Обычно у тебя есть хоть какое-то представление об этой сфере, иначе ты вряд ли бы придумал что-то новое и радикальное.

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

Открыл google docs, написал:

“Есть такая фишка. Нам нужно решить эту проблему, по-моему, мы её не решаем. Но есть это и это. Это похуже, но не совсем. Вот такие мои мысли”.

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

Потихоньку люди начинают оставлять комментарии:

«А вот это интересно, поговори вот с этим человеком. А вот об этом ты думал? И вообще-то на самом деле эту фишку делали два года назад, и она полностью провалилась, не получилось вообще ничего, очень похоже на 95%».

Кстати, так очень часто происходит! Потому что здесь сотни тысяч сотрудников, в этих компаниях работают люди с предпринимательскими жилками, и они все время что-то придумывают!

Очень часто есть куча таких документов. Инженеры могут просто взять и начать что-то строить. Любой может прийти и сказать: «Вот, я сделал».

Например, очень часто у нас делают всякие внутренние extensions, приложения для телефонов или что-то, что позволяет улучшать работу.

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

Просто внутренние приложения, снаружи никто не может им пользоваться.

Это бывает очень полезно — часто просто взял и начал работать.

Миф о 20%-ом времени

Еще у Google и некоторых подобных компаний есть такой концепт, может быть, вы слышали о нем — 20%-ное время.

Это такой миф.

Когда-то давно в Google говорилось, что 20% времени — это твое время. Делай с ним что хочешь — придумывай новые вещи, строй новые проекты и так далее. Один день в неделю вообще твой. Скооперируйся с другими коллегами, делайте новые приложения.

Естественно, это все принадлежит Google. Всегда все, что ты делаешь, принадлежит компании. Опять же, руководство очень демократично в этом плане себя ведет.

На самом деле это 20%-ное время превратилось в шутку в компании, его называют «120% времени». Естественно, ни у кого уже нет этого свободного дня в неделю. Если ты хочешь это делать, что-то такое построить, делаешь в 120% своего времени, в субботу или воскресенье.

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

Та же Stadia (суперигры прямо в браузере) — идея хорошая, но как обычно, есть свои нюансы и проблемы. Семь лет Stadia разрабатывается!

Я знаком с парнем, у которого появилась эта идея, он мне сказал:

«Да-да».

Я к нему тоже пришел, хочется поучаствовать, тоже что-то сделать.

Он говорит: «Да пожалуйста, ради Бога! Начинай, если есть что-то, давай будем кооперировать. У тебя сфера такая-то? Помогай вот здесь».

Говорит: «Я сам уже семь лет этим занимаюсь, вот вчера выпустили».

Семь лет от идеи до запуска!

О том как строятся новые внутренние продукты

Много всяких продуктов, которые мы любим и знаем, тот же Gmail или Android, Stadia — это все создавалось изнутри. Началось просто с того, что продакт-менеджер предложил, уговорил какого-то инженера начать это строить, потихоньку оно строится. Но строится оно очень-очень медленно.

Поскольку это все принадлежит Google, проекты, которые касаются тех сфер, которыми занимается сам Google, свой стартап в этом направлении ты иметь уже не можешь.

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

Часто люди уходят из этих компаний, делают стартап и потом возвращаются через n-ое количество лет. Это нормально.

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

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

Но подход более либеральный — пожалуйста, работайте над тем, что вас интересует. Желательно, чтобы это было что-то в компании, ваш passion. Либо, если надо, уходите и возвращайтесь, будем рады опять вас увидеть.

Вот такая философия.

Как демократия Google уживается c OKR и KPI

KPI — это показатель достижения успеха в определенной деятельности или в достижении определенных целей.

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

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

Гиперрост тяжело контролировать. За счет OKR им удалось немножко это сделать — все хотя бы понимают, куда двигаются разные сферы компании.

OKR очень требовательна: она создана, чтобы любой другой отдел или другой продукт видели, что есть ваша цель, и чтобы вы сами знали, что ваша цель достигнута.

KPI тоже есть, ничего необычного, но иногда Google изощряется: бывает, что любое действие, любая трата человеческих и/или денежных ресурсов требуется объяснить через KPI.

Цель компании есть, ее всегда можно посмотреть.

Но цель компании огромная:

Facebook — «соединить всех»,

Google — «организовать всю информацию».

Из нее исходит: «А как мы это сделаем?». Давай дадим доступ к интернету еще миллиарду населения. Или улучшим релевантность результатов поиска. Или заработаем больше денег для наших рекламщиков.

Это разные KPI.

Но опять же, каждая команда создает его сама. Нет такого, что кто-то сверху создал OKR продукта — сама команда должна подумать и сказать: «Окей».

О работе над метриками

Скажем, наш type line metrics.

Мы хотим для N-го количества пользователей понизить churn, заработать деньги или повысить в процентном соотношении конверсию, или степень роста год на год / месяц на месяц.

Команда сама может выбирать метрику в зависимости от того, над чем она работает. И команда еще не выпустили продукт, у них задача — выпустить продукт, добить количество ingate users.

Опять же, нет ничего нового.

Тот самый acquisition, engagement, весь жизненный путь продукта — все, что может быть связано с ними, обычно используют.

Если кто-то работает над фичей продукта, то мы улучшаем модели machine learning, чтобы мы могли автоматически решать много задач на этих уровнях — как делать все автоматически.

Например, мы хотим, чтобы наши модели стали более эффективными на N%. Но без того, чтобы мы делали Х ошибок.

Мы увеличиваем эффективность, но процент ошибок не поднимается. Таким образом, мы знаем, что наш продукт будет успешным. Опять же, это сами продукты компании это делают.

Естественно, это начинается, собирается продуктовая команда, продакт-менеджеры, инженеры, кто еще в команде.

И начинают думать: «Окей, что и зачем нам надо сделать? Как мы будем знать, что это будет сделано?»

Потом собираются все уже в большей группе, департамент или отдел: «Окей, у вас такая и такая цель, а у нас в нашем отделе вот такая. Это сходится, логично».

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

Естественно, если ты SVP (Senior Vice President), который следит за всей рекламой Google, ты не будешь читать миллион OKR у каждой команды.

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

В Google очень много уровней, фич, продуктов, главных линий компании, которые надо скоординировать на уровне миллиарда пользователей или миллиардов долларов.

Это совершенно другие задачи.

То, что делают top tech, не всегда полезно на уровне стартапа или маленькой компании.

В больших компаниях надо уметь выбирать лучшее и отказываться от худшего.

Как в Google управляют проектами? was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

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

Наверное, стоит начать с того, что в юности я хотела открыть свое дело. Поэтому в старших классах моим профильным предметом была экономика. А уже в университете я выбрала направление “Менеджмент организации” и в итоге окончила его с отличием.

Первая моя официальная работа была на part-time в магазине нижнего белья и пижам в международной компании. Тогда же я узнала, что стать управленцем нельзя просто так после окончания университета.

Для этого надо знать, как работает определенная сфера. Надо вообще знать, что такое работать! Поэтому дальше свое образование я рассматривала, скорее, как галочку в наличии пресловутой корочки и как гордость родителей.

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

А я просто менеджер. Менеджер чего?

В общем, решила поресерчить в интернете этот вопрос. И вдруг меня осенила мысль: “А почему бы не стать программистом?”. Вот так просто. Как по щелчку пальцев.

На самом деле мотивация была такая:

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

На тот момент среди моих знакомых не было ни одного программиста, так что я спросила у Google, с чего начать изучать программирование. Самый популярный ответ — “HTML, CSS и JavaScript”. По большей части, это и определило мое направление. Как итог, я занялась Frontend-разработкой, но об этом позже.

Несколькими днями позже я списалась с бывшей одноклассницей, которая, оказалось, занимается Frontend’ом. Это была удача, потому что она порекомендовала ресурсы, где можно попробовать онлайн верстать и писать JS-код.

Первым шагом была покупка ноутбука (на планшете прогать не очень удобно).

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

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

Поиски были довольно долгими.

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

Так как это IT-компания, я решила сразу сказать, что вообще я хочу быть разработчиком. На что CEO сказал:

“Мы ищем офис-менеджера, как минимум, на два года”.

Тогда я ответила:

“Отлично! Я и планирую пару лет поработать офис-менеджером. Будет время выучить язык!”.

Так я начала работать в 4xxi.

Спустя полгода у меня с CEO случился тот самый разговор:

— Кристина, может, тебя отправить на курсы по юриспруденции, бухгалтерии или кадрам? (Так как моя работа напрямую связана с этими сферами)
— А, может, JS? — спросила я.
— А, может, JS.

Честно, в тот момент я потеряла дар речи: для меня было практически немыслимо, чтобы CEO компании предоставил такую возможность сотруднику, потому что это кардинальная смена деятельности.

Позже я написала письмо с вопросом, а не шутит ли CEO.

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

В итоге в наставники мне выделили нашего Frontend-тимлида Сережу.

Помню, как я сообщила ему эту новость:

— Серёжа, привет! У меня есть для тебя новость.
— Привет! Хорошая или плохая?
— Это тебе решать. У тебя теперь есть стажер.
— Кто?
— Я.
— Это шутка?

Конечно, сначала это кажется шуткой, потому что услышать такое от офис-менеджера — это очень неожиданно.

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

Это были курсы HTML Academy. Она поделилась со мной видео-уроками и ресурсами, макетами и стандартным репозиторием.

В итоге мы с CEO обговорили условия и поставили мне цели и сроки на ближайший год. Я должна была пройти два курса по верстке, сделать стандартное тестовое задание 4xxi и начать изучать JS и React.

Я смотрела курсы и выполняла задания. Если были вопросы, то общалась с Сережей. Всё это было в выходные или вечером после работы. За что, кстати, Сережа огромное спасибо! Мы могли созвониться в 11 вечера и обсудить, как лучше отцентрировать блок на странице!

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

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

В какой то момент я поняла, что deadline близок. А я так же далека от выполнения плана, как жаркое лето — от Питера! Тогда я взяла себя в руки и решила, что одну контрольную точку я сдам: это пройти оба курса и сделать тестовое. И я это сделала!

Тимлид, кстати, довольно высоко оценил приобретенные мною скиллы в HTML Academy.

И все же итоговым переломным моментом стала следующая ситуация.

Для одного проекта ПМ попросил себе верстальщика на один день, чтобы сделать небольшую задачу в течение недели. Но ресурсов на тот момент не было. И я подумала: почему бы не помочь? Спросила, что за задача. Она оказалась довольно простенькой и заключалась в вёрстке отдельной от проекта страницы с цветовой анимацией и небольшим JS-кодом. Мы обсудили и договорились, что я после работы за 3 вечера сделаю её. CEO одобрил.

А после сдачи задачи CEO написал мне:

“Крис, открывай вакансию офис-менеджера, ищи себе замену и обучай”.

Я была в восторге от такого сообщения! Я стала ближе к своей цели еще на один шаг!

Я нашла себе замену и начала передавать все свои дела.

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

Уже с Нового года (настоящий подарок) 95% рабочего времени я занималась разработкой.

Первым моим боевым проектом стал редизайн нашего сайта 4xxi. Затем уже пошли коммерческие проекты на jQuery, React. Я буквально в бою учила JS. Но и, конечно, занималась дома (учебники, маленькие задания).

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

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

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

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

1. Моя напарница по первому коммерческому проекту спустя год призналась, что считала эту затею перехода из офис-менеджера в разработчики провальной. Но она увидела мои стремления и поняла, что ошибалась. И теперь она многим знакомым рассказывает мою историю и ставит в пример именно меня. Можно сказать, она была свидетелем и участником моего роста.
2. Безумно приятно было услышать слова похвалы от моего CEO, который был свидетелем моего найма в 4xxi и дальнейшего роста. Он тоже рассказывает о моём примере своим знакомым.
3. Мой друг (самоучка-программист) был приятно удивлен, что я добилась своей цели. И это очень круто. За последние лет пять у него каждую неделю хоть один да спросит, как стать программистом. Многие начинают. Но из всех людей смогли прогать только 4 человека. Приятно оказаться среди них.

Подводя итог, можно составить краткий ToDo-лист по достижению цели:

1. Определите точную цель “Хочу быть программистом!”. В идеале, добавить срок достижения, например, через 2 года.
2. Определите, зачем вам действительно это надо. Это будет хорошим мотивирующим пинком, когда вы подумаете бросить всё на полпути.
3. Найдите наставника. Будет здорово, если он же будет еще и вашим мотиватором, который будет спрашивать “Ну что? Как дела? Когда сделаешь то-то и то-то? Может, созвон?”. И вам будет стыдно, что вы срываете сроки.
4. Составьте с наставником план и ограничьте количество ресурсов для изучения, чтобы избежать дублирования информации (в 20 книгах по одному языку программирования 90% информации будет повторяться, так зачем распыляться на них?).
5. Использовать любую возможность, которая приблизит к цели.

Дерзайте, друзья! И, самое главное, верьте)

Ваша Крис, Frontend-разработчик.

Как я перешла на светлую сторону was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

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

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

О ПЕРЕХОДЕ НА УДАЛЕНКУ

35% ребят в 4xxi и так работали удаленно на постоянной основе, поэтому мы достаточно легко организовали переход тех, кто являлся любителем офиса.

Мы предоставили всю необходимую технику для работы: ноутбуки, стационарники, девайсы для QA и др. Также позаботились о комфорте самого рабочего места: столы и стулья оказались в списке необходимого перечня для тех, кто не привык постоянно работать из дома.

Отлаженные бизнес-процессы в нашей компании, в том числе и в HR, позволили безболезненно перевести всю компанию на режим полной “рабочей самоизоляции” за довольно короткий срок.

О ЗАДАЧАХ И ВЫСТРОЕННЫХ ПРОЦЕССАХ. ВЛИЯНИЕ COVID-19.

У меня достаточно широкий спектр HR-задач: найм и рекрутинг, онборд и мотивация сотрудников, поддержание HR бренда, обучение и развитие коллег, корпоративная культура и создание дружественной атмосферы. Как раз те важные составляющие моей работы, которые “нельзя пощупать”, но которые действительно сильно влияют на репутацию компании, на отношение сотрудников и на уровень комфорта внутри команд.

И в марте передо мной встал самый важный вопрос: как перевести оффлайн-процессы в онлайн и как выстроить свою работу таким образом, чтобы ни на эффективности, ни на результативности это не сказалось. Но обо всём по порядку.

Рекрутинг.

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

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

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

Но мы продолжили поиск на открытые вакансии, задействовав большее количество инструментов и каналов для найма, сократив этапы отбора до 1–2х.

Мы обратились к кадровому резерву, отлично “выстрелила” реферальная программа и аутстаффинг персонала. Не обошлось и без общения с фриланс-ребятами.

Благодаря наработанным контактам и взаимной поддержке от компаний-партнеров, мы не допустили простоя проектов и восполнили нехватку ресурсов точно в срок.

Онбординг.

В качестве инструмента для адаптации новичков в нашей компании используется наша собственная ERP-система (первый инструмент контроля) и Trello (второй инструмент контроля), где на протяжении всего испытательного срока ответственные люди помогают новому коллеге.

Процесс онборда построен следующим образом: карточка нового сотрудника ведется в доске Trello и путь прохождения разделен на несколько этапов.

Он включает в себя:

• Информационные задачи (изучение истории и ценностей компании, проектов, знакомство с бизнес-процессами);
• Бюрократические (подписание необходимых документов);
• По фану (сходить на обед с новыми коллегами, узнать прикольные истории из жизни компании и др);
• Направленные на самоконтроль (тайм-менеджмент).

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

В Trello чекаем, как ребята выполняют задачи, в ERP — собираем и заносим фидбеки и отслеживаем сроки завершения испытательного срока.

За каждым из новичков обязательно закреплен куратор. А в течении всего испытательного срока мы проводим ежемесячные встречи, где даем обратную связь о результатах и спрашиваем об уровне комфорта новичка.

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

Обучение и развитие.

Безусловно, обучение и развитие своих сотрудников для 4xxi является способом повышения эффективности и вовлеченности кадров, а это один из важнейших факторов успеха.

Раз в полгода в нашей компании стартует ревью 360, которое позволяет помимо самооценки каждого из ребят, дать фидбек своему коллеге, с которым взаимодействовал или же каким-либо образом сталкивался по работе другой сотрудник.

После чего формируются итоговые отзывы и, исходя из оценок техническими лидами/кураторами/руководителями, составляются индивидуальные планы развития.

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

Цели в планах формируются с двух сторон: от стратегии развития компании, необходимых знаний и навыков сотруднику для профессионального роста и от желания в изучении технологий/прокачку компетенций самого сотрудника.

Помимо этого, мы достаточно часто проводим PHP-Party (и не только), в котором наши ребята передают факел спикера и рассказывают о новых интересных штуках. Такие клубы внутри компании не редкость и затрагивают другие специальности: QA, FE и ПМ.

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

А совсем скоро (ну как скоро, в июле) мы хотим принять участие в качестве спикеров на одной из IT-конференций.

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

Корпоративная культура. Атмосфера, командный дух и мероприятия.

Для 4xxi корпоративная культура, как ресурс компании, бесценна.

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

Наша модель корпоративной культуры построена на принципах “Семьи”.

Теплая, дружеская атмосфера, часто руководители и ТОПы выступают в роли наставников, к ним всегда можно обратиться за советом.

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

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

COVID-19 отразился именно на этой части моей работы: сложно вовремя отследить эмоции ребят, уловить настроение и вовремя оказать поддержку, если она нужна.

Как решили проблему?

Мы стали больше проводить встреч p2p, митапов на команды и, безусловно, стараемся разнообразить наш общий досуг, перенеся оффлайн-встречи с коллегами в онлайн.

К примеру, мы уже несколько раз организовывали онлайн-игры (“Квиз, плиз!”, “ЧГК”, “Элиас” и др.), где после самой игры обязательно остается время и на “поболтать”.

Мы активно запускаем разные челленджи внутри компании в инстаграм, проводим новостные рассылки, планируем время по обучению английскому языку.

В планах попробовать собрать ребят на онлайн-тренировки, чтобы держать себя в форме.

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

ЧТО ДАЛЬШЕ.

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

То есть на психологическую составляющую.

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

Пандемия также не повлияла на мой объём работ и я не перестала внедрять те инициативы, которые планировала.

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

После завершения карантина обязательно хотим поучаствовать в качестве спикеров на конференциях для разработчиков (уже не онлайн).

Также много задач по продвижению HR бренда нашей компании, как и внешнего, так и внутреннего. И, конечно, впереди еще много митапов и встреч на всю компанию, чтобы команда, наша команда 4xxi, не чувствовала себя оторванной от компании.

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

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

Во всем том, что доставляет радость, приносит приятные впечатления и хорошее настроение в сложившихся обстоятельствах.

COVID-19 И HR ПРОЦЕССЫ was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

На данный момент многих компаний коснулись масштабные изменения из-за режима пандемии. Кто-то, как многие IT-компании, были более подготовлены. Кто-то — менее.

Команда 4xxi также столкнулась с некоторыми сложностями, но все же оперативно смогла перевести своих сотрудников на удаленных режим работы.

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

Привет, я — Алексей Сырковский, ПМ лид из питерской IT-компании 4xxi, которая разрабатывает крутые и успешные проекты мирового уровня. На сегодняшний день наш штат разработчиков насчитывает около 40 человек, не считая административного блока.

До начала пандемии большая часть сотрудников работала в офисе и только небольшая часть трудилась удаленно. Однако, вот уже больше месяца прошло с того момента, как мы полностью перешли на удаленку — полет, кстати, нормальный =)

Всем, кто привык и любил работать из офиса пришлось перестраиваться и учиться работать из дома. Тут всем советую почитать крутых ребят из BaseCamp. Книга так и называется «Remote. Офис не нужен».

Так что же поменялось с переходом на удаленку:

• Усилили политики безопасности (добавили новые правила для удалении и добавили чек листы для контроля) Кстати, в ближайшее время, часть из них планируем сделать публичными.
• Переход на удаленку позволил нам сократить время, которое команды тратили на митинги в офисе. Личные встречи всегда требовали больших затрат организации, чем сами созвоны.
• Многие вопросы стали решаться в разы быстрее через Slack, а статусы используются активнее самими сотрудниками в корпоративном мессенджере (ушел на обед и т.п.).
• Стали чаще включать видео на созвонах. Это помогает хоть как-то компенсировать нехватку живого общения (забавные истории с дресс кодом и нас не обошли стороной).

Самое главное в текущей ситуации — четкая организация своей работы и работы команды.

В 4xxi все разработчики и менеджеры разделены на отдельные команды. Каждая команда — самостоятельная боевая единица, работающая над своим набором проектов.

Размер и состав команды подобран оптимальным образом: командой рулит ПМ (или несколько ПМов в зависимости от размера команды), нужное количество разработчиков, тех. лид, QA.

Дизайнеры, девопсы, тех. писатели, data scientists — подключаются по необходимости.

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

Для всех команд у нас разработаны общие схемы и инструменты для работы над проектами.

Такие как:

• воркфлоу в таск-трекере (Jira),
• структура хранения базы знаний и документов по проекту (Confluence, Gdrive),
• групповые календари,
• общие схемы CI/CD и тп.

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

ПМы управляют своими командами самостоятельно. Микроменеджмент со стороны ПМ лида или СЕО сводится к минимуму.

Кстати, за последние полгода мы внедрили много классных штук, которые упростили контроль и управление проектами как для руководства, так и для ПМов:

• Централизованная система планирования загрузки команд и отдельных сотрудников.
• Отлаженная система отчётности на базе шаблонов.
• Автоматические расчеты окупаемости (эффективности) проектов (план-факт).
• Шаблоны чек-листов (ведем в Trello): еженедельные, для старта нового проекта и для релизов.
• Внутренняя ERP-система для учета отгулов и отпусков и ревью 360.

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

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

Я думаю, что многие сотрудники и компании по всему миру задумаются о переходе на удаленку после завершения пандемии.

Бизнес и COVID-19 was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

Я продолжаю сталкиваться с тем, что даже опытные дизайнеры интерфейсов ненавидят создавать адаптив, отдавая разработчикам дизайны только под основной экран, 1024, 768 и 320/375. В итоге, у разработчиков возникает множество вопросов о поведении интерфейса в диапазоне между этими числами. Часто верстальщик делает всё на своё усмотрение, после чего дизайнер возмущается видом конечного продукта, не соответствующего его ожиданиям. У верстальщика же просто не было времени или желания задать вопросы дизайнеру. Так что же сделать, чтобы такого не случалось?

Для меня дизайн — это математика. И адаптив яркий тому пример. Он требует много времени на проектировку, но это необходимо. И вот почему:

1. Дизайнер начнёт контролировать количество шаблонов страниц в проекте;
2. Дизайнер начнёт контролировать количество паддингов, шрифтов, размеров элементов и т.д.;
3. Интерфейс станет намного аккуратнее и комфортнее для пользователя;
4. Дизайнеру будет легче поддерживать и развивать интерфейс;
5. У менеджеров и разработчиков не будет возникать вопросов не только с адаптивом, но и с новыми страницами или элементами, которые срочно нужно внедрить, пока дизайнер загружен другой работой или укатил отдыхать;
6. Если у дизайнера несколько проектов одновременно или он возвращается к проекту спустя длительное время после простоя, то вспомнить сетку сайта не составит труда;
7. Если проект улетит другому дизайнеру, то это значительно ускорит его погружение в проект;
8. Дизайнер полюбит делать адаптив, ибо теперь это станет интересной задачей, в которой нужно 10 раз всё рассчитать и продумать, как спроектировать интерфейс за наименьшее количество шагов;
9. Детальная проработка адаптивного дизайна научит дизайнера предусматривать адаптив уже на этапе создания концепции проекта.

Я никогда не придерживаюсь какой-то определенной сетки при создании интерфейсов (типа 8–12 колонок). Сетку диктует вдохновение или контент. В одном случае это может быть хаотичная структура, в другом — строгая, по 3 колонки, с фиксированной шириной и отступами. Но структура всегда должна быть максимально продумана и логична. Каждый пиксель должен играть свою роль.

👉 Правило #1
Забудь об отрисовке адаптива под 1024/768 (планшет) и 320/375 (мобилка). Пусть сетка сама диктует, где и когда ей меняться.

Пример #1. Карусель постов

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

• 400 px — ширина карточки поста;
• 40 px — расстояние между карточками;
• 80 px — расстояние до стрелочек;

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

Суммируя все данные, мы получаем:
[80 + 36 (стрелочка) + 80] + 400 + 40 + 400 + 40 + 400 + [80 + 36 (стрелочка) + 80] = 1672
То есть, с ширины экрана 1672 px мы перестаём растягивать наш контент и тянем экран с помощью увеличения отступов от стрелочек до края окна. Значит, с брейкпоинта 1671 мы начинаем сужать интерфейс.

Сузить данный контент можно 3-мя способами:

• уменьшить карточки постов;
• уменьшить паддинги;
• уменьшить шрифты.

Теперь, ваша задача — рассчитать, до какого предела могут сузиться отступы и карточки, а затем расписать это всё верстальщику.

Сперва можно вдвое сузить расстояния около стрелок, приравняв их к внутренним отступам между карточками постов. После чего мы можем начать сужать карточки.
В изначальном варианте интерфейса у нас были довольно крупные названия постов, мы можем уменьшить их с 30 до 24 px.
Начав сужать контент, мы упрёмся в минимальный допустимый размер карточек, при котором в название и описание поста будет влезать достаточное количество символов. В данном случае, это 320 px.

Сложив все данные, мы узнаем, что минимальная ширина при указанных размерах будет равняться 1272 px. Это наш второй брейкпоинт.

Легендарное правило Mobile First
На заре появления адаптивного дизайна зародилось мнение начинать создание сайтов с размеров под мобильные устройства. Данный способ позволял свести количество функционала и данных на страницах до минимума, предоставляя пользователю только самое необходимое. В своё время издательство A Book Apart даже опубликовало книгу на эту тему (кстати, рекомендую к прочтению).

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

👉 Правило #2
Чем ближе вы к размеру 1000 px, тем больше вам стоит задумываться о том, какой интерфейс вы хотите получить в смартфоне.

С подобными карточками всё просто: мы либо свернем их в карусель, либо дадим списком друг за другом. Я остановлю свой выбор на карусели. На сенсорных устройствах, где почти весь интерфейс свайпится, можно скрыть стрелки прокрутки карточек и оставить page control indicator, который информирует нас о том, что карточек в данном блоке много.

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

Итак, минимальный размер телефона 320 px:

• пускай отступ между карточками не будет превышать 20 px, чтобы текст под карточками не упирался друг в друга;
• мы покажем еще 10 px от следующей карточки в карусели, значит, на карточку остаётся не более 290 px;
• карточку можно прижать прямо к краю экрана, но я бы оставила еще 10 px свободного пространства, чтобы текст под карточкой не упирался в край экрана.

Итог, 280 px.

Если мы сузим текущую карточку до 280, то увидим, что у нас не влезает крупный текст описания в 17 px. Уменьшим размер шрифта до 15.
Экран всё еще довольно широкий, и карточки могут существовать при просторных паддингах в 40 px.
Сложив все минимальные данные, получим третий брейкпоинт — 1000 px.

👉 Правило #3
Рекомендуемые размеры текста контента на мобильных устройствах — 15–17 px. Используйте 12–14 размер только для дополнительной и ненужной информации. Человеку в движении и с расстояния вытянутой руки будет сложно прочесть столь мелкий текст.

👉 Правило #4
Не прижимайте контент к краю экрана. Возьмите запас в 10–30 px (в идеале, 15–20). Довольно сложно прочесть текст, который упирается в экран телефона. Исключением являются картинки и медиа, их можно (и иногда даже нужно) растягивать на всю ширину экрана.

Вернёмся к нашему интерфейсу. В окне меньше 1000 мы можем сжать нашу карусель до 2-х карточек на одном экране и сохранить комфортные паддинги между постами.
Сложив все данные, получим следующую минимальную точку — 680 px.

Кстати, вот как будет выглядеть экран при такой сетке при ширине в 1020 px:

Теперь мы дошли до мобильных устройств. Нашим пятым брейкпоинтом станут все экраны менее 680 px. Мы сузим отступы до края окна и получим удобный слайдер, при минимальных размерах карточек в 280 px.

В итоге, мы получили следующие брейкпоинты изменения интерфейса:
1672, 1272, 1000, 680

У нас нет никаких дыр, мы предусмотрели дизайн интерфейса для абсолютно любого экрана браузера.

👉 Правило #5
В большинстве случаев для адаптива необходимо всего 4–5 брейкпоинтов, в которых элементы или паддинги начинают изменять свои значения.

Голова не кипит ещё? Ок, тогда идём дальше! 🔥

Пример #2. Карточка товара

Попробуем резиновый дизайн. Итак, предположим, у нас есть карточка товара.

• 70% экрана занимают фотографии товара, расстояние между изображениями 10 px;
• 30% занимает описание товара и кнопки действий для пользователя.

Для примера я специально сделала интерфейс, в котором один элемент выходит за края общего контейнера контента (желтая полоса под названием).

Мы хотим, чтобы наш контент комфортно чувствовал себя и не зажимался между фотографиями и краем экрана. Мы дадим ему отступы в 60 px. НО! Так как один элемент выходит за границу общего контента, мы сделаем оптическую обманку: паддинги составляют 60 px, однако в действительности справа он занимает 60 px, а слева — 50 + 10 px (для полоски). Ничего страшного в таком ходе нет, но чем раньше вы сообщите о нём верстальщику, тем лучше. Разработчик не будет рад позже обнаружить подобный «минусовый» элемент. Ему либо придётся переделывать вёрстку, либо ставить минусовые значения. Как правило, дизайнеры ошибочно полагают, что если вылез какой-то кусочек, то пофиг, ничего страшного. Однако это не так.

Рассчитаем минимальный размер экрана, при котором наша сетка будет работать. Текст и фотографии могут сужаться, а вот выбор размера товара и кнопка покупки — ограничены в размерах и занимают 264 px.

[50 + 10] + 264 (выбор размера и кнопка) + 60 = 384
384 = минимальные 30%, значит, весь экран не должен быть меньше 1152 px. Дополнительно дадим погрешность на рендеринг шрифта в кнопках (в браузере и в граф. редакторах он может сильно отличаться). Округлим нашу ширину до 1200 px.

Начинаем сужать. При соотношении 70:30 мы можем получить результат, при котором фотографии будут слишком крупными, а места для текста и кнопок не останется. Переиграем пропорции сетки:

• 60% для фотографий;
• 40% для описания;
• уменьшим паддинги с 60 до 40;
• уменьшим шрифт заголовка с 48 до 36.

Считаем:
[30 + 10] + 264 + 40 = 344
344 = минимальные 40%, значит, минимальный экран для текущей сетки 860, добавим погрешность. Итог, вторая точка 880 px.

Снова изменим пропорции, чтобы избежать ситуации, при которой описание не будет влезать в экран. Новые пропорции 1:1:

• 50% для фотографий в один столбик;
• 50% для описания;
• оставляем прежние горизонтальные паддинги;
• нам пора задуматься о мобилках. Чем уже экран, тем меньше его высота. Пришло время сужать вертикальные паддинги.

Считаем:
[30 + 10] + 264 + 40 = 344
344 = минимальные 50%, минимальная ширина экрана для данной сетки — 688. Добавим погрешность, третий брейкпоинт — 690 px.

👉 Правило #6
В среднем, зона клика пальцем составляет 44–48 px, минимум 40. Это значит, что все кликабельные элементы (иконки, ссылки, кнопки) должны находиться на безопасном расстоянии друг от друга, чтобы по ним можно было без труда попасть пальцем, не зацепив при этом соседний элемент, когда нажимая на одну иконку, пользователь может вызвать соседнее действие. Это раздражает и требует от пользователя дополнительных усилий и действий, таких как отмены или возврата.

Вернёмся к нашему интерфейсу

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

Продолжим сжимать нашу сетку при пропорциях 1:1:

• уменьшим отступы с 40 до 20;
• уменьшим размер заголовка с 36 до 24.

Уменьшить длину кнопок в процессе адаптации экрана под мобильные устройства можно тремя способами:

• убрать из кнопки иконку и оставить только текст;
• убрать текст и оставить иконку;
• сократить количество слов в кнопке.

Определяющим фактором будет сама кнопка.

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

Теперь размер контейнера с полем выбора размера и кнопкой без иконки составляет 238 px.

Считаем:
[10 + 10] + 238 + 20 = 278
278 = минимальные 50%, минимальный размер экрана для сетки 556. Заложим погрешность, наша четвёртая точка — 570 px.

👉 Правило #7
При создании адаптива можно обрезать данные в кнопках. Если иконка достаточно информативна и может существовать сама по себе, можно убрать текст. Если без текста значение иконки определить сложно, лучше убрать иконку и оставить текст. В случае с кнопкой «Добавить в корзину» нам важнее донести до пользователя глагол ключевого действия. «Что сделать? Купить!». Иконка корзинки подобной ассоциации не вызовет, а вот глагол — да.

Итак, мы дошли до размеров под мобильные устройства

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

Для мобилок мы можем ограничить максимальную ширину фотографии до 520 px. Таким образом, она не будет заполнять весь экран, а у нас останется место для описания.

В итоге, у нас получилсь такие точки изменения интерфейса:
1200, 880, 690, 570

В статье уже слишком много данных, поэтому следующие примеры я опишу очень кратко.

Пример #3. Ещё одна резиновая сетка

Я возьму популярную сетку из 3-х колонок контента. Например, в левой колонке содержится список категорий заметок, в центральной — список заметок в выбранной категории, а в правой колонке можно просмотреть выбранную заметку.

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

👉 Правило #8
Старайтесь держать контент в центральной зоне. Он должен занимать главное место на экране и не должен заставлять пользователей слишком сильно поворачивать голову.

Привяжем наши колонки к процентам:

• навигация по сайту будет занимать 20%;
• список заметок в разделе — 30%;
• просмотр заметки — 50%.

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

Кстати, преимущество этой сетки состоит в том, что текст в правой колонке на экране величиной 1920 px будет занимать всего 840 px, что при достаточно крупном шрифте будет удобно для чтения. Для сохранения читабельности текста на экранах больших размеров можно наращивать паддинги внутри блоков.

Мы можем начать сужение страницы с уменьшения паддингов.

Дальше мы можем уменьшить экран, удалив дополнительные информационные элементы (например, иконки). Перенос навигации в «бургер» позволит убрать левую колонку.

Наконец, для мобильных устройств мы оставим на экране только просмотр заметки. Главное, не забыть сделать кнопку возврата на предыдущий шаг по каталогу сайта (список заметок).

Пример #4. Плитка

Еще одна популярная сетка интерфейсов, особенно для дашбордов.

Итак, у нас есть интерфейс с плиточной структурой. Сперва займемся сжатием:

• определим, при какой ширине карточек данные будут влезать в интерфейс, и уменьшим карточки до данной ширины;
• уменьшим отступы между карточками и до края браузера;
• переставим порядок карточек сначала из 3-х в 2 ряда, затем в 1 ряд;
• свернём ненужные карточки и малоинформативные карточки. Чем ближе мы к мобильному устройству, тем меньше данных должно быть. Если какие-то из карточек состоят из графиков, то большое количество контента затруднит загрузку страницы;
• сгруппируем карточки. Предположим, что в двух карточках имеются схожие графики или контент. Мы можем их совместить, повесив табы на блок, тем самым и уменьшив высоту экрана, и уменьшив количество элементов, необходимых для загрузки страницы.

👉 Правило #9
Не забывайте о скорости загрузки страницы и мобильном трафике. Элементы интерфейса можно растягивать в разных пропорциях, какие-то из них можно сворачивать или прятать. Для уменьшения высоты страницы под сенсорные устройства можно уменьшить количество данных в блоке. Например, показывать не 20 последних событий, а только 10.

Что можно сделать для больших экранов:

• увеличить паддинги;
• растянуть карточки;
• растянуть только одну колонку карточек, карточки на экране могут увеличиваться непропорционально.

И ещё несколько небольших правил о поведении интерфейса. Например, о всплывающих подсказках и т.д.

👉 Правило #10
Не забывайте о том, что на сенсорных экранах нет ховеров. Переведите их в клик или замените другими элементами.

👉 Правило #11
При разработке интерфейса необходимо использовать самые длинные имена, названия постов и т.д. Покажите, что произойдет, если текст перестанет влезать в свой блок: текст может обрезаться или перейти на следующую строку, а шрифт — уменьшиться.

👉 Правило #12
Укажите, куда именно вернётся пользователь при нажатии кнопки возврата: к поиску, к каталогу, к списку аккаунтов и т.д.

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

👉 Правило #14
Не отдаляйте элементы одного блока на слишком большое расстояние друг от друга. Пользователь может их потерять или не заметить.

👉 Правило #15
Просторные отступы привлекают внимание, а также увеличивают скорость чтения и поиска взглядом по странице.

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

Images and icons: vsworld.ru, unsplash.com, flaticon.com

Адаптивный дизайн: теория и практика was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

В этом году Вконтакте предложило для выбора проекта 6 направлений: технологии, медиа, образование, культура, благотворительность и городская среда. Кроме этого было задействовано 14 компаний–партнёров, которые предложили решить одну из их задач.

От 4xxi из желающих мы сформировали 3 команды и отправили заявки. Прошли только две. Обе команды выбрали для себя образование. В целом, наша компания любит образовательные проекты, работает над ними и даже делает свои.

Подготовка

В нашей команде было 4 человека:

• Я, дизайнер;
• Кристина, фронтенд-разработчик;
• Максим, бэкэнд-разработчик и идеолог проекта;
• Миша, андроид-разработчик.

Мы решили сделать свой проект, затрагивающий проблему грамотности русского человека. Эта тема актуальна для любого жителя нашей страны, ведь каждый из нас делает ошибки, плохо знает правила и устал от постоянных «мне нравитЬся твой дизайн» в сообщениях.

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

На этапе подготовки мы обозначили необходимый стек технологий, набросали схему проекта, чтобы понять его масштабы и несколько часов потратили на создание базы заданий для первой версии сервиса. Придумали себе двоякое название The Russian Rules и запилили командные футболки с «Ѣ!». :)

Хакатон. День первый. Пятница

В этом году Хакатон проводился, на секундочку, в главном штабе Эрмитажа!! Регистрация на мероприятие открылась в пятницу в 14 часов. После небольшой вводной речи организаторов и партнёров мы сели за работу в 17 часов. Именно от этой точки и отсчитываются 42 часа чистого кодинга.

В мероприятии участвовало более 100 проектов и более 400 человек. Организаторы изолировали холлы музея перегородками, разбили его на направления и поставили длинные столы, за которыми все и сидели. Честно говоря, было довольно тесно. Наш стол стоял у стены и мне приходилось разгонять всех участников на маршруте, ибо пройти между ними было нереально, иногда и вообще ныряла под столом. Стул упирался в сидящего позади человека, комп в сидящего напротив, а драка ногами за территорию под столом не утихала до самого окончания. В этой тесноте был и свой плюс: без труда заводишь знакомства и общения с соседями. Помещение без окон тоже сыграло на руку, не было понимания и ощущения день/ночь, что не влияло на продуктивность.

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

С наступлением ночи большинство участников разбежалось по домам или отключилось прямо на рабочем месте, не блокируя комп. Многие предусмотрительно взяли с собой спальные мешки (гениальные люди). Вообще, было приятным ощущение ночёвки в одном из крупнейших музеев мира. Когда ещё и у кого может быть такая возможность, как отключиться на его полу, ночью выйти прогуляться по Дворцовой площади, найти еды и пойти поедать её в Эрмитаже, не отрываясь от работы за компом? Звучит романтично, да?))

Наша команда проработала до 6 утра, кроме Максима, который после поезда убежал спать домой еще до разводки мостов. Утром мы решили сделать перерыв, немного поспать и уже потом устроить марш-бросок без сна до самого финала.

Итог работы с 17 часов вечера до 6 утра:

Кристина:
Готовила платформу для фронта. Начала делать лэйауты проекта и верстать первые экраны.

Миша:
Создавал базовую архитектуру проекта, начал делать библиотеку и сделал устойчивую авторизацию (повод для гордости, но о нём никто не узнает, ибо авторизацию мы потом урезали до входа через ВК). Делил приложение на слои, делал DI, понимая что с каждым часом его архитектура была менее похожа на то, что он ожидал изначально. Много времени потратил на ненужные вещи типа парса данных, на которые можно было бы забить. Слоёв архитектуры становилось всё меньше и меньше, и к 2-м часам ночи красивый код был послан куда подальше. Несмотря ни на что, Миша был уверен в том, что успеет закончить проект к 11 утра воскресенья.

Макс:
Настраивал сервак, который был необходим для деплоя и домена. Разворачивал симфони-приложение для фронта. Делал всё для того, чтобы ребята не зависели от него, и вскоре начал кодить.

Я:
Работала над дизайном. Урезала набор элементов до минимума, сведя сервис к линейной навигации, в которой мы словно за ручку берём юзера и ведём его прямо, не давая свернуть и отвлекаться на ненужные вещи. Определилась с концепцией и начала делать немного игровой и весёлый дизайн. Отрисовала 4 экрана веба и 2 андроида, которые сразу улетели в вёрстку, что потом довольно сильно усложнило мне жизнь, ведь теперь любые перемены в дизайне несли за собой дополнительную работу для верстальщика, а дизайн меня бесил и сильно. Не нравился, казалось, что всё не то, хотя ребята говорили, что им нравится. Прилично времени потратила на «поиграться в цвета» в надежде, что это может спасти ситуацию.

День второй. Суббота

«Мы проснулись с новым дизайном», — Макс.

Идея устроить перерыв на сон звучала прикольно, но на практике дала сбой. Уснула я только с 3-го захода. Первый закончился для меня тем, что через 20 минут я подскочила, начала рисовать новый дизайн, стараясь свести к минимуму последствия редизайна для верстальщика. Пришлось делать крайние svg-шки того же размера, что и облака в первой версии, сохранять структуру и прочие мелочи. Вторая попытка поспать закончилась для меня опять ноутом в руках и правками по цветам и шрифтам. И только с третьего раза я уснула на полтора часа. Позже меня озадачил мой выбор цветов, не припомню, чтобы когда-либо вообще использовала небесный, зеленый, желтый и белый в одном флаконе, вернувшись на хакатон и увидев здание Зимнего дворца напротив, в общем-то, я поняла «откуда ноги растут». Отличный пример дизайн-мышления в действии. Очевидно, разум в полусонном состоянии сам сгенерировал подходящий выбор, связав между собой «образование», «культура» и «русский». :)

В итоге мы проспали:

Миша — 2 часа, Кристина — 2 часа, Я—1,5 часа и Макс—6 часов.

День второй. Бизнес-линч

К 14:30 мы все вернулись в Эрмитаж на бизнес-линч с Командой. Ребята приняли нашу идею с воодушевлением, им понравился проект, дизайн и мы сами. Отметили фишку с «Ѣ!» в логотипе и прочие мелочи. Подкинули идею развиваться в социальном направлении, добавить к уровням систему рейтингов и прочее. Общение с ними пустило по венам не слабую долю мотивацию, и с улыбками мы побежали работать дальше. Спасибо вам, ребята! Вы были в тысячи раз лучше того, с чем нам пришлось столкнуться на следующий день. ;)

После бизнес-линча мы погрузились в работу до 11 часов следующего дня с редкими перерывами на еду и поисками кофе. Из нашей команды не спал никто.

Итог, к утру воскресенья:

Я:
Нарисовала новый дизайн. Пришлось менять логику работы ответов в экзаменах. Всплыли задания, в которых перед отправкой ответа необходимо было перепроверить себя, что исключило автоматический переход к следующему вопросу. Шлифовала весь процесс работы экзаменов, интервального повторения и изучения правил. В итоге, только к часу ночи был готов весь веб. Андроид окончательно улетел в разработку в районе 4–х часов утра. Пришлось использовать некоторые элементы с первой версии дизайна, без перерисовки стилистики, ибо времени уже не хватало. С ужасом поняла, что за прошедшие полтора дня выпила 4 литра кофе. Осознала, что когнитивные способности стремительно падают. Отвлекаясь на вопросы/ответы, возвращаясь к монитору, несколько секунд вспоминала, что я делала вообще. В какие-то моменты мозг совсем стал туго соображать, и я побежала раскидывать корпоративные шоколадки 4xxi по столам других участников, оживляя обстановку вокруг. Кстати, всё остальное время на волне азарта разум без сбоев в привычном режиме решал по 3–4 задачи одновременно и быстро фокусировался. :)

Кристина:
Переделывала 100500 раз вёрстку из-за дизайна и прочих правок/доработок. Чутка поджеэсила, чутка поджекьюрила. Ночью потеряла мотивацию, понимая, что мы не успеваем, ведь к 12 ночи было готово 1,5 экрана. Я не успела сделать Кристине в каком-либо виде адаптивный дизайн, в итоге выкручивались уже чисто её силами и моими небольшими комментариями.

Миша
Часов в 17 понял что ничего не успеет. В вечер субботы поменял базу данных с реляционной на документоориентированную. Если бы не потратил уйму времени на базу в начале, то все было бы круто.

«Был кодинг, была боль, всё как в тумане», — Миша.

Макс
После линча уверен был, что всё успеваем, часов в 19 это изменилось. Часа в 23 доделал API и отдал Андроиду. Тут же понял, что не будет спать этой ночью, ибо дофига работы.

День третий. Последние часы

Я:
Несколько раз попыталась уснуть, но всё же переключилась на тестирование сайта и мелкие доработки. Играясь с уже почти готовым проектом, была уверена в том, что у нас есть реальный шанс на победу, так как мы запилили действительно классную и полезную для общества штуку. За время тестирования уже освоила новое для себя правило.))

Кристина:
К утру начался хардкор и фикс багов, летящих со всех сторон. В итоге к 11 часам имела стабильно работающий сайт с адаптивной вёрсткой под мобилку.

Миша
Отчаянно кодил. Чувствовал себя довольно фигово, но к 11 часам были готовы авторизация, профиль и экзамен.

«С каждым часом мой код становился всё хуже и хуже», — Миша.

Макс
В начале ночи уехал домой с лекарствами для простывшей девушки. Продолжал работать из дома и вернулся за 3 часа до дедлайна. Херачил всё что придется: баги и прочее.

Презентация проекта жюри, которому нас-рать

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

В судействе нашего трека было 3 человека: какая-то девушка, спокойный и позитивный парень из партнёрского проекта «Сириус» и весёлый Сева из ВК. Девушка не представилась и её личность для нас осталась загадкой.

На защиту было отведено 3 минуты нашей речи и 2 минуты на их вопросы. Маловато, да? А что если я вам скажу, что мы не просидели там и этих 5 минут?

Организаторы заявили, что будет 7 критериев оценки. По факту вот с чем мы столкнулись:

1. Уникальность/актуальность идеи проекта:

• Жюри, даже толком не успев услышать что-либо о нашем проекте, перебило нас и начало сыпать вопросами из рубрики «Как вы будете продвигать продукт?». Мы даже не успели рассказать о том, что разбили обучение на 3 уровня правил: крайне необходимые для любого человека, более расширенные и уже совсем крутые, чтобы чувствовать себя образованным и умным человеком. Плюс к этому добавили игровую механику и интервальное повторение на проверку уже усвоенных правил, а ещё придумали всякие плюшки и фичи о русском языке, открывающиеся после успешного выполнения заданий.

2. Соответствие поставленной в кейсе задаче:

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

3. Практическая применимость, возможность внедрения и использования:

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

4. Дизайн и функциональность (наглядность, понятность интерфейса):

• Мы не успели что-либо показать. За эти часы были сделаны 2 концепции дизайна и 42 экрана. Интерфейс обладал простой линейной навигаций и не содержал никаких лишних и ненужных элементов для пользователя. Внедрить дизайн успели на весь веб и почти на весь андроид.

5. Техническая (технологическая) реализуемость прототипа:

• Жюри не посмотрели сайт дальше 2-х экранов (и те издалека). Не увидели объём сделанной работы. О существовании Андроида мы успели сказать только вскользь (из-за чего позже Миша получил почётное звание «Героя невидимого фронта»). Они даже не узнали и о том, что всю текущую базу правил и заданий мы создавали сами.

6. Качество представления информации и проведения презентации прототипа:

• Даже не знаю, что тут сказать, учитывая, что нас открыто «завалили», ведь за вопросами мы не успевали сказать ничего важного и нужного. Только за час — полтора до окончания кодинга мы смогли взяться за презентацию. Сделали её, буквально, на коленках. Хотя говорят, мол это самое важное. Хз, что может быть важнее реально работающего продукта?!

7. Законченность:

• У нас есть полностью рабочий клёвый сайт и половина андроида.

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

Кстати, наша вторая команда тоже была в треке образования и тоже, мягко говоря, в шоке от манеры общения жюри. Ребята из организаторов, может стоит доработать формат защиты и презентации?

Послевкусие

После презентации я показала наш проект нескольким участникам хакатона. Ребята иронично усмехались над моей фразой-предупреждением о нашем маленьком баге, в то время как они сами молились о том, чтобы сервис не отвалился при демонстрации из-за огромного количества «жуков». Удивились и тому, что мы успели запилить ВЕСЬ классный дизайн (и не один). Сделать 2 платформы. Были в шоке и от того, что мы сами сделали базу заданий и прочее. Короче, нас хвалили. В общем, итог хакатона прост: хочешь победить — решай партнёрские кейсы, остальное организаторам неинтересно.

Но в конце концов, у нас сейчас есть работающий продукт и мы реально гордимся собой. Мы не спали 55 часов. Работали в одном здании с легендарными картинами известных художников. В перерыве бегали между толпами посетителей, которые не понимали, что мы тут делаем с ноутами и в таком количестве. Бежали по Дворцовой, огибая толпы туристов, опаздывая на бизнес-линч в музее. В прогулках за кофе, успевали потереть пальчики Атлантов и ночевали в одном из зданий главного музея страны в компании таких же психов, как и мы сами. Ну круто, же?!)))

Отдельное спасибо хочется сказать:

• Вконтакте за организацию такого крутого мероприятия. Несмотря на поведение дамы в жюри, мы с радостью попробуем себя в этом деле снова;
• Волонтёрам в огромном количестве, которые всегда помогали с доброй улыбкой и не забывали напомнить нам о том, что пора пойти кушать или бежать на бизнес-линч;
• Эрмитажу за уникальную возможность провести здесь почти 3 дня;
• Участникам хакатона, которые подбадривали друг друга, танцевали под музыку и всячески разделяли с нами это мазохистское мероприятие. Ещё увидимся!

Добавляйтесь в социалках, везде я /mawsik. Кстати, совсем скоро устраиваю очередную сходку для дизайнеров Design Challenge (этакий маленький хакатон для дизайнеров), ещё есть время вписаться.

А сайт живёт и процветает. Мы добьём его, пофиксим баги, доработаем адаптив и функционал, и будем развивать. Включайтесь! :)

P. S. Если найдете какие-то баги или ошибки, не стесняйтесь, пишите в личку.

P. P. S. Ребята из Вконтакте, имена с маленькой буквы на бейджах мероприятия, вы серьезно?!))

Art of Coding глазами участника was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

При работе на долгоживущих проектах с насыщенной функциональностью разработчик неизбежно сталкивается с проблемой организации кода и доступности его для коллег. Адаптация новых членов команды тем проще, чем адекватнее и быстрее можно изложить суть проекта, логику и иерархию компонентов. Как известно, код чаще читают, чем пишут, и пишут его для людей. О разных подходах по организации кода в проекте существует немало обсуждений и практик. Очевидно, каждая команда с опытом разработки применяет свой “выстраданный” набор best practices.

Ниже я приведу некоторые идеи и принципы структурирования кода, которых придерживается моя команда при планировании новых фичей и рефакторинге на трехлетнем проекте SPA.

1. Feature first подход

Само слово feature (или просто “фича”) подразумевает для разработчика, знакомого с git-flow, некоторый законченный объем функционала, задачу. То же и в проекте. Feature — единица проекта, на основе разнообразия которых строится продукт. Feature-first предполагает, что все компоненты, объединенные общей логикой и интерфейсом, являются фичей и располагаются в одном месте. Открывая папку feature/Profile, мы находим весь код, относящийся к функционалу профиля пользователя и сразу получаем представление, как это работает. На тему feature-first подробнее написано в статьях.

2. Ducks

Подход к организации redux-приложений, подразумевающий отказ от типичной организации кода c разделением на actions, constants, reducers. Сведение всей логики управления состоянием redux исключает лишнюю навигацию по папкам и множество однотипных открытых файлов.

Модуль ducks должен удовлетворять нескольким требованиям:

• экспортировать функцию-редьюсер
• экспортировать action-creators как функции
• включать action types в формате “module/reducer/ACTION_TYPE”
• может экспортировать action types, если они необходимы внешним “слушателям”.

Предлагаю взглянуть на структуру организации кода на схеме и пройти от корня до компонента, от feature-first к ducks в отдельной фиче.

Cтруктура проекта Feature-first + redux-ducks.

Корневая папка проекта /

Здесь лежат все наши конфиги webpack, eslint, package.json и все остальное, связанное со сборкой приложения.

/src/app

Точка входа проекта /src/app/index.js. Здесь же в /src/app/store.js мы определяем store, в этой же папке redux-saga middleware. Если вы собираете несколько бандлов с разными точками входа, предположим, App авторизации (authApp) и основное приложение mainApp, будем использовать две разные папки, со всем остальным разберется webpack, если мы верно сконфигурируем пути в его config. В наших проектах используется styled-components, и в примере выше файл с injectGlobal стилей приложения.

/src/common

Любой переиспользуемый код, будь то селекторы или обычные компоненты input. Принцип прост: если есть что-то, что может использоваться в нескольких фичах, должно находится в /common. Например, user settings permissions. Константы и типы (в случае использования Flow) — также занимают свое место. Часто для таких ресурсов встречается именование shared, что также отражает суть. Чему быть, а чему нет в /common определить достаточно просто. Все переиспользуемые компоненты, весь повторно используемый код, будь то селекторы, helper-functions или утилиты для работы со строками/массивами/датами. Все, что требует, к примеру, moment.js выносится в утилиты, и moment не импортируется нигде и никогда внутри фич. Компоненты-фичи, имеющие свой редьюсер, также отправляются в common, к примеру — прелоадеры загрузки файлов. Настало время показать флоу экспорта и импорта на схеме:

Отмечу, что import между фичами запрещен.

Таким образом, все, что вам вдруг понадобилось из одной фичи в другой — выносится в /common. Если это вся фича, то наступает время плохих новостей, и пора подумать об архитектуре, правильно ли вы ее понимаете.

В моем текущем проекте — насыщенном фичами сервисе по управлению нештатными ситуациями — существует огромный объем логики, связанный с CRUD основных сущностей, управлением их состоянием, обновлением. Типовые операции могут быть использованы для обновления различных типов сущностей, и, как следствие, использоваться где угодно. Все связанное с этим универсальным функционалом поместилось в /common. Пример показывает, что здесь мы включаем не исключительно “тупые компоненты” и утилки, а выносим переиспользуемую в рамках проекта логику и инструменты.

/common/components

Здесь располагаем все “тупые” компоненты — buttons, inputs. В /common/<SomeComponent>— компоненты-контейнеры. При этом стоит обращать внимание на использование относительных путей импорта вида

import { SomeComponent } from “../SomeComponent”;

если вы используете их на одном уровне иерархии.

Как показала практика, использование такой организации файлов позволяет более эффективно избегать появления круговых зависимостей (circular dependencies), упрощает понимание кода, облегчает использование алиасов путей.

/features

В идеальном мире это была бы именно та папка, где сконцентрирована вся разработка в текущих спринтах. Фича собрана в одно целое, экспортируя наружу только компонент фичи, редьюсер и saga (redux-saga middleware).

Feature-first позволяет нам собрать всю разработку в одном месте и писать чистый, удобочитаемый код. index.js содержит всего 3 экспорта — компонент из container (единственный connected компонент в фиче), редьюсер из ducks и saga. Конечно, никакого ограничения здесь нет, но не будем забывать: “Усложнять просто, упрощать сложно.”

Глубже в feature — redux ducks

Как я сказал выше, redux-ducks подход позволяет собрать код, относящийся к управлению состоянием, в одном месте. Разбивая проект на фичи преимущества такого подхода становятся сразу очевидны. Стоит заметить несколько нюансов стиля, к которому мы пришли в течение длительной работы над проектом с большим количеством legacy и переписыванием многих фич. Хотя в ducks рекомендуется экспортировать редьюсер как default export, мы отказались от такого решения не только в данном случае, но и вообще в компонентах. Несколько здравых аргументов в пользу отказа от default export изложены в короткой статье, скажу лишь, что среди них исключение вероятности импорта под другим именем и улучшенная работа tree shaking. Использование префикса в нейминге фичи — рекомендуемая практика в хоть сколько-то больших проектах. Это позволит избежать путаницы в одинаковых константах вроде “FETCH_DATA” и упрощает дебаг в Redux DevTools, тогда “feature/SOME_ACTION” позволяет фильтровать экшны и с первого взгляда понимать, к чему они относятся. Кроме этого, мы пришли к унифицированному определению payload как объекта в action-creator, а конкретная его структура описана внутри. Нейминг в одном стиле позволяет абстрагироваться от конкретных параметров и логика становится более очевидной для восприятия при чтении кода.

Используя Feature-first и redux-ducks в рамках одной фичи у нас есть лишь один connect — в /feature/container. Во все компоненты ниже props приходят от родительского. В таком случае архитектура store приводится к “плоскому” виду, без глубокой вложенности.

Окей, а что, если у меня огромная фича? К примеру, интерфейс настроек пользователя с кучей возможностей.

Состояние одной фичи используется в другой? Тогда в /common/selectors добавляем селектор для /feature. Фича настроек пользовательского аккаунта используется для управления настройками, но само получение user profile и помещение активных settings в store может выполняться в common/Profile. В любом случае в /common/selectors/profile.js должны быть написаны последовательные селекторы для доступа к state.profile.settings и использования их в любой части приложения.

Экшн одной фичи используется в другой? Время налить кофе и подумать над архитектурой приложения.

В кратком изложении я опустил вопросы тестирования и типизации. Хотя очевидно, что они отлично вливаются в такую систему и декомпозиция играет на руку. Будет отлично, если какие-то из рассмотренных принципов организации кода окажутся вам полезными, а еще лучше, если в комментариях вы поделитесь своими решениями.

В завершение небольшая статья о ducks по существу, и еще один пример реализации структуры.

Happy coding!

Организация кода в масштабных React проектах. was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.

Предыстория

Привет! Я — Маша, Арт-директор компании 4xxi. Весной я поняла, что мне и нашим дизайнерам, чтобы не перегореть, необходима какая-то разгрузка от постоянной работы над гигантскими и сложными интерфейсами. Иногда творческой натуре необходимо порисовать что-то просто для души. Красивое, простое, без заморочек. Иногда хочется порисовать и нечто новое, дабы не терять скиллы в определенных направлениях и сферах дизайна. И я решила организовать для нас своего рода Design Challenge.

Идея очень проста: в выходной день, в свободное от работы время, мы собираемся в офисе. Я даю тематику проекта и мы расходимся по своим «норкам» на несколько часов. Полностью сами продумываем продукт проекта, идею, аудиторию, фичи. Рисуем в стилистике какой хотим. В общем, делаем что хотим для себя, для души. После чего собираемся и обсуждаем работы друг друга.

Первый Design Challenge зашёл нам отлично. Мы отвлеклись, взбодрились, вдохновились на новые подвиги. Результаты нашей работы раскрывать пока не буду, потому как идея продукта была с воодушевлением принята нашим CEO, и мы хотим реализовать это приложение.

Когда я рассказала об этом событии нескольким знакомым дизайнерам, им оно очень понравилось и они захотели присоединиться к нам на следующий заход. Я решила, что было бы прикольно собрать вообще разных дизайнеров, разного уровня, знакомых и незнакомых и замутить своего рода первый открытый Design Challenge 4xxi. Наш СЕО поддержал мою инициативу. Я кинула клич в соцсетях, набрала группу из 11 человек и назначила день. По опыту работы на курсах дизайна знаю, что большие группы — зло. На обсуждение макетов больше 10 человек может уйти несколько часов, что скажется на физическом состоянии и настроении участников. А 10–11 в самый раз :)

Задача

Прежде чем формулировать задание необходимо понять чего мы хотим от Design Challenge:

• порисовать для души;
• поработать над чем-то новым и интересным;
• поработать над маленьким проектом;
• поработать над своими UI/UX скиллами;
• поработать над своим бизнес-мышлением, продумать продукт с нуля без заказчиков, без спецификаций, без ТЗ
• не ограничивать участников в креативе и полете мыслей как в визуальной составляющей продукта, так и в функциональной;
• выделить на работу не больше 5–6 часов;
• получить фидбек по своей работе от других участников;
• никаких призов мест и наград, чтобы все участники чувствовали себя в равных условиях без конкуренции.

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

Задание:
Отрисовать мобильное приложения для фестиваля кино или мультифильмов. Участники должны придумать и продумать сами идею кинофестиваля, формат его проведения, место, условия посещения, что должно быть в приложении, чем будут заниматься участники на фестивале и так далее. Всё полностью лежит на фантазии участников.

• на работу ушло 4,5–3,5 часа (не все участники пришли вовремя);
• на обсуждение проектов ушло 1,5 часа;
• съедено 6 пицц, 3 осталось в подарок разработчикам на завтрак;
• все участники ушли с улыбками, довольные, с новыми знаниями и с желанием посетить следующий Design Challenge;
• часть участников влюбилась в наш офис 4xxi;
• учтены пожелания по улучшению организации в следующий раз.

: : : А теперь подробнее о результатах работы каждого из дизайнеров. Начнём с новичков. : : :

Валерия

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

Илья

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

Мария

У Маши нет опыта дизайна мобильных приложений, это её первая работа, которую она посвятила авторскому кино. В целом, работа аккуратная, но сильно сказывается опыт работы только с веб-интерфейсами: мелкие шрифты, стандартная структура расписания (как новостная лента). Отдельно отметили для Марии, что в случае с мобильными приложениями в навигации нельзя терять возврат к предыдущим экранам и выносить кнопки действия войти/регистрация в Nav Bar.
На мой взгляд для первой работы Маша очень постаралась и ей теперь есть над чем и как работать дальше. Она получила для себя большой толчок и мотивацию к дальнейшим успехам. (удачи, Маша!)
Профиль Маши

Иван

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

Тата

Да, её действительно зовут Тата!) Очень креативная и талантливая девушка с личным термосом горячего Улун. На мой взгляд у Таты отличное чувство вкуса. Она выбрала для себя жанр Нуар и смогла поддержать его в интерфейсе приложения через цвета, интересную типографику и работу с пространством. Грамотная подача элементов интерфейса. Отдельно отмечу, что у Таты до этого момента не было опыта работы с мобильными интерфейсами. (Круто, да?)
Плюс ко всему Тата успела сделать небольшую анимацию — времяубивалку для посетителей фестиваля. Если им будет скучно или нечем заняться, они могут просто погонять «волны» на своём экране :)
Профиль Таты

: : : Более опытные дизайнеры : : :

Глеб

Глеб создал приложение фестиваля эротического кино с возможностью знакомств между участниками прямо на фестивале. За 3,5 часа Глеб отрисовал полностью весь флоу продукта, около 15 экранов, тем самым дав акцент в работе на UX и проектирование сервиса больше, чем на его визуальную составляющую.
Для функционала знакомств Глеб взял за основу Tinder, сжав весь его функционал только до свайпа карточек пользователей. При совпадении положительных ответов система предлагает варианты дальнейшего развития событий, участники могут встретиться на территории фестиваля или найти друг друга в залах.
Профиль Глеба

Егор

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

Ольга

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

Работа дизайнера 4xxi Екатерины

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

И последнее, моя работа

Я безмерно люблю Чарли Чаплина и решила посвятить свой фестиваль этому великому человеку. Идея была в том, что на протяжении нескольких недель в разных точках города можно посмотреть его картины. Я не стала отрисовывать каталог фильмов, расписание или карту с точками локации, а дала больше волю творчеству, дабы порисовать что-то красивое и приятное.
Весьма приличную часть времени я затратила на фотообработку, а весь функционал приложения сжала до 4-х составляющих: список фильмов (расписание), qr-коды купленных билетов (свайпятся в рамках одного экрана), цитатник его лучших фраз и приложений (оформленный в духе заставок немного кино, меняются рандомно по клику на refresh), и биография Чаплина (доступна по свайпу вниз с главного экрана).
Сначала была мысль сделать все черно-белым, но мне это показалось слишком грустным ведь работы Чаплина полны юмора, иронии, добра и яркого цвета, несмотря на черно-белую киноленту.

На этом всё. Было безумно приятно, что всем участникам понравилось сие мероприятие. Если хотите поучаствовать в следующем, пишите мне в фейсбуке, добавлю вас в список.

Ах да, локация СПБ. Офис 4xxi на Горьковской. Только офлайн, в одном рабочем пространстве на равных условиях. :)

Design Challenge 4xxi #2 was originally published in Блог компании 4xxi: FinTech, EdTech и разработка стартапов on Medium, where people are continuing the conversation by highlighting and responding to this story.