Заметки о российском программировании

Дмитрий Волков
"Открытые системы"
vlk@osp.msk.su

Анатолий Гавердовский
АО "Весть", Москва
AnatolyG@vest.msk.ru

Игорь Косякин
АО "Новый Атлант", Москва
kip@novy-atlant.msk.ru

В пятом номере журнала "Открытые системы" за 1996 год была помещена статья "Заметки об американском программировании", вызвавшая немало откликов и породившая волну публикаций в компьютерной прессе об особенностях организации труда программистов в разных странах. Интересно в этой связи проанализировать некоторые аспекты современного состояния и перспективы российского программирования. Эту тему целесообразно рассмотреть с нескольких точек зрения: дисциплина; организация работы; интеллектуалы/исполнители; инструментальные средства.

Появляющиеся в прессе объявления о найме программистов, как правило, требуют от кандидатов знания SQL, С++, Power Builder и т. п., что говорит о стереотипном представлении о программисте, исключительно как о носителе инструмента - как об его продолжении. Если ты знаешь требуемый инструмент - ты программист, если нет, извини. Ясно, что это не главное. Программист - это набор психофизиологических характеристик, куда входят: способность решать проблему, не теряться в сложных ситуациях, способность обучаться, а самое важное - быть дисциплинированным. Дисциплина как раз и есть то главное, чего сегодня недостает российским программистам.

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

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

Если отбросить вопрос о дисциплине, то очевидно, что способность решать проблемы у россиян традиционно существенно выше - нет боязни трудностей, чего не скажешь о западных специалистах, привыкших к заштампованным решениям. А от заштампованности не спасет даже активный рекруитмент на весьма льготных условиях в университетской среде, где мысль более раскованна. Беда всех этих искусственных решений в том, что они разбиваются о воспитание. Когда проблемы накапливаются, и их в конце концов приходится форсированно преодолевать, то скорее всего продукт получится плохим. Иногда доходит до смешного: руководитель проекта заявляет, что "у нас нет больше ресурсов и до начала летних отпусков мы не сможем провести недельный заключительный этап тестирования, поэтому отложим выход продукта на полгода". Неважно, что были затрачены колоссальные усилия на создание кода, предварительную отладку, разработку проекта - из-за пустячной, с точки зрения российского программиста, проблемы задерживается выход продукта. Бывают, конечно, исключения, но в основном западные решения - это штампы, хотя и выполненные на высоком технико-оформительском уровне. У нас - прорубание стены для решения проблемы, у них - поиск маркетинговых ходов, объясняющих, почему они не решили задачу. Возможно, именно поэтому маркетинг как сфера деятельности получил такое развитие на Западе.

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

На Западе: руководитель дает секретарю соответствующим образом оформленный документ, который ставится на учетный номер; с него делается необходимое количество копий, оригинал с пометкой количества копий вкладывается в файлер. У каждого сотрудника имеются "ящики" In, Out, Work и Other. Секретарь помещает документ в In. Ничто не нарушает тишины в комнате, кроме щелчков клавиатур, шелеста распускающихся листьев тополя за окном и попискивания компьютера после очередного зависания Windows 95.

А вот Восток. Входит руководитель. "Господа программисты, минутку внимания. На 14.00 назначено совещание на 15 минут..." Далее следуют вопросы "зачем", "что брать с собой", "все или не все идут"; предложения - "давайте сейчас (завтра, вечером, в бане, в пивной)"; воспоминания - "а вот позавчера (год назад) на совещании..."; крики души - "а потише можно, я же по телефону разговариваю"; просьба руководителя передать информацию отсутствующим.

Нетрудно догадаться, в каком случае будет больше ошибок в программе, сколько человек не придет на совещание, сколько, придя, спросят - "что мы здесь делаем". Кроме того, сможет ли секретарь по просьбе директора назвать без посторонней помощи тему совещания, которое состоится (или состоялось на прошлой неделе) в подразделении? При нормальной организации труда, чтобы передать кому-либо документ, требуется лишь положить его в ящик с меткой Out на своем столе или, если хочешь пофлиртовать с секретаршей, - в box с меткой In на ее столе. А чтобы спросить у соседа по комнате об его "куске" программы - надо послать сообщение по внутренней почте или выйти в комнату отдыха и обсудить там.

Опыт показывает, что под неусыпным оком менеджера российские программисты легко привыкают к такой "тихой" технологии.

Теперь о качестве проекта. Это прежде всего тестирование. Независимая служба тестирования по западным нормам - это один кодировщик на два тестера. У нас же наоборот. У них нормой считается передать тестеру код, прошедший стадию компиляции без ошибок, у нас в руки тестеру попадает система, которая уже дышит - работает. Курирует проект администратор - в его компетенцию входит только координация работы, план, отчетность, конфигурация продукта или сборка. Лидер проекта, или, точнее, "кошачий пастух" - делает детальную разработку расписания, буквально по часам. Четкие обязанности членов команды. Исключены неопределенности типа: "а я так понял, а я так слышал, мне так сказали". Сроки: обсудили, пришли к консенсусу - все, подвели баланс, зафиксировали даты - это уже закон, независимо от того, какие новые идеи могут появиться у разработчика в процессе реализации. Тем самым может быть упущена реализация интересных решений, но надо отдавать себе отчет в том, что любые отклонения от сроков - это дополнительный риск. Проектные сроки незыблемы.

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

Как на Западе относятся к идеям сотрудников? Очень серьезно. В чем это выражается? Если ты выдвинул некую идею, руководитель назначает совещание - конечно не на сегодня, как это часто делается в России. Инициатор идеи знает, что все будет серьезно, тщательно готовится. Если предложение примут (что еще совсем не означает его реализацию), то руководитель еще долгое время на всех совещаниях будет упоминать в связи с этим твое имя, что очень приятно и вдохновляет на новые свершения.

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

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

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

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

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

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

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

Оставим в стороне такие объективные проблемы, как разница во времени, языковой ба-рьер и пр., и рассмотрим вопрос управления процессом. Вначале трудно было понять, почему они так управляют (а может быть, и не управляют вовсе), пока, после очередного жаркого обсуждения, один из высших менеджеров американской компании не посоветовал почитать книги Эдварда Йордона (Edward Yourdon) "Decline and Fall of the American Programmer", "Rise and Resurrection of the American Programmer" и "Death Match". Буквально на следующий день прояснились некоторые аспекты сотрудничества между российской компанией и нашим американским партнером.

Йордон приводит очень интересную классификацию компаний, занимающихся разработкой программного обеспечения. Эта классификация базируется на модели SEI (Software Engineering Institute), согласно которой все фирмы разбиваются на 5 уровней.

∙ Initial Level. На этом уровне царит полная анархия при разработке программного обеспечения - никто ни за что не отвечает. Могут существовать стандарты, могут быть написаны тонны инструкций, но все равно им никто не следует. Разработчик - бог, он может принять решение и начать кодировать в соответствии со своим видением задачи, никого не поставив об этом в известность. Разработчик объявляет сроки менеджменту и не отвечает за их выполнение. Это не означает, что они все сошли с ума, просто в этом случае ситуация будет абсолютно непредсказуемой. Проект вполне может закончиться раньше объявленного срока, равно и позже. Правда, практика показывает, что все подобные проекты заканчиваются не просто позже, а значительно позже объявленного срока. У компании могут быть все процедуры, и она их будет соблюдать в обычное время, но при малейшем кризисе процедуры отброшены. Под кризисом можно понимать появление неожиданного заказчика, требование за несколько дней подготовить демонстрацию и т. д.

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

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

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

Optimized Level. Это вершина, которая по плечу компаниям, способным применять полученную информацию для улучшения качества процесса разработки.

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

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

Вопрос. Сколько разработчиков сейчас работает над проектом?

Ответ. Точно сказать не могу, их количество постоянно меняется.

Вопрос. Какова производительность каждого разработчика в функциях или линиях кода?

Ответ. Извините, не могу сказать точно. Разве важно, сколько, почему и зачем, если мы продали 17 млн. копий продукта. Кого волнует бюджет продукта!

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

В России бытует мнение, что "программирование - это искусство", возникшее на заре отечественной компьютеризации, когда в стране отсутствовала информация о новых технологиях, все приходилось открывать заново - например документацию по языку АЛГОЛ переписывали в свое время от руки. Корректнее считать программирование высококвалифицированным ремеслом, который на порядок ниже, скажем, чем процесс проектирования истребителя. По уровню затрат разработка Су-27 в десятки раз выше, чем ОС NT. А всякого рода попытки фетишизации программирования часто исходят из неумения или нежелания нормальным образом организовать работу над проектом. Тем не менее уровень производственной культуры и образования российских программистов настолько отличается от остального мира, что мы просто обречены быть высокотехнологичной нацией. Другое дело, сможем ли реализовать этот потенциал?

к оглавлению

Знаете ли Вы, что диаграмма классов, Class diagram - это методология объектно-ориентированного проектирования, предназначенная для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.

НОВОСТИ ФОРУМА

Рыцари теории эфира