Дизайнер интерфейсов
Привет, Хабр! Меня зовут Андрей, руковожу проектами в РСХБ-Интех. В бэкграунде 6 лет управления проектами, портфелями проектов в интехе, ритейле, сертификация PME, PRIME. Сегодня я хочу рассказать о редком успешном кейсе использования метода быстрого прохода, и что это дало заказчику.
Итак, погнали!
Почему я решил написать эту статью?
Поработав в нескольких крупных ИТ компаниях на позициях руководителя проектного офиса, я поучаствовал в реализации различных архитектур управления проектами и портфелями. Важную и проблемную часть при этом составляли системы планирования – при кажущейся простоте и широком спектре решений на рынке. Проблема заключается в том, что планирование в компании - это несколько процессов:
• краткосрочное планирование (спринты),
• планирование проектов (контрактов),
• планирование загрузки ресурсов
• и наконец финансовое планирование (квартал, год и т.д.).
Все эти процессы связанны между собой, но в практике не реализуются в одной информационной системе. Поэтому хочу поделиться о своем опыте, удачных архитектурных решениях, которые в итоге позволили сделать более эффективными процессы управления проектами, бюджетирования и финансового планирования, благодаря интеграции различных процессов планирования.
Привет! Меня зовут Катя, я руководитель команды технических писателей в Ozon.
Недавно разбирала внутренние документы компании и поняла, что есть некоторая путаница в головах — не всегда понятно, что за документы должны быть в компании и кто их должен писать.
Привет, Хабр! Начинаю еще один цикл статей об устройстве PostgreSQL, на этот раз о том, как планируются и выполняются запросы.
Предыдущие циклы были посвящены изоляции и многоверсионности, журналированию и блокировкам.
В этом цикле я собираюсь рассмотреть этапы выполнения запросов, статистику, последовательное сканирование, индексное сканирование, соединение вложенным циклом, соединение хешированием, сортировку и соединение слиянием.
Материал перекликается с нашим учебным курсом QPT «Оптимизация запросов», но ограничивается только подробностями внутреннего устройства и не затрагивает оптимизацию как таковую. Кроме того, я ориентируюсь на еще не вышедшую версию PostgreSQL 14. А курс мы тоже скоро обновим (правда, на версию 13; приходится бежать со всех ног, чтобы только оставаться на месте).
Автоматизация процессов разработки и тестирования программного обеспечения (ПО) — лучший способ уйти от рутины и заняться действительно интересными задачами. Азарт от реализации новой функции может быть погребен под рутиной сборки, подготовкой и выпуска нового релиза. Как избежать этой неизбежной скучной задачи, но выпустить релиз ПО, не упустив при этом ни одной мелочи при его подготовке?
Выпуск релиза ПО — это не только сборка ПО в определённого формата пакет и отправка пакета на место его установки. Зачастую выпуск релиза включает в себя множество других задач, таких как:
Эджайл – это модно или полезно? Не знаю, как бы мы ответили на этот вопрос года три назад, а сейчас однозначно: это полезно и нужно! Именно благодаря Agile-подходам нам удалось успешно воплотить довольно давнюю идею и запустить в компании важнейший проект по созданию хранилища мастер-данных «М.Каталог». Но дело не столько в нем – кардинально изменились мы сами, что еще не раз покажет себя на новых проектах. Попробуем описать, в чем заключаются эти перемены и чем они полезны.
Из этой статьи вы узнаете о возможностях работы геолокации, когда приложение свёрнуто или закрыто; о тонкостях работы с авторизацией; о нововведениях в iOS 15, затрагивающих геолокацию.
Photo by Brooke Cagle on Unsplash
Вы читаете третью статью из серии «Дизайнер и метрики». В первой мы поразмышляли, нужны ли продуктовому дизайнеру метрики, а во второй посмотрели, какие вообще бывают метрики. Если вы ещё не читали эти статьи, то советую начать с них.
В этой статье речь пойдет о том, как ответить на вопрос, улучшили мы продукт или нет.
После раскатки нового функционала каждый дизайнер спрашивает себя: что изменилось? Удалось ли нам улучшить продукт?
Чтобы ответить на эти вопросы, нужно посмотреть, как изменились метрики после релиза функционала. Ведь зачастую результат работы дизайнера — это разница между метриками до релиза нового функционала и после него.
На первый взгляд кажется, что сравнить эти метрики очень просто: посмотрел на цифры до релиза и после, сравнил одно с другим, и если стало лучше — значит, все было не зря, а если хуже, то все надо переделывать.
Но такой подход часто ведет к ошибкам — поэтому прежде чем прыгать к выводам, нужно обратиться к математике и немного посчитать.
В нашем блоге мы много пишем о карьере в сфере ИТ, но обычно раскрываем темы, связанные с поиском работы инженеров и программистов. Сегодня же речь пойдет о том, как устроен процесс собеседований дизайнеров в топовых ИТ-компаниях – уровня FAANG (Facebook, Amazon, Apple, Netflix, Google). Поехали!
История кнопок в картинках от head of design Дмитрия Уколова: текстовые ссылки, скевоморфизм, Flat и Material design.
