User
Тестируете сайты вручную? Ваша девушка не хочет знакомить вас с родителями? Ваши друзья-курьеры и ваша морская свинка смотрят на вас свысока?
Специально для вас наш эксперт по end-to-end тестам Даниил Дунайчук записал гайд по старту в E2E атвотестах с помощью популярного фреймворка Playwright.
GitHub репозиторий с примерами из видео
Список литературы по Playwright и TypeScript
Теперь даже ваша морская свинка разберется 🐹❤️
7 правил как промоутить сотрудников
В IT у программистов есть грейды. Это примерно то же самое, что разряды у слесарей. Линейка обычно такая: Junior, Middle, Senior, Team Lead. У нас она немного другая, но суть та же. Промоушен (с англ. “повышение”) — это переход на более высокий грейд. Моя компания использует грейды больше 5 лет, поэтому я решил написать 7 основных правил процесса повышения грейда.
1. Инициатива 🙋♂️
Сотрудник должен сам писать отчет и проводить самопрезентацию на новый грейд. Да, именно он должен доказывать, что достоин повышения — по своей инициативе. Синдром самозванца? Остается навечно на старом грейде.
2. Основная работа 🔩
Отчет сотрудника должен основываться на основных рабочих рутинных задачах, а не на дополнительных факультативных увлекательных проектах. Например, выбрать 3–5 показательных завершенных задач-достижений в рамках должностных обязанностей и рассказать о них.
3. Матрицы компетенций 🛤❌
Это не зло, но и далеко не основа грейдов, как считает большинство. Это набор подсказок о том, какими хардами (hard skills — техническими навыками) можно похвастаться при написании отчета.
4. Ценность 🏁
Хвастаться хардами можно, но важно объяснить их пользу для бизнеса. Если сотрудник не может объяснить бизнес-терминами, зачем он прикрутил еще один линтер — пусть не пишет об этом в отчете. Да и вообще, пусть убирает этот линтер нафиг. Каждая задача-достижение должна приносить простую и понятную пользу для бизнеса; иначе это вредное баловство за чей-то счет.
Кстати недавно я публиковал пост с 5 основными шагами Илона Маска для достижения целей. Там была ценная мысль: «Часто умные инженеры оптимизируют вещи, которые вообще не должны существовать». Поэтому мой самый частый вопрос на совещаниях: «Чтобы что?».
5. Зоны ответственности 🤝
Кроме хард-скиллов и ценности для бизнеса важно упомянуть выполнение обязанностей и закрытие зон ответственности. Вспомните должностные инструкции сотрудника или описание вакансии на его должность. Например, сотрудник может помогать в найме и обучении новичков. Или заниматься анализом требований к задачам и давать обратную связь, если данные противоречивы — тем самым экономя время всей команды. Закрытие зон ответственности следует учитывать при выборе задач-достижений для отчета.
6. Помощь 🛟
Сотруднику могут помогать его линейный руководитель и ментор. Они должны заранее дать шаблон отчета, вместе выбирать задачи для отчета на регулярных встречах. В идеале сотрудник должен писать отчет постоянно, пока работает у вас, а не в последний момент.
7. Непредвзятость ⚖️
Выработайте объективный механизм принятия решений “да/нет” по промоушену. Если “нет”, то “нет”. Пересдача. Закройте глаза и забудьте, что перед вами знакомый человек. Перед вами безымянный винтик — и вы тоже винтик. Если вы требуете профессионализма от сотрудников — проявляйте его сами.
Мы сейчас проводим ревизию нашей системы грейдов и, вероятно, это не последний пост на эту тему. Подпишитесь на меня здесь или в телеге.
Может ли Бэтмен взять отпуск
Сегодня я расскажу вам о нашем небольшом, но очень ценном управленческом инструменте — мы называем его «техлид продукта». Если вы как-то связаны с созданием цифровых продуктов и заинтересованы в том, чтобы они хорошо работали, вам наверняка пригодится этот подход. Он особенно актуален, когда человеческие ресурсы по каким-то причинам ограничены.
Большинство инженеров любят быть героями. Я — люблю. Представьте себе хайлоад-продукт: куча пользователей, запросов, деньги летят миллионами. Система сложная, размазанная по разным серверам, а, пожалуй, даже по разным дата-центрам. В общем, всё мчится и бибикает. Но вдруг где-то откручивается гайка, труба отпадает, из неё бьёт пар. Экраны мониторов в командной рубке заливаются красным, женский голос повторяет: «Тревога! Прод лежит». Картина маслом.
Вы видите, насколько все серьезно и, не раздумывая, вступаете в неравную схватку с проблемой. Вскоре вы разносите полгорода, находите и перерезаете красный провод. Мир спасен в самую последнюю секунду. Все женщины ваши, мужчины хотят быть как вы. Для вас это чувство — наркотик, и, как любой другой наркотик, он может разрушить вашу управленческую жизнь. Почему?
Потому что вы становитесь не-за-ме-нимы. Представьте себе ситуацию в Готэм-сити, когда Бэтмен уехал в отпуск посерфить на Шри Ланке.
Незаменимых быть не должно. Для решения этой проблемы мы во Флаге придумали дополнительную роль, которая позволяет надевать костюм Бэтмена любому разработчику, начиная с грейда мидл. Мы присвоили этой роли список обязанностей, определили премии, закрепили во внутренних системах.
Обязанности роли «техлид продукта»:
1️⃣ Ответственность за работоспособность продакшена и стейджинга (боевой контур и финальный контур тестирования). Причем, именно работоспособность: создаёт и изменяет эти контуры другая роль.
2️⃣ Управление процессом устранения аварий: координация как внутренних, так и внешних специалистов, информирование заинтересованных лиц о статусе устранения аварии.
3️⃣ Ответственность за анализ аварий: ведение Post Mortem (отчётов об авариях), разбор аварий с командой, постановка организационных и технических задач для предотвращения аварий по итогам анализа.
4️⃣ Ответственность за ключевые технические решения на проекте: библиотеки и фреймворки, архитектура и подходы к разработке.
5️⃣ Ответственность за актуальность документации по разворачиванию сервисов локально у разработчиков.
6️⃣ Ответственность за создание и поддержку тестовых контуров.
7️⃣ Ответственность за актуальность документации по контрактам взаимодействия модулей системы.
🎱 Контроль технического долга на продукте.
9️⃣ Ответственность за информационную безопасность продукта: принятие решений по уровню доступа к системе для участников команды и третьих лиц, актуальность версий ПО и другое.
Для Флага всё это уже давно не теория, а рутина где-то с лета 2023 года. Роль техлида «склеивает» множество узких специализаций, таких как DevOps, Backend, Frontend, Mobile, PM и SA. Сейчас я спокоен, потому что знаю: аварии устраняются быстро, выводы делаются, наши продукты и процессы становятся надёжнее с каждым факапом. Да, факапы всё равно происходят, никуда от них не денешься. Зато узнаю я об этом из отчётов, а не из ночных смс и звонков.