Привет! Меня зовут Семен Ананьев, я solution-архитектор в Газпромбанке. За девять лет в разработке я насмотрелся на одну проблему, которая встречается практически везде.
Хочу обсудить разорванный ландшафт компании — ситуацию, когда бизнес и IT существуют в параллельных вселенных. Бизнес не понимает реальных возможностей технологий, IT не видит конечных целей. В итоге получается дорого и бестолково.
Рассказываю, как мы внедрили КЭДО у себя и почему теперь считаем, что это must have для удалённых команд.
Достаточно часто встречается заблуждение, что просто нужна «ещё одна серебряная пуля» и тогда точно наступит «вселенский коммунизм«. Многие в качестве такой «волшебной палочки» воспринимают таск-трекеры различной степени сложности. Стоит только внедрить, и «бизнес крутится, лавэ мутится«.
Всем привет! Меня зовут Алексей, я — Head of PMO and Delivery крупной восточно-европейской компании, но эту статью я писал в роли проектного менеджера работающего с большими международными командами и клиентами пять лет назад в не менее большой и международной компании. На тот момент, я занимался управлением проектами как в продуктовых, так и в сервисных компаниях более восьми лет. В те годы я управлял проектами в сфере e-commerce, работая с командами, распределенными по всему миру (США, Великобритания, Италия, Румыния, Словакия, Колумбия, Болгария, Индия, Чехия).
В статье разберем ТОП фишек Zoom, которые сделают проведение ваших планёрок и встреч проще и эффективнее. Это не обзор всех возможностей Zoom, а только тех фишек и лайфхаков, которые мы сами каждые день используем в работе. Перейдем сразу от слов к делу.
Проблема: культ «продуктивности разработчиков» (velocity, строки кода, story points) слабо связан с деньгами и ведет к spray-and-pray, раздуванию фич и росту KTLO.
Идея: сместить фокус с output на outcome/impact через Impact Intelligence и impact-сети: явные связи proximate-метрик (рядом с фичей) с downstream-метриками бизнеса.
Два рычага:
Robust Demand Management (RDM) — жёсткий отбор инициатив вопросами: проблема, доказательства, ожидаемые proximate/downstream-эффекты, горизонт, уверенность, допущения, как меряем, риски, альтернативы.
Impact Validation (далее…)
Дисклеймер: статья написана на основе интервью с DevOps-инженером В. Ивановым.
Мне 25 лет, и я работаю DevOps-инженером четвёртый год. Начинал системным администратором.
За это время сменил 5 работ. Первые три был сисадмином. На четвертой работе я был уже DevOps.
С каждым переходом добавлял новые технологии в стек, брал более сложные задачи.
Если в вашей практике налажен процесс передачи знаний от команды другой команде, от коллеги команде и т.д. То прошу бегло пробежаться по статье. В противном случае — если ваша команда испытывает трудности в передаче/получении знаний, то прошу уделить 5 минут вашего внимания публикации.
