Собрать команду энтузиастов и делать общий проект на будущее?

Собрать команду энтузиастов и делать общий проект на будущее?

Все чаще и чаще думаю, что время то идет и идет, и может уже хватить "работать на дядю"...

в тоже время самому становится "дядей" нет сил и желания,

поэтому как вариант, собрать команду энтузиастов, работающих в свободное время, и пилить общий проект-стартап, который может когда-нибудь выстрелит и будет нас кормить.

Хорошая идея)

Идей море. Реализаций еще больше.

Все чаще упираюсь в бюрократию.

Так что буду рад поработать в команде.

Если идея будет стоящая, то я тоже не против поучаствовать!

Я тоже рад бы поучаствовать. + Могу еще подтянуть пару проггеров по ходу дела.

Короче прогеров хватает. Программировать нечего!

Dmitry Shnyrev
Короче прогеров хватает. Программировать нечего!

Так собственно в этом вся загвоздка :)

Пишите если что :)

Developer
Пишите если что :)

В том то и загвоздка что не знаем что писать Предлагай идею!

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

Да все это понимают. Что надо взять что-то популярное и сделать лучше. Надо найти это ЧТО, чтобы заинтересовало всех. Если проект не будет приносить удовольствия, то он должен тогда компенсировать затраченное время $$$. А так как тут у всех интересы разные, то будет крайне сложно найти проект который всех заинтересует

Ктсати, чтобы уменьшить масштаб поисков - проект ни в коем случае не должен быть "для разработчиков".
Это тупиковая темя. Знаю что многие делали и мечтаю сделать супер крутой тул для облегчения разработки, но это всего лишь поможет удовлетворить собственное ЧСВ и не больше. Разрабы самые плохие клиенты. Большая часть (кто может) скорее напишет свое решение потому что будет считать решение другого глючным и не идельным. Остальная часть (не может сделать такое же решение) тупо будет использовать бесплатно. Сужу по себе. Ни разу не благодарил, тем более не платил за использование даже условно бесплатных либ и тулов для разработки. Так что на эту тему сразу табу с моей стороны, потому что кроме потраченного времени и звездочек на github профита будет 0!
Если делать, то что-то для простых людей, которые могут и хотят тратить деньги на сервис который облегчит их жизнь (и то что они сами не смогут сделать лучше)

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

Программа для клиента должна быть 100% написана для идиотов. Чтобы она смогла сопроводить процесс клиента, даже если посадить за компьютер макаку. А идей тут у меня масса. Для этого и полез в разработку вместо своего инженерства.
Первая идея: система управления складом. Могу поспорить, что сейчас все прогеры скажут а кули тут? Есть же готовое Warehouse. Но в ответ я на пальцах одной руки позагибаю аспекты, которые нужны клиенту и о которых программисты могут даже не догадываться. Кстати, клиент тоже.

SF - это в первую очередь CRM, но сейчас этих crm написано, как говна за баней. Вот лично мое мнение - надо вводить ERP в приложения. Если есть у клиента какое-то производство или документооборот - вот тут и надо работать. Уменьшая его затраты - ты увеличиваешь свою зарплату.

yurick
как говна за баней.
:D:D:D:D

yurick
Первая идея: система управления складом.

Чтобы написать систему управления складом надо знать как работает склад до винтиков. Программиста с такими знаниями не найти. Значит надо искать клиента. А значит это будет очередной из 1000 проектов под определенного клиента, который 100% нафиг не нужен будет другим клиентам потому что у них все по другому. Это не проект для команды энтузиастов, а обычный бизнес проект. Бесплатно я точно такое пилить не буду.
К тому же таких сервисов уже проверенных временем и со штатом специалистов море. Создать что-то конкурентное нереально!

Вот первый прогер отписался. Я же сразу написал - клиент даже сам не знает чего хочет, и далеко не факт, что чего он хочет - это правильно. Программист ложит пожелания и мысли клиента к код, а надо чтобы реализовывались процессы, которые необходимы для правильной работы.

1. Клиент может и не знать об адресации склада. С чего бы ему знать, если об этом пишут в учебниках и они не для кладовщиков.
2. Клиент может и не знать о необходимом внутреннем перемещении номенклатуры, исходя из месячных потребностей производства.

Не все можно перевести в программу, но процентов на 80 можно удовлетворить желания всех клиентов, даже если они о них и не подозревали. Тут много стопорит сам физический процесс, есть куча формул и математики в организации того-же склада, начиная от типа покрытия и до размеров ворот и т.д.

Вот реальный аспект, который нужен любому складу, но про него не всегда знают клиенты:
1. Есть физическая адресация номенклатуры, например: адрес номенклатуры "А-16-32". Это стандартная цифро-буквенная адресация. А - номер стойки, 16 - номер секции в стойке, 32 - номер ячейки в стойке. Кладовщик, согласно коду, найдет на складе любую вещь.
2. Процесс, о котором забывает любой клиент - это физическое перемещение номенклатуры. Система выявила, что номенклатура по адресу "A-16-32" имеет месячный оборот 1000 ед. А номенклатура с адресом "S-17-48" имеет месячный оборот 10000 ед. Кладовщику до первого адреса идти надо 1 минуту, а до второго - 10. Разумно ли переместить номенклатуру? Разумно - тогда мы экономим время на сбор и поиск и увеличиваем эффективность работы склада без найма второго кладовщика. Клиенту это выгодно? Выгодно. Знал он о такой возможности? Скорее всего нет.
И таких аспектов масса. И их реализация - это конкурентное преимущество продукта.

Любой продукт начинается с анализа конкурентов.
Ты уверен что в тех популярных решениях что представлены на рынке такого функционала нет?
И до того момента как дойдешь до реализации пунктов 1 и 2 надо еще будет написать 100500 стандартных фич обычного склада. К тому же ты не учел один момент - продукт должен быть НЕ для постсоветского рынка и все знания о НАШИХ складах и НАШЕМ документообороте можно выкинуть

Как бы суммируя то что я хочу сказать система складского документооборота это тухлое дело. Склады это очень маленький, скудный рынок который давно поделен. Чтобы туда соваться и иметь успех у тебя минимум должен быть свой склад и опыт уровня Amazon.

Если делать что-то то надо делать для простых людей. Таких как мы. Вот на что ты будешь тратить деньги каждую неделю/месяц/год. Вот о чем надо думать и куда надо лезть. Люди хотят покупать продукты/вещи - сделай систему интернет торговли и доставки. Людям надо лечиться - сделай сервис по поиску врачей и онлайн записи. Людям надо каждый год отдыхать - сделай тур-сервис.

А большенство складов как были с бумажным документооборотом, так они с ним еще и останутся на ближайщие лет 20 (я про совок) и нафиг не нужны будут твои супер системы автоматизации кладовщиков.

Вот, мы плавненько пришли к тому, что чтобы мы не написали - это нафиг никому не нужно. Как делают маркетолухи? Правильно, берут кусок говна. Вешают на него ярлык "Соответствие ISO 9001" и кричат на всех углах - только наше говно соответствует ISO 9001. Покупайте - не пожалеете.
Отсюда делаем вывод: ты можешь написать любое приложение, хоть по стимуляции эрекции у кунгурских хомячков или пособите по шитью жопок муравьев бисером до безобразия. Без грамотного менеджмента - это никому не нужно.

yurick
Без грамотного менеджмента - это никому не нужно.

В точку
Поэтому большенство программистов всю жизнь и работают на ЗП хотя могут с легкостью написать клон facebook за пару месяцев. Просто проект это ничто. Нужен бизнес план, менежмент, потом продажи. У меня столько замечательных проектов умерло в стадии бета из-за этого :(

Ну, или выводишь на стартап и делишься прибылью с тем, кто может продать говно так, чтобы люди еще от удовольствия причмокивали

Все эти размышления конечно хороши и все это понимают, но суть данной темы которую пытается предложить
Den Brown

Den Brown
собрать команду энтузиастов, работающих в свободное время, и пилить общий проект-стартап, который может когда-нибудь выстрелит и будет нас кормить.

Так что продолжаем искать такой проект.

Уже откинули:
- тулы для разрабов
- узкоспециализированные темы типа "автоматизация склада".

Какие еще будет предложения?

https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000DrzkrUAB

вот это была моя идея для app exchange - построил модель и архитектуру - сел писать и забросил на изначальной стадии )))) судя по описаниют они конечно пошли немного дальше и походу используют свой клауд для хранения пользовательских данных, видимо ценник позволяет.
очень распостраненная проблема, для которой приходилось не раз запиливать костыли - нехватка 20 полей для history tracking.
Для толкового app exchange приложения надо использовать метадата API чтобы динамически создавать триггера и тест к ним.

на ап эксчандже берут деньги за неизвестно что , вот например я так понимаю приложение просто дает доступ к обьекту к которому нет напрямую доступа (селектит и показывает юзеру). Смотрим ценник.
https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FvIxRUAV
тут отдельный вопрос покупает ли это ктото, потому что отзывов 0. но это не всегда показатель что продаж нет. на демо приложении (таком же но бесплатном) 11 отзывов есть.

в общем на мой взгляд надо писать решения к бизнес-задачам. типа вот приведенных выше.

ничего не мешает например найти какойто простой пакедж который продается с неадекватным ценником и сделать решение той же проблемы дешевле

Опять же оба приложения из разряда dev tools, про которые я говорил - дохлый номер.
Проект с программистом врядли будет использовать эти приложения - проще и надежнее написать самому.
Крупные проекты тоже врядли доверят свои данные третьей стороне (непонятному клауду), хотя на крупных проектах
100% есть свои программисты, поэтому сработает пункт номер один.
Простым клиентам хватит и стандартных 20 полей.

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

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

Эти 2 пакета выше решают именно бизнес проблемы. В том числе security and compliance problems. У разработчика не может стоять проблема трекинга 20+ полей если это прямо не заказывает бизнес. Я бы отнес к dev tools только приложения для автоматического написания тестов (такое есть вроде), Деплоймент тулы, гит автоматизации и т.д.

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

Андрей
вопрос покупки пакета это вопрос экономической целесообразности. Часто гораздо выгоднее что то купить готовое чем пилить своё даже при наличии девелоперов.

Спорный вопрос! Уже не раз наблюдал как большие проекты обжигались этим. Несмотря на красоту и быстроту развертывания сторонне решение это бомба замедленного действия. Во первых это баги которые никто не будет спешить фиксить по вашему первому зову, а во-вторых про кастомизации фич забыть. Сколько я уже костылей написал чтобы добавить в сторонние используемые либы хотелки клиентов. А столько раз говорил что это невозможно и получал минус себе в карму. И пришел я к выводу - лучше самому написать чем использовать что-то стороннее.

Недавний пример - клиент захотел на UI datepicker. Даже прислал JS либу готовую для использования. Прикрутили за пять минут. А через месяц клиент присылает требования - нужно дизейблить дни по условиям и подсвечивать дни в определенные цвета и паттерны. Естественно либа не поддерживает это из коробки. Шо делать?

да, Дима, это всё правда. У пакеджей полно ограничений и они очень быстро начинают бесить.
Смотри с другой стороны : у сэйлсфорса например тоже полно ограничений, клиент же не садит тебя писать сэйлсфорс с нуля а выживает с ограничениями которые есть. Вопрос экономической целесообразности и не более того. Так же и с покупкой пакеджа. Я бы посмотрел на клиента который сел бы писать свой CPQ вместо покупки.

если ты видишь пакедж на апп эксчандже и у него есть отзывы - ктото сегодня платит $ за его использование. Местами, очень хорошие $.

тут конечно вопрос в продажах, а продажников тут у нас на форуме не найти. Можно написать идеальный пакедж и не продать никому. Можно написать непонятно что и уметь впаривать его не шарящим клиентам и не плохо выгадывать каждый месяц на подписках.

Андрей
Можно написать идеальный пакедж и не продать никому. Можно написать непонятно что и уметь впаривать его не шарящим клиентам и не плохо выгадывать каждый месяц на подписках.

Правильно говоришь!
Надо сначала продать, а уже потом кодить!!!

Den Brown, как продвигается дело? Идеи для стартапа появились?

Interesting information? Help us, post link to social media..