Стиль перевернутой пирамиды в Agile-разработке

Современные репортеры, как правило, пишут свои статьи, используя так называемый стиль «перевернутой пирамиды». Они начинают с самой важной информации в первом предложении, за которой следует следующая по важности информация и так далее. Этот формат не только дает читателю наиболее быструю отдачу от его денег, но и предоставляет как репортерам, так и их редакторам огромную гибкость в неопределенных и быстро меняющихся условиях. Современные методы разработки программного обеспечения, такие как Agile, используют ту же идею, чтобы дать клиентам наибольшую отдачу от их денег – в столь же неопределенных условиях.

История гласит, что метод перевернутой пирамиды был изобретен, когда репортеры начали использовать телеграф для передачи своих историй редакторам газет из разных уголков страны. До этого большинство статей писались так же, как сегодняшние школьные сочинения или технические отчеты, то есть в дедуктивном стиле с заключением в конце. Но репортеры быстро обнаружили, что телеграф был ненадежным механизмом передачи. Мало того, что физическая связь была ненадежной, так еще их легко могли выкинуть с линии, если более важный клиент, например, военный, требовал срочной передачи. Наполовину переданная статья с заключением в конце была бесполезна («Кастер участвовал в решающем сражении, но выиграл он или проиграл?»).

Репортеры быстро адаптировали свой стиль письма так, чтобы каждая статья начиналась с самых важных деталей. Этот новый формат означал, что если передача материала прерывалась, то у редактора все равно была самая ценная часть статьи из возможных. Это также означало, что репортеры сохраняли свои рабочие места и свои доходы; какой смысл держать репортера, если он не может вовремя предоставить хороший текст?

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

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

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

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

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

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

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

Автор: Кларк Чинг
Источник

Книга в подарок

Опубликована наша книга «Прорыв. Единственный путь развития бизнеса». Это бизнес-роман о производственном предприятии, столкнувшимся с «потолком» в своем развитии. Для прорыва в развитии руководству и персоналу приходится преодолеть собственные, выстраданные на опыте, но устаревшие убеждения. Читателю предлагается пройти через этот прорыв вместе с героями. Вы увидите трудности такой трансформации, осознаете природу сопротивления изменениям и реальный путь к таким изменениям.
Подпишитесь на наш Telegram-канал и получите книгу в подарок!

Получить подарок