Несколько месяцев назад коллеги, работающие с одним из кластеров Kubernetes в dev-окружении, обратились с проблемой недоступности API-сервера Kubernetes. Dev-среды обычно не подключены к дежурной смене, и решением проблем занимаются владельцы или, если проблемы нестандартные, обращаются к профильным специалистам. В ходе диагностики оказалось, что kube-api стал потреблять значительно больше памяти. Это приводило к возникновению ошибки с OOM.

Давайте будем честными — если бы это произошло в production-окружении, мы, скорее всего, закинули бы больше памяти и успешно бы забыли про проблему. Но dev-стенд не имеет жёстких SLA с финансовой ответственностью, и это дало нам возможность и время разобраться с прожорливым kube-api.

Всех, кому интересно, что из этого вышло, прошу под капот.

Большинство IT-команд работает по методологии Agile, основной постулат которой гласит: «Работающий продукт важнее исчерпывающей документации». При этом одним из критериев качества требований к ПО, наряду с корректностью, непротиворечивостью, недвусмысленностью, является их полнота.

То есть налицо противоречие: документация IT-продукта в Agile менее важна, чем сам продукт, но при этом, чтобы продукт был качественно разработан, требования должны быть полными.

Как в такой ситуации аналитику, главной обязанностью которого как раз является составление требований, сделать работу качественно? Об этом мы и поговорим в этой статье.

В прошлом году мы с командой мобильного приложения «Госуслуги Авто» выпустили новый сервис — оформление ДТП без участия инспектора ГИБДД. В этой статье я расскажу, как мы разрабатывали сервис, какие грабли собрали, чему научились и каких результатов достигли.

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

Это вторая часть статьи «Мессенджеры на работе — это не прокрастинация, или как мы сделали сервис для автотестирования». Как и обещали, в данной статье мы расскажем о том, как масштабировали наш сервис, как развивали функциональность автотестов и как в итоге вышли за рамки обычного репорт-бота. 

Однажды у нас появилась идея отправлять отчёты о выполнении автотестов в мессенджер Telegram. Постепенно эта идея переросла в сервис, который позволяет запускать тесты, оповещать об ошибках и получать отчёты в любом мессенджере, где есть возможность интегрировать бота. Помимо доступа к результатам автотестов, бот получил интеграцию с Jira и другими инструментами, которые мы используем в РТЛабс.

В данной серии статей мы хотим рассказать нашу историю о том, с чего все начиналось, какие у нас были идеи, какие ошибки мы совершали и как мы их решили в итоговой реализации.

Год назад мой коллега рассказал о команде Customer Success (далее CS), которая старается услышать каждого пользователя и почувствовать его боль на себе. За год много чего произошло в мире и, как следствие, на Госуслугах тоже. Неизменно одно — чуткое включение команды CS на обратную связь наших пользователей.

В этой статье я хочу рассказать, какие подходы мы используем и, конечно, поделиться примерами профита.

Меня зовут Сергей, я занимаюсь нативной автоматизацией тестирования мобильных приложений (iOS) в компании РТЛабс. 

В данной статье я расскажу, как внедрялась отчётность на наших проектах, какие средства использовались и о порядке действий для получения результатов прогона автотестов в Allure.

2,5 года назад мы поняли, что работу с Госуслугами нужно упрощать — ведомства часто отказывали из-за неправильно заполненного заявления. Тогда был придуман новый подход к услугам. В него мы вложили весь опыт команды проектировщиков, аналитиков и оунеров, исследования и результаты тестирований гипотез.

Дополнительным источником инсайтов и вдохновения для нас стали феномены из когнитивистики — науки о сознании и его процессах. Они заставили обратить внимание на многие вещи в UI и UX с точки зрения работы мозга и его восприятия интерфейса. 

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

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

Привет, меня зовут Наташа, сейчас я продакт-менеджер в РТЛабс и работаю с командой разработки мобильных приложений Госуслуг.

В моем окружении каждый 5-й хочет в IT, но не знает, как в него попасть. Зачастую текущая работа таких кандидатов далека от информационных технологий. Если же это студенты, то как правило у них нет реальной практики (это особенно заметно в регионах), и поэтому они тоже не высоко ценятся на рынке труда.

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

Как мы пилили десятки гайдлайнов, зачем искали свой путь и что теперь можем посоветовать вам

РТЛабс — генеральный подрядчик Минцифры по Госуслугам. На протяжении двенадцати лет мы видели портал в десятках реинкарнаций разной степени проработанности. Неизменным оставалось одно — всегда требовалось описание того, что мы делаем. И как ни один дом не строится без чертежа, ни один проект не обходится без базы знаний и свода правил.

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

Меня зовут Дмитрий Пирумов, я возглавляю команду автоматизированного и приемочного тестирования в РТЛабс. В этой статье я хочу поделиться опытом проведения тестирования на проде, внедренного у нас в компании, и попробовать показать профит и болевые точки такого подхода. 

Госуслуги уже давно не про запись на приём в ведомственные учреждения и не про единое окно (чтобы этот термин не значил) — мы расширяем горизонт и развиваем полноценную цифровую экосистему.  На этот раз перед нами стояла задача разработать решение для подписания документов с помощью мобильного приложения, которое получило название «Госключ».  

На связи команда проекта «Госключ» и директор проектов РТЛабс Константин Белов. Задачами, связанными с пилотированием новых процессов на региональных и даже федеральном уровнях, нас удивить сложно. Они — частый гость в наших офисах, но редко речь идет про мини-революцию и борьбу с «устоями».

Не секрет, что коронавирус заметно поменял все сферы жизни и бизнеса. И было бы странно, если бы пандемия не повлияла и на процесс подписания документов при помощи государственных сервисов.

Цифровые ассистенты — тренд в массовом обслуживании. Они автоматизируют работу поддержки, помогают пользователям найти и подобрать услуги, записаться на прием, развлекают.

К порталу Госуслуг редко встретишь нейтральное отношение. Многие его любят и говорят, что это отличная альтернатива очередям в ведомствах и МФЦ — заполняешь заявление online и быстро получаешь нужную справку или документ. Для других Госуслуги — это проблема. Непонятно, как это работает, где найти услугу и куда нажимать.

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

Меня зовут Дмитрий Огуряев, я специалист в области массового розничного обслуживания. Большую часть жизни проработал в крупных розничных банках и последний год являюсь Заместителем Министра Минцифры, отвечающим за портал Госуслуг, а также за ряд иных направлений.

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

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

В области государственной цифровизации сформированы верхнеуровневые цели (без бумаги, онлайн, без личных визитов, цифровой вход - цифровой выход и тд). Но как достичь этих целей? Из каких строительных материалов строить цифровой небоскреб? В этой статье как раз попытаюсь приблизить ответ на этот злободневный вопрос.

Здесь вспоминается стихотворение Маяковского «Что такое хорошо и что такое плохо».

Привет, читатель!

Меня зовут Василий Кудрявцев, и вот уже ~10 лет я занимаюсь нагрузочным тестированием, а из них последние 1,5 года – в компании РТЛабс.

И сегодня мы поговорим не об инструментах или общих подходах, а об области, которую обычно обходят стороной или собирают на коленке — тестовые стенды для нагрузочного тестирования.

Здесь, на Госуслугах, мы пока только конструируем мечту каждого нагрузочника — свой отдельный, выделенный, рабочий (!) тестовый стенд.  Особенно это мечта актуальна для небольших продуктовых команд.

Единая биометрическая система (ЕБС) с 2018 года используется для идентификации человека по его биометрическим характеристикам: голосу и лицу.

Чтобы получать услуги по биометрии, пользователю необходимо зарегистрироваться в системе в одном из 13,1 тысяч отделений банков. Там операционист сделает его фотографию, запишет голос и отправит эти данные в систему. А для того чтобы компании могли оказывать по биометрии различные услуги, им необходимо провести интеграцию с ЕБС.

Оператором системы является «Ростелеком», а разработкой занимаемся мы – дочерняя компания РТЛабс .

Меня зовут Сергей Браун, я заместитель директора департамента цифровой идентичности в РТЛабс. Вместе с Артуром Душелюбовым, начальником отдела развития и разработки департамента цифровой идентичности, мы расскажем, как мы создавали платформу для любой биометрии, с какими проблемами встретились и как их решали.

сода…команда неравнодушных людей! И это может быть непривычным. Потому что в сознании многих gosuslugi.ru — это что-то «чиновническое» и «бездушное», если угодно. Но на самом деле сотрудники портала — граждане страны, которые хотят сделать удобные и человечные сервисы для нас: тебя, меня, друзей и родных. Сейчас расскажем, как мы «очеловечиваем» портал.