Привет! К определению сущности ИТ-бизнес-партнёра зачастую возникает больше вопросов, чем к названиям большинства других должностей. Для рядового сотрудника порой куда понятнее, чем занимается тот же scrum-мастер или agile-коуч. А вот с ИТ-бизнес-партнёром всё иначе: кто-то думает, что это такой аналог классического продуктолога, который просто чуть более вхож в руководящие круги. Другие считают, что это просто перемычка между бизнесом и чистым ИТ, мол, коммуникации такого рода не автоматизируешь, так что вот, пусть должность будет для живого человека.

В этом посте мы постараемся объяснить, чем же именно занят ИТ-бизнес-партнёр на работе, что входит в его обязанности, какими качествами он должен обладать. И сделаем мы это на живом примере: меня зовут Светлана Евстигнеева, я ИТ-бизнес-партнёр блока розничного бизнеса Московского кредитного банка (МКБ).

Привет! Как мы уже не раз рассказывали, СИБУР поделен на несколько сквозных процессов. Сквозные процессы – это бизнес-домены, которые объединяют в себе бизнес-команды одной сферы. У нас таких много, но конкретно этот пост будет посвящён дашбордам для O2C. 

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

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

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

Привет!

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

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

Нарезая задачки по бизнес-ценности, мы столкнулись с двумя типами проблем:

- максимально мелко нарезанные задачи все еще большие,
- разные бизнес-задачи завязаны на общие изменения.

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

- по типу работ,
- по слоям приложения,
- выделяя базовые функции.

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

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

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

У Национальной Медиа Группы есть много  ТВ-каналов — СТС, Че, Dомашний, Пятый, РЕН ТВ и многие другие. Само собой, у каждого канала есть свой сайт, на котором транслируется соответствующий видеопоток. И не ТВ-каналами едиными: ещё есть онлайн-кинотеатр more.tv со своими особенностями.

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

В прошлом месяце мы выпустили первый срез по IT-рынку, смотрели на активно нанимающие компании и вакансии в мае — тогда компании разместили 4438 вакансий, а лидером стала Bell Integrator, у которой можно было откликнуться на 236 вакансий. В июне лидер сохранил свою позицию, но в тройке активных работодателей появился новый игрок. 

Еще один важный спойлер: в этом рейтинге мы выделили вакансии, которые получили в июне самое высокое количество откликов — подумали, что вам будет интересно узнать, куда хотели попасть специалисты. 

1. Сравнение размера Вселенной в 3D
2. Измеряем богатство Джеффа Безоса в рисе

Привет! У нас в Спортмастере очень большая экспертиза в части работы с инструментами JIRA. Про доски, спринты и все прочее все наверняка знают и часто применяют. Мы хотим рассказать о других интересных плагинах, которые мы используем в рамках управления продуктом, начнем с JIRA Structure.

Зачем это нужно?

Structure — плагин для Jira, позволяющий гибко настраивать и управлять Jira-задачами любого типа.

Основные возможности:

Привет, Хабр!

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

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

Для хранения потоковой информации использовать структуру под названием log. Название вам знакомо, и не случайно вы с ней сталкиваетесь, читая консольный вывод приложений. Суть в том, что log – это просто упорядоченная во времени последовательность объектов. Когда происходит событие, мы можем просто добавлять его в конец лога с небольшим описанием происшедшего. Это скажет нам о том, что это событие произошло в определённое время относительно других событий. Всё это выглядит достаточно просто.

На Хабре уже много статей о любительской астрономии, но мне пока ещё не встречались статьи о вентиляции (охлаждении, терм стабилизации) телескопа. Про то, зачем это нужно, написано, например, тут и тут. Вкратце, проблема в том, что если ГЗ (главное зеркало) телескопа теплее, чем окружающий его воздух, над ним возникает конвективный поток, который заметно портит изображение. Звёзды обзаводятся асимметричными "лучами", а протяженные объекты (планеты) теряют чёткость и контрастность. Маленькие телескопы довольно быстро остывают сами, а большие, особенно закрытой конструкции (такие, как Шмидт-Кассегрен), Требуется охлаждать принудительно. Самый простой и естественный способ - продувка ГЗ и трубы компьютерными кулерами. Редкие модели крупных ШК оборудованы кулерами, поэтому приходится сверлить дырки. Считаю тему достойной Хабра: тут и разработка электроники, и Ардуино, и 3D печать. Эта статья - адаптация того, что я писал на Астрофоруме год назад, всё никак руки не доходили до Хабра.

Девайс назвал CoolScope. Потому что от клёвый, охлаждает, и эта надпись влазит в экранчик. Все чертежи, схемы и код прошивки выложены на гитхабе.

Привет! Мы написали свою систему диплинков на основе кодогенерации. В этой статье поговорим, как мы упростили работу с диплинками и смогли отловить устаревшие, добавили мониторинг и как собрали все диплинки в одной статье в конфлюенсе.

Диплинк — это uri на конкретный ресурс в приложении. Они нужны бизнесу, чтобы упрощать пользовательский опыт. Так вместо нескольких переходов внутри приложения диплинки позволяют направить пользователя на определённый экран в один клик (польза для пользователя) и снимать статистику (польза для бизнеса). Например: на внешней площадке компания разместила баннер, в котором предлагается заказать виртуальную карту, пользователь может кликнуть по баннеру и сразу попасть на экран заказа карты, а бизнес сможет оценить, какая из площадок более эффективна.  

Самая большая проблема — это проблема безопасности. Объясню на примере активити, которая открывает веб-страницы. Активити открывается по диплинку, в нём указывается URL в качестве параметра. Один из вариантов атаки — когда злоумышленник может заставить пользователя пройти по диплинку с URL на вредоносный сайт и таким образом провести атаку. Ещё одна из возможных проблем — на некоторых экранах нам нужно валидировать параметры, а это иногда занимает значительную часть активити. Было бы хорошо вынести валидацию в отдельное место. 

Ещё у нас бывали случаи, когда маркетинг запускал промо-кампании либо с диплинками, в которых содержались ошибки, либо с устаревшими диплинками, которые уже не поддерживались, и мы могли об этом даже и не узнать. А при заведении новой кампании маркетинг обращался к разработчиками за диплинками и поиск занимал некоторое время. Если разработчик помнил название экрана и диплинк без параметров, то его можно было быстро найти, а если название экрана сразу не вспомнилось, то алгоритм поиска примерно такой: сбилдить проект -> пройти на нужный экран -> посмотреть в логах, какая активити открылась -> пойти в манифест для получения диплинка -> открыть исходных код активити для сбора входных параметров.

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

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

На самом деле, сетку прогнозируют, формируют и постоянно актуализируют специально обученные люди из программного департамента.

Первые версии (v1 ~ v3)

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

Часто такой сервис отвечает за конкретную небольшую фичу в нашем продукте (или вообще за часть фичи), или же за часть какого-то большого процесса. Нам такой подход нравится, поскольку микросервисы имеют независимые жизненные и релизные циклы, мы можем релизить фичи независимо друг от друга. Кроме того, различные команды могут работать в рамках одного продукта параллельно над разными фичами, не мешая друг другу и не сталкиваясь лбами. Это даёт нам возможность независимо масштабировать микросервисы и гораздо быстрее проверять гипотезы. В общем, плюсов много. 

Сейчас будет «Но», правда?

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

К хорошему быстро привыкаешь, причём иногда настолько быстро, что кажется, будто какая-то полезная штука с тобой уже чуть ли не всю жизнь. С дистанционным банковским обслуживанием такая же история: по ощущениям ДБО – это уже чуть ли не стандарт, который обязательно должен быть у всех. Хотя на самом деле эта опция не так давно отметила десятилетие. За все годы развития ДБО постоянно обрастало новыми возможностями: сначала можно было просто оставить заявку на открытие счёта, затем открыть сам счёт, оформить дебетовку (а потом и кредитку). Сейчас так же просто можно оформить ипотеку или взять срочный кредит.

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

Отдельно тут можно отметить пандемию, когда в условиях карантина и удалёнки популярность ДБО многократно возросла. Мы в МКБ в это время потихоньку готовили ряд новых возможностей и планировали выкатывать их постепенно, но надо было подстраиваться под новую реальность и форсировать процесс. Сейчас наша система обслуживания клиентов построена так, что человек де-факто может посетить офис МКБ лишь один раз, после чего ему в дистанционном формате будет доступен весь спектр наших банковских услуг. Причём что в мобильных приложениях, что в веб-версии – объём функций практически идентичен.

Но этого поста бы не было, если б на пути ускоренного расширения функциональности мы не встретили его – стремительно растущий набор регрессионных кейсов.

Меня зовут Егор и в этом посте я расскажу, как мы наладили регрессионное тестирование, на примере собственно ДБО, а также одного из важнейших столпов качественного дистанционного обслуживания — нашей CRM.

Разработка ПО — довольно формализованная (в хорошем смысле),и активно развивающаяся отрасль, работающая с нематериальными результатами интеллектуальной деятельности. Есть лучшие практики больших компаний, есть опыт стартапов. И те и другие во многом стремятся использовать современные методологии разработки ПО, которые часто дорабатывают под себя. Ведь они обеспечивают собранность, систематизированность и прозрачность данных, помогают видеть процесс от А до Я, отслеживать эффективность и прочее, прочее, прочее.

Я не так давно пришёл в современное IT (около полугода назад), но за это небольшое время успел оценить, какую пользу приносят передовые практики управления разработкой, собственно, разработке. Я был приятно удивлен и слегка ошарашен. Настолько, что подумал — а почему бы не применить все это хозяйство к чему-то “не айтишному”? Скажем, к малому бизнесу, а именно - мелкому ритейлу товаров на маркетплейсах (МП)? 

Тут необходима ремарка. У меня давно была мечта: вне зависимости от места работы я хотел иметь свой маленький бизнес, который я буду параллельно выстраивать и развивать. Поэтому сейчас в отрыве от основной работы я продавец на одном из маркетплейсов.