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

Но реалии таковы, что удаленка стала must have для найма. И как тогда контролировать? Что выбрать, чтобы наблюдать за сотрудниками - системы трекинга времени, средства трансляции рабочего стола?

А если мы скажем, что ничего? Не надо тратить ресурсы на лишний контроль. И деньги сэкономите, и людям поможете раскрыться. 

Под катом рассказываем, как это у нас работает уже более 5 лет.

Ничто не предвещало беды, но тут в вашей удаленной компании пошел слух об очном корпоративе… Мы прошли через это. Было здорово. Но проанализировав на этапе подготовки стереотипы площадок и подрядчиков, а заодно отзывы самих ИТ-шников о том, что происходит “в среднем по рынку”, мы ужаснулись. С этим багажом знаний мы теперь можем раздавать “вредные советы” относительно того, как все сделать “правильно”. Поверьте, перетягивание каната и пьяные коллеги - далеко не самое страшное, что может быть у тех, кто не продумывает каждую мелочь!

Сколько существует удаленка, столько времени идут споры о том, как финансово сравнить ее с офисом. То ли удаленщик экономит на том, что не ездит на работу, то ли тратится на обустройство рабочего места… Кажется, дискуссия о том, может ли он получать те же деньги, что и его коллега в офисе, идет по кругу.

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

Каждый второй обыватель хочет зайти в “денежную” ИТ-отрасль через тестирование. И с развитием онлайн-образования появилось довольно много возможностей это сделать. Результат - QA, особенно уровня джуна, становится много. Как с ними конкурировать?

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

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

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

Уже почти два года Максилект - это не только сервисный бизнес, но и компания с собственной разработкой. Пришла пора подробнее рассказать о проекте, который мы реализуем самостоятельно, постепенно увеличивая команду.

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

С развитием коллективного иммунитета и вакцинацией удаленка перестает быть обязательной. И в этот момент людей пытаются вернуть в офис. Но открыто сказать об этом уже нельзя - удаленку распробовали. Мнимым выходом кажется идея гибридного формата работы: “Мы вам оставляем свободу, но предоставляем возможность не покрыться пылью дома, периодически встречаясь в офисе с коллегами и друзьями”. Но на деле все встречи придется планировать, а рабочие места - бронировать. И логистическими сложностями дело не ограничится. Гибридный формат как будто специально придуман, чтобы начать “классовую борьбу” вернувшихся в офис с теми, кто остался на удаленке.

Под катом разберем, что же может пойти не так...

С тех пор как удаленка стала массовой, количество статей на тему онбординга множится в геометрической прогрессии - сотрудников-то на проекты нанимать надо. Но среди десятков советов, как именно вводить новичка в курс дела, мы не видим главного - “начать с Консерватории”, т.е. выстроить внутренние рабочие процессы в компании и убедиться, что они функционируют в какой-то среднесрочной перспективе. После этого добавление “онбординга”, как отдельного процесса, пройдет легко и безболезненно. А главное, этот онбординг заработает! 

Мы уже 5 лет на удаленке. Сегодня расскажем о том, как выстроен наш онбординг и что у него на “подтанцовке”.

10 лет назад далеко не все ВУЗы готовили разработчиков для рынка. Я училась как раз там, где было все хорошо с базой, но плохо с современными технологиями, и по окончании не смогла найти себя в ИТ. Почти 10 лет меня мучил вопрос - а не вернуться ли? Не выйдет ли из меня хорошего тестировщика?

Смена профиля через столько лет после выпуска - своего рода “прыжок веры”. Но тут мне помог декрет. В этой статье я расскажу о том, как я использовала отпуск, чтобы найти свое место в профессии. А заодно поделюсь несколькими идеями, которые помогли пройти первые собеседования в новой для меня сфере.

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

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

Хотим поделиться с вами самыми интересными идеями (со ссылками на документацию, где подробно описано, как это работает).

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

В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.

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

Пытаясь усовершенствовать свою работу, чуть больше семи лет назад я пришел к раскладке Дворака и пользуюсь ей до сих пор. Хотя мне пришлось пойти на компромисс и отказаться от Дворака для программистов в пользу “классического”, в целом мне очень нравится, как спроектирована эта раскладка. Однако спроси меня сейчас, стоило ли оно того, я не порекомендую переходить. 

Под катом о том, как я переучивался и с какими трудностями эксплуатации столкнулся. Напоследок несколько выводов по итогам 7 лет эксплуатации.

Привет, меня зовут Руслан, я руковожу тестированием в Максилекте. Сегодня поговорим о базовых понятиях Devops, которые пригодятся автоматизатору. Расскажу про CI/CD в целом - что это такое и для чего оно нужно, а также про Docker. Объясню на пальцах, как развернуть тестируемый сервис в Docker-контейнере и пробросить к нему порты, как запустить тесты снаружи или внутри контейнера.

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

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

Привет, Хабр! Меня зовут Юра, я автоматизатор тестирования. Координирую пятерых автотестировщиков, которых сам же до этого и обучал.

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

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

Привет, Хабр! Меня зовут Владимир. Я разработчик в Максилекте. Помимо технического образования у меня есть бэкграунд в практической психологии. В этой статье я разберу модель уточнения, которая может быть полезна для дополнения информации о проекте как при обсуждении внутри команды, так и в разговорах с бизнесом. Модель содержит вопросы, которые стоит задавать, чтобы быстрее получить нужные данные.

Текст написан по материалам внутреннего тренинга, который я проводил в нашей компании в начале февраля.

Мне понравился механизм аспектно-ориентированного программирования (АОП), который используется в Allure Framework для перехвата выполнения тестовых шагов, отмеченных аннотацией @Step. И я попробовал применить его в автотестировании, не подключая к тестам таких монстров, как Spring или Guice.

Под катом несколько полезных примеров использования аспектов.

Привет, Хабр! Вокруг меня сформировался позитивный информационный фон на тему обработки событий через Kafka Streams. Этот инструмент привлекает множеством видео-докладов и статей на Хабре, подробной документацией, понятным API и красивой архитектурой. Некоторые мои знакомые и коллеги разрабатывают с его помощью свои системы. Но что происходит с в реальной жизни, когда эти системы уходят в production?

В этой статье я опущу введение в Kafka Streams, предполагая, что читатель уже знаком с ней, и расскажу о нашем опыте жизни с этой библиотекой на примере достаточно нагруженной системы.