Опыт работы в немецкой команде

В силу интересного стечения обстоятельств в феврале я перебрался из Санкт-Петербурга в Берлин и присоединился в качестве CTO к команде www.iversity.org.

Мы разрабатываем аналогичную Coursera платформу, только для европейского рынка. Также у нас есть субпроект MoocFellowship, который уже как-то освещался на Хабре.

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

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

Можно по-разному относиться к изложенному ниже, тем не менее вот несколько фактов, которые заставляют призадуматься:

• Командой размером в полтора раза меньше, чем в предыдущем проекте в России за 3 месяца мы сделали больше, чем за 9 в России. Технология одна и та же. Мы используем Ruby on Rails + немного AWS + свои сервера.
• За 4 месяца внутри команды не было ни одного конфликта.
• Текучки кадров нет.
• Нарисованный roadmap в целом соблюдается, при этом без переработок и явных напрягов.

КВАЛИФИКАЦИЯ И КОМПЕТЕНТНОСТЬ

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

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

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

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

ДИСЦИПЛИНА И РАБОЧЕЕ ВРЕМЯ

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

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

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

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

КОМАНДНАЯ РАБОТА

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

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

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

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

ПЛАНИРОВАНИЕ

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

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

Количество митингов сведено к минимуму. Митинги с участием всего коллектива вообще редкая вещь. Лично мы в отделе разработки используем SCRUM со стандартным набором пирогов типа planning pocker+story points. Спринты длятся две недели. Планирование нового спринта, оценка задач и разбор полета занимает примерно пол рабочего дня. Участвуют только разработчики и продукт менеджеры.

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

ЗАКЛЮЧЕНИЕ

Первый очевидный вопрос: «Если там все так круто работают, почему Германия не производит столько клевых стартапов, как Долина или Тель-Авив?». Ответ очень простой: для Германии вся эта IT толкотня больше представляет развлечение, нежели серьезную статью дохода. По крайней мере, по сравнению с автомобильной и прочими промышленностями.

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

Автор: Irbiz

Источник