Работаем с рекрутинговым агентством, они как-то с этим справляются. Детали подсказать не смогу, так как это их процесс.
А что касается опыта разработки, если вы говорите о том что он должен иметь опыт написания кода, нет. А вот системное мышление, вот без этого у нас не зедерживаются.
Здесь сильно помогает написание юзкейсов, причем что важно каждый шаг юзкейса нужно максимально упрощать. Например: проверка двух условий, это два шага, а не один как часто делают.
Так вот в таком формате мы описываем основной сценарий, а потом уже идешь по нему и на каждом шаге задаешься вопросом, а что может пойти не так. Таким образом получается выявить большую часть возможных отклонений.
Ну и это работает как для системных требований, так и для бизнес требований.
Со стороны и правда выглядит курьезно, но тут все сильно же зависит от размера продукта и того на какие сервисы аффектит данное изменение. Чем больше продукт, тем тяжелее вносить архитектурные правки.
Плюс уточню, речь не о смене адреса доставки, а именно о сдаче заказа в рандомный пункт.
Да, все верно. Местами процессы именно на это и направлены, чтобы потом не было ощущения что он видит это в первый раз и начинает предлагать как сделать получше “Поиграйтие со шрифтами/цветом/логикой и еще чем-нибудь только поиграйте”
Тут можно долго рассуждать, лично я для себя определяю от цели: Есть аудитория, и хотим на ней больше зарабатывать - пилим маркетплейс. Мало аудитории и надо ее набирать - идем на другие маркетплейсы. А дальше надо разбираться в деталях.
Согласен, однако рано или поздно оно упрется в потолок и встает вопрос, а как расти дальше? Вот тут сильно и приходят на помощь экосистемы. Еще кстати не стоит упускать из вида тот факт, что если у вас продукт вспомогательный (который используется как дополнение к какой-то системе, например телефония, чаты, смски, подписание документов), то вам жить без интеграции в кого-то будет сложно и мы снова приходим к экосистемам.
Насколько удачных не готов судить, но так или иначе они есть. Мой Склад и Эвотор сделали классические маркетплейсы приложений - это пример стратегии 1 "Развивайте вашу экосистему". Из примеров стратегии 3, можно отметить Wazzup и UIS, которые активно двигались через другие системы. А вот на стратегию 2 "Продвигайте свою экосистему среди существующих и потенциальных пользователей" пока не знаю что лучше привести...
Вот здесь было плюс минус тоже самое произошло.
Работаем с рекрутинговым агентством, они как-то с этим справляются. Детали подсказать не смогу, так как это их процесс.
А что касается опыта разработки, если вы говорите о том что он должен иметь опыт написания кода, нет. А вот системное мышление, вот без этого у нас не зедерживаются.
Здесь сильно помогает написание юзкейсов, причем что важно каждый шаг юзкейса нужно максимально упрощать. Например: проверка двух условий, это два шага, а не один как часто делают.
Так вот в таком формате мы описываем основной сценарий, а потом уже идешь по нему и на каждом шаге задаешься вопросом, а что может пойти не так. Таким образом получается выявить большую часть возможных отклонений.
Ну и это работает как для системных требований, так и для бизнес требований.
Со стороны и правда выглядит курьезно, но тут все сильно же зависит от размера продукта и того на какие сервисы аффектит данное изменение. Чем больше продукт, тем тяжелее вносить архитектурные правки.
Плюс уточню, речь не о смене адреса доставки, а именно о сдаче заказа в рандомный пункт.
Даже уже и не вспомню, потому как видел много разных вариантов и везде по чуть-чуть брал того что решало именно нашу задачу.
Да, все верно. Местами процессы именно на это и направлены, чтобы потом не было ощущения что он видит это в первый раз и начинает предлагать как сделать получше “Поиграйтие со шрифтами/цветом/логикой и еще чем-нибудь только поиграйте”
Если будут вопросы пишите, помогу чем смогу)
Тут можно долго рассуждать, лично я для себя определяю от цели: Есть аудитория, и хотим на ней больше зарабатывать - пилим маркетплейс. Мало аудитории и надо ее набирать - идем на другие маркетплейсы. А дальше надо разбираться в деталях.
Согласен, однако рано или поздно оно упрется в потолок и встает вопрос, а как расти дальше? Вот тут сильно и приходят на помощь экосистемы. Еще кстати не стоит упускать из вида тот факт, что если у вас продукт вспомогательный (который используется как дополнение к какой-то системе, например телефония, чаты, смски, подписание документов), то вам жить без интеграции в кого-то будет сложно и мы снова приходим к экосистемам.
Насколько удачных не готов судить, но так или иначе они есть. Мой Склад и Эвотор сделали классические маркетплейсы приложений - это пример стратегии 1 "Развивайте вашу экосистему". Из примеров стратегии 3, можно отметить Wazzup и UIS, которые активно двигались через другие системы.
А вот на стратегию 2 "Продвигайте свою экосистему среди существующих и потенциальных пользователей" пока не знаю что лучше привести...
Пока не готов привести пример, разве что теоретические рассуждения... если что-то дельное найду напишу.
Куда же без них, но это кажется тема для отдельной статьи =)
Все так, как говорится "Дъявол в деталях"
У моих знакомых никаких нареканий не возникало.
Поддерживаю про обновления на все 100