но я и не говорил о ней)

Если у бизнеса нет денег на разработку, то как они поднимут это проект? Пусть и монолит со старта

Пробили по реестру, он же в открытом доступе, но ты можешь по гпх работать без ип

но из налоговой можно узнать и о гпх, также могут пробить и узнать

Есть, но ограниченные ровно для того, чтобы хоть что-то запустить и проверить, что проект взлетит.

Если человек(что бывает редко) нашёл некий голубой океан(как например идея вб), ок тут надо херачить. Но это один случай из тысяч.

Поверь, на голубой океан ни ты ни я работать не будем) там придут ребята другого уровня и с другими связямм

Изначально вб делали вполне простые ребята. Но речь как раз про обычные проекты.

Хз, в ВБ попасть проще чем в Авито, и Авито вроде как прибыль приносит а ВБ убыточный

Хз, в ВБ попасть проще чем в Авито, и Авито вроде как прибыль приносит а ВБ убыточный

Наверное ты озон имел ввиду

определите "продумывать проект") отсюда начнем, но давайте во флудилке лучше

Если человек(что бывает редко) нашёл некий голубой океан(как например идея вб), ок тут надо херачить. Но это один случай из тысяч.

На уровне бизнеса, особенно если это модель стартапа, создаются десятки и сотни гипотез. MVP по гипотезам обычно пилится из говна и палок и всем плевать на архитектуру, важно как можно быстрее проверить будет ли гипотеза приносить деньги. Если этот MVP продается, дальше начинается калибровка под клиента, т.к. на этом этапе еще ни бизнес который продал, ни бизнес который купил толком не понимает как должен выглядеть продукт. Таких гипотез может проверяться сразу десяток параллельно. Если какая-то выстрелила, например на 1 доллар инвестиций, возврат 100 долларов, ресурсы перебрасываются на нее. Там ROI такой, что просто выкинуть готовый код и запилить новый уже с проработкой архитектуры и т.д. легче чем поддерживать костыльный начальный MVP. Если речь идет не о классической бизнес модели, а о стартапах, там об экономии никто не вспоминает, пока проект не подходит к этапу IPO.

На уровне бизнеса, особенно если это модель стартапа, создаются десятки и сотни гипотез. MVP по гипотезам обычно пилится из говна и палок и всем плевать на архитектуру, важно как можно быстрее проверить будет ли гипотеза приносить деньги. Если этот MVP продается, дальше начинается калибровка под клиента, т.к. на этом этапе еще ни бизнес который продал, ни бизнес который купил толком не понимает как должен выглядеть продукт. Таких гипотез может проверяться сразу десяток параллельно. Если какая-то выстрелила, например на 1 доллар инвестиций, возврат 100 долларов, ресурсы перебрасываются на нее. Там ROI такой, что просто выкинуть готовый код и запилить новый уже с проработкой архитектуры и т.д. легче чем поддерживать костыльный начальный MVP. Если речь идет не о классической бизнес модели, а о стартапах, там об экономии никто не вспоминает, пока проект не подходит к этапу IPO.

#вакансия #удаленно Всем здравствуйте! Ищу людей на вакансию #javascript #node Middle+ / Senior Fullstack / Backend JavaScript Developer (Node.js) Удалённо. ЗП от 3 000 до 7 000$. Мы – no-public команда, занимающаяся разработкой торговых ботов, арбитражных решений, автоматизацией, баунти-хантингом и мультиаккаунтингом. Обязанности: 🔹Разработка и поддержка функционала. 🔹Тестирование, улучшение алгоритмов. 🔹Участие в обсуждении архитектуры и реализации продукта. Требования: 🔹Опыт в обходе защит сайтов, антифрод-систем (Cloudflare, Akamai, деобфускация, фингерпринтинг). 🔹Знание Solana: парсинг, гейзеры, ноды, скоростные боты, снайперы, DCA, MEV, frontrun. 🔹Опыт разработки торговых ботов (wash trading/MM на биржах/перпетульных DEX через API или backend через куки). 🔹Работа с NFT маркетплейсами (Solana, EVM-сети). 🔹Навыки работы с нодами, DePIN, автоматизация работы с дедиками. Контакты: TG: @Anastasiia_Kaisheva

Правильно понимаю, что под гипотезой имеется ввиду, что найдена высоко маржинальная ниша? И в чём отличие проверки гипотезы от организации стартапа?

Стартап - это модель бизнеса нацеленная на быстрый рост, обычно в первую очередь за счет инвестиционных денег. Поиск ниши это предварительный этап стартапа. Гипотеза это предположение, что вот эта фича или продукт нужны рынку и ее будут активно покупать, т.е. вот эта вот штука позволит захватить долю рынка. Это предположение проверяется обычно минимальным функциональным продуктом, т.к. посмотрев макеты и шаблоны клиент может сказать что купит, а когда продукт готов, может оказаться, что клиент не готов покупать, т.к. ценность продукта не достаточна. В стартап модели бизнеса, все очень быстро меняется, поэтому где можно от чего-то избавиться и чем-то пожертвовать жертвуют. В идеальном мире, возможно можно было бы сделать сразу все идеально, но в реальности часто сталкиваешься с тем что большая часть работы это R&D и ты имеешь только общее направление.

Стартап - это модель бизнеса нацеленная на быстрый рост, обычно в первую очередь за счет инвестиционных денег. Поиск ниши это предварительный этап стартапа. Гипотеза это предположение, что вот эта фича или продукт нужны рынку и ее будут активно покупать, т.е. вот эта вот штука позволит захватить долю рынка. Это предположение проверяется обычно минимальным функциональным продуктом, т.к. посмотрев макеты и шаблоны клиент может сказать что купит, а когда продукт готов, может оказаться, что клиент не готов покупать, т.к. ценность продукта не достаточна. В стартап модели бизнеса, все очень быстро меняется, поэтому где можно от чего-то избавиться и чем-то пожертвовать жертвуют. В идеальном мире, возможно можно было бы сделать сразу все идеально, но в реальности часто сталкиваешься с тем что большая часть работы это R&D и ты имеешь только общее направление.

Стартап - это модель бизнеса нацеленная на быстрый рост, обычно в первую очередь за счет инвестиционных денег. Поиск ниши это предварительный этап стартапа. Гипотеза это предположение, что вот эта фича или продукт нужны рынку и ее будут активно покупать, т.е. вот эта вот штука позволит захватить долю рынка. Это предположение проверяется обычно минимальным функциональным продуктом, т.к. посмотрев макеты и шаблоны клиент может сказать что купит, а когда продукт готов, может оказаться, что клиент не готов покупать, т.к. ценность продукта не достаточна. В стартап модели бизнеса, все очень быстро меняется, поэтому где можно от чего-то избавиться и чем-то пожертвовать жертвуют. В идеальном мире, возможно можно было бы сделать сразу все идеально, но в реальности часто сталкиваешься с тем что большая часть работы это R&D и ты имеешь только общее направление.

сразу видно человека, кто много где поплавал, много чгео повидал :)

#вакансия #удаленно Всем здравствуйте! Ищу людей на вакансию #javascript #node Middle+ / Senior Fullstack / Backend JavaScript Developer (Node.js) Удалённо. ЗП от 3 000 до 7 000$. Мы – no-public команда, занимающаяся разработкой торговых ботов, арбитражных решений, автоматизацией, баунти-хантингом и мультиаккаунтингом. Обязанности: 🔹Разработка и поддержка функционала. 🔹Тестирование, улучшение алгоритмов. 🔹Участие в обсуждении архитектуры и реализации продукта. Требования: 🔹Опыт в обходе защит сайтов, антифрод-систем (Cloudflare, Akamai, деобфускация, фингерпринтинг). 🔹Знание Solana: парсинг, гейзеры, ноды, скоростные боты, снайперы, DCA, MEV, frontrun. 🔹Опыт разработки торговых ботов (wash trading/MM на биржах/перпетульных DEX через API или backend через куки). 🔹Работа с NFT маркетплейсами (Solana, EVM-сети). 🔹Навыки работы с нодами, DePIN, автоматизация работы с дедиками. Контакты: TG: @Anastasiia_Kaisheva

Во первых в Америке, например, сейчас среднее время выхода на прибыль стартапов 5-8 лет - насколько это быстро хз. Во вторых с чего вы взяли, что минимальных средств хватит, чтобы действительно проверить нужно ли это рынку?

Вот прям вижу картину сидит з-ся лид и пытается продать что то клиенту, который по инерции цепляется за старое. А если он и придёт что то тестировать, то обнаружит там что то забагованное и не приятное. Желание покупать такую фичу будет намного ниже чем если бы всё было сделано грамотно.

Смотря по какой схеме ты продаешь свой софт, если у тебя многомиллионный B2B контракт то с этим нет проблем, а клиент в B2C ну да. наверное уйдет, хотя и тут не всегда)

Контракт сначала надо получить. А ты приходишь к клиенту со своим фекальным изделием и просишь его раскошелиться.

К инвесторам. Я таких стартапов ‘на свои’ видел несколько штук

Ок, какой то бедолага заказал у тебя mvp , дал со старта пробный контракт. Дальше что?

Играет роль очень много факторов. Всё решает рынок и регуляторы. На рынке ты завязан в конкуренции и если долго будешь выбирать решение то тебя обойдут на повороте так сказать. Поэтому бизнес приходит и говорит: "Хочу зелёную кнопку, что бы при нажатии решала проблему 1, 2, 3." Как оно технически будет сделано обычно пофигу, главное что бы работало и желательно уже завтра и что бы не дорого. Но этими вопросами будет заниматься наёмный работник со стороны бизнеса который должен быть компетентен в выборе инструмента, который они хотят купить для решения своих проблем", а это не всегда так. Тут уж как собеседовали и как врал соискатель 😊. И это только малая часть относящаяся к рынку. А ещё есть регуляторы, в виде государства и других инстанций, которые приходят к тебе и говорят. "Привет Вася, расклад такой, если у тебя будет стоять отечественное ПО, то тебе субсидию дадим" - это пряник. А могут и с кнутом прийти, просто обязать и поставить сроки исполнения. И да, расскажите мне теперь про суппер продуманное решение, архитектуру и то что вы умнее других. 🙈

Затащил, быстро и дешево. Получаешь некоторые деньги.

занимаясь оверинжинирингом, архитектурными решениями на 10 лет вперед все чего ты добьешься это просреш все сроки. Ты всегда напираешь на то что вот, если сделать сразу без учета многомилдионной нагрузки и по книжкам, то все кранты проекту, но это далеко не так, проект развивается, его переписывают додеывают разные люди постоянно, переносят на другие технологии и т.д. это бесконечный процесс улучшений под требования, если в требованиях нет заоблачных RPS то и не надо тратить на это время также и с архитекутрой и т.д. ты не можешь знать наперед, надо делать что надо сейчас

То есть на фундамент из говна и палок начинают ставить небоскрёб?)

Что имеется ввиду под отечественным по?

То есть на фундамент из говна и палок начинают ставить небоскрёб?)

это некорректная аналогия, в отличии от дома, ты можешь переписать частично какие то вещи, оптимизировать когда нужно, проект твой может и не дожить до стадии "небоскреба", так зачем тратить на это время и деньги?

то что тебя обязали использовать решение, которое тебе может не нравиться

Он и не доживёт) Если не первый на рынке, то люди будут выбирать между твоим решением и другими.

Представь что ты хочешь построить дом в деревне, ты точно не знаешь какой, у тебя есть 1 мл рублей, и надо сразу хороший фундамент под такой дом, да? Ты заказываешь фундамент на 100 метровый дом за 900т.р., тебе его делают по всем правилам, а потом на остаток денег ты ставишь на него хозблок, т.к. ни на что другое денег и времени не осталось, и как тебе твой дачный дом, збсь?))

ну вот ты сам что выберешь? крутой фундамент и хозблок или законченный панельный дом на сваях?

Архитектура это про компромисы, всегда можно найти ещё какие то решения.

как ты их найдешь если требования могут меняться каждый день?

#вакансия #удаленно Всем здравствуйте! Ищу людей на вакансию #javascript #node Middle+ / Senior Fullstack / Backend JavaScript Developer (Node.js) Удалённо. ЗП от 3 000 до 7 000$. Мы – no-public команда, занимающаяся разработкой торговых ботов, арбитражных решений, автоматизацией, баунти-хантингом и мультиаккаунтингом. Обязанности: 🔹Разработка и поддержка функционала. 🔹Тестирование, улучшение алгоритмов. 🔹Участие в обсуждении архитектуры и реализации продукта. Требования: 🔹Опыт в обходе защит сайтов, антифрод-систем (Cloudflare, Akamai, деобфускация, фингерпринтинг). 🔹Знание Solana: парсинг, гейзеры, ноды, скоростные боты, снайперы, DCA, MEV, frontrun. 🔹Опыт разработки торговых ботов (wash trading/MM на биржах/перпетульных DEX через API или backend через куки). 🔹Работа с NFT маркетплейсами (Solana, EVM-сети). 🔹Навыки работы с нодами, DePIN, автоматизация работы с дедиками. Контакты: TG: @Anastasiia_Kaisheva

Можно конкретные примеры?

Например?

ну а какой пример когда все развалилось из-за плохих решений? Ну серьезно, куча видео где хуисосят код ядра линуска, или продуктов майкрософт, в яндексе куча неоптимлоьно написанного говна но работает же, денег приносит и норм

То есть на фундамент из говна и палок начинают ставить небоскрёб?)

нет, нельзя. ни о ком хорошо или плохо я говорить не стану. Да это и не требуется для изложенного мной выше спича. Я лишь подсветил, что "продуманное архитектурное решение" - это сказочка про козявочку. Как правило успешные люди выстреливают не продуманным архитектурным решением, а прибыльной(гениальной) идеей, случаем, связями, деньгами.

Тут, кажется, немного надо пересмотреть вектор: делать хорошо надо всегда. И с этим никогда никто не спорит (и хочет это "хорошо"). Основная проблема - а что такое хорошо? Тот же самый "хороший" процесс написания кода для джуна, мидла, сеньора будет отличаться. Тоже самое и с проектами, которые могут быть на разной стадии и с разными целями: - любимое импортозамещение. Тут очевидно, нужно сохранить преемственность и достоинства(с недостатками?) прошлых решений. И если "там" был монолит и коробка, то нет смысла изобретать SOA. - проект может быть проверкой гипотезы (аля гендир сгонял на конференцию, получил инсайд и такой: сейчас проверим). Тут очевидно нужно сделать быстрее, чем с детальной проработкой. - проект может быть в стадии переписывания. Тут всегда весы "за" и "против". Всегда можно переписать на плюсы и получить прирост к скорости, но команда у тебя джавистов. И что теперь, разгонять? А может быть и да, не знаю. - проект может быть никому не нужен (и такое бывает) и там "делать хорошо" == всплывание косяков коллектива. А за это уже по головке не погладят сами коллеги (они же понимают что происходит). -- Итого, тут промелькнуло "архитектура - это всегда компромиссы". Я бы даже обобщил: любая инженерная штука - компромиссы. Достаточно посмотреть на всякие механические изделия и там обычно "круто сделали ядро" и "навалили что осталось". В заключении, личное имхо: делать надо всегда хорошо. Просто "хорошо" зависит не от количества зелёных тестов или RPS, а от требований. Любая система создаются не в вакууме, а в экосистеме других информационных систем. Выдвинули требования - обозначили технических подход, реализовали. Удовлетворяет требованиям? Да. Прибыль/ROI и прочее есть? Да. Ну и отлично, сэкономленные время и силы можно потратить на тех. долг или же на дизайн макетов. Своим студентам давно перестал говорить в категориях "хорошо/плохо". Предпочитаю ориентироваться на фразы "более подходящее решение и менее подходящее решение".

ну а какой пример когда все развалилось из-за плохих решений? Ну серьезно, куча видео где хуисосят код ядра линуска, или продуктов майкрософт, в яндексе куча неоптимлоьно написанного говна но работает же, денег приносит и норм

именно поэтому "хорошо" начинается с анализа требований

А времени на анализ нет, тк менеджер пообещал сделать ещё вчера…

Тут, кажется, немного надо пересмотреть вектор: делать хорошо надо всегда. И с этим никогда никто не спорит (и хочет это "хорошо"). Основная проблема - а что такое хорошо? Тот же самый "хороший" процесс написания кода для джуна, мидла, сеньора будет отличаться. Тоже самое и с проектами, которые могут быть на разной стадии и с разными целями: - любимое импортозамещение. Тут очевидно, нужно сохранить преемственность и достоинства(с недостатками?) прошлых решений. И если "там" был монолит и коробка, то нет смысла изобретать SOA. - проект может быть проверкой гипотезы (аля гендир сгонял на конференцию, получил инсайд и такой: сейчас проверим). Тут очевидно нужно сделать быстрее, чем с детальной проработкой. - проект может быть в стадии переписывания. Тут всегда весы "за" и "против". Всегда можно переписать на плюсы и получить прирост к скорости, но команда у тебя джавистов. И что теперь, разгонять? А может быть и да, не знаю. - проект может быть никому не нужен (и такое бывает) и там "делать хорошо" == всплывание косяков коллектива. А за это уже по головке не погладят сами коллеги (они же понимают что происходит). -- Итого, тут промелькнуло "архитектура - это всегда компромиссы". Я бы даже обобщил: любая инженерная штука - компромиссы. Достаточно посмотреть на всякие механические изделия и там обычно "круто сделали ядро" и "навалили что осталось". В заключении, личное имхо: делать надо всегда хорошо. Просто "хорошо" зависит не от количества зелёных тестов или RPS, а от требований. Любая система создаются не в вакууме, а в экосистеме других информационных систем. Выдвинули требования - обозначили технических подход, реализовали. Удовлетворяет требованиям? Да. Прибыль/ROI и прочее есть? Да. Ну и отлично, сэкономленные время и силы можно потратить на тех. долг или же на дизайн макетов. Своим студентам давно перестал говорить в категориях "хорошо/плохо". Предпочитаю ориентироваться на фразы "более подходящее решение и менее подходящее решение".

косой менеджмент мы здесь не обсуждаем, но имеем в виду, да? :)

Не косой, а средне российский)

позвольте вас уверить: он не "российский", а "общемировой"

Не дописал и такую мысль: а ведь прибыль может и не придти, возврата инвестиций не случится, а на проекте написано все в ООП, по DDD и прочим XXX и YYY. Можно ли выдвинуть гипотезу, что это "бест практисы" плохие (если учитывать идеальную реализацию от исполнителя)? Конечно же нет. Все находится во взаимосвязях,. контекстах, ограничений и требований.

иногда бестпрактис хороши только в книжках, чистый код Мартина уже разваливали по перформансу, чистота написанного кода != эффективность, то же самое и с архитектурой, нужно понимать что и зачем ты делаешь, а не бездумно следовать