Привет! Меня зовут Андрей, я возглавляю команду, которая отвечает за надежность и стабильную работу бэкенда в Wrike. Если вы когда-нибудь задумывались, что же такое «backend reliability», то знайте, что вы не один! Я часто объясняю, что это что-то вроде должности инженера по надежности сайта (SRE), но сфокусированная исключительно на бэкенде. В статье я расскажу о зонах ответственности BRE команды и инструментах, которые мы применяем для поддержания стабильной работы бэкенда на высоком уровне.
Представьте себе: утро, вы запускаете удаленку или приходите в офис и вот оно – письмо с проблемой, которую надо решить. Что делать? Паниковать? Брать отпуск? Нет!
Всем привет! Меня зовут Виктор, и я ведущий системный аналитик в одном синем банке. За пять лет работы в IT я успел попробовать себя в разных ролях - от выездного it инженера и сотрудника техподдержки, до тестировщика и аналитика. Сегодня я хочу поделиться с вами простой инструкцией о том, как столкнуться с проблемой и эффективно ее решить.
Несложные изменения, которые сделают ИТ-сектор госзакупок намного дружелюбнее (сейчас все совсем не радужно).
Меня зовут Маргарита Белкова, я дизайнер-скриптолог в компании Just AI. И в этой статье я бы хотела рассказать о феномене перебиваний и о перебивании как фиче. Мы постоянно сталкиваемся с этим явлением в реальном общении, но как быть, когда это происходит в разговорах с голосовыми ботами? Разберем, как устроена эта функция голосового бота, какие виды бывают и в каких точках сценария перебивания наиболее уместны.
Вы сталкивались с ситуацией, когда мобильное приложение или веб-сервис напоминают лоскутное одеяло? Action-кнопки прыгают по экрану, навигационные паттерны неожиданно меняются, а дизайн элементов интерфейса разнится в частях проекта?
А теперь представьте, что вы создаёте цифровой продукт в роли PO, CPO или CTO. Тогда вы столкнетесь не только с несогласованным дизайном, но также с неуправляемым бэклогом (план против реальности), задержками выпуска версий и постоянными переделками функционала после выхода в продакшн.
Крупные проекты живут с подобными проблемами, но у меня для вас хорошие новости: их можно решить. В статье поделюсь опытом организации производственных процессов для 100 команд разработки, чтобы упорядочить этот хаос.
Коллеги, привет! Меня зовут Елена, я лид команды тестирования — отвечаю за выпуск релизов команды. В начале моей тест-лидской деятельности в текущей команде релизы от начала и до конца могла выводить только я. В отпуск было идти сложно, а болеть неприятно, приходилось постоянно участвовать в рабочем процессе. Сейчас я спокойно беру выходные, потому что команда способна подхватить и закрыть задачи без меня. Рассказываю, как мы к этому пришли.
В современном мире бизнеса и технологий мобильные центры принятия решений (Mobile Decision Centers, МЦПР) стали ключевой составляющей успешной стратегии. Они предоставляют компаниям инструменты для быстрого и информированного принятия решений на основе данных. Однако выбор подходящей платформы МЦПР может быть непростой задачей. В этой статье мы рассмотрим шаги, которые помогут вам правильно выбрать платформу для вашего мобильного центра принятия решений.
Всем привет! Меня зовут Катя, я PO приложения для подготовки документации. Мы продвигаем подход Docs as Code среди нетехнических специалистов. В этой статье я расскажу, как мы сэкономили кучу времени: научили ChatGPT4 писать сценарии e2e-тестов для нашего WYSIWYG-редактора.
По исследованию Verizon, причина 82% инцидентов информационной безопасности — ошибки сотрудников.
По нашим собственным исследованиям девять из девяти техник Initial Access (стадия первичного проникновения в систему при цифровых атаках по классификации MITRE ATT&CK) реализуются с участием человека — в том числе из-за недостатка знаний или навыков сотрудников по информационной безопасности.
При этом команды безопасности 99% времени и бюджетов тратят на работу с техникой, технологиями и понятными цифровыми и физическими активами. А как работать с основной причиной инцидентов — человеческим фактором — непонятно.
Меня зовут Сергей Волдохин, я CEO в команде Start X, ранее руководил безопасностью в международной компании со штатом более 9000 человек.
В этой статье я расскажу о нашей разработке — концепции People as Code и структуре People CMDB. Благодаря этому подходу люди смогут из главной угрозы безопасности стать сильным и надежным цифровым активом.
Если, конечно, одна из них не на 8 месяце. Когда хочется сократить сроки, самым логичным выходом из ситуации может показаться увеличение количества людей в команде. В этой статье мы рассмотрим несколько исследований, чтобы понять, как размер команды влияет на ее продуктивность.
В 2017 году я впервые почувствовал себя в роли CTO (Chief Technical Officer, технический директор). Я присоединился к маленькому стартапу в роли разработчика‑сеньора, и не успел опомниться, как оказалось, что я держу в руках бразды правления технической командой. Если сказать кому о том, что я занимаю пост технического директора, прозвучало бы это впечатляюще, но на самом деле моя должность больше соответствовала роли технического руководителя проекта. Я трудился в маленькой компании, в состав которой входило человек десять сотрудников, и плотно занимался разработкой продукта этой компании. Мои дни были наполнены программированием, отладкой и постоянной борьбой с новыми багами и проблемами клиентов. Я, кроме того, был ответственным за то, чтобы наша команда выполняла бы обязательства перед инвесторами и клиентами. Это было не только время непростых задач, но и время мощного обучения, и время профессионального роста.
И ещё — то было время постоянного стресса. Но это — уже совсем другая история.
Перенесёмся в наши дни. Сегодня я — сооснователь цифрового агентства, которое находится в Швейцарии. В нём я занимаю должность CTO. Мы одновременно работаем над несколькими проектами, задействуя в каждом из них универсальные команды. Наше агентство, со времён его создания, немного подросло. Теперь в нём работает почти 50 человек. Эволюционировала и та роль, которую я в нём играю. Я больше не занимаюсь только программированием и отладкой. Теперь я управляю ресурсами, занимаюсь планированием, принимаю стратегические решения. Сейчас передо мной стоят другие непростые задачи. Но я, как и раньше, прямо‑таки наслаждаюсь, решая разного рода проблемы, и понимая, что я — тот, кто формирует техническое видение компании.
Меня зовут Лена и я QA Engineer в Brickit, приложении для сканирования кубиков Lego. До этого мне довелось поработать в крупном зеленом банке. В этой статье я расскажу об отличиях корпорации и стартапа в разрезе процессов тестирования и разработки, а также дам несколько практических советов, которые в свое время пыталась отыскать в интернете.
Есть простая айтишная мудрость: «работает — не трогай». Она применима и к бизнесу. Но на практике без нововведений, хоть и редких, бизнес может не только перестать расти, но и начать стагнировать. И нередко изменения действительно оправданы и помогают улучшить показатели компании. Но только при условии, что к их внедрению подошли правильно, а не бросили сотрудников наедине с новыми инструментами, правилами или подходами.
Меня зовут Артур Нек, я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В статье расскажу, как управлять изменениями, чтобы не получить поток заявлений на стол.
Прообраз code review появился в 60-х годах прошлого столетия, когда программы писали на перфокартах. Главной проблемой тогда было преобразование программного кода в машинный — компиляция. Это сложный процесс, чувствительный к ошибкам и структуре написанного кода. Если в процессе генерации всплывала одна незначительная ошибка, приходилось начинать процесс заново: набирать, проверять и занимать очередь доступа к системе, которая могла длиться месяцами из-за большого количества желающих воспользоваться компьютером. Из-за высокой цены ошибки программисты досконально проверяли перфокарты друг за другом.
Сегодня ошибки в информационных системах по-прежнему стоят недешево, хоть исправлять их попроще. Проверка кода одним программистом за другим получила широкое распространение и сегодня известна как практика code review.
Всем привет! Меня зовут Соня Гусева, я фронтенд-разработчик в Яндекс Практикуме (или фронтенд-капибара). Вместе с командой мы развиваем платформу practicum.yandex.ru. Например, сделали поиск по пройденным материалам — тот самый, где «найдётся всё». И тёмную тему — для комфортной учёбы даже ночью.
Практикум появился в 2019 году и с тех пор растёт. В какой-то момент нам стало сложно погружать новичков в проект. Дело в том, что стиль кода всё время развивался, но правила оставались на уровне устных договорённостей. В итоге приходили новые тиммейты, видели легаси и более свежий код — и не понимали, какой написан правильно и почему они разные. Как следствие, код-ревью растягивалось, и тестирование проходило в разы сложнее. Люди чувствовали себя неуютно в таких процессах.
Нас спас единый гайд по стилю кода — документ, в котором мы закрепили правила по оформлению кода для всей команды. В этой статье я расскажу, от каких проблем вас сможет защитить такой гайд, и приведу подробную инструкцию, как его внедрить.
Если вы любите больше смотреть, а не читать, с этой темой я выступила на Frontend meetup, где рассказала подробно о внедрении стиля кода в проекты.
Статья была написана мной в 2020 году, после запуска в прод очередной платформы, построенной на микросервисной архитектуре с целью зафиксировать выученные уроки с точки зрения технического руководителя проекта. В проектах участвовало со стороны подрядчика более 300 человек технических специалистов - разработчиков, тестировщиков, аналитиков и др. Поэтому можно сказать, что проекты были достаточно крупными и значимыми.. Теперь уже многие компании - участники проекта либо свернули бизнес в РФ, либо поменяли бренд, а разработанные системы находятся в эксплуатации. Микросервисная архитектура давно не является новой архитектурной парадигмой. Но я думаю, что статья все еще актуальна, как и многие выученные уроки .
«Покажите мне ваши блок‑схемы и спрячьте ваши таблицы, и я буду продолжать оставаться в замешательстве. Покажите мне ваши таблицы, и мне не понадобятся ваши блок‑схемы — они будут очевидны» — Фред Брукс, автор книги «Мифический человек‑месяц».
А что мы все о грустном да печальном, ошибках да UB всяких? Давайте скрасим пятницу парой вредных советов ala Григорий Остер. В бытность мою работы в питерском офисе электроников (EA Spb), был у нас один замечательный QA инженер. В обычной жизни человек довольно замкнутый и неразговорчивый, но на вечеринках, приняв стопку-другую чаю, превращался в искрометного шутника, способного срифмовать все что угодно, чем мы неоднократно пользовались. Василий, за давностью лет, я к сожалению не помню твоей фамилии, если отзовешься в коментах, то обязательно поставлю авторство. Немного из тех виршей у меня сохранились, да смысла их записывать особо не было и некогда, потому что всегда был автор под боком, но кое что сохранилось.
Если ты с утра увидел
Багу в трекере своем
Не спеши её дебажить
Пусть немного полежит
В чате спрашивай побольше
И лида поотвлекай
Пусть о баге этом страшном
В фирме знает весь народ
А потом отправь на репро
И закрой как CNR
В Lamoda Tech мы работаем не только над e-comm платформой и приложениями, но и создаем продукты для внутренних пользователей. Например, системы для пунктов выдачи заказов, приложения для пеших курьеров и так далее.
Когда от пользователей этих приложений прилетает критический баг, его сразу передают в соответствующую команду разработки. А если багу присваивают низкий приоритет, то он отправляется в бэклог с неприоритетными задачами. У этого бэклога была интересная особенность: он всегда копился быстрее, чем решался, ведь в спринты попадала лишь малая его часть.
В какой-то момент ситуация стала критической: в списке скопилось больше 100 задач. Для двух небольших команд это стоило бы пары лет разработки, если брать по 2 задачи в каждый спринт.
Смотреть в этот бездонный колодец было больно. Поэтому мы решили действовать радикально: пофиксить все старые баги на багатоне и изменить работу с техподдержкой, чтобы не копить баги в таком количестве. Расскажу, как мы это организовали.
В этой статье HR-менеджер нашей студии расскажет о том, что входит в онбординг, чем он выгоден для компаний и как мы погружаем ребят в новые обязанности.
***
Привет! Меня зовут Валерия, я старший HR-менеджер веб-студии Pyrobyte. Наверняка многие из вас сталкивались со стрессом в первые дни на новой работе: новый офис незнакомые люди, другие обязанности. Куча эмоций, переживаний и сомнений, с которыми сложно совладать: «А понравится ли мне?», «А как меня воспримут коллеги и руководство?», «А справлюсь ли я?»
В таких ситуациях легко поддаться панике и уйти в переживания. Поэтому поддержка новичка в компании должна быть взята за правило. Чем мягче и последовательнее будет переход от стрессующего в первый день сотрудника до уверенной боевой единицы — тем лучше и для самой компании, и для сотрудника.
