Питер Уэйнер

Бизнес-руководителям нравится идея средств разработки, которые требуют минимального объема написания кода (Low-Code) или даже совсем не требуют (No-Code). Меньше кода, значит — меньше работы, проекты реализуются быстрее за меньшие бюджеты, а в конечном счете топ-менеджеры быстрее получают премии. Кому такое не понравится?

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

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

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

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

Перечислим девять причин, по которым программисты недовольны инструментами, призванными экономить их время.

1. Проблемы сопровождения и развития

Самая сложная часть работы с решением категории Low-Code обычно ждет вас через несколько лет после внедрения созданной в нем системы. Она прекрасно работает, но постепенно накапливаются запросы на исправления и усовершенствования. Нередко эти доработки выходят за пределы возможностей системы с минимумом кодирования, в связи с чем выполнить их непросто. Если бы в вашем распоряжении был исходный код, его можно было бы частично переписать, но его нет. И если бы разработчики знали, что в дальнейшем понадобится такая-то возможность, они бы, вероятно, изначально приняли другие решения, например воспользовались бы совершенно иным фреймворком. Но этого не произошло и теперь вы — в тупике.

2. Все получают одно и то же

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

Так и системы, созданные при помощи одного и того же инструментария Low-Code, выглядят сделанными «под копирку». Имея минимальный опыт, разработчик может беглым взглядом определить, какой именно инструмент использовался для разработки системы — движок «проглядывает» сквозь нее независимо от настроек, заставок и CSS-«обложек». Часть пользователей это устраивает, если для них лучше, чтобы интерфейс выглядел привычным, но другим нужен элемент новизны.

3. Универсальных инструментов не бывает

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

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

4. Иногда написать код проще, чем выполнить настройку

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

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

5. Полет вслепую

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

Если решения на базе Low-Code ведут себя, как ожидалось, проблем с этим нет. Но часто бывает так, что при минимальных неполадках работа застревает, так как нет возможности уточнить, что происходит внутри «черного ящика» — вы словно ведете самолет без приборов, летя наудачу.

6. Нельзя добавлять функции корректировки данных

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

В системах Low-Code для подобных задач могут быть предусмотрены фильтры или переключатели, и обычно этого достаточно. Но когда нет, вам не повезло. Для поставщиков малокодовых сред это тоже непростая ситуация. Некоторые из них экспериментировали с возможностью добавления произвольных фрагментов кода, но это чревато дырами безопасности, если кто-то находит способы злоупотребления. К примеру, из Drupal убрали возможность включения фрагментов кода PHP, чтобы закрыть потенциальную брешь безопасности и улучшить производительность кэширования.

7. Cистемы Low-Code, как правило, неэффективны

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

Допустим, ваша компания хранит все данные только в CSV-файлах. Но разработчики среды Low-Code должны все предусмотреть и также обеспечить поддержку JSON, YAML, XML версий 1.0 и 1.1 и т. д. Существует масса всевозможных форматов данных, и отдел маркетинга поставщика среды Low-Code будет настаивать на том, чтобы она поддерживала все из них — ведь нужно как можно больше галочек в таблице функциональности.

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

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

8. Нужны специальные навыки

Многие платформы с открытым кодом разработаны на популярных языках программирования, широко преподаваемых в университетах. Есть немало специалистов, которые способны разобраться в коде стеков, реализованных на Java, JavaScript, Python, PHP и т. д.

Но работе с инструментариями Low-Code студентов не учат, поскольку в теории это и не нужно. Конечно, подобные инструменты нередко тоже написаны на распространенных языках, но проблема не совсем в этом, а в сложности структуры фреймворков Low-Code. Вы платите не только за саму систему — в дальнейшем, если ее нужно будет доработать или расширить, членам вашей команды придется потратить дополнительное время на изучение ее устройства.

9. Зависимость

Внедрение платформы Low-Code напоминает попадание в толпу — присоединиться легко, а выбраться непросто. Цена уменьшения объема выполняемой вами работы — зависимость от гигантов, которые подпирают своими плечами ваши системы. Пока гиганты двигаются, вы двигаетесь вместе с ними. А если они останавливаются или падают, вас ждут проблемы.

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

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

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

Слишком маленькая проектная группа

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

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

Слишком большая проектная группа

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

Если программистов слишком много, проект может намертво застрять из-за подобных задержек. Было бы неплохо, если бы можно было содержать «запасных игроков» на проекте, но обычно денег на это нет.

Радикальные изменения функциональности

Теоретически методы agile-разработки должны обеспечивать скорость и гибкость, но иногда они бессильны – все зависит от масштаба перемен, которые понадобятся. Легко работать в «скором» режиме, когда речь идет о переносе кнопки или изменении цвета в пользовательском интерфейсе. Но когда нужно переработать схему, принципы сегментирования или механизм тиражирования базы данных, легкого пути выполнить «поворот» нет.

Неправильный выбор технологии для проекта

Даже если вы все тщательно спланировали и верно составили перечень функций, проект может провалиться, если для реализации выбрана не та технология. К примеру, базы данных разрабатываются максимально универсальными и гибкими, но имеют архитектурные ограничения. Если вы попытаетесь применять СУБД для задач, на которые она не рассчитана, то при росте масштаба производительность может буквально сойти на нет. Или еще пример: вы начнете проект с базой NoSQL, поскольку это «модно» и современно, а впоследствии выяснится, что вам на самом деле нужны транзакции, строго отвечающие принципам ACID, а NoSQL этого обеспечить не может.

Неверная расстановка приоритетов

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

Что в таких ситуациях делать разработчикам? Если они сосредоточатся на самой важной особенности, они не смогут продвигаться вперед и в итоге не закончат вообще ни одной функции. А если начать с самых простых, на выходе можно получить нечто бесполезное.

В процессе планирования нужен не просто контрольный список функций. При разработке архитектуры проекта необходимо принять во внимание возможные трудности и затраты на их преодоление.

Упущенная бизнес-возможность

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

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

Неверные архитектурные решения

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

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

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

Политические конфликты

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

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

Подобные ситуации встречаются чаще в последнее время, когда архитекторы стали делить приложения на многочисленные малые сервисы и наборы API. Когда за разные сервисы отвечают разные группы, они не всегда ладят друг с другом. Если группе А нравится JSON, а группа Б предпочитает XML, то в рамках общего проекта придется либо реализовать поддержку обеих нотаций, либо заставить одну из групп изменить предпочтения. В обоих случаях появятся сложности.

Ставка на «сырую» технологию

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

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

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

Ставка на устаревающую технологию

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

Невыполнимые сроки

Эксперты советуют: рассчитайте, сколько времени уйдет на проект, и умножьте на два. Но что они знают, эти эксперты, не написавшие ни строчки кода?

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

Непредвиденное соперничество

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

Склонность торопить события

Многие проекты ПО начинаются с чьего-то замысла по улучшению того или иного существующего сервиса. Инициатор объявляет, что задумал клон Snapchat или Uber для определенных задач, и ждет, что проект будет развиваться так же стремительно, как Snapchat или Uber. Но проблема в том, что оценка масштаба работ, проектирование потоков данных и разработка концепции пользовательского интерфейса зачастую занимают на порядок больше времени, чем написание кода. Однако мечтатели желают перейти от идеи сразу к программированию. (Почему? Может быть, виноваты создатели новых фреймворков, баз данных или «бессерверных» платформ, обещающие, что с их помощью вы сможете создать законченное приложение, написав всего несколько строчек кода.)

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

Ложные представления о могуществе программного обеспечения

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

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

– Peter Wayner. 14 reasons why software projects fail. CIO. June 18, 2018

Биткойн с самого начала казался чем-то непонятным, мистическим и почти что противозаконным. Происхождение этой технологии и ее создатель по сей день остаются неизвестными. Добавьте сюда скандал с торговой площадкой Silk Road, где анонимные пользователи скупали за биткойны наркотики. В конечном итоге ее владелец был приговорен к пожизненному тюремному заключению. Неудивительно, что биткойн изначально рассматривался многими как средство финансирования теневого мира. Математические расчеты, применяемые для генерации биткойнов, настолько сложны, что в голову сразу начинают лезть самые мрачные мысли.

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

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

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

Блокчейн – настоящая ценность биткойна

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

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

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

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

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

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

Блокчейн выходит за рамки криптовалют

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

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

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

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

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

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

Договоры

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

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

Работа с произвольными текстовыми документами – только начало. Уже созданы депозитные контракты, предусматривающие окончательную передачу денег при выполнении определенных условий. Такие контракты могут использоваться при сложных групповых сделках – например, при реализации краудсорсинговых проектов Indiegogo или Kickstarter. Положенные на депозит деньги разблокируются лишь в том случае, если в ходе реализации проекта будут выполнены заранее оговоренные пороговые условия.

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

Цифровые коллекции

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

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

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

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

Голосование

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

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

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

Транспортные накладные

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

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

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

Фиксация прогнозов

У каждого всегда имеется своя точка зрения на то, кто выиграет в Лиге чемпионов, но распространяться об этом готовы, как правило, только авторы сбывшихся прогнозов. Блокчейн – идеальный способ зафиксировать прогноз, после чего отказаться от него уже не получится.

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

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

Микротранзакции

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

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

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

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

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

Премиальные баллы

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

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

– Peter Wayner. Beyond bitcoin: 7 ways to capitalize on blockchains. InfoWorld