Как эффективно перейти от концепции к продукту?

Мне трудно различать цели между:

  1. Список функций
  2. Дорожная карта продукта
  3. График выпуска
  4. Управление задачами
  5. План проэкта
  6. и т.п.

Для моей концепции мобильного приложения я использую Trello и Evernote для управления своими идеями/задачами. Я начал выпускать релизы, и пользовательский интерфейс становится все более сложным и т. д. Когда я попытался привлечь друга, чтобы помочь с разработкой, он был полностью потерян относительно того, что планировал, работы, приоритета ошибок и т. д. Я чувствую, что я сделать этот путь сложнее, чем нужно, поэтому я, вероятно, просто где-то пропустил основную концепцию PM. Любые ресурсы были бы замечательными! Спасибо

Ответы (2)

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

Вот ваш ключ. То, что вы сделали, имеет для вас смысл, потому что большая часть этого, вероятно, находится в вашей голове (вы знаете, над чем вы хотите работать дальше, вы знаете, как выглядит «конечное состояние»).

Когда вы расширите свою команду, вам нужно будет стандартизировать некоторые из этих методов, чтобы выбросить их из головы и превратить в процесс. Несколько вещей, которые вы захотите сделать:

Видение продукта

Составьте вместе несколько утверждений, указывающих на то, чего вы пытаетесь достичь в больших масштабах. На что нацелен ваш продукт? Какие проблемы он решит?

Список функций

Более конкретно, чем Видение — каковы отдельные компоненты вашего Продукта? Например, для интернет-магазина функциями могут быть:

  • Корзина для добавления товаров
  • Витрина для просмотра товаров
  • Возможность зарегистрироваться и авторизоваться
  • Автоматические еженедельные электронные письма клиентам и т. д.

Эти функции могут хорошо отображаться в карточках на вашей доске Trello (в зависимости от степени детализации ваших карточек/функций).

Этот список даст вашему другу представление о «кусочках» вашей головоломки, из которых складывается ваше видение продукта.

Приоритизация

В этом может помочь ваша доска Trello. Убедитесь, что он имеет приоритет — карты с наивысшим приоритетом вверху, с самым низким — внизу. Таким образом, ваш друг будет знать, над чем работать дальше.

График выпуска

Вы захотите сообщить своему другу (и спланировать), когда будет следующий выпуск. Какие функции вы собираетесь внедрить в какой выпуск? Релиз назначен на фиксированную дату или зависит от того, когда функции будут готовы? Это то, что будет держать вас и вашего друга вместе, стремясь к этой краткосрочной цели, зная, когда будет следующая большая «веха».

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

Инструменты

Похоже, вы страдаете от отсутствия процесса. Trello и Evernote — очень простые инструменты, они очень гибкие. Они позволят вам делать то, что вы хотите. Это может быть хорошо, но при работе с другими это может стать трудным, если вы не очень хорошо определяете процесс и придерживаетесь его.

Возможно, вы захотите взглянуть на инструмент управления проектами с немного большей структурой, чем Trello, может быть, что-то вроде Rally ( https://www.rallydev.com/ ). К подобному инструменту добавляются накладные расходы, поэтому, возможно, стоит еще раз попытаться определить свои процессы и посмотреть, сможете ли вы быть достаточно дисциплинированными, чтобы заставить их работать в инструментах, которые у вас есть до сих пор. Дисциплина - это главное!

Итак, резюмируя, вот что должно быть в вашем списке TODO:

  1. Создайте видение продукта
  2. Создайте список функций
  3. Убедитесь, что у вас есть процесс расстановки приоритетов
  4. Установите график выпуска и разработайте план выпуска
  5. Найдите подходящие инструменты, которые помогут вам управлять описанными выше процессами

Если вы сделаете это перед своим другом, я думаю, вы обнаружите, что общее видение/цели/планы/приоритеты значительно облегчают вам задачу.

Я настоятельно рекомендую посмотреть в Story Maps . Это очень простой и понятный способ создать справочную информацию об общем виде программного продукта, целях, выпусках, рисках и т. д.

Спасибо за этот совет. Есть ли у вас какие-либо предложения для чтения, кроме лучших хитов, которые я найду в Google?
«Карта пользовательской истории» Джеффа Паттона — надежный ресурс. До того, как я прочитал это, я применял картирование несколькими различными способами (часто «на полпути» с лишь частичными преимуществами), но я получил много хороших советов из этой книги, которые улучшили наше использование карт — выполнение последующих проходов с разными точками обзора или « объективы», разбивая его на цели и т. д. Существует множество вариантов этого подхода, поэтому обязательно прочитайте как можно больше и подумайте об их преимуществах по сравнению с вашим контекстом. Удачи!