Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Менеджеры в Agile проектах

Всем привет.

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

(Здесь была картинка для привлечения внимания, но я решил обойтись без нее).

Немного о себе: в IT с 2001 года, бывший девелопер, перешел в бизнес-аналитики, т.к. понял, что «interactions and people» мне интереснее и важнее «processes and tools». Сейчас работаю в Люксофт Украина. Подробнее, кому интересно, в LinkedIn.

Проект

Теперь о проекте, в котором я сейчас работаю: разработка крупной системы для clearing and settlement (C&S) сделок по ценным бумагам (конкретно, cash equities) в инвестиционном банке UBS Investment Bank. В детали системы и использующего ее бизнеса я не могу вдаваться из-за NDA, зато о процессах могу рассказать все.

Над проектом работает 120+ человек в 5 локациях, объединенные в 12 Scrum-командах (количество периодически меняется, т.к. некоторые команды реформируются, некоторые создаются, а некоторые — прекращают работу). Разработка идет 5-й год, 99% требуемого функционала уже в продакшене, сейчас идет финальная «обработка напильником».

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

Процесс

Команды кроссфункциональны, т.е., в каждой команде есть люди со скиллами BA, QA и development. Даже если роль BA или QA занимает выделенный человек, обычно он/она выполняет какие-то смежные активности. Это позволяет, во-первых, поддерживать всю команду во «включенном» состоянии (т.е., члены команды активно общаются), во-вторых, повысить Truck Number (количество членов команды, которых нужно «задавить грузовиком» для прекращения эффективной работы).

Согласно принципам Agile Manifesto, команды общаются с заказчиком (людьми из бизнеса) напрямую, причем делает это не только бизнес-аналитик, а и все остальные члены команды во время PBR (product backlog refinement workshops).

Команды, естественно, работают по какому-то плану, и этот план — product backlog (у нас их несколько, т.к. есть несколько направлений работы по продукту). У каждого бэклога есть Product Owner, над каждым бэклогом может работать одновременно несколько команд. Задачи распределяются по командам во время Joint PBR, на котором PO вкратце объясняет суть приоритетных задач и команды по очереди разбирают их для дальнейшего изучения, уточнения требований, взаимозависимостей и т.д.

Таким образом, к началу очередной итерации у каждой команды есть вполне актуальный sprint backlog, в котором для каждой user story есть:

  • требования (причем, собранные самой командой)
  • definition of done (что должно быть сделано в рамках user story)
  • acceptance criteria (как именно это должно в итоге работать)

С технической точки зрения качество обеспечивается:

  • TDD и, как следствие, 100% покрытием unit tests
  • активным использованием BDD и specification by example, понятных бизнесу и легко транслируемых в behavioural tests
  • работающими практиками continuous integration

А теперь о том, кто же это все менеджит.

Из четырех типов менеджеров у нас реально есть только две роли:

  • account manager в нашей терминологии называется delivery manager и занимается как раз обсуждением новых проектов с заказчиком, утрясанием рейтов, people management (включая вопросы увольнения и повышения з/п; при этом, естественно, ориентируется на фидбэки коллег, заказчиков и т.д.)
  • менеджер продукта — это как раз классический Product Owner, который знает пользователей, их приоритеты и экспертов в предметной области.

В принципе, часть функций «менеджера проекта» лежит на PO, но это касается только приоритизации требований и, частично, их декомпозиции (обычно вместе с командой). Разбиение на задачи, effort estimation и обновление burndown charts — задача команды (с которой они справляются). Естественно, в команде есть ScrumMaster, который следит за соблюдением процесса и, в нужный момент, может подсказать команде практику для более эффективной работы. С другой стороны, со временем необходимость в такой роли в большинстве команд отпала по ходу их совместной работы.

Кроме того, мы активно привлекаем внешних консультантов для анализа и улучшения наших процессов (таких, как Craig Larman, Portia Tung, Gojko Adzic и т.д.). Естественно, вопрос выделения бюджета на такие вещи, так же, как и на обучение/сертификацию/участие в конференциях решают совместно delivery managers со стороны как Люксофта, так и UBS. Но немаловажным фактором, влияющим на принятие решений, является, опять-же, фидбэк от команд.

Подробнее о проекте можно посмотреть в выступлении моих коллег на QCon London 2011.

Таким образом, мы подходим к шуточному вопросу, который я озвучил в комментариях к колонке Святослава: Должен ли у команды быть менеджер?

Я, конечно же, слукавил. Менеджер у проекта (не у команды!) быть должен. Но вот чего он не должен делать — так это «менеджить», а именно — «микроменеджить».

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

Как этого добиться? Подбирать правильных людей, учиться самому и учить их. Не жалеть средств на улучшение коммуникаций (от командировок до интерактивных досок). Слушать команды и слышать их. В общем, inspect and adapt!

Буду рад выслушать ваши комментарии и ответить на вопросы.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

LinkedIn

Схожі статті




27 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Sergey Prohorenko, (сори за отклонение от темы) во всех ли проектах в Luxoft используется Agile? Не то, чтобы это был спортивный интерес, но тем не менее

Не буду кривить душой, не во всех. Некоторые проекты и по вотерфоллу достаточно успешно работают, в Боинге так вообще жесткий CMMI Level 5 процесс.

Но большинство пытаются внедрять Agile (в основном, Scrum), не у всех, правда, best practices.

Коментар порушує правила спільноти і видалений модераторами.

И как UBS — доволен? Будут ещё больше аутсорсить?

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

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

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

Не помню, кто в своей книге описывал типичный случай «внедрения» XP:
" - У нас XP не работает!
— А что именно вы применяете из XP: парное программирование, US, CI?
— Нууу, нет
— Тогда почему вы называете свой процесс «XP»?

— Мы не ведем документацию!«

На Agile 2011 я даже специальное слово услышал для таких процессов — «Scrumbut» («we are using Scrum, but...»).

На Agile 2011 я даже специальное слово услышал для таких процессов — «Scrumbut» («we are using Scrum, but...»).
Русский вариант — «скрамно»

Этот пример в “Balancing Agility and Discipline” был, по-моему.

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

Единственное что могу посоветовать, если все таки Вы не хотите использовать полноценного ПМа в проекте, наймите програм менеджера, который в 3-6 месяцев не только нормально пропишет процессы для компании/проекта, но и на уровне микроменеджмента их качественно отладит.

Ооо, а вот и 23-летние senior project manager-ы пожаловали!

Уважаемый Андрей, спасибо за совет, но мы уже справились, проект почти завершен (к концу года должны закончить, судя по бэклогу и велосити). При этом обошлись без PMI, Prince2 и т.п.

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

Например, на прошлой неделе я был на конференции Agile 2011, там о таких внедрениях рассказывали, что буквально лет пять назад я бы не поверил:

  • использование Scrum в продажах (процесс ставил небезызвестный Jeff Sutherland)
  • Scrum в софтверном проекте для European Space Agency (довольно зарегулированная организация, надо думать)
  • использование Agile техник в San Jose City Council (в частности, в предвыборной гонке и в составлении городского бюджета)

И это только вершина айсберга. Даже PMI, глядя на глобальную смену фокуса, начал предлагать курсы по Agile Project Management.

Другое дело, что такой «mindshift» дорого стоит, слишком многие привыкли к вертикальной иерархии, и нужно много учиться и пытаться, чтобы научиться не просто «do Agile», а «be Agile». Но результат себя оправдывает. У нас — оправдал (программа сейчас — одна из основных на «радаре» топ-менеджмента как UBS, так и Luxoft, благодаря выстроенным процессам и созданным командам).

Сейчас читаю книгу об истории гугла, там был интересный момент, связанный с ПМ.

По мере (бурного) роста компании были попытки организации и процесса разработки. Появилась дюжина или две проджект менеджеров, которые были «щитом» между инженерами и другими департаментами и Ларри с Сергеем. Затем Ларри достало то, что он не может напрямую «командовать» работой инженеров и они разом избавились от всех ПМ. Все 300 или около того инженеров стали подотчетны напрямую какому-то VP по разработке.

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

Как-то так. Автор книги был маркетологом, так что технических подробностей там мало. Но все равно интересно.

И да, к топику статьи это почти никакого отношения не имеет. Просто захотелось поделиться. :)

зі всього побачив толк ПМа тільки в генеруванні репортів і трендіння з клієнтами....

Менеджеры? Опять?

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

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

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

в рамках проекта потребуется:

1. детализировать требования
2. разработать ПО
3. создать комплект документации
4. ввести в опытную эксплуатацию
5. провести обучение пользователей
6. провести доработку по результатам ОЭ

7. ввести в промышленную эксплуатацию

ПМ должен будет:

1. управлять процессом сбора и согласования требований
2. управлять командой разработки и тестирования при создании ПО
3. согласовать требования и сроки инсталляции оборудования на эксплуатационной площадке
4. управлять командой технических писателей
5. организовать обучение сотрудников заказчика

6. провести приемочные испытания и сдать систему

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

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

ребята, ну вопрос же риторический :)


2. управлять командой разработки и тестирования при создании ПО
4. управлять командой технических писателей

Ну вот вы же сами пишете, что:

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

А потом начинается старая песня про то, что должен ПМ.

Конечно, если итерация у нас полгода, и работает над ней 50 человек, то нужен специально обученный цербер, чтобы контролировать всех и вся. Но если итерация 2 недели, то команда, которая за эти две недели делает определенную часть бэклога вполне способна самостоятельно справиться с детализацией требований, разработкой, тестированием (особенно, если тест-кейсы бизнес-логики разрабатываются совместно с заказчиком в виде примеров и потом имплементируются в виде acceptance test-ов — FitNesse, JBehave, whatever), демонстрацией, доработкой, обучением пользователей и выкаткой в продакшен.

Ну ок, у нас выкаткой в продакшен занимается Production Services team (они же и L1 support), но все равно подготовкой implementation plans, «озеленением» регрессионных тестов и подготовкой скриптов для релиза занимаются feature teams.

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

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

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

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

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

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

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

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

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

Я где-то упоминал Люксофт? Эджайл был выбран именно UBS, и структура, описанная в статье, работает одинаково для всех локаций и подрядчиков. И это, как мне кажется, весьма показательно — если даже

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

то, наверное, не так все просто?

Более того, я не утверждаю, что менеджеров у программы нет. Есть, конечно же, programme manager в UBS, занимающий позицию executive director. Он общается со спонсорами (спонсор не один), выбивает бюджеты, отчитывается о статусе. Но вот чего он (и никто в программе) не делает, так это не ведет диаграммы Гантта («Gantt charts are 100% failure» © Jeff Sutherland), не следит, чем занимается каждая отдельная команда (это — внутреннее дело команды и PO) и вообще не имеет детального плана проекта (т.к. бэклог детализируется и реприоритизируется по мере продвижения проекта).

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

И вы совершенно правы, что

коллективной ответственности не бывает

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

Погоджуюсь.
Колись мав розмову з скрум проповідником на тему — ось проект завалився (ПРОВАЛ) — хто винний ? Розуміючи можливі відповіді («шукають винних в нас, а насправді треба досягати цілі» і інше ...) перефразував — Хто буде реально «пхати» проект і відповідати своїм хоча б авторитетом за його успішне виконання ?

Відповідь була цікава — а що проект може завалитися ? Ну не буде якоїсь фічі після спрінта — в новому добавим....

Те що описувалося в статті є просто спосіб організацїї надання послуг і не більше. причому значення має якість послуги що надається зараз. Бюджети, терміни і тд другорядне — вони ж мають продакт овнера — і він погодився на всі спрінти, зауважень до виконання спрінтів не має — всі щасливі...

І в багатьох (а в наши раеліях майже всіх) випадках це працює...

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

Ось в цій ситуації я б хотів побачити «капіталіста», що вкладе гроші (розуміючи що перші продажі (прибутки) десь повинні підти через рік — тобто йому НЕ ПОТРІБНІ ВЗАГАЛІ НІЯКІ БІЛДИ ПІСЛЯ ЯКИХОСЬ ІТЕРАЦІЙ- ЙОМУ ПОТРІБЕН ПРОДУКТ) і погодитья на вибачте але «розводіловку» з спрінтами і продакт овнерами.

Тому що навіть якщо ризики заховати (ітеративність і інкрементальність) вони не зникають.

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

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

В добавку к выше сказанному Сергеем, могу также добавить, что даже при успешном завершении всех запланированных работ и ввод их в эксплуатацию нет никаких гарантий, что это еще кому то будет нужно через пол года. Ведь как обычно бывает: работа в самом разгаре, а тут конкурент вышел на рынок с новой фичей. И начинается... Изменения в требованиях, длинные переговоры и тд. А ведь бизнесу нужно что? Это быстро выйти на рынок с новой версией чтобы удержать своих пользователей от ухода к конкуренту. И если команда этого не в состоянии сделать, то это и есть ПРОВАЛ.

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

Ідеї ітеративної розробки «в обед сто лет»....І прямого відношення до питання необхідності менеджмента вона не має..

Знов таки мантра про «Изменения в требованиях, длинные переговоры» — насправді це є мантра людей що продають людино-години, а не людей що націленні на результат.

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

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

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

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

Это вполне стыкуется с «принципом единоначалия», что за успех или провал проекта несет ответственность один человек. Спрашивать за возникшие серьезные проблемы с команды — это как-то глупо, и не один заказчик не станет этого делать. Финансово-бюджетные вопросы, решение о наеме и перераспределении людей в командах также лягут на такого менеджера. Равно как и ответственность за анализ рисков по контракту.

По-поводу роли Product Owner. Он мог бы соответствовать роли ПМ, т.к. именно он знает приоритеты требований и что и в какой момент ДОЛЖНО появиться в продукте, а также КОГДА должна начаться опытная эксплуатация и обучение. Он может даже вести диаграмму Ганнта, где будет расписано какая фича и в какой итерации появится. Однако т.к. product owner может быть назначен со стороны заказчика, а не организации-исполнителя, а также не несет ответственность за другие активности — это не ПМ.

Scrum master — тоже не ПМ. Но его роль очень важна на этапе становления agile команды. В самом начале работы по agile команда не сможет просто так взять и самоорганизоваться. Ее «самоорганизует» scrum master до тех пор, пока не наступит «привыкание к agile» и команде не станет на ноги самостоятельно. После этого роль scrum master уходит на второй план и он уже не так нужен. Хотя, с кого тогда будет спрашивать delivery manager? ;-)

Очевидно, что при вышеуказанной организации работы delivery/account manager будет-таки следить за статусом работы КАЖДОЙ из команд и обращаться к scrum master или product owner соответствующих команд для решения возникающих проблем.

Підписатись на коментарі