Agile *

Ниже представлен перевод руководства Google re:Work — Guide: Set goals with OKRs. Я решил не писать с нуля еще один общий обзор по OKR, а просто перевести это, на данный момент, наиболее авторитетное руководство по OKR, и дополнить его ссылками и своими материалами по OKR, которые включают в себя несколько конспектов приложенного видео Google Ventures на русском языке.

Дополнение: В ноябре 2017 года Рик Клау написал серию твитов, где существенно поправляет некоторые моменты из своей презентации 2012 года, видео которой представлено ниже: Google OKR Video пять лет спустя — обзор опыта Google Ventures по внедрению OKR (2012-2017)

Введение

Исследования показали, что приверженность цели помогает повысить производительность труда. Если посмотреть более глубоко, исследования обнаруживают, что постановка вызывающих и четко определенных целей может еще более повысить вовлеченность сотрудников в достижении этих целей. Google часто использует “цели и ключевые результаты” –  “Objectives and Key Results” (OKRs), стараясь поставить амбициозные цели и отследить продвижение к ним.

OKR – краткий обзор

• Цели амбициозны и могут ощущаться несколько некомфортными
• Ключевые результаты измеримы и должны быть легко оцениваемы числом (Google использует шкалу от 0 до 1.0)
• OKR являются общедоступными, так, что каждый внутри организации может видеть, над чем работают другие
• “Попаданием в яблочко” для предварительной оценки OKR является достижениие 60-70% от нее. Если кто-то раз за разом полностью достигает своих целей, значит их OKR недостаточно амбициозны, и им нужно думать более масштабно.
• Низкие оценки следует рассматривать как данные для уточнения дальнейших OKR.
• OKR не являются синонимом оценки сотрудников.
• OKR не являются коллективным списком следующих дел.

Негибкий “Энтерпрайз” и гибкие методологии

Существует устоявшееся мнение, что IT-специалист в крупных компаниях — это маленький “винтик” в огромном механизме, призванный выполнять какую-то конкретную функцию. А механизм, в свою очередь, беспощадно эксплуатирует ресурс своих “винтиков”.

Однако мы (в Альфа-Банке в целом и в Альфа-Лаборатории в частности) придерживаемся иного подхода. Подхода, когда усилия всех участников процесса направлены на создание ценности для клиента, при этом путь, которым они этого достигают, может содержать очень много степеней свободы.



Я расскажу, как у нас в Лаборатории выстраиваются процессы работы. Мы опираемся на концепцию Agile. В качестве основного фреймворка мы выбрали Scrum, модель производства — командно-центричная.

Управление проектом в любой сфере предполагает наличие дедлайнов. Есть главный, венчающий собой всю работу и говорящий о его завершенности/незавершенности. Как правило, планы включают в себя и другие дедлайны для этапов поменьше.

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

1. Что такое качество в разработке ПО?
2. Во сколько нам обходится некачественное ПО?
3. Кто отвечает за качество?

Для меня поводом задаться этими вопросами стала встреча с компанией в которой 3 месяца в году всё подразделение разработки (около сотни человек), занято устранением ошибок и дефектов, а остальные 9 месяцев они пишут ошибки софт для Заказчиков.

Ниже результаты моих теоретических и практических исследований в поисках ответов. Постарался изложить их просто, без «мозговзрыва» присущего этой теме.

Данный материал — перевод статьи за авторством Matthew Heusser, Managing Consultant в Excelon Developmen. Редактура — Ирина Махмутова.

Почему руководство не принимает agile и что вы можете с этим сделать

Первый в моей практике переход в agile имел полную поддержку высшего руководства компании. Топ менеджмент обеспечил финансирование всех необходимых тренингов, инструментов и консалтинга.

Руководители провели встречи со всеми сотрудниками компании, на которых разъяснили новый подход к работе и то, как изменятся документирование, разработка и структура команд. Правда была одна странная штука: проектные планы, управление портфелем и бюджетирование должны были остаться прежними, не говоря уже про HR и финансы. С тех пор я слышал эту историю много раз, разница была только в деталях — что именно должно было остаться неизменным. При этом все (за исключением может быть пары executives)) согласно кивали.

Наши топы часто тратят уйму времени и денег на agile, но при этом дискредитируют инициативы, которые продвигают. Это не просто частая проблема; это практически всеобщая проблема, а всеобщие проблемы склонны иметь системные причины.

Я приведу пять самых распространенных причин, почему топы не получают agile — и что с этим делать.

Enterprise Agile: Поторопитесь ускориться быстрее

В следующие несколько абзацев хочу поделиться не так давно случившимся у меня опытом проведения ретроспективы по методу шести шляп. Метод шести шляп (англ. Six Thinking Hats) — метод организации мышления, помогает взглянуть на проблему с разных сторон, а также одна из разновидностей мозгового штурма при работе в команде.

Интересно будет тем, кто ищет новые способы проведения ретроспектив, кто интересуется командной работой, подходами к принятию решений и генерации идей.

Цель текста — рассказать, что такой метод есть, на основе простого примера показать, как его можно использовать для организации ретроспективы; вызвать интерес у читателя для дальнейшего самостоятельного изучения этого метода.

Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.

За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.

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

Что самое важное в организации команды? Может построить планы?

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

Что делают успешные команды и чего не делают разваливающиеся за неделю? Что важнее — назначить на каждую задачу исполнителя или проставлять дедлайны, а может самое важное ставить приоритеты? Есть ли действие, которое значительно увеличивает срок жизни проекта?



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

23 мая в питерском офисе Wrike прошла встреча для scrum-мастеров и project-менеджеров. Мы поговорили о реальном применении скрама в IT-разработке, инструментах scrum-мастера, взамоотношении компонентных команд с бизнесом, о целеполагании в условиях разработки по Agile и многом другом. Спешим поделиться видеозаписями докладов.

Узнаете себя? А может, другие из-за вас чувствуют себя так?

Групповой чат похож на непрекращающееся совещание со случайными участниками и без повестки дня. Так считает Джейсон Фрайд, знаменитый сооснователь компании 37signals, автор бестселлеров Getting Real и Rework. Мы в Alconost перевели для вас его статью с анализом плюсов и минусов групповых чатов. Небольшой спойлер: минусов оказалось в несколько раз больше.

Половина успеха в управлении проектами — постановка целей, и это не самая простая половина. Мы в Wrike в свое время основательно озаботились выбором оптимального подхода к целеполаганию на уровне всей компании и отдельных команд, и в итоге остановились на OKR. Изначально концепция Objectives & Key Results (цели и ключевые результаты) зародилась в Intel, но действительно популярной ее сделал Джон Доерр из Google.

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

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

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

Муха дрозофила. Источник

Оставим в стороне книги и маркетинговые изысканя про agile-методологии и встретимся 23 мая в питерском офисе Wrike поговорить о реальном применении скрама в IT-разработке. Участники поделятся как успешными, так и не сработавшими практиками, обсудим, как проходят скрам-ивенты в различных компаниях, какие техники и инструменты применяются. Встреча будет интересна для практикующих scrum-мастеров и сочувствующих. Помимо докладов, планируется дискуссия по темам митапа в неформальной обстановке.

Название этой статьи частично позаимствовано из одного популярного спектакля и кинофильма. «Дальше не придумали, импровизируй» – после этой фразы в фильме звучит нецензурная реакция человека, который понял, что импровизировать придется именно ему. В этой ситуации когда-нибудь оказывался или окажется каждый профессионал, работающий в сфере информационной безопасности. Это тот самый момент, когда ты встал у руля ИБ в организации нового для тебя профиля, когда в структуре компании происходят изменения уровня слияний и поглощений, или когда внезапно в 8 вечера пятницы начинают раздаваться звонки с сообщениями о неработающих банкоматах… Именно тогда в голове начинает звучать этот голос, дающий единственно верное направление дальнейших действий.

Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе, который поможет структурировать каждый этап проекта и учитывать все поставленные задачи. Речь идет об иерархической структуре работ WBS (Work Breakdown Structure).

В качестве предисловия

Ты сидишь перед монитором, разбираешь утреннюю почту, и вдруг воздух вокруг начинает дрожать.

— Что происходит?!

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

— Где я? Что это за место?

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

— Приветствую, %UserName%, ты в оплоте магов! Мы знаем, что ты способен пользоваться Источником Силы. Я расскажу тебе о нем. Источник содержит пять Сил — Земля, Воздух, Вода, Огонь и Дух. Земля олицетворяет устойчивость, Воздух — свободу, Вода — изменение, Огонь — мощь, Дух — дисциплину. В большинстве случаев для выполнения необходимого действия вполне достаточно какой-либо одной части из пяти. Так потоки Огня позволяют зажечь свечу и контролировать горение пламени. Но более сложные задачи требуют плетения потоков из большего числа Сил. Для примера, тому, кто захотел бы воздействовать на погоду, потребовалось бы сплести одновременно потоки Воздуха, Воды и Духа. Но для того, чтобы начать обучение, тебе придётся пройти испытание...

Я работаю с большими компаниями, которые пытаются применить Agile, начиная со Scrum. Хотя каждая организация находится в своем секторе, использует разные технологии и имеет свою культуру управления, у всех была одна общая болезнь — своего рода «гигантизм». В этой статье содержится список общих проблем гибкости в больших организациях и исследуется возможность избежать симптома «гигантизма».

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

Одна из очень известных компаний, которая была примером успешного применения Scrum в 1997 году, обратилась за помощью в Danube Technologies, Inc. в 2009 году, потому что «рынок» показал, что они оказались менее гибкими, чем конкуренты. Начинания по внедрению Scrum, которые начались 1997 году, по-видимому, не могли выдержать десятилетие сосуществования с проблемами, присущими крупным предприятиям. К сожалению, большинство попыток внедрить Scrum в крупных организациях не приводит к долговременным преобразованиям. Препятствия для внедрения Scrum обычно также мешают достижению успеха в бизнесе в целом, а устоявшиеся организации обычно неохотно избавляются от них.

Препятствие #1: Наивный менеджмент ресурсов

В Руководстве PMBOK написано:

«зачастую возникает необходимость увеличения бюджета, чтобы добавить дополнительные ресурсы для выполнения того же объема работ в более сжатые сроки»

В отношении программного обеспечения, Фред Брукс (в книге «Мифический человеко-месяц») дает утверждение, которое противоречит предыдущему:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»

Чтобы разрешить этот парадокс, давайте рассмотрим определение «ресурса».

Наряду с развитием механических систем автомобиля инженеры постояно стремились добавить что-то в электроную начинку, сделать машину безопаснее, управляемее и умнее. Сегодня для этого есть все предпосылки: ИТ-отрасль развивается огромными темпами, автопроизводители готовы сотрудничать и вести перспективные разработки, корпорации вкладываются в развитие автотранспорта. Между тем, «ум» автомобилей развивался поступательно, на протяжении более полувека. Всё это время он принимал разные формы и уходил в разные концепции: от безопасности до развлечений. Современый виток эволюции зашёл так далеко, что уже непонятно, софт определяет железо или железо — софт. А значит, пора написать об автомобилях на Гиктаймс