• Интервью с Сергеем Архипенковым

    Posted on October 17th, 2008 Александр Орлов 4 comments

    Когда-то давно я публиковал ссылку на отличную книгу Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Кстати говоря, с тех пор книгу скачали около 2500 раз, что, скажем прямо, много. :)

    Сергей с тех пор сильно продвинулся в сторону тренингов – он читает много открытых курсов – подробнее можно почитать у него на странице.

    Ну и как-то так получилось, у нас выдалась свободная минутка и мы решили сделать с Сергеем мини-интервью. Темы обсуждались вот какие:

    • Надо ли исправлять “неправильных” людей?
    • Почему хорошо управляемый проект может быть выполнен командой обычных исполнителей?
    • Важно ли уметь говорить на одном языке с инженерами?
    • Качества и навыки успешного проджект менеджера
    • Ключ к мотивации людей
    • Стоит ли портить человечские отношения из-за работы
    • Как оценить перспективность проекта и причем тут Word 5.0?

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

     

    4 responses to “Интервью с Сергеем Архипенковым”

    1. Здравствуйте, Александр!

      Давно и с интересом читаю Вашу рассылку. Интервью с Сергеем Архипенковым дало конструктивный повод познакомиться и завязать диалог.

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

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

      Меня «зацепил» вопрос «Почему хорошо управляемый проект может быть выполнен командой обычных исполнителей?». Собственно даже сам вопрос уже достаточно вызывающий (поймите меня правильно ?). Резанул глаз термин «обычный исполнитель». В моем понимании исполнитель может быль или квалифицированным (и тогда можно говорить о степени квалификации), или нет. Неквалифицированным специалистам в команде не место. А вот квалифицированные… Разве могут они быть «обычными»? Возможно, в моей практике было слишком много положительного опыта, но я, как менеджер, подразделяю квалифицированных исполнителей на 3 больших категории: начинающий (достаточный уровень квалификации, малый уровень опыта), профессионал (богатый и разнообразный опыт разработки), профессионал высокого класса (профессионал, способный генерировать решения с показателями выше средних: разработка за очень коротки срок, эффективное решение задач повышенной алгоритмической сложности и т.д.). В нашей компании существует практика называть специалистов всех этих категорий разработчиками (даже если начинающие тяготеют к чистому кодингу, а профессионалы высокого класса – к дизайну систем). Может быть от того, что ни в одной из этих категорий я и мои коллеги не видим места «обычности» (безынициативности, труднообучаемости, невовлеченности)?!

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

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

      Трудно оспорить сравнение разработки ПО с постановкой спектакля. Параллель между актерами и разработчиками вполне очевидна. И, конечно, трудно сравнить работу актера/разработчика с трудовой деятельностью, скажем, плиточника (хотя… ?). Но вот в деятельности театрального режиссера и менеджера любого инженерного проекта (в том числе и строительного), я не наблюдаю особо значимых различий. Те же функции постановки задач, контроля исполнения и соотношение с бюджетом и сроками.

      На мой взгляд, деятельность менеджера, как раз ближе к профессии, чем к искусству (в отличие от деятельности разработчика ПО). «Ближе» не означает абсолютного соответствия. Успешный менеджер в любом направлении – это всегда комбинация хороших профессиональных навыков с мощным творческим потенциалом. Но менеджерами не рожаются – ими становятся (чему целиком и полностью посвящена Ваша рассылка, Александр). И сравнение управленческих практик, применяемых в разных проектах (и даже в разных предметных дисциплинах) – это один из самых эффективных способов обучения, на мой взгляд. Так что я бы сравнивал нас, грешных, и с судостроителями, и с пищевиками ?. Главное, чтобы объекты сравнения были достойными!

      И напоследок о том, чего в интервью я не увидел, а хотелось бы… Много было сказано об отношениях менеджер – команда. Безусловно, это наш повседневный хлеб и мы (менеджеры) не можем об этом не говорить. Однако, есть еще немаловажная составляющая нашей деятельности – общение с заказчиком, с постановщиком задачи, с приемщиками… Зачастую давление с этой стороны является определяющим для менеджера. Имеются ли у Серегя поучительные принципы на этот счет?

      С уважением,
      Арефьев Александр

    2. Александр, спасибо за интересный комментарий и за теплые слова про рассылку и сайт. :)

      Думаю, что Сергей здесь же ответит грамотно, интересно и подробно, как он всегда обычно делает. :) Но чуть попозже – сейчас, говорит, плотно загружен.

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

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

      В моем опыте во всех командах, где я был, и которыми я руководил – всегда были суперзвезды, которые не обычные исполнители. И как можно жить без них я не очень понимал – отсюда был и вопрос Сергею. :)

      Сравнивать управленческие практики и дальше будем стараться – я очень люблю заглянуть к “соседям” и посмотреть как у них. :)

    3. Здравствуйте Арефьев Александр!

      Вы писали:

      > Меня «зацепил» вопрос «Почему хорошо управляемый проект может быть выполнен командой обычных исполнителей?». Собственно даже сам вопрос уже достаточно. Резанул глаз термин «обычный вызывающий поймите меня правильно исполнитель». В моем понимании исполнитель может быль или квалифицированным (и тогда можно говорить о степени квалификации), или нет. Неквалифицированным специалистам в команде не место. А вот квалифицированные… Разве могут они быть «обычными»?

      Александр, спасибо, что Вы внимательно прочитали интервью и нашли время поделиться своими мыслями.

      Что касается «обычных исполнителей». Здесь просто ошибка. Саша неверно меня процитировал, а я это попустил. Правильная цитата «обычные разработчики»: программисты, аналитики, тестиовщики и др. Должны ли они быть квалифицированными? Безусловно!

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

      > Трудно оспорить сравнение разработки ПО с постановкой спектакля. Параллель между актерами и разработчиками вполне очевидна. И, конечно, трудно сравнить работу актера/разработчика с трудовой деятельностью, скажем, плиточника (хотя… ). Но вот в деятельности театрального режиссера и менеджера любого инженерного проекта (в том числе и строительного), я не наблюдаю особо значимых различий. Те же функции постановки задач, контроля исполнения и соотношение с бюджетом и сроками.

      Что касается аналогий, то я против того, чтобы прогрммостроение сравнивать с отраслями материального производства. Путь от идеи до ее реализации в этих отраслях выглядит следующим образом: НИР-ОКР-завод. В верхней части этой пирамиды находятся отраслевые НИИ, которые производят идеи и занимаются проектированием новых изделий. На втором этаже пирамиды работают конструкторы в конструкторских бюро, в задачу которых входит реализация нового проекта в чертежах деталей и технологиях изготовления и сборки. На нижнем уровне находятся производственные мощности – заводы, на которых инженеры и рабочие воплощают «в железе» чертежи и технологии.

      Если проводить аналогию, то программисты работают исключительно на вершине описанной пирамиды. Программирование – это проектирование и только проектирование. Роль конструкторского бюро для программного проекта выполняют компилятор и сборщик программ. А программистским аналогом завода, который переводит конструкторскую документацию в продукт, доступный потребителю, служит вычислительный комплекс, на котором выполняется созданная программа.

      Так что, для меня самая близкая аналогия это производство художественных кинофильмов, где наличие даже самых звездных актеров не обеспечивает успех, а талантливый режиссер может создать отличное кино с командой студентов, например Н.Михалков и к/ф «Свой среди чужих, чужой среди своих».Главная задача режиссера и менеджера программного проекта сплотить вокруг себя эффективную самоорганизующуюся и самоуправляемую команду.

      > Однако, есть еще немаловажная составляющая нашей деятельности – общение с заказчиком, с постановщиком задачи, с приемщиками… Зачастую давление с этой стороны является определяющим для менеджера. Имеются ли у Серегя поучительные принципы на этот счет?

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

      Извиняюсь за пространные ответы. Просто, затронутые вопросы для меня очень важны.

      С уважением,
      Сергей Архипенков.

      Успехов.

    4. [...] Интервью Сергея Архипенкова сайту happy-pm.com [...]

    Leave a reply

    You must be logged in to post a comment.