ch5.adoc

Дизайн, разработка, инновации

«Размер и разнообразие сообщества является ключевым фактором.»

Давайте рассмотрим инновации, которые Википедия определяет как «развитие новых ценностей посредством решений, которые отвечают новым требованиям, не явным потребностям или потребностям старых клиентов или рынков в новых способах добавления стоимости». На самом деле это значит решать проблемы более дешевым способом. Звучит просто, но истории рухнувших технологических гигантов говорят об обратном. Я постараюсь объяснить, почему команды часто понимают это не правильно, и предложу способ, как нужно создавать что-то инновационное.

История двух мостов

Два старых инженера разговаривали о жизни и хвастались своими выдающимися проектами. Один из инженеров рассказал, как он разработал один из величайших когда-либо созданных мостов.

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

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

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

Как ZeroMQ потерял свою дорожную карту

Когда я представлял ZeroMQ на конференции Mix-IT в Лионе (Франция) в начале 2012 г., меня несколько раз спросили про «дорожную карту». Мой ответ был: нет больше дорожной карты. У нас они были, и мы их ликвидировали. Вместо нескольких экспертов, пытающихся определить следующие шаги, мы позволили событиям развиваться естественным путем. Аудитории не очень понравился мой ответ. Слишком не по-французски.

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

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

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

В итоге мы столкнулись с травматическими изменениями в ZeroMQ, от которых дорожные карты нас не уберегли, несмотря на кучу сил и слов, потраченных на то, чтобы «делать все правильно». Результатом этого стали несовместимые изменения в API и протоколах. Было ясно, что нам нужен новый подход, определяющий процесс внесения изменений. Разработчикам программного обеспечения не нравится идея о том, что мощные, эффективные решения могут появляться без того, чтобы умные разработчики их тщательно выверяли и обдумывали. И все же тогда в Лионе никто не поставил бы под вопрос эволюцию. Это странно и иронично, поэтому далее я еще поразмышляю об этом явлении, ведь на его основе сообщество ZeroMQ развивается с начала 2012 года.

В главенствующей теории инноваций говорится о том, что гениальные индивидуумы, обдумав проблемную ситуацию, выдают точное и аккуратное решение. Иногда у них случаются озарения в стиле «эврика!» — и решение готово. Изобретатель и сам процесс изобретения редкие, драгоценные, единоличные. История знает многих таких героев-одиночек. Мы обязаны им нашим современным миром.

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

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

Поэтому, вот альтернативная теория инноваций:

1. Есть безграничная область проблем/решений.

2. Область меняется с течением времени в зависимости от внешних обстоятельств.

3. Мы можем точно воспринимать только те проблемы, которые нам близки.

4. Мы можем оценить прибыльность/затратность проблемы, используя рынок решений.

5. Есть оптимальное решение для любой решаемой проблемы.

6. Мы можем достичь этого оптимального решения эвристическим и механическим путем.

7. Наш интеллект может ускорить этот процесс, но не заменить его.

Из этого следует:

• Индивидуальная креативность менее важна, чем процесс. Более умные люди могут работать быстрее, но при этом двигаться в неверном направлении. А коллективное видение реальности помогает нам следовать актуальным путем и не обманывать ни себя, ни других.

• Нам не нужны дорожные карты, если у нас хорошо налажен процесс. Со временем, по мере того, как решения будут конкурировать за долю рынка, функциональность будет расти.

• Мы не столько изобретаем решения, сколько находим их. Мои соболезнования творческим натурам: творчество является лишь обрабатывающим информацию големом, начищающим до блеска свое собственное эго и озабоченным поднятием кармы.

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

• Размер и разнообразие сообщества является ключевым фактором. Более крупные и разнообразные сообщества охватывают больше релевантных задач, решают их более точно и делают это быстрее маленькой группы экспертов.

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

Можем ли мы применить вышеописанную теорию на практике? В конце 2011 г. я начал документировать C4 и похожие контракты и использовать их в ZeroMQ и в проектах с закрытом кодом. Лежащий в основе процесс я называю «Ориентированной на простоту разработкой» («Simplicity Oriented Design», SOD). Это воспроизводимый способ разработки простых и элегантных продуктов. Он организует людей в гибкие цепочки поставщиков решений, которые могут быстро и дешево сориентироваться в проблемной области. Они делают это, создавая, тестируя и сохраняя минимальные приемлемые решения, называемые «патчами», или отказываясь от них. Жизнеспособные продукты состоят из длинной череды патчей, применяемых один поверх другого.

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

Чтобы лучше понять то, как мы пришли к SOD, давайте рассмотрим альтернативы.

Trash-Oriented Design

Наиболее популярным типом разработки в крупных организациях является «Мусоро-ориентированная разработка», или сокращенно TOD («Trash-Oriented Design», TOD). TOD основывается на убеждении, что для того, чтобы делать деньги нам нужны крутые идеи. Это упорно всплывающая чушь является мощным костылем для тех, кто лишен воображения. Теория гласит так: идеи редки, поэтому весь фокус в том, чтобы схватить их. Словно далекие от музыки люди восторгаются гитаристом, не понимая, что великие таланты настолько дешевы, что они буквально играют на улицах за копейки.

Основным выхлопом TOD является дорогостоящее «мышление»: концепции, инженерная документация и продукция, которая отправляется прямиком в мусорное ведро. Получается это так: приходят Творческие Люди с длинным списком «мы можем сделать X и Y». Я видел бесконечно детализированные списки всех тех удивительных вещей, которые мог бы делать продукт. Мы все были повинны в этом. Как только свершилась творческая работа по генерации идей, то дело лишь за исполнением их.

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

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

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

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

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

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

А в это время еще один менеджер-визионер где-то там в организации наливает себе точно лишний стаканчик текилы и рассказывает сотрудникам отдела маркетинга о своей Гениальной Идее.

TOD мог бы быть карикатурой, если бы не был так распространен. Около девятнадцати из двадцати продуктов, готовых к выпуску на рынок большими компаниями, ждет провал (да, 87% статистики делается на месте). Из двадцати лишь один возможно преуспеет, да и то благодаря агрессивной рекламе и слабости конкурентов.

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

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

Теперь, сразив дракона абсолютной бесполезности, атакуем демона сложности.

Complexity-Oriented Design

По настоящему хорошие команды разработчиков и маленькие компании могут обычно заниматься созданием приличных продуктов. Но большая часть продуктов все равно получится слишком сложными и менее успешными, чем могли бы быть. Это все потому, что команды специалистов, даже лучшие из них, часто упрямо практикуют «Ориентированную на сложность разработку» («Complexity-Oriented Design», COD), как я ее называю. И работает она так:

• Менеджмент правильно идентифицирует некоторые интересные и сложные проблемы, привлекательные с экономической точки зрения. Вот тут-то они как раз и попадают на колею TOD.

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

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

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

• Рынок при знакомстве с продуктом, чешет за ухом и спрашивает: «Что, серьезно, и это лучшее решение, которые вы нашли?». Да, люди используют продукцию, если при этом им не придётся тратить свои собственные деньги за подъем на гору мануалов.

• Менеджмент получает позитивные отклики от своих крупных клиентов, которые разделяют мнение о том, что чем выше стоимость (обучения и использования), тем выше ценность, и продолжает толкать процесс.

• В это время где-то в мире маленькая команда занимается решением такой же проблемы, используя лучший подход, и через год разносит сложившееся положение на рынке на мелкие осколки.

Для COD характерны команды, которые одержимы решением неправильных проблем и которые подвержены коллективной мании.

Продукты COD обычно крупные, амбициозные, сложные и непопулярные. Многое из программного обеспечения open source является следствием COD. Для разработчиков безумно сложно остановиться и прекратить расширять проект с целью охватить еще и еще потенциальных проблем. Они спорят: «А что, если кто-то захочет сделать Х?», но они никогда не спрашивают себя: «Сколько на самом деле стоит сделать Х?».

Хорошим примером COD на практике оказался Bluetooth, сложный, с излишне-усложненной конструкцией комплект протоколов, которые пользователи ненавидят. Он продолжает существовать только потому, что в сплошь запатентованной отрасли нет реальных альтернатив. Bluetooth прекрасно защищен, что почти бесполезно для бесконтактного протокола. В то же время ему не достает стандартного API для разработчиков, что значит, его реально накладно использовать в приложениях. На канале групповых дискуссий #zeromq участник Wintre однажды написал, как он был взбешен, обнаружив, что в XMMS 2 была рабочая plugin система, но он не мог проигрывать музыку.

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

Основные уроки COD просты, но горьки на вкус:

• Делать что-то, в чем нет необходимости сейчас — бессмысленно. Не важно, насколько вы талантливы или гениальны — если вы занимаетесь тем, что делаете никому не нужные вещи, вы теряете время.

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

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

Simplicity Oriented Design

Наконец, мы подошли к редкой и ценной Ориентированной на простоту разработке (Simplicity Oriented Design, SOD). Этот процесс начинается с реализации: мы не знаем, что мы должны сделать, пока не начнем делать что-то. Выдвижение идей или крупных проектов не просто бесполезно, а мешает разрабатывать по-настоящему точные решения. Действительно лакомые задачи спрятаны, как заветные оазисы, и любая деятельность, кроме разыскивания их, лишь больше окутывает их туманом. Вам нужно быть мобильным, двигаться быстро и налегке.

SOD работает следующим образом:

• Мы составляем список интересных проблем (наблюдая за тем, как люди используют технологию или другие продукты) и располагаем их от простых к сложным, рассматривая и определяя способы использования.

• Мы берем самую простую, самую драматичную проблему и ищем для нее минимальное количество приемлемых решений, или «патчей». Каждый патч решает именно исходную и всеми одобренную проблему наиболее оптимальным способом.

• При оценке патчей мы руководствуемся следующим вопросом: «Можем ли мы найти более простое решение проблемы?». Мы можем измерить сложность количеством концепций и моделей, с которыми пользователю придется ознакомиться или перебирать наугад для использования патча. Чем меньше, тем лучше. Идеальный патч решает проблему, не требуя ничего от пользователя.

• Развитие нашего продукта заключается в создании патча, который решает проблему «доказательства концепции» и который потом встраивается в единую линию более зрелых продуктов, состоящих из сотен тысяч патчей один поверх другого.

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

• Мы выстраиваем наши проекты как цепочку поставщиков решений, где каждый проект может обеспечить задачи своим «поставщикам» и получить в ответ патчи. Цепочка поставщиков является «стоп-краном», потому что когда люди нетерпеливо ждут ответа, нам волей неволей приходится работать в узких временных рамках.

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

• Проекты экспортируют формальные и задокументированные интерфейсы, поэтому проекты-исходники (клиентские) находятся в неведении о проделываемой работе. При этом они могут соревноваться за внимание проектов-клиентов, создавая бесплатный и конкурентный рынок.

• Мы привязываем нашу цепочку поставок к реальным пользователям и внешним клиентам, и мы ведем весь процесс быстрыми циклами с тем, чтобы проблема, полученная от пользователей со стороны могла быть проанализирована, оценена и решена патчем за несколько часов.

• В каждый момент, начиная с первого патча, наш продукт готов к выпуску. Это важно, потому что большая часть патчей будет неправильными (10-30%), и только давая продукт пользователям, мы можем узнать, какие из патчей проблемные и требуют доработки.

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

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

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

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

В open source проектах мы делаем эту работу публично. Нет такого момента «а давайте откроем код». Когда так делают, по-моему, это говорит о том, что люди не понимают смысл open source проектов — вовлечь пользователей в ваше исследование и построить сообщество вокруг основной архитектуры.

Эмоциональное выгорание

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

С другой стороны, не все проекты столь удачны и, если вы работаете с open source, то должны понимать риски, связанные с эмоциональным выгоранием участников. Это относится ко всем сообществам, основанным на добровольном участии. В этой главе я объясню что именно вызывает выгорание, как его распознать и предотвратить, и, если это всё-таки произошло, как его преодолеть. Дисклеймер: я не психиатр и эта статья основывается на моём собственном опыте работы в сообществах добровольцев на протяжении 20 лет, включая проекты свободного программного обеспечения и общественные некоммерческие организации, такие как FFII.

Когда мы говорим о добровольном участии, мы подразумеваем работу без прямого или косвенного экономического вознаграждения. Мы жертвуем личной жизнью, профессиональным развитием, свободным временем и здоровьем, чтобы достичь той цели, которую…​ решили достичь. В любом обычном проекте нам нужно какое-то вознаграждение, чтобы продолжать заниматься им изо дня в день, тогда как в большинстве добровольных проектов вознаграждения носят косвенный и, как правило, неденежный характер. Как правило, когда мы далаем что-либо на добровольной основе, нам достаточно лишь услышать в ответ "Эй, это очень круто!". Карма - это мощный мотиватор.

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

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

Когда я сгорал на проектах с открытым исходным кодом, таких как Xitami, я отчетливо помню, что чувствовал. Я просто перестал работать, отказался отвечать на электронные письма и сказал людям забыть об этом. Это заметно. Они отключаются, и все вокруг начинают говорить: "Он ведет себя странно…​ подавлен или устал…​"

Диагноз прост. Много ли кто-то работал над проектом, который никак не окупался? Принесла ли она исключительные жертвы? Он потерял или бросил свою работу или учебу, чтобы сделать проект? Если вы отвечаете "да", то это выгорание.

Есть три простых метода, которые я разработал за эти годы, чтобы снизить риск выгорания в командах, с которыми я работаю:

• //Незаменимых нет.// Работа в одиночку над важным или популярным проектом, концентрация ответственности на одном человеке, который не может устанавливать свои собственные границы - это, вероятно, главный фактор. Это прописная истина в менеджменте: если кто-то в вашей организации незаменим, избавьтесь от него.

• //Нам нужна работа, чтобы платить по счетам.// Это трудно, но, увы, необходимо. Получение денег способом, не связанным с добровольным проектом, значительно облегчает поддержание добровольного проекта.

• //Рассказывать людям о выгорании.// Это должен быть базовый курс в колледжах и университетах, так как работа на общественных началах становится более распространенным способом для молодых людей профессионально экспериментировать.

Когда кто-то работает в одиночку над критическим проектом, //знайте// - они рано или поздно слетят с катушек. На самом деле это довольно предсказуемо: что-то вроде 18-36 месяцев в зависимости от человека и того, с каким экономическим стрессом он сталкивается в своей личной жизни. Я не видел, чтобы кто-нибудь выгорал ни за полгода, ни за последние пять лет в проекте без экономических стимулов.

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

Шаблоны для успеха

Я завершу эту главу серией шаблонов поведения для достижения успеха в разработке программного обеспечения. Они стремятся включить всё, что отделяет успех от славной трагической неудачи. Они были написаны за один день как “религиозно-маниакальные догматы” руководителем и “всё остальное безумное” — коллегой. Для меня они являются наукой. Но относитесь к Ленивым перфекционистам и другим инструментам так, как вы относитесь к обычным инструментам — заточите их, используйте и выбросите, если подвернется что-то получше.

Ленивый перфекционист

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

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

Доброжелательный тиран

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

Доброжелательный тиран делит большие проблемы на мелкие и отдаёт их разным группам, чтобы сосредоточиться. Он разбивает задачи между этими группами, как API или решения “вне протокола”, о чем я расскажу в следующей главе. Доброжелательный тиран строит цепочку, которая начинается с проблем и заканчивается нахождением решения. Он безжалостен в том, как работает эта цепочка, но не говорит людям что и как они должны делать.

Небо и Земля

Идеальная команда состоит из двух частей-сторон: одна для написания кода, другая для обратной связи.

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

Открытая дверь

Точность знаний приходит из разнообразия.

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

Смеющийся клоун

Совершенство исключает участие.

Смеющийся клоун, нередко действует как “удачливый неудачник” и не претендует на компетентность. Вместо этого его выходки и неуклюжие попытки провоцируют других на спасение его от собственной трагедии. Так или иначе, он всегда выявляет правильные пути решения проблемы. Люди настолько заняты, доказывая его неправоту, что не замечают, насколько ценную работу проделывают.

Заботливый генерал

Ничего не планируйте. Разрабатывайте стратегию и тактику, а не ставьте цели.

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

Социальный инженер

Если вы знаете своего врага и знаете себя, вам не нужно бояться и ста сражений. — Сунь-Цзы

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

Преданный садовник

Тот победит, чья армия воодушевлена единым духом во всех своих рядах.— Сунь-Цзы

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

Бродяга

После пересечения реки, вы должны оказаться вдалеке от нее. — Сунь-Цзы

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

Пиратская банда

Код, как и все знания, лучше всего работают как частная неколлективная собственность.

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

Флешмоб

Вода формирует свой курс в зависимости от грунта, по которому протекает.— Сунь-Цзы

Флешмобы объединяются вместе в пространстве и времени по мере необходимости, а затем эти объединения очень быстро исчезают. Физическая близость имеет большое значение для связи с высокой пропускной способностью. Но со временем это создает технические гетто, где Земля отделяется от Неба. Флешмоб старается собрать много “частых пассажиров”.

Канарейка-дозорный

Боль, как правило, не является хорошим знаком.

Канарейка-дозорный измеряет качество организации по его собственному уровню страданий и по наблюдаемому уровню удовлетворения тех, с кем он работает. Он приводит новых участников в организации, чтобы тем могли показать еще сырые “страдания невиновных”. Он может использовать алкоголь, чтобы заставить других рассказать о своих болевых точках. Он спрашивает других и самого себя: “Вы счастливы участвовать в этом процессе, и если нет, то почему?” Когда организация процесса причиняет боль ему или другим, он рассматривает это как проблему, которая должна быть решена. Люди должны наслаждаться своей работой.

Виселица

Никогда не мешай другим совершать ошибки.

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

Историк

Сохранение общих записей может быть утомительным, но это единственный способ избежать сговора.

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

Провокатор

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

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

Мистик

Когда люди спорят или жалуются — просто отправьте им цитату Сунь-Цзы. — Микко Коппанен

Мистик никогда не спорит напрямую. Он знает, что спорить с эмоциональным человеком — только вызывать еще больше эмоций. Вместо этого он уклоняется от дискуссии. Трудно сердиться на китайского генерала, особенно когда он мертв уже 2400 лет. Мистик играет Виселицу, когда люди настаивают на правоте, совершив ошибку.