Правило «Шестёрки»

Проблема-2003

Успех «Шестерки» берет свое начало в катастрофе с предыдущей версией продукта. В задуманном виде пятая версия не вышла вообще.

Чтобы понять суть катастрофы, придется мысленно вернуться в 2002 год: Windows XP едва поступила в продажу, процессоры компьютеров лишь недавно взяли барьер 1 ГГц, а вот на антивирусном фронте приходится бороться со все новыми классами угроз. Все антивирусные компании значительно наращивают функциональность своих продуктов — внутри должны оказаться и сетевой фильтр (файрвол), и постоянно работающий файловый монитор, и десятки других функций. Имея весьма мощное, но разработанное еще в девяностых ядро антивирусного сканера, команда ЛК приходит к пониманию, что дальнейшее «обвешивание» его новыми функциями сделает продукт до неприличия медленным — уже к имевшейся версии 4.0 по этой части были серьёзные нарекания пользователей («Касперский тормозит» — это как раз из той эпохи). Именно поэтому за новую версию 5.0 взялись «по науке» — новый технический директор, новая система проектирования и принципиально новая архитектура самого антивируса.

На разработку были брошены практически все ресурсы компании, но, спустя год выяснилось, что, даже сделав все по правилам, можно не получить жизнеспособный продукт. Система, созданная по канонам корпоративных клиент-серверных приложений (такую архитектуру выбрал технический директор), никак не соответствовала требованиям, предъявляемым к антивирусу. Она получалась исключительно громоздкой и медленной, а число ошибок по мере отладок не уменьшалось – находились новые. «Я начал говорить с людьми, с ветеранами нашими, начал выяснять их мнение. Они говорят: неправильная архитектура. Получается карточный домик. Здесь поправил – там развалилось», – вспоминает Евгений Касперский. Поэтому доводить проект в его текущем состоянии смысла не имело. Надо было сломать и строить заново.

Сделать всех!

Команда разработчиков ЛК была разделена на тех, кто все еще пытался «добить» продукт на неверно выбранной архитектуре, и тех, кто взялся «доводить до ума» предыдущую (4-ю) версию продукта. Одновременно выделилась команда из четырех человек, решившихся с нуля создать новый продукт, который удовлетворял бы даже не текущим требованиям рынка, а тем, которые возникнут спустя год или два. Основная идея, которая была положена в основу «Шестерки», проста на вид, но сложна в исполнении. Ловить все вирусы и прочие угрозы, не тормозить, не отвлекать пользователя. Ну и красиво выглядеть, если пользователь все же заглянет в интерфейс... «Просто сделать самый лучший продукт», — эмоционально вспоминают тогдашний настрой разработчики. Небольшая по размеру команда поставила перед собой задачу неподъемную, как тогда казалось остальным 200 сотрудникам компании. Впрочем, определенные основания для оптимизма у них были. Дело в том, что отцы-основатели компании — Евгений Касперский и Алексей Де-Мондерик — активно изучали возможные альтернативы, искали более подходящую архитектуру для нового продукта. И довольно неожиданно выяснилось, что альтернатива есть и она разработана в самой ЛК.

Помощь из Праги

Надо сказать, что «под капотом» четвертой версии антивируса на самом деле трудились бок о бок два разных антивирусных ядра, или, как их называют на жаргоне, «движка». Над разбором файлов трудился старый, крайне удачный, многократно лицензированный различным западным компаниям (от G-Data до F-Secure) движок версии 3.0, разработанный еще в 1996 году, а вот более новую задачу фильтрации веб-трафика решал принципиально новый и исключительно мощный механизм, задуманный на «мозговом штурме» в Праге в 1998 году.

Он получил название «Прага», хотя архитектурой и во площением занимался в Москве Андрей Духвалов, в Прагу не ездивший вовсе. Из Чехии приехали только основные идеи, и Духвалова пригласили на работу как раз для их доработки и воплощения. «Прага» должна была статьсугубо антивирусным ядром, но стоявшие перед ней задачи были настолько амбициозны, что гибкости и сложности разработанного движка хватило бы для более сложных систем. Вопрос о том, можно ли сделать на «Праге» продукт целиком, пришел в голову Касперскому при общении с разработчиками предыдущей версии. Он вспоминает об этом так: «Однажды я спросил у Вити Матюшенкова, как там Прага работает внутри продукта, и он сказал: “стоИт как скала!”. Эта фраза была последней каплей, после нее у меня сформулировался Главный Вопрос. Я зашел в комнату, где работали Граф [Де-Мондерик] и Петрович [Духвалов] и задал этот Главный Вопрос: “а можно весь продукт на Праге сделать? ”. Граф ответил что-то типа “невозможно, Прага для других целей создавалась”, а вот Петрович промолчал, но следующим утром пришел с несколькими листами бумаги. И сказал: “Слушайте, а я тут некоторые use cases на «Праге» написал”. Граф посмотрел и сказал: “Ну-ка, пойдем поговорим”. Потом они ко мне пришли и сказали, что можно попробовать».

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

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

Что такое «Прага»

Этот раздел программисты читают с большим интересом. Все остальные могут его пропустить без особого ущерба для повествования.

Уже в самом начале девяностых, на заре антивирусной индустрии, встречались вирусы, которые невозможно было детектировать при помощи обычных сигнатур. Например, непосильны сигнатурному подходу полиморфные (шифруемые с переменным алгоритмом) вирусы. По мере усложнения компьютерных программ, распространения Интернета, перехода вирусописателей от хулиганства к криминальным заработкам, вредоносные объекты становились и сложней, и разнообразней. Даже имея ядро с дополнительными возможностями сверх сигнатурного «детекта», как это было у ЛК, разработчики были вынуждены то и дело обновлять сам антивирус, а не его базы, если им попадалось какое-то новое сложное «зверье». Это сильно замедляло время реакции на выход нового вируса, а успех, который ЛК получила, первой вылечив печально известный вирус CIH (Chernobyl), показал, что за быструю реакцию на вирусы очень даже стоит бороться.

Поэтому уже в 1998 году Касперский сказал коллегам: «Нужно ехать думать про новый движок». Куда ехать? Постановка задачи примерно такая: «Денег не было, поэтому мы искали самое дешевое место рядом с Москвой. Чтобы выехать за город и за городом думать. Чтобы не было там телефонов, Интернета — ничего. Wi-Fi не было никакого тогда. Самым дешевым местом «неподалёку» оказалась... Прага, хотя это совсем не рядом с Москвой».

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

Компонентная архитектура, реализованная компактно и с минимальными требованиями к ресурсам компьютера, по общему признанию, явилась залогом того, что в KAV 6.0 появилось так много новых функций – их туда было очень легко добавлять. Кроме того, когда «Прагу» стали «достраивать», чтобы сделать основой всего продукта, а не только антивирусного ядра, весомый вклад в созревание архитектуры внес Павел Межуев. «Было сделано еще одно важное архитектурное решение – модель разделения бизнес-логики и интерфейса. Также Духвалов и Межуев изобрели диспетчер задач, который мог управлять каждым процессом внутри продукта, и взаимодействие с процессами было очень простым», – вспоминает Николай Гребенников, бывший менеджером проекта KAV 6.0.

Принцип шести

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

Правда, система ролей, принятая в SCRUM, претерпела большие изменения. Касперский выделяет такие роли (их тоже шесть):

Архитектор

Человек, который знает, как и что нужно строить. В «Шестерке» также принимал активное участие собственно в программировании.

Технический дизайнер

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

Изобретатель

Воплощение нестандартных решений для конкретных частных проблем. Их в «Шестерке» было полно – в конце концов, она должна была обеспечивать максимальный уровень защиты при минимальном потреблении ресурсов.

Менеджер проекта

Роль менеджера в SCRUM не жестко регулирующая. Он контролирует ресурсы и сроки, но не руководит напрямую. Не указывает разработчикам, что делать, а лишь подталкивает их к проявлению инициативы. «Команда была маленькая, вначале даже начальника как такового не было. Был менеджер, который планы сводил, отчеты делал, но в основном по всем вопросам мы принимали коллегиальные решения», – вспоминает Духвалов.

Менеджер по маркетингу

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

Психолог

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

Вообще-то говоря, есть еще одна роль, и в SCRUM она крайне важна – это Документатор, человек, который конспектирует происходящее. Но этим никто не занимался, что принесло ряд проблем. «Мы не знали, почему мы это сделали именно так полгода назад», – лаконично объясняет Касперский.

Весьма принципиально, что количество ролей и людей никак не связано. Одна роль может быть распределена по нескольким людям, при этом каждый член команды может сочетать выполнение нескольких ролей. «Хотя определенная организация была, мы все делали единой командой, и роли, по сути, размывались – во время мозговых штурмов разные роли выполняли разные люди. Один, допустим, писал программный код, но и высказывал мнение о дизайне. И его мнение было важным для всех. Я сам был менеджер по продукту и тоже участвовал в обсуждении – это было очень ценное размывание ролей, и каждому было дело до каждого аспекта», – оценивает Николай Гребенников. По словам Де-Мондерика, у программистов тоже была высокая взаимозаменяемость: «У каждого была область, где он был крут, но вместе с тем 50 процентов было всякого другого. Майк мог писать драйвера, если вдруг Собко не приходил, специалисты по интерфейсу могли подхватить работы по ядру, и наоборот. Я мог вместо Макса Юданова что-то нарисовать, и Коля Гребенников иногда скины дорисовывал».

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

Гонка за идеалом

В силу использования «около-SCRUM» методики и амбициозности задач, стоящих перед командой, у «Шестерки» не было жестко зафиксированного технического задания. Согласно общим требованиям продукт должен:

• полноценно защищать от современных компьютерных угроз;
• оптимально использовать системные ресурсы;
• иметь компонентную архитектуру для простоты расширения;
• иметь компоненты, легко переносимые на разные платформы.

В рамках этой сверхзадачи конкретные требования к продукту много раз менялись. Это значительно замедлило его выпуск, но все равно позволило выпустить технологически революционную вещь, опередившую свое время года на два и при этом сильно опережавшую предыдущую версию по скорости. Вскоре после выпуска Kaspersky Anti-Virus 6.0 об этом хорошо написал дизайнер интерфейса Максим Юданов: «Одна из ключевых особенностей проекта – это отсутствие «нормального» ТЗ. Мы прототипировали, обсуждали, писали списки требований и функций, писали самое главное на желтых бумажках, приклеивали их к монитору, забывали, вспоминали и так далее, брали «помощь зала», в смысле сообщества бета-тестеров. И я уверен, что продукт не получился бы ТАКИМ, если бы мы с самого начала написали «нормальное» ТЗ. Мы в таком случае разработали бы продукт, как мы себе его представляли в самом начале разработки. И я точно могу сказать, что этот продукт был бы хуже, чем тот, что мы имеем сейчас».

С этим согласен Николай Гребенников, ныне CTO «Лаборатории Касперского»: «Если бы мы сначала утвердили красивый список функций и потом бы его не меняли, никакой бы поддержки от пользователей и понимания, что им нужно, у нас не было. Первая версия, которая у нас появилась, была не очень пригодная к использованию, много проблем. Над переделками и отладкой мы провели очень много времени – с момента альфы до технического релиза прошло пять (!) кварталов. Для текущего мира это непростительная роскошь, но в тот момент это был хороший опыт».

Касперский подводит итог лаконично: «В начале разработки инновационных продуктов готовьтесь к сносам сроков, возможно, неоднократным».

Жизнь на работе

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

Одно из сохранившихся писем Николая Гребенникова, относящееся к тому периоду, описывает это очень поэтично: «В какой-то момент это даже стал не совсем проект – это было сродни великой игре, когда с момента ее выхода и до финальных титров ты погружаешься в нее и живешь в ней. Утром идешь на работу и в метро вспоминаешь победы и поражения предыдущей ночи, работаешь, а вечером уже думаешь о стратегии прохождения очередного уровня; а после купания и укладывания ребенка ты снова в игре, и до утра ты в другом мире, где возможно все и тебе все по силам». Единственная поправка – в данном случае ночь надо заменить на день, а игру – на работу. «Лучшее время в жизни, наверное. Горящие глаза, листочки расклеенные, неспящий народ, утром прибегает: «Что я придумал», это было вот… супчик кипел», – вспоминает Евгений Касперский.

Потом, когда людей стало больше, костяк разработчиков заразил тем же настроением новичков, вспоминает Де-Мондерик: «Все вкалывали хорошо, и тут был важен заряд «костяка». Был костяк, который реально заражал друг друга идеей, у них был вызов! Сделать на порядок лучше, чем было. И для нас это было основным – Коля, Павел Межуев, Духвалов, я, Майк Павлющик. А остальные этой энергией пропитались. Когда все вокруг вкалывают и ты с ними в этой же комнате, когда все это перед глазами, то ты просто невольно тоже тянешься и стараешься».

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

Круг расширяется

По мере течения процесса разработки, который шел с сентября 2003 года по март 2006-го, команда постепенно расширялась, и к концу «Шестерку» сдавали в релиз почти три десятка человек. По мере появления новых потребностей и перехода продукта к стадии «Альфы» команду пополнили дизайнер Максим Юданов, программисты Павел Нечаев, Денис Гущин, Евгений Рощин и Андрей Герасимов.

Они снабдили продукт многими существенными новшествами – от «скинового» пользовательского интерфейса до встроенного файрвола. Появились специалисты по инсталлятору и бета-тестированию. Правда, наиболее существенную роль в отладке и совершенствовании KAV 6.0 сыграла еще одна оригинальная придумка команды «Шестерки» – форумное тестирование.

Форум

Все участники разработки Kaspersky Anti-Virus 6.0 сходятся на том, что именно благодаря созданному форуму тестеров продукт получился таким продуманным и так хорошо оттестированным. Пользовательское тестирование (которое практикуется в ЛК по сей день) было на тот момент инновацией и определенным риском – конкуренты могли узнать о разрабатываемых технологиях слишком рано.

«Вопрос решался на серьезном совете, потому что бета-тестирование — это по факту открытие бета-кода для хакеров и конкурентов. Были как противники, так и сторонники. Аргументы противников я уже озвучил, но и сторонники говорили весомо. У нас были очень ограничены ресурсы, было всего два тестера, остальные брошены на версию 5. А продукт написан с нуля, требовался значительно больший объем тестирования. Впервые был применен подход регулярных сборок, то есть еженедельных сначала, потом ежедневных. Форумное тестирование этих сборок позволяло добиться очень высокого качества тестирования без привлечения значительных внутренних ресурсов».

Все разработчики очень активно общались на форуме с тестерами. «Во время форумного тестирования было несколько тысяч пользователей, и человек пятьсот были очень активными. Они ждали новую сборку, каждый вечер ее ставили. И это было бесплатно для компании», – вспоминает Николай Гребенников, проводивший на форуме многие часы каждый вечер и, по собственному признанию, пару раз даже засыпавший прямо над клавиатурой.

На форуме собирали не только ошибки, но и пожелания к продукту. Многие из них были учтены, что и сделало KAV 6.0 таким ценным. Кстати говоря, пожелания собирали не только онлайн. Касперский вспоминает, что разработчики регулярно ходили по офису компании, брали менеджеров по продажам, техподдержке – и на всех «прогоняли» бета-версии. По итогам опроса сотрудников в продукт также вносились важные изменения, например, по просьбе техподдержки воплотили переключение на английский язык по одной кнопке.

Впрочем, «форумные» улучшения имели свою цену – перенос сроков выпуска. «По результатам форумного тестирования у нас был огромный список доработок, но в какой-то момент я понял, что мы не можем добавить уже ничего, даже если какое-то предложение очень интересно. Мы дали жесткое обязательство выпустить релиз до конца первого квартала 2006 года. Мы выпустились в 18 часов 30 минут 31 марта», — ставит драматическую точку Николай Гребенников.

Успех

На выходе у все еще небольшой, хоть и несколько разросшейся команды «Шестерки» получился продукт с феноменально компактным инсталлятором, эстетичным интерфейсом на основе сменных «скинов», весьма низким влиянием на производительность компьютера, а главное – просто напичканный серьезными нововведениями, такими как проактивная защита, блокирующая неизвестные приложения на основании того, что они ведут себя подозрительно. «В Symantec просто ошалели, когда американские журналы стали давать нам золотые звездочки. Да и везде, во всех журналах мы получали высшие оценки», – с удовольствием вспоминает Евгений Касперский. Благодаря развитию партнерских сетей в Европе, США и Китае удачный продукт имел действующий канал сбыта, и рейтинг бестселлеров в онлайн-магазинах в одночасье «позеленел».

Столь удачной «Шестерка» вышла благодаря подходящей архитектуре, которая позволяла легко внедрять технологические новации и обеспечивала высокую производительность, а также благодаря процессу разработки, который был идеально приспособлен к компактной и полной энтузиазма команде создателей. Пожалуй, в этом и состоит один из важнейших уроков работы над Kaspersky Anti-Virus 6.0 – чтобы проект «взлетел», процесс и технология разработки должны соответствовать команде разработчиков и масштабу задач.

Шесть ролей и одна кофеварка

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

Восемь лет спустя