Вспомогательные — не соглашусь, рутинные — в классическом применении. Я же занимаюсь задачками, в которых робот должен быть готов выполнить не рутинную задачу. Важное уточнение — он не должен вдруг начать выполнять работу бухгалтера, речь о неповторяющихся задачах.
По поводу заготовок катеров — задача для нас типовая, по модели УП формировать.
Надёжность роботов, если начинаешь в них залезать очень глубоко (и не от хорошей жизни) — вообще вещь странная. Как с технической, так и с программной стороны вопроса.
В заключение — по поводу стиля изложения. Тут, к сожалению, ничего поделать не могу — форма подачи материала по отношению к последним статьям у меня не менялась, и создавать тексты, наполненные только сухими фактами, мне крайне тяжело)
Задача любого стартапа на первоначальном этапе — не сдохнуть. Если мы рассуждаем с точки зрения армии молодых и горячих, пилящих убийц уберов и ФБ, тогда это вообще отдельная история массового психоза. В остальных же случаях стартап — это то, что болит. Т.е. мы видим, что в какой то отрасли есть проблема, и решаем изменить немножко мир. Или множко — как получится. Другое дело — готов ли мир меняться так, как мы его видим?
И в данном случае пивот — это свернуть с рельс ожидания на рельсы выживания. Никто не говорит о том, что идею изначальную нужно выкидывать. Но зачастую изначальная идея очень сложна в реализации. Либо потому, что продукт сложный и требует большого количества доработок. Либо потому, что аудитория не готова, и культуру потребления продукта надо создавать. Либо потому, что скорость развития недостаточна для выживания комании. И тут на помощь приходит pivot, когда мы меняем модель ради того, чтобы через пол-года компания продолжала существовать. И если у нас формируется стабильный источник дохода, то можно вернуться к первоначальной. Но вернуться уже имея имя, историю продаж и деньги на эксперименты.
Опять же, переход от «поделок на девкитах» к мелкосерийному производству мы тоже проходили. И на заменяемость комплектующих закладывались, начиная от выбора массовых (с дестяком заменителей) для пассивных и жесткой логики, заканчивая просчетом 3-4 процессоров на тот же футпринт и разводкой с напайкой разных модемов.
При переходе, согласен, возникает куча вопросов, достойных отдельной статьи. Задача же этого материала была проста — хватит закапывать миллионы в то, что имеет абсолютно невнятную рыночную перспективу
1. Надо. В большинстве слуачаев. По разводке платы — как только мы найдем проект, с которым можно сделать подобную вещь, обязательно напишу статью на живом примере. Я убежден, что в том же большинстве случаев 5 экземпляров прототипа можно получить за 50-100К, начиная от «хочу плату» и заканчивая «вот оно, для которого мы будем писать прошивку»
2. Россия жыш! Фирм достаточно много, сроки — 3-4 дня при срочном производстве)) Я об этом говорил на выступлении на Startup Village — почему то про эту конкретную возможность очень часто забывают
3. Пробовал. Сейчас это скорее молодой и растущий рынок, который только делает первые шаги. Я общался с парой представителей, все свелось к парадигме «овес нынче дорог». А вообще да, система для них. Дело в том, что основное преимущество ее там, где сменные водители (обычно постоянные водители лучше следят за техникой). Каршеринг же — возведенная в абсолют парадигма, в которой принцип «не свое — не жалко» царствует повсюду. Но пока не сраслось.
Вот-вот. На самом деле, вопрос «как продать» очень сильно зависит от индустрии, ЛПР, модели. Во ФРИИ с этим вопросом нам больше всего помогли Хасанов, Красинский, Валь. Наверное все же стоит описать свой опыт. Но в каждом случае он индивидуален, сложно все автоматизировать до «делай раз, делай два»
Могу ответить как тот самый стартап, который совершил тот самый пивот. Когда ты херачишь башкой об стену, то ты либо ее проламываешь, либо тебя вибрацией сносит к двери. Дверь — это пивот концепции, когда ты понимаешь, что сделано не так. Жалко ли мне? Ни разу. Потому что мне было бы во сто крат жальше времени, которое я бы потратил на продолжение борьбы с бетоном. И тут большой вопрос — либо удалось таки проломить, либо — сдох бы по дороге. Зачастую пивот — это просто продавать по другому то, что уже готово. Продавать другой ЦА. Продавть другими механизмами. И если на одну чашу весов положить «о божечки ты мой, как же я расстанусь с такой привычной моделью продажи», а на другую «баста, карапузики, у нас кончились деньги, а продаж все нет», выбор очевиден.
Каков вопрос, таков и ответ)))
По существу:
1. Книжек про стартапы — овер дофига. Садись и читай. Через год можно вынести какое то мнение и понять план действий. Что будем кушать год — не понятно
2. В инете про стартапы — куча статей и такая же куча срача с обсуждением, из которой вынести что то еще сложнее, чем из вороха книг.
3. Многие, на самом деле, доростают до осознания необходимости структурированного подхода слишком поздно. Особенно если есть готовый продукт и какие то продажи. ЧСВ никуда не денешь, что уж там… Поэтому выбить из головы гордость за первые сделки и заставить прекратить метаться можно только кувалдой «надо», а не легким поглаживанием литературой.
4. Даже если все есть на руках, даже если прочитаны правильные книги и есть четкое понимание «надо», остановиться в ступоре очень легко. То, что говорится в книгах, хорошо на бумаге, но переложить опыт на свой проект бывает сложно, нужен взгляд со стороны. Желательно — с опытом накладывания ни на один подобный проект.
5. Взгляд со стороны — это вообще прекрасно, потому что нам просто повернули чуточку башню, подали нашу работу немного под другим соусом, и родилось УТП (уникальное торговое предложение). Замечу — без единой строчки кода.
6. Так же аксель — это экономия времени на поиск контактов. Ребята реально помогают быстро проверять концепции, предоставляя ЛПР-ов из практически любой сферы
7. Контроль за циклом «креатив — формирование УТП — проверка гипотез — MVP — корректировка УТП — продажи». В акселераторе не позволяют застрять на каком то из этапов, ведя вместе с тобой проект, заставляя пробегать дистанцию за очень короткие сроки вместо вдумчивого медитирования на невнятные результаты. Как итог — можно проверить больше концепций за менее короткий срок, быстро отказавшись от нежизнеспособных или с непонятным финансовым результатом
ФРИИ в данном случае не уникален, по косвенным признакам так работает большинство акселераторов (я не беру сейчас сложные научные структуры, которые направлены на цикл разработки в 6-12 месяцев). Отличаются акселераторы только в области специализации. Но то, что эффект и польза неиллюзорны — сомнений не вызывает. Мы во ФРИИ за 3 месяца сделали то, что самостоятельно прошли бы за год, если не больше, причем с непонятно каким результатом. А для любого стартапа время до появления продукта = количество сожженных средств.
Клевый вопрос, имхо. Не в бровь, а в глаз))) Если интересно, могу написать несколько статей в разрезе IoT о том, как мы делали продажи. И откуда вообще родилась концепция. Потому что на эту тему можно и нужно писать 3-4 таких портянки. Иначе — ответ на вопрос можно свести к простому «взяли трубку, позвонили 1000 раз, херак — клиент»
Читал в свое время в журнале «За рулем», как они катались на нескольких представителях этого чудного (от слова чудо) семейства. Как итог — без развитой инфраструктуры владение подобным четырехколесником — бида. Ибо, как на велосиепеде, педали не покрутишь… Пожалуйста, Ваш кеп.
А если серьезно, то владение транспортным средством на электротяге — интересное и увлекательное занятие. Только почему то экологи забывают о том, что есть жутко ядовитый литий в АКБ, а сторонники экономии — что те же АКБ имеют достаточно ограниченный ресурс количества циклов заряда/разряда. Так что, как говорят в спорте, подождем еще годик.
Keil убог, уж извините. Если рассматривать данную IDE в основном в качестве блокнота, в котором ты пишешь исходник, или, к примеру, в качестве курса молодого бойца «смотри, сосунок, вот так твои деды программировали» — тогда да. Но в современном мире скорость разработки встраиваемого ПО так же начинает играть немаловажную роль. Да, не в такой степени, как прикладного, но при этом тенденция на лицо. А эти средства не помогают в основной деятельности — создании кода, а наоборот — делают работу аскетичной и унылой, как говно мамонта.
Понимаю, что нахватаюсь минусов, но Keil. IAR — унылы и убоги. Да, решают задачу. Да, предоставляют инструменты. Но оставляют после себя огромное пожелание — пусть дети разработчиков этого некрофилического непотребства работают в нем по 12 часов до конца жизни.
1. только с полноценной
2. Отладчик, реализация функций построения проекта, структуры языка — не так уж все и просто. Если задаться целью «о, я заюзаю в качестве компилятора gcc и буду крут» — то да, вопросов нет. А если в качестве цели телодвижений будет «построить рабочую среду», то тут уже начинает выясняться, что тыкнуть две кнопки и редиректнуть компилятор — это далеко не все
3. Спасибо, обязательно посмотрю. Но пока что надо базово понять — оно нам надо или «CooCox и не мучиться»
это плагин для VS, позволяющий использовать GDB из оболочки, и как следствие (по идее), наследовать все плюшки VS. Но, в отличие от Atmel Studio, которая так же построена на базе VS, поставляется в виде плагина, а не готовой среды разработки.
По поводу заготовок катеров — задача для нас типовая, по модели УП формировать.
Надёжность роботов, если начинаешь в них залезать очень глубоко (и не от хорошей жизни) — вообще вещь странная. Как с технической, так и с программной стороны вопроса.
В заключение — по поводу стиля изложения. Тут, к сожалению, ничего поделать не могу — форма подачи материала по отношению к последним статьям у меня не менялась, и создавать тексты, наполненные только сухими фактами, мне крайне тяжело)
И в данном случае пивот — это свернуть с рельс ожидания на рельсы выживания. Никто не говорит о том, что идею изначальную нужно выкидывать. Но зачастую изначальная идея очень сложна в реализации. Либо потому, что продукт сложный и требует большого количества доработок. Либо потому, что аудитория не готова, и культуру потребления продукта надо создавать. Либо потому, что скорость развития недостаточна для выживания комании. И тут на помощь приходит pivot, когда мы меняем модель ради того, чтобы через пол-года компания продолжала существовать. И если у нас формируется стабильный источник дохода, то можно вернуться к первоначальной. Но вернуться уже имея имя, историю продаж и деньги на эксперименты.
При переходе, согласен, возникает куча вопросов, достойных отдельной статьи. Задача же этого материала была проста — хватит закапывать миллионы в то, что имеет абсолютно невнятную рыночную перспективу
2. Россия жыш! Фирм достаточно много, сроки — 3-4 дня при срочном производстве)) Я об этом говорил на выступлении на Startup Village — почему то про эту конкретную возможность очень часто забывают
3. Пробовал. Сейчас это скорее молодой и растущий рынок, который только делает первые шаги. Я общался с парой представителей, все свелось к парадигме «овес нынче дорог». А вообще да, система для них. Дело в том, что основное преимущество ее там, где сменные водители (обычно постоянные водители лучше следят за техникой). Каршеринг же — возведенная в абсолют парадигма, в которой принцип «не свое — не жалко» царствует повсюду. Но пока не сраслось.
По существу:
1. Книжек про стартапы — овер дофига. Садись и читай. Через год можно вынести какое то мнение и понять план действий. Что будем кушать год — не понятно
2. В инете про стартапы — куча статей и такая же куча срача с обсуждением, из которой вынести что то еще сложнее, чем из вороха книг.
3. Многие, на самом деле, доростают до осознания необходимости структурированного подхода слишком поздно. Особенно если есть готовый продукт и какие то продажи. ЧСВ никуда не денешь, что уж там… Поэтому выбить из головы гордость за первые сделки и заставить прекратить метаться можно только кувалдой «надо», а не легким поглаживанием литературой.
4. Даже если все есть на руках, даже если прочитаны правильные книги и есть четкое понимание «надо», остановиться в ступоре очень легко. То, что говорится в книгах, хорошо на бумаге, но переложить опыт на свой проект бывает сложно, нужен взгляд со стороны. Желательно — с опытом накладывания ни на один подобный проект.
5. Взгляд со стороны — это вообще прекрасно, потому что нам просто повернули чуточку башню, подали нашу работу немного под другим соусом, и родилось УТП (уникальное торговое предложение). Замечу — без единой строчки кода.
6. Так же аксель — это экономия времени на поиск контактов. Ребята реально помогают быстро проверять концепции, предоставляя ЛПР-ов из практически любой сферы
7. Контроль за циклом «креатив — формирование УТП — проверка гипотез — MVP — корректировка УТП — продажи». В акселераторе не позволяют застрять на каком то из этапов, ведя вместе с тобой проект, заставляя пробегать дистанцию за очень короткие сроки вместо вдумчивого медитирования на невнятные результаты. Как итог — можно проверить больше концепций за менее короткий срок, быстро отказавшись от нежизнеспособных или с непонятным финансовым результатом
ФРИИ в данном случае не уникален, по косвенным признакам так работает большинство акселераторов (я не беру сейчас сложные научные структуры, которые направлены на цикл разработки в 6-12 месяцев). Отличаются акселераторы только в области специализации. Но то, что эффект и польза неиллюзорны — сомнений не вызывает. Мы во ФРИИ за 3 месяца сделали то, что самостоятельно прошли бы за год, если не больше, причем с непонятно каким результатом. А для любого стартапа время до появления продукта = количество сожженных средств.
А если серьезно, то владение транспортным средством на электротяге — интересное и увлекательное занятие. Только почему то экологи забывают о том, что есть жутко ядовитый литий в АКБ, а сторонники экономии — что те же АКБ имеют достаточно ограниченный ресурс количества циклов заряда/разряда. Так что, как говорят в спорте, подождем еще годик.
Понимаю, что нахватаюсь минусов, но Keil. IAR — унылы и убоги. Да, решают задачу. Да, предоставляют инструменты. Но оставляют после себя огромное пожелание — пусть дети разработчиков этого некрофилического непотребства работают в нем по 12 часов до конца жизни.
Правильно ли я понимаю, что это относится только к плюсам?
2. Отладчик, реализация функций построения проекта, структуры языка — не так уж все и просто. Если задаться целью «о, я заюзаю в качестве компилятора gcc и буду крут» — то да, вопросов нет. А если в качестве цели телодвижений будет «построить рабочую среду», то тут уже начинает выясняться, что тыкнуть две кнопки и редиректнуть компилятор — это далеко не все
3. Спасибо, обязательно посмотрю. Но пока что надо базово понять — оно нам надо или «CooCox и не мучиться»