Все чаще и чаще думаю, что время то идет и идет, и может уже хватить "работать на дядю"...
в тоже время самому становится "дядей" нет сил и желания,
поэтому как вариант, собрать команду энтузиастов, работающих в свободное время, и пилить общий проект-стартап, который может когда-нибудь выстрелит и будет нас кормить.
Хорошая идея)
Идей море. Реализаций еще больше.
Все чаще упираюсь в бюрократию.
Так что буду рад поработать в команде.
Если идея будет стоящая, то я тоже не против поучаствовать!
Я тоже рад бы поучаствовать. + Могу еще подтянуть пару проггеров по ходу дела.
Короче прогеров хватает. Программировать нечего!
Так собственно в этом вся загвоздка :)
Пишите если что :)
В том то и загвоздка что не знаем что писать 
Предлагай идею!
Самый простой вариант это написать популярное приложение, которое уже есть и сделать его качественнее. А учитывая, что под капотом у многих приложений собрались тысячи строк "кода" написанные индийскими командами за долгие годы в режиме "вроде запускается", то это вообще не проблема и вопрос лишь в свободном времени, т.к. некоторые идеи можно реализовывать по году.
Да все это понимают. Что надо взять что-то популярное и сделать лучше. Надо найти это ЧТО, чтобы заинтересовало всех. Если проект не будет приносить удовольствия, то он должен тогда компенсировать затраченное время $$$. А так как тут у всех интересы разные, то будет крайне сложно найти проект который всех заинтересует
Ктсати, чтобы уменьшить масштаб поисков - проект ни в коем случае не должен быть "для разработчиков".
Это тупиковая темя. Знаю что многие делали и мечтаю сделать супер крутой тул для облегчения разработки, но это всего лишь поможет удовлетворить собственное ЧСВ и не больше. Разрабы самые плохие клиенты. Большая часть (кто может) скорее напишет свое решение потому что будет считать решение другого глючным и не идельным. Остальная часть (не может сделать такое же решение) тупо будет использовать бесплатно. Сужу по себе. Ни разу не благодарил, тем более не платил за использование даже условно бесплатных либ и тулов для разработки. Так что на эту тему сразу табу с моей стороны, потому что кроме потраченного времени и звездочек на github профита будет 0!
Если делать, то что-то для простых людей, которые могут и хотят тратить деньги на сервис который облегчит их жизнь (и то что они сами не смогут сделать лучше)
Ну, идеи тут как-раз упираются в то, что программисты осилить не способны. Не потому, что глупые, а наоборот.
Программа для клиента должна быть 100% написана для идиотов. Чтобы она смогла сопроводить процесс клиента, даже если посадить за компьютер макаку. А идей тут у меня масса. Для этого и полез в разработку вместо своего инженерства.
Первая идея: система управления складом. Могу поспорить, что сейчас все прогеры скажут а кули тут? Есть же готовое Warehouse. Но в ответ я на пальцах одной руки позагибаю аспекты, которые нужны клиенту и о которых программисты могут даже не догадываться. Кстати, клиент тоже.
SF - это в первую очередь CRM, но сейчас этих crm написано, как говна за баней. Вот лично мое мнение - надо вводить ERP в приложения. Если есть у клиента какое-то производство или документооборот - вот тут и надо работать. Уменьшая его затраты - ты увеличиваешь свою зарплату.
:D:D:D:D
Чтобы написать систему управления складом надо знать как работает склад до винтиков. Программиста с такими знаниями не найти. Значит надо искать клиента. А значит это будет очередной из 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. Покупайте - не пожалеете.
Отсюда делаем вывод: ты можешь написать любое приложение, хоть по стимуляции эрекции у кунгурских хомячков или пособите по шитью жопок муравьев бисером до безобразия. Без грамотного менеджмента - это никому не нужно.
В точку
Поэтому большенство программистов всю жизнь и работают на ЗП хотя могут с легкостью написать клон facebook за пару месяцев. Просто проект это ничто. Нужен бизнес план, менежмент, потом продажи. У меня столько замечательных проектов умерло в стадии бета из-за этого :(
Ну, или выводишь на стартап и делишься прибылью с тем, кто может продать говно так, чтобы люди еще от удовольствия причмокивали
Все эти размышления конечно хороши и все это понимают, но суть данной темы которую пытается предложить
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, как продвигается дело? Идеи для стартапа появились?
с группой заинтересовавшихся участников форума мы уже обсудили некоторые идеи и мысли по этой теме.
ситуация такая,
(1) люди готовы немедленно втянутся в проект который уже имеет финансирование. У меня такого пока нет. И главное, когда он будет, это будет фактически просто аут-сорсенный проект, по имплиментации какой то очень частной бизнес логики, он будет скучным (как и все подобные проекты) и иметь минимальный потенциал реюзабилити. Просто обычная работа, что тоже прекрасно, но это не то о чем тема.
(2) а тема - "проект на будущее", т.е. такой проект за который пока никто не платит, но он тебе интересен по содержанию, ты питаешь к нему какие-то искренние чувства.
(3) и у каждого уже оказался какой-то собственный проект, над которым люди уже работают в свободное время, мы немного обсудили их, и просто не нашли проект, который мог бы заинтересовать других участников, не нашли "общего" проекта.
(4) что касается меня, то пока я объяснял другим участником суть моего проекта, то я понял, что могу и сам его начать и довести до уровня рабочего демо, что я и сделал примерно за шесть выходных. Так что оказалось, что просто поговорить на тему было очень продуктивным.
В этом и суть командной работы. Не обязательно чтобы все были 100% разрабами и кинулись с головой в разработку. Иногда просто нужен просто человек которые понимает проект и поможет мотивировать на работу. Иногда нужен человек который просто сделает какую-то мелочь которая не важна в рамках всего проекта, но отнимает кучу времени и сил (дизайн, стили к примеру). А так любой здесь может запилить facebook за пару выходных. К примеру видел недавно прототип проекта одного нашего коллеги (запиленный за пару дней), но который даст форум многим популярным существующим сервисам в нашей стране. А всего лишь у человека появилась мотивация, время и желание сделать инструмент, которые решит проблему актуальную для него в данное время.
