Ведение разработки: как вести 20+ проектов без помощи менеджеров

Денис Гордиенко, генеральный директор Bright Mobile, об управлении командой проекта о том, как вести свыше 20 проектов без по мощи ПМов

Сегодня хочу поделиться лайфхаком, который будет полезен для тех, кто планирует или уже развивает свою собственную студию разработки приложений и/или сайтов или набирает команду в свой проект «in house».

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

У всех моих проектов есть помощник менеджера, который помогает мне выполнять определённые конкретные задачи – например, зарегистрировать клиенту аккаунт AppStore или Google Play, забрать данные для публикации и т.д. Т.е. полномочий управления командой внутри проекта и общения с клиентами у ПМа нет: он лишь выполняет типовые, стандартизированные задачи по расписанному регламенту.

В ходе своей деятельности я обнаружил, что какого ПМа ни нанимай, толку будет мало. Был у меня опыт, когда один проект-менеджер получал больше 100 тысяч в месяц (в Тольятти): я тогда ожидал достаточно универсального подхода. Однако, в итоге, он лишь увёл у меня клиента и трёх разработчиков и открыл собственную студию. Так что смысла в дорогих менеджерах я не увидел никакого. Если менеджер дешёвый – так он больше проблем принесёт, чем результата результат.

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

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

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

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

Звучит, возможно, довольно грубо, но в суровых реалиях нашего рынка так оно и происходит: я могу нагрузить верстальщика дополнительными задачами (разумеется, оплачиваемыми не ниже уровня вёрстки), и он готов эти задачи реализовать. Для него это даже некоторого рода разгрузка – ему не приходится постоянно кодить, и время от времени он помогает мне в ведении проекта.

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

Я ставлю задачу верстальщику, когда он делает каркасы, подключаю сюда же другого верстальщика, чтобы он сделал code review, перегнал найденные баги в таблицу и проверил её. На этом этапе два верстальщика общаются друг с другом, и на выходе я получаю уже корректный код: мне не нужно по несколько раз подключаться к процессу. Так помощник экономит моё время и самостоятельно доводит исправление багов до идеала: если мне пишут, что всё готово, значит, так и есть – должно случиться что-то невероятное, чтобы какой-то баг так и остался неисправленным.

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

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

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

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

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

Очевидно, что люди приходят с разной подготовкой: кто-то лучше верстает, кто-то легче переводит баги с моего видео в таблицу. Я ограничиваю время на все типы заданий, их всего пять (об этом – чуть ниже). Но в регламент, вне зависимости от того, что у верстальщика лучше или хуже, он может не уложиться. Например, если с git’ом человек ни разу не работал, он вряд ли справится с ним за час. Но зато он может лучше справляться с Ionic, и сэкономить таким образом на нём время. В итоге получается микс: перекачивание времени между задачами, которое не так страшно, как полное выпадение из определённых рамок, когда исполнитель со всем работает плохо и не дотягивает до минимального необходимого мне уровня.

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

Первое: о деньгах. Когда я беру специалиста в свою команду, я всегда объясняю ему, как он может расти и увеличивать свой доход, и что может случиться, если он начнёт скатываться. Такое случается – иногда человек просто выдыхается, и ему нужно менять работу, а мне – специалиста. Это нормально. Чтобы сотрудник сразу знал, что его ждёт, я показываю ему следующую схему.

Есть такое понятие, как «полезные часы» – то время, которое даётся на решение задачи. Например, на вёрстку 20 экранов на типовых каркасов даётся 20 часов. Они и являются полезными часами.

Разработчиков делят на три уровня: Junior, Middle и Senior. Джуниору для выполнения плана достаточно закрыть 100 полезных часов. Мидлу – 140, Сеньору – 170. Зарплата соответствующая: 30, 42 и 55 тысяч в месяц.

Почему именно такие цифры? В среднем один месяц содержит 160 рабочих часов. Понятно, что есть праздники, есть вообще январь, в котором рабочих чуть ли не меньше, чем рабочих, но в среднем цифра всё-таки на уровне 160. Поэтому у Junior’а 60 часов будет уходить на поиск решений, багфикс предыдущих задач и прочие вспомогательные задачи, которые обеспечат минимум в 100 полезных часов. У специалиста ранга Middle впустую уходит меньше времени, а значит, больше часов будет полезных.

Наконец, у Senior’а 170 полезных часов. На целых 10 больше, чем имеется – казалось бы, есть диссонанс, но нет: подразумевается, что специалист настолько прокачан, что может собрать каркас не за один плановый час, а в два раза быстрее. У нас бывали случаи, когда на один каркас уходило лишь 15 минут. При такой работоспособности задачу, оценённую на час, удастся выполнить задачу вчетверо быстрее: значит, на 20 экранов потратится не 20, а только 5 часов. Так объём часов накапливается, и у мастера остаётся время ещё и на гугленье и исправление багов. Соответственно, планово повышается и зарплата.

Чтобы специалист Junior получил Middle, он должен три месяца подряд отрабатывать план его уровня, т.е. иметь 140+ полезных часов. Дальше зарплата увеличивается, и эта планка становится обязательной. Обратного перехода нет: если план мидла не закрывается два месяца подряд, то досвидание.

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

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

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

Первая задача – это тестовая вёрстка нашего готового решения RTPlatform. Здесь 14 экранов, нужно каждый из них сделать и сдать. На всё про всё даётся 14 часов, по итогу нужно залить исходники в точно таком же формате и скинуть ссылку. Некоторые экраны имеют несколько состояний, например, просмотры заданий: это может быть просмотр и своего, и чужого задания, есть варианты с откликами и без – всё это нужно предусмотреть.

Следующее – это работа с git’ом. Здесь нужно посмотреть видео и выполнить все действия, которые в нём имеются. Ничего сложного: смотрите, делаете то же самое. На выполнение даётся один час.

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

Затем – проверка исправленных багов. Пункт похож на предыдущий, только баги (которые занесены в такую же табличку) здесь уже исправлены. Нужно посмотреть видео, воспроизвести те же действия и покрасить каждый баг в таблице: в зелёный, если он исправлен, и в красный, если он так и остался. Если баг остался, но не совсем такой же, нужно приписать краткий комментарий о том, как он выглядит.

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

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

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

В таблице прописывается дата, тип работы (например, devops, сама вёрстка, занесение багов или баг-фикс), количество часов (не потраченное фактически, а выделенное на работу) и ссылка на проект.

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

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

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

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

Больше полезных материалов по ведению проектов на моём YouTube.