Компьютерра - Журнал Компьютерра N760

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

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

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

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

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

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

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

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

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

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

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

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

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