http://habrahabr.ru/company/kaspersky/blog/222635/

Когда говорят, что инновации Made in Russia — это только спорные проекты вроде «Ё-мобиля» паровоза Черепановых, однозначно неоспоримые вроде космических ракет и прочих полу- и совсем неполу-военных изделий, или голые идеи на экспорт — не верьте. У нас есть чем похвастать, и мне за это гордо.

За прошедшие XX-надцать лет моя компания выросла из мелкого местечкового мухомора в топы рейтингов IDC и верхне-правильный угол «магического квадрата» Гартнера. Красивый офис на главной улице страны, Слон Дали на ресепшене, почти 3 тысячи человек в штате, 30+ офисов по всему миру… и прочие хвалилки. Но здесь не про это.

Почему это получилось? Много причин. Например, мой неизменный принцип: пробовать, пытаться и не бояться ошибок. А еще ― партнёрская программа, работа с ритейлерами, онлайнерами, столицами и провинциями ― там много чего было, но и это не по данной теме.

Все перечисленное — вторично (да простят меня те, кто несёт эту службу). Первично — наши технологии и продукты (в смысле, просто софт, а не «софт+всё остальное»). Поскольку если есть софт — всё остальное можно настроить. Если же нет главного — товара, — то всё остальное нет смысла строить. Иначе бизнес (продажи) будет либо одноразовым, либо коррумпированным, что мне претит категорически и фатально.



Итак, софт. Чем здесь можно гордиться? Есть чем! Расскажу вам, уважаемые хабравчане, про «Шестёрку».

Совсем недавно мы праздновали восьмилетие со дня выпуска в свет революционной (для своего времени) шестой версии KAV (Kaspersky Anti-Virus то бишь), продукта, который порвал (буквально) рынок домашних антивирусов в 2006-2009 годах. Который свёл вместе супер-изобретательские технологии: проактивная блокировка вирусов, удобство пользования и минимум потребления ресурсов (да, именно с «Шестёрки» мы больше не тормозим). Прорывные методы работы с мировыми ритейлерами, онлайнерами и маркетигами оставляю в сторонке, это тема для другой беседы. Фиг с ним, в следующий раз.

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

Благодаря всему этому «Шестёрка» получилась принципиально лучше прежних версий. Принципиально лучше прежних версий наших продуктов, и на годы опередила все домашние продукты наших главных конкурентов. Да и не главных конкурентов тоже. Сиё изделие ловило вирусы как Покрышкин мессершмитты, будучи при этом очень компактным, незаметным и быстрым во всех хороших смыслах этих слов. Правда, разрабатывали ее очень долго, чуть ли не три года, и с большими приключениями. Думаем отнести их описание в Голливуд Мосфильм, а здесь просто признаюсь, что для создания этого проекта нам пришлось изобрести свою разновидность agile-методики на основе SCRUM, уволить техдиректора, нанять нового и тоже уволить, а также пустить под нож пятую версию продукта… Путь к победе был нелёгок и тернист.

Под нож

За что на плаху пошли два директора и один продукт? Это было 12 лет назад, 2002-й год. Кто помнит те времена? Только что вышла Windows XP (кстати, помянем старушку, «всего хорошего, и спасибо за рыбу» ©), 1 ГГц вполне себе круто, до айфона еще 5 (пять!) лет, а вот на антивирусном фронте от популярности Интернета становится веселее с каждым днём. Появляются всё новые типы вирья (Мелисса, РедКод, Сламмеры всякие), и антивирусные компании вынуждены наращивать функциональность продукта. Внутри антивируса должны оказаться и сетевой файерволл (или брандмауэр, если вам больше нравятся слова из немецкого), и постоянно работающий файловый монитор, и десятки других функций. Наша «четвёрка» с такой нагрузкой не справлялась («Касперский тормозит» — это вот как раз оттуда, из той эпохи), и мы, попрощавшись с техдиректором «четвёрки», наняли нового. Чтобы он сделал нам современный антивирус, который ловит всё и всех. И не тормозит, зараза! Чтобы новый правильный директор набрал правильных людей, выбрал правильную организационную структуру, правильный метод управления проектами, правильный контроль качества — ну, сами понимаете. Он должен был сделать всё. Мы (компания) за это предоставили все возможные ресурсы — кадровые и финансовые. Главное — сделать!!! Остальное — заработаем.

И… хрен там! Через полтора (или два) года почти все наработки пришлось пустить в корзину. Новый техдиректор создал… мягко говоря, систему, не вполне подходящую к требованиям коммерческого программного продукта. Управленческие методики были скопированы с софт-аутсорсинга, а техническая архитектура продукта была построена по канонам корпоративных клиент-серверных приложений. Вся эта, простите, херота ну никак не соответствовала требованиям, предъявляемым к коммерческому домашнему антивирусу. Мало того, что прототип «пятёрки» был громоздким и медленным, в нем по мере отладки не уменьшалось число ошибок! Мы начали говорить с нашими старыми программистами, выяснять их мнение. Они говорят: неправильная архитектура. Получается карточный домик. Здесь поправил — там развалилось. Поэтому доводить проект в его текущем состоянии смысла не имело. Надо было сломать и строить заново.

О пользе чешского пива и объектного подхода

Хотя мы об этом не знали, у нас уже было решение проблемы: архитектура, пригодная для создания антивируса, уже была разработана. Она трудилась в «уголочке» четвертой версии, фильтруя веб-трафик. Задумали мы ее в Праге аж в 1998 году (ага, искали место подешевле в Подмосковье для мозгового штурма, но Подмосковье оказалось дорогим, в отличие от Праги), но пока наняли человека, который занялся ее программированием — Андрея Духвалова — пока он что-то написал, наступил XXI век.

«Прагу» (так назвали архитектуру) написали в основном для разбора сложных вредоносных объектов. Детектировать вирьё «по тушке» (даже полиморфной) — это умел делать уже движок 1992 года. А вот «тушку» достать из любого объекта на компьютере (например, из ворд-документа внутри архива внутри почтовой базы данных) — это была очень сложная задача. «Прага» умела делать это. Но чтобы «научить» ее этому, пришлось заложить настолько мощный потенциал по функциональности, что его хватило бы на что-то большее, чем антивирусный движок. Те, кто использовал «Прагу» в KAV 4.0, очень ее хвалили, и однажды у меня возник Главный Вопрос.

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

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

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

Немножко больше о Праге

Я не уверен, что каждый из нас получит удовольствие от копания в «топком броде». А уж джинсы отстирать потом от полученных ощущений — это вообще дело очень упорных рук (гуглить «mad mud road/trip/hike). Посему вот небольшое эссе, которое, кстати, не принадлежит моему «перу», но в точности совпадает с моим мировоззрением.

Наш SCRUM

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

Для горстки психов, CMM и прочие модные уже тогда не модные проектные методики не очень-то подходят. Agile-методики десять лет назад не были мейнстримом, и всю тему пришлось раскапывать, подробно изучать самим. В итоге, начитавшись книжек и наспорившись, в качестве методики разработки взяли сильно перелопаченный SCRUM.



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

• Архитектор: человек, который знает, как и что нужно строить. В «Шестёрке» также принимал активное участие собственно в программировании;
• Технический дизайнер: для этой роли никто не придумал более точного названия, но этот человек отвечает за реализацию конкретных решений и, что более существенно, работает «главным спорщиком», который знает, как не надо делать те или иные вещи;
• Изобретатель: воплощение нестандартных решений для конкретных частных проблем. Их в «Шестёрке» было полно. В конце концов, она должна была обеспечивать максимальный уровень защиты при минимальном потреблении ресурсов. Если что-то нужно было сделать, но никто не понимал как именно — ему говорили: «Иди домой, придумай к утру, так надо»;
• Менеджер проекта: как и в классическом скрауме, у нас менеджер — не начальник. Он контролирует ресурсы и сроки, но не руководит напрямую, а лишь подталкивает девелоперов к проявлению инициативы. «Команда была маленькая, вначале даже начальника как такового не было. Был менеджер, который планы сводил, отчеты делал, но в основном по всем вопросам мы принимали коллегиальные решения», — это Духвалов вспоминает;
• Менеджер по маркетингу: среди психов должен быть человек, который напоминает им, что продукт делается не для себя, а для клиентов. В самом широком смысле слова. Клиент = кто деньги платит, кто партнёр, кто техподдержка, кто продаёт лично — и все остальные тоже! Ты можешь сто раз знать, как делать антивирусную защиту, но как показать ее юзеру, чтобы тому было удобно, понятно и не боязно — решает маркетолог. Фидбэк собирали на форуме и прямо в ЛК. Мы регулярно ходили по офису компании, брали менеджеров по продажам, техподдержке — и на всех «прогоняли» бета-версии. По итогам опроса сотрудников вносили нужные изменения, например, по просьбе техподдержки сделали переключение на английский язык по одной кнопке;
• Психолог: как сказал наш драйверист Андрей Собко, самое трудное в разработке было — договориться с коллегами. Они все жутко упрямые. Конечно, это все творческие конфликты, и они проходили очень продуктивно, но все равно — нервы, много работы, мало выходных и сна. Кто-то должен следить, чтобы атмосфера оставалась доброжелательной;
• Документатор: слово «Документатор» хочется прямо взять в тройную рамочку. Мы попросту не смогли взять человека на роль Документатора, денег тупо не было! А он очень нужен — кто-то, кто записывает все происходящее. Без него мы через полгода уже не знали, почему то или это сделано именно так.

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

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


^{Николай Гребенников и скрижали список функций первой бета-версии}

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

О сроках

Проблема сроков и списков todo была у нас при разработке «Шестёрки», и стояла очень остро. С одной стороны, не было фиксированного ТЗ, и требования к продукту много раз менялись по ходу разработки. Мы прототипировали, обсуждали, писали списки требований и функций, писали самое главное на желтых бумажках, приклеивали их к монитору, забывали, вспоминали и так далее. С альфы до техрелиза прошло аж пять кварталов! С другой стороны, в результате в продукт вошло множество функций, о которых мы вначале не задумывались вовсе, и которые и сделали его революционным. Здесь, конечно, большую роль сыграл наш форум.

Хотя с сентября 2003 по март 2006 года, пока делалась «Шестёрка», в ней появилась куча новых задач, а команда выросла почти до тридцати человек, было одно дело, которому выделенной команды ну никак не хватало. Это бета-тестирование. Продукт — новый от и до, написан с нуля. Продукт сложный, поэтому требуется огромный объём тестирования. Впервые был применён подход регулярных сборок, то есть сперва еженедельных, потом ежедневных. В результате мы поспорили-поспорили, и решились на форумное тестирование. Благодаря нескольким тысячам форумчан, KAV6 был очень неплохо оттестирован! Все разработчики очень активно общались на форуме с тестерами. «Человек пятьсот были очень активными. Они ждали новую сборку, каждый вечер ее ставили», — вспоминает Коля Гребенников, бывший менеджером проекта KAV 6.0. Он сидел на форуме многие часы каждый вечер и иногда даже засыпал прямо над клавиатурой. Впрочем, мы все сидели вечерами, потому что энтузиазма было ого-го. Горящие глаза, кипящий котел идей — лучшее время в жизни!

Да, возвращаясь к форуму — он нам и помог, и помешал. Помог выпустить отличный продукт, помешал соблюсти сроки :) По результатам форумного тестирования у нас был огромный список доработок, но в какой-то момент пришлось его закрыть на добавление. Гребенников поклялся мне выпустить релиз до конца первого квартала 2006 года. И успели-таки — в 18 часов 30 минут 31 марта!

Успех

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

Вот!

Вместо заключения

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


^{Талисман проекта и по совместительству первая в ЛК кофемашина. Уже не работает :(}

Проект получился!

И последнее. Недавно нам пришлось расстаться с одним из ключевых, самых главных людей из «Шестёрки». Николай Гребенников ушел своим путём, компания — продолжает идти своим. Это тех-эссе я посвящаю Николаю Гребенникову, который был со мной 10 лет, вместе с которым мы своротили горы, и которого я буду помнить всегда, пока не помру.

Евгений Касперский