Самый мягкий
АрхивКто не верит, что наш софт - "самый мягкий", пусть обратится через редакцию "Компьютерры" в любую российскую программистскую компанию. Там вам покажут россыпи самородков - золотой фонд России, ее интеллектуальный капитал.
Кто не верит, что наш софт - "самый мягкий", пусть обратится через редакцию "Компьютерры" в любую российскую программистскую компанию. Там вам покажут россыпи самородков - золотой фонд России, ее интеллектуальный капитал.
Сергей Королев, в прошлом программист и руководитель проекта, затем генеральный директор АО "Агама", вице-президент московского офиса "ПараГраф", ныне - и. о. генерального директора фирмы "Русское Слово".
По образованию они могут быть химиками, металлургами, физиками и даже математиками, но все они зовутся Программистами, и роднит их общая страсть - властолюбие. Но власть над компьютером, которую они получили благодаря дару программирования, позволяет им победить своим разумом не только мертвое железо, но и себе подобных Homo Programmiens, и в соревновании этом есть объективные показатели, которые легко измерить и сравнить. Конечно, трудно объективно соревноваться в написании, например, операционных систем: до сих пор непонятно, почему же Windows победила OS/2, - вроде бы последняя не хуже сделана была. Но, пожалуй, тут не программисты IBM виноваты. А вот если сузить задачу, вычленить самую суть, чтобы только программистское мастерство видно было - вот тут-то с нашими тягаться никто не сможет.
В подтверждение приведу рассказ известного в прежние времена журналиста Николая Семенова. Началась история на заре перестройки, когда тогдашнее "прозападное" правительство страны во время одного из вояжей захватило молодых предпринимателей перенимать опыт капиталистического управления. Среди них был руководитель успешного многопрофильного кооператива (Платов, если кто помнит те времена и имена), который на всех фуршетах пил исключительно водку, а на скучных демонстрациях организации управления производством, посмеиваясь, говорил, что его ребята безо всяких этих менеджеров, планов, графиков и отчетов и почище вещи сделать могут, особенно в интеллектуальной области.
Времена тогда были "дооконные", размеры программ, особенно резидентных, байтами измерялись, и в качестве полезной утилиты членам делегации подарили удивительно малого размера драйвер управления дисководом, который при записи запаковывал, а при чтении восстанавливал файлы с невиданным по тем временам коэффициентом сжатия. Все его расхваливали, а Платов поклялся, что в следующий приезд вернет этот подарок с сюрпризом.
Следующая поездка долго не случалась, "прозападное" правительство ушло в отставку, а новое, напротив, не учиться, а учить других желало. Платов, воспользовавшись случаем, вызвался на очередной выставке показать достижения русской мысли. Отряхнув пыль с подарка, он всучил его Леве, своему ведущему программисту, дав "техническое задание": сделать то, не знаю что, но чтобы все отпали.
Нашим хакерам к таким заданиям было не привыкать. Они не могли сказать, когда и что будет готово, - да Платов и не спрашивал: ребята его никогда не подводили. Взял Лева двоих помощников, прошлись они пару раз по подарку дизассемблером и после нескольких бессонных ночей в дымном полуподвале вспомнили несколько недокументированных особенностей DOS, на самом низком уровне команд процессора, используя нестандартным образом любой бит каждого регистра, вставили несколько затычек и привезли не успевшего проспаться Леву с дискетой в последний момент прямо к трапу самолета с правительственной делегацией.
"Возвращение" подарка было обставлено с большой помпой. Прародители утилиты, правда, долго не могли понять, что же в ней изменилось (интерфейс-то тот же самый остался), но когда Лева записал фидошную конференцию в несколько сотен мегабайт на одну дискету, их удивлению не было предела. Оказалось к тому же, что программа размером на два байта меньше стала. Более того, при замене оригинальных процедур на новые удалось сэкономить несколько байт, в которых теперь гордо красовались имена хакеров.
- И твое имя тут есть? - спросили Леву.
- Никак нет, - отвечает Лева, - моего одного и нет. Мой модуль настолько маленький, что на нем мое имя не поместится. Зато я его сделал одной левой, и он самое популярное в Фидо слово из трех букв всего в один бит кодирует, за счет этого и такая фантастическая компрессия выходит!
В общем, триумф был небывалый. Вот только потом, при тестировании, выяснилось, что с англоязычными (особенно литературными) текстами коэффициент сжатия не такой уж фантастический, а бинарные файлы новая утилита не только не сжимает, а даже и увеличивает. Так что новых заказов, на которые Платов рассчитывал, получить не удалось.
Тем не менее, мастерство Левы оценили и пригласили на стажировку в известную компанию. На одной вечеринке авторы исходной программы поинтересовались, где он теорию кодирования изучал.
Лева им отвечает:
- Наша наука простая: в курилке поболтаешь, а что не найдешь - по Фидо спросить можно.
Они говорят:
- Это жалко, лучше бы вы теорему Ш-К почитали, которая теоретический предел кодирования устанавливает. Тогда вы могли бы сообразить, что наша утилита всего на 1% до этого предела не дотягивает, а при уменьшении ее размера хоть на один байт ближе 5% к пределу не подойти.
Лева спорить не стал, хотя и не поверил. А в скорости стажировка закончилась, Лева по пути на родину пытался на спор перепить одного англичанина, что кончилось плохо для обоих. Но англичанина вылечили, а Лева с тех пор из-за постоянных запоев стал профнепригоден. Когда он входит в запой, то вспоминает самый большой секрет, который со стажировки вез, и умоляет собутыльников:
- Скажите Платову, что буржуины программы, прежде чем тиражировать, у программистов отбирают и тестировщикам отдают: пусть и у нас тестировать станут, а то, храни Бог, в них блохи заведутся!
Но собутыльники считали, что это Леве блохи да чертики от белой горячки видятся, и Платову ничего не говорили. На этом деле фирма Платова и погорела, когда сработанная в ней программа вдруг в отчете для налоговой инспекции всю "черную" бухгалтерию солидного банка распечатала.
Прошу прощения за адаптацию рассказа Николая Семеновича Лескова к нынешним временам, но ведь как мало с тех пор переменилось! Перечитал (а по правде говоря, впервые прочитал серьезно и полно, а не в цитатах да детских пересказах) "Левшу" я после одной планерки, на которой Жора Пачиков, чрезвычайно высоко ценящий коллектив "ПараГрафа" (по крайней мере, наполовину состоящий из высококласснейших специалистов), сорвался: "Да что ж вы, ребята, каждый из вас Левша, а блоха опять не прыгает!"
А в рождественские дни ОРТ экранизацию "Левши" запустило, выполненную в виде фарса, где даются рецепты отношения ко всяким подобным соревнованиям.
Первый рецепт: то, что непонятно, нужно утрировать и высмеять. Любую здравую мысль легко довести до абсурда. Обсмеять же, обратив в форму анекдота, русский народ умеет мастерски. Представьте, как легко можно потешаться над немецкой педантичностью, китайской тщательностью или американским правилом выполнять, не задумываясь, заученные действия в стандартных ситуациях. Конечно, для любого алгоритма поведения можно найти исключение, в котором преимущество на стороне совершающего нетрадиционные поступки. Но беда, если непредсказуемость поведения и решений выдается за спасительное главное достоинство.
Второй рецепт: играть по собственным правилам, отбрасывая трудновыполнимые условия как несущественные и заменяя их задачами, которые противник и не ставил никогда (например, за ненадобностью). Кто сказал, что блоха прыгать должна? Разве вы не знаете, что мастерство - в том, чтобы к ней самую маленькую деталь прикрутить! А ваш модем на 56K разве на наших линиях работает? Да он только после нашей подкрутки сможет сигнал "занято" распознать! А ваша бухгалтерия может генерировать отчеты для начальства, налоговой инспекции и братвы так, как главному бухгалтеру нужно? А ваша программа с таким количеством функций, что средний пользователь даже десятую часть их никогда не узнает, разве сможет запуститься на типичном компьютере пятилетней давности наших бюджетных заказчиков? То-то же, а мы - могем!
Второй рецепт часто применяется и по отношению к потребителю программы или ее заказчику, причем часто непреднамеренно. Просто так уж устроена жизнь, что приоритеты у пользователя и программиста разные. Во-первых, программисту иногда очень хочется украсить свое творение такой "подковкой", которую никто другой повторить не сможет. Ее иногда можно эффектно продемонстрировать, придумав специальную ситуацию, когда без нее обойтись невозможно, - но пользователь, скорее всего, в эту ситуацию никогда не попадет. Во-вторых, программист тоже ведь является пользователем своей программы, но только очень профессиональным. А у профессионального пользователя свои приемы, большие потребности, а простые средства ему кажутся убогими и никому не нужными. Так и получаются программы, которые вроде направлены на массовый рынок, но увешаны профессиональными наворотами. Еще одно следствие профессионализма программиста - это интерфейс, рассчитанный не на новичка, а на опытного пользователя.
Профессионализм программиста, конечно, нельзя ставить ему в вину. Это, как часто бывает, оборотная сторона достоинства. Точно так же, недостатком оборачивается и желание программиста сделать свою часть работы как можно лучше. А значит - переделать все заново, когда выяснится, что это можно сделать элегантнее или более эффективно, или когда "подковка" не встает и нужно "всю ножку из другого материала сделать". В результате работа над любым модулем может продолжаться - с его улучшением, конечно, - бесконечно. И здесь уже наблюдается несовпадение приоритетов программиста и компании, поскольку для фирмы в целом, как правило, важнее выпустить продукт как можно быстрее, нежели повысить эффективность одной из функций на десяток процентов или пополнить список из ста возможностей еще одной.
Даже когда усовершенствования наконец останавливают и программу отдают тестировщикам, программист продолжает работу - скажем, для следующей версии продукта, и тут к нему возвращается старый модуль, чтобы он исправил небольшую ошибку. Как тут не вставить еще одну "выкованную подковку"? Правда, это требует повторного тестирования всего модуля (вместо сокращенного тестирования только исправленной ошибки), порой - изменений в документации, иногда и модификации других, смежных модулей. Опять задержка выхода продукта, снова конфликт интересов программиста и компании.
Оборотная сторона еще одного достоинства - умения делать все лучше других - заключается в том, что очень малая часть готовых разработок устраивает нашего героя. Это относится и к работе его коллег (которую даже не всегда можно использовать повторно, потому что на документирование исходных текстов и написание сопроводительной документации обычно времени не хватает: лучше за это время код заново переписать, с улучшениями), и к разработанным третьими фирмами библиотекам (в них всегда чего-нибудь не хватает, того, что кажется совершенно необходимым), и даже к своим собственным старым разработкам (за прошедшее время стало ясно, что все было сделано неэффективно). В результате случается так, что очередная версия программы не несет в себе ни одной строчки кода предыдущей версии (это не преувеличение, а реальный случай широко известного массово продаваемого продукта).
Ничего удивительного в том, что у медали две стороны, нет. Я намеренно подчеркивал оборотные стороны, поскольку лицевые видны хорошо и останавливаться на их преимуществах нет необходимости. Вот только встает вопрос, как это соотносится с темой номера? Где же российская специфика этих "слонов"? Мне кажется, ответ заключается во втором персонаже Лескова - менеджере Платове. Это очень российский тип менеджера. И вообще отношение его с ремесленниками очень российское. В нем нет ни следа планирования работы, контроля, нет такой важной функции менеджера, как посредничество между заказчиком и исполнителем.
Слово "заказчик" употребляется здесь в широком смысле: например, для массового продукта им может быть не конечный потребитель, а отдел маркетинга, который выражает (в идеале) пожелания усредненного потребителя. Очевидно, этот усредненный потребитель далеко не так хорошо разбирается в предметной области, он по определению более тупой, и это свойство естественным образом проецируется программистом на маркетолога. Поэтому последний не имеет никакого авторитета, программисту легко доказать своим коллегам, что для блага потребителя маркетологу лучше забыть про свои глупые желания и побыстрее научиться всему, что опытный программист заложил в свой продукт. В отсутствие менеджера, демпфирующего противоречия между желаниями разработчиков и требованиями маркетинга, у последнего нет никаких шансов влиять на развитие продукта, и поэтому часто он вымирает в российских компаниях как класс. Место умершего занимает отдел продаж, чью деятельность по продвижению уже готового продукта - без всякой обратной связи, без возможности влиять на развитие продукта - называют у нас маркетингом.
Менеджерам вымирание не грозит хотя бы потому, что руководитель фирмы, за редким исключением, просто физически не может поддерживать общение со всеми программистами. Поэтому из их числа выбирается лидер - Левша, который и выполняет функции менеджера нижнего уровня, то есть, как представитель исполнителя, общается с заказчиком (ежели такой имеется) и (или) с руководителем компании и доносит до всей команды их пожелания. Однако ему не до того, чтобы тратить время на исполнение менеджерских функций, ему нужно самому по клавишам стучать и продукт развивать. Порой таким лидером группы в маленькой компании все управление и ограничивается. Если же фирма побольше, то роль менеджера может сыграть руководитель или его заместитель. Тут-то и получается вариант Платова. Платов дает задание "сделать что-нибудь этакое, чтобы знали наших", ставит сроки "к моему отъезду", в остальном полностью полагаясь на Левшу, которому, конечно, верит, но готов, в случае чего, и голову ему снять. А в мелкие скучные детали Платов и не лезет, он без Левши изделие и показать-то, чаще всего, не может.
Тем не менее, менеджер в программистской среде воспринимается как неизбежное зло, а не как необходимый и полезный коллега. Частично это объясняется уровнем развития отрасли: большинство программистских фирм выросло из "творческих коллективов" и не достигло стадии большого конвейерного производства. А атрибуты этого производства (между прочим, и американские) очень напоминают разные "ящики" и другие социалистические конторы, что вызывает автоматическое неприятие демократа-программиста. Ведь, несмотря на "общинность" русского уклада и характера в целом, творческие личности у нас гораздо большие индивидуалисты, чем на Западе. Они болезненнее переносят вмешательство в творческий процесс (по их мнению - диктат, цензуру) и хуже работают в коллективе, зато больше ценят возможность самовыражения. Их труд должен быть авторским. Неспроста ведь на каждой подковке блохи у Лескова имена умельцев были выгравированы. Это у них там никого не удивляет, что именем Нортона назван пакет программ, созданный программистом John Socha, - это естественно так же, как и то, что Форд не стоял за конвейером. А у нас имя Веселова навсегда связано с "Лексиконом", антивирусы сплошь именные (Лозинского, Касперского), и вообще, одна из проблем отрасли - это то, что авторы считают созданный ими код своей собственностью. Следствие - некоторые известные скандалы, связанные с уходом части команды из одной фирмы в другую, а также не дошедшие до скандалов, но довольно распространенные случаи существования очень похожих по функциональности и даже интерфейсу программ, сделанных в разных фирмах одной и той же командой. По той же причине исходные тексты не документируются должным образом (сам я и так разберусь, а другие - в случае чего - пусть помучаются).
Есть профессии, где без команды даже творческое дело сделать невозможно. Например, артисты легко подчиняются диктату режиссера, без дирижера невозможен оркестр, без редактора можно выпускать разве что стенгазету, а не периодическое издание. Профессиональный артист может сыграть любую роль так, как нужно режиссеру. Точно так же профессиональным программистом должен называться специалист, который зарабатывает на хлеб созданием такого кода для компьютеров, который требуется фирме, точнее, ее заказчику или отделу маркетинга. Любого кода, а не только того, на котором он набил руку или который ему нравится по каким-то другим причинам. Однажды я переключил высококлассного программиста с создания ключевых для предыдущего продукта модулей на более рутинную работу, необходимую в тот момент фирме. Он ответил, что, конечно, он справится и с самой тривиальной задачей, но только если ему зарплату повысить. Это подход не профессионала, а любителя, который то, что любит, готов делать бесплатно. В этом смысле российское программирование - не профессиональное, а любительское.
Необходимость в менеджере, напротив, возникает на профессиональном уровне. Его основная задача - руководство конкретным проектом. Успешным можно считать проект, если поставленная задача решена в срок и в рамках выделенного бюджета. Задача менеджера - разбить общий проект на части, распределить эти части между исполнителями, следить за ходом выполнения отдельных задач и координировать их. Менеджер может не знать, как решается та или иная задача, но его обязанность - определить степень готовности этой задачи и в случае задержки предпринять необходимые действия по исправлению ситуации. У хорошего руководителя проекта разработка программы - процесс предсказуемый и управляемый, в противоположность творческому процессу любительского программирования, когда быстро создается основной скелет программы и начинает действовать закон "95х95": 95% всего времени проект находится в стадии 95-процентной готовности, поскольку осталось только "чуть-чуть вот здесь доделать".
Менеджерская работа - скучная, нетворческая, и талантливые программисты, даже назначенные менеджерами, ее избегают. Несмотря на то что она более высоко оплачивается, "карьеристов", старающихся перейти с программистской должности на менеджерскую, в России немного. Про систему образования, которая бы готовила таких специалистов, и говорить не приходится. В результате, по мнению многих руководителей компьютерных компаний, профессия менеджера проекта является одной из самых дефицитных в отрасли. Отсутствие таких специалистов не позволяет перейти от любительского к профессиональному программированию. В России много высококлассных программистов. В России есть компании, выпускающие продукты профессионального уровня.
Но в России нет фирмы, которая бы специализировалась на профессиональном программировании. Профессиональном в том упомянутом выше смысле, когда программирование - это написание кода в соответствии с точно определенным заданием. Кто бы ни поставил задание и интересное оно или нет - не важно, - профессиональная команда готова ее выполнить. Почему разным компаниям, в том числе и компьютерным, выгодно сформулировать задание и разместить его на стороне - это отдельный вопрос, но такое явление, называющееся аутсорсингом (в области программного обеспечения по-русски это обычно называют контрактным программированием), широко распространено в мире. Для Индии, говорят, выполнение подобных работ является существенной частью валового национального продукта. Есть небольшие фирмы, выполняющие контрактные работы, и в России. Но компании, которая бы на этом специализировалась, причем не в одной узкой области (когда, как правило, один или несколько клиентов являются постоянными пожизненными партнерами небольшого коллектива программистов), а берущейся за любой заказ, - такой компании нет. Например, кому-то потребовалось написать конверторы, преобразующие файлы известных документированных форматов в новый, только что разработанный, или заполнить базу данных известной структуры, спроектировав заодно несколько форм ввода-вывода, или организовать сбор данных с нескольких датчиков и заполнить ими определенные формы через Интернет. Найдутся ли в России программисты, способные выполнить подобные задачи? - Найдутся тысячи. А в какую компанию для этого нужно обратиться? - В индийскую. Печально...
Несколько месяцев назад, решив сменить место работы, я обратил внимание на эту нишу на российском рынке. Для ее заполнения нужно было организовать фирму, которая бы обладала двумя достоинствами, выделяющими ее среди других программистских компаний: командой опытных руководителей проектов и отлаженным технологическим процессом профессионального программирования. Третье необходимое достоинство - высококлассные программисты. Почему я их не перечислил, надеюсь, понятно из статьи: я не сомневаюсь в их необходимости, я не вижу их недостатка, и я призываю их переходить из любительской в профессиональную категорию.