• 5 разных Вась

    Posted on June 22nd, 2008 Александр Орлов 14 comments

    Людей все время классифицируют. Товарищ Юнг и семья Майерс Бриггс, например, продвинулись довольно сильно. Однако, как менеджеру мне наиболее интересно смотреть на людей с точки зрения добровольного взятия ответственности на себя.

    Вот например, приходит менеджер к программисту и говорит:

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

    И тут возможны различные типы Вась.

    Вася №1. Вася кладет примерно 200 г на менеджера и проблему. Менеджер либо забывает, либо потом напоминает, на что всегда есть отмазка (“а ты же не сказал, к какому сроку”, “а я посмотрел, но там что-то непонятное”, “а я как раз собирался в феврале посмотреть”,..)”.

    Вася №2. Вася смотрит, обнаруживает, что проблема в его коде. Проблему устраняет.

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

    Случай №1 рассматривать не будем – тут все понятно. Васю по какому-то недоразумению все еще не уволили. Самое время.

    Случаи №2 и №3 – все ли хорошо? С одной стороны, вроде да. С другой стороны, как могло бы быть лучше?

    А лучше могло бы быть так.

    Продвинутый Вася №2. Вася смотрит, обнаруживает, что проблема в его коде. Проблему устраняет. После чего:

    • Быстренько проводит расследование, почему эта проблема не вылезла на более раннем этапе?
    • Кумекает, что можно подкрутить и соптимизировать. чтобы избежать таких проблем в будущем?
    • Обсуждает с менеджером, чего он (Вася) накумекал и нарасследовал.
    • Вносит изменения в работу, скрипты и прочая и прочая.

    Продвинутый Вася №3. Вася смотрит, обнаруживает, что проблема не в его коде. Находит человека, в чьем коде проблема и передает проблему ему. После чего время от времени справляется, как там решение проблемы. Менеджер находится в копиях писем.

    Что объединяет продвинутых Вась? Две вещи:

    • Если менеджер приходит к ним с проблемой, они стараются довести ее решение до конца. Сами. В любом случае.
    • Они выходят за рамки своих обязанностей. Тем, что дергают других людей, кто может помочь решить проблему. Тем, что думают, что и как сделать, чтобы таких проблем больше не появлялось.

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

    Ну что, пойдем выйдем? :)

     

    14 responses to “5 разных Вась”

    1. Этот конструктивизм универсален:))

    2. Саша, а ты много встречал таких прогрессивных вась за свою карьеру?

    3. 2 ugrimoff – однозначно!

      2 Kostya – довольно много. Особенно среди зарубежных коллег. Но и среди наших – довольно много. Процентов 10-20, в среднем. :)

    4. Как показала моя практика – продвинутые Васи не всегда нужны.
      И выход за пределы свой сферы ответственности не всегда приветствуется.
      Иногда за это бьют по башке.
      Больно.

    5. [...] поводу статьи про разнотипных Вась поступило замечание от слушательницы. В том духе, что [...]

    6. Еще бывает – сидит старший программист, выполняет сложный проект. А его дергают все подряд, потому что знают, что он крут. В результате, старшему сложно сосредоточиться на проекте и проект не поспевает к сроку. Тут получается, что дерганье не очень хорошо. Надо сначала дернуть менеджера, наверное, чтобы сказал к кому обратиться?

    7. Про Вась 2, 3 — согласен.

      Про №1 нет:

      1. Если есть CI, то программист и без менеджера знает, что упали тесты.

      2. Если есть политика по исправлению упавших тестов, то программист знает что и когда ему по этому поводу делать и без дополнительного вмешательства менеджера.

      3. Программист не сидит с мыслью “чем же заняться?” (если так, то это большой вопрос к менеджеру), а значит чем-то занят. Менеджер должен явно указать какой приоритет у новой задачи, иначе это выбор программиста. В этом случае “собирался посмотреть в феврале”, “посмотрел быстро, но там что-то непонятное и надо долго разбираться” совершенно корректные ответы.

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

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

      Еще один фактор: менеджер все-таки заранее должен знать как давать задание конкретному программисту, чтобы оно было выполнено.

      Если же конкретизировать исходную ситуацию (менеджер устно что-то сказал разработчику, через некоторое время случайно вспомнил, поинтересовался и узнал, что задачей не занимались), то вывод о том, что виноват прежде всего разработчик и его надо уволить выглядит просто дико.

    8. CI – дело хорошее, но тесты бывают разные. Иногда тест приходит от кастомера.

      Политики – дело тоже такое, что если они есть, все их прочли, усвоили и следуют – и отлично. Но в жизни часто встречаются перекосы… ладно, суть, конечно не в этом. :)

      Суть в том, что менеджер, который ставит нечеткие цели, конечно тоже не всегда хорош. Четкость постановки целей, во-первых, должна соответствовать уровню подчиненного.

      А во-вторых, подчиненный должен ей соответствовать. :) В примере №1 подчиненный понимал, что цель поставлена нечетко, ино намеренно не стал ее уточнять, чтобы не делать лишней работы. И это плохо, на мой взгляд.

    9. Еще много могу написать на эту тему, но, если кратко, то:

      1. Программист не помог менеджеру. Причин может быть громадное кол-во (как уважительных, так и неуважительных). Надо смотреть подробно. Но максимально возможное наказание — непродвижение дальше в сторону менеджера, т.к. это ошибка управления проектом (выбрал не тот порядок задач).

      2. Если подчиненный понимал, что цель поставлена нечетко, то это же понимал и менеджер. Зачем он тогда так ее поставил? Хотел подставить подчиненного или переложить ответственность за то, что надо делать сейчас?

      В общем, явная вина менеджера в обсуждаемом эпизоде, детали лишь показывают степень.

      PS. Очевидно, что тесты (ошибки?) от клиентов можно пропускать через баг-трекеры, чтобы не забыть.

    10. Еще немного с другой стороны:

      1. Основная задача менеджера — коммуникации, именно в них провал.

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

    11. Ну, то есть, если программист _намеренно_ кладет на задачу, которую ему выдал менеджер, то можно сказать, что менеджер виноват в том, что плохо проконтролировал. Ну да, можно.

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

      Требовать от программиста большей организованности по задачам, чем у менеджера можно, но странно.

      Виноватых пачка (программист, менеджер, руководство менеджера), но в большей степени сам менеджер.

      Естественно, если программист _систематически_ делает не то, что ему сказали, то это повод задуматься об увольнении. Но никак ни разовый случай.

    13. Ну да, намеренность может быть выяснена только потом. Когда симптомы будут повторяться. Уверен, что поработав с командой какое-то время (полгода хотя бы) вы уже с уверенностью сможете сказать, кто к какому типу принадлежит.

    14. Перечитал свой пост еще раз. :) На тему того, где я требую от программистов большей организованности, чем у менеджера. Вроде не требую. Просто говорю, с какими людьми приятно работать.

      В общем, да, бывали случаи, когда что-то выпадало из моей головы. И было очень приятно, что из головы моего сотрудника это не выпадало.

    Leave a reply

    You must be logged in to post a comment.