Если вы не сокращаете, а переобучаете людей, то выходит, что вы начинаете а) платить больше ФОТа более квалифицированным сотрудникам б) добавляете ФОТ тех, кто настраивает роботов и в принципе участвовал в процессах - например, отвлекаясь от основной работы в) платите за лицензии владельцу RPA ПО, правильно я понял?
То есть внедрение RPA не уменьшает ФОТ, а увеличивает?
Можете рассказать, какие количественные показатели были поставлены по целям до запуска внедрения RPA?
Ошибаются. Обязаны в течение 7 дней дать письменный ответ о причинах отказа, если вы об этом потребовали. Другой вопрос, точно ли вы хотите с такими людьми как-то дальше общаться? Может быть, и к лучшему, что вам отказали.
Вы игнорируете то, что я пишу. И про числодробилки, и про тестирование на практических задачах, а не на синтетических тестах, и про то, что вертикальное масштабирование уже давно не основной вариант.
К счастью, вне зависимости от того, что себе там думают интернет-эксперты, "Эльбрус" развивается и будет развиваться дальше
Там нет ни RAC, ни Oracle Streams/GoldenGate, ни AdvancedQueueing, ни Flashbacks, ни Report Services, ни монитора, даже embedded java нет. Про APEX не помню, есть ли, возможно, тоже нет. В общем, можно длинный список перечислить, чего там нет
В большинстве военных и гражданских применений будет перспективен. Для настоящих числодробилок используют специальные устройства типа видеокарт и других акселлераторов, что касается производительности типовых приложений (особенно веб), то один раундтрип запроса между БД и сервером приложений съест все выигрыши оптимизации под конкретную архитектуру.
Сколько в итоге будет отставание производительности на практике - 20% 40%? Это все ерунда, уже давно никто не ускоряет задачи вертикальным масштабированием single core, single thread
В этой статье я вижу антологию домыслов. Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так? Непонятно.
И заканчивая поиском заговоров в типовой схеме b2b приобретения изделий. К слову, Oracle работает так же, по запросу, продавая свои БД, бесплатная ознакомительная версия у них появилась относительно недавно, и она не содержит всех коммерческих фич вообще.
Очень хотелось бы в следующей статье увидеть факты, исследования и отсылки на авторитетные мнения.
Отказываясь от менеджмента, их работу все равно никуда не деть, кроме как переложить на разработку. И вот уже разработчики должны отвечать и за приоритизацию, и за достижение консенсусов, и за то, что требования не потеряны. И это только начало. Но переложив ответственность, никто не задумывается над тем, что и платить за эту работу тоже надо отдельно. Все это -- прямой путь к выгоранию
Тут надо обратить внимание, что "ТЗ по ГОСТу" в самом ГОСТе называется "ТЗ на создание автоматизированной системы". То есть в общем случае оно содержит требования не столько к самой АС (там они рамочные), сколько к процессу создания, а именно: план, бюджет и источники финансирования, сроки, порядок и условия привлечения подрядчиков, план запуска очередей и предоставления промежуточной и итоговой отчетности, порядок приемки готовой системы. То есть ТЗ по ГОСТ 34 это высокоуровневый план работ, а не SRS, software requirement specification или product description, или как там принято называть
Я не знаю, нужны ли вам тут советы, но напишу. В моем понимании, разработчик занимается непотребством, потому что к категориям "задача сделана" и "задача не сделана" добавляет на свое усмотрение какую-то недиагностируемую третью "задача сделана настолько, насколько захотелось ее сделать сегодня". То есть пытается сдавать вам и заставить вас принимать у него, по сути, неоконченную работу. А если дозволительно одному -- остальные тоже могут начать так делать
Движение вполне понятно. Государство продолжает оставаться большим заказчиком на крупных инфраструктурных и социальных проектах. Для того, чтобы правильно учесть и распорядиться деньгами, выделяют филиалы и целые банки, обслуживающий вполне конкретные направления ден.потоков. При этом если смотреть на картинку в целом, движения средств в конечном итоге -- это перемещения единичек и ноликов на счетах, подконтрольных ЦБ, а ненужные прокладки в виде банков тут только мешают. Цифровой рубль позволит обеспечить гораздо большую прозрачность и убрать накладные расходы в виде учета. Еще бы ПФР так же развалили..
Да, спасибо, но там совсем другая платформа (два процессора), плюс код заброшен — я так понял, это была короткая работа силами студентов, а летает все равно сишная прошивка, плюс в сенсорфьюжне Махони также есть ошибки
Таких планов не было — стоимость переключения на другую прошивку неподъемная, плюс разные cleanflight, betaflight предлагают значительно больший объем сервиса, которого в прототипе нет и не планируется. Но можно обсудить разработку безопасной прошивки конкретно под вашу плату
Если вы не сокращаете, а переобучаете людей, то выходит, что вы начинаете а) платить больше ФОТа более квалифицированным сотрудникам б) добавляете ФОТ тех, кто настраивает роботов и в принципе участвовал в процессах - например, отвлекаясь от основной работы в) платите за лицензии владельцу RPA ПО, правильно я понял?
То есть внедрение RPA не уменьшает ФОТ, а увеличивает?
Можете рассказать, какие количественные показатели были поставлены по целям до запуска внедрения RPA?
Очень понравилось изложение, спасибо большое, по сути - самодельный event loop. А что думаете о переносе большей части логики в NDK?
Ошибаются. Обязаны в течение 7 дней дать письменный ответ о причинах отказа, если вы об этом потребовали. Другой вопрос, точно ли вы хотите с такими людьми как-то дальше общаться? Может быть, и к лучшему, что вам отказали.
(Пояснения: https://rg.ru/2015/08/04/rabota.html)
Вы игнорируете то, что я пишу. И про числодробилки, и про тестирование на практических задачах, а не на синтетических тестах, и про то, что вертикальное масштабирование уже давно не основной вариант.
К счастью, вне зависимости от того, что себе там думают интернет-эксперты, "Эльбрус" развивается и будет развиваться дальше
Там нет ни RAC, ни Oracle Streams/GoldenGate, ни AdvancedQueueing, ни Flashbacks, ни Report Services, ни монитора, даже embedded java нет. Про APEX не помню, есть ли, возможно, тоже нет. В общем, можно длинный список перечислить, чего там нет
В большинстве военных и гражданских применений будет перспективен. Для настоящих числодробилок используют специальные устройства типа видеокарт и других акселлераторов, что касается производительности типовых приложений (особенно веб), то один раундтрип запроса между БД и сервером приложений съест все выигрыши оптимизации под конкретную архитектуру.
Сколько в итоге будет отставание производительности на практике - 20% 40%? Это все ерунда, уже давно никто не ускоряет задачи вертикальным масштабированием single core, single thread
В этой статье я вижу антологию домыслов. Начиная с того, что основным критерием перспективности процессоров здесь подразумевается показатель "Ватт/гигафлопс". Кто решил, что это так? Непонятно.
И заканчивая поиском заговоров в типовой схеме b2b приобретения изделий. К слову, Oracle работает так же, по запросу, продавая свои БД, бесплатная ознакомительная версия у них появилась относительно недавно, и она не содержит всех коммерческих фич вообще.
Очень хотелось бы в следующей статье увидеть факты, исследования и отсылки на авторитетные мнения.
Честно говоря, стало менее понятно, кто за что отвечает. Но понятно, в каком направлении растет
Отказываясь от менеджмента, их работу все равно никуда не деть, кроме как переложить на разработку. И вот уже разработчики должны отвечать и за приоритизацию, и за достижение консенсусов, и за то, что требования не потеряны. И это только начало. Но переложив ответственность, никто не задумывается над тем, что и платить за эту работу тоже надо отдельно. Все это -- прямой путь к выгоранию
Тут надо обратить внимание, что "ТЗ по ГОСТу" в самом ГОСТе называется "ТЗ на создание автоматизированной системы". То есть в общем случае оно содержит требования не столько к самой АС (там они рамочные), сколько к процессу создания, а именно: план, бюджет и источники финансирования, сроки, порядок и условия привлечения подрядчиков, план запуска очередей и предоставления промежуточной и итоговой отчетности, порядок приемки готовой системы. То есть ТЗ по ГОСТ 34 это высокоуровневый план работ, а не SRS, software requirement specification или product description, или как там принято называть
Я не знаю, нужны ли вам тут советы, но напишу. В моем понимании, разработчик занимается непотребством, потому что к категориям "задача сделана" и "задача не сделана" добавляет на свое усмотрение какую-то недиагностируемую третью "задача сделана настолько, насколько захотелось ее сделать сегодня". То есть пытается сдавать вам и заставить вас принимать у него, по сути, неоконченную работу. А если дозволительно одному -- остальные тоже могут начать так делать
Движение вполне понятно. Государство продолжает оставаться большим заказчиком на крупных инфраструктурных и социальных проектах. Для того, чтобы правильно учесть и распорядиться деньгами, выделяют филиалы и целые банки, обслуживающий вполне конкретные направления ден.потоков. При этом если смотреть на картинку в целом, движения средств в конечном итоге -- это перемещения единичек и ноликов на счетах, подконтрольных ЦБ, а ненужные прокладки в виде банков тут только мешают. Цифровой рубль позволит обеспечить гораздо большую прозрачность и убрать накладные расходы в виде учета. Еще бы ПФР так же развалили..