• Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    done
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    Задача любого стартапа на первоначальном этапе — не сдохнуть. Если мы рассуждаем с точки зрения армии молодых и горячих, пилящих убийц уберов и ФБ, тогда это вообще отдельная история массового психоза. В остальных же случаях стартап — это то, что болит. Т.е. мы видим, что в какой то отрасли есть проблема, и решаем изменить немножко мир. Или множко — как получится. Другое дело — готов ли мир меняться так, как мы его видим?

    И в данном случае пивот — это свернуть с рельс ожидания на рельсы выживания. Никто не говорит о том, что идею изначальную нужно выкидывать. Но зачастую изначальная идея очень сложна в реализации. Либо потому, что продукт сложный и требует большого количества доработок. Либо потому, что аудитория не готова, и культуру потребления продукта надо создавать. Либо потому, что скорость развития недостаточна для выживания комании. И тут на помощь приходит pivot, когда мы меняем модель ради того, чтобы через пол-года компания продолжала существовать. И если у нас формируется стабильный источник дохода, то можно вернуться к первоначальной. Но вернуться уже имея имя, историю продаж и деньги на эксперименты.
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    Опять же, переход от «поделок на девкитах» к мелкосерийному производству мы тоже проходили. И на заменяемость комплектующих закладывались, начиная от выбора массовых (с дестяком заменителей) для пассивных и жесткой логики, заканчивая просчетом 3-4 процессоров на тот же футпринт и разводкой с напайкой разных модемов.

    При переходе, согласен, возникает куча вопросов, достойных отдельной статьи. Задача же этого материала была проста — хватит закапывать миллионы в то, что имеет абсолютно невнятную рыночную перспективу
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    1. Надо. В большинстве слуачаев. По разводке платы — как только мы найдем проект, с которым можно сделать подобную вещь, обязательно напишу статью на живом примере. Я убежден, что в том же большинстве случаев 5 экземпляров прототипа можно получить за 50-100К, начиная от «хочу плату» и заканчивая «вот оно, для которого мы будем писать прошивку»
    2. Россия жыш! Фирм достаточно много, сроки — 3-4 дня при срочном производстве)) Я об этом говорил на выступлении на Startup Village — почему то про эту конкретную возможность очень часто забывают
    3. Пробовал. Сейчас это скорее молодой и растущий рынок, который только делает первые шаги. Я общался с парой представителей, все свелось к парадигме «овес нынче дорог». А вообще да, система для них. Дело в том, что основное преимущество ее там, где сменные водители (обычно постоянные водители лучше следят за техникой). Каршеринг же — возведенная в абсолют парадигма, в которой принцип «не свое — не жалко» царствует повсюду. Но пока не сраслось.
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    Вот-вот. На самом деле, вопрос «как продать» очень сильно зависит от индустрии, ЛПР, модели. Во ФРИИ с этим вопросом нам больше всего помогли Хасанов, Красинский, Валь. Наверное все же стоит описать свой опыт. Но в каждом случае он индивидуален, сложно все автоматизировать до «делай раз, делай два»
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    Могу ответить как тот самый стартап, который совершил тот самый пивот. Когда ты херачишь башкой об стену, то ты либо ее проламываешь, либо тебя вибрацией сносит к двери. Дверь — это пивот концепции, когда ты понимаешь, что сделано не так. Жалко ли мне? Ни разу. Потому что мне было бы во сто крат жальше времени, которое я бы потратил на продолжение борьбы с бетоном. И тут большой вопрос — либо удалось таки проломить, либо — сдох бы по дороге. Зачастую пивот — это просто продавать по другому то, что уже готово. Продавать другой ЦА. Продавть другими механизмами. И если на одну чашу весов положить «о божечки ты мой, как же я расстанусь с такой привычной моделью продажи», а на другую «баста, карапузики, у нас кончились деньги, а продаж все нет», выбор очевиден.
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    0
    Каков вопрос, таков и ответ)))
    По существу:
    1. Книжек про стартапы — овер дофига. Садись и читай. Через год можно вынести какое то мнение и понять план действий. Что будем кушать год — не понятно
    2. В инете про стартапы — куча статей и такая же куча срача с обсуждением, из которой вынести что то еще сложнее, чем из вороха книг.
    3. Многие, на самом деле, доростают до осознания необходимости структурированного подхода слишком поздно. Особенно если есть готовый продукт и какие то продажи. ЧСВ никуда не денешь, что уж там… Поэтому выбить из головы гордость за первые сделки и заставить прекратить метаться можно только кувалдой «надо», а не легким поглаживанием литературой.
    4. Даже если все есть на руках, даже если прочитаны правильные книги и есть четкое понимание «надо», остановиться в ступоре очень легко. То, что говорится в книгах, хорошо на бумаге, но переложить опыт на свой проект бывает сложно, нужен взгляд со стороны. Желательно — с опытом накладывания ни на один подобный проект.
    5. Взгляд со стороны — это вообще прекрасно, потому что нам просто повернули чуточку башню, подали нашу работу немного под другим соусом, и родилось УТП (уникальное торговое предложение). Замечу — без единой строчки кода.
    6. Так же аксель — это экономия времени на поиск контактов. Ребята реально помогают быстро проверять концепции, предоставляя ЛПР-ов из практически любой сферы
    7. Контроль за циклом «креатив — формирование УТП — проверка гипотез — MVP — корректировка УТП — продажи». В акселераторе не позволяют застрять на каком то из этапов, ведя вместе с тобой проект, заставляя пробегать дистанцию за очень короткие сроки вместо вдумчивого медитирования на невнятные результаты. Как итог — можно проверить больше концепций за менее короткий срок, быстро отказавшись от нежизнеспособных или с непонятным финансовым результатом

    ФРИИ в данном случае не уникален, по косвенным признакам так работает большинство акселераторов (я не беру сейчас сложные научные структуры, которые направлены на цикл разработки в 6-12 месяцев). Отличаются акселераторы только в области специализации. Но то, что эффект и польза неиллюзорны — сомнений не вызывает. Мы во ФРИИ за 3 месяца сделали то, что самостоятельно прошли бы за год, если не больше, причем с непонятно каким результатом. А для любого стартапа время до появления продукта = количество сожженных средств.
  • Наши грабли в запуске hardware-стартапа — поиск бизнес-модели и разработка MVP в сфере «интернет вещей»
    +2
    Клевый вопрос, имхо. Не в бровь, а в глаз))) Если интересно, могу написать несколько статей в разрезе IoT о том, как мы делали продажи. И откуда вообще родилась концепция. Потому что на эту тему можно и нужно писать 3-4 таких портянки. Иначе — ответ на вопрос можно свести к простому «взяли трубку, позвонили 1000 раз, херак — клиент»
  • Два месяца подряд электромобили возглавляют рейтинг продаж в Норвегии
    +2
    Читал в свое время в журнале «За рулем», как они катались на нескольких представителях этого чудного (от слова чудо) семейства. Как итог — без развитой инфраструктуры владение подобным четырехколесником — бида. Ибо, как на велосиепеде, педали не покрутишь… Пожалуйста, Ваш кеп.

    А если серьезно, то владение транспортным средством на электротяге — интересное и увлекательное занятие. Только почему то экологи забывают о том, что есть жутко ядовитый литий в АКБ, а сторонники экономии — что те же АКБ имеют достаточно ограниченный ресурс количества циклов заряда/разряда. Так что, как говорят в спорте, подождем еще годик.
  • STM32+Visual Studio
    +2
    Главное в работе — удобство.
  • STM32+Visual Studio
    0
    Keil убог, уж извините. Если рассматривать данную IDE в основном в качестве блокнота, в котором ты пишешь исходник, или, к примеру, в качестве курса молодого бойца «смотри, сосунок, вот так твои деды программировали» — тогда да. Но в современном мире скорость разработки встраиваемого ПО так же начинает играть немаловажную роль. Да, не в такой степени, как прикладного, но при этом тенденция на лицо. А эти средства не помогают в основной деятельности — создании кода, а наоборот — делают работу аскетичной и унылой, как говно мамонта.

    Понимаю, что нахватаюсь минусов, но Keil. IAR — унылы и убоги. Да, решают задачу. Да, предоставляют инструменты. Но оставляют после себя огромное пожелание — пусть дети разработчиков этого некрофилического непотребства работают в нем по 12 часов до конца жизни.
  • STM32+Visual Studio
    0
    CooCox не поддерживает плюса
  • STM32+Visual Studio
    0
    Спасибо за ликбез.

    Правильно ли я понимаю, что это относится только к плюсам?
  • STM32+Visual Studio
    0
    А можно поподробней о возможностях (первая часть поста)? Не холивара ради, а исключительно в познавательных целях.
  • STM32+Visual Studio
    0
    1. только с полноценной
    2. Отладчик, реализация функций построения проекта, структуры языка — не так уж все и просто. Если задаться целью «о, я заюзаю в качестве компилятора gcc и буду крут» — то да, вопросов нет. А если в качестве цели телодвижений будет «построить рабочую среду», то тут уже начинает выясняться, что тыкнуть две кнопки и редиректнуть компилятор — это далеко не все
    3. Спасибо, обязательно посмотрю. Но пока что надо базово понять — оно нам надо или «CooCox и не мучиться»
  • STM32+Visual Studio
    0
    это плагин для VS, позволяющий использовать GDB из оболочки, и как следствие (по идее), наследовать все плюшки VS. Но, в отличие от Atmel Studio, которая так же построена на базе VS, поставляется в виде плагина, а не готовой среды разработки.
  • Galileo — первый Arduino-совместимый микрокомпьютер на платформе Intel. Уже в продаже!
    0
    могу тебе показать ворох железа, в числе которого и расбери, которое греется через час загрузки даже не под 100% до состояния эмердженси шатдаун.
  • Galileo — первый Arduino-совместимый микрокомпьютер на платформе Intel. Уже в продаже!
    +2
    Сорри за резкий тон. Был не прав
  • История одного провала
    0
    Имелось ввиду комментирование псевдоготового результата. Неоттестированное толком приложение демонстрировалось заказчику, после чего появлялась еще кучка требований и комментариев к программе, способу ее работы и взаимодействию с окружающим миром. Ну а так как у нас результат все же с приставкой псевдо-, то недоработки в том, что показывалось, возникали неизбежно. Как следствие, чтобы сгладить проблему нерабочей программы (которую, попросту, надо было оттестировать корректно, ибо сроки все равно увеличивались в два раза от озвученных мною и в 4 — от спущенных сверху в виде дедлайна), то эти комментарии принимались.

    Я допускаю, что на самом деле их было гораздо больше, как мне и было озвучено. Просто героические усилия и солидарность приводили к тому, что я получал 30% от озвученных пожеланий. Так это или нет — легче от этого не становилось. Перекраивать приходилось огромные куски программы, причем перекраивать на скорую руку, ибо следующий дед лайн был еще оптимистичней предыдущего. И так далее.
  • История одного провала
    0
    Постоянно использую agile в разработках. Но когда по всем нормативам получается 80 часов, которые под лозунгом «даешь пятилетку в три года» трансформируются в 30 часов, никакая система не поможет. Урезание, и зачастую за счет тестирования и отладки
  • История одного провала
    0
    Именно.
    А если быть совсем точным, то изначальный уровень абстракции был попилен в угоду количеству комментариев и переделок и постоянно сокращаемым срокам. В результате — костылестроение
  • Galileo — первый Arduino-совместимый микрокомпьютер на платформе Intel. Уже в продаже!
    0
    А я и не говорю о потреблении электроэнергии платой. Я о чипе.
  • Galileo — первый Arduino-совместимый микрокомпьютер на платформе Intel. Уже в продаже!
    +1
    А на картиночку тыкнуть? В левом верхнем углу картинки Analog In
  • Galileo — первый Arduino-совместимый микрокомпьютер на платформе Intel. Уже в продаже!
    0
    Может наоборот плюс? Главный бич всех таких поделок — охлаждение. Ну не получается все в одном — и производительность, и теплоотвод. Так что это скорее не минус, а плюс, который может не давать железке выполнять роль кипятильника
  • История одного провала
    0
    Как бы это помягче сказать… Суперкласс, 40 входных переменных, хранение данных предварительных рассчетов в массиве выходных данных, который под темповые области вручную увеличен в два раза (вместо размерности [x,y,z], которая описывает иерархию, выполнен в виде [x, y, 2z]), да и вообще — хранение данных в ООП языке в стиле процедурного программирования… Боюсь, юнит-тесты вызвали бы гору непонимания и долгие объяснения «как, что и зачем».
  • История одного провала
    +1
    приятного
  • История одного провала
    +1
    Потому что результатом работы должен являться продукт, а не процесс. Процесс заказчику не сдашь. Более того, это начинает постепенно накладываться на другие запланированные задачи, откладывая точку их начала — далее наваливается как ком.
  • История одного провала
    0
    Видимо, настройки компилятора.
  • История одного провала
    –2
    Две компании и два сотрудника — не думал, что будет такая беда с тем, чтобы их идентифицировать по буквам
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    0
    Я говорил о рабочем процессе, в котором есть постоянная команда, которая не успевает. но никак не о крайнем случае заморозки проекта и его последующем форсировании.
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    0
    Спасибо за Ваш ответ. Собственно, тезисно по Вашей статье я прошел, не буду повторяться.

    что касается систем управления проектом, то на мой взгляд, они очень и очень сильно схожи с проблемами, стоящими перед одним программистом.
    Давайте немного раскрою мною же и выданный постулат:
    Проблемы есть везде. У менеджера, у программиста. И у того, и у другого корень проблемы практически всегда один и тот же. Согласование рабочего процесса для менеджера = ожиданию программистом кода от другого участника. И там и там возможны задержки, накладки.
    непостоянство технического задания одинаково ударяет что по менеджеру, что по программисту
    нехватка ресурсов может ощущаться и там и там.

    Одним словом — проблемы прямо рядышком. Менеджеру даже проще — у него больше возможностей для их решения.
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    0
    Ни с каких. Сколько бы не брал примеров из личной практики, какой бы ни был проект — приплюсовывание рабочих рук на позднем этапе с явным запаздыванием ведет всегда только к лишней нервозности и беготне по кругу. Полностью с Вами согласен.
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    +2
    Не всегда так.
    Да, я не раз встречал со стороны заказчика непонимание, когда в ведомости проекта значилась строчка «менеджмент проекта». Но, как правило, это решалось достаточно просто — вот тебе дизайнер, вот программист, вот архитектор, вот разработчик базы данных. Работайте. Особо упертым хватало 3 дней, чтобы понять, что это АД.

    С другой стороны, при правильной постановке рабочего процесса, вопросов не возникает. По сути дела данная должность — прослойка между руководителем и группой программистов (берем только ситуацию с оценкой результатов, на самом деле предметное поле несколько шире). Если человек, занимаемый должность, не перекладывает на плечи начальства мелкие проблемы коллектива, а на плечи коллектива — спускаемые директивы начальства в прямом виде, то он как раз и выполняет то, зачем он работает — несет полную ответственность за вверенный участок работы. Потому отчитывается перед начальником он. И в голове начальника прежде всего не «ой какая крутая группа программистов, которая все сделала», а «ой какой Вася/Петя/пофиг как зовут молодец, правильно поставил рабочий процесс и все сделал вовремя». Да, группа программистов стоит за плечами этого руководителя, и их успеха никто не умаляет. Это те люди, чьими руками ковалась победа. А тим лид при этом — тот, кто привел к победе. Так что вроде все закономерно.
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    +1
    Когда статья больше похожа на обсуждение новой бехи жалобу на то, как страшно жить, то смысл ее писать? А тем более мне странно то, что пришла она из песочницы. Каг бэ да, пожаловаться на жизнь — это завсегда, но в рамках статьи да еще и с получением инвайта?..
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    +1
    У сожалению, сам себе начальник имеет еще больше проблемное поле и еще большую зону ответственности
  • Проблемы перехода в менеджеры среднего звена — это проблемы?
    +3
    Ответил бы в комментах к самой статье, если бы не был в статусе рид-онли. А так пришлось в песочницу накатать
  • В пень free-lance.ru!
    0
    спасибо
  • В пень free-lance.ru!
    +2
    А чего минусовать? Это факт :)))
  • Хабра-lance
    +1
    если не лень — киньте ссылочку, когда закончите
  • Хабра-lance
    0
    Ой, не то слово :)