«Менеджер должен понимать, чем живут программисты и дизайнеры»: как отбирать и обучать руководителей проектов

Менеджеры проектов — это ключевые сотрудники в команде. На их плечах лежит основа успеха компании. 5 лет назад мы изменили подход к мотивации и обучению руководителей проектов. Рассказываю, как отбирал сотрудников, и как сейчас устроена их работа в агентстве.

Nineseven.ru специализируется на разработке и поддержке интернет-магазинов для крупных e-commerce проектов. Агентство существует уже 14 лет и за это время пережило немало перемен. Мы открылись в 2010 году, начав работу командой из трех человек и 563 долларами начального капитала, а наш первый офис был всего 5 кв. метров.

Сначала работа агентства была построена хаотично: мы брали заказы на FL.ru, а бухгалтерия велась в записной книжке. В 2012 году начали появляться первые небольшие белорусские заказчики, а с 2013 года пошел ощутимый рост. Мы все еще концентрировались на дизайне, но стали активнее браться за разработку. Однако проблема с финансовым учетом все еще не была решена, а с позиционированием и продажами дела шли плохо.

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

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

К 2019 году «успешный и автономный» бизнес Nineseven практически испустил дух без моего надзора. На зарплаты не хватало 10 000 долларов. Я собрал команду в офисе и сказал, что практически всем нужно уволиться — сейчас денег нет, но потихоньку будем рассчитываться. Так штат из 15 человек сократился до 4, остались только менеджеры. Офис из кареты на 120 квадратов превратился в тыкву на 32.

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

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

Также дизайн — это история про разовые проекты. Заказчику не нужны постоянные доработки и поддержка. Получил результат и ушел. Приходилось постоянно генерировать поток клиентов, чтобы хоть как-то выживать. Анализ проектов показал, что интернет-магазины — самые долгоиграющие проекты, поэтому фокус сместился на разработку и работу с конечным продуктом для клиентов из e-com. Мы сделали упор на наш опыт в e-commerce проекте МТС.

После этих реформ 2019 года мы начали расти и увеличили оборот с 300 000 до 700 000 долларов к 2023 году.

Однако на этом наши изменения не закончились. «Под капотом» работы команды оказалось еще немало проблем.

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

Многие дизайнеры про верстку знают минимум — могут отличить друг от друга тег <table> от <p>. Большинство слабо представляет, как строятся сетки в CSS и что получится при переводе нарисованного макета в HTML-разметку.

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

Или например, приходит верстальщик Pixel Perfect. Его задача — сделать так, чтобы верстка совпадала на 100% с нарисованным макетом. Если он сделает все по уму и унифицирует отступы для всех страниц, то к нему придет менеджер и скажет, что они не совпадают с отступами на макете, и верстальщик такой — ну окей, сделаю как у дизайнера. Из-за таких ситуаций верстальщику приходилось делать множество версий заголовка для каждой страницы.

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

Тут у программиста начинаются проблемы с версткой. Например, у системы «Битрикс» единая структура шаблона, которая состоит из трех частей: header, footer и body.

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

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

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

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

Для решения этого момента я поставил себе три задачи:

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

У руководителя в работе пул из трех-пяти проектов и своя команда верстальщиков и разработчиков. С этой командой он постоянно на связи и поддерживает ее в рамках проектов. Руководитель принимает макет у дизайнера, дает правки, передает верстальщику адекватную версию макета — так на каждом этапе.

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

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

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

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

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

Разбираться в этапах разработки на уровне джуна. Подробно об этом я расскажу дальше и покажу примеры тестовых заданий. Коротко: нужно понимать, как устроена работа в Figma, «Битрикс», понимать, какие нюансы могут возникнуть на каждом этапе.

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

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

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

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

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

Второе задание: сверстать макет. У меня уже был удобный с точки зрения верстки дизайн-макет: условно, слайдер на всю длину, немного текста, внизу текст в два ряда, табличка. Задача была — собрать на HTML структуру, сделать CSS-верстку и макет, но без использования JavaScript, потому что это другой уровень сложности.

Третье задание: перевести макет в код на «Битрикс». В качестве вводных у меня был простенький шаблон текстового сайта. Нужно было сделать несколько страниц на системе управления «Битрикс»: создать темплейт, сделать нарезку header и footer, и в body подключить несколько простеньких компонентов, вроде news.list, news.detail, настроить пагинацию и несколько менюшек.

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

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

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

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

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

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

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

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

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

У нас очень хорошие зарплаты по рынку. Был проджект, который заходил в компанию стажером и получал 300-400 долларов. Сейчас он получает в 5 раз больше.

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

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

Основная команда менеджеров состоит из 5 человек, Паша и Юра с нами дольше всех. Паша пришел в ноябре 2016 года, а Юра на месяц раньше.

Юра учился в БГУ на радиофизике и компьютерных технологиях. Во время универа работал на стройке: держал обои, красил стены и получал по 30 долларов в день. Учебу решил бросить в пользу этих невероятно шальных денег и стал работать «официальным» подсобником. После двух кризисов строительных работ, когда вся бригада сидела и не делала приблизительно ничего, прислушался к знакомым, которые говорили бросать, и ушел со стройки. У нас тогда работала его бывшая одногруппница. Она предложила Юре попробовать пойти на вакансию менеджера и дала рекомендации по подготовке. Он прошел самый базовый курс по HTML, почитал про разработку сайтов. В Nineseven у Юры было первое и единственное собеседование в жизни.

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

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

Наверное, меня этот вопрос еще ждет впереди, если будут новые проекты. Но, скорее всего, мы будем медленно расти в плане менеджеров. У нас 2-3 сделки в год — это как бы хорошо, а менеджер может вести, условно, по пять проектов.

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

Nineseven.ru начала активно расти с 2019 года. Мы увеличили оборот с 312 296 долларов в 2020 году и команды из 10 человек до 723 477 долларов и штата из 30 человек в 2023 году. Сейчас в команде 33 человека, и в основном это технические специалисты.

Краткая выжимка наших изменений: