Путешествие Йордона в Россию

Выпускник знаменитого Массачусетского технологического института, Йордон начал карьеру программиста в середине 60-х годов и со временем завоевал мировую известность как автор метода структурного системного анализа программ и как участник разработки методологии объектно-ориентированного анализа. Книги Йордона по программированию и управлению проектами разработки стали настольными не для одного поколения тех, кто так или иначе связан с созданием программного обеспечения, и переведены на множество языков, в том числе русский. В 1997 году Йордон был официально объявлен членом Зала компьютерной славы, где компанию ему составляют такие знаменитости, как Чарльз Бэббидж, Сеймур Крей, Грейс Хоппер, Билл Гейтс. А в 1999-м одно из авторитетных американских изданий по разработке программного обеспечения включило Йордона в десятку самых влиятельных людей в этой области.

Йордон, заядлый путешественник, в России побывал впервые. Его выступления перед московской и питерской аудиторией были посвящены темам, которые больше всего интересуют мэтра последние годы. Это управление так называемыми «безнадежными» проектами и технологии Web 2.0. Понятие «безнадежного» (по-английски звучит еще мрачнее — death march, «смертельный марш») проекта представителям индустрии разработки программного обеспечения особенно близко, о чем свидетельствовало и количество поднятых рук на семинаре в Москве в ответ на вопрос Йордона, кому из участников приходилось сталкиваться с такими проектами в своей практике. По Йордону, их основные характеристики — это почти всегда сжатые сроки, очень часто недостаток специалистов, иногда ограниченность бюджета, обязательно большие риски, которые, как правило, не очевидны в начале проекта, практически неизбежные сверхурочные работы и большая вероятность тяжелых последствий в случае неудачи, вплоть до банкротства компании и судебных разбирательств (последнее, правда, справедливо в первую очередь для американского рынка, как признался Йордон). И чем масштабней программный проект, тем больше шансов у него стать «безнадежным». Рецепты Йордона по управлению безнадежными проектами многогранны, но суть их состоит в том, что технологические аспекты разработки не должны быть на первом месте. Гораздо важнее правильно определить «политику» ведения проекта, умение договариваться с различными заинтересованными сторонами о сроках, бюджете и ресурсах, выбор правильной стратегии в отношении набора и мотивации специалистов и т.д.

В популярных сегодня возможностях Web 2.0 Йордон также призывает видеть все, а не только технологические грани. Для Йордона понятие Web 2.0 включает в себя помимо соответствующего программного инструментария бизнес-стратегии, позволяющие использовать блоги и wiki в интересах компаний, и различные социальные и культурные тенденции, связанные с широким распространением феномена Web 2.0. Йордон сам разместил в формате wiki свою книгу по структурному анализу Modern Structured Analysis, тем самым превратив ее из объекта пассивного изучения в объект постоянной модификации и модернизации. То, что перспективы Web 2.0 по-настоящему увлекают мэтра, постоянно ощущалось и во время нашей с ним беседы.

Вы работаете в индустрии программного обеспечения более сорока лет. Какие вы бы выделили наиболее заметные события в истории разработки программного обеспечения?

Самая важная веха в истории разработки — появление Internet и World Wide Web. Именно они сделали программное обеспечение доступным практически каждому. До эпохи Internet доступ к программному обеспечению имели немногие, и для большинства его использование оказывалось очень сложным. А сегодня появилась возможность для отдельных людей создавать свои собственные программы и делать их доступным по Сети. Web 2.0 и социальные сети — наиболее значительные события последних лет, но они не были бы возможны без Internet-революции середины 90-х.

Сейчас вы много занимаетесь вопросами влияния Web 2.0 на бизнес. Что вы думаете о применении этих технологий в процессах разработки?

Команда разработчиков программной системы может использовать блоги, wiki для своих целей. Им крайне необходимы эффективные инструменты для совместной работы, для того чтобы делиться идеями и взаимодействовать друг с другом. В недавнем прошлом единственным таким инструментом взаимодействия фактически была электронная почта. Конечно, и она никуда не делась, но сегодня социальные сети и технологии Web 2.0 способны обеспечить более эффективный и удобный способ коммуникаций. Между прочим, wiki изначально появились в конце 90-х именно для команд разработчиков, и лишь позже завоевали всеобщую известность в качестве средства реализации Wikipedia. Создатель первого wiki-сайта Уорд Каннингем стремился упростить взаимодействие в группах программистов, работающих над одним проектом, дать им возможность быстро вносить изменения в совместно разрабатываемый код.

Вы разместили в формате wiki свою книгу. Что вы ждете от этого проекта, какой внешний вклад в ваш труд был бы для вас наиболее ценен?

До сих пор это были относительно простые улучшения и корректировки. Можно сказать, что пока идет процесс формирования сообщества. Для того чтобы делать более содержательные дополнения, необходимы и время, и энергия участников, а кроме того, определенная интеллектуальная смелость вносить изменения в материал, изначально написанный кем-то другим. На этом сайте я разместил около шестисот страниц информации и понимаю, что многие, в особенности студенты, испытывают некоторую робость менять их. Но я всячески это приветствую, надеясь, что наиболее важными изменениями станет актуализация этих материалов. Эта книга была выпущена довольно давно, в 1989 году, в 2000-м я кое-что изменил в очередной редакции, но и с тех пор прошло уже восемь лет. Так что для меня наиболее важно, чтобы на этом wiki-сайте появились новые материалы, которые сделают мой исходный труд соответствующим сегодняшнему дню. Этот процесс трудно стимулировать, так что пока в основном я сам нахожу в тексте собственные ошибки, делаю улучшения, исправляю диаграммы. Но, надеюсь, со временем мои читатели станут более активными.

Выступая на семинаре в Москве, вы вспоминали те счастливые времена, когда были молоды, программировали в одиночку и совершенно не заботились о том, что происходит вокруг вас. Однако сейчас разработка — как правило, сложный процесс, в который вовлечена большая команда специалистов, подчас распределенная географически. Сегодня это индустрия. Какие возможности открывает и какие проблемы ставит такая ситуация перед индивидуальными разработчиками?

Как программист-одиночка я работал, когда мне был двадцать один год. А в двадцать два я стал участником первого в своей жизни «безнадежного» проекта, и в этот момент я уже был членом команды из пяти-шести разработчиков, которая, в свою очередь, входила в проектный коллектив численностью около ста человек. Действительно, сегодня в многие проекты разработки вовлечено огромное число участников, разбросанных по всему миру. Но по-прежнему мы наблюдаем очень успешные примеры разработки решений командами в два-три человека, например, в области технологий Web 2.0. О некоторых из них я рассказывал на семинаре, например, так появился новый тип блогов — так называемые «микроблоги», где все посетители отвечают на один и тот же вопрос. На микроблоге Twitter у вас поинтересуются, что вы делаете в данный момент, а на микроблоге Dopplr посетителей спрашивают, куда они собираются отправиться в ближайшее время и когда планируют вернуться. Думаю, команда, которая начинала работать над YouTube, тоже включала в себя не более четырех-пяти человек; это уже потом она сильно выросла.

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

Конечно, не всех привлекает возможность работать в такой маленькой группе. Если вы закончили университет с дипломом по компьютерным наукам, то, вероятно, найдете более интересное применение своим знаниям и способностям, работая в крупных компаниях, в больших ИТ-департаментах. Но, по крайней мере в США, при желании вы по-прежнему сможете приложить свои силы и в совсем маленьких проектных командах.

Существует мнение, что престиж профессии программиста сегодня довольно низок. Что вы думаете по этому поводу?

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

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

Может ли ситуация измениться?

Думаю, да. Опять же, некоторые компании, которые специализируются на Web 2.0, демонстрируют, что это не такая уж плохая профессия, и в ней остается немало шансов на успех. Однако наибольший оптимизм, на мой взгляд, вызывают открывающиеся возможности комбинировать традиционную работу по разработке программного обеспечения с другими областями, например, медициной или иными научными дисциплинами. Хотя это может потребовать от студентов изменения образовательной стратегии. Чтобы устроиться на такую перспективную работу, им, возможно, придется получать два диплома, один по компьютерным наукам, другой — скажем, по химии. Но это самый лучший путь вернуть престиж профессии.

А существует ли на самом деле профессия программного инженера?

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

Что вы думаете о подготовке разработчиков в американских университетах?

Самая большая проблема связана с той ситуацией, о которой я уже говорил. Снижение интереса абитуриентов к компьютерным наукам и программной инженерии приводит к тому, что многие университеты сокращают набор на соответствующие специальности. С другой стороны, за последнее десятилетие многие учебные программы были значительно усовершенствованы, так что в целом у меня нет оснований для серьезной критики университетского образования для разработчиков программного обеспечения.

Давайте обратимся к теме безнадежных проектов. Насколько их успех зависит от выбранной методики разработки? Ваше мнение по поводу применения «скорых» (agile) методов?

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

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

Если кратко, в чем состоит кардинальное отличие управления безнадежными проектами от традиционного управления проектами?

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

Выступая перед московской аудиторией, вы заметили, что делать предсказания — неблагодарное занятие. И все же — каковы, на ваш взгляд, основные тенденции в разработке на ближайшую перспективу?

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

Думаю, основная причина, что мы не используем их в достаточной степени, состоит в том, что рынок был не очень требовательным. Наиболее очевидный пример — Microsoft Windows. Эту операционную систему разрабатывают 4 тыс. человек, она чудовищно сложна, громоздка и неэффективна, в ней множество ошибок, но при этом она имеет коммерческий успех. Рынок ее принимает. Это хорошая иллюстрация так называемого «неплохого программного обеспечения» (good enough software) — мы допускаем возможность использования программных продуктов не самого лучшего качества. Проведу сравнение с американской автомобильной индустрией. До 50-х годов мы выпускали вполне успешные в коммерческом плане автомобили. А в 60 — 70-х возникла японская автопромышленность, и они стали продавать более дешевые машины, а американцы — охотно их покупать. Хорошая машина за существенно меньшие деньги — почему бы и нет. Затем оказалось, что японские автомобили более надежны, лучше спроектированы. А сегодня большинство американцев скажут вам, что у них лучше дизайн, они более красивы. Таким образом, для потребителя на авторынке на первом месте — цена, затем надежность, затем элегантность и красота продукта.

В Windows мы имеем слишком дорогой, ненадежный продукт, но Microsoft, тем не менее, преуспевает, поскольку рынок практически не видит альтернатив. Может быть, только Mac OS. Нужна реакция со стороны рынка, чтобы в Microsoft осознали необходимость кардинальных изменений.

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

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

Познакомившись с вашим сайтом, я узнала, что вы очень любите путешествовать. В России вы впервые. Каковы ваши впечатления о Москве и Санкт-Петербурге — как путешественника и с профессиональной точки зрения?

Мне очень понравился Санкт-Петербург, в этом городе чувствуется дух истории. Люди, с которыми я встречался, показались мне очень дружелюбными. И вот что еще интересно — меня поразила начитанность тех, кто слушал меня на семинарах. В своей презентации я рекомендовал много литературы, и, как мне показалось, значительной части аудитории эти книги хорошо знакомы. Те, с кем я здесь общался, производили впечатление очень профессиональных людей. Видно, что они стремятся изучать все новое, что есть в области разработки, чтобы всегда быть на «переднем крае». Это выгодно отличает вас от ситуации в Америке. Конечно, у нас ведется большая работа в области программной инженерии, в компьютерных науках и т.д. Но при этом огромное число разработчиков вообще не имеет фундаментального образования в этих областях. Например, сотрудник, который занимается поддержкой моего сайта, имеет диплом по истории искусства. Это молодой человек 28-30 лет, он постоянно изучает все, что связано с языками Java, JavaScript, Pythone, PHP, знает много умных вещей и может по-настоящему хорошо делать свою работу. Но он никогда не получал систематического компьютерного образования и не читал никаких книг на эту тему. Он добывает нужную информацию в Сети, благо инструменты типа Google дают возможность это делать.

Но полученные таким образом знания часто очень поверхностны, они не дают глубокого понимания базовых принципов. Однако действительность такова, что огромное число занятых в разработке находятся именно на таком уровне. Я знаю, что в конце 90-х можно было сделать прекрасную карьеру в сфере разработки без всякого специального образования, начав с книги типа «HTML для чайников». Правда, первые несколько лет после краха «доткомов» компании стали более требовательными и стремились нанимать на работу только людей с университетскими дипломами в компьютерных науках и программной инженерии. Но сейчас, с наступлением эпохи Web 2.0, компетенции в маркетинге иногда становятся более важны, чем знание HTML. И вновь наблюдается пришествие в индустрию разработки множества людей с весьма поверхностным образованием. Я не владею в деталях ситуацией в России, но мне встречались здесь начитанные, профессиональные люди. Российская программная индустрия за последние двадцать лет завоевала репутацию очень образованной. У российских разработчиков потрясающая академическая база в математике, компьютерных науках, программной инженерии.

Но так ли это важно в современной ситуации — быть настолько образованным в фундаментальных науках? Может быть, важнее иметь знания о бизнесе, рынке, определенные практические навыки?

Смотря чего вы хотите достичь. Хорошо известный в США пример — компания Google, среди создателей которой есть выходец из России. Они разработали очень сложные технологии и смогли построить успешную компанию. Думаю, образование такого уровня ценно, если вы хотите создавать что-то фундаментальное, работать над высококритичными системами. С другой стороны, если иметь в виду работу в обычной американской компании, то достаточно будет знать не очень сложные программные технологии, которые базируются на том фундаменте, который предоставляют разработки Microsoft или Google. В этом случае, наверно, важнее изучать вопросы маркетинга и другие более практичные области.