Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
Спасибо за статью
Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений
Может статья и хорошая, но дальше читать не стал.
Что за фэйл с Бэкбон? Можно поподробнее?
Как в бэкбоне может что-то подтекать? Расскажите, мне действительно интересно. Там кода мышка наплакала, в котором разобраться и поправить если что нет так займет полчаса-час. Бэкбоне предоставляет только каркас по сути и базовые вещи типа роутинга и моделей. Честно не знаю где там что-то может течь.
Пример: частенько получается так что есть вложенные вьюшки, родительская внезапно удаляется, и вместо неё создаётся новая с таким же, или большим, количеством потомков, и так с довольно высокой частотой — GC просто не успеет собрать мусор.
Вьюшки надо удалять каскадом, каждый родитель должен уметь удалять созданные им вьюхи. Бекбон сам этого не делает и никогда не обещал этого делать. Это криворукость разработчиков, бэкбон тут ни при чем. Пишешь вьюху — всегда делай в ней destroy метод. Создаешь вложенные вьюхи — удаляй их при дестрое. Подписываешься на события — отписывайся при дестрое. Бэкбон никогда не обещал делать этого за разраба, тем он и ценен, 100% гибкость решений, но надо все аккуратно кодить. Это не плохо и не хорошо, просто вот такая у него ниша.
Увы, но вывод каков — писать сразу все серьезно и спланировано на всех возможные варианты развития?
Точка «ой, у нас все плохо, мы этого не закладывали в архитектуру» всегда будет, вопрос, как ее встретить и что с ней делать. Бежать с нуля переписывать — отличный вариант, только надо не забывать о поддержании старой версии.
А с Netflix-ом я лично не знал, что начинали они с пиратской раздачи видео всем друзьям )))
Точка «ой, у нас все плохо, мы этого не закладывали в архитектуру» всегда будет, вопрос, как ее встретить и что с ней делать. Бежать с нуля переписывать — отличный вариант, только надо не забывать о поддержании старой версии.
А с Netflix-ом я лично не знал, что начинали они с пиратской раздачи видео всем друзьям )))
Да — в основе любого бизнеса лежит простая идея — уговорить некую условную тетушку купитьза $10 нечто, о чем она 5 мин назад и не подозревала.
Если число тетушек растет с течением времени, то бизнес удачен, иначе это просто разводка
Если число тетушек растет с течением времени, то бизнес удачен, иначе это просто разводка
Печально, что менеджмент превалирует над техническим процессом. Понимаю, «белые воротнички» хотят покупать лексусы и катать гламурных див на дискотеки с мохито… Только какое отношение всё это имеет к производству программного продукта? Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации. И сколь бы она не влияла на продажи, она не должна оказывать влияния на программистов, т.к. от симбиоза программиста и менеджера появляются недопрограммисты-недоменеджеры. Каждый должен заниматься своим делом. И хорошо бы эти кухни окончательно разделить. Нужен продукт? Заказывайте его разработку. А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь! Только не надо скулить о том, что «весь мир так живёт». Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.
В проектной деятельности код стоит на последнем месте, основной критерий это соответствие требованию заказчика, а с точки зрения кода оно абсолютно невзыскательное. Заказчик пишет ТЗ в стиле: «Нужен импорт данных из такой то системы», «Аналитика по таким то объектам», «Сбор данных из контроллера».
Проектный менеджер в такой ситуации — царь и бог, а остальные просто действуют под его указку, захочет сменит всю команду, главное добиться тех основных требований, что указаны в ТЗ. Дальнейшие баги и проблемы, являются лишь пунктом поддержки данного решения.
Для SaaS решений обратный подход.
Проектный менеджер в такой ситуации — царь и бог, а остальные просто действуют под его указку, захочет сменит всю команду, главное добиться тех основных требований, что указаны в ТЗ. Дальнейшие баги и проблемы, являются лишь пунктом поддержки данного решения.
Для SaaS решений обратный подход.
«Печально, что менеджмент превалирует над техническим процессом.»
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Ну произвели вы чугунную рельсу. Ну есть у вас 3 квадратных километра складов, забитых рельсами. И что дальше? Никому вы из не продадите, все хотят стальные.
Производство — лишь малая часть работы. Равно как и беготня по клиентам с просьбами купить вашу рельсу, то есть продажи.
А в основе… в основе менеджмент. Бизнес-идея. Удовлетворения потребностей заказчиков. Ну скажем чугунная рельса, по которой поезд едет тихо.
Так что в идеале — программер должен понимать, зачем он делает ту или иную фичу, что она дает при маркетинге. А если программер не понимает ЦЕЛИ написания кода, не понимает, какие характеристики кода важны, а какие нет — хреновый получается код.
При выборе между памятью и скоростью, между универсальностью и эффективность, между отлаженностью и скоростью разработки, важнее всего понимать маркетинг.
P.S. Я как раз программер, а не маркетолог. Но я хочу, чтобы наши изделия продавались, а не писать свой код «в стол».
Производство — лишь малая часть работы. Равно как и беготня по клиентам с просьбами купить вашу рельсу, то есть продажи.
А в основе… в основе менеджмент. Бизнес-идея. Удовлетворения потребностей заказчиков. Ну скажем чугунная рельса, по которой поезд едет тихо.
Так что в идеале — программер должен понимать, зачем он делает ту или иную фичу, что она дает при маркетинге. А если программер не понимает ЦЕЛИ написания кода, не понимает, какие характеристики кода важны, а какие нет — хреновый получается код.
При выборе между памятью и скоростью, между универсальностью и эффективность, между отлаженностью и скоростью разработки, важнее всего понимать маркетинг.
P.S. Я как раз программер, а не маркетолог. Но я хочу, чтобы наши изделия продавались, а не писать свой код «в стол».
Статья кидает из крайности в крайность, но как тема к размышлению — хороша.
По поводу MVP — путается прототип для тестирования спроса и 1-я версия уже добротно сваянного продукта (тоже с с минимум необходимых функций).
По поводу MVP — путается прототип для тестирования спроса и 1-я версия уже добротно сваянного продукта (тоже с с минимум необходимых функций).
Так это ж классика: «good marketing and sales always beat great technology» (хороший маркетинг и продажи всегда победят отличную технологию).
После прочтения почему-то сразу вспомнились pied piper и «коробка».
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализацииПростите, а где там такое написано? Друг интересуется, я было обрадовался, смотри мол, пофиг на твой левел, главное — маркетинг. А по ссылке какой-то мутный перечень, без сводки. Запросил там отчет, получил сводку. В ней тоже нет 5%.
Поэтому резонный вопрос, откуда взята цифра? От верблюда?
По данным CB Insights, только 5% стартапов прогорают по причине слабой технической реализации. Большинство провалов случается в результате неверного позиционирования продукта, отсутствия грамотной маркетинговой стратегии, плохих специалистов по продажам, неверной бизнес-модели. Наличие или отсутствие высококвалифицированных инженеров практически не играет никакой роли, делают вывод исследователи.
Ну все верно, обычно я исхожу из того, что на успех проекта инженерная составляющая влияет примерно на 30%, но время идет, создается больше удобных инструментов, фактически продукты производить легче и роль инженеров-программистов в успехе продукта постоянно падает.
я всё удивляюсь, при таком количестве заготовок кода в базах гугла и гитхабов, где нейросеть-программист, которая предложит лучший по качеству код, сама его реплицирует и заставит самосовершенствоваться?
по сути, стиральная машинка, девальвировавшая ценность труда прачки.
и все эти годы учебы программированию следующим поколением землян будут восприниматься как архаичная и бесполезная трата времени, вроде просмотра тв. если нейросеть-программист оставит землян в живых.
по сути, стиральная машинка, девальвировавшая ценность труда прачки.
и все эти годы учебы программированию следующим поколением землян будут восприниматься как архаичная и бесполезная трата времени, вроде просмотра тв. если нейросеть-программист оставит землян в живых.
«Если обратиться к примеру самых успешных технологических стартапов мира (Uber, Airbnb, Snapchat, Pinterest и прочие), мы не увидим сложных программных решений.»
Да ладно не увидим?
Uber Engineering Blog:https://eng.uber.com/
Да ладно не увидим?
Uber Engineering Blog:https://eng.uber.com/
Всю статью можно свести к одной фразе:
Лучше сначала надо что-то продать, а потом начать разрабатывать, чем сначала разработать, а потом пытаться продать.
Лучше сначала надо что-то продать, а потом начать разрабатывать, чем сначала разработать, а потом пытаться продать.
это же классическая история про двух программистов, когда один пилил продукт несколько лет до идеала, а второй каждые полгода сыровяленную требуху апдейтил. когда первый свой продукт явил миру, оказалось, что он никому не нужен.
ибо: у всех стоит продукт второго программиста, им нравится, что он постоянно обновляется и поддерживается, а главное — в нем уже появилось то новое, что в «идеальный продукт» первого не вкрячишь никак — только заново писать всё.
финита.
//это было краткое содержание статьи методом «притчи»
ибо: у всех стоит продукт второго программиста, им нравится, что он постоянно обновляется и поддерживается, а главное — в нем уже появилось то новое, что в «идеальный продукт» первого не вкрячишь никак — только заново писать всё.
финита.
//это было краткое содержание статьи методом «притчи»
К сожалению, выигрывает тот, кто первый вышел на рынок. По этому метод разработки «хуяк-хуяк и в продакшен» всегда будет самым востребованным, несмотря на высокие риски. Есть слабая надежда на хорошие статически типизированные языки, типа Haskell или Rust, но что бы их применение не замедляло разработку, требуются очень опытные программисты.
Понимаете, не важно, какие у тебя программисты, главное — какие продавцы!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кого волнуют баги продукта, если он успешно продается