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

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

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

В последние пару лет, примерно раз-два в месяц, я получаю сообщения, похожие по своему содержанию. К примеру:
Наталья, здравствуйте. Хочу попросить у вас совета, как специалиста в области 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). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

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

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

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

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.