<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Бизнес с автомобилем если и можно сравнить, то только в нескольких конкретных случаях. В остальном же, автомобиль это завершенный продукт. В мастерской не просят его ускорить в несколько раз, сделать из него самолет, корабль, танк и т.д.
Представители бизнеса изначально конечно не могут написать ТЗ, но должны к этому стремиться. Зачем они тогда нужны, если не могут объяснить, чем они занимаются и что им нужно. Тогда комании будет хватать только ИТ-отдела с программистами из разными направлениями/опытом для решения задач бизнеса и отдела операторов, которые просто будут заполнять нужные данные.
Мотивация — это краеугольный камень любых начинаний и процессов. Именно мотивация определит, будет ли движение и в какую сторону. Именно отсутствие мотивации со стороны руководителей бизнеса мешает развивать что-либо. Собственники и руководители хотят видеть уже опытного сотрудника, который будет сам все делать, позволяя руководству/собственникам ничего не делать. И чем больше, тем лучше.
На шкале истории бизнеса просто есть маленький отрезок, который называется «увлечение информационными технологиями», который начался весело и интересно, а превратился в глобальное мошенничество.
О, мошенничество значит….
Автор, вы давно в какой-нить ашаниум заходили? Вы так для интереса можете представить сколько времени будет составляться один отчет о продажах, которые каждый ашаниум и не только он обязаны делать каждые сутки? Так, без компа, чисто ручка + бумажка?
Банальная фигнюшка — этикетка со штрихкодом — это тоже информационные технологии, представляете? А благодаря этому + POS один кассир заменяет 3-4 кассиров «без штрихкода».
Это так, вполне себе очевидные для всех применения этих самых технологий.
Так что с мошенничеством вы как-то погорячились
Осталось найти достаточное количество управленцев, владеющих эльфийским, а не детским лепетом…
может быть вместо google translate поискать грамотного «переводчика» ?
Спорно. Я сторонник того, чтобы Эльфийский учил тот, кто бегает по совещаниям и кого автор в других своих статьях назвал координатором, а затем переводил для всей команды. Видится более эффективным решением, чем обучение ослов богословию.
Человечество не молодо. И период взаимопонимания, судя по выдолбленным в горных массивах дворцовых комплексах, у него позади.
К выполненной задаче наш вид очень быстро охладевает. Я думаю, сейчас нет цели, чтобы было все хорошо. (но, см. PS)
Другое дело — устроить шабаш
юзпользователей, которые вводят в ТЧ и справочники ахинею, несмотря на проверки заполнения и фильтрацию ввода значений на двойные/тройные пробелы.Разозлить «умного» программиста и сделать из него тупого — это же очень интересная игра в стиле Огги и коркоачес,
P.S. Но стремиться к совершенству — это мне по душе. Несмотря на искусственные сложности.
Вот читаю очередную крутую статью автора и просто даже подумать страшно, как его трясет на всевозможных совещаниях и обсуждениях в его очередной организации от бессилия, когда очередной главный бухгалтер или начальник снабжения начинает предлагать что-то «новое и эффективное»)
Написано все красиво, но донести до конкретных людей все эти знания и выводы практически невозможно — слова всегда останутся только словами, какими бы логичными и четкими они не были) Только испытания на собственной шкуре дают людям мудрость, к сожалению. Тем более программист в организации — это не тот советчик, которого будут слушать, даже если этого программиста назвать аналитиком бизнес-процессов, начальником службы автоматизации бизнеса и прочими красивыми должностями.
В любом случае, удачи автору в достижении своей благородной цели)
«Почему бизнес и ИТ не понимают друг друга?»
Потому что они немного про разное.
«И как сделать, чтобы понимали?»
Добавлять одной из сторон понимания другой стороны. Очевидно, что гораздо проще добавить ИТ понимание бизнеса, чем наоборот.
Вау.
Я думаю, вопрос решения бизнес-задач несколько глубже, чем просто бизнесменам и программистам научиться друг друга понимать. В ваших статьях я уловил некую мысль, что якобы существуют какие-то «бизнес-программисты», которые способны решать задачи вроде «уволить двух бухгалтеров», «снизить остатки на складе на 50%», а то и «повысить продажи в два раза». Ни один программист не способен решить такую задачу, это полностью другая область деятельности. И я скажу больше, ни один начальник, который приходит к программисту с очередной задачкой «сделай мне вот такой отчет» — тоже не знает решения. Т.е. нет однозначного решения, что вот этот вот отчет делает работу одного бухгалтера не нужной. Можно лишь пробовать, тестировать. Глядишь, на 100-й раз что родится путное, продвинет бизнес вперед. Программирование — это вообще про другое. Это про то, как в условиях ограниченных данных составить какой-то понятный алгоритм действий. В реальном бизнесе очень мало понятных алгоритмов действий. Методик и технологий много, но что сработает для конкретного бизнеса — большой вопрос. Поэтому четких алгоритмов решения задач (с понятными исходными данными, ресурсами, результатами) — не существует, поэтому навыки программистов для решения таких задач малоприменимы.
Нет поэзии, произведений искусства, вау-эффектов и взаимного обожания бизнеса и ИТ. Говоря приземленно, нет ИТ-решений, реально помогающих бизнесу.
это заблуждение, уважаемый автор.
Фишка в том, что те самые решения являются штучным товаром, они уникальны и полезны только вот этому конкретному бизнесу и составляют так называемое конкурентное преимущество.
Поэтому Вы про них и не знаете.
(9) Вопрос оптимизации существующих процессов программист таки может решить удачно.
(11) Вряд ли, ведь он не понимает, как именно существующий процесс влияет на деньги. Т.е. взять произвольную компанию — и дать задачу программисту: «на-кось, оптимизируй», то результат будет нулевой или отрицательный.
(12) Это весьма спорное заявление. В большинстве случаев разобраться, как процесс влияет на деньги, не представляет особой сложности.
Язык бизнеса невозможно выучить, потому что у бизнеса нет языка. Стоит перейти с одного предприятия на другое — становится ясно, что эльфийский язык — это ересь и абракадабра. Все разговаривают на языке руководства. У каждого директора свой язык. Предметная область — это хаос, который будут бесконечно автоматизировать, но дело, по сути, с места так и не сдвинется. И тут даже серебряная пуля ни чем не поможет.
Проблема в том, что, если язык ИТ строг, устойчив, функционален и полностью выполняет свою задачу, то язык бизнеса находится на первобытном, пещерном уровне развития. Это еще даже не язык вовсе, а скорее невнятные мычания, изредка напоминающие хоть какой-то набор слов.
Что нужно, чтобы было хорошо? Первое и главное — всеобщая консолидация бизнес-знаний, полная ревизия, классификация и каталогизация всех понятий. К сожалению, ничего подобного в ближайшем будущем не просматривается. Так что можно спокойно продолжать автоматизацию хаоса. Это не мы сделали бизнес таким, и его языковые трудности — не наша сфера. Это забота тех, кто занимается бизнесом. Так пусть они поднимут голову над своей делянкой и займутся своим языком.
Нет, конечно. Только сравнение некорректное. Автосервис это уровень техподдержки — возникла ошибка, не проводится, проводится не так.
Но если вы приедете в тюнинг-ателье, то от вас захотят конкретное ТЗ. Иначе сделают на свой вкус. А там нравится или нет — не их проблема. Плати деньги и забирай. Или второй вариант — давай конкретное ТЗ и плати повторно чтоб переделали.
Задача: Сеалать чтоб не было дефецита (добавить кнопку «Сделать хорошо») — это не задача.
Большинство бизнюков — не знает никакого языка бизнеса. И эти процессы от них так же далеки как и програмный код.
ну и вообще — это отдельная профессия «бизнес-аналитик», который может посмотреть как есть и предложить как нужно.
И совет из серии: мышки — становитесь ежиками
(8) Если представители ИТ поймт бизнес — зачем им тогда им нужен, они откроют свой бизнес, а со знаниями ИТ они заткнут бывших заказчиков, а ныне конкурентов за пояс!
та прослойка — это, как правило, тимлид, или директор (если фирма небольшая) — то есть тот, кто сам в этом варился/варится, и не уйдет, набравшись знаний. Тимлид, а особенно если он хороший аналитик, видит что 2 бухгалтера делают тупую работу 7 часов в день, и дает задачу на доработку, чтобы заменить их 1 обработкой. Я такое не раз делал, но понять что именно сделать, и где та самая «дырка» — работа ТЛ. Собсно поэтому тимлид получает больше архитектора, хотя знает в ИТ и меньше..
А бизнес-аналитикам то за что досталось?
Вообще, наверное, ваша точка зрения имеет место быть, в некоторых случаях. Но я все же считаю, что разработчику в общем случае не нужно тратить время на изучение «эльфийского». И вот почему:
В IT-компаниях (НЕ в 1С-ном мире уже давно, в 1С-ном пока не везде, но процент растет) уже давно произошло разделение на аналитиков и разработчиков (а также тестировщиков, администраторов и др.). Появились аналитики (или консультанты) уже и на конечных предприятиях. Здесь каждый участник команды хорошо знает именно свою область и работу: аналитики общаются с бизнесом, разработчики программируют. Узкая специализация и разделение труда — хорошо это или плохо? Не мне судить. Но я убежден, что команда из 3 хороших аналитиков и 2 разработчиков сделает работу намного эффективней (качественней, быстрее, дешевле), чем 5 разработчиков 1С, пытающихся разговаривать с бизнесом на их языке.
Ну, собственно, верно всё. А ещё слух был, что придумали зачем-то строительных архитекторов, сметчиков, каменщиков, крановщиков, штукатуров, маляров, дизайнеров интерьеров … Выдумают же, вот чесслово 🙂 Туалет на даче и без всей этой братии могу построить, легко! Хотя погодите, говорят, в городах то туалеты прям в домах, да ещё и в несколько этажей…
Имхо, эта проблема связана либо с аутизмом (диагноз) либо с саботажем / прокрастинацией в случаях не связанных с нарушением психики. И то и другое форс мажорные обстоятельства. В первом случае бизнесу придется и учить клингонский и нанимать аналитиков или менять разработчиков. Во втором поможет примитивный аджайл с увеличенным интервалом между спринтами, чтобы разработчик, который погружается в проблему полностью, имел возможность выйти из астрала (или вынырнуть из выгребной ямы, называемой конфигуратор) и обратить свой взор на реальные проблемы как собственные, так и проекта. Или так же как в первом случае
нанимается аналитик или меняется разработчик. Понимает разработчик эльфийский или нет значения не имеет. понимание бизнесом клингонского снижает количество архитектурных ошибок. Понимание программистами эльфийского уменьшает ошибки кодирования и модификации. Тот кто идет в лес может делать себе посох из подножных материалов. Но если он ищет в нем партизан, то деревьев не увидит. В этом кроется причина бесполезности ежедневных и вообще периодических планерок и совещаний. Они проводятся перед началом и по окончании спринта. Если этого недостаточно, меняется размер спринта.
Мой вывод из статьи — в понимании нет необходимости. Достаточно исполнительной дисциплины и работающего отдела кадров. Но этот вывод сделан на базе отношения с работниками фикси, фри или франчи — не важно.
Нюанс в том, что при отношениях между клиентами и командой разработчиков проблемы понимания не возникает. Будь то отдел разработки, франч или отдельный фикси. Как в стране Оз. Говорят и понимают на всех языках даже Тотошка со Страшилой. В отличие от хоккея или футбола состав команды может меняться в процессе матча лиги чемпионов причем на место вратаря и нападения ставят свежих нетренированных новичков, которых срочно нужно прокачать ( они дешевле и не защищены контрактом). А состав тренеров вполне может в это время сделать ставку на победу противника или конкурента. Предметом обсуждения будет кто на сколько попал или кто кого кинул( выражаясь по эльфийски). Каковы принципы работы в такой команде?
Сравнение с автосервисом категорически неверное. Ваш автосервис — это аутсорсинг по обслуживанию компьютеров и сети. Они не спрашивая ТЗ почистят сеть от вирусов, настроят бэкапы, дадут рекомендации по замене оборудования… Но они не модернизируют ваш программный продукт. Так же как и большинство автосервисов не возьмётся установить на вашу малолитражку 30″ колёса и движок на четыреста лошадей. А вот если вы таки захотите подобное и найдёте где, вот тут уже с вас запросят много-много дополнительной информации. Потому что вы хотите только колёса и движок, а надо бы еще корпус укреплять, амортизаторы другие, глушитель на крышу поднять и тому подобное.
Наша контора в основном занимается разработкой и сопровождением ПО, в том числе сайтов, для организаций в области экспертизы строительных проектов. Нам учить язык и вникать в дебри экспертизы строительства? Там много специфичного.
(26) вы наверняка уже вникли.
Но вообще, вникать в специфику бизнеса не нужно, достаточно вникнуть в основные понятия, которые актуальны для любого бизнеса — процессы, система управления, цели функций и т.д.
Это все равно, что для программиста понимать алгоритмы, функции, классы, методы, свойства, асинхронность, запросы и т.д.
В разных языках и средах программирования есть свои особенности, но базовые понятия остаются на месте. То же и в бизнесе.
Если вы понимаете, что такое абстрактный процесс, и что с ним можно делать — ускорять, упрощать, повышать надежность, управлять им — то можете улучшать процессы любой компании.
Так же, как вы можете написать функцию или сортировать массив на любом языке программирования, освоив его базовый синтаксис.
(20)
убежденность — это хорошо. На фактах удавалось проверять?
Я вот прям сейчас наблюдаю картину, когда 2 хороших аналитика, очень глубоко понимающих бизнес, ставят трем крутым js-разработчикам такие задачи, что плакать хочется.
(17)
это вы два стереотипа в кучу смешали. Никто не понимает задачу устранения дефицитов, как большую кнопку «Сделать хорошо».
Такую задачу просто не ставят, заранее считая ее не решаемой, именно в такой постановке. Сразу, в ходе первого же обсуждения, начинают дробить на куски, раздавать в разные отделы, тем самым переводя цель в разряд недостижимых. В терминах статьи — сразу переводят на эсперанто.
(20) Нет такой науки «экономика», есть наука «математика» (с)
Кто такой аналитик?
Лично у меня сам факт существования такой профессии вызывает некоторый разрыв шаблона.
3 аналитика на 2-х разработчиков??? о_О
(20)(20) Нет такой науки «экономика», есть наука «математика» (с)
Кто такой аналитик?
Лично у меня сам факт существования такой профессии вызывает некоторый разрыв шаблона.
3 аналитика на 2-х разработчиков??? о_О
(32) Языки видимо совсем сложные (хотя, скорее всего, языка как такового нет), раз 3 переводчика нужны…
(32) Сформулировать проблему или потребность, как правило, сложнее чем реализовать. Если цель очевидна, то нет затрат времени разработчика на бесконечные уточнения требований
(34) (34) Напоминает ситуацию, когда один «копает», а всё остальные только «ставят задачи». Видели такую картинку?
(36) Не видел, мне только вчера интернет провели.
По сущетсву вопроса: какая разница что это может напоминать если так эффективнее? Другой вопрос если эти три аналитика там потому что «так у других, а мы чем хуже?» Но это скорее подтверждает утверждение, чем его опровергает.
(37)
ИМХО, сомневаюсь.
Уж скорее эти три аналитика там просто потому что нет трёх дополнительных разработчиков.
У бизнеса одна задача — создать стоимость. Заработать. Как это будет решаться в каждой конкретной организации — дело управленческое. Но любое «заработать» состоит из стоимости продажи за вычетом стоимости приобретения (создания, придумывания, …). В итоге любой бизнес хочет как можно больше заработать и как можно меньше потратить, но из-за лени и некомпетентности руководства, как основных стейкхолдеров, влияющих на стоимость, часто принимаются компромиссные решения типа «сделать это с минимальными телодвижениями с нашей стороны», т.к. руководство — это не владельцы бизнеса, а те же наемные сотрудники. И только владелец (если это конкретный человек) может мыслить немного по-другому, предъявляя требования не столько к продукту, сколько к снижению стоимости владения при достаточном на его взгляд снижении затрат (ибо ИТ — это в первую очередь именно снижение затрат, но оно должно быть выше стоимости владения) или увеличении производительности труда (что, опять же, влечет за собой снижение затрат на единицу продукта).
В итоге бизнес в лице владельца хочет от ИТ снижения затрат и увеличения производительности труда, а управленцы — минимального движения их телесами, при котором можно сохранять статус кво или даже продвигаться вверх. Вот и весь язык бизнеса. Есть еще пограничные варианты, но мотивация у всех — больше денег и меньше движений.
Не могу согласиться с базовым тезисом.
Программистам — действительно нельзя. Потому, что это задача для специалиста по управленческому учёту и/или по оптимизации бизнес-процессов.
Вообще есть хороший критерий качества постановки задачи: если понятно, как выполнить задачу вручную (пусть это и будет крайне трудоёмко), то эту задачу можно и автоматизировать. Ну а если нельзя — значит, постановка негодная.
Вся так называемая ИТ — «неизбежное зло» по определению, потому что бизнесу не нужны «компьютерные программы». Бизнесу нужны решения задач.
Если задача решается программой или её доработкой — это хорошо (причина терпеть), программы и их доработки стоят денег и требуют времени (несомненное зло).
(40)
И тут же:
Что-то я потерял нить.
Вообще, поставить можно любую задачу, и выполнить можно любую задача, но эффективность выполнения задачи — это потенциальная выгода, деленная на стоимость времени исполнителя. Если исполнитель будет делать это миллион часов, а пользы от этого три копейки, то считать данный труд эффективным не представляется возможным.
В шестнадцатом, если не ошибаюсь, веке появился капитализм с первыми мануфактурами, суть которых сводилась к разделению труда, обеспечивающему повышение этого труда производительности. В пределе разделение труда привело к созданию конвейера, простые операции на котором можно было освоить любому олигофрену. Теперь вместо олигофренов там роботы, а процесс разделения труда активно атакует современную ИТ-отрасль. Например, в веб-разработке современные верстальщики, из которых раньше вырастали фронтэнд-кодеры, в большинстве своем не хотят развиваться дальше, оставаясь верстальщиками — зарплата их уже позволяет вполне себе жить. Т.е. нет уже практически пресловутого аникейщика, который и программист на всех языках, и сайтостроитель, и админ, и компьютерный мастер с паяльной лампой на перевес. Закончился период «первоначального накопления капитала». Фуллстек-разработчики уже доросли до седин в бородах, а молодежь и одну простую область осваивает с трудом.
Отсюда как бы мораль: разделение труда — это хорошо. Аналитику аналитиково, программисту программистово. Не нужно все в одну кучу — лучше будет. Но если вдруг изъявит кто желание разобраться в языке бизнеса — молодцом будет и ожидает его долгая дорога по карьерной лестнице.
(32)
У меня не вызывает. Работаем по такой схеме много лет.
(32)
Да, именно так. В среднем отношение 1:1, все зависит от стадии проекта.
Ваша картинка сюда не подходит, т. к. в моем примере все 5 человек работают, только каждый занимается своим делом. Разработчики разрабатывают (и занимаются только этим), а аналитики занимаются сбором требований, уточнением этих требований, согласованием трудозатрат, вводом в эксплуатацию, обучением сотрудников, поддержкой пользователей в процессе эксплуатации и т. д.
Если всей перечисленной работой аналитиков вы хотите заниматься сами, то пожалуйста. Каждый делает то, что ему нравится. Просто вы работаете не разработчиком 1С, а консультантом-разработчиком 1С. И я не говорю, что это плохо. Мне просто почему то кажется, что при прочих равных моя команда эффективней, хотя подтвердить это цифрами я не могу, да.
(28)
Ну что же? Всяко бывает. Вполне возможно, что поработав таким составом, сделав несколько совместных проектов, вы в итоге выйдете на пик производительности команды. А аналитики научатся ставить задачи и таким крутым разработчикам, особенно если крутые разработчики им в этом помогут.
(42) Наверное вы правы, просто в наших краях таких аналитиков очень мало
(12) там и понимать нечего, сокращения времени выполнения процесса напрямую влияет на деньги. потому что время всегда деньги.
(28) лучший аналитик, это бывший разработчик, который перешел
(45) свободное время ваших сотрудников — это просто дополнительно выпитые чашки чая 🙂 Если у вас был случай в практике, когда вы что-то автоматизировали, сократили время какого-то важного процесса, и тем самым увеличили поток прибыли компании — расскажите, пожалуйста.
(47)Это если это освободившееся время ничем другим не занимать. 99% сотрудников сами не придумают, чем им для пользы компании заниматься 🙂
Друзья, прошу прощения за спам — поучаствуйте в .
(12) Не соглашусь. Например, в одной конторе за несколько лет только недавно сумели посчитать прибыль, со всеми вытекающими. Мне кажется это нифига не минус, а живые деньги. Или, например, в одной конторе уменьшили воровство. Тоже вроде как деньги. Конечно, это работа не только программиста, а целой команды, состоящей из программиста, гл.буха и директора. Только почему-то раньше эти задачи не могли решиться и все бились головой об стену.
В общем, может и ошибаюсь сильно, но так смело бы не утверждал про программистов.
Эсперанто — ущербный суррогатный монотонный как заевшая пластинка недоязык, основанный на латинской лексике романских языков, по сути суррогатный итальянский. Лучше использовать настоящий итальянский, он намного изысканнее и интереснее!