Твой белый хлеб

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

Определение команды не ограничивается группой специалистов за компьютерами в одной-двух комнатах. Разные члены команды могут работать на разных материках, одно физическое лицо может участвовать в нескольких проектах одновременно (и входить, таким образом, в несколько команд). По слухам — не проверенным сообщениям в форумах — существуют команды, объединяющие более шестисот программистов в одном проекте. Однако не все, кто входит в команду, обязательно программисты. Специалист, отвечающий за пособия для пользователя, может не иметь доступа к исходному коду, но он — неотъемлемая часть команды. С одной стороны, его устами команда говорит с клиентом — есть ли что-то важнее в этом мире? С другой — существуют ресурсы, которые совместно используются автором пособий и остальной командой. Например, компьютеры для демонстрации: разработчики обеспечивают наличие на них сегодняшней версии продукта, из нее автором нарезаются картинки для пособий.

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

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

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

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

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

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

Общность составляющих успеха — вот что (среди других причин) делает участников нынешних соревнований высокооплачиваемыми профессионалами. Еженедельные тренировки — это не только потерянное время и невыпитое пиво. Это твой завтрашний белый хлеб, по возможности — с икрой и маслом. Приятного аппетита!

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