Эй, так в чем проблема?

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

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

Для того, чтобы понять эту проблему получше, давайте рассмотрим задачу строительства дома. Допустим, кто-то решил построить дом на определенном участке земли. У дома должно быть два этажа и гараж. У нас даже есть грубая схема передней части дома, начерченная на салфетке. И вот клиент подходит к вам со всей этой информацией и салфеткой и спрашивает: «Тебе же этого хватит, чтобы приступить к строительству, да?» И как вам, хватит?

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

— Ну… — говорит вам клиент, — давай ты пока начнешь строить; а я буду по мере возможности сообщать тебе новую информацию. Так мы не будем тратить время впустую.

Вы точно знаете, что информации для того, чтобы строить, не хватает, а дальнейшие расспросы клиента ничего пока не дадут. Но дедлайн никто отменять не собирается и вы никак не можете себе позволить просиживать штаны в надежде на то, что клиент расщедрится на детали. И что вам остается? Делать предположения и допущения.

Старая поговорка гласит: «when you assume, you make an ass of u and me» (когда делаешь предположения, выставляешь идиотами нас обоих), и это чистая правда. Предположения опасны и очень часто лживы. И все же без предположений запустить проект не получится. Итак, что вы делаете. Вы начинаете с допущения, в истинности которого вы точно уверены — о том, что у дома будет два этажа и гараж. Тут же вопрос — гараж надо делать пристройкой или отдельно? И какого размера нужно его делать? Не будем усложнять, допустим, что гараж должен быть построен отдельно и рассчитан на одну машину. Теперь можно работать над гаражом как над отдельным зданием, а потом, когда станут известны подробности о доме, его можно будет строить рядом с гаражом.

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

Спустя еще несколько дней гараж почти закончен. Вы довольны качеством результата, ведь у вас было так мало информации! Вы уже готовы приступить к строительство дома, когда клиент сообщает новые подробности — гараж должен быть рассчитан на две машины и пристроен к дому. У вас трагедия — вы сделали такой крутой гараж, а теперь его придется снести, чтобы построить «нужный». Хуже того, теперь у вас остается меньше времени, чтобы закончить весь проект — и вот вы уже начинаете ворчать.

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

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

И кто-то еще удивляется, что разработчики так быстро «выгорают» и меняют работу?