3 способа разработки

Разработка, Направленная на Создание Мусора

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

Главным продуктом РНСМ являются бессмысленности, написанные по столь «ценным» идеям: концепты, графики, описания дизайна и прочие продукты, создаваемые для одной лишь цели — быть выброшенными в корзину.

Это работает так:

• Креативные Ребята приходят с длинным списком «фич А и Б, которые мы можем сделать в нашем продукте». Невероятно детальный список того и этого, что наш будущий Великолепный Продукт мог бы делать. Какие они молодцы, что придумали всё это! Ну а теперь, когда основная (креативная) часть работы уже сделана, остался лишь вопрос технической реализации, ну а это ведь не сложно!
• Менеджеры и их консультанты передают блестящие идеи дизайнерам и архитекторам, которые пишут тонны спецификаций. На этом этапе десяток базовых идей превращается в несколько сотен детальных требований. Для Продукта, который изменит мир.
• Спецификации передаются разработчикам, которые несколько… удивившись осторожно спрашивают, а кому же, …, пришло в голову всё это… написать? Они начинают объяснять, почему кое-что сделать трудно, а кое-что вообще невозможно, но… Поезд уже ушел. Архитектура утверждена на самом верху, ну и в самом деле — кто такие эти разработчики, чтобы спорить с Креативными Ребятами и их высокооплачиваемыми консультантами?
• Разработчики возвращаются на свои рабочие места, униженные и обречённые строить гигантскую «креативную-и-элегантную» кучу мусора. Эта работа выворачивает мозги, поскольку теоретики сверху абсолютно не думали о нюансах практической реализации. «Элементарные» и «минорные» изменения могут занимать недели. Проект начинает запаздывать, менеджеры нажимают на разработчиков, пропадают свободные вечера и выходные.
• В конце концов, нечто, кое-как симулирующее работающий продукт, выпускается. Оно несуразное и хрупкое, сложное и уродливое. Креативные Ребята обзывают разработчиков некомпетентными бездарями и платят своим консультантам ещё больше денег, чтобы те прицепили бантик на эту свинью, и вот внешне как-будто становится чуть-чуть лучше.
• К этому времени менеджеры начинают пытаться продать весь этот ужас, и вдруг (сюрприз-сюрприз!) оказывается, что он триста лет никому не нужен. В этом месте самое главное — не упасть в грязь лицом и… выкинуть миллион долларов на рекламную компанию! Приходится чуть ли не доплачивать, чтобы убеждать людей пользоваться этим продуктом. Ах, этот тупой, отсталый и неблагодарный рынок!
• Спустя год интенсивного маркетинга продукт всё ещё убыточен. Более того, весь этот год его преследовали катастрофические провалы и негативные отзывы в прессе. Компания тихонько спускает его в урну, увольняет консультантов, покупает конкурентный продукт от компании-стартапа, живущей в соседнем гараже и выпускает его как «Версию 2.0». Сотни миллионов долларов выброшены в корзину.

Тем временем, еще один Визионер из топ-менеджмента выпивает лишнюю рюмку с ребятами из маркетинга и ему в голову приходит Блестящая Идея…

Разработка, Направленная на Создание Мусора могла бы быть карикатурой, если бы не случалася в жизни столь часто. Что-то типа 19-ти из 20-ти продуктов, выпускаемых на рынок большими фирмами, являются провальными (да, 87% статистики берётся с потолка). Оставшийся 1 из 20-ти является успешным по каким-то совершенно случайным причинам, типа совсем плохих конкурирующих продуктов или нового рынка.

Главный вывод из применения РНСМ легко сделать, но трудно принять: идеи не стоят ничего. Без исключений. Нет никаких «блестящих идей». Каждый, начинающий дискуссию с восклицания «ох, а ещё мы можем сделать вот ЭТО!» должен быть избит окрущающими со всей страстью и энергией, которую они берегли для звонящих в двери свидетелей Иеговы. Все эти Креативные Ребята с их «гениальными идеями» выглядят как человек, сидящий в кафе у подножья горы, попивающий свой горячий шоколад и объясняющий окружающим: «Эй, у меня есть отличная идея — мы могли бы забраться на эту гору! И построить коттедж на вершине! С двумя саунами! И садом! Его можно будет подключить к солнечным батареям! Чуваки, это круто! В какой же цвет мы его покрасим? Зелёный! Нет, синий! Так, идите и постройте его, а я останусь в этом кафе и нарисую пару графиков для нашего проекта!»

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

А теперь, после победы над Драконом Полной Неуместности, мы атакуем Демона Сложности.

Разработка, Направленная на Создание Сложности

Хорошие инженеры и маленькие фирмы теоретически способны создавать достойные продукты. Но подавляющее большинство продуктов всё ещё слишком сложно и менее успешно, чем они могли бы быть. Это потому, что команды специалистов упорно внедряют у себя процесс разработки, который я называю Разработка, Направленная на Создание Сложности (РНСС).

Работает он так:

• Менеджеры верно находят интересные и важные проблемы с реальным экономическим эффектом от их решения. На этом этапе они уже на шаг впереди компаний, практикующих РНСМ из предыдущего параграфа.
• Команда разработчиков с энтузиазмом начинает строить прототип системы, а затем базовую функциональность основного продукта. Всё идёт по плану, работа спорится, вещи делаются логичными и элегантными.
• К этому времени менеджмент приходит с ещё более интересными и важными проблемами. Да, их труднее решить (кое-что вообще придётся переделывать), но ведь если мы это сделаем, то будем ещё на два шага впереди конкурентов, ведь так?
• Разработчики делают то, что должны делать разработчики — разрабатывают. Разрабатывают, разрабатывают, разрабатывают и ещё раз разрабатывают. Менеджеры приходят со своими интересными и важными задачами снова и снова. И разработчики разрабатывают снова и снова. Чтобы получить в итоге идеальную, солидную, массивную, ОГРОМНУЮ СЛОЖНОСТЬ.
• Продукт выходит на рынок, рынок чешет репу и спрашивает «Что, вот это всё правда надо было делать так сложно?». Люди начинают кое-как пользоваться продуктом, тратя своё время и деньги чтобы разобраться в его невообразимой сложности, но что делать, если альтернатив нет?
• Менеджмент получает позитивные отзывы от крупнейших заказчиков — их менеджмент верит, что если уж всё так сложно и так много времени надо потратить на обучение и использование — значит это точно хороший продукт (?!).

РНСС характеризуется командами людей, остервенело и фанатично решающими частные задачи, не нужные 99% пользователей. РНСС-продукты получаются громоздкими, амбициозными, сложными и непопулярными. Множество опенсорс-продуктов появилось на свет в стремлении получить простое решение там, где было только сложное. Для некоторых инженеров невероятно трудно остановиться в стремлении расширить функционал продукта «на случай если вдруг кому-то ещё понадобиться вот это». Они хотят сделать людям добро, не задумываясь, нужно ли оно им и существуют ли вообще эти люди где-нибудь в мире.

Хороший пример РНСС — Блютус. Это сложный, надуманный набор протоколов, который пользователи ненавидят. Он продолжает существовать благодаря массивному пакету патентов, которые просто невозможно не нарушить, создавая альтернативу. Блютус идеально безопасен, что близко к бессмысленности для протокола столь малого радиуса действия. В то же время он страдает от недостатка стандартного API для разработчиков, вынуждая каждого изобретать ни с чем не совместимый велосипед в своём приложении.

На IRC-канале #zeromq Wintre однажды написал как он был разъярён, когда много лет назад обнаружил, что аудиоплеер XMMS 2 обладает хорошей системой плагинов, но не умеет играть музыку.

РНСС — это болото, плавающие в котором разработчики и архитекторы варятся в собственном соку, придумывают сами себе проблемы и сами же их героически решают, нисколько не заботясь о том, насколько это всё вообще востребовано за границами их воображаемого мира.

Главные выводы из РНСС, опять-таки легко сделать, но трудно принять:

• Создавать продукт, который вам не нужен прямо сейчас — бессмысленно. Не важно насколько вы умны и талантливы, если вы делаете никому не нужную чушь, о которой никто не просил.
• Проблемы бывают разного масштаба. Некоторые из них просты, другие — нет. Странно, но часто решение именно простых, пустячных проблем — как раз то, что нужно людям. С другой стороны разработчикам не интересно работать над банальностями и пустяками, им подавай Вызов, Проблему. Если пустить разработку на самотёк — разработчики будут работать над точно интересными им, но не факт что полезными пользователям задачами.
• Инженеры и архитекторы любят всякие там Архитектуры, Паттерны, здесь что-то обобщить, а тут оптимизировать, а там выпендриться хаком — и всё это неумолимо ведёт к росту сложности. Критически важно иметь рычаг воздействие на такие вещи. Это может быть, например, жесткий дедлайн, заставляющий разработчика сделать маленькое, простое решение, работающее «здесь и сейчас», вместо гениального и общего, которое не будет закончено никогда.

Разработка, Направленная на Создание Простоты

И наконец, мы добрались до редкого, но тем более ценного способа работы — Разработка, Направленная на Создание Простоты, или РНСП. Начинается она с простой вещи: нужно осознать, что мы не знаем, что хотим построить, до того, как начнём это делать. Начинать с Гениальных Идей и планов по гибкому масштабированию на тысячи серверов не только бессмысленно, это скорее даже является прямой помехой аккуратной базовой архитектуре. Настоящие проблемы в действительности скрыты в тумане и единственный способ развеять его — начать двигаться, исследовать, как вы исследуете скрытую кару в компьютерной игре. На первом этапе вам надо быть быстрыми, мобильными, одним словом двигаться — и пока не так уж важно куда. Только разведав некоторую площадь, станет понятно куда идти дальше.

РНСП работает так:

• Мы собираем множество интересных проблем в какой-то сфере и располагаем их по возрастанию — от простых к сложным, пытаясь найти какие-то общие паттерны.
• Мы берём и решаем простейшую, элементарную проблему, причём делаем это минимально затратным способом — «патчем». Каждый патч решает ровно одну проблему, и ровно одним, минимально затратным способом.
• Мы вводим одну-единственную метрику качества патча: «Может ли это быть сделано ещё проще, всё ещё решая данную проблему?». Сложность можно измерять в количестве информации, которую пользователю придётся узнать (или угадать) чтобы воспользоваться патчем. Чем меньше, тем лучше. Идеальный патч решает проблему, не требуя от пользователя совершенно никаких знаний и умений.
• Наш процесс разработки начинается с патча, который решает проблему «нам нужен proof of concept» и развивается в мощный продукт, состоящий из сотен или тысяч патчей, дополняющих и исправляющих друг друга.
• Мы не делаем ничего, что не является патчем. Мы строим правила процесса разработки таким образом, чтобы каждая задача решалась одним патчем, решающим эту и только эту, осознанную и описанную проблему.
• Мы строим «цепочку поставок» задач, в которую пользователи добавляют свои проблемы, а разработчики — решают их. Эта цепочка обладает хорошим «стоп механизмом», не дающим разработчикам улететь на крыльях своей фантазии в заоблачные дали — а попробуй это сделать, когда есть конкретный живой человек, ждущий быстрого решения проблемы.
• Разработчики вправе работать над любыми проектами и предоставлять патчи к любому компоненту. Никто не владеет проектом единолично — есть «главный» репозиторий со своими формальными критериями приёма патчей, но если они кому-то не нравятся — любой может сделать свой форк. Один и тот же проект может иметь соревнующиеся форки, побуждая каждый из них развиваться лучше.
• Проект предоставляет некоторый набор документированных интерфейсов, позволяя другим компонентам (клиентам, плагинам) их использовать. Создание хорошего API — способ получить много продуктов-спутников, сформировать экосистему и завоевать рынок.
• Мы выводим цепочку поставок задач внешним пользователям и клиентам и обеспечиваем цикл частых релизов, так что пользовательская проблема может поступить к нам извне, быть проанализирована, оценена и исправлена патчем всего за несколько часов.
• В каждый момент времени начиная с первых патчей наш продукт готов к поставке. Это важно, поскольку значительная часть патчей (10-30%) будут неверными и только давая доступ к продукту пользователям мы можем понять что пошло не так и нуждается в исправлении.

РНСП — надёжный способ поиска оптимальных решений наиболее значимых проблем в неизвестной предметной области. Вам не надо быть гением, чтобы применять РНСП, вам нужно всего-лишь видеть разницу между бесцельным блужданием в тумане и деятельностью по развеиванию этого тумана, в результате которой проступают очертания действительно важных проблем.

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

Как только вы улавливаете всю мощь данного подхода, силу коллективной мысли и прекрасную бесконечность улучшения своего продукта, вы также осознаёте почему некоторые компании и продукты застревают в болоте провальных перспектив. У них просто нет разнообразия мышления, подходов, коллективного интеллекта и фантазии для правильной разведки неизвестных предметных областей и рынков. Когда Nokia убила свои открытые проекты — она сама себе перерезала глотку.

Хороший архитектор с хорошей командой может использовать РНСП для построения продуктов мирового класса. Чтобы получить максимальную выгоду — РНСП должен использоваться постоянно, изо дня в день, вырабатывая у разработчика нюх на проблемы нелогичности. Мы часто упускаем из виду всякие мелкие неувязки, но хороший архитектор видит их и способен воспринимать их как шанс сделать продукт лучше. Суть данного вида построения ПО в безостановочном (пусть и не большом, но постоянном) приближении к идеалу в использовании продукта.

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