Осталось справиться еще с одной трудностью – настоящей бедой разработки программного обеспечения и ее своевременного завершения. Предположим, вы уверены, что у вас есть нечто достойное быть разработанным. Для многих людей очень важно, чтобы вы закончили разработку к определенной дате. Существует секрет, как сделать эту работу вовремя, на протяжении веков используемый в искусстве. В следующей главе мы рассмотрим, как применить его при разработке ПО.
Глава 4. План своевременного завершения
Это Аарон и Майк. Они работают в компании под названием Workiva, где выпускают ряд продуктов на основе платформы Wdesk. Эта организация помогает другим большим компаниям решать серьезные задачи и является одной из крупнейших компаний типа «программное обеспечение как услуга», о которых вы, скорее всего, никогда не слышали.
Аарон и Майк выглядят очень довольными. Но это типично для людей, которые работают вместе над решением сложных задач. Или это потому, что один из парней держит в руке бутылку пива? Нет, дело вовсе не в этом. Они довольны, так как только что нашли решение сложной задачи, а пиво является лишь наградой за труд. Кстати, если вы не получаете пиво или еще какое-нибудь поощрение за решение сложных задач там, где работаете, стоит с кем-нибудь поговорить об этом.
Аарон и Майк только что завершили очередной раунд исследования продукта, и теперь они уверены, что нашли решение, которое стоит разработать и запустить для использования клиентами.
Исследование началось со смутной идеи: выяснить, кому и каким образом могла бы быть полезна функциональности, с которой они начали работать. Они обсудили идею с заказчиками и проверили свои предположения о том, как те работают в данный момент и с какими проблемами сталкиваются. После этого ребята создали простые прототипы. Аарону и Майку оказалось вполне достаточно создать простые электронные прототипы в Axure и удаленно протестировать их вместе с заказчиками, чтобы убедиться, во-первых, что решение применимо и полезно, а во-вторых, что заказчики его оценят. Необходимости встраивать прототип данной функциональности в работающее ПО, чтобы получить ответы на свои вопросы, не было.
После нескольких итераций с простыми прототипами ребята наконец убедились, что у них есть нечто достойное реализации. Вам может показаться, что это заняло очень много времени, но на самом деле потребовалось около трех дней. Последним шагом стало создание бэклога и плана предъявления функциональности пользователям. План вы можете видеть на фотографии. Это очень хороший план, именно поэтому они так радуются.
Очень важно отметить, что эта карта не охватывает весь продукт – она касается лишь функциональности, которую они добавляют в существующее приложение. Вот почему она намного меньше карты Гэри из главы 1 или карты команд Globo.com. Я подчеркиваю это потому, что некоторые ошибочно полагают: они должны составить карту историй всего продукта, чтобы внести крохотное изменение, и по этой причине отказываются от использования карт вообще.
Включайте в карту лишь то, что необходимо для поддержки обсуждения.
Поделитесь с командой
Чтобы внедрить новую функциональность, Майку и Аарону нужно было, чтобы у них и команды выработалось общее мнение о ней. Ребятам из их команды нужно было осознать проблему и возможности для улучшения, а также оценить, сколько времени займет реализация решения. Для этого Майк с Аароном и создали окончательный вариант карты. С ее помощью они изложили историю функциональности шаг за шагом с точки зрения пользователя. Вы заметили, что на карте присутствуют распечатки экранов? При построении карты ее авторы использовали экраны, отмечая на них детали по мере продвижения, чтобы при ознакомлении с историей легче было понять решение. Именно так поступают сотрудники компании Disney, когда излагают сценарий мультфильма с помощью раскадровок.
Если члены команды задавали вопросы, почему на экране происходит то или иное, Майк и Аарон рассказывали о вариантах, которые они рассматривали, и о том, как вели себя пользователи. Если кто-то спрашивал, что именно происходит после введения данных, ребята были готовы дать ответ, так как уже обдумывали это. А если они не могли ответить, то возможные решения обсуждались всей командой, записывались на стикерах или помечались на эскизах и заносились в модель. Было добавлено довольно много стикеров, касающихся деталей, не предусмотренных Аароном и Майком, но пришедших в голову членам команды. Позднее Аарон признался мне, что команда обнаружила несколько технических зависимостей, о которых они с Майком никогда бы не догадались.
Секрет верной оценки затрат времени
Каждому, кто давно плавает в море разработки программного обеспечения, хорошо известно: одна из самых трудных задач, которую нам приходится решать, – необходимость оценить, сколько времени займет разработка. Я хочу открыть вам один из самых важных секретов правильной оценки времени.
Лучше всего затраты времени оценивают те разработчики, которые верно понимают, что именно они оценивают.
Существует множество методов, с помощью которых, как предполагается, можно дать очень точную оценку времени, но я не буду приводить их здесь. Я лишь хочу сказать: ни один из этих методов не будет работать, пока все люди, разрабатывающие концепцию ПО и реализующие ее, не начнут понимать ситуацию одинаково.
При выработке одинакового понимания временные оценки не должны замалчиваться. Поэтому лучше всего прямо сейчас обсудите их с кем-нибудь еще.
Планируйте разработку шаг за шагом
У команды Workiva не было возможности уменьшить количество необходимых элементов в разработке. Они не могли проделать то, что сделала команда Globo.com, как описано в главе 2, то есть оставить часть запланированного на потом. В Workiva было решено, что нужно разрабатывать сразу все. На этапе прототипирования у них уже была возможность исключить многое и подтвердить, что решение до сих пор остается полезным для заказчиков. Тем не менее на карте можно выделить три среза.
«Зачем они вообще тратили на это время?» – можете удивиться вы. Действительно, предъявить треть от того, что нужно заказчикам, – это примерно как продавать одну треть спортивного автомобиля: никто не сможет на нем ездить. Но Майк владелец продукта. Он не может отойти в сторону после того, как найдено хорошее решение. Его роль немного меняется, и сейчас он больше похож на режиссера в кино: должен присутствовать при съемках каждой сцены. И ему нужно решить, какие сцены должны быть отсняты первыми, а какие – последними. Он знает, что к концу съемок фильма все сцены сложатся вместе и составят одно последовательное повествование.
Поэтому Майк и работал со своей командой над составлением плана разработки. Вот что они сделали – разделили карту тремя поперечными срезами.
Первый срез включает в себя основные функциональные элементы. Как только все фрагменты, входящие в этот срез, будут реализованы, работа с функциональностью может быть проделана в приложении шаг за шагом. Функциональность будет работать не во всех ситуациях, где запланировано, поэтому предъявлять ее пользователям на этом этапе нельзя: последует лавина жалоб и возмущений. Но зато Майк и его команда смогут понаблюдать за работой функциональности с начала до конца. Они смогут ввести реальные данные и оценить производительность приложения, а также применить некоторые средства автоматизированного тестирования, чтобы оценить способность к масштабированию нагрузки. Можно узнать многое о технических рисках, которые способны вызвать значительные проблемы позднее. Таким образом, двигаясь вперед, команда будет более уверена в своевременном окончании разработки. Или по крайней мере будут выявлены непредвиденные трудности, которые могут замедлить работу. Первый срез я называю функциональным ходячим скелетом – этот термин я позаимствовал у Алистера Коберна. Я слышал также, что в этом значении употребляются слова «стальной каркас» или «трассирующая пуля».
Второй срез нужен для дополнения функциональности и приведения ее в состояние, близкое к готовности для релиза. Кроме того, без сомнения, в процессе этого возникнет что-то непредусмотренное, например, упущенные характеристики, необходимые для работы функциональности, важные детали, которые невозможно было выявить, работая с прототипом. Возможно, обнаружится, что производительность системы ниже ожидаемой и необходима дополнительная работа, чтобы довести скорость до нужной величины. Все эти так называемые предсказуемые неожиданности – концепция, близкая к «неизвестным неизвестным» Дональда Рамсфилда. Не думайте, что ничего такого не обнаружится. Вы же знаете: они существуют.
И наконец, третий срез нужен для окончательной доработки функциональности и доведения ее до наилучшего состояния. Кроме того, на этом этапе придется разбираться с теми самыми неожиданностями.
Не каждый срез достоин релиза
Все перечисленные срезы не являются запусками продуктов для заказчиков и пользователей – это всего лишь своего рода вехи, на которых члены команды должны приостановиться и оценить, как далеко они зашли. Но пусть это вас не смущает: с точки зрения заказчика или пользователя, работа еще не закончена.
Команды Майка и Аарона оценили, что работа над функциональностью потребует примерно двух месяцев. Как и Эрик, они использовали двухнедельные спринты, значит, для реализации потребовалось бы четыре спринта. Я думаю, они могли бы разделить карту на четыре среза, чтобы на каждый пришелся один спринт, но ребята не рассматривали срезы с этой точки зрения. И вам тоже лучше так не делать. Воспринимайте срезы просто как наборы определенных задач по разработке, каждый со своей исследовательской целью. А решать, в какие спринты или итерации войдет очередной набор, нужно по мере необходимости.