За последние 10 лет работы в качестве QA, бизнес-аналитика, продакт-оунера, продакт менеджера, а также ментора, я получил бесценный опыт, которым хочу поделиться.
Важность онбординга недооценивается
У каждого продукта и проекта должен быть онбординг для новоприбывших. Особенно, если проект крупный. Это очень помогает в долгосрочной перспективе.
Это должен быть хорошо продуманный документ, постоянно обновляемый вами и коллегами. Новые ребята также должны иметь кого-то, кому они могут задавать вопросы.
Кроме того, важно иметь процесс, который поможет убедиться, что адаптация прошла успешно, и не проигнорирована. Это может быть беседа, или, например, опросник в Google Forms, Typeform, Survey Monkey.
Тайм-менеджмент важен для всех
Всегда имейте список задач под рукой. Это может быть блокнот и ручка, но лучше использовать такие инструменты как Notion.
Нет оправдания не проверять почту в рабочее время. Но имейте в виду, что у любого человека есть как минимум 24 часа, чтобы прочитать и ответить на несрочные электронные письма.
Используйте свой календарь и будильник, чтобы получать напоминания о важных встречах, time tracking, и проверке электронной почты.
Уважайте календарь других. Всегда проверяйте, доступны ли ваши коллеги, прежде чем приглашать их.
Нон-стоп митинги приводят к стрессу и снижению эффективности, это доказано научно. Поэтому старайтесь планировать митинги так, чтобы между ними были перерывы.
Объясняйте свое решения
Предположим, вы приняли важное решение, которое касается функционала продукта. Важно объяснить всем затронутым командам, какие у вас были аргументы и данные, какие исследования вы проводили, какие альтернативы вы рассматривали и почему вы выбрали тот или иной вариант. Особенно для непростых решений.
Привлекайте своих товарищей по команде к обмену отзывами
Спросите товарищей по команде, что они думают о той или иной фиче или решении. Но спрошивайте их не только как профессионалов, но и как обычных людей, например: «Как думаешь, эта фича зайдёт юзерам?».
Поговорите с неразговорчивыми коллегами лично, т.к. они могут не сказать публично того, что на самом деле думают.
Не забывайте о саморазвитии
Если вы не изучите основы своей ИТ-сферы, если вы не будете следовать тенденциям, вы будете изобретать колеса и, в конце концов, облажаетесь. Или вас обгонят более молодые, мотивированные и наглые коллеги. Так что вы должны постоянно учиться, ломать стеклянные потолки, расширять свои границы и убивать свои страхи. Последовательное личное развитие поможет вам чувствовать себя более уверенно и принимать более взвешенные решения. Кроме того, новый скилл или сертификат может стать поводом поднять вам зарплату :)
Менторинг — еще один способ узнать что-то новое и освежить собственные знания. Потому что чтобы кого-то чему-то научить, нужно сначала самому глубоко изучить тему.
Рекомендации по выходу из проекта
Обязательно оставляйте после себя:
Документ со всеми ссылками, контактами и советами, которые понадобятся новичку. Это действительно помогает и ценится;
Хорошее впечатление. Устройте вечеринку или хотя бы теплое прощальное письмо. Скажите всем «спасибо» и похвалите тех, кто это заслужил.
Наследие. Выложите свои советы, шаблоны и другие полезные вещи во внутреннею базу знаний. Если у вас её нет, создайте его сейчас. Экспертиза не должна исчезнуть вместе с вами.
Налаженные процессы. Все должно работать и без вас. Команда, атмосфера, проект, продукт и клиенты не должны сильно пострадать.
Лучшие практики по выходу в отпуск или на больничный
Если вы лид и уезжаете в отпуск или идёте на больничный, то убедитесь, что кто-то будет выполнять вашу роль пока вас нет. Поэтому обязательно предоставьте доступ ко всем необходимым документам, ресурсам и митингам.
Обязательно разъясните обязанности своему заместителю. Лучше всего поговорить с ним/ней лично и ответить на вопросы. Не забудьте после встречи отправить ему/ей email c инструкциями.
Отслеживайте, поддерживайте и документально утверждайте требования
Meeting notes c action items спасут ваc. Много раз. Не пренебрегайте ими. После каждого митинга оставляйте себе в календаре 10 минут на то, чтобы сразу же выслать meeting notes;
Используйте traceability matrix, чтобы проверить что ничего не забыто и всё покрыто. Например, что все бизнес-требования были покрыты юзер сторями, функциональными требованиями и тестами. Или чтобы убедиться, что та или иная сторя трассируется на бизнес-правило или change request, а не выдумана дизайнером или тестировщиком из ниоткуда;
Настаивать на официальном утверждении (sign-off) требований. Иначе заколебётесь потом разгребать "а мы же говорили..." и "мы не это имели ввиду...";
Убедитесь, что у проекта есть roadmap (не путать с gantt chart), доступный для всех членов команды и заказчиков;
Требования должны быть дополнены диаграммами, таблицами, схемами и т. д. Мои любимые — это use-case диаграмма, flowchart, BPMN 2.0, диаграммы состояний и dialog map. Использование нескольких способов описания требований помогает выявить упущенные требования и edge cases.
Данные на первом месте
Не поддавайтесь авторитету и самоуверенности своего заказчика или коллеги. Уважайте чужое мнение, но дайте понять, что он/она не может знать пользователей. Без данных и исследований все, что мы знаем, — это предположения (assumptions). Одна объективная метрика или исследование лучше, чем 10 субъективных мнений.
Soft skills и коммуникации
Хвалите своих коллег;
Прежде чем задавать миллионы вопросов, потратьте какое-то время, чтобы самому попытаться разобраться в вопросе;
Не просите разработчиков или кого-либо другого делать вашу работу;
Не нарушайте субординацию без веской причины или разрешения;
Будьте очень кратки с топ-менеджерами компании. Говорите с ними на языке бизнес-ценности и прибыли;
Уважайте культуру других;
Никакие зумы и коллы никогда не заменят по эффективности физическое общение;
Проводите время с коллегами после работы;
Если у вас конфликты с коллегами, убедитесь, что проблема не в вас самих. Помните, что и вы, и ваши коллеги на одной стороне, а проблема всегда на другой стороне;
Критикуя предлагай.
Если вы BA/PO/PdM, то не говорите разработчикам, как кодить. Не говорите дизайнерам, как дизайнить. Не говорите тестировщикам, как тестить. Дайте им контролируемую свободу. Но обязательно обратите внимание на то, какие есть ограничения, кто является целевой аудиторией, какие есть приоритеты для бизнеса, и зачем пользователь хочет выполнять ту или иную задачу.
Всегда будьте готовы признать, что были неправы.
