Благосостояние
Я часто сталкиваюсь с тем, что ключевые управленческие и экономические термины используются как мантры. Их произносят с умным видом на встречах, вписывают в корпоративные ценности, но за ними редко стоит системное понимание. Одно из таких понятий — «благосостояние».
Его принято сводить к деньгам. Много денег — высокое благосостояние. Мало денег — низкое. Это примитивно и опасно. Опасно именно для нас, руководителей и тимлидов, потому что мы начинаем управлять командой или продуктом, ориентируясь на единственный, к тому же запаздывающий, индикатор.
На протяжении своей карьеры — будь то управление командами разработки, выстраивание архитектуры сложных сервисов или консалтинг — я убедился: чтобы управлять чем-либо эффективно, необходимо это декомпозировать. Разобрать на составные части, понять связи между ними и только потом собирать обратно работающую систему.
Благосостояние — это система взаимосвязанных элементов, находящихся в постоянном динамическом взаимодействии. И если вы хотите повышать благосостояние своей команды, своего продукта или, в конце концов, себя самого, вам необходимо понять эту систему.
Проблема: Сведение сложного к примитивному - не нравится пример
Почему мы склонные к упрощению? Потому что это легко. Например, зарплата — это конкретная цифра. Ее можно сравнить, ее можно измерить в процентах от прошлого года. Но когда говорят: «Мы повысим твое благосостояние на 15%», подразумевая только деньги, то это не всегда так, а точнее всегда не так.
Игнорируется факт, что человек, может столкнуться с дефицитом времени на семью, с ростом стресса из-за возросших ожиданий или с невозможностью обменять деньги на нужный ему продукт (например, качественное обучение). Общее состояние — то самое благосостояние — может не вырасти, а даже упасть. Корень проблемы — в непонимании структуры.
Четыре элементарных частицы
Давайте заменим расплывчатый термин на рабочую модель. Система благосостояния состоит из четырех фундаментальных, взаимозависимых элементов: Люди, Потребности, Ресурсы, Продукты.
Люди (Агенты системы)
Это мы с вами. Команда. Пользователи. Клиенты. Не абстрактная «целевая аудитория», а конкретные индивиды с ключевыми атрибутами:
- Есть потребности: Вся деятельность человека инициируется необходимостью закрыть ту или иную потребность. Это — мотор системы.
- Обладают ограниченными ресурсами: Главный ограничитель. Время, навыки, знания, физическая сила, внимание. Без ограничений не было бы нужды в экономике и управлении как таковых.
- Создают продукты: Способность к преобразующей деятельности — ключевое свойство. Продукт — это материальный или нематериальный результат приложения ресурсов.
- Способны к обмену: Возможность добровольно обмениваться продуктами с другими людьми — фундамент сложных систем, от рынка до open-source сообщества.
Узнай своих агентов. Недостаточно знать имя и должность. Пойми, какими ресурсами они реально обладают (время часто переоценивают, навыки — недооценивают) и на какие потребности направлена их деятельность.
Потребности (Вектор движения системы)
Потребность — это не только «есть» и «спать». В контексте современной, особенно IT-среды, иерархия потребностей сильно усложнилась.
- Субъективная важность: Потребность существует только если сам человек считает ее важной для закрытия. Бесполезно предлагать сотруднику курсы по управлению, если его ключевая потребность сейчас — профессиональное признание среди коллег.
- Закрывается продуктами: Потребность абстрактна. Закрывается она всегда конкретным продуктом. Потребность в передвижении закрывается продуктом «такси» или «велосипед». Потребность в признании — продуктом «публичная похвала от тимлида» или «значок “работник месяца”».
- Состояние «закрыто»: Конечная цель. Состояние, при котором дисбаланс, вызвавший потребность, устранен.
Прояви потребности команды. Они не всегда озвучиваются прямо. «У меня горят сроки» — это не потребность в деньгах, это потребность в управляемом потоке задач и приоритезации. «Мне скучно» — потребность в сложных вызовах и развитии.
Ресурсы (Топливо системы)
Всё, что ограничено и необходимо для создания продуктов.
- Ограниченность — ключевое свойство: Время, человеческие силы, сырье, вычислительная мощность, фокус. Безграничных ресурсов не существует. Управление — это искусство распределения ограниченных ресурсов для максимизации результата.
- Происхождение: Ресурсы могут быть природными (материалы) и человеческими (время, навыки, интеллект). В digital-сфере второй тип абсолютно доминирует.
- Назначение — создание продуктов: Ресурсы ценны не сами по себе, а своей способностью трансформироваться в продукт, закрывающий потребность.
Оценивай ресурсы трезво. Самая частая ошибка руководителя — нереалистичная оценка ключевого ресурса — времени. 40 часов в неделю — это не 40 часов на продуктивную работу. Это 20-25 часов глубокой работы, остальное — контекст, коммуникация, рутина. Неучтенные ресурсы — главный генератор технического долга и выгорания.
Продукты (Результат работы системы)
Продукт — это артефакт, созданный путем преобразования ресурсов и предназначенный для закрытия потребности.
- Требует ресурсов для создания: Нет продукта без затрат. Код, документация, отчет, организованное собрание, приготовленный ужин — всё это продукты.
- Закрывает потребность: Ценность продукта определяется исключительно его способностью эффективно закрывать конкретную потребность. Продукт без потребности — это мусор.
- Пригоден для обмена: Это свойство позволяет системе масштабироваться. Я создаю продукт «код», который закрывает потребность компании в новом функционале. В обмен я получаю продукт «деньги», который закрывает мою потребность в крыше над головой. Обмен не всегда симметричен и не всегда моментален.
- Эффективность закрытия: Продукт может закрывать потребность хорошо, плохо или частично. «Узнай, удалось ли закрыть потребность» — ключевая точка сбора обратной связи.
Сфокусируйся на итоговом продукте. В управлении проектами мы часто путаем активность с результатом. Проведенное собрание (активность) — это не продукт. Продукт — это «принятое решение и зафиксированный план действий», который закрывает потребность в координации. Смещай фокус с затраченных часов (ресурс) на произведенные артефакты (продукты), закрывающие потребности.
Связи — то, что делает систему живой
Само по себе перечисление элементов бесполезно. Ценность — в понимании связей между ними.
Цикл благосостояния выглядит так:
- Человек испытывает Потребность (например, потребность в профессиональном росте).
- Он оценивает имеющиеся у него Ресурсы (2 часа времени в неделю, базовое знание Python, готовность учиться).
- Он направляет эти ресурсы на создание или приобретение Продукта, который, по его мнению, закроет потребность (записывается на продвинутый курс по Python, покупает книгу, начинает pet-проект).
- Он обменивает свои ресурсы (время, деньги) на право потреблять этот продукт.
- Он потребляет Продукт (проходит курс).
- Он проверяет, закрыта ли Потребность. (Стал ли он чувствовать себя более уверенным разработчиком? Получил ли он новые, востребованные навыки?).
Если потребность закрыта — цикл завершен, уровень благосостояния по этому вектору повысился. Если нет — цикл повторяется с новыми данными. Человек будет искать другой, более эффективный продукт или попытается увеличить ресурсы (найти больше времени).
Где здесь деньги? Деньги — это универсальный посредник в обмене, высоколиквидный ресурс, который упрощает трансакции. Но это всего лишь инструмент. Фетишизация денег как синонима благосостояния — это подмена цели средством.
Изоляция и падение ценности
Представьте своего лучшего backend-разработчика, Алексея. Алексей — гуру в микросервисной архитектуре. За неделю он может написать систему, которая будет стабильно обрабатывать миллионы запросов. Его личный «output» огромен. Теперь представьте, что мы помещаем Алексея в изоляцию.
- Его потребности разнообразны: еда, жилье, медицинская помощь, развлечения, общение.
- Его ресурсы ограничены: 24 часа в сутки и его навык писать код на Go.
- Его продукт — безупречный, высокопроизводительный код.
Вопрос: Сколько из своих потребностей Алексей сможет закрыть своим продуктом в условиях изоляции?
Ответ: Нулевую. Код не накормит, не вылечит зубную боль и не составит компанию для просмотра фильма. Потенциальная ценность кода не реализуется. Личное благосостояние Алексея стремится к нулю, несмотря на его феноменальную производительность.
Проблема не в том, что Алексей не производит ценности. Проблема в том, что у него нет возможности обменять свой продукт на продукты других людей.
Разрыв цепочки обмена. Произведенный продукт не находит своего потребителя, а потребности создателя не находят своего удовлетворения.
Ограниченность ресурсов и его разрушительный эффект
Теперь посмотрим, что происходит, когда в этой отлаженной системе возникает жесткое ограничение ключевого ресурса. Это не абстракция. В управлении проектами мы сталкиваемся с этим ежедневно: лимитированный бюджет, замороженные найм, ограниченная пропускная способность команды.
Ограничение ресурсов действует по принципу домино:
- Первое падение: падение объема производства. Нехватка времени, специалистов, материалов или инструментов напрямую снижает количество и/или качество создаваемых Продуктов. Команда, которая могла бы делать 10 фич в месяц, из-за недоукомплектованности делает только 5.
- Второе падение: сужение возможностей для обмена. Меньше создано продуктов — меньше товаров и услуг предлагается на «рынок» для обмена. Экономика команды, компании или общества беднеет в прямом смысле слова — не в денежном, а в товарном.
- Третье падение: нереализованный потенциал и не закрытые потребности.
- Со стороны производителя: человек или команда, которые могли бы создавать высокоценные продукты и обменивать их на многое, лишены этой возможности. Их потенциал не реализован. Их важные потребности (в признании, в достойном обмене их труда) не закрыты.
- Со стороны потребителя: другие люди лишаются доступа к этим не созданным продуктам. Не написанный код значит не запущенный сервис, который мог бы закрыть потребность тысяч пользователей. Невыращенная пшеница значит не испеченный хлеб.
Возникает порочный круг: ограничение ресурсов → меньше продуктов → меньше возможностей для обмена → не закрытые потребности → падение мотивации (которая тоже ресурс!) → дальнейшее снижение способности создавать продукты.
Практический пример из IT: Представьте талантливого разработчика, тоже Алексея, который вынужден работать на устаревшем железе (ограничение материального ресурса). Его сборка проекта занимает 20 минут вместо 2. Где он тратит свой ресурс? Не на создание ценного продукта (кода), а на борьбу со средой и ожидание. Его личный потенциал не реализуется. Команда получает меньше функциональности. Заказчик — более медленный вывод продукта на рынок. Потребности всех участников цепи закрыты хуже и в меньшем объеме.(подставьте вместе "IT" другую сферу, вместо "Команды" страну - пример универсален)
Ограничение доступа продуктам на рынок
Теперь представим, что в нашу модель благосостояния внедряют правило, которое ограничивает доступ продукта на рынок . Такое правило блокирует или сильно затрудняет связи между элементами модели «Продукты» и «Люди».
- Юридические: лицензии, патенты, сертификаты, запреты.
- Географические: таможенные пошлины, эмбарго, локализация.
- Технические: закрытые API, проприетарные стандарты, искусственные ограничения совместимости.
- Экономические: высокие цены, эксклюзивные дистрибьюторские соглашения, искусственное создание дефицита.
- Продукт не может быть обменян. Его потенциальная ценность не реализуется. Это все равно что иметь мощный сервер, но не подключать его к сети.
- Производитель не получает взамен другие продукты. Труд и ресурсы, затраченные на создание продукта, оказываются потрачены впустую. Это чистые убытки.
- Потребности производителя остаются незакрытыми. Он недополучает медицинские услуги, образование, качественную еду — потому что его продукт не был конвертирован в право на их получение.
- Потребности потенциальных потребителей остаются незакрытыми. Другие люди, которым был нужен этот продукт, не могут его получить. Их система продолжает «болеть».
- Возникают каскадные эффекты. Производитель, не получив обмена, сокращает инвестиции в новые продукты. Потребитель вынужден искать худшие или более дорогие аналоги, переплачивая своими ресурсами.
Ограничение доступа разрывает связи в системе. Количество успешных обменов падает. А поскольку благосостояние — это и есть количество закрытых потребностей через обмен, оно закономерно снижается у всех участников цепи.
Рассмотрим гипотетический (но вполне себе реальный) пример из IT-консалтинга.
Сценарий 1: Открытый доступ.
Ваша команда разрабатывает мощную библиотеку для обработки данных. Вы выкладываете ее в открытый доступ (open-source) с либеральной лицензией.
- Обмен: тысячи разработчиков по всему миру бесплатно используют ее в своих проектах. Ваша валюта обмена — не деньги, а репутация, карьерные возможности, возможность привлечь лучших кандидатов.
- Результат: вас приглашают на высокооплачиваемые конференции как эксперта (обмен репутации на деньги). К вам выстраивается очередь из талантливых разработчиков, желающих с вами работать (обмен репутации на человеческий капитал). Вас нанимают на ключевую роль в крупную компанию с огромным окладом (обмен продукта и репутации на деньги и статус).
- Итог: через цепочку обменов ваш продукт закрыл ваши потребности в деньгах, статусе, профессиональной реализации. Ваше благосостояние резко возросло.
Сценарий 2: Жесткое ограничение.
Вы ту же библиотеку закрываете в проприетарную лицензию, устанавливаете высокую цену и сложную процедуру покупки.
- Обмен: продуктом воспользовались 10 компаний из вашего региона, которые прошли все юридические процедуры.
- Результат: денежный поток есть, но он ограничен. Репутация не распространяется. Новых карьерных возможностей не возникает. Рынок талантов о вас не знает.
- Итог: вы получили краткосрочный денежный обмен, но упустили огромный пласт других возможностей для обмена. Ваше благосостояние (в его полноценном понимании) оказалось ниже, чем в первом сценарии.
Вопрос не в том, что open-source всегда лучше. Вопрос в осознанном выборе. Во втором сценарии мы добровольно установили ограничение на свой продукт и сократили потенциальное количество обменов.
Экономический трафик в одну сторону
В реальном секторе перепроизводство одних товаров при дефиците других ведёт к кризисам. В digital- и IT-среде это происходит менее заметно, но не менее разрушительно.
Рассмотрим на примере. Допустим, есть потребность рынка — «удобное и быстрое получение такси». Первые приложения, которые ее качественно закрыли, получили колоссальную ценность и, следовательно, высокое благосостояние для своих создателей (основатели стали миллиардерами, разработчики — востребованными специалистами с высокими зарплатами).
Что происходит дальше? Успех заметен. Ресурсы (инвестиции, лучшие разработчики, время менеджеров) массово устремляются в эту узкую область. Появляется десять, двадцать, тридцать приложений-клонов, которые предлагают слегка иной интерфейс, скидку на пять рублей или иную модель лояльности. Но базовая потребность-то уже закрыта! Потребность «удобно и быстро поймать машину» решена первыми игроками.
- Падает ценность каждого нового продукта в этой нише. Его способность к обмену резко снижается. Новому приложению придется затратить колоссальные ресурсы на маркетинг, агрессивные цены и т.д., чтобы «выменять» долю рынка. ROI стремительно падает.
- Обесценивается труд создателей. Спрос на разработчиков подскочил, но теперь их труд тратится на создание продуктов с изначально низкой обмениваемостью. Зарплата (основной инструмент их обмена) может временно расти, но устойчивость такой системы под вопросом. Когда пузырь лопнет, их навыки окажутся сфокусированными на низкоценностном сегменте.
- Наступает дефицит в других сферах. Самый критичный удар по благосостоянию. Пока лучшие инженеры и дизайнеры создают двадцатое такси-приложение, их ресурсы (время, талант) не направлены на создание продуктов для других важных, но не закрытых потребностей.
Многие потребности остаются открытыми. А значит, общее благосостояние проседает. Нам нечем обмениваться, чтобы их закрыть. Мы создали «профицит» в одной области и «жестокий дефицит» в десятке других. Мы стоиим в «пробке» из однотипных продуктов, в то время как целые «районы» потребностей остаются без внимания.
Благосостояние: пересматриваем определение
Отбросьте академические учебники. С практической точки зрения, благосостояние — это не количество денег на счету и не абстрактный «уровень жизни». Это конкретная, измеримая величина:
Благосостояние — это возможность обменять продукт своего труда на максимально широкий спектр продуктов, созданных другими людьми, для закрытия своих ключевых потребностей.
Следовательно, ваше личное благосостояние растет, когда вы можете одним и тем же продуктом своего труда (например, месячным объемом разработанного кода) «купить» больше: лучшее жилье, качественную еду, образование для детей, путешествия.
Ценность вашего продукта определяется не его внутренней «крутостью», а тем, сколько чужих продуктов за него готовы отдать.