Ответ
При оценке новой команды я фокусируюсь на технических и процессных аспектах, которые напрямую влияют на качество работы и продуктивность.
1. Процессы и культура качества:
- Code Review: Существует ли систематический процесс? Как проходит обсуждение? Это формальность или конструктивный диалог?
- Тестирование: Каково покрытие автотестами? Есть ли пирамида тестирования (unit, integration, e2e)? Как быстро прогоняется тест-сьют?
- CI/CD: Настроен ли автоматический пайплайн (сборка, тесты, деплой)? Как часто происходят релизы?
2. Технический стек и подходы:
- Инструменты: Современные и подходящие для задачи или устаревшие? Есть ли единые стандарты (линтеры, форматеры)?
- Документация: Насколько она актуальна? Где хранится (Confluence, README, код как документация)?
- Технический долг: Признается ли его наличие? Есть ли планы по его сокращению?
3. Взаимодействие и коммуникация:
- Планирование: Используются ли Agile-практики (Scrum, Kanban)? Насколько реалистично оцениваются задачи?
- Знание продукта: Понимает ли команда бизнес-ценность того, что разрабатывает?
- Онбординг: Есть ли четкий процесс для новых членов команды? Насколько быстро можно начать вносить значимый вклад?
4. Фокус на результате:
- Метрики: Отслеживается ли что-то помимо дедлайнов (качество кода, количество инцидентов, удовлетворенность пользователей)?
- Итеративность: Готова ли команда получать обратную связь и быстро вносить изменения?
В идеале я ищу команду, где есть баланс между строгими инженерными практиками и здоровой атмосферой, позволяющей эффективно решать сложные задачи.
Ответ 18+ 🔞
Слушай, а вот как я обычно новый коллектив на разрыв аорты проверяю. Не по харизме менеджера, а по тому, что реально в работе болит. Сейчас разложу, как есть.
1. Процессы, или где тут у вас дерьмо закатывают под ковёр?
- Code Review: Это святое, блядь. Меня бесит, когда это формальность — «а, ок, апрув». Нет, ты посмотри, сука, на этот кусок кода. Это же пиздец, а не решение. Надо обсудить, поругаться, в итоге сделать лучше. Конструктивный диалог, а не одобрение для галочки. Если его нет — это тревожный звоночек размером с колокол «Успенский».
- Тестирование: Автотесты — это не прихоть, это страховка от того, чтобы не обосраться на ровном месте. Какое покрытие? Есть ли нормальная пирамида (unit, integration, e2e), или всё висит на хрупких e2e-скриптах, которые гоняются полдня? Если тестовый прогон дольше, чем сериал «Игра престолов», — это пиздец.
- CI/CD: Если чтобы задеплоить фичу, нужно вручную танцевать с бубном, копировать файлы по FTP и шептать заклинания — это не процесс, это пиздец. Должен быть пайплайн: запушил код → собралось → прогнали тесты → улетело на стенд. Частые релизы — признак здоровья, а не аврала.
2. Техдолг и инструменты, или на чём вы тут, блядь, ездите?
- Инструменты: Работают на React 15 образца 2016 года? Линтеры и форматеры — это как общие правила гигиены, чтобы код не выглядел как помойка. Если их нет — всем плевать, и это чувствуется.
- Документация: Где она? В голове у того чувака, который в отпуске? Если Confluence обновляли при царе Горохе, а в README.md лежит только «npm start», то онбординг нового человека — это квест на выживание.
- Технический долг: Его наличие — нормально. А вот отношение к нему — показатель. Если все делают вид, что его нет, и продолжают лепить костыли на костыли, то проект медленно, но верно превращается в того самого Франкенштейна, который всех ебёт.
3. Коммуникация и планирование, или вы вообще понимаете, что делаете?
- Планирование: Спринты или канбан — неважно. Важно, как оценивают задачи. Если постоянно берут «всего пять маленьких тасок», а потом две недели горят и делают их в ночь перед демо — это пиздец, простите мой французский. Оценки должны быть адекватными, а не из разряда «ой, да мы тут за час».
- Знание продукта: Программист — не обезьяна с клавиатурой. Если команда не понимает, зачем и для кого они пишут эту фичу, а просто выполняет ТЗ — результат обычно получается технически правильный, но нахуй никому не нужный.
- Онбординг: Новый человек должен начать приносить пользу не через полгода, а через пару недель. Если нет чёткого пути «вот репозиторий, вот как запустить, вот наши стандарты, вот простенькая задача для начала» — значит, всем похуй.
4. Результат, или что мы, блядь, в итоге производим?
- Метрики: Дедлайны — это хорошо. Но если ради них выплёскивают в продакшн сырой код, который потом неделю чинят, — это не эффективность, это идиотизм. Отслеживают ли количество багов в продe, откаты, satisfaction пользователей? Или главная метрика — «закрыли спринт»?
- Итеративность: Способна ли команда не зацикливаться на своём гениальном решении, а услышать фидбек и быстро его доработать? Или после сдачи фичи все разбегаются, как тараканы от света, и «теперь это проблемы саппорта»?
Короче, я ищу место, где есть здоровая паранойя по поводу качества, но при этом не заебали бюрократией. Где можно поругаться на код-ревью, а потом вместе пойти на кофе. Где техдолг признают и потихоньку разгребают, а не делают вид, что его не существует. Вот это, блядь, и есть баланс. Всё остальное — или бардак, или болото.