Сейчас в интернете рассказывают про преимущества автоматизации. Типа мол снижает нагрузку на человека, делает Ваш бизнес более гибким, подкованным. Можете выявлять слабые места, точки роста, оптимизировать процессы. На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д. и т..п. Не отрицаю. Но достаточно часто такая автоматизация не ведет к оптимизации а только ухудшает ситуацию. Я знаком с вопросом не понаслышке и хотел бы рассказать о проблемах. Благо отвечал много времени за приложения на предприятии.
Вот представьте ситуацию: есть конкретный отдел, который вручную собирает статистику делает бюджетирование. Из нескольких систем выгружают данные, потом эти данные объединяет. На этапе объединения надо где то данные сгруппировать, где то дополнить, где - то почистить. Много муторной работы. И вот появляется в таком отделе человек, который не только слышал что автоматизация это круто, но и вполне умеет работать с базами данных, настраивает экстракторы, писать скрипты и на всем этом хозяйстве строить отчеты. Навыки, на самом деле, не сильно распространенные, потому что чаще всего конкретно желающий предполагает что он может все это сделать.
И вот ему для всего этого счастья требуется база данных и доступы к нужным системам. Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы. Буду все делать в свободное время, но это поможет сократить n рабочих часов нашему отделу в месяц.
Ему вторит его руководитель: “...нам это очень надо, мы готовы даже бюджет выделить...”. Руководитель думает о том, что его сотрудники часто сидят до 11 часов вечера чтоб все это гавнище свести в единый отчет и очистить данные. Перепроверить. А тут ему предлагают золотой ключик. Инициативный сотрудник рассчитывает получить премию и внеочередное продвижение по службе. И вот приходят они к сатрапу айтишнику вроде меня. Который им говорит: “хрен вам а не база данных с доступами”.
Что в такой ситуации обычно делают сотрудник с менеджером: для начала начинают считать меня мудаком ретроградом. Потом жалуются на меня моему руководителю. Часто еще и вверх по вышестоящей лестницы. Но удивительным образом, со стороны и моего руководства чаще всего получают отказ.
И вот тут начинается самое интересное: они меня считают мудаком, потому что не знают всей кухни и последствий. Я же знаю к чему это приводит. Самые простые причины почему отказываю в улучшении бизнес процессов и оптимизации:
1. Лицензия на БД и железо.
Уже забыл все термины как это точно называется правильно с точки политики того же Микрософт, но используется одна лицензия на сервер (или ядро?) и на одном сервере можно располагать кучу БД. Так что стоимость одной бд получается недорогой. Но если давать базы данных всем желающим, очень быстро начинаешь налипать на новые сервера и новые лицензии. Отделов много, подразделений много, оптимизаторов еще больше и всем давай базы данных. Железо тоже стоит недешево под все это счастье. А еще это счастье надо бэкапировать и обслуживать. А бюджет на железо и лицензии не резиновый, и руководство и так долбит постоянно, что надо бы сократить расходы а не увеличить. У меня свои KPI у вас свои.
2. Есть штатные инструменты, которые не нравятся конкретному оптимизатору.
Простой пример: чаще всего выгружают и занимаются полной херней, ровно потому что учет сделать в корпоративной (так называемой ERP) непросто и дорого. Для примера SAP (1С чуть лучше но тоже не фонтан). Когда узнают сколько будет стоить нужная оптимизация в SAP (а там за самые небольшие поделки часто выставляется стоимость квартиры в Москве), все крутят пальцем у виска и говорят спасибо не надо. То есть, долго, дорого, херова (обычно еще и сроки все консультанты срывают).
А в это время оптимизатор показывает отчеты на каком нибудь power BI где в качестве источника данных используется несколько табличек. Конечно, это все запилить просто. И летает и красиво и вообще секси. А тут предлагают этот ужасный SAP. О чем Вы вообще?
Но как человек два десятка лет занимавшийся автоматизацией, я скорее отдам предпочтение сделать все штатными средствами на базе SAP, чем плодить сущности по желаниям. Пусть и дороже, но зато это будет работать и через 10 лет. А не 2-3 года пока есть оптимизатор. По факту выйдет дешевле (не топлю за САП, главное что в существующей ERP. SAP отстой)ю
Часто доходит до абсурда: одному оптимизатору не нравится SAP (и вполне заслуженно), другому оптимизатору не нравится power BI, третьему надо чего - нибудь на в tibco spotFire. Доходит до абсурда, когда в одном управлении одни и те же процессы сделаны разными инструментами. То есть, полный зоопарк. И вот тут подходим по сути к ключевому, почему такие ретрограды вроде меня отказывают.
3. Оптимизатор не имеет представления за что он берется.
Как ни странно, несмотря на огромное кол-во якобы инженеров, которое выпускают наши ВУЗы найти реального специалиста, который знаком и с базами данных, и с программированием (чтоб наладить те же экстракторы), чтоб еще писал запросы и умел визуализировать это все не так много. Вот тут писал про свой взгляд на возможности конкретных специалистов.
При этом, надо еще разбираться в конкретной области, которую ты оптимизируешь. К примеру, так как я автоматизировал управленческий учет, то во времена внедрения, разбирался в бухучете, складском учете или кадровом учете лучше рядового бухгалтера (при этом на всех участках учета). В качестве подтверждения своих слов могу привести факт работы в качестве руководителя кадрового подразделения. И не получил ни одного взыскания за это время (ИТ там не было никаким боком.. почти.. если не считать моего желания “оптимизировать” некоторые процессы).
Как вы понимаете, редко кто все это знает и умеет. Обычно человек даже не представляет тот объем, который он хочет оптимизировать. Было забавно наблюдать, как с одной и той же задачей ко мне приходили 4 раза из разных отделов, я им объяснял эту задачу (они узнавали много нового, вплоть до того, что я им отдавал мною лично написанное ТЗ из первой итерации), каждый раз брались решать и ни разу никто не сделал.
Хуже того, часто бывает что в результате “оптимизации”, время затрачиваемое на конкретную задачу увеличивается. И я это могу видеть сразу а оптимизаторы нет. Конкретный пример: приходит ко мне девушка, которая хочет повысить мотивацию работников для рацпредложений. Мне надо сделать такой то сайт, там должно быть это, это и это. И главное КРАСИВО! (за вот это красиво вообще убивать надо, но это уже отступление).
Общий смысл, что надо собрать рац предложения, сотрудники и руководители проставляют баллы по определенному алгоритму и всех надо оповестить. Причем баллы можно проставить в голосовалке в аутлуке, собрать рацухи через письма ну и выложить результаты уже на корпоративном сайте. Зачем под это все городить отдельный сайт, кто его будет делать и поддерживать она ведь не задумывается. Ей благодарность за такую инициативу надо получить. А я вижу что через отдельный сайт затраты на всю эту херню увеличиваются в разы. А еще вероятнее, что девочка побалуется с данным проектом пол года и потом успешно все забудут про эту супер пупер инициативу. Но конкретная девушка получила одобрение у высокого руководителя и уверена что ИТ должно все сделать. Благо я с этим руководителем был хорошо знаком (а он еще в придачу очень грамотный и знаком со всем написанным в сегодняшнем материале). На одном из совещаний в двух словах объяснил почему ей отказал. Он только посмеялся. В общем как говорится "Вам шашечки или поехать?".
4. Поддержка и развитие.
Практика показывает, что конкретные наработки на коленке, сделанные оптимизатором живут пока он работает на конкретном месте. Но стоит ему уйти с данной позиции, все это перестает жить. Хорошо, если это ведет только к увеличению работы конкретных сотрудников в отделе. Хуже когда производство уже заточено на данное приложение. Доходило до смешного, когда какое то корявое приложение, по 8-12 лет использовали и боялись трогать: не дай бог что-нибудь перестанет работать. А оно и переставало работать в нужный момент.
Но тут бизнес в первую очередь business first (сразу после safety first), IT это сервис, который помогает бизнесу зарабатывать деньги, так что давайте быстро делайте или вся компания без денег останется. И вот с помощью бубна, сверхурочных и т.д. с выходами в выходные у нас все работает.
Как Вы понимаете, как человек регулярно с этим сталкивающийся, имею естественное желание сократить количество выходов в выходные и праздники. За которые меня чаще всего и не платят как раз. И как в том анекдоте, хочу убивать такие наработки пока они маленькие.
А когда начинаешь объяснять, что в целом то если Ваше предложение правильное, то давайте делать по нашим правилам: анализ, документация, техническое задание, разработка, инструкции пользователя. Сразу вопрос: кто обучает пользователей? Кто поддерживает инструкции. И самое неприятное для желающих оптимизировать у нас есть очередь разработок, уже принятых в работу. Можем Вас поставить в очередь примерно через 9 -16 месяцев (серьезно). Очередь конечно обычно меньше, но всегда есть разработки вне очереди. Поэтому сразу говоришь максимальный срок.
Если будете делать сами, мы вам сможем оказывать консультационную поддержку, но только по нашим регламентам (все логично). В качестве инструментов будем использовать только те, по которым у нас есть штатные сотрудники и чьи должностные инструкции входит поддержка таких то инструментов.
Но оптимизаторы писать документацию не хотят вместе с ТЗ и инструкциями пользователей. Проводить семинары по обучению пользователей не хотят. Это все долго ведь, муторно и фи-фи. Вот же секси: power BI на базе пары табличек, работает супер. секси и все такое. Дайте доступы и сервак, чтоб все работало шустро.
И вот тут хотел бы отметить главное отличие российской компании в которой я работал от западной: в российской никакому оптимизатору не получится пропихнуть свою разработку мимо ИТ. Если ИТ сказало нет, то значит нет. А вот в иностранной есть разные способы, как пропихнуть. Через директоров, через свой личный бюджет или через низкую дисциплину.
Мне лично импонирует российский подход, так как если смотреть на дистанции в 5-10 лет он более эффективен. Долго принимают, долго согласовывают. Но коль уж согласовали, то будет работать и у всех во всех подразделениях одинаково. А в западной компании, где я работал, по данному вопросу зоопарк, с которым непонятно что делать.
Любой ИТ специалист прекрасно знает, что поддерживать одно приложение в рамках крупной компании дешевле и лучше чем штук 20 в разных инстанциях. Мое любимое выражение: лучше безобразно, но единообразно. Это дешевле и видна картина целиком и не надо все компилировать и сращивать.
5. Вот наше говнище. Это вам. Возьмите и распишитесь (ключевое).
Самое неприятное в такой ситуации, когда какой то оптимизатор (гораздо хуже когда это команда оптимизаторов) увольняется или переводится. На это завязаны бизнес процессы и надо поддерживать. Как результат, все “наработки” передают в ИТ. Как мы помним, чаще всего в такой ситуации, нет ни документации ни даже инструкций пользователей. А все сакральные знания оптимизатора находятся в его голове. При увольнении он там что - то напишет в hand overе, но это будет составлять в лучшем случае 10 процентов от необходимого. И что с этим счастьем делать непонятно.
Как мы помним, в ИТ проходят оптимизации и сокращения, люди и так завалены работой. А тут им дают еще кучу чужого говна. И это дополнительная работа чтоб привести в порядок.
Бывает что такие поделки живут еще 3-5-8 лет и их потом либо оптимизаторы другие оптимизаторы с оптимизируют, либо по регламентам переведут на общие рельсы.
Вывод
Условно говоря, когда оптимизатор приходит ко мне он не видит всей этой кухней, которая есть у нас. Более того, часто он даже не может понять о чем я говорю. Людям со стороны часто непонятно что говорит профессионал более высокого уровня. Забавно было, как в некоторых статьях меня пытались высмеять люди, вообще в ИТ слабо разбирающиеся. Условно говоря я им говорю про архитектуру, а они меня пытаются высмеять по поводу того, что я не знаю Phyton.
Когда ты не видишь всей кухни и не разбираешься в процессе, многие решения кажутся глупыми и бестолковыми. Если же тут уйти в сторону принятия решений высокопоставленными руководителями, то со стороны многие решения кажутся глупыми и бестолковыми. А по факту являются наиболее рациональными. Но не профессионалу они кажутся бестолковыми.
Хорошо, когда есть грамотный руководитель и плохо, когда левый человек, не разбираясь в процессах начинает руководить большими структурами. К примеру, плохо когда Оксана Пушкина девочка проводит закон о домашнем насилии принимает законы в которых не разбирается. По факту, сегодняшняя статья больше про внутреннюю кухню сложных процессов и как это выглядит со стороны для обывателя. Просто привел пример на базе собственного опыта. Но лучше перевести на то, как мы рассматриваем многие постановления или законы со стороны обывателей.
Специально для Anisiya: Вас разбанил, так как Вы много рассказывали про свою компетенцию. Будет интересно Ваше мнение.
Комментарии
Вы меня не правильно поняли. Обычно наоборот пытался вникать и думать как можно в существующей архитектуре реализовать.
Там уже ветвление описывать долго было. Тот же power bi меня пользователи убедили внедрять, когда были на распутье.
Бухгалтер нынче это кожаный мешок, задача которого правильно разнести проводки.
Если кожаный мешок учится, то это хороший бухгалтер, а если может проявить инициативу, тогда главный бухгалтер.
Но рядовой состав обычно так себе, и разобраться в их работе труда не составляет.
+
Сталкивался в области ремонта оборудования: процесс не описан, но автоматизирован. Еще и структуры "оптимизировали", аутсорсинг. В итоге - приписки и туфта. Руководство устраивает. Похоже на СССР, лозунги про одно, делают другое.
ИСО 55000 вам в помощь. Там про процессы есть.
А ещё хреново, когда «оптимизатор» предлагает запилить алгоритм MRP в BI, а ИТ не видит в этом ничего плохого. «Мудаки оба», — говорит в этот момент специалист по процессам.
Эта маленькая история в дополнение к вашей картине. Специалисты по процессам у вас пропущены. Они тоже не исправят всей ситуации, но выкидывание их из общей картины напоминает ежегодное мучительное изобретение велосипеда. Каждый раз заново.
У нас был еще зоопарк систем: отчетность в эксель, 1С, ЕРП самопальное от подрядчика и выгрузка в ЕРП заказчика.
И да, у Заказчика: нам надо импортное ЕРП для IPO. Обязательно чтобы ЕРП было импортное и красиво звучало. "Для привлечения инвесторов".
Ага, цирк с конями везде есть. И цели очень разные. Некоторым шашечки (айпио), некоторым ехать. Только ехать все рано будет надо (если нет цели банкротиться). А вот тут возникает вопрос архитектуры процессов, которая так-то поважнее архитектуры ИТ будет (с точки зрения постановки целей).
Под это ipo как раз sap внедряли. Oebs не влетел в России. Вот и навнедряли это щастье. Хотя российские аналоги для российского рынка заметно лучше.
До смешного: в сапе до сих пор нет нормального учёта спецодежды.
По спецодежде. Вроде как в EhP6 сделали
https://sapboard.ru/forum/viewtopic.php?p=455156
Там даже в обсуждении фигурирует карточка ОС.
То есть запилили на основных средствах
Я когда просил провести презентацию в паре контор, мне отказали.
Точно уже не помню детали, могу ошибиться, по моему обращался в ,Sap cis, молгу, ibs.
Все активно внедряют на 1с.
Детали в лень у коллег узнавать.
Поинтересовался у коллег. Есть примеры внедрений даже. Есть отдельное решение у САП называется EHSM, в нем тоже есть этот функционал.
Насчет использования «чужеродных» объектов, в ряде случаев это нормально :) и даже правильно. Из интересных примеров, в одной компании растениеводство планируется и управляется на объектах ТОРО. Поле — техническое место. Вроде довольны :)
Все таки по моему я сап просил провести презентацию. И мне отказали.
То что какое то решение есть, я в курсе. Но до решения как в 1С далеко.
Оёбс всё. Это даже немного печально. С другой стороны есть шанс у наших ЕРП, особенно в условиях импортозамещения. Только вот все равно сложно соревноваться с платформами которые всем миром разрабатываются. Идя малого и среднего бизнеса — без вопросов, а для крупного…
И слава богу. Я успел год на проекте Ростелеком поработать, после него и сап гибкое приложение с интуитивно понятным интерфейсом.
Видели бы вы, что SAPеры во время внедрения с бизнесом делают... хотя, может и видели, но смотрели с другой стороны баррикады
С обоих сторон смотрел.
Видел. Скорее с другой, да :)
Как пример: РЖД учёт вагонов на sap bi решили запилить. По моему отказались потом.
Справедливости ради готового решения для РЖД по учету вагонов не существует. Так что пилить все равно бы пришлось. Другое дело, что за основу лучше взять транзакционную, а не аналитическую систему, если уж это действительно «учёт».
Да ровно в этом косяк был, что транзакционные задачи на хранилище пытались реализовать.
Это фундаментальная опа нашего времени. По факту специальность бизнес-архитектор (или BIM или как только не называют) только складывается, нет общих требований к образованию, люди то филологи, то инженеры-механики (как я) и повсеместно встречаются пробелы в понимании самых базовых вещей и принципов. Причём привлечение дорогущего бизнес-консалтинга зачастую только усугубляет.
Насчёт дорогущего консалтинга вообще могу часами матерится.
Если говорить про меня, то как то в 2006 году меня на 2 дня за 120 тр продали. Когда ценник увидел, сам офигел
Хороший ценник для 2006 года :)
Да и сейчас не плохой :). Архитектор в районе 34 на максимуме встречал, если не ошибаюсь. Но это при калькуляции проекта. А там надо было конкретную работу сделать. Отдельный контракт.
Если от грандов брать САП архитекторов крутого грейда, то до 100 тыщ за
ночьдень доходитБерете и делаете песочницу - полный клон системы. Тем более вам бюджеты выделили. Пусть играются, а там видно будет, выйдет из этого что-то или нет. А если вы просто всех посылаете, то все правильно они вам говорят:
Ещё один не понял о чем речь.
Вы сами то поняли? А то мне кажется ЧСВ вам немного мешает.
Песочница, разработка, тестирование и продакшн. До четырех систем в ландшафте было на моей практике.
Перенос из разработки в продуктивную систему только с тщательным оформлением всей документации. Многие специалисты предпочитали в разработке жить.
Из надо обслуживать. И это все денег стоит. Ровно то что я написал.
Железо и софт для компьютеров. Пункты 1,3,4,5 из статьи.
Да, тестирование и переход в продакш - это будет сложно. Но если вы правы и человек пришел к вам с какой-то ерундой, то дальше песочницы дело не уйдет, в ней все и сдохнет. Но от этого вам одни плюшки: у вас сформируется репутация прогрессивного специалиста, радеющего за развитие компании. А не то, что о вас все думают сейчас. Кроме того, песочница сетапится один раз, всех остальных можно в нее же отправлять, соответственно имея бонусом экономию кучи времени без репутационных издержек.
Если же из идеи что-то вырастет, то весь этот геморрой того стоит. Что касается денег - вам же бюджет выделили.
Проблема в том, что это не ваш уровень (IT одела) это уровень вашего руководства, которое учитывает не только шкурный интерес отдела IT (в узких рамках которого понятно, что не нужен весь этот гемор с неизвестными последствиями), но и другие интересы компании.
Для штатных средств есть песочницы . Тут я описал больше когда пользователю надо нештатными средствами сделать или нашими руками.
И да, я уже больше года просто блогер.
Вот поддержу вас! Я как атйтишник насмотрелся на своих коллег, которые посылают всех подряд куда угодно, лишь бы не делать свою работу. При этом дальше своего отдела (считай, носа) видеть не хотят. Не понимают, что в ряде случаев выгода бизнесу от хотелки может на порядки превышать стоимость автоматизации и всего того геморроя с железками, о котором пишет автор. У меня в команде такие не задерживаются. Поддержу и песочницы - очень помогают проверять гипотезы и принимать решения по хотелке самими же хотетелями. И волоки сыты, и овцы целы.
Жму руку!
Давайте начнем сначала: для любой хотелки требуется экономическое обоснование. Это для начала. По моему опыту в этот момент сливается 60 оптимизаторов.
Часто менеджеры любят сообщать, что это де даст экономический эффект ив столько то миллионов рублей
Когда после этого спрашиваешь а форму заполните? Чтоб раз такой эффект, то вам бюджет на эту сумму сократят? И тут сливается 95% оптимизаторов.
Ещё такой момент: оптимизация может быть в сокращении рабочего времени. Это вообще красота. Никто не соглашается сокращать штатную единицу.
Можно отпрлзти: улучшение безопасности производства.
Дальше: есть сумма оптимизации, есть приоритет проставленный руководителем производства. ИТ работает по данному списку. Если у вас это не так, то это ваша проблема а не моя и не имеет отношения к статье.
Ни разу не видел, чтобы даже после внедрения 1С сокращалась бухгалтерия. Но добавлялись ребята по обслуживанию компьютеров и программ.
нет, он сделал пример на небольшую систему управления предприятием, небольшим, и беспредельными ресурсами it.
такое в начале 2000х было популярно - сделать снимок системы, воссоздать отдельно, на резервном узле?, поиграться - если взлетело - актуализируешь на том узле информацию, изменившуюся с момента разделения снимков и переключаешься на резервный узел. старый узел идёт в бэкапе, вдруг всё упадёт от новой, потом выступает песочницей для следующих хотелок. это в своё время ibm в части своих материалов по полуоси и имхо 360системам публиковала, как хорошую практику на небольших системах.
Да не проблема снимок на тесте развернуть. На разработке обычно прав не хватает у разработчиков. Или данные перс затирать.
да, когда подняли флаг "ПД, 152" - заТБМись, тут всё и заТБМлось. полные сведения и эрзацы совершенно по маштабам не сопоставимы.
Статья хорошая, правильная.
Но извините, я то же наверное не понял, о чём речь.
Starcon предлагает сделать копию системы - и пусть играются.
Пусть отвяжутся в конце концов.
По мне, так сделать гораздо более рационально, чем каждому втолковывать какие-то понятные только вам истины.
Потом на этом этапе большинство оптимизаторов "сольётся".
А с теми, кто пройдёт такой естественный отбор, покажет какой-то результат, можно наверное и повозиться.
Может всё-таки есть что-то дельное в предложениях такого упрямого оптимизатора.
Как боец по "другую сторону окопа" хочу добавить к совершенно правильно изложенным в этой статье истинам, что:
1) Такой-вот оптимизатор в системе - это дополнительный аудит.
Безопасности, например.
2) В моём случае выяснилось, что администратор довёл у нас систему до такого состояния, что стал незаменимым.
Это была примерно та же оптимизация, так ругаемая в статье, только на уровне системного администратора.
Выяснилось, что любое обновление просто убьёт систему без права на восстановление.
Ещё раз отмечу: в штатных инструментах песочницу без проблем.
Какие бюджеты? На закупку? На увеличение датацентра вдвое? И на удвоение команды ИТ?
Полный клон требует и места, и процессоров, и лицензий, и обслуживания - почти столько же, сколько основная система.
И потом: таких "оптимизаторов" обычно несколько. А когда в одну программу лезут сразу несколько команд - бардак неминуем.
С лицензией справедливости ради часто нет проблем. Они считаются по продуктивным.
Согласен, погорячился.
большинство местных и не поймут о чем вы :)
вон уже пошли рекомендации одна другой краше
Ага. Как минимум двое уже отметились
Считается что если человек действительно профи, он сможет кратко и доходчиво объяснить проблему не профессионалу. Слабо одной фразой сформулировать, о чем он?
В любое организационной единице должны быть две противоположных по вектору силы: развития и стабилизации (или инерции). Управляя этими силами, руководитель обеспечивает выживание и процветание компании в этом сложном мире. Проблема больших контор в том, что сила инерции в них слишком велика, и это нормально. Если сравнивать компанию с кораблем, то маленькая компания - это лодка, которая очень маневренна, но не устойчива и недостаточно быстроходна. А большая компания - это как большой теплоход. Если начать ему резко штурвал перекладывать, можно и потопить. Цена ошибки становится неприемлемой. Проблема таких контор - затухание импульса на развитие и изменение. Статья - взгляд с одной стороны.
Статья про сложные процессы и взгляд на а низ со стороны обывателем.
профи всегда сможет доходчиво объяснить - НО не обязан
тем более теоретикам которые и близко не понимают как там оно на самом деле в организационной единице и тем более в части касающейся ИТ ибо особенностей хватает
но вообще да могу сформулировать - автор о том что в ИТ творится ЖОПА но набеганием кучи умных и эффективных мальчиков с горящими глазами знающих умные слова - ее не решить
более того когда мальчик поварится в этой каше - постепенно приходит понимание что это все "жжжж" неспроста - но тогда он уже перестает быть мальчиком
Если мальчик - "бухгалтер", который полез в СУБД, понятно что его надо гнать ссаными тряпками. А если это такой же IT-шник, пусть без опыта но с потенциалом и с горящими глазами, ему надо дать возможность.
Я в IT 25 лет, последние лет 15 руковожу вот такими вот "профи" , причем в разных компаниях, включая международные. Как правило очень малый процент таких вот профи - реально профи. Обычно они просто думают, что они профи. Поэтому когда очередной профи встает в позу и есть такая возможность, я охотно меняю их 1:1 на талантливых мальчиков с высшим профильным образованием и горящими глазами.
Страницы