Я использую Gitlab в качестве инструмента управления продуктами для 3 продуктов уже почти 2 года. На первый взгляд похоже на Trello. Однако, если вы улучшите свой способ его использования, вы в конечном итоге станете больше, чем владельцем/менеджером продукта. Я объясню, как.
Как владелец продукта, ваша основная обязанность — создавать функции, повышающие ценность бизнеса компании с минимальными усилиями и временем выполнения заказа. Когда клиент описывает бизнес-потребность, если вы не знаете, в какой степени нуждается ваш продукт в разработке, вы зайдете в тупик. Вы должны были попросить команду разработчиков ответить, сколько времени у вас должно быть на запуск этой функции. Это становится намного сложнее, если потребность заканчивается несколькими продуктами.
Gitlab позволяет вам увидеть полную программную архитектуру вашего продукта и то, как он связан с бизнесом. Продукт содержит API, BFF, UI, потребителя и фидеры. Иногда он собирает бизнес-данные с серверов SQL и NoSQL. Если вы не знаете, сколько проектов GitLab вы должны затронуть, чтобы развернуть функцию перед анализом, вы не сможете фактически ответить на вопросы своих клиентов и предложить им различные решения для их нужд.
Когда вы расставляете приоритеты, вы должны учитывать как архитектуру программного обеспечения, так и цели ваших клиентов. Клиентам не нужно знать, сколько потребителей вы должны написать, или вам нужна новая конечная точка в API, если достаточно добавить новое поле в конечную точку вашего API, или является ли ваш процесс обработки данных асинхронным или синхронным. Им просто нужно знать, когда вы предоставите функцию или ответите на их потребности. Что такое время выполнения…
Мы начали использовать GitLab просто для того, чтобы попробовать. Долгосрочный результат потрясающий. Это чистая прозрачность. Мы открываем наши бизнес-истории на пустом проекте (продуктовом бэклоге) на GitLab. Пока мы делаем технический анализ, мы открываем наши задачи по API, BFF, потребителю, фидеру и любому проекту, который нам нужно решить. Мы напрямую связываем наши задачи с бизнес-историей, которая включает только пользовательскую историю и критерии приемлемости.
Результат таков: вы привыкли к отношениям между бизнесом и архитектурой. Разговаривая с клиентом, вы знаете, сколько вам нужно шансов, чтобы добавить новую функцию поверх нее. Вы угадываете, сколько очков истории вам нужно потратить на эту функцию, каково будет ваше время развертывания в продукте.
Реальный пример выглядит следующим образом
Бизнес-потребность: мы хотим перенаправить наших продавцов на сайт партнеров по решениям одним щелчком мыши в кампании.
Это бизнес-требование приводит к 3 пользовательским историям и нескольким критериям приемлемости.
Первое: кто будет добавлять гиперссылку, как добавить гиперссылку, где добавить гиперссылку
Второе: кто увидит гиперссылки, как направлять гиперссылки, где показывать гиперссылки
Третье: как мы измеряем потенциальных клиентов с помощью функции «подать заявку сейчас»
Эти 3 пользовательские истории касаются нескольких проектов API, BFF и пользовательского интерфейса. Но в итоге вы будете оценивать задачи, а не пользовательские истории. Пользовательские истории — это сумма очков историй задач.
В соответствии с этим наша команда разработчиков могла развернуть эту функцию в рабочей среде за 3 дня.
Прозрачность позволяет вам планировать спринт и то, как бизнес-требования могут повлиять на ваш следующий спринт. Насколько мало шансов/функций изменить дорожную карту продукта. И это позволяет вам, когда появляется новый проект, разделить на этапы. И вы улучшите себя, прислушиваясь к требованиям бизнеса. Вы просто прилагаете к этому среднее техническое усилие.
