Трайб agile: интерьеры, материалы, мебель, акустика. Коворкинги. БЦ. – Белорусский программист в Spotify: «Работай, как хочешь,

интерьеры, материалы, мебель, акустика. Коворкинги. БЦ.

Сбербанк — крупнейший российский универсальный коммерческий банк.

Бизнес-задача

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

Организация пространства

Эксперимент по созданию современного гибкого офиса формата agile Сбербанка осуществил в новом собственном здании «Президент Плаза» на Кутузовском проспекте. Началась работа по трансформации с трех этажей (все три экспериментальных офиса от трех разных архитектурных бюро принимают участие в премии Best Office Awards 2016 – прим.ред.). Дизайн-проектом 14-го этажа занималась Aurora Group.

Офисное пространство нового типа подразумевает предельную гибкость: удобство в формировании команд, возможность самоорганизации и постоянное двухуровневое взаимодействие. Первый уровень – так называемые скводы (англ. squad) – это самоорганизующиеся рабочие группы, состоящие из 10-15 специалистов разного профиля, своего рода маленькие стартапы. Второй уровень – трайбы (англ. tribe), в которые объединяются скводы. Для четырех трайбов на этаже выделены зоны совместной работы, каждая из которых вмещает порядка 200 человек.

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

Эргономичное планировочное решение позволило сделать офис просторным и обеспечить комфортные условия для работы: удобные рабочие места по фронту остекления, зоны отдыха и неформального общения, зоны коворкинга и кофе-поинты, библиотеки и блоки с переговорным с маркерными досками на стенах и встроенными системами хранения – все в ядре офиса. На 14-ом этаже размещено наибольшее количество рабочих мест — около 750, что отвечало требованию технического задания.

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

Дизайн-идея

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

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

24 000 метра (3 этажа) были спроектированы и построены за 4 месяца.
Бюджет был в два раза ниже, чем на офисных проектах такого уровня. Поэтому поставка всей встроенной мебели, перегородок и осветительного оборудования осуществлялась отечественными компаниями в кратчайшие сроки и с минимальным бюджетом.

Максим Неретин

генеральный директор Аврора Групп

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

Проект-номинант премии Best Office Awards 2017!

Приобрести билеты на церемонию награждения по специальной цене

Регистрация на форум Business & Design Dialogue 2017

Белорусский программист в Spotify: «Работай, как хочешь,

Через неделю в Минск приедут представители двух европейских компаний, которые часто ставят в пример при построении производственного процесса в ИТ. Об одной из них, шведском музыкальном сервисе Spotify (более 60 млн пользователей), в Беларуси слышали немногие. Не знал о компании и белорусский программист Кирилл Жданович, пока год назад не получил приглашение на должность разработчика в стокгольмский офис Spotify. Сегодня Кирилл любезно согласился поделиться своими наблюдениями о непростой для постороннего, но естественной и эффективной для «своих» системе организации процессов разработки в компании на основе методологии Agile.

Читать далее

— Сложно ли было попасть в Spotify?

— Не то, чтобы сложно, но я до сих пор уверен, что успешное прохождение интервью в такого рода компаниях — достаточно большое везение. Многое зависит от человеческого фактора: ты можешь понравиться или не понравиться. Даже мои знакомые, хорошие люди и специалисты, не прошли собеседование. Возможно, они не подошли на определённую позицию, но сильны в другом.

В Минске я работал в компаниях достаточно успешных, где можно учиться у людей: «Кредо-Диалог», Wargaming.net, BP Mobile и потом в MAPS.ME. Когда заканчивал институт, познакомился с Лёшей Толстиковым, куратором минской Школы анализа данных «Яндекса», — и поступил туда.

Мне кажется, что ШАД и участие в соревнованиях типа Codeforces и TopCoder помогли мне пройти все собеседования. Во многих компаниях очень часто задают алгоритмические задачи, и у меня все интервью заканчивались на 20 минут раньше, потому что я всё решал гораздо быстрее положенного. Вопросы, связанные с архитектурой, даются мне сложнее, потому что разработкой занимаюсь не так давно.

— Ты хотел попасть именно в Spotify или просто выбирал из нескольких вариантов?

— Меня нашли рекрутёры. В MAPS.ME было интересно, особенно с сооснователями Юрой Мельничеком, Виктором Говако и Сашей Золотарёвым — очень много знаний получил. Мне просто написали и спросили, хочу ли я попробовать. Я подумал, что никогда не собеседовался в такие компании — почему бы и нет. И Швеция — интересная страна для жизни. Начал узнавать, чем занимается Spotify. Оказалось, что это очень известная компания, с большим количеством пользователей и интересным продуктом. Чем больше узнавал, тем больше хотелось получить работу. Съездил на интервью — и мне почти сразу прислали «офер». Я решил, что смогу многому там научиться. Прошёл почти год, и я до сих пор не жалею.

— В вашем офисе много иностранцев?

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

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

— Действительно ли корпоративная культура Spotify так отличается от того, что ты видел раньше? Что было самым необычным для тебя?

— Скажу сразу, что компания большая и общая культура, конечно, есть. Однако в каждой команде, в каждом подразделении она немного разная. В MAPS.ME Юра Мельничек старался прививать нам корпоративную культуру, и многие вещи были уже мне знакомы.

Здесь складывается ощущение, что всё делается так, как это должно быть. Например, если у кого-то спросить, нужны ли частые релизы, не думаю, что кто-то ответит, что не нужны. Нужно ли писать тесты? Нужно ли работать в паре, делиться знаниями, заменять человека, если он уйдёт? Да, нужно. Все эти вещи здесь работают. Мне всегда казалось, что это простые ценности в разработке: XXI век — ну кто тесты не пишет?

Мы постоянно хотим делать продукт лучше. У Spotify есть слоган: «Think it. Build it. Ship it». Т.е. сначала мы подумаем, потом сделаем, потом посмотрим — и поправим. Когда мы что-то сделали, мы обязательно смотрим назад: как это прошло, что мы могли сделать лучше, какие ошибки мы не хотели допускать.

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

— Как тебя вводили в курс дела? Что такое Bootcamp?

— Через неделю после прихода в компанию я пошёл на Bootcamp. У нас в группе было семь разработчиков, нужно было за две недели сделать прототип продукта и посмотреть, как это работает. Получается, что мы были маленьким squad’ом (Первичная команда разработчиков в Spotify — Прим. dev.by), у нас был свой Agile-coach, свои тестировщики, свои менторы. Это было, как прививка: мы играли с мёртвыми бактериями, нам было весело, все только приехали, общаемся, и продукт весело делается. При этом мы посещали семинары, узнали о системах оценки в компании, о том, как тестируются продукты, о безопасности. Придя в команду, у меня было ощущение, что я уже готов к работе.

— Agile-coach есть в каждой команде?

— В каждом «трайбе» (Объединение команд разработчиков, работающих в связанных областях — Прим. dev.by) решают сами. В одной команде у нас был коуч, а сейчас он непостоянный, работает с несколькими командами.

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

Хочу сказать, что Agile-культура для кого-то хороша, а для кого-то нет. Например, мой брат, у которого 15 лет опыта в разработке, не понимает, зачем нам нужен Agile-coach. Здесь тоже есть такие люди. Не все любят долгие планирования, не все считают это полезным. Но другим это подходит — помогает строить процессы.

— Сколько человек в твоей команде?

— Я работал в нескольких командах. Их стараются делать достаточно маленькими — как маленькие стартапики. И все сидят вместе. Обычно в командах от 7 до 14 человек. Например, в продуктовой команде может быть сразу тестировщик, дизайнер, автоматизатор, Agile-coach, разного вида разработчики и product owner. Кто-то может приходить на время, чтобы помочь с реализацией какой-то идеи.

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

— А общее направление движения обсуждается на совместных собраниях?

— Везде это работает по-своему. Мы разбиты на «трайбы», в которые входит несколько команд (squads). Есть ещё подуровни, но они не так важны. Очень часто нам рассказывают, что мы делаем и почему мы делаем это именно так, чтобы люди знали, что происходит. Когда команда что-то сделала, она может показать это всем: от своего «трайба» до всей компании. Поскольку есть несколько офисов, обычно это происходит в большой переговорной комнате с видеосвязью.

— Есть какие-то «дедлайны», обязательные отчёты или вы настолько автономны, что никто не следит даже за тем, когда вы что-то делаете?

— «Дедлайны», само собой, есть, отчёты, наверное, тоже, но я как разработчик о них не знаю. Я вижу еженедельные отчёты от всех «трайбов» о достижениях и планах.

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

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

— Как часто вы делаете релизы?

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

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

Тут работает такая идеология: мы хотим часто «шипить», получать быстрый фидбэк и быстро учиться — и всё это как-то работает.

— Как обсуждаются ошибки?

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

— Команды часто между собой взаимодействуют?

— Постоянно. У нас есть гильдии: например, все Java-разработчики общаются, есть собрания, на которых они обсуждают технологии. Все вместе обсуждают, например, переход на другой фреймворк. Команды очень зависят друг от друга. Но, к примеру, моя команда гораздо больше зависит от команд из нашего «трайба», чем от каких-то других.

— По какому принципу команды собираются в «трайбы»?

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

— Как работает внутренний open source?

— Всё начинается с разговора: ребята, я хочу использовать ваш код и сделать то-то. Они могут сказать, что это как раз то, что они хотели, но нужно учитывать какие-то особенности. Это хорошая подсказка. Конечно, бывает, что кто-то что-то сделал без предупреждения, а ты потом смотришь и удивляешься. Бывает, что люди по незнанию что-то сделали. Но все постоянно что-то друг другу «контрибьютят». Человек может потратить своё время, например, в Hack day, и что-то добавить — и все только рады.

— Ты уже участвовал в Hack Week?

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

Есть планы глобальные, а есть то, что люди хотят попробовать и внести в продукт. И недельный хакатон — прекрасное время для этого. Во многих компаниях есть innovation labs, где сидят люди и что-то придумывают. Здесь здорово, что каждый может в этом поучаствовать. Если у тебя есть идея — бери и делай. И потом специалисты, которые занимаются продуктом, изучают результаты. Я уже был свидетелем того, как вещи, придуманные на Hack Week, были запущены в продакшн.

— «Овертаймы» случаются?

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

Работая в своей первой команде, я обещал что-то сделать, но не успевал. Это не ломало сроки, но я не хотел сам себе вредить. И я работал допоздна. Ко мне подошел мой PO и говорит: «Видел, ты сегодня пришел в 8, а уже 7 вечера — иди домой». И он достаточно часто такое говорил.

Однажды я задержался по собственной инициативе, потому что нужно было доделать что-то важное. Потом он написал мне примерно такое письмо: «Ты молодец. Это было не обязательно, но за то, что ты это сделал и поработал на три часа больше, в понедельник уйди на полдня раньше».

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

Есть обязательное время, когда ты должен быть на «митинге». А потом можешь работать из кафе или из дома, если при этом люди могут с тобой взаимодействовать. Главное — результат. Я не видел, чтобы кто-то этим злоупотреблял.

— В видео много говорилось о мотивации в Spotify. Есть какая-то особая система?

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

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

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

— Расскажи о бытовой стороне работы в Spotify.

— Офис очень здоровский. У каждой команды своя комната с open space, в одной части стоят столы, в другой — место для собраний с диванами, стульями, телевизором для связи и досками для рисования. Сейчас я сижу в маленькой переговорной комнате с досками, здесь помещается человек шесть. У каждой команды есть своя такая комната.

Spotify очень славится социальными ивентами. Компания часто «хостит» всякого рода митапы. Много совместных поездок, мероприятий. Например, все желающие организованно едут кататься на лыжах или заниматься сёрфингом. Очень часто в офисе бывают живые выступления музыкальных групп, которые можно увидеть на больших фестивалях. Летом и зимой проходят традиционные новогодняя и летняя вечеринки.

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

Есть комната, где можно поспать, два игровых помещения, музыкальная студия с профессиональным оборудованием. В компании много музыкантов, диджеев. Как-то в офисе был концерт, на котором сотрудники играли каверы на песни известных групп.

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

О передовом опыте Spotify в имплементации и масштабировании методологии Agile директор по разработке компании Кевин Голдсмит (Kevin Goldsmith) расскажет в Минске 26 марта. Организатором бесплатного для посещения мероприятия выступиила Godel Technologies Europe. Подробнее>>>

Фото: Spotify

Академия | Agile-трансформация в Сбербанке

По следам конференции «Команды-2017. Опыт лидеров», которая прошла 29 ноября и на которой побывала Юлия ЧемеринскаяСамое практическое и конкретное выступление было у Наталии Даниленко, начальника управления по работе с персоналом Сбербанк Технологии. О нем и напишу. Ибо масштаб сберджайлизации абсолютно уникален для России: сейчас в agile-­периметре уже более 11000 сотрудников группы компаний Сбербанк, из них более 6000 — это сотрудники ИТ-компании, в которой Наталия является руководителем HR-службы. 

Agile-технологии в Сбере за год слегка трансформировались и приобрели свой формат, поэтому его называют Sbergile:)
 

КАК ЭДЖАЙЛ ЖИВЕТ В СБЕРБАНКЕ

Манифест — манифестом, его уже все выучили:)
А вот конкретные цели. Чего в компании хотели достичь:

Организационная единица — это команда. Объединена она по способности создать продукт. Команда в Sbergile — постоянная команда. В отличие от Scrum. Ее не распускают. Она отвечает за созданный продукт, совершенствует его в течение всей его жизни.
Важно, что в команде все со всеми общаются лично каждый день.

Представляете, 1300 команд? 10 тысяч человек? Масштаб вызывает уважение. А представляете, какую гигантскую работу пришлось провести, чтобы это стало возможным? Вот лишь четыре задачи трансформации. Каждая огромна, трудозатратна и с точки зрения перестройки крайне непроста. И самое сложное здесь — это культурная трансформация людей и компании.

Разумеется, возникает вопрос: при размывании роли руководителей как оно все управляется? И что сказали боссы, которых лишили должностей и званий? Сняли, так сказать, погоны? Отвечу сначала на второй вопрос. Разговоров пришлось провести много. Но теперь в подразделениях Сбербанка, перешедших в agile, больше нет отделов, управлений и департаментов в штатном расписании. Бывшие начальники отделов, управлений, департаментов теперь на экспертных должностях без подчиненных.  Трайб — это организационный «мешок» в котором нет больше иерархической структуры и начальников.
Кстати, никто из них не уволился! В отличие от, к примеру, переходящего на холакратию Zappos, который потерял 50% своих менеджеров, не согласных с таким поворотом:)

УПРАВЛЕНИЕ В СБЕРДЖАЙЛ

Как выглядит управлениие в Сберджайл.
Agile — структура виртуальная. А так все сотрудники числятся на единой должности ИТ-инженер с широкими обязанностями.
А роль руководителя размыта между разными людьми и держится на четырех ключевых фигурах. Ну потому что, согласитесь, не может быть одного руководителя над девятью разными профессиями, собранными в одной команде.

1. Владелец продукта.

 
С ним все более-менее просто. Сложно только, что это роль, а не должность:) Часто воспринимается как руководитель – сложно перестроиться с иерархической культуры. Хотя Владелец продукта может получать меньше участника команды.
Опыт пребывания Владельцем продукта полезен всем, но не всем комфортен.

2 и 3. Лидер чаптера и Лидер компетенции

Лидер чаптера — это такой играющий тренер. У него 7 человек. На 50% он является лидером чаптера, а на 50% занимается  развитием других. Например, у него 15-летний опыт работы с кредитными картами. Он и создает с командой продукт, и развивает сотрудников в других командах, кто тоже занимается кредитеыми картами.

Лидер области компетенций, к примеру, мастер 80-го уровня в IOS, занимается только развитием этой техкомпетенции у 24 сотрудников, за которых он отвечает. Грубо говоря, учит писать и проверяет их IOS-коды.

4. Agile-коуч

От скрам-мастеров Сбер отказался и передал их роль agile-коучам. Они ребята очень загруженные, коучат по 3-4 команды. Развивают ценностно (в сторону agile) и помогают понять и реализовать потенциал каждого сотрудника.

 

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

ОЦЕНКА И РАЗВИТИЕ ЛЮДЕЙ В СБЕРДЖАЙЛ

Что является обязательным условием развития? Стимул развиваться, объективная оценка и постоянная обратная связь.
Про развитие по всем фронтам уже написала выше. И бизнес-компетенции тебе развивают, и технические, и человеческие.
Так же происходит и оценка: с разных сторон, разными людьми.

То есть одним человеком на постоянной основе занимаются аж сразу три человека:

• владелец продукта смотрит на него с позиции создания самого продукта — качества и сроков,
• лидер компетенции — на его технические компетенции,
• аgile-коуч отвечает за его развитие в эджайл, его роли в команде, его потенциала.

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

ПРЕМИРОВАНИЕ

До недавнего времени, а именно до октября этого года, в Сбербанке была квартальная система премирования, основанная на целой многоступенчатой системе KPI. С октября от нее отказались, потому что в понимании Наталии (я, кстати, тоже очень поддерживаю) материальное стимулирование не работает на сотрудниках, от которых мы ждем интеллектуального продукта, креативности и инновационности. Оценка по KPI превращается в профанацию, все пытаются «обмануть систему» или «прогнуться» под нее, убивая инновации, риск и творчество.

В результате перевели премирование в оклад и осталась только небольшая годовая премия. Это очень верно. Айтишники не премиями мотивируются.

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

Ну и в заключении плюсы и минусы.

ПЛЮСЫ AGILE-ТРАНСФОРМАЦИИ

МИНУСЫ AGILE-ТРАНСФОРМАЦИИ

 

В конце Наталия пригласила всех желающих на экскурсию по Сберджайлу, которая состоится в декабре в офисе на Кутузовском. Следите за нашими анонсами!

Если вам было интересно, ставьте лайки и делитесь постом, буду писать еще.
Удачи,
Ваша Чемеринская
[email protected]

Масштабирование Agile в Spotify | AgileRussia

Масштабирование Agile с помощью кланов, отрядов, отделов и гильдий
Авторы: Henrik Kniberg & Anders Ivarsson
https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf

 

(Tribe – клан, Squad – отряд, Chapter – отдел, Guild – гильдия)

Всегда непросто иметь дело с несколькими командами в организации, занимающейся разработкой продуктов!

Один из самых впечатляющий примеров, с которым мы столкнулись – это музыкальный сервис Spotify, в котором был распространен Agile, несмотря на то, что компания разрослась до 30 команд, которые находились в трех городах.

Spotify – это замечательная компания, которая преобразовала всю музыкальную индустрию. Он существует всего 6 лет, при этом у нее уже более 15 миллионов активных пользователей и более 4 миллионов платежей. Сам по себе продукт можно охарактеризовать как «магический музыкальный плеер, в котором вы можете найти и проиграть любую песню в мире».

Алистар Коберн (один из отцов-основателей Agile разработки) зашел на Spotify и сказал: «Прекрасно, я искал кого-нибудь, кто смог бы реализовать этот матричный формат с 1992 года 🙂 , поэтому действительно очень рад увидеть это.»

Итак, как же это организовано?

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

Замечание: Spotify быстро развивается (как и любая хорошая agile компания). Эта статья показывает, как мы работаем сейчас, но путь еще не пройден до конца. К тому времени, как вы прочитаете об этом, многое уже изменится.

Отряды

Основная единица разработки в Spotify – это Отряд (Squad).

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

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

Поощряется применять в отрядах принципы Lean Startup, такие как MVP (minimum viable product – минимальный жизнеспособный продукт) и подтвержденное обучение (validated learning). MVP означает частые и ранние релизы, а подтвержденное обучение означает использование метрик и A/B-тестирования, чтобы понять, что действительно работает, а что не работает. Все это суммируется слоганом: «Подумайте об этом, постройте это, поставьте это и измените это».

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

У большинства отрядов есть свое рабочее пространство, включающее письменные столы, гостиную и «личную» комнату. Почти все стены – это доски. Мы никогда не видели лучшего пространства для взаимодействия!

Да, это акула парящая в воздухе, совершенно нормально.

Чтобы стимулировать обучение и инновации, отряды поощряют к тому, чтобы примерно 10% времени отводилось на «хакерские дни». Во время «хакерских дней» люди делают что им хочется, обычно они проверяют новые идеи и обмен мнениями со своими товарищами. У некоторых команд – один хакерский день каждую вторую неделю, другие собирают свои дни в «хакерскую неделю».

Хакерские дни – это не только прекрасное времяпровождение, это также отличный способ узнавать о современных инструментах и практиках, а иногда это ведет к важным инновациям в продукте!

У отряда нет формально назначенного лидера, но есть product owner. Product owner отвечает за приоритезацию работ команды, но он не вовлекается в то, как выполняется сама работа. Product owner-ы разных отрядов взаимодействуют друг с другом, чтобы поддерживать высокоуровневый документ, который показывает, куда же движется Spotify как единое целое. И каждый product owner отвечает за поддержку баклога продукта для своего отряда.

В отряде также есть agile коуч, который помогает двигаться вперед и улучшать то, как работает команда. Коучи проводят ретроспективы, совещания по планированию спринтов, проводят коучинг 1-на-1, и т.д.

В идеале каждый отряд полностью автономен, напрямую общается со своими заинтересованными лицами, и у него нет блокирующих зависимостей от других отрядов. Это мини-startup. Но с 30 командами – это не просто! Мы прошли длинный путь, но многие улучшения еще впереди.

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

Кружочки показывают текущее состояние, стрелочки показывают тенденцию. Например, мы видим, что три отряда отчитываются о проблемах вокруг поставки и что ситуация не улучшается – эта область требует срочного внимания! Также видно, что у отряда 4 есть проблемы с agile коучем, но ситуация улучшается.

• Product owner – У отряда есть выделенный product owner, который приоритезирует работы, принимая во внимание бизнес ценность и технические аспекты.
• Agile коуч – У отряда есть agile коуч, который помогает выявить препятствия и постоянно улучшать процесс разработки.
• Влияние на работу – Каждый член отряда может повлиять на свою работу, быть активным в планировании и выбирать задачи, над которыми он будет работать. Каждый член отряда может проводить 10% своего времени на хакерские дни.
• Легкость поставки – отряд может сделать (и делает!) поставку с минимальными требованиями к синхронизации с другими частями продукта.
• Процесс, который подходит команде – отряд владеет своим процессом и постоянно улучшает его.
• Миссия – у отряда есть миссия, о которой все знают и заботятся, и истории в баклоге относятся к этой миссии.
• Поддержка организации – отряд знает, куда обратиться, если требуется помощь в решении проблемы, по техническим и по другим вопросам.

Клан

Клан (Tribe) – это набор отрядов , которые работают во взаимосвязанных областях, таких как плеер или инфраструктура бэкэнда.

Клан можно представить как “инкубатор” для мини-стартапов-отрядов, у них большая степень свободы и автономии. У каждого клана есть лидер, который отвечает за создание наилучших условий существования отрядов внутри клана. Отряды клана физически находятся в одном офисе, рядом друг с другом, и расположенные рядом гостиные способствуют общению между отрядами.

Размер клана основан на концепции «Числа Данбара», которая говорит о том, что большинство людей не могут поддерживать социальные отношения более чем со 100 людьми или около того (для групп, которые интенсивно борются за выживание это число может быть значительно больше, но это не относится к Spotify, верите вы этому или нет…). Когда группы становятся слишком большими, все больше появляется таких вещей как ограничивающие правила, бюрократия, политика, дополнительные уровни управления, и другие ненужные вещи.

Поэтому кланы сконструированы так, чтобы в них было меньше 100 человек.

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

Зависимости между отрядами

Во множестве отрядов всегда есть зависимости. Зависимости – это не обязательно плохо. Иногда отрядам нужно работать вместе, чтобы создать что-то действительно необыкновенное. Тем не менее, наша цель – сделать отряды максимально автономными, особенно нужно минимизировать зависимости, которые блокируют или замедляют работу отряда. Мы регулярно опрашиваем отряды, от каких других отрядов они зависят, и до какой степени эти зависимости блокируют или замедляют работу отряда. Вот пример:

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

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

В scrum есть практика «scrum of scrum», синхронизирующее совещание, где собираются по одному от каждой команды для обсуждения зависимостей. Обычно мы не используем «scrum of scrum» в Spotify, в основном потому что большинство отрядов достаточно независимы, и такие координационные совещания просто не нужны. «Scrum of scrum» проводится, если возникает такая потребность. Например, недавно у нас был большой проект, в котором требовалась скоординированная работа множества отрядов на несколько месяцев.

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

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

В Spotify есть отдельная операционная команда, но их работа – это не делать релизы для отрядов, их работа – давать отрядам поддержку, с тем что отряды сами выпускали релизы: поддержка в форме инфраструктуры, скриптов, процедур. Они как бы «строят дорогу к выпуску продукта».

Это неформальное, но эффективное взаимодействие, основанное на личном общении, а не на детальной документации.

Отделы и гильдии

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

Если бы каждый отряд был полностью автономен и не общался бы с другими, то зачем вообще их объединять в одну компанию? Spotify можно было бы поделить на 30 разных мелких компаний.

Вот почему у нас есть Отделы (Chapters) и Гильдии (Guilds). Это клей, который держит всю компанию вместе, это дает нам некоторую экономию, не жертвуя автономией.

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

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

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

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

Гильдия – это более органичное и более масштабное «сообщество по интересам», группа людей, которые хотят поделиться знаниями, инструментами, кодом и практиками. Отделы всегда внутри клана, а гильдия охватывает специалистов всей организации. Вот некоторые примеры: гильдия web технологий, гильдия тестирования, гильдия agile коучей, и т.д.

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

В каждой гильдии есть «координатор гильдии», который координирует работу гильдии :0)

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

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

Минуточку, разве это не матричная структура?

Да. Хорошо, что-то в этом роде. Однако, это другой тип матрицы, в отличие от того, к чему привыкло большинство из нас.

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

В Spotify редко делается что-либо подобное. Наша матрица направлена на поставку.

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

Горизонтальное измерение – для обмена знаниями, инструментами и кодом. Работа руководителя отдела – содействовать и поддерживать это.

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

Это похоже на модель «профессор и антрепренер», рекомендованную Mary и Tom-ом Poppendieck. Product Owner – «антрепренер» или «чемпион по продукту», который фокусируется на поставке отличного продукта, а руководитель отдела – это «профессор» или «лидер по компетенции», который фокусируется на техническом мастерстве.

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

Что насчет архитектуры?

Технология Spotify ориентирована на сервисы. У нас более 100 разных систем, и каждая может поддерживаться и устанавливаться отдельно. Сюда включаются бэкэнд сервисы, такие как управление плейлистом, поиск или оплата, и клиенты, такие как iPad плейер, специфические компоненты,такие как радио, или секция «Что нового?»музыкального плейера.

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

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

Чтобы справиться с этим риском, у нас есть роль «System Owner». У каждой системы есть system owner, или пара system owner-ов (мы поощряем парность). Для критичных систем system owner – это Dev-Ops пара, один – со стороны разработки, а другой – со стороны операций.

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

System Owner – это не узкое место и не «архитектор башни из слоновой кости». Он не должен лично принимать все решения, или писать весь код или делать поставлять все релизы. Это обычный член отряда или руководитель отдела, у которого есть обычные ежедневные обязанности, кроме владения системой. Однако, время от времени, он будет брать «День
system owner-а» и выполнять домашнюю работу в своей системе. Обычно мы стараемся, чтобы время на поддержку своей системы было не больше 10% рабочего времени. Однако это может сильно отличаться от системы к системе.

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

Как все это работает?

Компания Spotify выросла очень быстро – более чем за 3 года мы выросли с 30 до 250 человек. Эта модель масштабирования – с отрядами, кланами, отделами и гильдиями – была постепенно введена в течение последнего года, поэтому люди все еще привыкают к ней. Но, судя по опросам и ретроспективам, эта модель масштабирования работает достаточно хорошо!
Несмотря на быстрый рост, удовлетворенность сотрудников постоянно растет: в апреле 2012 она составляла 4.4 из 5 возможных.

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

как устроена мобильная разработка в Uber, Spotify, «Одноклассниках» и Авито / Конференции Олега Бунина (Онтико) corporate blog / Habr

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

---

Филипп Уваров, Android developer в Spotify. В компании работает последние полгода — в одной из платформенных команд, которые занимаются поддержкой других разработчиков в Spotify. Живет в Швеции. До Spotify работал в одном шведском стартапе, а еще раньше — в Avito.

Артем Ольков, Lead IOS Developer в «Одноклассниках».  В данный момент возглавляет iOS-разработку одного из продуктов. Помимо собственно разработки, отвечает за архитектуру, проектирование, распределение задач, согласования с дизайном, API backend-а и т.п. Всего в «Одноклассниках» сейчас около 60 мобильных инженеров, которые делятся на более мелкие команды. В команде Артема — 11 человек.

Максим Ефимов, Senior software engineer в Uber. В компании работает два года, занимается Android-разработкой. Входит в команду «rider payments», которая занимается обработкой всего, что связано с платежами в приложении для пассажиров Uber. До этого разрабатывал под Android в других компаниях — в основном, на заказ, а еще раньше — писал на С++ (серверные решения для SCADA-систем). В Uber в рамках подразделения, которое занимается платежами, есть еще несколько подобных команд для других приложений, а также инфраструктурные команды — в общей сложности это несколько десятков команд.

Евгений Суворов, руководитель разработки юнита «мобильная архитектура» в Avito: Разработкой мобильных приложений занимается около восьми лет. Пробовал игры, фрилансил, работал в компаниях-аутсорсерах, в большой компании, после чего переключился на продуктовую разработку.

---

Давайте начнем с особенностей. Чем отличается работа команд при большом штате разработчиков в компании?

Артем Ольков (Одноклассники): На мой взгляд, особенности связаны скорее не с масштабом компании, а с тем, как внутри нее устроены процессы и какую роль в этих процессах играет команда. Грубо говоря, если ваша команда делает мобильную платформу, на которой базируются другие приложения или сервисы компании, к ней будет прилетать 1000 запросов из разных уголков и без хорошего product manager-а разработка захлебнется. Если же команда делает отдельно стоящий сервис без сложных интеграций, то процесс будет выглядеть гораздо проще.

Максим Ефимов (Uber): На мой взгляд, самая характерная черта — это скорость работы.

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

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

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

Филипп Уваров (Spotify): Я думаю, основная особенность в том, что я не знаю всех Android-разработчиков в лицо. А еще у нас очень сильно разделены сферы ответственности. Это позволяет всегда находиться в контексте того, что ты делаешь, и достаточно быстро доставлять продукты в своем направлении.

Как ваша команда синхронизируется с другими внутри компании?

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

Филипп Уваров (Spotify): У нас кросс-функциональные команды, которые занимаются конкретными вопросами (например, как мы, разработкой аналитики для мобильных клиентов), объединяются в один большой департамент — мы называем его «трайб» (племя). Как правило, команды внутри одного трайба достаточно тесно связаны между собой, у них идет активный обмен опытом. Плюс у нас, естественно, есть клиенты — это другие разработчики, поэтому мы поддерживаем те решения, которые создаем для них.

Максим Ефимов (Uber): У нас команды небольшие, в каждой не более 20 человек. Они объединены в структурные подразделения, которые отвечают за большие области, например, мобильное приложение. При этом сами команды достаточно автономны, потому что если все свести к какой-либо единой системе управления с прямым подчинением, мы получим очень неэффективную систему.

Общая продуктовая идея доносится до отдельных команд через product manager-ов или owner-ов. Есть отдельная структура, которая объединяет этих людей и помогает формировать понимание того, как и куда мы движемся. На каком-то верхнем уровне могут определяться стратегические цели вроде заботы о безопасности пассажира. Ну а детали решаются на один — два уровня ниже. Например, у нас есть определенные механизмы обеспечения безопасности в странах, где люди в основном пользуются наличными для оплаты.

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

А есть ли проблемы, типичные для больших команд? С чем вам приходится сталкиваться?

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

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

А это значит — качественный Continuous Integration, Continuous Delivery, автоматизация тестирования.

Филипп Уваров (Spotify): Я думаю, самая масштабная проблема — это распространение знаний внутри компании. Я могу не иметь представления о том, что происходит в каких-то далеких командах. И то же самое верно в обратном направлении: многие команды понятия не имеют, что у нас в Spotify вообще существует команда аналитики. Именно здесь ощущается масштаб.

Второй момент — скорость принятия инновационных решений: адаптация того же Kotlin-а и других новых технологий. Одно дело — прийти и сказать пяти разработчикам: «С сегодняшнего дня мы пишем на Kotlin», но совсем другое — сказать это 100 разработчикам. Существует огромная инфраструктура, которую нужно переводить, как-то поддерживать эти нововведения (CI и т.п.).

Артем Ольков (Одноклассники): Да, проблемы действительно две: передача знаний и согласование действий, в том числе по модернизации.

Есть ли в крупных компаниях какие-то проверенные способы решения этих проблем?

Филипп Уваров (Spotify): Для решения первой проблемы — шаринга знаний — у нас есть такая штука, как гильдии. Это объединения разработчиков по функциям, например, Android-гильдия, которая раз в две недели проводит какие-то мероприятия: презентации, ланчи, где можно обсудить насущные проблемы или поделиться чем-то, и пр. Еще у нас, опять же, по гильдиям, проходят внутренние конференции. Плюс есть почтовые рассылки и т.д. Остается простая человеческая проблема: за всем этим сложно угнаться.

Отдельной строкой хочется выделить внутреннее обучение (повышение квалификации). У нас есть свой Data University, где можно выучиться на дата-инженера. Сейчас коллеги думают над созданием такой же схемы для мобильного обучения.

Артем Ольков (Одноклассники): У нас нет ярко выраженных гильдий.

Так или иначе ребята, объединенные одной задачей, пересекаются на различных митапах — друг друга знают, общаются в курилке или за обедом. Есть отдельные чатики, например, чисто для iOS-ников. Внутри команды, понятно, вопрос решается проще — мы все сидим за одной «ромашкой».

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

Вторая проблема — согласование действий — решается грамотным менеджментом.

Максим Ефимов (Uber): На самом деле в том же шаринге знаний я не вижу проблему. Я вижу, что сам механизм шаринга отличается. В маленьких командах это просто делается абы-как. Собрались — поговорили. А у нас есть удобные процессы, которые позволяют организовать все так, чтобы оно работало. Про них я, кстати, буду рассказывать в своем выступлении на AppsConf 2018. Идея в том, что в нашей компании практически вся разработка довольно прозрачна. Люди из любых команд могут смотреть на то, что делают другие разработчики, и что-то из этого использовать у себя.

Евгений Суворов (Avito): У нас также организуются встречи 2 раза в неделю. Мы любим автоматизацию, и эта задача тоже автоматизирована. Есть процесс, когда в течение недели люди накидывают темы, про которые они хотели бы рассказать на общей встрече iOS или Android-разработчиков. И если есть повестка, мы собираемся. В рамках встреч продуктовые команды рассказывают про те фичи, которые они реализовали в продукте, потому что иначе сложно уследить за всем, что происходит.

Мы встречались с самого начала, но именно с ростом компании эти встречи стали наиболее актуальны.

Плюс есть чатики, где можно обсудить какие-то конкретные вопросы.

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

Артем Ольков (Одноклассники): Это все-таки зависит от того, чем вы занимаетесь и как зарабатываете деньги.

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

Потому что если собрать в кучу всех iOS-ников, вбрасывать в них задачи, не имея очень короткого моста общения с дизайном, backend-ом или тестированием, придется тратить слишком много времени на согласования.

Филипп Уваров (Spotify): У нас все делятся по продукту. Например, наша команда занимается аналитикой и в нее входят и iOS, и backend разработчики, и много кто еще. На мой взгляд, это очень разумное деление команд, которое тоже ведет к определенным проблемам, но при этом хорошо работает на таких масштабах.

Максим Ефимов (Uber): Мне кажется, идея делить команды по платформам — iOS, Android, backend — на больших масштабах сработает не очень хорошо. Она достаточно сильно отделяет разработчиков друг от друга и в итоге синхронизация, к примеру, двух мобильных приложений под разные платформы, будет стоить гораздо дороже. А профита с того, что люди в команде видят только людей со своей платформы, как мне кажется, не так уж и много. Да, с шарингом знаний проще, но стоит ли это того? Мне кажется, нет.

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

Евгений Суворов (Avito): Соглашусь.Такая структура вполне удачна и мы как раз недавно внедрили ее у себя в Avito, по крайней мере в продуктовой части бизнеса.

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

В какой-то момент в Avito были две большая команды — iOS и Android-разработки, по 15 человек каждая. И на этом этапе мы начали разбиваться на продуктовые команды: выделились группы «buyer experience», «seller experience», мессенджера, доставки и т.д. Это решило вопрос с приоритетами. Раньше в команды приходило много project manager-ов с запросами на фичи, и для них каждая из этих фич имела приоритет номер один. В итоге у нас 20 проектов и сквозные приоритеты их не ясны. Вышестоящим людям приходилось управлять этим вручную. После выделения многофункциональных команд, у каждой из которых — свой pipeline разработки, свои приоритеты и ресурсы, все стало проще.

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

Часто ли проходят реорганизации команд?

Филипп Уваров (Spotify): Какие-то перемещения происходят каждую неделю. В нашей компании команды маленькие и автономные. При желании можно очень легко перейти из одной в другую. Насколько часто это происходит — зависит от команды и направления, в котором ты работаешь. Там, где работаю я, это не ярко выражено. Но Spotify славится тем, что мы работаем по agile и во многом от нас пошли такие вещи, как OKR и т.п. Поэтому руководство компании не боится менять приоритеты, если вдруг понимает, что что-то не работает. Мы просто переключаемся на что-то другое.

Максим Ефимов (Uber): У нас были масштабные реформы, связанные в первую очередь с очень быстрым ростом амстердамского офиса. В течение года число сотрудников увеличилось чуть ли не в два раза. Те команды, куда набирали людей, стали очень большими и одному менеджеру было тяжело управлять такой структурой. В связи с этим команды просто делились на несколько «подкоманд», каждая из которых занималась более узкой сферой. Мне кажется, это естественный процесс.

Согласны ли вы с идеей, что в большой команде, чтобы не страдало качество кода, стоит избегать найма джуниоров и сеньоров с избыточной квалификацией?

Филипп Уваров (Spotify): Я думаю, ни то, ни другое. Spotify каждый год набирает достаточно много выпускников ВУЗов через летнюю практику (какая-то часть людей после практики получает приглашение на работу). Аналогично мы без проблем берем людей с несколькими PhD.

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

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

Максим Ефимов (Uber): Мы отталкиваемся от несколько иного принципа. У нас есть желательное соотношение опытных разработчиков и джунов. Как раз для того, чтобы не возникло ситуации, когда есть толпа джунов, а помогать им и объяснять, как надо работать, некому. Поэтому мы стараемся соблюдать баланс.

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

Евгений Суворов (Avito): На мой взгляд, набирая сеньоров, не стоит бояться, что у них свой царь в голове или что они не будут слушаться.

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

К джуниорам тоже нужно подходить индивидуально. Когда мы еще были одной командой, периодически появлялось интуитивное ощущение, что команда может вывезти еще одного джуна. И в этот момент можно было взять прекрасного амбициозного парня, который довольно быстро вырастал до качественного инженера. В команде с хорошо налаженными процессами обучение проходит действительно быстро. Да и джуны бывают разные — одни приходят после ВУЗа с горящими глазами, но ничего не умеют, а другие имеют за плечами семь лет опыта backend-а, просто только что переключились на мобильные приложения.

То есть джуниоров мы не боимся, но ориентируемся на ощущения команды — нужно ей это или нет.

Планирование, синхронизация, распределение задач

Много ли сил отнимает планирование и синхронизация разработчиков в рамках большой компании (пусть даже в маленьких командах)?

Филипп Уваров (Spotify): Это как раз плюс деления команд по продуктам, а не по функциям: мы занимаемся планированием только нашего небольшого продукта внутри компании и нам зачастую все равно, что там делают остальные миллион разработчиков.

Артем Ольков (Одноклассники): Здесь я могу рассказать только про нашу конкретную команду. У нас начало разработки, и это дает определенные поблажки — позволяет быть свободнее. На данный момент у нас есть только ежедневные 15-минутные митинги по текущему статусу и часовое закрытие предыдущего / планирование следующего спринта раз в неделю. Все остальное решается в личном порядке.

Максим Ефимов (Uber): В нашем случае — не очень большую. Быть может, раза в 1,5 — 2 больше, чем это занимало у меня, когда я работал на аутсорсе.

Правда, есть некоторые процессы в компании, вроде code review, которые тормозят разработку. Грубо говоря, пока какая-то команда, ответственная за свой кусок кода, не посмотрит твой коммит, может пройти просто какое-то время. Но я не думаю, что это относится к плате за синхронизацию. Это скорее о том, как настроена на низком уровне вся эта схема — кто кого ревьюит, как устроено ожидание и т.п.

Евгений Суворов (Avito): Проблему синхронизации мы изначально решили частыми релизами. В итоге сейчас сама синхронизация занимает немного. Все почти автоматизировано.

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

Филипп Уваров (Spotify): В больших командах имеет смысл распределение продукта по зонам ответственности. Таким образом, на задачах всегда будут люди, которые ответственно к ним подходят, потому что им же с этим жить потом. У них не меняется контекст, т.е. не возникает ситуации, когда все разработчики занимаются абсолютно всем (Петя здесь написал 10 строчек, чуть ниже Василий еще 5 дописал и в итоге получается месиво, которое потом невозможно поддерживать).

При этом если работаешь внутри маленького «продукта внутри продукта», ты должен более-менее понимать, как эта вся система работает от backend-а до клиента.

Евгений Суворов (Avito): Что касается качества, то лучше полагаться на тестирование и code review. Например, в моей команде сейчас ребята с бэкграундом мобильной разработки пилят микросервисы на backend-е на трех языках — Python, PHP, Go — которые должны выдерживать нагрузку Avito. Но коммуникации, автоматизация тестирования и т.п. обеспечивают на входе джуниоров, а на выходе — качественную штуку.

Можете ли вы вспомнить одну-две самые интересные задачи, с которыми сталкивалась ваша команда в последнее время?

Артем Ольков (Одноклассники): Как я уже сказал, мы делаем новый продукт. Самая интересная задача лично для меня, как для человека, который его ведет, — его планирование и проектирование: выстраивать архитектуру, продумывать, что у пользователя будет, а чего не будет, и как разработчикам с этим жить.

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

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

На backend-е микросервисы зародились давно, а в мобильных приложениях этот тренд появился совсем недавно — может год — два назад. И то в больших зарубежных командах, в России таких мало.

Технологический стек

Сталкивались ли вы в последнее время с каким-то революционным изменением технологического стека в своей компании / команде? И вообще как такие процессы у вас проходят?

Филипп Уваров (Spotify): У нас такое редко практикуется. Есть эксперименты по внедрению новых технологий, в частности, с переездом Gradle на Bazel или с Teamcity на нашу внутреннюю систему, но не более того. Я думаю, у нас невозможны такие революции по определению.

Максим Ефимов (Uber): До Uber-а у меня был такой опыт, но здесь это постоянно идущий процесс. Есть несколько людей, включая меня, кто выступает за Kotlin. Есть определенные вещи, с которыми нам нужно разобраться, как работать. Но в целом это возможно. Мы над этим сейчас работаем. Мы не должны сидеть и ждать, пока «самый главный разработчик» скажет: «Теперь вы пишите на Kotlin-е». Kotlin уже используется в части нашей кодовой базы, но все еще в процессе.

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

Евгений Суворов (Avito): У нас есть две платформенные команды, которые пилят инструменты для внутреннего использования. Рост компании и модуляризация изменили подход этих команд к работе. Им пришлось много коммуницировать, чтобы понять, что же нужно конечным потребителям (разработчикам).

В плане технологических изменений у нас появился Technology Radar. Часто разработчики говорят: «Давайте внедрим эту штуку вместо той, которую мы 5 лет делаем, т.к. она морально устарела». Чтобы разобраться с этими предложениями, мы завели Technology Radar, в котором тому, у которого есть инициатива, приходится влезть в небольшую бюрократию, провести какое-то исследование, выразить в цифровых метриках, что нововведение нам что-то ускорит, а что-то замедлит, что есть какие-то риски относительно новой технологии. Это пройдет ревью от нескольких коллег и, если все хорошо, технологию применят. Правда, с Technology Radar предложений стало меньше.

Сложнее ли проводить такие реформы с ростом масштаба компании?

Максим Ефимов (Uber): Сложнее, но не намного. Допустим, в маленькой компании вас 10 человек и кто-то один хочет что-то поменять. Для этого ему нужно договориться с девятью людьми. Если же у вас 100 разработчиков, это не значит, что нужно будет договариваться с 99. Конечно, далеко не все будут в этом активно участвовать, это не так сложно, как могло бы быть.

Какие из последних технологий лично вам кажутся наиболее интересными с точки зрения применения в крупных командах (даже если они не работают в вашей компании)?

Евгений Суворов (Avito): Наверное, ключевое — это микросервисы, разделение по доменным областям, разбиение на команды, у которых свои приоритеты. В плане технологий — везде свои особенности.

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

Хотя бывают и исключения. Ввиду разбиения на модули у нас страдал Android-проект —  IDE очень долго парсила модель проекта и помогли только новые early adopted preview версии. Там были экспериментальные галочки, с которыми все стало круче работать.

Филипп Уваров (Spotify): Я думаю, Kotlin —  одна из супер-многообещающих вещей. Мне кажется, в скором времени все забудут про Java на Android, особенно если у Kotlin станет чуть получше с билдами и мы сможем на него перейти. Насколько я знаю, многие большие команды — вроде Facebook — долгое время противились Kotlin-у как раз потому, что там огромные проекты, которые и без этих проблем собираются три года, а с Kotlin будут собираться по шесть лет.

Из последнего лично мне кажется достаточно интересным Flutter.

Артем Ольков (Одноклассники): Я считаю, что лучший стек технологий в контексте разработки под iOS — родной, который предоставляет Apple. Дополнительные фреймворки зачастую не нужны. Есть интересные инструменты, но они построены очень крупными командами только под свои нужды. За пределами этих команд они зачастую добавляют только больше болей.

Есть пара очень интересных подходов, которые сейчас в тренде, и некоторые из них — вполне заслуженно. Хочется отметить конкретно Unidirectional Data Flow.

А что вы думаете о постепенном переходе на Swift?

Артем Ольков (Одноклассники): Это сложная тема. Сейчас мы начали новый проект и у нас все на Swift, но есть 150 строк на Objective-C, т.к. по определенным причинам мы не смогли с помощью Swift относительно лаконично сделать то, что нам было необходимо.

Если у вас все на Objective-C и вас он полностью устраивает, есть ли смысл переходить на Swift? У многих ребят, которых я знаю, перенос кодобазы на Swift — это именно HR-PR-история, потому что на рынке очень много новых разработчиков, которые просто не знают Objective-C и не хотят его изучать.

Евгений Суворов (Avito): Это как раз наш случай. Мы влезли в Swift в свое время и он замедлил нам время сборки. Вообще там было много минусов, но для нас один из ключевых поинтов был в том, что это такая хайповая штука, на которую мы сможем нанимать много разработчиков. В целом это себя оправдало в определенной степени. Swift сейчас развивается, но на Objective-C, возможно, было бы быстрее, удобнее и меньше проблем.

Идея долгосрочной поддержки может стать поводом для перехода (разработчиков в перспективе должно стать больше)?

Артем Ольков (Одноклассники): На этот вопрос не так просто ответить. Apple все еще находится в той позиции, когда они могут сказать, что Swift больше не поддерживается, и отдать его на развитие open source. Вероятность такого развития событий на сегодняшний день очень мала, но она не нулевая. Objective-C все еще получает улучшения.

Лично мое мнение (в Одноклассниках с ним могут и не согласиться) — если просто взять объективные факты — через пять-семь лет будут жить оба языка, а разработчикам нужно будет просто уметь работать и с тем, и с тем. Это не сложно, если понимать основные концепции. Зная один, выучить другой — уже не такая большая проблема. На сегодняшний день разработки под iOS — это больше не про знание языка, а про знание фреймворка, на котором ты работаешь.

Разработка и тестирование

Когда вы пишете тесты? TDD или уже после написания кода?

Филипп Уваров (Spotify): Если честно, с учетом запуска билдов на Android я не верю в то, что можно эффективно писать тесты до кода. Мы обычно пишем тесты параллельно, вместе с разработкой.

Артем Ольков (Одноклассники): Все зависит от того, про какие тесты мы говорим. Unit-тесты на совести команды разработчика.

Конкретно в нашей команде мы покрываем Unit-тестами только определенные слои, в которых нам нужно быть уверенными (проблемы на других слоях мы видим сразу). Если это интеграционные тесты (API, UI и т.д.) — за них уже отвечают тестировщики по мере появления задач.

Максим Ефимов (Uber):Я знаю, часть нашего бэкенда любит TDD, но среди мобильных разработчиков я таких людей не знаю. Нам важно, что получилось в итоге, а уж в какой последовательности человек это написал — его личное дело.

Евгений Суворов (Avito): Тестировщик присутствует на всем жизненном цикле фичи. В самом начале он помогает в постановке задачи, определяет функциональные требования, описывает приемочные тест-кейсы. UI- и unit-тесты пишет сам разработчик. В принципе, тестировщик тоже может их писать — у нас отдельная команда, которая занимается инструментом для написания UI-тестов.

Сами тесты можно писать независимо на любом этапе. На каком — маленькие команды решают самостоятельно. Они могут использовать или не использовать TDD.

В целом практика TDD не очень популярна. У нас в Android-сообществе есть человек, который это действительно практиковал и пытался найти единомышленников. Он как раз выступает на AppsConf 2018 с докладом про TDD.

Но в основном тесты пишут уже после того, как написали фичу.

Предусмотрены ли у вас какие-то стандарты покрытия?

Филипп Уваров (Spotify): Они могут быть разными, в зависимости от задачи. Но 100% покрытие бизнес-логики unit-тестами обязательно.

Максим Ефимов (Uber): У нас есть общее понимание того, что мы тесты делаем. Но никто нигде не говорит, какой должен быть процент покрытия. Команды это определяют сами.

А существует ли с вашей точки зрения  какое-то «золотое» соотношение тестирования и разработки в проекте?

Филипп Уваров (Spotify): Я не смогу назвать идеальную пропорцию — все зависит от задачи.

Например, если мы делаем прототип чего-либо (proof of concept некой идеи), наверное, здесь тестирование будет стремиться к нулю. Если же мы делаем продукт, который будет использовать вся компания с высокой нагрузкой, то здесь на тестирование должно выделяться столько же времени, сколько и на разработку.

Евгений Суворов (Avito): У нас на самую большую команду, включающую четыре мобильных разработчика, есть два QA-инженера, которые тестируют не только мобильную часть, но и backend, frontend и все остальное. Но идеальное соотношение зависит от деталей организации процесса. Например, в моей платформенной команде шесть инженеров, но в принципе нет QA.

Предусмотрены ли у вас процедуры контроля качества кода внутри сообщества разработчиков?

Филипп Уваров (Spotify): Да, code review — одна из базовых проверок. Плюс у нас очень много проверок выполняется на CI: у нас подключено несколько инструментов для статического анализа кода, которые проверяют code style и все на свете — и об этом частично я буду рассказывать в своем докладе на AppsConf 2018.

Артем Ольков: В Одноклассниках есть pull request, есть контроль code style, который обеспечивают форматтеры; есть линтеры, которые выявляют простые ошибки. Есть сборки с тестами, правила ведения git-а. Все — очень маленькие шаги, направленные к одной великой цели: сделать так, чтоб кодовая база была хорошей.

Максим Ефимов (Uber): Code review — такая штука, которой избежать нельзя. Нельзя залить коммит, если его никто не посмотрел. Но процесс команды настраивают сами.

Евгений Суворов (Avito): У нас тоже предусмотрены code review-процессы через пулл-реквесты. Когда разработчик реализует новую фичу, контрибьютит код, он создает пул-реквест, который проходит серию автоматических проверок, в том числе, по качеству.  Потом код смотрят соседи-разработчики.

Мы запустили этот процесс, как только в команде появился второй разработчик. По мере развития компании менялся и сам процесс. Вначале он был ручным, потом появилась автоматизация. Чуть позже мы увеличили количество апрувов с одного до четырех, иначе люди были не готовы принимать решения, влияющие на растущую кодовую базу («а вдруг я неправильно оценил?»). При разделении на многофункциональные команды, когда люди разбежались по разным юнитам, мы сбавили количество апрувов до двух.

По сути это некий регулируемый процесс. По мере роста компании кодовая база эволюционирует, повторяя структуру компании. Команда разбилась по юнитам, кодовую базу мы тоже начали модуляризировать, чтобы отдельные юниты не мешали друг другу и могли разрабатываться относительно независимо. Эта была долгая история. Естественно, это отразилось на пул-реквестах и code review. Параллельно мы стараемся автоматизировать то, что возможно.

Как часто имеет смысл выпускать релизы в проекте крупной компании?

Филипп Уваров (Spotify): Чем чаще, тем лучше.

Артем Ольков (Одноклассники): Это также очень сильно зависит от бизнеса, пользователей, модели распространения. К примеру, до «Одноклассников» я работал в «Акронисе». Там мобильное приложение — это компонент большого десктопного продукта, и его релизы были привязаны к релизам десктопа. У большого продукта было два больших релиза в год — летний и зимний — так исторически сложилось. Поэтому и мобильное приложение релизилось летом и зимой. В промежутках были только хотфиксы и какие-то быстрые исправления.

В Одноклассниках также все зависит от команды. Например, Android-разработчики у нас релизятся жестко каждую неделю.

Максим Ефимов (Uber): Мне кажется, то, как это организовано у нас — вполне разумно и удобно. У нас релизы идут на регулярной основе.

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

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

Евгений Суворов (Avito): Изначально релизы у нас были раз в месяц — это всего 12 релизов в год. Если ты не успел в определенный релиз сделать фичу, то ждешь еще месяц. В итоге люди пытались задерживать релизы, из-за этого тормозились другие команды и страдало качество (некоторые фичи доделывали в спешке, тяп-ляп).

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

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

Крупные команды имеют и другие отличия. О деталях спикеры и их коллеги будут рассказывать на AppsConf 2018ApplsConf 2018. Там будут разговоры и об инструментах, и о принципах организации масштабных команд.

Современные тренды и рекомендации по аджайлизации крупных финансовых институтов

12-15 Мая 2019 в Дублине состоялся PMI EMEA Congress 2019, который был организован одним из лидеров отрасли в области разработки методологии управления проектами – Project Management Institute (PMI). Конгресс собрал более 700 делегатов из 70 стран и 450 организаций и стал мировой площадкой по обмену знаниями и опытом в применении современных методов и подходов в области управления изменениями. Во многих крупных российских банках и финансовых учреждениях на текущий момент происходит Agile трансформация структуры управления изменениями, поэтому анализ опыта аджайлизации в других подобных организациях является важным фактором успешного и эффективного внедрения Agile.

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

• Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов. Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.
• Внедрение методологии Agile в некоторых крупных организациях привели как к позитивным результатам, а именно, к повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат.
• Эффективным способом при внедрении методологии Agile является совмещение классических подходов проектного управления с гибкими методиками.
• Необходимо учитывать национальный и региональный менталитет сотрудников при внедрении методологии Agile. Национальные особенности должны отражаться в программах обучения Agile.
• В общем случае недооценивается роль обучения философии Agile и изменению мышления сотрудников организации. Для успешного внедрения необходимо кардинально поменять отношение персонала к процессам внутри организации, к роли работы в команде, при этом высококвалифицированные индивидуумы могут покинуть компанию, поскольку они теряют ощущение незаменимости и уникальности, возможности быть единственным умеющим плавать на пляже героем-спасателем.
• Для успешного использования Agile зачастую требуется кардинально пересмотреть бизнес-модель и структуру организации.
• Роль проектного офиса, программного и портфельного управления проектами при переходе на Agile обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд.
• Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи трайба. Механизмы расширения и видоизменяя трайба не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации.
• Качество продуктов снижается из-за выделенном акценте на уменьшении T2M.
• Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата.
• Уровень и качество коммуникаций между подразделениями при использовании Agile должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования Agile только увеличит T2M и стоимость внедрения изменений.
• Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд.
• Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд.
• Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации.

Рекомендации:

• Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого трайба выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами трайбов с веб-трансляцией и открытым участием всех желающих сотрудников организации.
• Необходимо усилить роль и объем обучения Agile методикам. Обучение должно акцентироваться не только на техниках, таких как Scrum, Kanban, но и идеологии и философии Agile, изменению принципов мышления, инновационным и нестандартным аналитическим подходам. Обучение должно опираться на конкретные примеры и практики крупных финансовых институтов, стран и регионов. Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании.
• Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности трайбов.
• Agile принципы не должны быть обязательны для всех проектов, особенно если речь идет о регуляторных и нормативных изменениях. В каждом конкретном случае необходимо принимать обоснованное решения при использовании Agile в таких случаях. Допускается совмещение классических и гибких подходов к реализации проектов.
• Необходимо уделять особый и выборочный акцент качеству конечного продукта. Работающий продукт важнее исчерпывающей документации, но качественно работающий продукт невозможно создать без должной документации и QA, поэтому необходимо постоянно балансировать на этой грани, при этом не в ущерб качеству продукта.
• Взаимодействие между подразделениями необходимо вывести на новый уровень. Бюрократические препоны, беспочвенные отсылки на процессы и ВНД во взаимодействии должны жестко пресекаться высшим руководством трайбов, и оперативно разрешаться. Должен быть создан соответствующий on-line механизм внутри трайба и между трайбами с соотвествующими КПЭ у всех руководителей. Необходимо создать атмосферу общей командной работы внутри организации, а не перекладывания ответственности между подразделениями и блоками. Принцип люди и взаимодействие важнее процессов и инструментов необходимо сделать базовым при коммуникации между трайбами.
• Мотивационная составляющая работы, нацеленность на изменения, нестандартность мышления должны быть объединены в единой оценке сотрудников всех уровней с понятной и прозрачной обратной связью. При этом, чтобы выражение таких идей не воспринималось, как увеличение нагрузки на чаптеры, кластеры и трайбы, должны быть созданы прозрачные механизмы расширения команд, увеличение бюджета, а не его перераспределение внутри уже выделенного.
• Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ чаптеров, кластеров, трайбов и организации в целом.

Использованные материалы:

Презентации PMI Leadership Institute Meeting 2019 — EMEA and PMI EMEA Congress 2019:

• Design Thinking to Improve Your Agile Process, Presenter: Denis Vukosav
• Artificial Intelligence Horizons in Portfolio Planning, Presenters: Umut Sezen, Christopher Reeves
• The Journey Towards Agility: Lessons Learned From Successes and Failures, Presenter: Simona Bonghez
• Product Theatre: Successfully Integrating Agile Jira Projects into a Hybrid PMI/PMBOK-based PPM Environment, Presenter: Gerald Aquila
• Possible Mission: Escape from Earth – Agile Edition – Business Simulation, Presenters: Santi Alcaide, Alfred Maeso Aztarain
• Survival of the Fittest: Taking Organisational Agility to the Next Level, Presenter: Leonor Viturro
• Dynamic Governance for Portfolios/Programmes/Projects, Presenters: Teodor Darabaneanu, John Buck
• Agilely Vaulting Over Waterfalls: Applying Agile to Waterfall and Vice Versa, Presenters: Karthik Ramamurthy, Sripriya Narayanasamy
• A Framework for Applying Agile Practices Within Projects, Programmes and Portfolios, Presenter: Nicholas Clemens
• Planning Matters — Even if You Are Agile!, Presenters: Christopher Worsley, Louise Worsley
• Embedding Quality Processes in Agile Product Delivery, Presenter: Geetanjali Bhat
• Product Education Session: Opportunities for Project Managers in the Lean-Agile Enterprise with SAFe, Presenter: Richard Knaster

Дополнительные статьи по теме:

McKinsey: Как банк ING встал на Agile-рельсы

McKinsey: Как банк ING встал на Agile-рельсы

Летом 2015 года нидерландская банковская группа ING начала программу преобразований, чтобы перейти от традиционной организационной модели к адаптивной (Agile) схеме работы, построенной по примеру таких компаний, как Google, Netflix и Spotify. Благодаря новой структуре и модели работы банковской группе удалось ускорить вывод новых продуктов на рынок, повысить уровень вовлеченности персонала и увеличить производительность труда.

Кейс Agile-трансформации ING является знаковым не только для финансовой отрасли Нидерландов или Европы. ING первым из крупных традиционных корпораций отважился не просто на локальные эксперименты с новыми подходами в области управления, а на комплексную Agile-трансформацию, которая охватывает все направления бизнеса и тысячи сотрудников.

Еще более важно, что вся организация откликнулась на изменения, показав именно те результаты, ради которых затевалась вся трансформация: повысилась удовлетворённость клиентов, сократились издержки. ING впервые стал работодателем #1 в Нидерландах, опередив не только другие финансовые институты, но и Google, традиционно занимающий первые строчки в предпочтениях соискателей.

Зачем банку новый подход к работе

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

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

Чтобы реализовать эту стратегию, ING требовалось организовать работу по принципам Agile, свести к минимуму бюрократию и дать сотрудникам необходимые полномочия. Менеджмент хотел сделать компанию гибкой, чтобы она быстро адаптировалась к изменениям и самостоятельно ориентировалась в новых реалиях. Цель — помочь сотрудникам стать более разносторонними и квалифицированными профессионалами.

Внедрение Agile не ограничивается изменениями только в ИТ-отделе или другом подразделении. Главное — придерживаться принципа «сквозного процесса» и создавать междисциплинарные команды, которые работают над удовлетворением потребностей клиента и объединены общим пониманием успеха. В такие команды входят маркетологи, специалисты по продуктам, коммерческие специалисты, UX-дизайнеры, специалисты по ИТ и анализу данных.

Как стать лучшими в своем деле

Если у талантливых молодых людей спросить, где они мечтали бы работать, почти всегда они назовут Facebook, Google, Netflix, Spotify и Uber. Интересно, что все эти фирмы работают в разных отраслях и ориентированы на разные цели — медиабизнес, поиск в интернете, организация перевозок. Их общая черта — особый подход к работе и яркая корпоративная культура. Они работают в небольших группах, которые объединены общей целью, следуют Agile-манифесту, тесно взаимодействуют с клиентами и всегда готовы вносить изменения в то, над чем работают.

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

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

Ключевые элементы преобразований ING

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

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

Цель ING — выпускать новые релизы программ намного чаще: каждые две недели вместо пяти-шести крупных обновлений в год. Интеграция процессов разработки продуктов и эксплуатации ИТ-систем помогает им создавать продукты с инновационными характеристиками.

Новая модель управления персоналом.

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

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

Начало преобразований головного офиса

От разработки стратегии и видения до внедрения новой организационной модели работы в масштабе всего головного офиса прошло около девяти месяцев:

1. Сначала компания проработала видение и изучила опыт ведущих технологических компаний.
2. Затем определила целевую организационную модель с новой «нервной системой»: для этого потребовалось два месяца и пять выездных совещаний совета директоров.
3. Параллельно банк создал шесть пилотных команд: на основе этого опыта они корректировали организационные решения, условия работы и общую структуру.
4. После этого они сосредоточились на практической реализации: подборе сотрудников, подключению их к работе и реорганизации офисов.

Изначально банк ориентировался на трансформацию головного офиса группы — 3 500 сотрудников. Они начали с подразделений, которые занимались маркетингом, управлением продуктами, управления каналами и ИТ. В компании решили, что переход профильных служб на Agile станет хорошим примером для остальных сотрудников.

Банк оставил в стороне отдел кадров, финансовую службу, отдел управления рисками, а также отделения, колл-центры, операционный блок и ИТ-инфраструктуру. Это не значит, что эти подразделения не перешли на модель Agile: просто в них адаптивность проявляется иначе.

Например, в операционном блоке и колл-центрах компания создала самоуправляемые команды, как в Zappos. Их ответственность возросла, а контроль со стороны руководства стал менее пристальным, чем раньше. Параллельно ING внедрил ежедневные стендапы и другие гибкие приемы работы для сотрудников службы продаж и сети отделений: так руководители подталкивали их двигаться в сторону Agile.

Функциональные подразделения — юридическая служба, финансовая служба и отдел управления операционными рисками — остались независимыми и не задействованы в Agile-командах напрямую. Но команды обращаются к ним за помощью и объективными советами.

Конечно, можно начать с ИТ-отдела и постепенно двигаться в сторону бизнеса: ИТ-специалисты проверят и доработают концепцию, прежде чем она будет внедряться более широко. Однако в ING уверены, что внедрение можно начать с любого направления и потом расширять его в сторону бизнеса и ИТ. Любая из этих моделей работоспособна.

Что действительно невозможно по мнению топ-менеджеров банка — выборочно внедрять разные элементы Agile-подхода: это бессмысленно и только усложняет работу. Например, иногда формально принимается адаптивный подход, но при этом сохраняется существующая оргструктура и система управления.

Новая организационная модель

Новая модель работы ING начинается со сквода. Каждый сквод должен:

1. Письменно сформулировать цель, для достижения которой он работает.
2. Определиться со способом измерения эффекта для клиентов.
3. Решить, как управлять повседневной работой.

Скводы входят в трайбы, в которых используются дополнительные инструменты: скрам, канбан-доски для планирования и ежедневные стендапы. С помощью этих механизмов работа согласовывается с владельцами продуктов и даёт ощущение причастности. Вся организация была разделена примерно из 350 скводов по девять человек, сгруппированных в 13 трайбов.

Для синхронизации на уровне трайбов банк проводит квартальный обзор бизнес-результатов (Quarterly Business Review — QBR), как в Google и Netflix. Каждый трайб описывает, чего достиг за прошедший квартал и какие основные выводы сделал, отмечая не только достижения, но и неудачи. Во время такого обзора команды формулируют цель на следующий квартал и указывают, с какими трайбами или скводами будут сотрудничать для ее достижения. Все трайбы имеют свободный доступ к документам QBR. В компании поощряют комментарии и обратную связь — эта информация также свободно распространяется во всем банке. В ING прошли уже более десятка QBR, но руководство уверено: несмотря на улучшения, еще есть над чем работать.

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

Например, разработка мобильных приложений банка — отдельный трайб со своим руководителем и Agile-коучем. В трайб входят три сквода: по одному на каждую популярную мобильную платформу — iOS, Android и Windows Phone. Каждый сквод объединяет разработчиков, маркетологов, дизайнеров, продуктовиков и других специалистов: всего девять человек. Специалисты одного направления из разных скводов составляют чаптер: например, дизайнеры приложений для iOS, Android и Windows Phone — это чаптер дизайна мобильных приложений.

Взято отсюда: https://www.facebook.com/McKinseyRussia/posts/2272719559620426