МойОфис хуже, чем Microsoft Office. Например таблицы в МойОфис сильно тормозят, особенно если речь идёт о таблицах, например, в 20 тысяч строк и больше. Я пользовался 1 день и понял, что МойОфис не сможет заменить мне Microsoft Excel.
Поэтому, считаю проблему компании МойОфис не в управленцах, а в программистах.
Сколько поставщиков знаю, все отправляют прайсы только в Экселе. И какие ты более эффективные инструменты знаешь для взаимодействия между магазинами и производителями?
Ладно я умею пользоваться СУБД, могу составить запрос SQL, а подавляющее большинство моих конкурентов такое сделать не смогут. И че теперь производителю им не реализовывать товары?
Хаха)
Там схема немного сложнее у нас (ну конечно, да, этож ынтырпрайз, хахаха).
Исходные данные и для питонов и для нашей Java - одни и те же. Лежат в одном месте. И к ним обращается и Java и Питоны.
Разница в том, что Java - это тырпрайз со всеми вытекающими, релиз-процесс, и вся остальная хуйня, а питон - это наколенные поделки, без релиз-процессов и прочего, за счет чего, получается что согласно процессам на Java функциональность выводится минимум за полтора месяца. А на питоне могут то же самое написать за пару дней)
И суть в том, что, бизнес-пользователи, тестируют, по сути, с помощью питона всякие подходы, и просят нас это запрогать уже в тырпрайзе...
Но скорость изменений настолько высока, что они что-то оттестировали, пришли к нам, типа мол - вот хотим синюю полупрозрачную ленточку... Мы говорим - да окей, ближайшая поставка - через полтора месяца. Все, по рукам.
Но через неделю выясняется, что синяя полупрозрачная ленточка - это полная хуйня, нужна красно-оранжевая. Но, производственный процесс запустился на синей ленточке, и остановить это сложно. Конечно, бизнес подойдет и скажет что синяя полупрозрачная ленточка - это уже хуйня, и нужно ориентироваться на оранжевую. Но, методологи от IT докажут и расскажут бизнесу, в очередной раз о том, что надо "ЧЕТКО ПОНИМАТЬ ЧТО ТЫ ХОЧЕШЬ" и "ПРИХОДИТЬ С КОНКРЕТНЫМИ ПОСТАНОВКАМИ И НЕ МЕНЯТЬ ИХ НА ХОДУ". В итоге, бизнес будет какое-то время мириться с этим. Но параллельно он попросит своих пользователей в очередной раз на коленке на питоне поправить пару строк, чтобы в итоге это была красно-оранжевая полупрозрачная ленточка. И это сделают за пару дней.
А потом вот на таких созвонах, на предложение "всем перейти в питон" будут слушать возражения в стиле "ПОСМОТРИТЕ НА ЗАРПЛАТЫ JAVA-РАЗРАБОТЧИКОВ и PYTHON-РАЗРАБОТЧИКОВ, ЭТО ПОТЕРЯ КВАЛИФИКАЦИИ и ЗАРПЛАТЫ".
А ведь бизнес смотрит на это, и видит.
1. Чуваки на питоне выдают результат за пару дней и стоят дёшево.
2. Чуваки на Java что-то совсем нихуя нам не поставляют годный функционал, да и еще и стоят дорого.
Очевидное решение со стороны бизнеса - разогнать Java. ))))
Очевидное решение со стороны бизнеса - разогнать Java. ))))
Ну не знаю. Тут надо смотреть, приносят ли программисты,а точнее их продукт деньги?
Я сам когда-то работал программистом в компании, которая делала отчёты. Наш отдел писал ПО для автоматизации процессов в самой организации и за ее пределами. Много лет писали и дорабатывали. Потратили на это кучу денег. Многие программы были написаны, но никогда не применялись вообще. А специалисты этой компании так и продолжали делать отчёты вручную в Ворде, используя обычный калькулятор. Брали прошлые отчёты и в них часть информации меняли на новую. Как они говорили, им так привычнее. В итоге компания разорилась, причем как раз из-за вложений в IT разработки. Директора (несколько ооо было) стали Ипешниками и сами стали вручную делать такие отчёты. То есть, в этом случае компания просто выбрасывала на ветер деньги, которые зарабатывались специалистами, которые вручную делали отчёты. Конечно, в таком случае надо было как можно раньше закрыть наш отдел или оставить одного. А нас было человек 10 и все получали выше среднего по рынку.
Но в вашем случае у вашего продукта есть пользователи, в отличии от нашего. А значит, он продается. Пользователи ждут обновлений, значит продукт востребован, может и дальше приносить прибыль.
Так, ну ок, на самом деле я не кидаю никакие камни в ваш огород, тем более, если у вас бизнес (любой), то вы явно на ступеньку смышленней и выше меня, и уж точно не мне говорить что и как должно быть автоматизировано. Да хоть это из говна и палок сделано, главное чтобы оно работало и оправдывало вложения.
Расскажу небольшую историю про случай в одной крупной компании (понятное дело, я не буду называть в какой). Я рассказываю потому что, я к части условных активностей, описываемых ниже, имею почти прямое отношение, но часть я слышу, как это говорится "краем уха". И да, я некоторые обсуждения менеджеров не знаю, но я сужу по всему благодаря тому, что я собираю кусочки информации и на основании этого делаю вывод, поэтому если вдруг кто-то считает что "краем уха услышал - это не канает, ты там что-то додумал" - на это отвечаю - пошли нахуй. А Вы почитайте её с точки зрения того, кто за весь этот концерт платит.
Смотрите, ситуация.... На самом деле, я сейчас понимаю что трудно придумать аналогию, но буду стараться как могу. И давайте может, постараюсь "притянуть за уши" ваш пример.
Вот у вас есть деятельность - выставление заказов, по прайсам от поставщиков. Предположим, у вас есть какая-то методология... Ну там:
1. Принять прайс
2. Оценить его, вычистить мусор
3. Сложить в свою базу
4. Проанализировать, выбрать лучший товар, и сделать заказ.
И дальше, представьте... У вас есть две команды (наверняка для вас это непозволительная роскошь, но, представьте).
Одна команда - это IT. А вторая команда - это ваши пользователи (для айти - это бизнес-пользователи, заказчики, ну или как хотите их называйте). И тут нужно сделать еще одно допущение - ваши бизнес-пользователи - не просто умеют по телефону лялякать, а они еще и на питоне захуярить что-то могут, в базах ебашут на SQL на право и налево, и могут организовать бизнес-процесс на одних хранимках T-SQL (PL/SQL, pgPLSQL, да похуй... короче, на любых).
И ваши пользователи, в рамках выполнения цели по задаче - могут наебашить что-нибудь на питоне, потом, они еще не гнушатся взять трубку и позвонить поставщику лично... Узнав детали, они ручками что-то правят в Excel. И на выходе, для получения конечного результата, ручками забивают определенные цифры в "заранее подготовленный лист на котором готовы все формулы".
Параллельно сидит команда IT и хуярит на Java супер-энтерпрайзное решение, которое автоматически под нагрузкой умеет "в параллеле" обрабатывать много каталогов от поставщиков и автоматически делать все действия (4 шага) - описанные выше. При этом, когда команда IT слышит, что команда заказчиков, пока ждет (оооочень долго ждет) готовности разработки всех задач, которые им нужны, чтобы эффективно выполнять вышеописанную методологию из 4 шагов, параллельно побыстрее автоматизирует части шагов на питоне, а что-то и просто в Excel руками делают, то команда IT даже чуть ли не смеется над командой заказчиков, типа "ебать они долбоебы, пиздец, автоматизация в Excel, ну это же пиздец, у нас же тут Java, Kafka, микросервисы, spring.... А они дурачки всё по старинке в Excel делают".
Идут годы (да, годы). И команда заказчиков как-то уже привыкла к своим поделкам на Python+Excel, а команда IT все доделывает свой монструозный продукт (но со всеми атрибутами пиздатости, аля кафки, спринга и прочего говна). И постепенно уже руководители бизнеса начинают задаваться вопросом, мол, а нахуя козе баян как говорится. Мы тут платим дохуя бабла чтобы у нас тут все было как в энтерпрайзе, и кафки и спринги, но оно все не взлетает и не взлетает... Причем бизнес видит, что пользователи, которые хуярят на питоне выдают задачи быстрее чем IT.
Ну и так как это большая корпорация с "нетоксичным коллективом", то ни у кого смелости не хватает сказать - это всё полное фуфло, выкидывайте это говно, ваша джава говно, нихуя не работает, кафку тоже не можете настроить - собрали вещи и проваливайте нахуй отсюда, не занимайте места и не тратьте ФОТ.
Вместо этого начинается все "из далека". Бизнес начинает предлагать всякие штуки. Например, бизнес говорит - а давайте что-то сделаем чтобы можно было и вашей штукой пользоваться, и чтобы пользователи на питон могли бы быстро прогонять скрипты свои. В ответ IT отвечает что мол - мы подумаем, бла бла бла. Но, у IT явно не видно желания пачкать руки в этом гов... питоне, поэтому IT как-то сводит такие подходы на нет, потому что это не ынтырпрайзно... ниправильно... Ну и можно там до кучи, не соответствует паттернам-хуяттернам каким-нибудь, или там, не соответствует методологии SOLID (ну или не методологии, а как эта хуета называется), KISS и прочие прочие умные словечки, зная которые можно набить себе зарплату повыше.
Ну и на финальной стадии, приходит бизнес со следующим предложением. Дальше, я приведу пример разговора одного человека, который, назовем так - главный по Java в проекте со стороны IT и кого-то со стороны бизнеса.
Тут я могу почти как цитату привести ответ главного по Java, во время разговора по телефону с одним из представителей бизнеса с другой стороны. А то что сказал представитель бизнеса - я могу только предположить, но из ответа главного по Java это следует.
Так вот, восстанавливаем примерно разговор. У нас два действующих лица, назовем их - Java (J) и Business (B).
B: Привет, ну что, давай обсудим основные направления развития системы
J: Хорошо, давайте.
B: Видите ли... Мы посмотрели на общие результаты команд за прошедшее время, и увидели что наши пользователи на питончиках вроде что-то выдают, а вот на Java система все дорабатывается и не успевает за потребностями бизнеса
....
B: И у нас родилась идея. С учетом вышеизложенных факторов, мы хотели бы предложить, чтобы ваши разработчики тоже бы занялись бы питоном, и вместе с нашими бизнес-пользователями они выдали бы еще больше результата...
J: Нет нет нет... Этому не бывать. Вы хотите чтобы разработчики на Java начали переквалифицироваться в разработчиков на питон. Этого не будет, мои разработчики не будут этого делать. Посмотрите на зарплаты Java разработчиков и на зарплаты Python разработчиков. Для моих разработчиков этого будет даунгрейд, никто не будет этим заниматься.
--------------------------------------------------------- END ----------------------------------------------
Конец истории....
Интересно Ваше мнение, со стороны бизнеса )))
По-моему похожие ситуации происходят повсеместно. Например, я менее чем за год уверенно стал писать на php только потому что модули для 1с Битрикса приходилось допиливать самому, иначе от разработчиков не дождешься. А если почитать комментарии к модулям 1с Битрикс, то приходишь к выводу, что большая часть пользователей 1с Битрикса тоже допиливают функционал этих модулей самостоятельно.
Что касаемо Java и Python, то зачем разработчикам изучать Python и писать на нем,если можно сконтачить их и другими способами? Например, Delphi 7, на котором я сейчас в основном пишу, не умеет работать с протоколом HTTPS. Раньше таких проблем не было, поэтому я на нем раньше даже парсеры писал. А теперь многие сайты работают на HTTPS. Приходилось заказывать парсеры на фрилансе. Писали мне на питоне. На выходе была таблица с кривыми данными, а формат не соответствовал расширению.
Поэтому, я написал программу на Делфи, которая запускала прогу на питоне. Как только программа завершала парсинг,моя программа меняла расширения файлов на правильное,запускала bat файл, в котором поочередно преобразовывались файлы из xlsx в xls при помощи консольной программы. Это делалось, чтобы не применять OLE. А потом прога анализировала и переделывала данные правильно.
Аналогично проделывал с API. Мне надо было новые товары загружать в кассу через API. Для автоматизации процесса. Но это можно сделать только через HTTPS товароучетной системы. А Делфи так не умеет. Поэтому я написал php скрипт, который работает с API. Получилось так:
Программа на Делфи архивирует данные о более 20 тысячах товаров (1 секунда) и загружает на поддомен моего скрытого сайта по http (2 секунды). После загрузки это все разархивируется скриптом php. Далее программа на Делфи запускает скрипт,который отправляет данные по https по API (2-3 минуты).
Ваши разработчики могли бы написать ПО так, чтобы оно могло обрабатывать выходные данные, получаемые от ПО, написанного на питоне. Или автоматически запускать эти программы, а потом обрабатывать полученные данные
Вершина автоматизации - Excel. Может тогда выкинуть нахуй все эти питоны, мл и прочее, ведь это дорого, геморрой, проще ручками сделать быстрее. Ну или в ход пустить тяжёлую артиллерию - ВПР.
Нахуй вся эта OLAP аналитика с расчетом нарастающих итогов и с разбивкой по регионам и товарным группам)
Для автоматизации я применяю Delphi 7 (да, до сих на нем пишу, по мне намного лучше питона), php, Android Studio (Java). Если мне нужна аналитика по продажам, то я запускаю уже давно сделанную страницу php и она мне выдает нужные мне таблицы: что и сколько докупить, чтобы на месяц хватило, сколько заработал сегодня, вчера, за неделю, месяц, год, сколько чистыми, сколько с налогами и комиссиями и так далее.
Другое дело, когда мне поставщики скидывают прайсы только в форматах Эксель. Не вижу проблем за пару минут сделать заказать с помощью ВПР.
Нафига? Чтобы потом обратно перевести в Эксель и отправить заказ поставщику? Мне проще открыть в Microsoft Excel и применить функцию ВПР. Потом лишнее удалить и отправить поставщику. Работы минуты на 2
А меня никто и не лишал экселя. Я до сих пор пользуюсь экселем. Просто давно вижу призывы переходить на российский софт, про импортозамещение. А какой смысл, если он тормозит?
Я не спорю, что при необходимости даже ежемесячного обмена информацией, разумно обменяться сертификатами и сделать интеграцию.
Но разовые запросы всегда будут, для разовых запросов формат электронной таблицы удобней, а значит ограничение в 20 тыс. строк становится неприемлемым.
А если у меня, например, киоск на рынке с овощами. Разумно мне, моим конкурентам и моим поставщикам будет обменяться сертификатами и сделать интеграцию?
У меня, конечно, не киоск с овощами. В нашем городе примерно 120 магазинов нашей направленности. Из них только у 6 магазинов есть хоть какой-то товароучет. В основном в 1С. В у нас самописная система на Делфи с экселем, потому что 1с розница зависает на попытке загрузить в нее даже 10 тысяч товаров. А у нас уже более 25 тысяч наименований.
Но речь не о 6 магазинах,а об оставшихся 114 магазинах, у которых нет ТУС И которые навряд ли смогут реализовать интеграцию.
Это все условности в ваше голове. Так или иначе любой производитель уже ведёт каталог продукции, а значит создать сервис на основе этой базы/выгрузки вполне под силу. Ничего там такого сверхъестественного нету. И да,это вполне по силам нормальному сеньеру, даже без аналитика, за разумный срок. Уж крупный производитель вполне осилит пару тройку разрабов. Да и кто то у них содержит ИТ, и поднять докер с парой сервисов вполне по силам даже админку толковому - ничего там мудреного нет.
В общем это просто не желание/не понимание сделать нормально. Проще же содержать нескольких менеджеров, которые будут ручками обновлять, ошибается. Им будут бесконечно звонить заказчики, уточнять позиции, возмущаться что в прайсе естьч по факту нет, т.к. девочка проехала позицию. Ну да,это же хорошо выглядит - бурная деятельность и похер что КПД к нулю стремится. В свое время когда отвечал за закупку офисной техники, заебала такая вот контора с вечным бардаком с прайсами - нахер их отправил и ушел к другим поставщикам. Даже откат мне их не всрался.
А мелкие производители могут пользоваться готовыми сервисами. Гугл в помощь - полно всяких. Но там же целых 5 тыщ в месяц платит надо! Не, мы лучше обезьянью работу делать будем в Экселе,который внезапно нихрена не имеет той функциональности что нужна. Так, лишь лёгкое облегчение типа авто фильтра.
Автоматизировать иди нет - дело сугубо личное. Если я вижу что на сайте нет цены, типа звоните уточняйте - сразу нахуй. Понятно что этот геморрой будет. Начнут выяснять, потом ещё пять раз поменяют в итоге просто время потеряешь. То же самое и обычными магазинами - не могут сразу сказать цену - идите нахер.
В Экселе есть очень удобная функция - ВПР. И остатки можно с помощью нее вычислить, добавить в прайс проданное.
