Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.
Дисклеймер: понимаю, что тема холиварная, и с точки зрения строгой методологии нужно выбрать между оценкой по времени или по сторипоинтам и не пытаться поженить одно с другим. У нас в компании допустимы разные варинты и я, как тимлид, очень рад, что такие решения даются на откуп юнитов и отдельных команд — можно настроить процессы под свою команду и свои задачи.
Здесь хочу поделиться своей логикой и тем, как искал аргументы, чтобы реализовать свой эксперимент. Любые менния по теме приветствую в комментариях.
Разные компании по-разному оформляют свои политики конфиденциальности — единого формата нет. Подавляющее большинство из них написано тяжелым юридическим языком, поэтому многие даже не пытаются изучать их, например, чтобы понять, как тот или иной сервис будет работать с персональными данными.
Есть множество инициатив, призванных повысить прозрачность таких документов: от унифицированных иконок на сайтах до браузерных расширений, и новые проекты продолжают появляться. Мы решили взглянуть на ситуацию со стандартизацией политик конфиденциальности и обсудить, нужен ли им единый формат.
Привет! Я Максим Коровенков, DevSecOps Lead в Купере (ex СберМаркет). Хочу поделиться мыслями по поводу минимально необходимого набора процессов, сопутствующих внедрению сканеров безопасности в пайплайны разработки.
В результате попытаюсь ответить на вопрос: «А что, собственно, стоит иметь в виду под фразой “Мы внедрили сканеры безопасности в пайплайны разработки”?»
Да, в тысячный раз про пайплайны, но, как вы, думаю, догадываетесь, желание поделиться казалось бы очевидными мыслями появилось не случайно! Не так давно я завершил найм и укомплектовал свою DevSecOps-команду. В рамках поиска пришлось провести достаточное количество интервью, на которых я любопытствовал, как обстоят дела у соискателей с пайплайнами безопасности на текущем/предыдущем месте работы. Это удивительно, но для 90% респондентов фраза «внедрение сканеров безопасности в пайплайны» означает только факт внедрения. Лишь некоторые кандидаты упоминали отправку результатов в VMs/ASOC систему.
Ведь действительно кажется, что все просто: запаслись вокабуляром из нескольких аббревиатур, внедрили инструменты, SAST, SCA, может что-то еще, настроили отправку результатов для AppSec-ов и, как-будто, можно идти бить баклуши. Но я на своем опыте убедился, что DevSecOps — это про глубокую проработку процессов. Поэтому в данной статье сконцентрируюсь больше на процессах, нежели на технике.
Предлагаю наконец переходить к сути!
Привет, Хабр! На связи Дмитрий Секачев — корпоративный архитектор службы развития ИТ-архитектуры ВТБ. Я занимаюсь корпоративной архитектурой в дочерних компаниях банка. Сегодня расскажу вам про новый архитектурный продукт — «Референтная прикладная архитектура как АрхПродукт» (РПА как АрхПродукт).
Мы с коллегами готовим серию статей, в рамках которых вы узнаете, как применять данный продукт в процессах слияния/поглощения компаний, построения целевой прикладной архитектуры своей организации, как сократить объем «выборочных» процедур по выбору ИТ-решения и многие другие интересные аспекты применения референтной прикладной архитектуры. Поехали!
Устал от стандартного подхода к саппорту своего продукта через Jira? Надоели миллион уведомлений на почту о изменениях в таске? Раздражает скорость ответа на тикет? Тогда мы идем к тебе...
Привет всем! Меня зовут Таня Конюшенко, и я — продуктовый дизайнер в Купере. В этой статье я рассказываю о том, как открыла для себя дизайн-Discovery и внедрила его в моей продуктовой команде. Мой опыт будет полезен дизайнерам, которые много слышали о Disco, но не понимают, в чём его смысл.
Ещё год назад я ничего не знала о Discovery, потому что работала в заказной разработке. О том, в чем разница между дизайнерами в агентстве и продукте, рассказывала в своей прошлой статье.
Когда я пришла в Купер (тогда он был ещё СберМаркетом), меня сразу познакомили с понятием Discovery, но смысла я в нем не увидела. Сейчас мое отношение кардинально другое. Discovery хорош, но нужно правильно его выстроить. Мой путь к идеальным процессам был тернистым…
Но давайте по порядку. Что входит в дизайн-Discovery и чем это отличается от общего Discovery команды?
Привет, Хаброжители!
Привет, Хабр! На связи C#-разработчик компании SimbirSoft Георгий. В этой статье поговорим о том, как с помощью комментариев кода можно ускорить погружение новых разработчиков в проект, упростить написание документации и найти общий язык с коллегами-разработчиками.
Материал будет интересен как начинающим IT-специалистам, кто только учится писать чистый и красивый код, так и тем, кто отвечает за формирование кодстайла проектов. Подкреплять свои рассуждения буду примерами из личного опыта и опыта коллег. Сначала быстро пройдемся по основам, а потом откроем этот ящик Пандоры и уйдем в рассуждения.
Привет, Хабр! Я Константин Сошнев, бизнес-аналитик портфеля продуктов «Цифровой вагон» в ПГК-Диджитал. Мы занимаемся созданием цифрового двойника грузового вагона, повышаем точность информации о текущем состоянии вагона, помогаем своими инструментами снижать совокупные расходы на ремонт и увеличивать производительность вагона.
Очень часто IT-проекты фокусируются на разработке, настройке и внедрению информационной системы, упуская из вида вопросы трансформации существующих бизнес-процессов и обеспечения приживаемости продукта в рамках этих самых процессов. Это может привести к тому, что затраченные на разработку информационной системы ресурсы не окупятся и не принесут ожидаемого эффекта владельцу бизнеса. Сегодня в условиях значительного влияния различных факторов российским компаниям стоит переосмысливать расстановку границ IT-проектов и фокусироваться на приживаемости систем не меньше, чем на самой разработке.
Такой подход, в классическом понимании, можно отнести к IT-продуктам, ориентированным на результат. Основная цель – максимально полно определить функциональный набор, который должен выполнять продукт для удовлетворения изначально выявленных требований заказчика, и определить те из них, которые можно реализовать в текущем проекте.
Project scope, или границы проекта, путем декомпозиции глобальной задачи, показывают нам, какая часть конечного продукта будет реализована в текущем проекте. Проще говоря, определяем черту между тем, что реализовываем сейчас и тем, что отложим на потом или от чего вовсе откажемся. Границы проекта помогут нам не только помочь качественно спланировать объем работ, но и пригодятся для удержания непомерных желаний заказчика. Самое главное, что при определении границ проекта нужно использовать функции, а не сущности предметной области, которые могут привести к ряду негативных последствий.
Есть мнение, что ИТ-сообщество можно условно поделить на тех, кто знаком с пакетом маршрутизации FRRouting, и тех, кто никогда о нем не слышал. Мы решили обсудить его возможности, мнения комьюнити, а также отличия от пакета Quagga.
Без отечественных ИТ-решений не обходится ни один бизнес, а от эффективности российского ПО зависит стабильность и развитие компании. Однако тем, кто далек от мира информационных технологий, достаточно сложно оценить качество ИТ-продуктов, а еще сложнее выбрать ИТ-компанию, которая предложит лучший вариант по соотношению “цена-качество”.
Привет, меня зовут Марина Гончарова, я старший менеджер проектов в Купере (ex СберМаркет). Я работаю в IT с 2008 года, а проджектом — с 2015, и за эти годы у меня накопилось много знаний, приёмов и лайфхаков, которыми хочется делиться. Одна из таких животрепещущих тем — как сделать даже короткие встречи эффективными и результативными для всех участников.
При работе в разных компаниях я сталкивалась с тем, что все встречи по умолчанию ставятся минимум на час, и даже за час мы не всегда успеваем всё обсудить. 8 рабочих часов, 7-8 встреч — и вот весь день занят, а работать некогда, ну или приходится перерабатывать вечером. Лёд тронулся во время пандемии, когда компании перешли на удалёнку, и стало ясно, что с таким обилием часовых встреч нужно что-то делать.
Началась практика встреч на полчаса, но чтобы уложиться, обсудить только важное, и не уйти с открытыми вопросами, такие встречи нужно проводить по определённым правилам. И я подумала, что может быть полезно эти правила сформулировать и рассказать. Вам может показаться, что эти правила — это базовая база, но мне ни разу не попадались ни статьи на эту тему, ни в книжках я не видела лаконичного описания этой базы.
Цифровая трансформация 一 одна из 5 национальных целей развития страны до 2030 года. В ее реализации участвует сразу несколько государственных органов и организаций, среди которых АНО «Аналитический центр при Правительстве Российской Федерации», АНО «Цифровая экономика», а также Минцифры РФ, второй год подряд выпускающие объемное исследование под названием «Белая книга цифровой экономики».
«Белая книга цифровой экономики 2023», представленная 19.06.2024, содержит информацию по национальной программе, государственным услугам и сервисам, направлению ГосТех, развитию высокотехнологичных направлений, инфраструктуры, кибербезопасности, нормативному регулированию и другим. Представляем вашему вниманию выдержки из нескольких направлений исследования.
Встречаем по одежке, а провожаем по уму или что такое мягкие навыки?
Привет, Хабр!
Сегодня я хочу погрузиться в методики оценки мягких навыков, которые используют работодатели. В мире, где роботы еще не захватили господство, именно soft skills — те самые «мягкие» навыки, могут стать ключом к вашему офферу.
Привет!
Коротко о себе:
Мой опыт в разработке ПО насчитывает порядка 18 лет, и 6 из них пришлись на работу в качестве Data Scientist. За это время я прошел путь от научного работника, аналитика данных, дата-сайентиста до Chief Data Scientist в банке. Сейчас я работаю в Синимекс, мы занимаемся разработкой ИТ-систем для бизнеса.
В этой статье я бы хотел обозначить и обратить внимание сообщества на проблемы, а также побудить коллег по Data Science инженерии подключиться к инициативе развития MLOps, чтобы совместными усилиями улучшать IT- ландшафт.
Введение
Представление моделей бизнес‑процессов на основе онтологий (онтологическое моделирование) эквивалентно Semantic BPM. Введение в семантический BPM (Business Process Management) см. «Semantic BPM. Семантика и синтаксис бизнес‑процессов» [semBPM24]. Если кратко, то можно провести аналогию: если классическая BPM система (BPMS: ARIS, бизнес‑студия, fox‑manager и т. п.) — это технологический аналог mediawiki (wikipedia), то Semantic BPM — это технологический аналог semantic mediaWiki (Wikidata), т. е.
IF MediaWiki → Semantic MediaWiki then BPM (ARIS, BPMS, EA) → Semantic BPM
Основной замысел (цель) семантического представления процессов (BPM, EA) не классическими BPM‑системами, а семантическими (Linked Data) — такой же, как и у семантических wiki
Одно из ключевых дополнений к wiki‑гиперссылки (html) это указание не просто что «ОбъектА связан с ОбъектомБ» (т. е. просто «связано») и соответствующий кликабельный переход (wiki‑ссылки, markdown syntax), а указание, что «ОбъектА связан с ОбъектомБ» такими‑то типом отношения (впрочем, как и задание других свойств объекта через отношения).
Изначально все BPMS (изначально называемые CASE‑средствами) — семантические, т.к. их суть — это отношения между объектами, только в них семантика глубоко спрятана «под капотом» BPMS и нестандартная (собственная, проприетарная). Semantic BPM «поднимает» семантическую составляющую на поверхность (возможность работы с семантическим слоем) и использует стандартные сематические технологии Linked Data.
В основе RDF (Resource Description Framework) — триплеты «субъект — отношение — объект» лежит ERD: Entity Relationship (ER) diagram. RDF \ ERD — это способ формализации знаний на основе атома знания — триплета. Вообще ER, subject, predicate, типы рассуждений и другие базовые элементы для работы со знаниями в СССР содержались в школьных учебниках [Логика54].
Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так?
Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения.
Задача была такова – реализовать массовое управления биржевыми ордерами, причём не только в рамках одной биржи, а в целом по всей планете. И чтобы оно точно отработало.
В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.
Привет, Хабр! Это Оля Муттер, руководитель IT-проектного офиса в Купере (ex СберМаркет). Жизнь заставила меня научиться настраивать процессы как боженька. Я стартовала карьеру в роли бизнес-аналитика, доросла до директора продукта в финтехе, успела побывать наставником для проджектов, создать несколько проектных офисов и центров компетенций — всего за десять лет.
Сейчас я рулю проектным офисом в Купере (ex СберМаркет) — это 1300+ человек в IT-команде. Как понять, работает ли такая большая система эффективно? И что делать, если какая-то веточка этого гигантского дерева растет не в ту сторону? Об этом моя сегодняшняя статья.
Спойлер: надо дебажить процессы, а для этого придется много работать с цифрами и общаться с людьми. За это у нас в компании отвечают delivery-менеджеры.
