Задать вопрос
@Kirill-Gorelov
С ума с IT

Баланс между клиентами и функционалом софта?

Есть софт, продаю.
Софт естественно из b2b. И естественно спрашиваю у клиентов, что им нужно, самому выдумывать так себе идея.

Приходят новые клиенты и говорят, что не хватает какого-то определенного функционала и у старых клиентов появляются аппетиты и тоже просят доработок. Все доработки и новый функционал делается бесплатно и раскатывается на всех клиентов.

Собственно вопрос.
Как правильно лавировать между хотелками клиентов и своим тех долгом и своими идеями?
У меня кроме как решения: сначала идут хотелки клиентов, свои идеи последними

Как мне кажется, что на первых парах, норм. Но если клиентов станет сотня, то все это будет проблематично....
И еще важный момент, хоть хотелки их аргументированы и имеют свой смысл, но что если они слишком специфичные или идут наперед моего плана развития софта?
  • Вопрос задан
  • 436 просмотров
Подписаться 3 Простой 4 комментария
Решения вопроса 4
newross
@newross
Product owner
Если не хочешь превратить продукт в хаос, то вводи полноценную систему развития продукта:
1. Зарегайся в сервисе типа https://www.productboard.com/
2. Заведи туда все хотелки клиентов и фидбэк, слинкуй хотелки с фичами и фидбэком
3. Оцени фичи с точки зрения прибыльности и усилий на реализацию, если правильно все слинкуешь, у тебя будет данные какие конкретно клиенты просили какую фичу, размер клиента и выручки от него.
4. Учти исключения, например, якорный клиент хочет какую-то фичу надо выкатить ее чтобы он остался
6. Подготовь роадмап с учетом полученного рейтинга фич и приступай к реализации.

Главные моменты:
- Делай только то, что значительно увеличивает выручку\снижает затраты\снимает тех ограничения
- Всегда оценивай как кастомизация под конкретного клиента повлияет на продукт в целом. Иногда лучше не делать кастомизации
- Мелкие хотелки мелких клиентов идут мимо
- Очередность поступления запросов не должна влиять на твои решения
Ответ написан
Комментировать
Ну как владелец ПО ты должен вести какую-то стратегию развития.

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

Правильно делаешь, что задумался.
Тут у тебя два варианта:
1. Удовлетворять хотелки в исходном виде.
2. Использовать "хотелки" только как сигнал о проблеме/задаче. А способ решения придумывать самостоятельно.

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


Как правильно лавировать между хотелками клиентов и своим тех долгом и своими идеями?
У меня кроме как решения: сначала идут хотелки клиентов, свои идеи последними

Ну тут у тебя два варианта:
1. Тот что ты назвал - хотелки клиентов вперёд.
Так у тебя будет меньше времени на техдодг и рефакторинг. Да и свои идеи ты откладываешь на потом. Что делать, если эти отложенные идеи должны повысить привлекательность софта в глазах новых клиентов?

2. Искать баланс. Например, если ты работаешь по скраму - ты можешь в спринт брать N задач на новые фичи от клиентов, M задач на новые свои фичи, X задач на баги, Y задач на техдодг.
Либо можешь по расписанию устраивать "инженерные спринта" или "спринт на баги".
Подобное можно реализовать и без спринтов, но сложнее.


Как мне кажется, что на первых парах, норм. Но если клиентов станет сотня, то все это будет проблематично....

Ну ты как минимум не сможешь их все исполнять сразу и тебе придётся их записывать и выставлять приоритеты.
Ответ написан
Комментировать
firedragon
@firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
Нам нужен план! (С) Илон Маск

Итак логично что хотелки платные, так же логично потестировать итак делаем следующее:

Основная часть клиентов идет на сайт site.com - стабильная версия
Часть клиентов идет на сайт beta.site.com - тут самый хардкор, но и самые новые плюшки
Часть клиентов идет на сайт clientname.site.com - тут плюшки конкретно под него

Далее вы разделяете версии на ветки нужно кстати держать это под контролем не более 2 мажорных веток.
2.0
2.1
2.2
Кстати этот пункт опциональный

хотелками клиентов и своим тех долгом и своими идеями?


откатываете на бете и на clientname и потом перетаскиваете на основной.

И да за тех долг вам не платят!
Ответ написан
@nolotion
Все вопросы хорошие и правильные, и однозначного ответа на них нет. Похоже, пришла пора познакомиться с product management, почитать книжки по продуктовой разработке, глянуть какие-нибудь курсы.
Если в двух словах - вам поможет видение и приоритизация.

Как правильно лавировать между хотелками клиентов и своим тех долгом и своими идеями?

Приоритизацией задач. Единого правильного подхода, конечно же, нет. Выбирайте и адаптируйте под себя и свой продукт.

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

Впиливание штучных запросов от клиентов - это антипаттерн продуктовой разработки. Так лучше не делать.
https://medium.com/the-full-stack-researcher/shoul...
Если фичи бегут впереди паровоза или поперек видения продукта - их тоже лучше не делать.

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

Еще возможно стоить увеличить ресурсы - нанять дополнительно программистов, тестировщиков, сейлзов - чтобы закрывать те процессы, в которых боттлнек.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
phaggi
@phaggi
лужу, паяю, ЭВМы починяю
На мой взгляд диванного аналитика, очередность - в порядке поступления. Вне зависимости от того - ваши это идеи или клиентов. Но учитывать суперкритичные, конечно.

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

Войдите, чтобы написать ответ

Похожие вопросы
04 дек. 2024, в 12:26
5000 руб./за проект
04 дек. 2024, в 12:04
10000 руб./за проект
04 дек. 2024, в 11:57
60000 руб./за проект