Йоу, всем привет! Меня зовут Анастасия, я бизнес-аналитик во внутреннем продукте Ozon по автоматизации закупок собственных товаров. Я расскажу, как мы пересмотрели ценность нашего продукта и дали ему новую жизнь.  

Внутренний продукт не видят покупатели и продавцы Ozon — с ним работают наши коллеги. В системе по автоматическому оформлению закупок они каждый день выводят заказы для поставщиков, проверяют корректность рассчитанных объёмов закупок, настраивают входные параметры закупок. Последнее, что они хотят, — тратить время на блуждание по сервисам в поисках причин ошибок и отсутствующих нужных данных. А именно этим приходилось заниматься коллегам во времена старой логики нашего продукта. Чтобы это исправить, мы с командой затеяли увлекательное «приключение на 20 минут». 

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

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

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

Статья написана на основе доклада "Под капотом SAST: как инструменты анализа кода ищут дефекты безопасности" с TechLead Conf 2022. Содержимое адаптировано для читаемости: что-то сокращено, что-то модифицировано.

В публикациях о различных уязвимостях и инцидентах информационной безопасности часто встречается аббревиатура CVE. CVE (Common Vulnerabilities and Exposures) – это список известных уязвимостей и дефектов безопасности. Рассмотрим, что он из себя представляет и какие дефекты безопасности из него были востребованы у хакеров в 2021 году.

Среди методов, привлекаемых к решению задач исследования операций (ИО) особое место занимает метод ветвей и границ (МВГ), который внес оригинальный взгляд в целом на проблемы оптимизации и позволил по другому воспринимать смысл оптимальности решений. Авторы разработанного метода предложили оценивать целевую функцию (ЦФ) задачи нижней границей целевой функции (НГЦФ) всего множества решений конкретной задачи, не получая ни всех решений, ни одного из них. Располагая такой оценкой, можно формировать решения задачи последовательно их улучшая не сильно уклоняясь от НГЦФ. В статье предлагается детальный разбор этого метода решения на числовом примере с подробными комментариями выполняемых действий при поиске оптимального решения.

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

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

Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими продуктами.

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

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

Меня зовут Артур Нек, я Канбан-консультант, основатель компании Neogenda и управляющий партнер Kaiten. В статье расскажу, как управлять изменениями, чтобы не получить поток заявлений на стол. 

Слово «ретроспектива» произошло от латинского “retro” – «обратно, назад» и “spectare” – «смотреть, созерцать», то есть буквально оно означает «Взгляд в прошлое». 

Ретроспектива в командах разработки не новое явление. После нее в идеальном мире следующие этапы работы точно будут лучше! Правда, правда. 

Всем привет, меня зовут Саша Комбаров, я исполнительный директор в веб-студии. В материале расскажу, что такое ретро, зачем и как проводить ретроспективу и как мы проводим собрания по методу «Четырех Ч». А также расскажу, как мы внедрили ретро в отделы компании: управление, дизайн, маркетинг, продажи, тестирование и аналитика. И что это дало :)

У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).

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

Данная статья - перевод с английского языка итоговой сводки по написанию требований.

Если вы создавали свой стартап, занимались маркетингом ИТ продуктов или были частью продуктовой команды, то возможно знакомы с фреймворком планирования RICE для приоритизации продуктовых замыслов, идей и фич. Но сегодня речь не о нём. Будем обсуждать альтернативную версию этого фреймворка – «RIDE».

Когда в СССР организации стали переводить на электрические калькуляторы (которые от розетки), бухгалтеры, сметчики и плановики никак не могли уйти от своих больших деревянных счёт: им казалось, что машина непременно ошибётся и за ней нужно перепроверять. Когда у них на столах появились электронные CITIZEN, они оценили удобство лёгкого беспроводного устройства и не протестовали. А вот ПК с 1С на борту вызвали едва ли не революцию. Молодые мгновенно оценили все плюсы, а старая гвардия раскололась на три части: одни шли учиться и въедливо мучили внедренцев, вторые упёрлись и решили стоять на ручном труде до последнего, третьи просто-напросто уходили на пенсию или искали работу, не связанную с компьютерами. Как ни странно, привычка до конца так и не сформировалась: и сейчас в командах компаний можно найти противников корпоративного ПО, не умеющих в нём работать, причём и 1985, и 1990, и даже 1993 годов рождения. Для них любая новая рабочая программа — источник стресса, особенно если задевается их непосредственная работа (например, автоматизируются процессы).  

Отправная точка — требования

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании. 

Понимание того, чем является архитектура и способность оценить её качество - разные вещи. Зачастую она воспринимается, как нечто неотделимое от ПО, присущее ему. Как следствие, зачастую, сама роль и ее задачи ускользают от разработчика.

В этой проблеме поможет разобраться Роман Хаимов. Он занимается разработкой ПО в практике Frontend “Рексофт”, компании, которая более 30 лет занимается разработкой ПО на заказ для российских и международных компаний. Сегодня Роман расскажет про главную задачу (или роль) любого структурного элемента в приложении. Вместе с ним мы посмотрим на простых примерах, на что влияет архитектура проекта, а также поймем, что может изменить ситуацию к лучшему.

Предметно-ориентированный подход (DDD, Domain-Driven Design) в проектировании программного обеспечения является наиболее эффективным способом моделирования бизнес-процессов. Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).

Подход к разработке фронтенда в продукте – уже давно не прихоть разработчика, а инструмент для решения бизнес-задачи. В статье простыми словами о том, почему это так, как выбор подхода зависит от назначения продукта, а также примеры использования подходов.