Службе поддержки сотрудников исполнилось 10 лет. В честь юбилея решил собрать ретроспективу развития продукта и написать про менеджмент и ключевые организационные изменения: как действовали с учетом масштабов компании, как пересобирали процессы в полете. И почему сделать просто порой и непросто, и небыстро.
К работе с бэклогом можно подойти по-разному. При выборе формата важно учитывать особенности конкретной команды: количество ролей, степень неопределенности в прогнозировании будущей нагрузки, количество и сроки задач.
В статье мы рассмотрели форматы работы с бэклогом на примере двух команд, процессы которых сильно отличаются. Одна команда использует метод SAFe, вторая — оперативное планирование. Рассказали, как устроен процесс работы в каждой и какие нашли преимущества и недостатки за полтора года.
История о том, как в нашей команде отпала необходимость в дежурном аналитике и какие чудеса творят разработчики, чтобы облегчить жизнь аналитиков. Один бот заменил нам сразу несколько уведомляторов, а еще он сам анализирует изменения в Нормативке и разного рода справочниках.
Редис – это кеш? А, может быть, это основная база данных? Так мы и живём в Мойре – опенсорс-системе реалтайм-алёртинга, родом из компании Контур. Расскажу вам про плюсы и минусы такого подхода, про жизнь в Редисе при 3 миллионах RPS, про миграции данных и оптимизацию базы.
История об испытаниях, которые ждут аналитика в стартапе. Расскажу о том, как выстроить процесс, когда разработка и аналитика стартуют вместе, как поддерживать частые изменения и как мы выкручивались без тестовых площадок.
Всем привет. Это лонгрид о том, какие сложности у нас были с переводом календарей внутренней соцсети на новый бэк, как мы выруливали, как бета-тестили с помощью фича-флагов и как это всё в итоге того стоило. Подробный разбор большого проекта не для слабонервных))
В гайдах мы описываем принципы, которые используем в работе, делимся своим взглядом и накопленным опытом в исследованиях и проектировании. В этой статье расскажем, почему и как мы пишем гайды, чем они отличаются от статей и какую пользу приносят. А еще поделимся полезными ссылками!
Стать ориентированным на цели бизнеса – это важнейший софт скилл, который позволит вам быть востребованным. Но как на бизнес может влиять тестировщик?
Меня зовут Раткин Кирилл, я начал свой путь в тестировании 13 лет назад. Сейчас я руковожу кластером QA-команд в Контуре. В этой статье я поделюсь с вами советами, которые могут помочь вам понять, как начать решать проблемы компании и в каком направлении мыслить.
В этой статье мы начнем с небольшого погружения в код ThreadPool’a, а закончим интересным кейсом применения матанализа в одной из самых важных частей многопоточности в дотнете.
С большой силой ThreadPool'а приходит большая ответственность! И поэтому наша ответственность – понимать устройство этого мощного инcтрумента, чтобы понимать его ограничения. А два главных способа понять: чтение кода и, конечно, эксперименты с многопоточностью...
Я Ульяна Галиуллина, проектирую интерфейсы внутренних сервисов Контура. Сегодня хочу поделиться с Хабром, как на протяжении последних 10 лет эволюционировали интерфейсы нашей внутренней поддержки. А они не могли не изменяться, ведь у 12000+ сотрудников масса вопросов и проблем: с Wi-Fi, отпусками, заказом новой мебели. А еще постоянно что-то ломается и не получается :)
Привет, меня зовут Владислава, я UX-исследователь в Контуре в направлении Недвижимость. Мы создаем решения для застройщиков и риелторов. Например, в портфеле направления есть сервисы для электронной регистрации прав собственности в Росреестре и проверки юридической чистоты сделок.
В этой статье расскажу, как мы выстроили процесс анализа успешности решения. Если вы из раза в раз задаетесь вопросом: «А не фигню ли мы сделали?», но не знаете, как это можно проверить — эта статья для вас.
Я Илья Мезенцев, ML разработчик в Контуре. Расскажу о том, как мы в DS-команде создавали единую схему всех своих решений. Статья для DS-специалистов уровня senior/lead, которые отвечают за проекты целиком.
Мы сделали гайд для создания user-friendly интерфейсов. Он будет полезен не только новичкам в UX-исследованиях, но и опытным исследователям, аналитикам и проектировщикам.
Про no-code говорят уже больше 40 лет, но в этом подходе до сих пор остаются существенные пробелы. Поделюсь своим видением в статье. Меня зовут Даниил Мясников, я руковожу в Контуре функциональными зонами на P –– Python, PHP, Perl.
Как за 2 месяца создать самопополняемую документацию там, где ее никогда не было? Вот четыре этапа, которые нужно будет пройти техническому писателю.
Привет, Хабр! Меня зовут Женя Мельцайкин, я работаю в команде мобильной разработки Контура.
Мы разрабатываем экосистему для бизнеса, которая оптимизирует рутинные задачи: работу с маркировкой, проверку контрагентов, товароучет, документооборот, отчетность. И в одном из продуктов работаем с подписанием электронных документов. Электронная подпись — это юридически значимая операция, поэтому важно не допустить ошибки пользователя.
В статье расскажу, как мы сделали кнопку по проведению жеста свайпом на Jetpack Compose, чтобы избежать случайной подписи документа.
Стажировка – отличный способ привлечь в команду новых специалистов. Но ее организация требует много ресурсов. И чтобы эти затраты принесли ценность, нужно учесть множество факторов.
Мы проводим летние стажировки в Центре ИИ 6 лет. С 2018 года 80% принятых на стажировку остались с нами после ее окончания. А 60% из них – работают до сих пор и обучают новые поколения стажеров.
В этой статье расскажу, что мы делаем, чтобы стажировка приносила команде пользу.
Меня зовут Настя Миронова, я менеджер разработки в Контуре и уже около двух лет руковожу командой Рейнджеров – это разработчики без своего продукта, такие мобильные инженеры. Команда появилась в конце 2020 года, и за это время мы постоянно исследуем, чем можем помочь проектам компании, как делать это еще лучше, и как вырастить или найти ребят, постоянно готовых к вызовам.
Думаем мы не в одиночку – в компании развиты механизмы и практики горизонтальной мобильности, которые помогают в переходах между продуктами, командами и даже ролями.
Об этом и расскажу в статье с примерами коллег.
Давным-давно, во времена, когда по Земле бродили цифровые динозавры, а разработчики .NET ещё помнили, зачем нужна технология WebForms (и какие у неё были проблемы с производительностью), в Контуре появился продукт под названием Фокус, предназначенный для проверки контрагентов. И у этого продукта довольно быстро появился API, ориентированный на крупных клиентов.
ASP.NET MVC был ещё в новинку, до появления WebAPI оставались годы, и отцы-основатели проекта приняли вполне актуальное, с учётом реалий того времени, решение: делать API на базе ashx-хендлеров, чтобы максимально повысить скорость работы.
Шли годы, .NET Framework сперва меняла версии как ветреная красавица перчатки, а потом и вовсе перешла в разряд «для поддержки жизнедеятельности требуется опытный некромант», .NET Core сперва появился, а потом благополучно переименовался в просто .NET, дорос до 6-й, а потом и 7-й версии… а API Фокуса всё ещё жил по старому, доброму принципу «работает — не трогай». И вот, наконец небосвод провернулся, и звёзды сошлись в нужной позиции. Мы поехали на .NET 6.
Оговорюсь сразу, что сам переезд произошёл примерно полгода назад, когда .NET 8 ещё находилась в стадии альфы. Именно поэтому в качестве целевой версии .NET была выбрана именно стабильная 6-я. Тем не менее большинство проблем будут актуальны и при миграции на 8-ю версию.
В мобильных приложениях всё больше локальной логики, всё меньше приложений выполняют функцию тонкого клиента для простого отображения данных с сервера. Описание этой бизнес-логики в виде конечных автоматов позволяет сделать код более надёжным и читабельным, а визуализация графа состояний конечного автомата помогает избежать фрагментарного видения бизнес-процесса у разработчиков.
Разработчикам граф помогает понимать код, а тестировщикам — писать тестовые сценарии. Поскольку у нас есть информация о состояниях и переходах, можно сформировать другое представление графа, которое позволило бы оценить покрытие бизнес-логики инструментальными тестами. Это поможет тестировщикам измерить процент покрытия и то, каких тестовых сценариев не хватает. Возможно, даже даст понимание, что есть какие-то кейсы, которые были пропущены во время ручного тестирования.
