Представьте на минутку, что вы оказались на хлебозаводе. Сначала всё выглядит совершенно непонятно: куча оборудования неизвестного назначения, вокруг него суетятся люди. Затем вы немного осваиваетесь и замечаете более простые и привычные вещи. Вот контейнеры с кунжутом. Вот большие чаны с тестом. Вот маленькие шарики из этого теста. Вот уже выпеченные булочки.
Всё это — производственне запасы, сырьё или полуфабрикаты, которые надо превратить в конечный продукт и продать, чтобы получить прибыль. Запасы перемещаются и накапливаются между машинами. Рядом с машиной, посыпающей кнжутом булочки для гамбургеров стоит контейнер с этим самым кунжутом. В самом конце конвейера — ящики с готовым хлебом и булочками, ожидающие погрузки в грузовики, которые отвезут их голодным потребителям.
Хранение запасов стоит денег. Предположим, что на хлебозаводе есть шесть 50-тонных силосов для хранения муки. Это значит, что в среднем каждый день в них находится около 150 тонн муки. По сегодняшним ценам это 73000$ мёртвого капитала.
Есть и другие издержки, например порча. Мука может храниться месяцами, но готовые булочки начинают терять в цене как только выйдут из печи; через 24 часа они не стоят почти ничего.
Зачем тогда вообще хранить запасы? Потому что есть ещё и расходы связанные с их нехваткой. Если на заказ новой партии булочек с кунжутом уходит два дня, то, если они вдруг закончатся в вашей закусочной, ваш бизнес по продаже гамбургеров остановится на двое суток. Запасы — это буфер, который предотвращает непредвиденные остановки. Сейчас придумано множество алогоритмов для вычисления оптимального объёма этих буферов (для начала: бережливое производство, теория ограничений).
Зачем я вам всё это рассказываю? Затем, что в производстве ПО тоже существуют места, где накапливаются «производственные запасы». И хранение этих запасов может стоить кучу времени и денег.
«Что? Разве можно сравнивать производство софта и булочек?» — спросите вы.
Подумайте об идеях, как о сырье и полуфабрикатах. Так же как и кусочки теста, идеи проходят через несколько точек обработки прежде чем будут представлены конечному пользователю в виде функций продукта:
- Принятие решений (стоит ли нам реализовать эту функцию?)
- Проектирование (спецификации, планирование, макеты и т.д.)
- Реализация (написание кода)
- Тестирование (поиск ошибок)
- Отладка (исправление ошибок)
- Выпуск (доставка программы потребителям, развёртывание на сервере)
(P.S. «Водопад» тут ни при чём. Нет. Совершенно точно нет! Отвалите!)
Запасы могут скапливаться между всеми этим этапами. Например, когда программист заканчивает писать код (этап 3), он отправляет его тестировщику (этап 4). В любой момент времени какое-то количество кода дожидается своей очереди на тестирование. Это и есть запасы.
Стоимость таких запасов огромна. Они могут добавить шесть или даже двенадцать месяцев ко времени релиза. Всё это время куча кода и идей простаивает на разных этапах производства вместо того, чтобы попасть в руки пользователей. Эти задержки могут стать решающим отличием инновационного продукта (iPhone) от вечно вторых догоняющих аналогов (Windows Phone). Практически невозможно заставить потребителя купить Windows Phone, если iPhone вышел всего шестью месяцами раньше.
На многих рынках работает сетевой эффект, и быть первым значит стать тем победителем, который получает всё. Так что размер запасов на этапе разработки может иметь решающее значение.
Давайте пройдёмся по трём местам, где скапливается больше всего запасов.
Бэклоги. Вокруг каждого проекта роятся идеи новых фич, и появляются они гораздо быстрее, чем их можно реализовать. Поэтому их записывают в очередь на реализацию — бэклог. Множество идей в бэклоге на самом деле никуда не годятся и записываются только для того, чтобы не обидеть тех, кто их придумал. В результате все довольны.
Проблема в том, что 90% фич из бэклога никогда не будут реализованы. Так что каждая минута, потраченная на запись, проектирование, обдумывание или обсуждение таких фич — потерянное время. Когда я слышу, что некоторые команды практикуют регулярное «расчёсывание бэклога», аккуратно и методично растрачивая драгоценное время на вещи, которые никогда не станут частью конечного продукта, мне хочется вырвать себе глаза.
Предложение: Не позволяйте бэклогу разрастаться больше чем на месяц-другой работы. Если бэклог полон, не вносите туда новых элементов, пока не реализуете старые. Не надо тратить время на обсуждение, проектирование или спецификации фич из бэклога. Он должен рассматриваться как список вещей, о которых запрещено говорить и над которыми запрещено работать до начала реализации.
Баг-трекеры. Это отличная вещь. Особенно если багрепорты подробны, полны и конкретны. Но я заметил, что в реальном мире желание не пропустить ни единого сообщения об ошибке приводит к тому, что однажды вы с ужасом обнаруживаете, что в вашем трекере 3000 незакрытых ошибок, некоторые из которых уже давно потеряли актуальность, другие невозможно воспроизвести, а большинство даже не стоят того, чтобы их исправлять, потому что они совершенно незначительны. На то, чтобы собрать эти багрепорты, ушли месяцы и годы, и вы спрашиваете себя, как это вообще возможно — у нас 3000 ошибок, а продукт при этом очевидно очень хорош, пользователи любят его и пользуются им каждый день? И вам становится ясно, что вы просто чересчур усердно собирали эти ошибки, вместо того, чтобы развивать продукт.
Предложения:
- Сразу отсеивайте ошибки, которые слишком незначительны, чтобы их записывать.
- Следите за тем, чтобы в любой момент время на исправление всех ошибок из багтрекера не превышало двух недель.
- Если их накопилось больше — остановитесь и начните исправлять их, пока не доберётесь до откровенно глупых и незначительных ошибок. После этого закройте их все с пометкой «won't fix». Не бойтесь пропустить что-то важное — серьёзные ошибки обязательно всплывут ещё не раз.
Фичи, ожидающие релиза. До сих пор многие команды работают квартальными или годичными циклами выпуска версий, обычно в случае если процесс развёртывания новой версии сложен и дорог. Операционные системы и любой другой софт, который пользователи должны устанавливать самостоятельно, попадает в эту категорию.
Это одна из самых дорогих форм запасов. Они могли бы приносить вам деньги, но они просто пылятся в ожидании релиза, а тем временем продукт более шустрых конкурентов уже делает это!
Самое страшное, что разработчики часто даже не чувствуют разрушительного эффекта таких задержек, так как вся команда сидит на ночных сборках и использует новые фичи каждый день. Наверняка в Microsoft все жутко довольны Windows 8, которой они пользуются уже с год, так что им не понять страданий OEM-поставщиков, которые пытаются продавать компьютеры с Windows 7 в мире Mac OS X Lion.
Предложение: Не позволяйте готовому функционалу лежать мёртвым грузом. Переработайте свой процесс развёртывания так, чтобы обновляться каждые нескольок месяцев, а не лет. Если вы уже это сделали, постарайтесь обновляться еженедельно. Поднимайте планку всё выше, и выкатывайте небольшие изменения как можно чаще.
Итак, к чему я веду? У нас в Fog Creek были все три вида запасов: гигантский бэклог, чудовищная база багрепортов и фичи, годами дожидающиеся релиза. Мы прочувствоали всё это на своей шкуре. И я понял, что нам нужна система, которая ограничивала бы размер запасов.
Сначала я придумал штуку, которую я называл «Пять вещей». Идея была в том, чтобы программа для управления проектами позволяла бы каждому отвечать не больше чем за пять вещей — две в работе, одна на подходе и ещё пара — в планах на ближайшее будущее. В таком виде идея так и не была реализована, но она легла в основу Trello.
Trello отлично работает с небольшим количеством запасов, но быстро становится громоздкой и неудобной, когда вы впихиваете в неё много лишнего. Это сделано намеренно. Это позволяет видеть и чувствовать, когда запасов слишком много. (щёлкните по скриншоту и посмотрите на нашу собственную страницу разработки).
Каждый день вы смотрите на доску Trello и видите, например, что уже целых 17 фич готовы и ждут релиза. Это побуждает устранить затор как можно быстрее.
Каждый раз, когда кто-то предлагает безумную новую идею, вы смотрите в бэклог и, если там слишком много записей, не тратите время на обсуждение и обдумывание этой идеи.
Я искренне надеюсь, что такой подход позволит вам тратить намного меньше времени на работу над вещами, которые никогда не увидят белый свет. «Расчёсывание бэклога». Что за чушь!
Автор: ilya42
