К основному контенту

Нет такой вещи как Проект, или профессиональная деформация коуча

Автор: Наталья Тренина

В последние пару лет, примерно раз-два в месяц, я получаю сообщения, похожие по своему содержанию. К примеру:
Наталья, здравствуйте. Хочу попросить у вас совета, как специалиста в области Agile и Scrum. Я нахожусь в процессе изменения вектора в своей карьере. Давно зрел, и сейчас окончательно решил стать Project Manager. Хочу быть причастным к созданию чего-то полезного. Дальше, как правило, следует беспокоящий вопрос, или просьба посоветовать что-то конкретное. Это очень волнительный момент, сколько бы раз происходило. Влиять на развитие организации морально куда легче, чем давать советы конкретному человеку. К тому же, #яжкоуч - прекрасно понимаю что советы редко бывают верны, и размывают ответственность за принятое решение.
Я пришла в гибкую разработку из классического мира проектного управления, куда меня занесло непредсказуемой закономерностью.

Вскормленная книгами Барри Боэма и Тома ДеМарко, за годы фриланса, класическая девочка-задрот, постепенно перевоплощалась из программиста в предпринимателя. Особым шагом в развитии стал крах небольшой компании, которую мы с партнером строили на доверии работы с одним ключевым заказчиком. Которому, как вы догадываетесь, не стоило доверять
Моя первая управленческая седина проявилась именно тогда: кризис 2005-го, слабый маркетинг, недостаток связей и общего жизненного опыта, желание спрятать голову от проблем в теплом ламповом свечении строчек кода.

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

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

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

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

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

7 июля 2009 года я начала себя с чистого листа. Эти 6 лет были мощными во всех отношениях развития - как Agile-коуча, так и предпринимателя. Мне повезло - у меня был невероятный партнер, прекрасные учителя, поддерживающая команда, и много возможностей для практики.
Но есть один побочный эффект: я стала совершенно непригодна для давания советов в винтажном управлении проектами. И честно извинилась перед коллегой за свою бесполезность в том случае, если он планирует развиваться по траектории PMP .

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

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

Теперь, на высоком уровне абстракции - там, где формулируется моя профессиональная миссия - попросту нет Проекта.

Есть Продукт. И есть Команда.
Есть Жизненный цикл Продукта.
И есть Жизненный цикл Команды.
Продукт, Команда и их постоянное, взаимообуславливающее развитие.

Как же быть, если вы PM, но ваш внутренний вектор все более отчетливо направляется в сторону Agile, Scrum, Lean StartUp..? Отличия ролевой парадигмы, особенности работы над видением и требованиями, развитие высокопродуктивных команд и предпринимательского духа компании, нюансы внедрения изменений - все это в программе одесского сертификационного класса.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


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

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton)
Переведено с английского проектом Agile Translations.



Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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