Сегодня побывал на конференции Яндекс.План Б. Хочу поделиться своими заметками и комментариями по докладам, которые довелось послушать:
Спасибо Яндексу за это. :)
-
"Фэйлы внедрения планирования" (Роман Чернин)
В итоге доклад был совершенно не связаны с этой темой, о чем Роман и предупредил. Типа "планы изменились". :)
Речь, в общем, шла о том, что в продуктовой разработке, по большому счету, нет ни сроков, ни заказчиков, ни требований. Как это решать? Яндекс для этого выделяет отдельных Product Manager'ов. Эти самые Product Manager'ы и берут на себя роль заказчиков, и именно в их ведении оказывается конечный результат. Так, чтобы работа разных команд сошлась в одном едином продукте, который понравиться бы пользователям. Лично я с такой системой знаком не понаслышке. И в ней очень важно, чтобы этот самый Product Manager сам четко понимал, что он хочет получить на выходе, и кому всё это надо.
-
"Framework для планирования проекта с точки зрения менеджера продукта" (Ольга Павлова)
Доклад и сам стиль презентации заставили проснуться всех тех, кто еще этого не сделал. Основные тезисы, которые я для себя отметил:
- "Управление продуктом - это управление мечтой заказчика". И результатом работы должно быть именно воплощение этой мечты.
- "Точных формулировок не бывает" - как бы вы не пытались формулировать изначально, все равно получиться не то, что хотел заказчик. Чтобы в итоге удовлетворить заказчика, надо ему показывать промежуточные результаты. Но результаты должны непременно соответствовать уровню интеллекта заказчика.
- "Делаем игрушки" - т.е. в процессе работы для демонстрации заказчику нужно создавать игрушки, которые бы он понял. Для одних это могут быть прототипы, для других скетчи, а кому то, может, и диаграмм Ганта будет достаточно.
- "Работа менеджера - отвечать на вопросы" - т.е именно PM должен знать что, зачем и почему делается, и что будет дальше.
- "Сроки часто срываются из-за того, что в них не закладывается время на согласование".
- "Не нужно бояться делать на выброс" - не стоит пытаться дождаться ситуации, когда все станет понято, и лишь тогда начинать. Начинать надо сразу, и прямо сразу показывать полученые прототипы. Да, многие из них будут выброшены, но именно так удастся лучше и быстрее понять, что же все-таки хочет заказчик.
- "План проекта не лестница, а лабиринт"
- Обсуждения должны вестись с разработчиками. Не планируите в одиночку. Каждый специалист должен вносить свою часть в план.
-
Полёт на Марс, или как не обидеть слона (Георгий Липатов)
- "Нельзя ставить слишком жесткие сроки"
- "Большинство разработчиков хотят делать хорошо. Надо лишь дать им такую возможность"
- Тестирование должно быть сосредоточено внутри команды, и быть единым процессом с разработкой. Люди делают одно дело, на общее благо, и не должно быть эффекта противостояния.
- Разработчики в идеале должны работать на FullTime на один проект.
-
"Планирование аналитической части проекта" (Иван Потапов)
Лично на мой взгляд, самый скучный доклад из тех, что я слышал, сводящийся к одной фразе "аналитики должны анализировать". Возможно там была какая-то специфика, связанная с аутсорсингом, но лично я для себя кроме фразы "во всем виноваты аналитики" ничего более не вынес.
-
"Изменение процессов планирования в растущей команде тестирования" (Станислав Комарницкий )
Очень интресный доклад об организации тестирования в Яндексе. Поразило отношение количества разработчиков к количеству тестеров: 10 к 1. Интересный подход с тем, что тестеры это что-то вроде пограничного пункта. Границу можно перейти в другом месте, но при этом тестеры ответственность за результат не берут.
Лично мое отношение, что тестеры в принципе не должны брать на себя ответственность за результат, они лишь помогают своим опытом и силами найти то, что не нашли разработчики.
"Трудности планирования в удаленных и географически распределенных командах" (Дмитрий Григорьев)
Впервые слушал рассказ о команде, где люди работают в разных странах, часовых поясах, и даже никогда не видели друг друга. И судя по докладу автора у них получается вполне хорошо координировать работу 60! человек. При этом они не требуют одновременного online'а всей команды.
Еще удивило то, что они учитывают время работы (выполнения конкретной задачи) каждого сотрудника с точностью до 10 минут.
Опять же мое отношение к удаленной работе неоднозначно. Сужу по себе. Производительность моя дома выше, но сложно обеспечить стабильный рабочий день - слишком много отвлекающих факторов в лице домашних. Касательно же учета времени я вообще резко против. Из моего опыта это вреда приносило больше, т.к. люди не работой занимались, а думали как оправдать время."Планирование для продуктового менеджера" (Михаил Карпов)
- "Команде должно быть удобно работать"
- "Команда должна быть в курсе происходящего в проекте"
- 3 горизонта планирования: "Хотелки" , "Описания", "ТЗ". Т.е. в горизонте на год у нас приоритезированые "Хотелки", в 3х месячном горизонте они обрастают описаниями, которые в месячной перспективе в результате обсуждении с командой превращаются в "ТЗ". Яндекс использует для хранения результатов обсуждений Wiki.
"Планирование в распределенных командах" (Мария Петрова)
Еще один опыт распределенных команд.- "В распределенных командах не должно быть испорченного телефона" - именно по этому все разговоры и все общение жестко фиксируется в вики или письмах, иначе потом концов не найти.
- "Люди сами себе назначают сроки" - когда человек сам говорит, что он это сделает за какой-то период времени, то винить ему потом некого.
- "Доверие" - очень важный аспект работы любой команды.
- "Есть люди, которые в принципе не могут работать удаленно".
- "Собеседовать человека удаленно не получается" - по опыту Марии, проще слетать в командировку, чем через некоторое время уволить человека. Данный тезис несколько противоречит утверждениям Дмитрия Григорьева, но у каждого свой опыт.
Спасибо Яндексу за это. :)