CC BY
10
Юрий Зиссер
директор УП «Надежные программы», председатель совета директоров TUT.BY
ЖИВЫЕ КЛАССИКИ
Уникальнейшую возможность посетить мастер-классы родоначальников программирования — Майкла Кусумано, Лари Константина, Ивара Якобсона и других знаменитых прародителей высоких технологий — предоставила Software Engineering Conference, организованная российской национальной ассоциацией компаний-разработчиков программного обеспечения «Руссофт» и компанией RUSSEE, оказывающей услуги на рынке образовательных и консалтинговых услуг в области информационных технологий.
В программу мероприятия вошло около 70 докладов из стран СНГ, США, Канады, Франции, Германии и Индии по трем основным тематическим направлениям «Новейшие технологии в сфере разработки ПО», «Управление процессами разработки ПО» и «Управление человеческими ресурсами». Однако центром притяжения интересов большинства участников конференции оказались живые «классики», приглашенные для проведения 4-часовых мастер-классов.
СЕКРЕТЫ НЕ ДЛЯ MICROSOFT
Семинар Майкла Кусумано, профессора школы менеджмента имени А. Слоуна при Массачусетском технологическом институте, соавтора переведенной на 14 языков знаменитой книги «Секреты Microsoft», назывался «Предпринимательство в сфере программного обеспечения: сравнительный анализ бизнес-моделей и ключевые факторы успеха».
Г-н Кусумано отметил, что в мире 35 тыс. фирм-разработчиков со штатом от пяти человек и выше ежегодно продают программного обеспечения на 700 млрд долл. США, из которых 1/3 составляют продукты, а 2/3 — услуги. Из этих компаний на долю Северной Америки приходится 50 %, Европы — 30 %, Азии — 15 %. Каждый год возникают тысячи фирм по разработке программного обеспечения, из которых выживают единицы. Много ли перспективных технологий стали (или когда-нибудь станут) полезными для конечных пользователей или для бизнеса? Например, искусственный интеллект так и не воплотился в продукт и остался технологией. Интернет-браузеры (как и любое бесплатное программное обеспечение) не принесли своим разработчикам ничего, кроме имени, и с этой точки зрения бизнесом не являются.
М. Кусумано назвал восемь условий, шесть-семь из которых должны выполняться для запуска любого успешного бизнеса, не обязательно связанного с программированием. Вот они: сильная команда менеджеров, привлекательный рынок, новаторский продукт (или услуга), свидетельства живого интереса специалистов и потенциальных покупателей, наличие плана преодоления барьера начального недоверия (90 % покупателей никогда не станут работать с новичками), качество бизнес-модели (выход по финансам «в ноль» в течение 2 лет, масштабируемость доходов), стратегическая и техническая гибкость, потенциальные возможности инвесторов по первичному размещению акций или продаже бизнеса в будущем. При этом начинающим следует избегать типичных ошибок: излишних затрат на исследования и разработку еще до первого внедрения; попыток создать слишком универсальное решение вместо узкоспециализированного нише-вого; переоценки достоинств своего продукта перед существующими аналогами; самоуспокоения из-за избытка финансирования («поцелуй смерти»).
Что же касается стратегии программистских компаний, то М. Кусу-мано отметил принципиальную разницу между ориентацией на продукты и услуги. В первом случае экономический эффект достигается численностью пользователей, долей рынка и пониманием общих нужд пользователей, а во втором доходность основана на масштабах компании, а бизнес — на понимании специфических нужд каждого пользователя.
С одной стороны, выпускать продукты в миллионах экземплярах по цене магнитных носителей представляется весьма выгодным. Как заявил руководитель компании Sun Microsystems Скотт Мак-
нили, «услуги станут надгробием для компаний с устаревшими технологиями, которые больше не в состоянии конкурировать». с другой, немногочисленные, ставшие бестселлерами, «коробочные» продукты подвержены быстрому моральному устареванию и к тому же плохо продаются в периоды экономических и иных кризисов. с этой точки зрения фирмы, ориентированные на услуги, выглядят предпочтительнее. к тому же, создавая программу-хит, очень сложно угадать запросы потребителя. в любом случае низкий ценовой барьер входа на рынок очень скоро приводит к появлению конкурирующих продуктов, к маркетинговым войнам и неизбежному падению нормы прибыли.
в конечном счете оптимальной является гибридная модель, когда «коробочные» продукты порождают широкий спектр услуг, связанных с их обслуживанием. однако, с другой стороны, и услуги продаются лучше, будучи «упакованными» в виде более понятных и осязаемых покупателями «коробочных» решений, играющих роль своеобразного локомотива продаж. Этот рецепт особенно применим к оффшорному программированию, где «овеществление» услуг является вполне очевидным и естественным маркетинговым ходом. постепенно с годами соотношение между объемами продаж продуктов и услуг у большинства компаний стремится к 30:70 независимо от того, с чего она когда-то начинала свое дело. достижение подобного соотношения — признак зрелости бизнеса. правда, это — «средняя температура по палате», выведенная из многолетних исторических наблюдений над сотнями компаний. наиболее очевидным исключением из этого правила является, например, корпорация Microsoft.
новые программные продукты рождаются в двух случаях — при появлении технических новшеств (новых типов компьютеров, технологий, устройств, операционных систем) и бизнес-ниш, требующих автоматизации. признанные лидеры рынка обычно удерживают свои доминирующие позиции до возникновения новой ниши или технической платформы, в которых они некомпетентны. им может не хватать технологий, маркетинга либо знания конкретного вертикального рынка. многие фирмы выросли
П I
*
№4(38)_2006 НАУКА И ИННОВАЦИИ
вместе с новыми рыночными сегментами, в которых лидирующим корпорациям было нечего предложить. за примерами далеко ходить не надо: так, IBM в 1960—1980-х гг. упустила рынки систем управления базами данных, ERP-систем, операционных систем для персональных компьютеров. A Microsoft в 1990-х не удержала инфраструктуры интернета, сферы управления личными финансами и малым бизнесом, вертикальных приложений. в зачаточном состоянии находятся приложения для мобильных телефонов, а ведь это «рынок объемом в 5 миллиардов пользователей», — отметил м. кусумано.
юзабилити как результат моделирования
семинар профессора сиднейского технологического университета ларри Константина назывался «разработка программного обеспечения, ориентированная на процесс использования». A ведь не так давно речь шла о том, что по должно ориентироваться на пользователя! первый подход говорит о важности удовлетворенности пользователей, о том, что разработка должна отталкиваться от вводимых данных, основываться на непрерывной обратной связи с юзерами, изучая их опыт, ловя каждое их слово и бесконечно переделывая интерфейс под их сиюминутные пожелания. неизбежный результат данного подхода — итерационное прототипирование методом проб и ошибок.
за примерами «дружественного интерфейса» далеко ходить не надо. однажды с успехом использовав новую возможность текстового процессора Microsoft Word, мы уже через месяц не помним, каким образом добились результата. пятнадцать минут, затраченные на поиски в меню и встроенной системе помощи, ничего не дают, поскольку мы давно забыли те умные слова, которыми разработчики решили назвать искомые возможности.
напротив, при разработке, ориентированной на процесс использования, выполняется моделирование поведения пользователя, при котором достаточно лишь эпизодического его участия в процессе. Краеугольный камень методики—разработка моделей диалога взаимодействия пользователя с компьютером. Главная идея методики — чем проще программа, тем лучше она умеет предугадывать намерения юзера. вместо того чтобы быть «дружественными к пользователям», программы должны повышать их личную производительность. Удобство использования по ведет к удовлетворенности юзеров, а не наоборот.
для разработки «правильных» программ, по мнению л. Константина, необходимо определить три модели: модель ролей (роли пользователей по отношению к системе), модель задач (структуру работ, необходимых пользователям для достижения целей) и модель содержания (содержание и организацию пользовательского интерфейса, поддерживающего выполнение выявленных задач). лишь на последнем этапе можно реализовать абстрактное прототипирование, разрабатывать сценарии взаимодействия и визуализировать их. задачи осуществляются пользователями, выполняющими определенные роли. в свою очередь, роли определены потребностями, интересами, ожиданиями, поведением и обязанностями пользователей, взаимодействующих с системой, например роль тестировщика, роль требующего экстренной по-
59
мощи, роль билетера и т.д. Один участник может играть несколько ролей и наоборот, причем каждая из них обладает наименованием, контекстом, характеристиками и критериями.
Обыкновенный банкомат после вставки банковской карты и ввода пин-кода задает два совершенно лишних вопроса: выбор языка и выбор действия из меню, указывает Л. Константин. Таким образом, сценарий диалога банкомата с держателем карты состоит из произвольно и нелогично перемешанных высокоуровневых и низкоуровневых (машинных) требований. Банкомат ориентирован на работу встроенной программы, а не на пользователя и тем более не на процесс использования. На самом деле проектирование должно начинаться с определения ролей участников системы — человека (роль «желающий-снять-деньги» и т.д.) и банкомата. Последний сразу же после ввода пин-кода должен предлагать к выдаче типовую сумму, а все остальные возможности (выбор языка и других сумм, печать справки по счету) должны стать опциями. типовая сумма определяется из истории операций данного клиента, а стандартный язык интерфейса — страной происхождения карточки.
Впрочем, не все рецепты нужно воспринимать буквально. Так, на примере разработки подсистемы выдачи забронированного театрального билета перед спектаклем проявилась специфика, зависящая от культуры страны внедрения. Профессор л. константин убежден, что для получения забронированного и ранее оплаченного билета посетители театра должны вставить в устройство считывания свою кредитную карту (так как это просто и универсально) и лишь в случае ее отсутствия назвать кассиру номер заказа или фамилию. Описанная система разрабатывалась для Новой Зеландии. Надо ли объяснять, что для наших театров порядок должен быть обратным?
плоды ЗРЕЛОСТИ
Мастер-класс профессора института Карнеги-Меллона, соавтора знаменитого стандарта СММ1 Марка Полка назывался «Зрелое управление разработкой программ» и был посвящен управлению
'Г*
Профессор Л. Константин
разработкой программного обеспечения. Изложение частично основывалось на не переведенной у нас работе С. Мак-Коннелла «Быстрая разработка». Вдохновенный, яркий, блестящий стиль изложения профессора Полка покорил слушателей, а энцикло-педичность источников, использованных для доклада, позволила за 4 часа охватить едва ли не все аспекты управления разработкой программ.
Мастер-класс Ивара Якобсона из Стокгольмского университета под названием «UML — основа лучших современных приемов разработки программ» начался с обсуждения CMMI — стандарта зрелости фирмы-разработчика программного обеспечения. Многие ошибочно полагают, что главный критерий правильности процессов — документирование и измерение всего и вся, отметил г-н Якобсон. В реальности зрелые процессы должны быть направлены на получение работающих программ, на как можно более раннюю их работоспособность, а также на раннее снижение рисков, заботу о качестве на протяжении всего проекта, на максимально точный переход от исходных требований к программному коду, гибкость к всевозможным изменениям и т.д. Хорошие программы должны состоять из компонентов, для описания взаимодействия которых используется UML (Unified Modeling Language), а разработка должна выполняться с использованием объектно-ориентированного программирования. Таким образом, зрелый процесс итеративен, сосредоточен на различных способах использования программы (use cases) и архитектуре. Поэтому внедрение UML и RUP (Rational Unified Process) — необходимое условие достижения зрелости процессов.
Не менее любопытна и изложенная в мастер-классе И. Якобсона концепция активного программного обеспечения. Все мы привыкли к тому, что программы разработаны технократами для технократов. В программах человек активен, а компьютер пассивен, бизнес-логика «зашита» в программы и с большим трудом поддается изменениям. Кроме того, мы привыкли, что программы выполняют в точности то, что приказал пользователь, а не то, чего он на самом деле ожидал.
В отличие от традиционных программ активные не требуют глубокого изучения бизнес-логики и самих программ, и их можно легко приспособить к организационным изменениям. В ряде случаев они могут брать на себя инициативу, оценивать мнения, предлагать пользователю варианты, обеспечивать информацией, причем уровень поддержки пользователей зависит от уровня их познаний в предметной области, программе и т.д. Иными словами, программы должны «понимать», что работают не с бездушными роботами, а с живыми людьми, и проявлять некоторый интеллект. Пока что реализация активных программ — отдаленная мечта.
Профессор Якобсон коснулся и других модных веяний технологии программирования — сервисно-ориентированной архитектуры, шины корпоративных сервисов, систематического повторного использования компонентов, модельно-управляемой архитектуры, аутсорсинга и распределенной разработки и т.д. В целом компьютерный мир, заключил он, движется от компьютерно-ориентированного к человеко-ориентированному.
