Не надо обращаться с разработчиками, как с рабочими конвейера: какие есть ловушки в аджайле Статьи редакции

Отрывок из книги гендиректора Twillo Джеффа Лоусона «Спроси разработчика: как стать лидером рынка с помощью создания собственного ПО», которую выпустило издательство «Альпина Паблишер».

Методология аджайл — или же гибкий подход к разработке — не панацея от всех проблем, как ее иногда описывают неофиты. Как и любая система организации, аджайл-подход имеет свои плюсы и минусы. В недавнем разговоре с генеральным директором публичной компании я спросил, как продвигается их аджайл-трансформация, и он ответил: «Сборище лентяев рассказывает нам, как вести бизнес, — и ничего не меняется!» Я чуть не упал со стула. Где же методология аджайл дала сбои?

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

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

Это подходит для сборки автомобилей, но не для работы творческих людей. Канбан-доски напоминают мне о статье, прочитанной несколько лет назад, — она была интересной, но немного пугающей. В неи рассказывалось о китайской деревне Дафэнь, на которую приходится 61% мирового производства картин маслом, многие из них — это копии работ великих мастеров. Это фабрика изобразительного искусства со «сборочными линиями», выпускающими выполненные вручную копии картин Винсента Ван Гога, Леонардо да Винчи, Энди Уорхола и многих других. Художники работают в бригадах. Каждый мастер идет по проходу между мольбертами и наносит несколько мазков на каждый холст. Следующий добавляет еще один элемент... В Дафэне работают более 8 тысяч художников, и они выпускают от трех до пяти миллионов картин в год. Превращение Моне в деньги — это довольно хитроумный трюк. Но я был потрясен, когда прочитал о Дафэне: меня оскорбляло то, что компании нанимают творческих людей, а затем полностью изгоняют творчество из их работы.

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

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

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

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

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

Одна из любимых поговорок моего отца — «Всё в меру». Большинство вещей в нашей жизни нормальны, пока ты не увлекаешься ими слишком сильно. Алкоголь. Телевизор. Секс. Именно так я подхожу к методологии аджайл при разработке ПО. Вместо того чтобы развертывать полномасштабную реализацию аджайл с коучами, консультантами и кучей жестких правил и процедур, некоторые компании просто берут несколько принципов аджайл, которые имеют смысл, и отбрасывают остальное.

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

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

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

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

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

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

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

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

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

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

#книги #аджайл