Как оценить процессы в компании + комментарии разработчика
Собеседование — только полдела. На интервью не всегда очевидно, как на самом деле будут устроены рабочие процессы, и реальность может оказаться не такой радужной. Как выбрать тот проект, где будешь по-настоящему счастлив? На Stack Overflow пользуются тестом Джоела — это 12 вопросов, которые должны помочь оценить качество работы команды. 12 простых вопросов, да/нет ответы. Но этому списку уже 20 лет, и Gergely Orosz пообщался со множеством разработчиков и адаптировал тест к современным реалиям. Приводим перевод нескольким блоков и комментарии разработчика: он как раз недавно вышел работать в новую компанию.
Необходимо, но не достаточно: 3 требования к новой компании
Есть три пункта, которые Джерджели называет базовыми: без них невозможно комфортно работать и развиваться на новом месте.
— психологическая безопасность: чувствуют ли себя люди в безопасности, высказывая мнение, которое отличается от мнения остальной команды?
— достойная вашего труда компенсация: получают ли зарплату, которая соответствует рынку?
— гибкие рабочие часы: могут ли гибко организовывать своё рабочее время?
Последний пункт кажется неочевидным, но в ковидные времена произошло резкое увеличение количества позиций на удалёнке. Поэтому чтобы конкурировать между собой за лучших специалистов, компании обязаны проявлять гибкость в вопросах графика.
«Начиналось всё неплохо: позвали в небольшой проект. Развивается стремительно, у команды хороший технический уровень — это очень воодушевляет. А потом — всё куда-то скатилось.Атмосфера нездоровая — вечные политические игры. Например, уволили двух коллег, которые впахивали больше всех остальных, причин не объясняли. Да и вообще команда малопроизводительная — когда никто не хочет работать, становится скучно, хотелось задач поамбициознее.
Они стали релоцировать всех сотрудников в Прагу, и я был в шаге от того, чтобы подписать документы —, но задумался. А хочу ли я подписывать контракт на два года и оставаться с командой и дальше? Не особо.
До этого я год работал в IT-гиганте — большая машина, много бюрократии, если появляются свои идеи, как улучшить продукт — их трудно продвинуть. Планы у менеджеров расписаны на два года вперёд. Поэтому решил придерживаться своей линии: искать какой-то стартап.
Хотелось, чтобы было достаточно много свободы, чтобы команда не создавала видимость загруженности, а действительно работала. Это должно быть место, где люди горят своим делом.
А ещё мне нравится работать удалённо. Возможность выбирать свой ритм жизни хотелось сохранить.
Может, работники IT по сравнению с другими специальностями и избалованы:, но ведь с другой стороны, если все компании примерно выровнялись по уровню компенсации, «кофе и плюшкам на кухне» — IT-специалисты реально могут себе позволить выбирать тот проект, который по-настоящему откликается, чьи ценности ты разделяешь. Зачем терпеть скучный проект и неприятную команду?» — Артём С.
5 вопросов про взаимодействие с командой
Самостоятельные и креативные люди процветают в компаниях, где есть ясность процессов, возможность автономности с одной стороны и сотрудничества с другой. На какие стороны работы команды Джерджели предлагает обратить внимание? Могут выполняться 4 пункта из 5.
- Обусловленность действий. Есть ли процесс, который позволяет делиться бизнес-запросами, почему нужно выполнить ту или иную задачу? Дорожная карта продукта, OKR, цели компании.
- Бэклог/дорожная карта продукта и инженеры, которые вносят вклад в эти процессы. Есть ли у команды чёткий бэклог, который позволяет ответить на вопрос «над чем будет работать дальше и почему»? Могут ли инженеры вносить предложения в дорожную карту? Приоритизируются ли благодаря этому предложения по погашению технического долга?
- Прямая коммуникация при возникновении проблем. Могут ли разработчики напрямую общаться с разработчиками других команд? Или они должны пообщаться с своим менеджером, который поговорит с другим менеджером, который поговорит с ещё одним менеджером, который поговорит с…
- Коллаборация со специалистами других сфер. Могут ли разработчики работать напрямую с дизайнерами, продакт-менеджерами, дата сайентистами и другими стейкхолдерами, не прибегая к помощи посредников, например, менеджеров?
- Инициатива поощряется. Вознаграждаются ли люди с новыми идеями и инициативами, или считаются, что они лишь зря отвлекают внимание?
«За 12 лет в IT я успел поработать и в крупных, и в мелких компаниях. Бросил какое-то место, просто потому что понял, что не цепляет. И пришёл работать в стартап почти бесплатно: потому что попал в суперскую идейную команду. Команда горела: в год чемпионата по футболу в России мы запартнёрились с FIFA, Apple сделал фичеринг — и всё это без бюджетов, на одном энтузиазме. Найти правильную схему для монетизации не смогли, поэтому решили разбежаться, но сама атмосфера — это было круто.Я задумался об этом, когда увидел Wheely — знал о них и до поиска работы, у меня там есть знакомые. Случайно увидел вакансию, поговорил с ребятами, откликнулся через бота — так действительно было удобнее. Решил, что не хочу ехать в Прагу, хочу нормально работать.
Ещё и по идеологическим представлениям совпали: Wheely отказались предоставлять данные о передвижении своих пользователей.
Можно работать на удалёнке — и это правильно, как мне кажется. Я верю, что если человек работает, он будет работать откуда угодно. А если увиливает от ответственности, то и в офисе найдёт возможность её на себя не брать», — Артём С.
5 вопросов про инженерную культуру
Стабильная инженерная культура — чтобы специалисты не перегорали на работе и не были разочарованы. Это принципы, которых придерживается большинство IT-проектов — и разработчики могут быстро развиваться внутри компании. Могут выполняться 4 пункта из 5.
- Различаются ли этапы «функциональная готовность» и «готовность к продакшену». Есть ли различия между прототипом, MVP и готовым к продакшену продукту? Есть ли чеклист для оценки качества, что продукт готов к выпуску?
- Код ревью и тестирование — являются ли они частью рутинного процесса разработки, а их отсутствие — редким исключением?
- Налажен ли процесс непрерывной интеграции. Есть ли у вас процесс непрерывного развёртывания, чтобы отправлять код прямо в продакшен, и если нет, то могут ли разработчики отправлять собственный код в это окружение?
- Oncall не влияет на здоровье сотрудников. Для проектов, где есть oncall, следят ли за тем, как он влияет на состояние людей и работу над продуктом?
- Доступ к исходному коду. Может ли любой разработчик просматривать и вносить свой вклад в исходный код?
«На старом месте работы было очень много встреч с продактами, бесконечные обсуждения, постоянно что-то разбирали и обговаривали. Но никак не удавалось наладить процессы внутри команды, что-то постоянно кому-то мешало. Люди были недовольны.А оказывается, можно созваниваниваться только раз в день по 15 минут, и этого достаточно всем. Так вообще работает? Все Agile, Scrum и прочие методологии не работают при разлаженности команды. Достаточно самого минимального усилия, чтобы запустить процессы и команде было удобно работать.
И чтобы двигаться дальше, стремиться к чему-то новому — нужна эмоциональная составляющая, без неё не получится. Если проект в принципе не интересен, успеха, скорее всего, не будет. В общем, корпоративная культура формирует заинтересованность разработчика, как мне кажется», — Артём С.
Помимо этих двух, автор отдельно выделяет блок про развитие карьеры в конкретной компании: наличие «культуры обратной связи», карьерной лестницы, менеджеры с техническим бэкграундом.
Список хорош, но насколько он применим на практике? Джерджели говорит, что судя по его опыту общения с разработчиками из разных стран — вполне, и многие инновационные и быстро развивающиеся компании от FAANG до успешных стартапов используют эти принципы.
А как вам кажется, это возможно? И что важнее всего в компании? Напишите, пожалуйста, в комментариях.
