Менеджеры и другие вирусы

Архив

Николай Гребенников, директор департамента по исследованиям и разработке "Лаборатории Касперского", еще во время учебы на третьем курсе МГТУ им.

Николай Гребенников, директор департамента по исследованиям и разработке "Лаборатории Касперского", еще во время учебы на третьем курсе МГТУ им. Баумана с подачи своего научного руководителя начал работать в Государственной Регистрационной палате при Министерстве юстиции, где на Delphi и Interbase написал систему регистрирования юридических лиц на территории РФ. Работа была интересная, но платили мало. Гребенников ушел в отдел информационных технологий ИТАР-ТАСС, где платили еще меньше, а после этого начал работать в коммерческих компаниях, в том числе и в Cybiko (один из проектов Давида Яна из ABBYY), где трудился над созданием одноименного мини-компьютера. В декабре 2002 года Николай пришел на собеседование в "Лабораторию Касперского".

Сейчас с улыбкой вспоминаю, как почти месяц мне по разным причинам отказывали. К моменту прохождения интервью в "Лаборатории Касперского" я успел достаточно хорошо изучить PMBOK[A Guide to the Project Management Body of Knowledge (PMBOK Guide) - стандарт управления проектами и документ, описывающий этот стандарт. В конце нынешнего года должна выйти четвертая версия стандарта. Тест, который Гребенников упоминает ниже, называется PMP. - Прим. ред.], тестирование по которому проводилось здесь при приеме на работу. Мой результат был 4,55. Если не ошибаюсь, этот показатель - третий в России среди тех, кто проходил данный тест онлайн. Успешно пройдя тестирование и ряд интервью, в январе 2003 года я был принят в компанию на должность системного аналитика. Причем существовала договоренность, что если я сумею хорошо себя зарекомендовать, через некоторое время мне будет дана возможность реализовывать на практике собственные идеи в качестве менеджера проектов. В итоге я проработал полгода в команде, занимавшейся разработкой Антивируса Касперского для рабочих станций версии 5.0, а в сентябре 2003 года возглавил проект Prototype Personal Prague (PPP). На его реализацию ушел год.

На основе успешно завершенного проекта PPP осенью 2004 года было принято решение о начале разработки Антивируса Касперского версии 6.0 и сформирована проектная команда, в которую вошел и я. Работа над шестой версией продукта заняла почти три года. В процессе ее разработки нашей командой предпринимались попытки внедрения ряда других, во многом инновационных решений. Возможно, именно это и послужило причиной моего назначения в июне 2005 года на должность заместителя руководителя департамента инновационных технологий (R&D).

Руководителем подразделения в тот момент был Евгений Касперский, но поскольку Евгений является публичной персоной, времени на управление департаментом у него оставалось немного. Поэтому значительная часть задач по оперативному руководству департаментом легла на меня. Число сотрудников департамента, поначалу не превышавшее шестидесяти человек, в настоящий момент выросло втрое и достигло 185 человек, причем это далеко не предел - в планах у нас дальнейшее расширение.

Важным аспектом моей работы в то время было совмещение функций менеджера и менеджера проектов. В силу ряда причин тогда не существовало четкого механизма обратной связи с потребителем. Перед нами стояла задача - создать эффективный механизм сбора мнений конечных пользователей. Мне пришла в голову мысль об организации общения с нашими пользователями через форум компании, где бы информация аккумулировалась и анализировалась на всех этапах реализации каждого конкретного проекта: на начальном этапе тестирования, в процессе эксплуатации официальных версий или же стадии выпуска обновлений. Выпущенная нами в марте 2005 года бета-версия Антивируса Касперского 6.0 произвела настоящий фурор на форумах, в том числе и на форуме "Лаборатории Касперского". В кратчайшие сроки была сформирована команда заинтересованных в дальнейшем развитии продукта людей - не побоюсь этого слова - наших фанов. Они принимали самое деятельное участие в тестировании Антивируса, чем сильно нам помогли: выложив новую сборку вечером, к утру мы получали множество ценных откликов, на основе которых вносили в продукт изменения.

Совмещение функций заместителя департамента информационных технологий и менеджера проектов позволило мне принимать решения о внедрении в продукты новых инновационных разработок компании, таких, например, как небезыз­вестный модуль проактивной защиты. Кроме того, мы приступили к созданию прототипов ряда компонентов, которые в версиях 7.0 и 8.0 дали свой эффект. После выхода Антивируса Касперского версии 6.0 в мае 2006 года мы сконцентрировались на технологиях и в версии 7.0 внедрили модуль эвристического детектирования, что фактически позволило реализовать концепцию "тройного щита" с несколькими модулями защиты.

Через год начались работы над версией 8.0. Поскольку речь шла о создании антивируса с применением по-настоящему революционных технологий, было решено, что проект возглавлю я как руководитель департамента R&D - это позволило бы максимально оперативно принимать решения о внедрении новых компонентов. Задуманное мы смогли реализовать через девять месяцев кропотливого труда - 29 апреля 2008 года.

Параллельно в январе 2008 года в "Лаборатории Касперского" была проведена реорганизация, в результате чего были сформированы новые менеджерские функции. Решением компании я был назначен на должность директора департамента по исследованиям и разработкам, которую занимаю до сих пор.

Что оказалось для вас неожиданным, когда вы стали менеджером?

- Пожалуй, то, что большинство книжных рекомендаций и методик попросту неприменимы в реальной жизни. Кроме того, идеи agile-разработки, казавшиеся очень эффективными, особенно для небольших команд, оказались не столь эффективны в рамках работы над таким масштабным проектом, как, например, Антивирус Касперского 6.0.

Чем отличается руководство инженерами от руководства менеджерами?

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

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

В какой момент люди переходят на следующий уровень?

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

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

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

Менеджерская ошибка, ставшая для вас самым большим уроком?

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

Как мотивировать людей?

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

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

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

Что касается книг по управлению, то я бы отметил "Руководство командой разработчиков программного обеспечения. Прикладные мысли" Сергея Архипенкова - за практический подход и отсутствие "советов от великих консультантов", а из книг по бизнесу в целом - "Построенные навечно. Успех компаний, обладающих видением" Джима Коллинза и Джерри Порраса. Книга не новая, но крайне поучительная.