Давным-давно, году в 1993-м, если не ошибаюсь, к нам обратилась крупная финансово-кредитная структура из Сибири. Банкирам требовалось современное решение, позволявшее реализовать локальную систему безналичных платежей. Это сегодня такая задача выглядит тривиальной. Кругом интернет, сетевая инфраструктура, провайдеры, многократно опробованные технологии... А тогда ничего этого не было. Мы проанализировали ситуацию и поняли, что единственный вариант — делать систему на смарт-картах. А как иначе? Если «умная» инфраструктура отсутствует как класс, значит, носителем «ума», всей бизнес-логики и гарантом безопасности должен выступать «пластик» с чипом.

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

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

Через месяц мне позвонил представитель нашего американского партнера — архитектор системы, и заявил: «Требования, которые были поставлены перед вашими программистами, — не выполнены!».

Звоню своим, пытаюсь прояснить ситуацию.

— Эти американцы просто дураки, — с ходу заявляет мне руководитель группы программистов. — Мы сделали всё гораздо лучше, чем они предлагали!

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

Наши «золотые головы» (без всякой иронии, — действительно золотые!) никак не могли взять в толк: не нужно пытаться сделать «лучше». Надо сделать именно то и так, что и как сказано в проектной документации.

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

Стоит ли объяснять, что и после этого расслабиться не удалось... Через некоторое время я получил еще один звонок от архитектора проекта: «Твои люди не хотят использовать наработки друг друга! Каждый хочет сделать всё сам. И каждый уверяет, что напишет код быстрее, лучше, чем другие».

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

Может быть следовало защищать своих сотрудников от «несправедливых нападок»? Нет. Я отлично понимал: то, что предложили американцы, — современно, интересно и работоспособно. И, что важнее всего, проект решал задачу клиента. К тому же своими силами мы в то время просто не могли построить что-то похожее. Не было видения всей картины, не было опыта. Наконец, было хорошо видно, что профессионалы из США сделали ставку и на безопасность, и на стандарты, и на функционал, предложив по-настоящему глубоко спроектированную систему.

В общем, мы многому тогда научились. В 1996 году наше решение получило почетную награду от международной организации Smart Card Forum. Но в 1997-м я приехал в Америку на одно из крупных ИТ-мероприятий и в очередной раз осознал: всему российскому рынку информационных технологий еще только предстоит научиться проектному мышлению. Потому что практически во всех дискуссиях, затрагивающих тему сотрудничества с ИТ-компаниями из нашей страны, поднимался всё тот же злосчастный вопрос — «неумение русских работать в команде».

В кулуарах я пытался добиться от зарубежных коллег ответа. Ну почему мы — не умеем? Что делаем неправильно? Ответ чаще всего звучал так: «Ну вот ты же в кино ходишь, книги читаешь, и наверняка замечаешь, что один из ключевых элементов американской культуры скрыт в часто употребляемом слове «команда». Посмотри вокруг! Мы не скрываем: в США целенаправленно пропагандируется и культивируется командный принцип работы. И в школе, и в университете, и в бизнесе. Это часть нашей культуры. Нас этому просто учат с самого детства!».

И это действительно так. Обратите внимание, американцы практически ушли из сегмента конвейерного производства — производственным центром, всемирной «фабрикой» стала Азия. Но зато в США сконцентрировано 80% современного софтверного бизнеса, то есть бизнеса, являющегося ключевым в постиндустриальную эпоху.

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

Софтверный бизнес, да и ИТ-бизнес в целом построен именно на командной работе. Но для американцев команда — чуть ли не фундамент национальной экономики.

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

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

И мне в очередной раз стало ясно: всем нам еще работать и работать над собой.

Конечно, за 20 лет развития рынка ИТ в стране многое изменилось. И мы давно уже не те, что в начале 90-х, когда только начиналось (по крайней мере, у нас в компании АйТи) построение систем менеджмента качества, отстраивался механизм управления разработками, шла постановка бизнес-процессов... Но до сих помню, насколько титанические усилия приходилось предпринимать. Это было если и не подвижничество, то уж точно — что-то сродни просветительской деятельности. Каждый разработчик объяснял нам: «Боссы, вы не правы! Не нужно усложнять процесс! Зачем сначала проектировать, описывать, разделять на задачи, тестировать, документировать, зачем использовать разных людей? Я сам разработаю вам новый продукт за неделю!».

И ведь нужно было не заставить людей начать работать иначе, а — убедить! Мы проводили тренинги и семинары. Вывозили сотрудников за город просто для того, чтобы поговорить с ними о том, как важны стандарты и процессы. Что надеяться только на «звезд», на людей, которые «сами всё могут сделать» — неправильно. Хотя бы потому, что эти люди сегодня есть, а завтра их нет. И без них всё перестает работать. А еще хуже, никто не в состоянии разобраться в том, что они сделали (пусть гениально, но — непрозрачно для тех, кому дальше эксплуатировать и развивать созданную систему).

Только теперь, как мне кажется, что-то начало меняться. Таких нечеловеческих усилий по постановке менеджмента, как прежде, предпринимать уже не нужно. Люди сами начали понимать преимущества хорошо организованной структурированной разработки. А главное, приходит новое поколение, которое на мой взгляд куда лучше подготовлено к совместной работе, чем гении-одиночки советской эпохи, в 90-х неожиданно оказавшиеся «в рынке».

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

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

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