С точки зрения теории все логично и правильно. Но вы начали спор в прикладной плоскости (какое решение эффективнее), не имея на руках цифр. Управленческая теория со времен Друкера говорит: считай цифры и принимай решения на их основе.
Ну и кто запрещает делать все одновременно? SkyEng и так выходит на новые рынки и по географии (Китай) и по вертикалям (математика), если вы не в курсе. А вы, судя по высказыванию, не в курсе.
Про каналы продаж… А сколько вы вообще знаете каналов продаж, которые уже охвачены SkyEng и которые еще не охвачены?
Если бы ещё понимать о какой проблеме говорить. Люди иногда сами не очень понимают чего хотят (в изучении языков иногда хотят просто ощущения развития).
Ну и пассаж про «альтернативные действия» это все мимо кассы. Конкретики нет, какие действия, почему они дадут предсказуемой больший результат — это пока на уровне домыслов
Работа «вслепую» выглядит странно для любой специальности, не так ли? Речь в статье не о плохих ТЗ, а невозможности сделать market fit с наскока.
Как говорил Эйнштейн, правильно сформулированный вопрос содержит ответ. Проблема в том, чтобы этот вопрос (market fit) найти и сформулировать. В этом первая задача продакта.
Вторая описываемая в статье проблема в том, что зачастую команда разработки живет в своем мире, где все задачи гарантированно правильные и в самой задаче не содержится «багов». При том, что «баги» в результатах выполнения задач считаются нормой и наличие тестировщиков тоже считается нормой.
Альтернатива тоже практически гарантирована. Попасть в рыночную потребность с первого раза могут только очень крутые менеджеры. Но у них и команды часто их уровня :-)
Я прихожу к разработчику и говорю: «Давай сделаем железную коробку на колесах, чтобы ее можно было вручную толкать». Разработчик делает. Потом я прихожу и говорю: «Давай двигатель добавим», а в ответ слышу: «Мы это в архитектуру не закладывали», так что пусть и дальше руками толкают.
Решение напрашивается само собою: Вместе с задачей на железную коробку можно обсудить перспективы: «Слушай, а если тележка понравится, сможем мы приделать ей колеса?»
Если, конечно, есть понимание возможных сценариев развития.
У разработки результат выполнения известен и валидируется однозначно;
У product-owner'ов результат выполнения НЕ известен и валидируется рынком по-разному.
И надо помнить, что работа «в стол» демотивирует ЛЮБОГО. А чтобы снизить этот эффект, надо задать разработке один вопрос: «Парни, я за пиццей, какую возьмем сегодня?» И за совместным поеданием наладить отношения и обсудить «эксперименты Эдисона».
p.s. Опытные менеджеры, кстати, в бюджет проекта закладывают «представительские расходы» на такие угощения пиццей ;-)
Про каналы продаж… А сколько вы вообще знаете каналов продаж, которые уже охвачены SkyEng и которые еще не охвачены?
Похоже, моя фраза про «мимо кассы», таки в кассу.
Если бы ещё понимать о какой проблеме говорить. Люди иногда сами не очень понимают чего хотят (в изучении языков иногда хотят просто ощущения развития).
Ну и пассаж про «альтернативные действия» это все мимо кассы. Конкретики нет, какие действия, почему они дадут предсказуемой больший результат — это пока на уровне домыслов
Как говорил Эйнштейн, правильно сформулированный вопрос содержит ответ. Проблема в том, чтобы этот вопрос (market fit) найти и сформулировать. В этом первая задача продакта.
Вторая описываемая в статье проблема в том, что зачастую команда разработки живет в своем мире, где все задачи гарантированно правильные и в самой задаче не содержится «багов». При том, что «баги» в результатах выполнения задач считаются нормой и наличие тестировщиков тоже считается нормой.
Думаете доволен разработчик, что сделал классный код? Неа. Потому что его труд остался лежать ровно также незаметно, как если бы он его удалил.
А вот я бы с радостью «закопал» в проект чуть меньше денег и а остальные деньги пустил бы в другой проект, глядишь бы второй выстрелил.
Решение напрашивается само собою: Вместе с задачей на железную коробку можно обсудить перспективы: «Слушай, а если тележка понравится, сможем мы приделать ей колеса?»
Если, конечно, есть понимание возможных сценариев развития.
И надо помнить, что работа «в стол» демотивирует ЛЮБОГО. А чтобы снизить этот эффект, надо задать разработке один вопрос: «Парни, я за пиццей, какую возьмем сегодня?» И за совместным поеданием наладить отношения и обсудить «эксперименты Эдисона».
p.s. Опытные менеджеры, кстати, в бюджет проекта закладывают «представительские расходы» на такие угощения пиццей ;-)
DIVс фоном#333Скажите, а почему неудобно автоматическое увеличение поля ввода текста?