Бывший сотрудник
Плюсы работы
- Начало рабочего дня достаточно плавное: можно стартовать примерно с 8:00 до 12:00
- Интересная предметная область: собственные устройства, протоколы, IoT - много практики на стыке софта и железа.
- Удалось пощупать сразу несколько стеков технологий и направлений (десктоп, бэкенд, кодеки), за счёт чего расширился технический кругозор.
- В команде много приятных в общении ребят, с которыми комфортно работать.
- Нет жёсткого тайм‑трекера и постоянного режима "нужно было сделать вчера"
Минусы работы
– Улучшить процесс онбординга. Когда нанимают разработчика, он по сути сразу попадает на задачи: нет выделенного человека, кто бы системно вводил в контекст проектов, архитектуру, существующие решения и процессы, менторил. Вход в работу сильно зависит от личной инициативы и саморазборок в коде, что повышает риски ошибок и замедляет адаптацию.
- Усилить команду и процессы вокруг разработки: сейчас нет выделенных тестировщиков и проджекта, поэтому значимая часть нагрузки (проверка, уточнение требований, коммуникация) ложится на разработчиков. Это приводит к высокой личной нагрузке на одного человека.
- Сбалансировать процессы ревью. Есть ощущение, что ревью часто уходит в стилизацию кода и гиперфиксацию на архитектурных нюансах, тогда как бизнес‑логика и сроки остаются на втором плане. Из‑за этого возникают многократные итерации, серьёзные изменения уже написанного кода и, как следствие, не всегда рациональный расход ресурсов команды.
- Чётче разграничить ответственность за ревью и сроки: бывает, что merge request долго лежит без просмотра, но при этом именно исполнитель ощущает на себе ответственность за задержку.
- Сделать оценку разработчиков менее зависимой от "ключевого" проекта. Сейчас создаётся впечатление, что в первую очередь замечают тех, кто задействован в приоритетных направлениях и чаще коммуницирует с руководством, тогда как вклад людей на других задачах и в фоновую инфраструктуру остаётся менее видимым.
- Сделать процесс роста и пересмотра зарплаты более прозрачным. По моему опыту, повышение в основном инициируется самим сотрудником; прогнозируемая система грейдов и регулярного пересмотра помогла бы лучше планировать своё развитие.
- Наладить более регулярную профессиональную обратную связь. Формализованные one‑on‑one есть, но проходят раз в год и фокусируются в основном на последних месяцах, а не на системной оценке работы за весь период. Хотелось бы чаще получать структурный фидбэк по результатам и понимать, что именно влияет на решения о повышениях и поощрениях.
- Усилить именно управленческую часть роли тимлидов. Как технические специалисты они сильные, но хочется больше поддержки в планировании, защите команды и донесении до руководства реальной нагрузки и достижений разработчиков, а не только технического контроля.