Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

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

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

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

Все в меру

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

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

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

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

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

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