• Интервью с Николаем Гребенниковым, “Лаборатория Касперского”

    Posted on November 26th, 2008 Александр Орлов 8 comments

    Не так давно мы договорились с журналом “Компьютерра” запустить новую рубрику – разговоры с интересными менеджерами из нашей индустрии. В качестве менеджеров будут выступать директора департаментов крупных компаний, собственники своих компаний по разработке ПО – то есть люди, которым точно есть чем поделиться с аудиторией Happy PM. :)

    Итак, на этой неделе состоялся первый выпуск новой рубрики – в текущем номере “Компьютерры” опубликовано интервью с Николаем Гребенниковым, директором департамента по разработкам “Лаборатории Касперского”. Чуть ниже вы можете скачать интервью полностью. Вопросы, которые обсуждались:

    • Применимы ли книжные методики в реальной жизни
    • Два главных качества хорошего проджект менеджера
    • Что отличает руководство инженерами от руководства менеджерами
    • Надо ли говорить с инженерами, когда ты уже наверху
    • Как подобрать человека на роль заместителя
    • Как избежать интриг
    • Мотиваторы для программистов

    Текст интервью в pdf

     

    8 responses to “Интервью с Николаем Гребенниковым, “Лаборатория Касперского””

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

    2. Интервью с Асхатом на очереди?

    3. 2 Алексей – не, Асхата не опубликуют, наверное. Там формат рубрики – действующие менеджеры. А Асхат – эксперт, правда, мега-эксперт. :) Думаю, что я это интервью включу в книгу (из всех интервью есть идея скомпилировать книгу).

    4. 2 Alex. В общем, да. Я даже бы сказал, что менеджерами надо делать тех, кто эти качества уже выработал и показал, работая инженером. :)

    5. Всем доброго здравия.

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

      Спасибо.

    6. Боюсь, что шансы, что Николай найдет время поделиться идеями не велики. Но я ему все равно написал. При встрече надо будет этот вопрос обсудить в деталях.

      Я вообще много общаюсь про гибкие методики, и для себя сделал несколько выводов про их внедрение. Выводы вот какие:

      1. Методики довольно хреново приживаются там, где их пытаются насадить сверху. Это я слышал в нескольких, кстати, больших компаниях.

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

      3. Внедрение методик зачастую происходит довольно противоестественным образом (часто из-за пункта 1). Типа сделаем итерации, но на скрам митинги мы забьем в силу того, что бла-бла-бла. :)

      4. Эффект от внедрения часто наступает не сразу, а, например, через год – когда команда выравнивается по квалификации, когда большинство косяков в результате ретроспектив устранены и пр., и пр.

      А вообще надо позвать Асхата, чтобы он поделился своим опытом про Agile в проект, как у Вас, Альберт, и про то, что там можно было бы сделать.

    7. По поводу Agile в глобальных проектах. Тут возникает вопрос в том, что такое Agile. Если под Agile подразумевать хаос и анархию, то в глобальных проектах (в отличие от маленьких и локальных) Agile сдохнет быстро.
      Для глобальных проектов разработка ведется по другому.
      Проблемы большого проекта –
      1) необходимость синхронизации работы нескольких команд
      2) архитектура должна быть хорошей :-)
      В стандартной разработке вы от 1) и 2) спасаетесь качественным предварительным планированием, создаете процессные артефакты и т.д.
      В agile вы разобъете проектную группу на небольшие “agile”-команды и…
      а) добавите короткие итерации для каждой команды (что позволит вам легко синхронизировать работу команд)
      б) таки будете синхронизировать работу команд. Например, выстроите механизмы по передаче “заказов” между командами. Грубо говоря, команде А нужно, чтобы Б сделала изменения в ядре. А “заказывает” работу Б. Соответствующая фича попадает в план итерации команды Б.
      Это очень сильно упрощает работу с изменениями, которые, как говорится, “happens”

      г) Таки займетесь (сюрприз!) качественным предварительным планированием, создадите процессные артефакты и т.д.
      Просто они немного проще и эффективнее, чем это принято за счет как раз “гибкости” отдельных команд и коротких итераций

      Как-то так.

    8. Если интересны детели, то Scrum в больших проектах я рассказывал на AgileSummer. Видео есть на http://agilesummer.org/video

    Leave a reply

    You must be logged in to post a comment.