Журнал «Компьютерра» № 29 от 15 августа 2006 года

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

Нарисованная картинка может показаться слишком циничной; тем не менее никакая крупная корпорация просто не сможет выжить, не обеспечив маломальскую заменяемость (а значит — стандартизацию) своих работников. Да, ограничение средств выражения мыслей несколько снижает эффективность процесса — зато повышает его предсказуемость. Крупная корпорация не может полагаться на внезапные озарения, ее плоть — каждодневный, часто рутинный, труд. (Это всё банальности, но необходимые.)

Идеальное (по крайней мере, с точки зрения Корпорации) решение задачи «однообразных работников» зовется Платформа. Платформа — набор решений, охватывающих все области деятельности Корпорации; Платформа — контролируемый набор взаимоинтегрируемых инструментов; Платформа — Единый Набор Кнопок с Самого Верха до Самого Низа.

Будь то Платформа Java, Платформа .Net, Платформа 1С, Axapta, Oracle — цель и смысл один.

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

Другое дело, что «прогресс» такого рода многие и за прогресс-то не считают. Достаточно вспомнить последнюю (в смысле — самую свежую) крупную и громкую платформу, сделанную с нуля, — Microsoft .Net, которую задолго до, во время и еще долго после выхода в свет (да и до сих пор) окружали недоуменные статьи на тему «что-же-здесь-нового-и-зачем-об-этом-так-кричать» [Одну из наиболее характерных статей такого рода, к тому же неплохо написанную и сносно переведенную на русский, можно найти у Джоэля Спольски:russian.joelonsoftware.com/articles/MicrosoftGoesBonkers.html]. Действительно, ни один из компонентов .Net, будучи рассмотрен сам по себе, не был чем-то «новым и особенным»; инновацией была целеустремленность и последовательность, с которой Microsoft охватил весь процесс разработки ПО — для любых условий, на любом языке, с интеграцией (и дифференциацией) всего и вся. Набор не самых передовых технологий, объединенных не самым изящным образом, за несколько прошедших лет изменил индустрию весьма существенно — и кто скажет, что это не прогресс, тот прогресса не видел.

Что это мы такое накреативили?

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

Пользователю (заказчику, потребителю результата) по-прежнему предлагается либо довериться репутации производителя («фирма веников не вяжет уже сорок лет»), либо опробовать его перед покупкой/оплатой — и при «опробовании» приходится ориентироваться в основном на собственный опыт, интуицию, вкус и тому подобные неформализуемые способности. В любом случае, предполагается, что корректность произведенного уже обеспечена производителем (внутри его головы или его фирмы) и является полностью его болью и заботой.

У самого производителя сегодня не намного больше средств обеспечения этой корректности, чем 10-20-30 лет назад, — автоматически проверить что можно (например, орфографию), тестировать автоматически или вручную [Разницу между проверкой и тестированием можно сформулировать так: проверка напрямую сверяет результат с «правильным» (что возможно далеко не всегда), а тестирование рассматривает его как «черный ящик»: на вход подали А — на выходе должно получиться Б] и опять же — полагаться на свой опыт-вкус-интуицию. Прогресс в стане производителей идет в основном не технологический, а методологический: скажем, все в той же разработке ПО — от когдатошнего максимально-формального процесса (определяем требования до начала работы, пишем кучу документации до начала кодирования, ни на йоту не отклоняемся от плана) — к сегодняшним гибким (agile) методологиям (требования могут меняться в процессе разработки, вся функциональность охвачена тестами, код, спецификации, требования непрерывно перерабатываются).