• Прижизненное вскрытие

    Posted on July 3rd, 2008 Александр Орлов No comments

    Все, наверное, слышали о такой штуке как ретроспектива. Для тех, кто не слышал, вкратце – это вскрытие состоявшегося проекта по его окончании. Когда собираются все участники проекта и высказываются по темам:

    • Что было хорошо
    • Что было плохо
    • Как можно было бы улучшить в следующий раз

    Основное правило – говорить конструктивно. Целью ретроспективы не является кого-то загнобить. А наоборот помочь всем в проекте работать еще лучше. Что интересно, обычно получается конструктивно. И вообще проходит достаточно интересно. Особенно, если вскрытие производят не только менеджеры, но действительно все сотрудники. Всем нравится быть хозяевами своей судьбы.

    Но поговорить я хотел не об этом, а о немного другой ситуации. Вот, допустим, приходит техлид к менеджеру и говорит:

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

    Палыч молча выслышивает, потом вкрадчиво начинает:

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

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

    Казалось бы все правильно. Палыча можно понять, до релиза месяц, кастомеры уже на подходе, а тут такое. Но есть несколько но.

    Но №1. Палыч не берет на себя ответственности за косяки с проектом в случае провала. В итоге у Коли (и у команды) остается впечатление, что в случае чего, все шишки достанутся им.

    Но №2. Коля приносит проблему с горящими глазами. Ему не терпится взять и накинуться на нее по всем планам, чтобы успеть-таки к релизу ее разрешить. После разрыва у Палыча Коля бредет в свой кубик с мыслями “ну на хрена мне это все?”, обновляет резюме и ставит в МоемКруге галочку “ищу работу”.

    Но №3. В случае появления следующей проблемы, Коля к Палычу уже не идет, а либо А: Пытается втихаря ее разрешить, либо Б: откладывает ее в сторону, надеясь, что ее найдет и понесет Палычу кто-нибудь другой.

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

    Leave a reply

    You must be logged in to post a comment.