Я пришёл к такой схеме на сложных ERP-проектах, которые длятся по 6–12 месяцев и требуют около 500 часов работы.
Предварительная оценка — бесплатно, но она приблизительная.
Ставка за час работы фиксируется в договоре и не изменяется в течение какого-то срока, например года, при условии своевременной оплаты со стороны клиента.
Клиент платит блоками по 150 тыс. рублей. Каждую неделю отправляется акт о выполненных работах. Задача за первые два транша (то есть за 300 тыс., что составляет примерно треть проекта) — выйти на работающий функционал, пригодный для запуска в эксплуатацию.
В договоре указывается, сколько часов в месяц мы гарантированно уделяем этому проекту (обычно 60–90).
Также в договоре описывается общая схема блоков и прописываются точки, в которых мы заранее видим, что клиент может не справиться. Например, если он говорит, что его сотрудники будут заполнять какую-то конскую форму, а мы по опыту знаем, что не будут — так и фиксируем это в договоре.
Стартовая эксплуатация оформляется актами, в которых указано количество заказов, расчётов и прочих операций, проведённых командой заказчика в новой системе.
После этого принимаются уточнения по проекту со стороны клиента (ранее они не рассматриваются, потому что до реальной эксплуатации — это просто фантазии), и пересматривается оценочный объём.
Следующий блок оплачивается, когда израсходованы часы по предыдущему. Не оплатил — работы на паузе. Не оплатил в течение трёх недель — договор тоже на паузе. Оговаривается, что возобновление работ происходит только после оплаты + 4–6 недель (потому что мы уже будем заняты другим проектом).
Не оплачено в течение трёх месяцев — расторжение. Значит, клиент вышел из проекта. Такое бывает, особенно после достижения точки первоначальной эксплуатации, когда становится ясно, что кроме ПО нужны ещё и организационные изменения, а они невозможны.
Если проект дошёл до конца — подключается абонентка на сопровождение: чтобы 2–3 небольшие задачи в месяц не согласовывать отдельно. Абонентка на разработку — ни в коем случае. Это бесконечный конфликт про объём задач, который «должен быть выполнен».
Такая схема работает, но тут возникает другой вопрос: со стороны подрядчика требуется дофига скилла — и в бизнесе клиента, и в разработке, и в коммуникации (причём с разными, зачастую конфликтующими между собой, людьми у заказчика). И в итоге, если у тебя есть такой скилл, непонятно, зачем вообще заниматься такими проектами, а не работать в условном Сбере.
Доступов к ТСПУ у техподдержки хостеров нет. Я попал уже на эту штуку дважды - у VULTR и потом через 3 недели у Digitalocean. Никаких сверх-защит не стояло, обыкновенный https, просто перестают проходить пакеты и вме (только я определил порог как 30Кб, но считал на калькуляторе по битам, мог ошибиться). Блокировка наблюдалась не по всем маршрутам, те поэксперементировав с прокси в различных точках РФ-хостеров у кого есть иностранные сервера, я подобрал работающий маршрут. Блокировался именно SSL - TLS и SSH работали нормально.
Не ограничится, будут еще другие, такие-же некритичные. Есть какая-то идея, что некритичные ошибки — ведут к критичным для системы, это не совсем так. Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время. Но разработчику на время/деньги все-равно — платит корпорация, она за эффективность не доплачивает, зато делает мозг за мелкие недочеты.
И я читаю эту статью так: если у вас нет 2 миллиардов рублей на сервис из четырех табличек, то не стоит пытаться разрабатывать так, как разрабатывает корпорация, вы просто не доживете до запуска — неважно будет, есть там у вас железобетонная защита от всего на свете и красивые 404 во всех местах или нет.
Разработчик он за зарплату. Деньги не его. Методичек много, поле для деятельности большое. Эффективность бизнеса - не его задача. Смерть проекта от 1000 порезов не его проблема. Утверждения про безопасность - ну так что угодно объясняется. Становится безопасности больше от применения всех методичек вперемешку - по разному, если навертели в 4 этажа, что самим непонятно как работает, ну какая там безопасность. Кто-то говорит публично, что это дичь - ну это как против использования микросервисов в проекте трехстоаничного сайта рот открывать.
Я на 1К звезд решил, что хватит мне OSS заниматься. Для того что бы сложный проект реально развивался, он должен реально зарабатывать. И в этот момент становится понятно, что бесплатная аудитория и платная аудитория - не пересекаются. Первая во вторую не конвертируется.
Конечно, но я вижу, что корпораты в os выкладывают то, на что затраты уже произведены, но заработать с этого прямо не получается. Поэтому os позволяет получить косвенный эффект. Выложили golang, получили тестирование и реальную оценку (при этом команда как работала над ним, так и работает). Выложил Дипсик свою модель, заработал на шорте акций Нвидиа, получил медийный шум, привлек внимание. В опенсорсе тот, кто отстает. Альтман хоть и говорит, что он неправильно оценил на какой они стороне истории с опен-сорс, но это просто вращение языком. Реально они опенсорсят только вторичные вещи, что бы посмотреть, что в реальных условиях там люди придумают, потом складывают интересные идеи со своим представлением и переносят в корп-продукт. И то это сомнительная история, я думаю они это делают на всякий случай, так как по факту у меня за 5 лет только 1 штуку из 300 примерно, придумало комьюнити, до которой я сам раньше не додумался. Ну и это все не является длящимся, как только задача исчезает, весь этот опен-сорс сворачивается. Развивали Flutter пока всем нужны были приложения и гуглу надо было конкурировать за андроид, вкладывали в это, хайп на приложухи прошел, забросили.
Ну раз здесь такие темы обсуждаются... Расскажите пример атаки на ssh на 22 порту с разрешенным root у которого стоит биологически-псевдослучайный 24 значный пароль. Можно такое?
Был хайп, он прошел, множество проектов конвертировалось в коммерческие (мой например - это было самым лучшим решением), множество проектов совсем померло, или находится в анабиозе (вроде что-то делают, а вроде и нет). Количество венчурных денег в os-проекты резко упало (мне по крайней мере так кажется глядя на индекс Рунакап). Но какие-то преимущества есть, например когда прям совсем сырой продукт, можно привлечь стартовую аудиторию, посмотреть о чем она просит на форуме итп. Также можно получить бесплатные маркетинговые каналы на том же хабре. Но если смешанная модель по типу опен-кор, то так уже не получится (и здесь и на реддит будут банить). Для корпоратов выкладывание в os позволяет упростить формирование индустриального стандарта (если это нужно). Но все это из моего опыта, еффективнее делать просто за бабло.
Крупные компании поддерживают те проекты, которые нужны им.
Если есть маленький разработчик и он решил запились свой os проектик, то если этот проектик больше, чем 3-4 месяца работы по вечерам - ему капец.
Стоимость привлечения пользователя на os проект аналогична привлечению платящего пользователя.
С ростом пользователей растет и объем работы по поддержке.
Бесплатные пользователи потом почти никак не конвертируются в платных.
Бесплатные пользователи считают, что они и есть ценность, поэтому генерят запросы и предложения в техподдержку, так-как считают это своим вкладом в развитие проекта.
Никакие фонды ничего никуда не распределят, любой распределяющий фонд работает для прибыли своих администраторов.
Организация комьюнити и его работы над проектом, дороже чем прямые затраты на написание кода.
Что бы получить нормальный код в os надо потратить существенно больше ресурсов, чем просто его написать.
Спасибо невозможно обменять в магазе на киллограм огурцов.
Мнение различается от волны эмиграции (кто переезжал задолго до всех событий чаще имеют отрицательное отношение хз почему). Также испания явно не подходит тем, кто стремился попасть в Лондон/Сан Франциско, а оказался например в Барселоне (они страдают) - здесь нет этого рабочего сверх-надрыва и наэлектризованности пространства желаниями урвать свои 100 лямов любой ценой.
Испанцы весьма обязательные в важных вопросах, с компетентностью тоже все ок и с очень толерантным отношением к иностранцам (всегда конечно можно вести себя вызывающе и нервно, чем вызвать сильное неприятие). От окупасов ставят сигналку, да и если это единственное жилье, то их выкинет полиция (точнее они не полезут). Но окупасы и размножившие их комунисты - оба пункта проблемные.
Откуда берется эта "миллионная копия", мне бы вот первые 100 продать и не за какие-то там миллионы, а по цене туалетной бумаги, которую стандартный человек просирает за неделю.
Суперкорпорация — суперкорпорациям нужны определенные продукты, абы че они не финансируют. Да и между прочим — нынешний open source такой и есть. Все крупные проекты — это фонды спонсируемые корпоратами, или проекты нацеленные на корпоратов.
Еще у вас такая идея, что рапространение происходит само-собой и на него нет расхода, а на самом деле он есть и очень большой. В плановой экономике этот расход меньше, но там другая проблема, чего нужно всегда в дефиците, а чего не нужно — завал, так как экономика сложнее, чем получается считать у генплана. Вот так и будет в вашей суперкорпорации.
Вы хотите, что бы были платные проекты, только бесплатно. Это коммунизм, заканчивается отсутствием еды, потому что так не работает. Вы рассмотрите, что деньги это внимание, если проект бесплатный — значит у него денег, ему нечем привлекать внимание пользователей у него нет ни на что ресурсов (это я как майнтейнер open source проекта говорю).
При этом Deep Seek с выкладкой модели бесплатно, это не платный проект, только бесплатно — этот ход, я думаю, позволил им очень хорошо заработать на шорте акций Nvidia (они же хэджфонд). А предоставлять нормальный API-сервис и зарабатывать на модели — это и не их приоритет, они даже не пытаются и правильно.
Можно ли придумать другой носитель ресурса внимания, можно — натуральная экономика, бартер, обком партии, итп, но по факту (за 5000 лет истории) оказалось, что деньги обладают наименьшими транзакционными издержками.
Тут вон вообще кто-то из читателей решил, что это инструкция как взять с людей больше денег и поплевать им в душу, хотя ровно про обратное. Далее по порядку:
Единичный/Множественный: если единичный заказ на 5 млн, то там где есть один такой, скорее всего найдется и второй. Если он на 5 тр но этот заказчик заказывает много, и у него по одному из 20 просрочка, то вполне переживаемо, если по всем 20, то как раз будет видно. Если на 5 тр и он реально единичный, ну тут цех старался конечно, но как получилось.
Заранее/Впритык: размещение заранее — большая редкость, и скорее всего в этот момент участок не сильно загружен и как мы запланировали, так срок и будет реализован. Проблемы у всех в сезон, когда приходит множество заказов одновременно. В цеху всегда что-то идет не так, но когда очередь производства большая, даже мелкие проблемы получают больший мультипликатор. Со стороны заказчика, даже если он заказывает заранее, неразумно сообщать, что у него есть время, так как в этом случае его заранее будет бесполезно.
Ну и цифра то синтетическая, она не заменяет взаимодействия с заказчиком. Но например, часто просят подвинуть срок на более раннюю дату, нежели расчетную и если видно, что на направлении завал, то врядли он реально подвинется.
Я пришёл к такой схеме на сложных ERP-проектах, которые длятся по 6–12 месяцев и требуют около 500 часов работы.
Предварительная оценка — бесплатно, но она приблизительная.
Ставка за час работы фиксируется в договоре и не изменяется в течение какого-то срока, например года, при условии своевременной оплаты со стороны клиента.
Клиент платит блоками по 150 тыс. рублей. Каждую неделю отправляется акт о выполненных работах. Задача за первые два транша (то есть за 300 тыс., что составляет примерно треть проекта) — выйти на работающий функционал, пригодный для запуска в эксплуатацию.
В договоре указывается, сколько часов в месяц мы гарантированно уделяем этому проекту (обычно 60–90).
Также в договоре описывается общая схема блоков и прописываются точки, в которых мы заранее видим, что клиент может не справиться. Например, если он говорит, что его сотрудники будут заполнять какую-то конскую форму, а мы по опыту знаем, что не будут — так и фиксируем это в договоре.
Стартовая эксплуатация оформляется актами, в которых указано количество заказов, расчётов и прочих операций, проведённых командой заказчика в новой системе.
После этого принимаются уточнения по проекту со стороны клиента (ранее они не рассматриваются, потому что до реальной эксплуатации — это просто фантазии), и пересматривается оценочный объём.
Следующий блок оплачивается, когда израсходованы часы по предыдущему. Не оплатил — работы на паузе. Не оплатил в течение трёх недель — договор тоже на паузе. Оговаривается, что возобновление работ происходит только после оплаты + 4–6 недель (потому что мы уже будем заняты другим проектом).
Не оплачено в течение трёх месяцев — расторжение. Значит, клиент вышел из проекта. Такое бывает, особенно после достижения точки первоначальной эксплуатации, когда становится ясно, что кроме ПО нужны ещё и организационные изменения, а они невозможны.
Если проект дошёл до конца — подключается абонентка на сопровождение: чтобы 2–3 небольшие задачи в месяц не согласовывать отдельно. Абонентка на разработку — ни в коем случае. Это бесконечный конфликт про объём задач, который «должен быть выполнен».
Такая схема работает, но тут возникает другой вопрос: со стороны подрядчика требуется дофига скилла — и в бизнесе клиента, и в разработке, и в коммуникации (причём с разными, зачастую конфликтующими между собой, людьми у заказчика). И в итоге, если у тебя есть такой скилл, непонятно, зачем вообще заниматься такими проектами, а не работать в условном Сбере.
Доступов к ТСПУ у техподдержки хостеров нет. Я попал уже на эту штуку дважды - у VULTR и потом через 3 недели у Digitalocean. Никаких сверх-защит не стояло, обыкновенный https, просто перестают проходить пакеты и вме (только я определил порог как 30Кб, но считал на калькуляторе по битам, мог ошибиться). Блокировка наблюдалась не по всем маршрутам, те поэксперементировав с прокси в различных точках РФ-хостеров у кого есть иностранные сервера, я подобрал работающий маршрут. Блокировался именно SSL - TLS и SSH работали нормально.
Не ограничится, будут еще другие, такие-же некритичные. Есть какая-то идея, что некритичные ошибки — ведут к критичным для системы, это не совсем так. Если сосредотачиваться на реальной безопасности и оставить на потом, если потребуется, такого рода штуковины как пагинация -1, то сделать получится существенно больше за те-же деньги/время. Но разработчику на время/деньги все-равно — платит корпорация, она за эффективность не доплачивает, зато делает мозг за мелкие недочеты.
И я читаю эту статью так: если у вас нет 2 миллиардов рублей на сервис из четырех табличек, то не стоит пытаться разрабатывать так, как разрабатывает корпорация, вы просто не доживете до запуска — неважно будет, есть там у вас железобетонная защита от всего на свете и красивые 404 во всех местах или нет.
Разработчик он за зарплату. Деньги не его. Методичек много, поле для деятельности большое. Эффективность бизнеса - не его задача. Смерть проекта от 1000 порезов не его проблема. Утверждения про безопасность - ну так что угодно объясняется. Становится безопасности больше от применения всех методичек вперемешку - по разному, если навертели в 4 этажа, что самим непонятно как работает, ну какая там безопасность. Кто-то говорит публично, что это дичь - ну это как против использования микросервисов в проекте трехстоаничного сайта рот открывать.
Ок, открыл, ввел, получил ошибку, что дальше? Как это вредит безопасности если там препереды и ограничения доступа по другим параметрам?
А если взять текст и просто самому сделать его менее пластиковым, то будет результат?
Вот мы сильно перепилили бесплатную версию, приходится сейчас ее частями демонтировать.
Я на 1К звезд решил, что хватит мне OSS заниматься. Для того что бы сложный проект реально развивался, он должен реально зарабатывать. И в этот момент становится понятно, что бесплатная аудитория и платная аудитория - не пересекаются. Первая во вторую не конвертируется.
Конечно, но я вижу, что корпораты в os выкладывают то, на что затраты уже произведены, но заработать с этого прямо не получается. Поэтому os позволяет получить косвенный эффект. Выложили golang, получили тестирование и реальную оценку (при этом команда как работала над ним, так и работает). Выложил Дипсик свою модель, заработал на шорте акций Нвидиа, получил медийный шум, привлек внимание. В опенсорсе тот, кто отстает. Альтман хоть и говорит, что он неправильно оценил на какой они стороне истории с опен-сорс, но это просто вращение языком. Реально они опенсорсят только вторичные вещи, что бы посмотреть, что в реальных условиях там люди придумают, потом складывают интересные идеи со своим представлением и переносят в корп-продукт. И то это сомнительная история, я думаю они это делают на всякий случай, так как по факту у меня за 5 лет только 1 штуку из 300 примерно, придумало комьюнити, до которой я сам раньше не додумался. Ну и это все не является длящимся, как только задача исчезает, весь этот опен-сорс сворачивается. Развивали Flutter пока всем нужны были приложения и гуглу надо было конкурировать за андроид, вкладывали в это, хайп на приложухи прошел, забросили.
Ну раз здесь такие темы обсуждаются... Расскажите пример атаки на ssh на 22 порту с разрешенным root у которого стоит биологически-псевдослучайный 24 значный пароль. Можно такое?
Был хайп, он прошел, множество проектов конвертировалось в коммерческие (мой например - это было самым лучшим решением), множество проектов совсем померло, или находится в анабиозе (вроде что-то делают, а вроде и нет). Количество венчурных денег в os-проекты резко упало (мне по крайней мере так кажется глядя на индекс Рунакап). Но какие-то преимущества есть, например когда прям совсем сырой продукт, можно привлечь стартовую аудиторию, посмотреть о чем она просит на форуме итп. Также можно получить бесплатные маркетинговые каналы на том же хабре. Но если смешанная модель по типу опен-кор, то так уже не получится (и здесь и на реддит будут банить). Для корпоратов выкладывание в os позволяет упростить формирование индустриального стандарта (если это нужно). Но все это из моего опыта, еффективнее делать просто за бабло.
Тестирование, маркетинг, фонды, университетские, найм, ибд
Крупные компании поддерживают те проекты, которые нужны им.
Если есть маленький разработчик и он решил запились свой os проектик, то если этот проектик больше, чем 3-4 месяца работы по вечерам - ему капец.
Стоимость привлечения пользователя на os проект аналогична привлечению платящего пользователя.
С ростом пользователей растет и объем работы по поддержке.
Бесплатные пользователи потом почти никак не конвертируются в платных.
Бесплатные пользователи считают, что они и есть ценность, поэтому генерят запросы и предложения в техподдержку, так-как считают это своим вкладом в развитие проекта.
Никакие фонды ничего никуда не распределят, любой распределяющий фонд работает для прибыли своих администраторов.
Организация комьюнити и его работы над проектом, дороже чем прямые затраты на написание кода.
Что бы получить нормальный код в os надо потратить существенно больше ресурсов, чем просто его написать.
Спасибо невозможно обменять в магазе на киллограм огурцов.
Делайте нормальные, коммерческие проекты.
Мнение различается от волны эмиграции (кто переезжал задолго до всех событий чаще имеют отрицательное отношение хз почему). Также испания явно не подходит тем, кто стремился попасть в Лондон/Сан Франциско, а оказался например в Барселоне (они страдают) - здесь нет этого рабочего сверх-надрыва и наэлектризованности пространства желаниями урвать свои 100 лямов любой ценой.
2 года
Испанцы весьма обязательные в важных вопросах, с компетентностью тоже все ок и с очень толерантным отношением к иностранцам (всегда конечно можно вести себя вызывающе и нервно, чем вызвать сильное неприятие). От окупасов ставят сигналку, да и если это единственное жилье, то их выкинет полиция (точнее они не полезут). Но окупасы и размножившие их комунисты - оба пункта проблемные.
Откуда берется эта "миллионная копия", мне бы вот первые 100 продать и не за какие-то там миллионы, а по цене туалетной бумаги, которую стандартный человек просирает за неделю.
Суперкорпорация — суперкорпорациям нужны определенные продукты, абы че они не финансируют. Да и между прочим — нынешний open source такой и есть. Все крупные проекты — это фонды спонсируемые корпоратами, или проекты нацеленные на корпоратов.
Еще у вас такая идея, что рапространение происходит само-собой и на него нет расхода, а на самом деле он есть и очень большой. В плановой экономике этот расход меньше, но там другая проблема, чего нужно всегда в дефиците, а чего не нужно — завал, так как экономика сложнее, чем получается считать у генплана. Вот так и будет в вашей суперкорпорации.
Вы хотите, что бы были платные проекты, только бесплатно. Это коммунизм, заканчивается отсутствием еды, потому что так не работает. Вы рассмотрите, что деньги это внимание, если проект бесплатный — значит у него денег, ему нечем привлекать внимание пользователей у него нет ни на что ресурсов (это я как майнтейнер open source проекта говорю).
При этом Deep Seek с выкладкой модели бесплатно, это не платный проект, только бесплатно — этот ход, я думаю, позволил им очень хорошо заработать на шорте акций Nvidia (они же хэджфонд). А предоставлять нормальный API-сервис и зарабатывать на модели — это и не их приоритет, они даже не пытаются и правильно.
Можно ли придумать другой носитель ресурса внимания, можно — натуральная экономика, бартер, обком партии, итп, но по факту (за 5000 лет истории) оказалось, что деньги обладают наименьшими транзакционными издержками.
Мир хочер бесплатного ПО, но на поддержку разработчиков ему пофиг
Тут вон вообще кто-то из читателей решил, что это инструкция как взять с людей больше денег и поплевать им в душу, хотя ровно про обратное. Далее по порядку:
Единичный/Множественный: если единичный заказ на 5 млн, то там где есть один такой, скорее всего найдется и второй. Если он на 5 тр но этот заказчик заказывает много, и у него по одному из 20 просрочка, то вполне переживаемо, если по всем 20, то как раз будет видно. Если на 5 тр и он реально единичный, ну тут цех старался конечно, но как получилось.
Заранее/Впритык: размещение заранее — большая редкость, и скорее всего в этот момент участок не сильно загружен и как мы запланировали, так срок и будет реализован. Проблемы у всех в сезон, когда приходит множество заказов одновременно. В цеху всегда что-то идет не так, но когда очередь производства большая, даже мелкие проблемы получают больший мультипликатор. Со стороны заказчика, даже если он заказывает заранее, неразумно сообщать, что у него есть время, так как в этом случае его заранее будет бесполезно.
Ну и цифра то синтетическая, она не заменяет взаимодействия с заказчиком. Но например, часто просят подвинуть срок на более раннюю дату, нежели расчетную и если видно, что на направлении завал, то врядли он реально подвинется.