Разработчиководство для начинающих продактов

Дистанционная работа над стартапом может быть успешной, если усилия команды сложатся правильно. Но как правильно? Чаще всего я участвую в международных проектах, где соединяю русскоязычную команду разработчиков с американскими заказчиками и инвесторами (я — Product Owner). Работала как в офисах крупных международных компаний, так и на удалёнке в самых разных стартапах. Получила сертификат Project Management Professional от PMI.

Полученным опытом и попробую поделиться. Вот несколько простых практик, которые помогают мне работать с технической командой:

Атмосфера. Стараюсь установить между коллегами уважительные и доброжелательные отношения. Желательно не брать в команду токсичных людей.

Без формальностей. Предупреждаю коллег, что если за ними на экране покажутся дети или домашние животные, то это нормально. Говорю, что не нужно париться по поводу дресс-кода. Стараюсь приветствовать каждого и создавать живое и доброжелательное настроение на встрече.

Вера в людей. Людям нравятся, когда в них видят хорошее. В таком состоянии они способны на великие вещи. Не забываю хвалить и благодарить разработчиков.

Доверие. Если с самого начала набираешь в команду мотивированных профессионалов, следующий шаг — довериться им. Настоящим джедаям нужно доверять, их опыту, ответственности, смекалке, умению оптимизировать и автотестам. Здравый смысл при этом, лучше не отключать.

Зрительный контакт. Я рекомендую всем участникам встреч включать камеру для фокуса на теме разговора. Кому-то сначала неловко, потом всем лучше.

Индикаторы настроения. Важно регулярно разговаривать с членами команды, чувствовать настроение, чтобы мотивировать, избегать подводных камней или внезапного ухода специалиста. Также полезны опросы (обычно использую Typeform или SurveyMonkey). Массовое недовольство или потеря командой веры в проект — страшный сон продакта, порой реальный, особенно на удаленке.

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

Комфортное общение. Разработчикам должно быть комфортно писать ПО, задавать вопросы и обсуждать с мной задачу.

Лишние собеседники. Не зову на встречу всех подряд. Если на встрече участвуют лишь вовлеченные в тему, разговор получается продуктивнее.

Маленькая команда. Позволяет избежать последствий закона diminishing returns (когда рост числа сотрудников не повышает продуктивности).

Обсуждение с техлидом и ключевыми разработчиками бизнес-задачи. Часто позволяет найти эффективный метод её воплощения.

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

Проверенные инструменты для работы. Стараюсь предлагать инструменты знакомые команде. Например: Slack для коммуникации, Jira для постановки и приоритизации задач и Zoom для встреч, Figma для дизайна, Notion для документов. Времени для переучивания или привыкания к новым программам, скорее всего не будет.

Разъяснение. Важно держать разработчиков в курсе происходящего на продуктовом и бизнесовом уровнях проекта.

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

Тайминг звонков. Перед каждой встречей разрабатываю четкий план и повестку созвона. Для каждого участника заранее готовлю вопросы и просьбы. Тогда у всех есть время и возможность высказать своё мнение.

Экономия времени. Отказываюсь от ненужных встреч и разговоров. Как правило, у нас один общий звонок в начале рабочей недели и планирование спринта раз в две недели. Все остальные созвоны — по необходимости.

Ясно поставленные и рассчитанные задачи. Сначала проверяю, доступно ли и корректно ли сформулированы задачи. Затем вместе с командой определяем сроки, роли и порядок их исполнения.

Спасибо за чтение!