А есть проект по разделению записи разговора двух участников на две дорожки, чтобы каждый участник был на отдельной дорожке? просто аудиозапись, без видео
ездил тут к теще (живет в другом городе). теща: «хочу подарить тебе зонт на др. съезди в вайлдбери и выбери» приезжаю в пункт выдачи, выдают 5 зонтов — разные ручки, расцветки, все разворачиваю, смотрю, пробую раскрывать, выбираю 1, остальные возвращаю. у тещи спрашиваю «оплата после того как забрал заказ?» оказывается, нет. она все 5 оплатила, «ну а что такого» — говорит, — «они же за отмененные заказы вернут деньги, сто раз так уже делала»
если б заказывал просто один, я онлайн недели 2 выбирал бы ;)
у вас интересная гипотеза, будет интересно проследить за ее проверкой.
заметьте, что запрос на open-source CMS есть у бизнесов, которые реализуют сайты. собственно спрос на CMS — это снижение издержек на разработку сайтов. Среднестатистической веб-студии проще сделать индивидуальный дизайн для клиента и натянуть дизайн на стандартный wordpress + докастомизировать плагинами — т.е. как раз снижение издержек на производство сайтов.
отсюда есть вывод-цепочка: производитель — дилерская сеть — конечные клиенты
приводимые как примеры амоCRM и Битрикс — это производители, их партнерские сети — работают с клиентами и зарабатывают на клиентах, сами производители не работают с конечными клиентами. они предоставляют продукт, следят за его использованием, соблюдением ограничений на использование — через лимиты тарифов и вознаграждают партнеров.
даже упомянутые open-source cms: есть сообщество разработчиков — производитель, есть веб-студии — партнерская сеть, которая разрабатывает сайты и зарабатывает на клиентах, и конечно, есть конечный клиент, который говорит: «о, да мне надо сайт»
в общем, к чему это: пока у вас не будет плана как на вас кто-то постоянно будет зарабатывать, проект вероятно не взлетит в объеме и сроках. и если вы не будете знать как вы будете зарабатывать на тех кто зарабатывает на вас, то вероятно вам проект быстро надоест ))) правда при решении этих вопросов тема open-source может отойти на второй план
еще интересный вопрос: почему должны выбрать вашу CRM, а не amo, битрикс, аденту, медеск, мэлтор, креатио, регионсофт, ретейл и десяток еще уже имеющихся на рынке в разных нишах? и кто будет делать этот выбор?
работаю с разными интеграторами и разными CRM практически каждый день — поэтому сомнений в вашем проекте у меня много, но повторюсь, будет интересно посмотреть за реализацией вашей идеи
в статье не заметил ссылки на гитхаб, вы еще ничего не выкладывали?
и немного возражу tcapb1 по поводу «CRM должна быть массовой чтобы быть конкурентной»
необязательно. сейчас разные кейсы идут. есть класс микро-CRM, которые уже более смещены на ведение лидов — к примеру, интеграция только с whatsapp и инстаграм — лиды приходят из инсты, ведутся по воронке, коммуникации только по номеру мобильного — звонки+сообщения в whatsapp. хотя конечно, очертить границы, в рамках которых будет open source CRM, не пытаясь уйти в сервер универсальных приложений достаточно сложно ))
кстати, битрикс вполне себе open-source. т.е. можно скачать виртуальную машину, найти в ней нужные директории и посмотреть исходники.
возможно, облачная open-source crm? но опять же… «где деньги, Зин?»
интересное применение на отдельной области наработанных технологий: там вот и tarantool используется на сервере, и визуальный конструктор логики — так сказать low-code для докторов ))
и, конечно, хабр не для профессиональных докторов, поэтому здесь интереснее технологичность решения: было бы интересно отдельно видеть ui для конструктруирования блок-схем как отдельный проект, который можно встроить в другие продукты
в целом, по статье и по подходу — лютая академичность и совковость. Вы все инструменты переизобретаете на свои «не имеющие аналогов на западе».
хотя вполне вероятно все эти схемы Дракона близки к диаграммам UML. Где вы отчасти решили некоторые проблемы типа лейаута элементов.
свой формат drn — это sqlite с кодом внутри? зачем так?
прикольно, как можно 20 с лишним лет выезжать на визуализации Бейсика )))
А vosk сервер у вас как запущен? сами конфигурировали для использования русскоязычной модели?
для описания всех запущенных процессов можно использовать docker-compose.yml: ваш python-бот + монго + caldi
работа с определенным API сильно зависит от Google. Оболочка предоставляет всего лишь некоторые обходные возможности, не мейнстрим. ок, протестируем, по возможности ))
А есть какие-то изменения по записи звонков? Google запрещал сторонним приложениям записывать через API звонки. Но потом вроде были обещания, что разрешат в Андроид 12.
а у вас получается разделить роли разработчика actions и разработчика процессов на основании actions? не получается ли так что один человек все это разрабатывает и потом все эти процессы отлаживает?
если получается разделять, то как вы документируете возможности каждого actions? что action может и главное не может делать и пора этот action функционально проапгрейдить или разработать новый action?
Вопрос еще по этой статье: упомянуты методологии SAFe, LeSS, Nexus
есть ли где-то перевод на русском этих методологий?
и есть ли известные применения на практике этих методологий? т.е. компании, которые сказали «да, мы ранее намучались, внедрили SAFe|LeSS|Nexus и теперь ловим кайф», в мире и РФ?
Нальешь кружечку чая, откусишь печеньку — и оп, статья закончилась ))
Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.
Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.
Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?
Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
Откуда у вас эти картинки? Т.е. вы на кого-то опираетесь в описании моделей управления? Есть какая-то книга, статья, которые послужили отправной точкой этих схем? Или это ваши размышления, умозаключения, изложение опыта?
В ваших схемах представлена иерархия, в первом случае коммуникация осуществляется на уровне начальников, во втором случае — на уровне сотрудников. Какое отношение имеет процесс к иерархии? В целом, несколько ортогональные понятия. Т.е. у вас между парой отделов может быть коммуникация на одном уровне, между другой парой — на другом, а весь процесс проходить через все отделы, хотя вы называете это разными моделями управления.
Обычно говорят о вертикальном и горизонтальном прохождении процесса по иерархии, описывая важность построения горизонтальных связей между отделами на уровне сотрудников без вышестоящего (вертикального) согласования для ускорения бизнес-процессов.
«функциональный подход заключается в объединении сотрудников в отдельные структурные бизнес-единицы (отделы, департаменты и прочее) по принципу однообразия выполняемой деятельности с жесткой вертикальной иерархией» — ок, а в процессном нет объединения сотрудников в бизнес-единицы? конечно, есть, т.к. иерархия в целом никуда не уходит. Только фокус смещается.
Преимущества процессной модели описанные весьма сомнительны. Например,
«мотивация сотрудников привязана к получению конечного результата, а не к выполняемым ими функциям». Реально? В хорошо поставленном процессе от сотрудника мало чего зависит. Или это не так?
А есть проект по разделению записи разговора двух участников на две дорожки, чтобы каждый участник был на отдельной дорожке? просто аудиозапись, без видео
ездил тут к теще (живет в другом городе). теща: «хочу подарить тебе зонт на др. съезди в вайлдбери и выбери» приезжаю в пункт выдачи, выдают 5 зонтов — разные ручки, расцветки, все разворачиваю, смотрю, пробую раскрывать, выбираю 1, остальные возвращаю. у тещи спрашиваю «оплата после того как забрал заказ?» оказывается, нет. она все 5 оплатила, «ну а что такого» — говорит, — «они же за отмененные заказы вернут деньги, сто раз так уже делала»
если б заказывал просто один, я онлайн недели 2 выбирал бы ;)
заметьте, что запрос на open-source CMS есть у бизнесов, которые реализуют сайты. собственно спрос на CMS — это снижение издержек на разработку сайтов. Среднестатистической веб-студии проще сделать индивидуальный дизайн для клиента и натянуть дизайн на стандартный wordpress + докастомизировать плагинами — т.е. как раз снижение издержек на производство сайтов.
отсюда есть вывод-цепочка: производитель — дилерская сеть — конечные клиенты
приводимые как примеры амоCRM и Битрикс — это производители, их партнерские сети — работают с клиентами и зарабатывают на клиентах, сами производители не работают с конечными клиентами. они предоставляют продукт, следят за его использованием, соблюдением ограничений на использование — через лимиты тарифов и вознаграждают партнеров.
даже упомянутые open-source cms: есть сообщество разработчиков — производитель, есть веб-студии — партнерская сеть, которая разрабатывает сайты и зарабатывает на клиентах, и конечно, есть конечный клиент, который говорит: «о, да мне надо сайт»
в общем, к чему это: пока у вас не будет плана как на вас кто-то постоянно будет зарабатывать, проект вероятно не взлетит в объеме и сроках. и если вы не будете знать как вы будете зарабатывать на тех кто зарабатывает на вас, то вероятно вам проект быстро надоест ))) правда при решении этих вопросов тема open-source может отойти на второй план
еще интересный вопрос: почему должны выбрать вашу CRM, а не amo, битрикс, аденту, медеск, мэлтор, креатио, регионсофт, ретейл и десяток еще уже имеющихся на рынке в разных нишах? и кто будет делать этот выбор?
работаю с разными интеграторами и разными CRM практически каждый день — поэтому сомнений в вашем проекте у меня много, но повторюсь, будет интересно посмотреть за реализацией вашей идеи
в статье не заметил ссылки на гитхаб, вы еще ничего не выкладывали?
и немного возражу tcapb1 по поводу «CRM должна быть массовой чтобы быть конкурентной»
необязательно. сейчас разные кейсы идут. есть класс микро-CRM, которые уже более смещены на ведение лидов — к примеру, интеграция только с whatsapp и инстаграм — лиды приходят из инсты, ведутся по воронке, коммуникации только по номеру мобильного — звонки+сообщения в whatsapp. хотя конечно, очертить границы, в рамках которых будет open source CRM, не пытаясь уйти в сервер универсальных приложений достаточно сложно ))
кстати, битрикс вполне себе open-source. т.е. можно скачать виртуальную машину, найти в ней нужные директории и посмотреть исходники.
возможно, облачная open-source crm? но опять же… «где деньги, Зин?»
и, конечно, хабр не для профессиональных докторов, поэтому здесь интереснее технологичность решения: было бы интересно отдельно видеть ui для конструктруирования блок-схем как отдельный проект, который можно встроить в другие продукты
в целом, по статье и по подходу — лютая академичность и совковость. Вы все инструменты переизобретаете на свои «не имеющие аналогов на западе».
хотя вполне вероятно все эти схемы Дракона близки к диаграммам UML. Где вы отчасти решили некоторые проблемы типа лейаута элементов.
свой формат drn — это sqlite с кодом внутри? зачем так?
прикольно, как можно 20 с лишним лет выезжать на визуализации Бейсика )))
для описания всех запущенных процессов можно использовать docker-compose.yml: ваш python-бот + монго + caldi
если получается разделять, то как вы документируете возможности каждого actions? что action может и главное не может делать и пора этот action функционально проапгрейдить или разработать новый action?
есть ли где-то перевод на русском этих методологий?
и есть ли известные применения на практике этих методологий? т.е. компании, которые сказали «да, мы ранее намучались, внедрили SAFe|LeSS|Nexus и теперь ловим кайф», в мире и РФ?
Думаю, очевидно, что на разном уровне у вас просто разный продукт, не так ли? Для команды компоненты: продукт — это компонента, для команды биллинга — это биллинг. Если биллинг использует компоненту, то он по сути выступает заказчиком на некоторые фичи компоненты, и соответственно получает ценность компоненты.
Команда, реализующая продвижение какой-то услуги вашей компании, для которой продукт — продажа услуги, будет по сути заказчиком для биллинга, чтобы были нужные опции расчетов.
Но вы в статье говорите, что продукт — это не биллинг, и не система подбора услуг, где есть скрам-мастер и продукт-owner. А есть некий «мега-продукт», который несет «ценность». Т.е. вы просто перешли на уровень абстракции выше, когда соединение нескольких систем дает удобство для клиента? И продукт есть feature, который как раз дает добавленную стоимость (как денежное выражение ценности для клиентов)?
Отсюда следующий вопрос. Т.е. как происходит организация команд для реализации мега-продуктов? Т.е. остается ли команда, которая, например, занимается тем же биллингом.
В ваших схемах представлена иерархия, в первом случае коммуникация осуществляется на уровне начальников, во втором случае — на уровне сотрудников. Какое отношение имеет процесс к иерархии? В целом, несколько ортогональные понятия. Т.е. у вас между парой отделов может быть коммуникация на одном уровне, между другой парой — на другом, а весь процесс проходить через все отделы, хотя вы называете это разными моделями управления.
Обычно говорят о вертикальном и горизонтальном прохождении процесса по иерархии, описывая важность построения горизонтальных связей между отделами на уровне сотрудников без вышестоящего (вертикального) согласования для ускорения бизнес-процессов.
«функциональный подход заключается в объединении сотрудников в отдельные структурные бизнес-единицы (отделы, департаменты и прочее) по принципу однообразия выполняемой деятельности с жесткой вертикальной иерархией» — ок, а в процессном нет объединения сотрудников в бизнес-единицы? конечно, есть, т.к. иерархия в целом никуда не уходит. Только фокус смещается.
Преимущества процессной модели описанные весьма сомнительны. Например,
«мотивация сотрудников привязана к получению конечного результата, а не к выполняемым ими функциям». Реально? В хорошо поставленном процессе от сотрудника мало чего зависит. Или это не так?