суббота, 17 декабря 2011 г.

Конференция Яндекс.План-Б

Сегодня побывал на конференции Яндекс.План Б. Хочу поделиться своими заметками и комментариями по докладам, которые довелось послушать:
  1. "Фэйлы внедрения планирования" (Роман Чернин)

    В итоге доклад был совершенно не связаны с этой темой, о чем Роман и предупредил. Типа "планы изменились". :)
    Речь, в общем, шла о том, что в продуктовой разработке, по большому счету, нет ни сроков, ни заказчиков, ни требований. Как это решать? Яндекс для этого выделяет отдельных Product Manager'ов. Эти самые Product Manager'ы и берут на себя роль заказчиков, и именно в их ведении оказывается конечный результат. Так, чтобы работа разных команд сошлась в одном едином продукте, который понравиться бы пользователям. Лично я с такой системой знаком не понаслышке. И в ней очень важно, чтобы этот самый Product Manager сам четко понимал, что он хочет получить на выходе, и кому всё это надо.
  2. "Framework для планирования проекта с точки зрения менеджера продукта" (Ольга Павлова)

    Доклад и сам стиль презентации заставили проснуться всех тех, кто еще этого не сделал. Основные тезисы, которые я для себя отметил:
    • "Управление продуктом - это управление мечтой заказчика". И результатом работы должно быть именно воплощение этой мечты.
    • "Точных формулировок не бывает" - как бы вы не пытались формулировать изначально, все равно получиться не то, что хотел заказчик. Чтобы в итоге удовлетворить заказчика, надо ему показывать промежуточные результаты. Но результаты должны непременно соответствовать уровню интеллекта заказчика.
    • "Делаем игрушки" - т.е. в процессе работы для демонстрации заказчику нужно создавать игрушки, которые бы он понял. Для одних это могут быть прототипы, для других скетчи, а кому то, может, и диаграмм Ганта будет достаточно.
    • "Работа менеджера - отвечать на вопросы" - т.е именно PM должен знать что, зачем и почему делается, и что будет дальше.
    • "Сроки часто срываются из-за того, что в них не закладывается время на согласование".
    • "Не нужно бояться делать на выброс" - не стоит пытаться дождаться ситуации, когда все станет понято, и лишь тогда начинать. Начинать надо сразу, и прямо сразу показывать полученые прототипы. Да, многие из них будут выброшены, но именно так удастся лучше и быстрее понять, что же все-таки хочет заказчик.
    • "План проекта не лестница, а лабиринт"
    • Обсуждения должны вестись с разработчиками. Не планируите в одиночку. Каждый специалист должен вносить свою часть в план.
  3. Полёт на Марс, или как не обидеть слона (Георгий Липатов)

    • "Нельзя ставить слишком жесткие сроки"
    • "Большинство разработчиков хотят делать хорошо. Надо лишь дать им такую возможность"
    • Тестирование должно быть сосредоточено внутри команды, и быть единым процессом с разработкой. Люди делают одно дело, на общее благо, и не должно быть эффекта противостояния.
    • Разработчики в идеале должны работать на FullTime на один проект.
  4. "Планирование аналитической части проекта" (Иван Потапов)

    Лично на мой взгляд, самый скучный доклад из тех, что я слышал, сводящийся к одной фразе "аналитики должны анализировать". Возможно там была какая-то специфика, связанная с аутсорсингом, но лично я для себя кроме фразы "во всем виноваты аналитики" ничего более не вынес.
  5. "Изменение процессов планирования в растущей команде тестирования" (Станислав Комарницкий )

    Очень интресный доклад об организации тестирования в Яндексе. Поразило отношение количества разработчиков к количеству тестеров: 10 к 1. Интересный подход с тем, что тестеры это что-то вроде пограничного пункта. Границу можно перейти в другом месте, но при этом тестеры ответственность за результат не берут.
    Лично мое отношение, что тестеры в принципе не должны брать на себя ответственность за результат, они лишь помогают своим опытом и силами найти то, что не нашли разработчики.
  6. "Трудности планирования в удаленных и географически распределенных командах" (Дмитрий Григорьев)

    Впервые слушал рассказ о команде, где люди работают в разных странах, часовых поясах, и даже никогда не видели друг друга. И судя по докладу автора у них получается вполне хорошо координировать работу 60! человек. При этом они не требуют одновременного online'а всей команды.
    Еще удивило то, что они учитывают время работы (выполнения конкретной задачи) каждого сотрудника с точностью до 10 минут.

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

    • "Команде должно быть удобно работать"
    • "Команда должна быть в курсе происходящего в проекте"
    • 3 горизонта планирования: "Хотелки" , "Описания", "ТЗ". Т.е. в горизонте на год у нас приоритезированые "Хотелки", в 3х месячном горизонте они обрастают описаниями, которые в месячной перспективе в результате обсуждении с командой превращаются в "ТЗ". Яндекс использует для хранения результатов обсуждений Wiki.
    По каждому проекту есть некая страничка, где одним взглядом можно понять всё: над чем работаем сейчас, что будем делать, где найти всю инфу. При этом команда Михаила не использует TDD и Code Review и, я так понял, особо не страдает.
  8. "Планирование в распределенных командах" (Мария Петрова)

    Еще один опыт распределенных команд.
    • "В распределенных командах не должно быть испорченного телефона" - именно по этому все разговоры и все общение жестко фиксируется в вики или письмах, иначе потом концов не найти.
    • "Люди сами себе назначают сроки" - когда человек сам говорит, что он это сделает за какой-то период времени, то винить ему потом некого.
    • "Доверие" - очень важный аспект работы любой команды.
    • "Есть люди, которые в принципе не могут работать удаленно".
    • "Собеседовать человека удаленно не получается" - по опыту Марии, проще слетать в командировку, чем через некоторое время уволить человека. Данный тезис несколько противоречит утверждениям Дмитрия Григорьева, но у каждого свой опыт.
Увы, после этих долкладов я вынужден был покинуть эту конференцию, и вторую часть, где были интерактивы, я уже не посетил. Резюмируя, конференция мне понравилась. Основными докаладчиками были именно менеджеры, а уж они говорить умеют много, долго и красиво, потому скучно не было.

Спасибо Яндексу за это. :)

1 комментарий:

Eduard Kibort комментирует...

Общался в кулуарах с Мишей Карповым. Чаще в Яндексе роли Product Manager-а и Project Manager-а выполняет один человек. И в команде Миши TDD действительно не используют, а вот Code Review в полный рост и люди позитивно к этому относятся.