Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон
Шрифт:
Интервал:
Закладка:
Поэтому неудивительно, что ежедневные летучки могут нарушать поток. Какое соотношение состояния потока и встреч лучше всего подходит вашей организации? Почему бы вам… не спросить своего разработчика?
Многие разработчики хотят свободы, чтобы понимать клиентов, глубоко вникать в бизнес и использовать весь свой потенциал. Но чрезмерно жесткое следование методологии аджайл может убедить разработчиков в том, что их работа вовсе не понимание клиентов или бизнеса, поэтому они ограничиваются той ролью, которую от них ожидает система. Важно не дать менеджерам по продукту и разработчикам попасть в эту ловушку. Если разработчики ограничивают себя, это может в краткосрочной перспективе упростить их жизнь: «Просто говорите мне, что делать». Но довольно скоро они почувствуют неудовлетворенность и начнут искать работу в более подходящем месте. Методология аджайл сама по себе довольно хороша для разработчиков. Но руководители низшего уровня должны позаботиться о том, чтобы разработчики оставались вовлеченными в бизнес и относились к разработке как к совместной работе, а не как к выполнению задач.
Все в меру
Одна из любимых поговорок моего отца – «Все в меру». Большинство вещей в нашей жизни нормальны, пока ты не увлекаешься ими слишком сильно. Алкоголь. Телевизор. Секс. Именно так я подхожу к методологии аджайл при разработке ПО. Вместо того чтобы развертывать полномасштабную реализацию аджайл с коучами, консультантами и кучей жестких правил и процедур, некоторые компании просто берут несколько принципов аджайл, которые имеют смысл, и отбрасывают остальное. «Я уже давно не использую какую-либо формальную методологию», – говорит соучредитель компании Breaker и ее технический директор Лия Калвер (мы упоминали о ней в главе 4). По ее словам, инженеры у нее практикуют быстрые спринты, но не утруждают себя другими элементами аджайл, такими как ежедневные летучки.
В Twilio мы не придерживаемся строго какой-либо определенной формы аджайл и позволяем командам выбирать свой стиль работы – какие-то из них принимают более формальные элементы аджайл, другие – менее формальные. Но мы строго реализуем ряд ключевых идей. Самое строгое правило состоит в том, что небольшие автономные команды – основа прогресса. Мы ограничиваем размер команд 10 сотрудниками. Вместо системы планирования, навязывающей им работу, мы просим их намечать собственные ежеквартальные цели на основе пожеланий клиентов. Когда представления команд о том, что необходимо, отличаются от наиболее важных целей руководства, оно не спускает указания сверху, а начинает дискуссию для разрешения конфликта. Это некоторые из обязательных элементов для всех наших команд разработчиков, число которых приближается к 150.
Когда структура сформирована, мы обычно позволяем командам выбирать свой стиль работы. Большинство (если не все) команд работают в режиме двухнедельных спринтов и стремятся достичь заметного прогресса в конце каждого из них. У одних команд это получается лучше, чем у других. Все они стараются ограничивать объем незавершенной работы, что является целью методов скрам и канбан. Некоторые команды работают в одном помещении, тогда как другие распределены по всей стране или даже по континентам. Однако лучше всего держать команды в пределах четырех или пяти часовых поясов друг от друга, чтобы обеспечить достаточное пересечение рабочего времени. Большинство команд оценивают производительность с помощью пунктов истории. Хотя определение пунктов истории у каждой команды свое, это нормально. Такая практика является частью потока работ многих аджайл-команд, и мне она нравится. Оценка здорового подхода к работе у технической команды не менее важна, чем измерение результативности продавца на закрытых распродажах.
Наши команды находятся на разных этапах реализации методологии «Спросите своего разработчика». В некоторых командах инженеры регулярно обсуждают клиентские аспекты создаваемого продукта. Чаще всего это команды, где разработчиков знакомят с проблемами клиентов, а не только с пользовательскими историями.
Я всегда нахожу время, чтобы пройтись по офисам Twilio и поинтересоваться у инженеров, над чем они работают, – мягко и только если они не очень сосредоточены. Обычно я спрашиваю, какой проблемой клиента они сейчас занимаются. Нередко завязывается обстоятельный разговор о клиенте, но бывает, что в ответ я получаю безразличное пожатие плечами и слышу: «Я не уверен, что это действительно проблема клиента, этим вопросом мне поручил заняться менеджер по продукту». Это признак того, что команды, возможно, слишком далеко зашли в аджайл-разделении труда. В таких случаях полезно поговорить с командой – и с лидерами, которые могут получить более высокую отдачу от своей команды, и с разработчиками, которые довольствуются тем, что «не знают». На мой взгляд, такой подход препятствует карьерному росту и тех, и других.
Если вам интересно, как реализуется методология аджайл и способствует ли она повышению гибкости, поговорите со своими разработчиками и менеджерами по продукту. Вы поймете, как они работают, насколько их работа является гибкой и клиентоориентированной. В частности, постарайтесь понять, насколько эффективна взаимосвязь менеджеров по продукту и технических талантов. Спросите разработчиков, хотят ли они, чтобы менеджеры по продукту были диспетчерами или координаторами взаимодействия с клиентами. Выясните у менеджеров по продукту, смотрят ли они на свою роль так же, как и вы. Вы можете поинтересоваться у команд, дорабатывают ли они рабочие планы на основе единого понимания клиентов или действуют по принципу «разделяй и побеждай»: менеджеры по продукту знают клиентов, а инженеры знают код. Я считаю, что команды, где менеджеры по продукту знают довольно много о коде, а разработчики столь же много о клиентах, делают более совершенные продукты. Позволяют ли спринты каждый раз создавать какой-нибудь полезный продукт? Регулярно ли команды добиваются прогресса? Нет единственно верного способа реализации методологии аджайл, но есть возможность реализовать ее плохо и удалить клиентов из рабочего процесса. Понимание ценности методологии аджайл, а также того, как команды внедряют ее, объясняет,
