Ни и как мы их развиваем?!!! Мы изначально анализируем их потребности и делаем универсальное масштабируемое ПО. На курсы личностного роста они сами вольны ходить, без нашего участия.
Я согласен, что скорее всего С.Б. именно противопоставлял PD и CD, лингвистически. Но в русском, в отличие от английского, оно лишеного смысла и звучит очень натянуто. Поэтому, имхо, нужно искать термин, который отражает суть процесса, а не переводит английский термин в лоб!
«разработку под» я предлагал заменить «клиентоориентированностью». с «разработкой клиента» как был не согласен, так и остался. Не по-русски оно, звучит как развод клиента. Откройте толковый словарь: разработка используется с неодушевленными предметами (план, земля, материалы и т.д.), в отличие от английского, в котором у слова еще полтора десятка значений (в том числе, которые можно использовать с «клиентом» — формирование, создание, эволюция).
Денис, я предлагаю закрыть спор. Я услышал ваше мнение, надеюсь, вы услышали мое. По сути мы говорим про одно и то же, а спор — в плоскости филологии.
Вы утвержали, что словосочитание Customer Development Model используется для параоксального противопоставления Product Development Model. Я с вами согласен, что в английском в профессиональной среде это вполне оправдано, так как данный термин вполне устоявшийся. В русском же языке противопоставлять банально нечему, т.к. словосочитание неустоявшееся, а термин просто эхо множественных переводов с английского. Поэтому сама игра слов бессмысленна получается. А если так, то зачем пытаться перевести в лоб. Давайте переведем по смыслу!
Я предлагаю не переходить на личности и не приводить в качестве аргумента чужое местожительство. Оно рассизмом отдает. Поэтому если и спорить, то придерживаясь этических принципов и научных методов.
«модель разработки продукта» — встречается в гугле 12100 раз.
«product development model» — 50300
Это конечно не на порядок больше, но все же в 4 раза. Во-вторых, предложенный вами термин — «Модель разработки клиента» — еще дальше от сути. Вы просто взяли и в лоб перевели. Ну попробуйте стихи так же переводить, оправдывая это парадоксальностью и не возможностью иначе передать игру слов. Я лично придерживаюсь иной точки зрения. Можете предложить более точный термин — вперед. Я не из тех, кто до последнего за «свое» будет держаться.
Кроме четвертого абзаца я прочитал The Four Steps to the Epiphany и The Startup Owner's Manual. В оригинале. Поэтому можно продолжать спорить о парадоксах и метафорах Стива, но сути это не меняет: в основе разработки любого продукта — проблема будущего потребителя.
Термин «Модель разработки клиента» — лишен любого смысла — и лингвистического, и здравого. Мы не можем как Стив парадоксально противопоставить этот термин «Модели разработки продукта», так как это не устойчивое общепринятое выражение; и обычного смысла оно тоже лишено: мы не разрабатываем клиента! Мы определяем его проблему и разрабатываем все так же некий продукт!
Я прошу прощения, но перевод «модель развития клиента» — не отражает суть. это калька. Customer Development — противопоставление Product Development, где в процессе создания нового продукта отсутствует потребитель как таковой. При Customer Development — вы все также развиваете, создаете продукт, но ориентируетесь на потребителя: его нужды и проблемы. А не свои домыслы.
Мне кажется, мы говорим более менее об одном и том же, но я бы хотел подчеркнуть одну мысль. Мы не «развиваем клиентскую базу». Мы создаем некий продукт-решение под нужды конкретного потребителя или группы потребителей, обладающего достаточной универсальностью для масштабирования проекта. И за счет этой универсальности продукт в последствии находит новых потребителей, а не потому что мы их холим и лелеем.
Ввиду сказанного, я бы предложил переводить Customer Development как «Клиентоориентированная разработка». Буду рад, если кто-то предложит более точный термин.
Все гуру кричат одно горло: хватит делать 1001ое мобильное приложение. Решайте конкретные задачи, проблемы бизнеса. И задача стартапа, в отличие от разработки по ТЗ заказчика, как раз таки выявить эти проблемы, проанализировать, и — главное — предложить некое универсальное решение, которое подойдет и фирме Х, и в последующем остальным фирмам с аналогичной проблемой. Если решение будет не масштабируемым, то это не стартап)
Друзья, allexe и JustRoo,- не спорте! Правда посередине, ответ можно найти в The Four Steps to the Epiphany. Подход называется Customer Development. Да, могут быть проекты, когда ты деаешь продукт, который «навырост». Например, Стив Бланк приводт пример с Photostoyou, которые раньше других начали предлагать какие-то услуги для только что появившихся цифровых фотоаппаратов. Да, это вполне закономерная проблема, если вы пытаетесь сделать продукт и создать им новый рынок. Честер Карлсон 10 лет бегал со своей идей электрографии прежде, чем смог продать свой патент — будущий ксерокс. Но идея в том, что валидация все равно нужна. Нельзя делать абстрактные проекты, оторванные от мира. Если у вас есть проблема, сходите и пообщайтесь с другими людми. Вы же не инопранетянин! Вероятно, она будет и у других. А если нет, то это повод подзадуматься! Понятно, что в случае с продуктом на новый рынок валидация будет менее жеской и определенной и у предпримиателя зачастую возникают дополнительные риски. Но первичную и последующие проверки гипотез — никто не отменял!!! Кроме этого, с выходом на новый рынок у предпринимателя возникает дополнительная обязанность: обучить рынок. Рассказать всем зачем это надо, как этим пользоваться и как прекрасна станет их жизнь с приобретением продукта. Тут же возникают доп риски: что вы это как первопроходец сделаете, а сливки снимут те, кто сделает аналог сразу после вас.
Да бросьте! Никто там в бараний рог не скручивается, чтобы понравится. Да, письмо не холодно-формальное. Да, автор ссылается на проекты Дэвида. Но Дэвид публичный человек, ведет свой блог и о его проектах можно прочитать в открытых источниках. Наверное, нужно сделать скидку, что это США и там несколько иначе ведут бизнес. Оно как-то намного доброжелательнее и «теплее». Неделю назад общался со своим главным конкурентом, с которым у меня замечательные отношения. Ну и я хочу сказать, что написать формально-холодное письмо намного проще, чем дружеское, выдержанное в определенных рамках. Да, есть задача как-то зацепить внимание такого человека, но имхо нет лучшего способа, чем сказать какие-то очень релевантные тебе вещи. Вспомним гадалок. Главное палку не перегибать. И имхо поцелуев «ниже пояса» тут нет. Обратите внимание, что Дэвид пишет, что ему захотелось помочь этому малому.
Про суть проблемы — согласен. Я сам со скрипом продирался. Идея в том, что ребят делима: 1) делать ли продукт, который бы решал некую проблему, связанную с место нахождением объекта и его неким состоянием (все что угодно: больной, заключенный, такси и т.д.) 2) или сделать просто бэк-энд сервер, аля API-сервис, который бы позволил другим проектам строить конечные продукты, решения.
Безусловно любой перевод не способен перенести 100% вкладываемого автором смысла, всех оттенков и тем более всегда точно подобрать емкие переводы сленгу, шуткам, оборотам. Поэтому я с себя ни разу не снимаю ответственность за перевод. Но я, если честно, не вижу моветона. Во-первых, форма you, как вы знаете, это и «ты», и «вы». Во-вторых, на английском все используемые обороты, шутки звучат вполне в тему и ухо не режут. Оригинал можно найти по ссылке под постом.
А что, простите, обсуждается кроме дела?
У всего есть свои крайности. Да гениальную идею будет намного сложнее реализовать, если вы не можете донести ее в доступной форме до окружающих. И дело даже не в инвесторе, хотя он в среднем обычно более толковый и понятливый, чем остальные. Потом же вам как-то этот продукт продавать нужно, нужно общаться с миллионом людей. Да, нужно уметь обличать свои мысли в надлежащую форму.
Второй момент. Я все-таки (как и Дэвид) склонен считать, что умение говорить правильные вещи и подавать их в правильной форме свойственно в большей степени толковым ребятам. Поэтому на этом основании есть все оснвоания предположить, что на том конце не мудак. Хотя, согласен, жизнь не устает демонстрировать и обратные примеры.
Рады стараться!
Я согласен, что скорее всего С.Б. именно противопоставлял PD и CD, лингвистически. Но в русском, в отличие от английского, оно лишеного смысла и звучит очень натянуто. Поэтому, имхо, нужно искать термин, который отражает суть процесса, а не переводит английский термин в лоб!
Денис, я предлагаю закрыть спор. Я услышал ваше мнение, надеюсь, вы услышали мое. По сути мы говорим про одно и то же, а спор — в плоскости филологии.
«модель разработки продукта» — встречается в гугле 12100 раз.
«product development model» — 50300
Это конечно не на порядок больше, но все же в 4 раза. Во-вторых, предложенный вами термин — «Модель разработки клиента» — еще дальше от сути. Вы просто взяли и в лоб перевели. Ну попробуйте стихи так же переводить, оправдывая это парадоксальностью и не возможностью иначе передать игру слов. Я лично придерживаюсь иной точки зрения. Можете предложить более точный термин — вперед. Я не из тех, кто до последнего за «свое» будет держаться.
Термин «Модель разработки клиента» — лишен любого смысла — и лингвистического, и здравого. Мы не можем как Стив парадоксально противопоставить этот термин «Модели разработки продукта», так как это не устойчивое общепринятое выражение; и обычного смысла оно тоже лишено: мы не разрабатываем клиента! Мы определяем его проблему и разрабатываем все так же некий продукт!
Мне кажется, мы говорим более менее об одном и том же, но я бы хотел подчеркнуть одну мысль. Мы не «развиваем клиентскую базу». Мы создаем некий продукт-решение под нужды конкретного потребителя или группы потребителей, обладающего достаточной универсальностью для масштабирования проекта. И за счет этой универсальности продукт в последствии находит новых потребителей, а не потому что мы их холим и лелеем.
Ввиду сказанного, я бы предложил переводить Customer Development как «Клиентоориентированная разработка». Буду рад, если кто-то предложит более точный термин.
Про суть проблемы — согласен. Я сам со скрипом продирался. Идея в том, что ребят делима: 1) делать ли продукт, который бы решал некую проблему, связанную с место нахождением объекта и его неким состоянием (все что угодно: больной, заключенный, такси и т.д.) 2) или сделать просто бэк-энд сервер, аля API-сервис, который бы позволил другим проектам строить конечные продукты, решения.
А что, простите, обсуждается кроме дела?
Второй момент. Я все-таки (как и Дэвид) склонен считать, что умение говорить правильные вещи и подавать их в правильной форме свойственно в большей степени толковым ребятам. Поэтому на этом основании есть все оснвоания предположить, что на том конце не мудак. Хотя, согласен, жизнь не устает демонстрировать и обратные примеры.