. Вместе со своими студентами в Массачусетском технологическом институте Кузумано постоянно ведет исследования отрасли разработки программного обеспечения, при этом активно участвуя в ее работе в самых разных уголках мира. В его багаже — создание французской компании Business Objects и руководство одной из ведущих индийских компаний-разработчиков. Участие Кузумано в московской конференции разработчиков программного обеспечения Software Engineering Conference (Russia), где он выступил с докладом и провел семинар по вопросам предпринимательства в области разработки, стало, несомненно, большим событием.
Как эволюционировала индустрия программного обеспечения, и каковы тенденции на ближайшее будущее?
Сорок лет назад программное обеспечение выполняло исключительно служебную функцию, способствуя продаже аппаратных платформ. В самостоятельный бизнес разработка стала превращаться в 70-е годы, может быть, несколько раньше, когда в Соединенных Штатах IBM и некоторые другие компании создали пакеты функций для мэйнфреймов, которые продавались как автономные программные продукты.
Важным шагом к формированию бизнеса программных продуктов стало появление архитектуры «клиент-сервер». Появились мини-компьютеры, затем новый класс вычислительной техники — рабочие станции и ПК. И произошел настоящий взрыв — возникло множество компаний, выпускавших программные продукты. Следующий коренной сдвиг в индустрии программного обеспечения — появление Internet. Продуктовые компании получили возможность освоить совершенно новый бизнес. В это время появилось и много новых разработчиков, создававших программные системы на базе Internet — браузеры, серверы, другие технологические решения. Но одновременно начал складываться и новый сервисный бизнес, нацеленный на то, чтобы помочь заказчикам создавать программные связи между внешними Web-компонентами приложений и базовой функциональностью на мэйнфреймах и других типах компьютерных систем. Таким образом, основные изменения в индустрии разработки шли в параллель с важнейшими технологическими переменами в аппаратной базе и системном программном обеспечении. И, по существу, это был переход от программ как сервиса к программам как продукту, а затем опять к сервису, но более развитому.
Что касается тенденций, предсказывать будущее очень сложно. Но если посмотреть на это с тех же позиций, то есть проанализировать эволюцию платформ, то наиболее важным процессом последнего времени является перевод большого числа компьютерных функций на карманные устройства, развитие мобильных вычислений, возможность предоставления приложений с помощью механизма Web-сервисов. И это снова приводит к появлению множества новых программных продуктов и новых направлений сервисного бизнеса. Продуктовый бизнес в области программного обеспечения сейчас находится в большом кризисе. Есть даже прогнозы, что со временем он полностью исчезнет, однако я с этим не могу согласиться. Думаю, Oracle, SAP, Microsoft и им подобные никуда не денутся. Но тенденция очевидна — объемы продуктового бизнеса неизменно снижаются последние десять-пятнадцать лет.
Ваши исследования последнего времени сфокусированы на различных бизнес-моделях программной индустрии — продуктовой и сервисной. Что Вы порекомендуете выбрать начинающей компании — заняться тиражированием готового продукта или пойти по пути разработки на заказ и предоставлению иных услуг, связанных с программными системами?
Я рекомендую гибридную модель. Разработка программных продуктов по-прежнему не теряет своей значимости. Но если вы будете ориентироваться на то, чтобы для каждого нового заказчика строить полностью настроенную на его потребности систему, то надо иметь в виду, что бизнес такого типа очень трудно расширять и сложно сделать по-настоящему прибыльным. Конкурировать в этом виде бизнеса могут лишь консалтинговые брэнды первой величины, такие как Accenture, McKinsey, индийская Infosys, или те, кто способен обеспечить очень дешевую рабочую силу, как большинство индийских компаний. Возможно, некоторые российские и украинские компании имеют шансы на успех в этом противостоянии благодаря обладающим высокой квалификацией и очень талантливым программистам с относительно низкими зарплатами. Но надо иметь в виду, что ценовая конкуренция будет расти. В Китае, к примеру, хорошая подготовка по компьютерным наукам и очень сильные программисты с зарплатами примерно в пять раз меньшими, чем у индийских разработчиков. Качественная подготовка кадров в области программной инженерии ведется в Пакистане. Так что моя рекомендация для начинающих компаний — иметь некоторую уникальную технологию, на базе которой можно создать продукт, что будет основой их бизнеса, но сам бизнес должен быть ориентирован на предоставление кастомизированной версии этого продукта для различных типов заказчиков. Действуя таким образом, вы сможете достичь определенной масштабируемости бизнеса, но при этом ваш продукт не станет ширпотребом, и вы сможете получить определенную прибыль от сопровождения ваших систем.
У Вас есть опыт руководства индийской компанией. В чем, по Вашему мнению, причины «индийского чуда» в области офшорной разработки?
Я занимался консалтингом в корпорации Motorola, открывшей свой индийский филиал в 1992 году, а последние два года был директором Patni Computer Systems, которая занимает шестое место среди крупнейших индийских компаний-разработчиков программного обеспечения. Если вернуться лет на пятнадцать лет назад, то Индия обладала, на мой взгляд, несколькими важными преимуществами. Во-первых, большое количество хорошо подготовленных специалистов по компьютерным наукам, инженеров с высшим образованием, но при этом недостаток работы на существовавших тогда в Индии предприятиях. Людям нужны были возможности для развития своей карьеры. Во-вторых, знание английского языка. И, наконец, третий фактор — крайне низкий уровень заработной платы. Десять лет назад зарплата индийского программиста составляла десятую или даже пятнадцатую часть зарплаты разработчика в США (правда, сейчас это уже не так, уровень оплаты индийских специалистов растет).
Эти факторы, думаю, не потеряли своего значения и сегодня, но я бы добавил четвертый аспект, который десять-пятнадцать лет назад не был так существенен. Индийские предприниматели начинают понимать, что привлекательность американских компаний для заказчиков во многом основана на процессах обеспечения качества, и готовят свои компании к сертификации на соответствие четвертому и пятому уровням модели зрелости SEI CMMI. При этом для индийских компаний это в большей степени средство маркетинга, чем инструмент для реального усовершенствования процессов разработки и повышения качества. Есть данные, свидетельствующие о том, что разработка в Индии хоть и хорошего качества, но не настолько, как, скажем, в Японии.
Вы заметили, что планируете написать статью об аутсорсинге в России. Чем Вас заинтересовала эта тема, и что Вы можете сказать о потенциале российских разработчиков?
Я сейчас веду колонку в Communications of ACM, и недавно опубликовал серию заметок, сравнивая индустрии программного обеспечения в разных странах мира. Одна из заметок была посвящена Японии. Последнюю заметку я написал об ирландской программной индустрии, которая несколько лет назад стала очень популярной для аутсорсинга, правда, менее популярной, чем Индия, поскольку зарплаты там выше. Ирландия — еще один пример страны, где есть хорошо подготовленные инженерные кадры, не очень много местных компаний, способных предложить им работу, и относительно невысокий уровень оплаты труда (по крайней мере, так было до тех пор, пока они не вошли в Евросоюз). Наблюдая за российской индустрией разработки, я автоматически начинаю проводить сравнение с тем, что видел в других странах — в Индии, в Ирландии, в Китае. У России и Украины, где, как мне кажется, ситуация очень похожа, есть ряд потрясающих характеристик с точки зрения разработки программного обеспечения: глубокий уровень математической подготовки специалистов, опыт создания крупномасштабных, сложных систем как для военных, так и для гражданских целей. Здесь очень глубокие корни для сложных проектов, гораздо мощнее, чем в Индии, где исторически не велика была потребность в решении таких задач.
С другой стороны, в США практически не знают каких-либо российских или украинских продуктовых компаний; чуть больше известно о компаниях, готовых к выполнению аутсорсинговых работ. Я пока не готов оценить масштабы российского программного бизнеса именно как бизнеса. Сколько у вас компаний, кто из них ориентируется на разработку готовых продуктов, кто — на сервис и поддержку, это еще предстоит изучить. Думаю, у России очень большой потенциал, однако проблемой может стать недостаточное знание английского языка, а также отсутствие сертификации по СММI.
Существуют ли различия в принципах ведения бизнеса по разработке программного обеспечения в разных регионах мира?
Соединенные Штаты в этом смысле уникальны, поскольку здесь очень сильна традиция предпринимательства, большие объемы венчурного капитала, индивидуальные вложения в начинающие компании на ранних стадиях становления. Из одного только Массачусетского технологического института с 1945 года вышло около 4 тыс. стартапов, принесших сотни миллиардов долларов прибыли. Если мы посмотрим на Индию, то здесь объем венчурного капитала не так велик, и в начинающие компании денег вкладывается не очень много. Большинство индийских предпринимателей предпочитали уезжать в США и там основывать компании. А в самой Индии создавались, главным образом, сервисные фирмы с низким уровнем капитализации, ориентированные на аутсорсинг.
Китай также за период либерализации экономики приобрел серьезный опыт предпринимательства в области разработки программного обеспечения, но и здесь не много венчурного капитала, и, наоборот, значительная доля государственного капитала во многих компаниях. Так, государственные вложения в создание собственной операционной системы для мобильных устройств на базе Linux, поскольку китайские власти считают стратегически важным уменьшить зависимость от таких производителей, как Microsoft или Nokia. Есть, конечно, и независимые фирмы, но за ними не стоит много денег. Не много венчурного капитала и в Японии, где существует традиция идти работать в большие корпорации, а не создавать свои собственные компании. Поэтому еще раз подчеркну, что в отношении активности частного предпринимательства в области разработки США имеет уникальный опыт. Подобные компании есть и в Европе, к примеру, SAP или Business Objects.
В России, как я могу себе представить, люди тоже не всегда решаются на быструю карьеру. Вопрос в том, что можно сделать для того, чтобы развивать предпринимательство здесь в России.
В своем выступлении на конференции вы отметили, что в Европе (и, надо полагать, в России) к программному обеспечению относятся, скорее как к науке, чем как к бизнесу. Это преимущество или недостаток?
С моей точки зрения это, конечно, недостаток. Некоторые компании выигрывают от того, что способны превратить научное знание в уникальный продукт. За приложениями SAP стоит много специалистов с ученой степенью. Но в общем случае, когда доминирует подход к разработке программ как к научному процессу, это означает, что компания готова тратить неограниченное время в стремлении добиться совершенства, прежде чем программный продукт будет, наконец, выпущен на рынок. Я столкнулся с этим, работая с Business Objects, и это было ужасно — крайне сложно заставить их выпустить что-либо в продажу, потому что всегда находилась масса аргументов, что продукт еще недостаточно хорош. Прошло два-три года, прежде чем удалось выпустить окончательную версию продукта сложнейшей архитектуры, уровень которой наконец удовлетворил разработчиков.
Могу предположить, что российские программистские компании также ориентируются на высокое качество продукта больше, чем на задачи бизнеса. И это может создать определенные проблемы, если вы хотите быстро выводить свои продукты на рынок или быстро строить системы для заказчиков.
Одна из ваших самых известных книг называется Microsoft secrets. Так в чем же состоит главный секрет Microsoft?
Секрет Microsoft, который мы обнаружили десять лет назад, как раз и состоит в балансе между бизнесом и технологией, в хорошем понимании и того, и другого. Билл Гейтс и Пол Аллен поняли, как писать программы для процессоров Intel, почувствовали то, что потом превратилось в архитектуру Wintel. Но с самого начала они знали и о том, как делать деньги. Хорошо известно, что Гейтс сразу поставил перед своими программистами цель зарабатывать деньги на их программных продуктах, делать настоящий бизнес. В Microsoft старались набирать людей именно с такой философией. Для многих компаний в то время кандидату для поступления на работу достаточно было быть хорошим программистом, но только не для Microsoft, где надо было стремиться делать деньги, хорошо получать за свой труд, завоевывать серьезное положение на рынке, а не просто создавать технологии из любви к технологиям. Так была сформирована определенная культура компании, тот стиль программирования, при котором они не пытаются придумывать все с нуля, не стремятся быть первопроходцами, но стараются понять, где появляется потенциал для массового рынка, и бросают туда максимум своих ресурсов. Это стратегия «следования в русле», а не инноваций, и она оказалась успешной.
За последнее десятилетие, я полагаю, Microsoft стала намного больше во всех отношениях. В 1995-м в компании было 7 тыс. сотрудников, а сегодня у них работает 61 тыс. человек. Размер компании, число продуктов, которые в ней создаются, число рынков, которые она осваивает, масштабы систем стали гораздо значительней, и потому всем этим намного сложнее управлять. В команду, работавшую в 1995 году над Windows, входило 450 человек; сегодня это более 7 тыс. человек. Код Windows в 1995-м составлял несколько миллионов строк; сегодня это 60 млн. строк. Но на самом деле я бы не изменил ничего из того, что написал десять лет назад. И сейчас компания в значительной степени руководствуется теми же принципами относительно бизнеса и технологий. Но, как в любой компании, которая стала намного больше и достигла зрелости, все процессы в Microsoft замедлились и усложнились — контакты между группами, создание кода и т.д. Сегодня у них много проблем, скажем, с выпуском Longhorn, и это связано с размерами команды разработчиков, объемом кодовой базы, а также, в определенной степени, с недостатком внимания, которое уделяется архитектуре. Но эта же проблема существовала и десять лет назад. Они работают над этим, но проблемы остаются, задерживается выпуск давно обещанных систем, особенно это касается усовершенствований в Windows. Причина в неэффективности процессов, но это никогда не было сильной стороной Microsoft.
Не возникает ли у Вас сегодня желания посвятить книгу какой-либо другой компании, обладающей, на ваш взгляд, собственным секретом успеха?
Сейчас меня больше интересуют проблемы индустрии в целом, переход от модели бизнеса, ориентированной на разработку готовых продуктов, к ориентации на предоставление сервисов. Поэтому мне особенно интересны те компании, которые определяют этот процесс, которые уже создали большую инсталляционную базу своих продуктов и разрабатывают эффективный сервисный бизнес. С этой точки зрения в центре внимания будут, прежде всего, SAP и Oracle. В SAP предпринимают серьезные усилия по созданию интеграционной платформы вокруг технологии NetWeaver, то есть они пытаются стать в большей степени тем, что мы называем платформенной компанией, обеспечить для других разработчиков удобные средства интеграции их приложений с приложениями SAP. Это и сейчас можно делать, но пока достаточно сложно, а создание платформы позволит упростить этот процесс. А это уже сервисный бизнес. Мне бы хотелось провести несколько встреч с представителями этой компании, но проблема в том, что они не очень открыты для подобных исследований.
Было бы интересно написать и об Oracle, но я не очень люблю Ларри Эллисона, да и книги о нем уже есть. Меня не очень привлекает работа подразделений по созданию приложений, но то, как организует свой бизнес консалтинговая группа Oracle, производит большое впечатление. Они очень агрессивно продают идею процессов, и это серьезная тема для изучения. Oracle вообще очень интересна с точки зрения бизнеса, особенно после приобретения PeopleSoft и Siebel.
Есть также индийские компании, которые движутся по абсолютно нехарактерному для рынка своей страны пути, стремясь закладывать основы продуктового бизнеса, отличного от традиционного сервисного бизнеса, базирующегося на низкой стоимости человеческих ресурсов. Например, Infosys пытается больше ориентировать свой бизнес на разработку продуктов. И это также дает почву для размышлений.
Итеративная разработка существует уже немало лет, ее преимущества, казалось бы, всем очевидны, но в индустрии по-прежнему остается достаточно компаний, которые придерживаются традиционного и малоэффективного «водопадного» метода. Чем это вызвано? Что мешает победоносному шествию итеративной разработки?
На самом деле, даже если компания использует «водопадный» метод, она делает итерации, так как невозможно с первого раза сформулировать требования к системе или написать код именно так, как надо. На каком бы этапе вы ни обнаружили ошибку, вам придется вернуться на несколько шагов назад, чтобы выяснить природу этой ошибки, то есть фактически выполнить итерацию. Дело не в том, что в методе «водопада» нет итераций, а в том, что в этом случае итерации очень трудно производить, они не заложены в процессе. Но и в итеративной разработке существует несколько фундаментальных проблем. Одна из них заключена в отсутствии четких критериев, когда итерации надо остановить. Для того чтобы держать проект под контролем, вывести продукт на рынок или поставить заказчику в заданный срок, компания должна в определенный момент остановить итерации — прекратить изменять требования, стабилизировать дизайн системы, вносить изменения в код и т.д. Это всегда сложно. Для того чтобы построить успешный итеративный процесс, необходима дисциплина как внутри компании, так и со стороны заказчика, который тоже в какой-то момент должен остановиться и перестать формулировать новые требования. Как показывают наши исследования, предпочтителен процесс разработки на базе прототипов, которые позволяют на ранних стадиях продемонстрировать заказчикам, что вы делаете, и получить от них обратную связь, что поможет раньше завершить итерации. Именно поэтому продуктовые компании практикуют демонстрацию прототипов своих систем группам пользователей.
Таким образом, итеративный подход требует большей дисциплины; «водопадный» проект спланировать намного легче, но гораздо труднее получить в итоге хороший продукт. Вторая проблема итеративной разработки состоит в том, что сервисным компаниям, которые придерживаются итеративного подхода, труднее составить контракт. Заказчики хотят получить от аутсорсера определенные гарантии, письменные подтверждения относительно того, что и как они разрабатывают, к какому сроку и т.д. Но компании трудно определить эти обязательства, пока у нее нет документированных требований и детального дизайна системы. В водопадном методе детальные требования существуют до начала работы над проектом. Так что если процесс составления контракта на аутсорсинг разработки программного обеспечения очень заформализован, как, например, в Пентагоне, компании бывают вынуждены прибегать к «водопадному» методу, который упрощает управление этим процессом. Чтобы изменить эту ситуацию, нужно, чтобы заказчики были более гибкими в отношении соглашений с аутсорсерами, чтобы контракты содержали общие, а не детальные требования, общее представление желательных функций и т.д. 80% проектов, следующих «водопадному» методу, не укладываются в бюджет. Но для того чтобы изменить ситуацию, необходимо изменить подход крупных заказчиков к процессу составления контрактов.
Как Вы оцениваете роль моделей зрелости CMM/CMMI в достижении реальной успешности, эффективности работы компании-разработчика?
Есть много свидетельств (в том числе и из моих личных наблюдений), что тот тип практик, которые рекомендует СММ, действительно способен обеспечить улучшение качества разработок, повышение управляемости проекта, а в долгосрочной перспективе, возможно, и способствовать снижению стоимости, поскольку проекты становятся более успешными, повышается эффективность бизнеса в целом. Но и здесь существует ряд проблем. Во-первых, для того чтобы удовлетворить все требования, которые предъявляются при сертификации на четвертый или пятый уровень, понадобится множество бюрократических процедур и большие средства для документирования, сбора данных, формализации процессов и т.д. С одной стороны, это очень полезно, но, с другой, многие проекты по разработке программных продуктов нужно делать быстро, поскольку меняются рыночные условия, растет конкуренция, и их нужно делать дешевле, чему процессная бюрократия не способствует. А если компания небольшая, она вообще не может позволить себе тратить время и деньги на эти проблемы. Для таких компаний сертификация в краткосрочной перспективе выгоды не принесет, а в долгосрочной вообще нельзя гарантировать, что компания не окажется банкротом.
Кроме того, часто компании считают, что для того чтобы обеспечить управление разработкой в соответствии с той структурой, которую определяет SEI CMM, проще определить процессы по «водопадному» методу, то есть задать последовательные этапы проектирования, разработки, тестирования и создавать для них документы, базы данных и процедуры. В результате, к большому сожалению, ряд компаний, получивших сертификацию СММ, на деле оказывались негибкими и неэффективными. Хотя это, конечно, не общее правило. Многие компании считают для себя важным достичь третьего уровня СММ, потому что более высокие уровни требуют большей бюрократизации и жесткой структуры. Но, с другой стороны, выйти на американский рынок практически невозможно, не имея сертификации на пятый уровень, поэтому аутсорсинговые компании испытывают в этом отношении жесткий прессинг.
Какое влияние оказывает на индустрию программного обеспечения движение Open Source?
Пользователи получают от открытого кода большие преимущества; на рынке появляются превосходные технологии, такие как ОС Linux, Web-сервер Apache, СУБД MySQL, сервер приложений JBoss и т.д. Но одновременно движение Open Source создало много сложностей для продуктового бизнеса. Теперь любая компания должна внимательно смотреть, нет ли открытой альтернативы их технологии, поскольку, если такая имеется, существует большая вероятность, что, затратив немалые средства на исследования, разработку и маркетинг своей системы, компания в конце концов окажется банкротом. С другой стороны, для сервисного бизнеса открытый код создает дополнительные возможности. Например, IBM получает большие преимущества от систем с открытым кодом, зарабатывая на интеграции и поддержке. Корпорация делает большие деньги на продажах собственных аппаратных платформ и инфраструктурного программного обеспечения, но при этом поддерживает Linux и Apache и имеет большой штат, который занимается вопросами Open Source.
Но в целом я считаю, что движение Open Source полезно для индустрии, потому что создает альтернативу. Теперь продуктовые компании, чтобы выжить, должны быть более креативными и более эффективными. На самом деле, число по-настоящему широко распространенных продуктов с открытым кодом довольно ограниченно. Есть тысячи подобных программ с очень скромной клиентской базой и множество корпоративных пользователей, которые не используют системы с открытым кодом, поскольку им нужны строгие соглашения, техническая поддержка и гарантии качества кода. Скажем, в Японии открытый код вообще не пользуется популярностью. Так что место для прибыльных продуктовых компаний всегда найдется, но, вполне вероятно, сервисные компании продолжат доминировать, усиливая свои позиции именно благодаря открытому коду.
Вы утверждаете, что не любые технологии — это обязательно шанс для развития бизнеса. В каких технологиях сегодня Вы видите реальные перспективы для индустрии программного обеспечения?
В ближайшем будущем такими технологиями будут программное обеспечение для беспроводных устройств, антиспамерские средства, технологии, связанные с разными аспектами защиты, такими, например, как контроль доступа, индивидуальная идентификация.
Вы преподаете в одном из самых известных в компьютерной отрасли университете. Что Вы порекомендовали бы для организации подготовки кадров в области разработки и управления индустрией программного обеспечения?
В МТИ есть различные курсы по проектированию компьютерных систем, языкам программирования, архитектуре и т.д. Кроме того, программы по менеджменту включают курсы по бизнесу в области разработки, управлению инновациями, предпринимательству, которые дают студентам совсем другой набор знаний и навыков, дополняющих технологическую подготовку. Но одновременно очень важно создавать возможности за рамками формальных классов. Так, в течение почти двух десятилетий мы проводим конкурс по бизнес-планам, победитель которого получает 50 тыс. долл. Кроме того, этот конкурс позволяет венчурным капиталистам оценить возможности участников; как правило, победитель и команды, занявшие второе и третье места, получают финансирование. Так что такие дополнительные возможности иногда оказываются даже важнее, чем обучение по основным программам. Я считаю, что эффективная подготовка специалистов для индустрии разработки должна сочетать в себе все эти три компонента — научные программы, курсы по менеджменту и неформальные инициативы.
