Проблемы понимания профессионала и обывателя

Аватар пользователя brekotin

Сейчас в интернете рассказывают про преимущества автоматизации. Типа мол снижает нагрузку на человека, делает Ваш бизнес более гибким, подкованным. Можете выявлять слабые места, точки роста, оптимизировать процессы. На базе накопленных данных делать бюджетирование, прогнозирование и оптимизировать склад и т.д. и т..п. Не отрицаю. Но достаточно часто такая автоматизация не ведет к оптимизации а только ухудшает ситуацию. Я знаком с вопросом не понаслышке и хотел бы рассказать о проблемах. Благо отвечал много времени за приложения на предприятии.

Вот представьте ситуацию: есть конкретный отдел, который вручную собирает статистику  делает бюджетирование. Из нескольких систем выгружают данные, потом эти данные объединяет. На этапе объединения надо где то данные сгруппировать, где то дополнить, где - то почистить. Много муторной работы. И вот появляется в таком отделе человек, который не только слышал что автоматизация это круто, но и вполне умеет работать с базами данных, настраивает экстракторы, писать скрипты и на всем этом хозяйстве строить отчеты. Навыки, на самом деле, не сильно распространенные, потому что чаще всего конкретно желающий предполагает что он может все это сделать. 

И вот ему для всего этого счастья требуется база данных и доступы к нужным системам. Приходит он к таком сатрапу вроде меня и говорит: дайте базу данных и доступы. Буду все делать в свободное время, но это поможет сократить 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: Вас разбанил, так как Вы много рассказывали про свою компетенцию. Будет интересно Ваше мнение. 

Авторство: 
Авторская работа / переводика

Комментарии

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Он невменяем.  Его на год забанил. Надоел он мне. 

Аватар пользователя Капустин Степан

занимался задачами которое ставит руководство стоимостью в десятки миллионов вместо левых копеечных задач

Ну тогда к чему тут вселенский плач, жалобы и стоны?

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Давайте с другой стороны: в ИТ консалтинге в Москве работают в основном приезжие. Потому что надо летать в командировки и работать. Москвичи обычно не соглашаются. Это факт, можете поинтересоваться. Многие (как и я) уходят работать на предприятие, потому что устают работать в таком формате. На предприятии работать значительно проще. У меня в один год было 286 дней в командировке! При этом считалось вообще ненормальным в командировке уйти в 18:00 с работы. Это чуть ли не к саботажу приравнивалось. 21:00 - 23:00 и так каждый день. В выходные да, действительно можно было уйти в 18:00, но при условии что нет горячей работы.

Работая непосредственно на предприятии я один раз на проекте посчитал и получилось что у меня в месяц было более 340 рабочих часов. При рабочей недели в 40 часов и никто мне не оплачивал переработки. Почти каждый день уходил в 23 часа домой. Было и в 2 часа ночи. А с утра к 9:00 должен быть на рабочем месте, поглаженный и работоспособный. В том числе и в выходные. И да, еще дюлей за этот проект получил а не премию и сверхурочные. Руководство не могло оценить объём работы. Собственно, уход в 23:00 объяснялся просто - можно было добраться до дому, поспать 7 часов, отвести ребенка с утра в садик и как раз успеть в теплый светлый офис к 9:00. 

Лучше втоптать в грязь этих "оптимизаторов" как можно быстрее: нам хорошо, а их проблемы... Проблемы индейцев шерифа не волнуют. (с)

вот ровно один "специалист" пытается в комментариях втоптать ИТ в грязь у меня в статье в комментариях, пытаясь свалить некомпетентность свою или своих Ит на все ИТ в целом. 

 

Аватар пользователя Капустин Степан

При этом считалось вообще ненормальным в командировке уйти в 18:00 с работы. Это чуть ли не к саботажу приравнивалось. 21:00 - 23:00 и так каждый день. В выходные да, действительно можно было уйти в 18:00, но при условии что нет горячей работы.

Работал я в командировке... Вот ровно в таком режиме: к 8.00 чтобы был, уйти раньше 22-23 часов - как преступление. И в субботу и в воскресенье, если на предприятие пускали /чаще всего предприятия были непрерывного цикла, так что у них суббота-воскресенье-праздник - циферка на календарике другого цвета, не более/. И не потому, что вот так было надо - у меня дом, семья, жена, дети, хрена ли мне в какой дыре отираться, питаться в разных тошниловках или всухомятку? Быстрее все сделать и домой. Заплатят за сверхурочку - хорошо, нет - да и хрен бы с ними, запишу себе, с чем пришлось возиться, да в следующий раз учту это при разработке имитатора, чтобы больше дома поработать, а не тут...

пытаясь свалить некомпетентность свою или своих Ит на все ИТ в целом

Вот именно об этом я и говорю: втоптать, пока большое начальство не узнало да показатели не поменяло...

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

надоел мне этот поток сознания, из дальнейшей дискуссии выхожу. 

Аватар пользователя Капустин Степан

Счастливого пути.

Что надо - я уже узнал.

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые.

Вот на этой фразе Вы и спалились. smile3.gif

Её могли сказать финансисты-экономисты, директор, акционеры, но никогда не скажет отдел ИТ. 

Аватар пользователя Капустин Степан

Вы ба статейку для начала прочитали, что ли...

Но если давать базы данных всем желающим, очень быстро начинаешь налипать на новые сервера и новые лицензии. Отделов много, подразделений много, оптимизаторов еще больше и всем давай базы данных. Железо тоже стоит недешево под все это счастье. А еще это счастье надо бэкапировать и обслуживать. А бюджет на железо и лицензии не резиновый, и руководство и так долбит постоянно, что надо бы сократить расходы а не увеличить. У меня свои KPI у вас свои.

Это не я писал...

Хотя наши говорят точно так же.

Аватар пользователя Советчик
Советчик(5 лет 12 месяцев)

У ИТ службы тоже есть свой бюджет. И есть куда его потратить помимо покупки новых серверов и лицензий.

Комментарий администрации:  
*** Уличен в антисоветской лжи и набросах - https://aftershock.news/?q=comment/7625227#comment-7625227 ***
Аватар пользователя Барсук
Барсук(3 года 1 месяц)

У ИТ службы тоже есть свой бюджет. И есть куда его потратить помимо покупки новых серверов и лицензий.

Вы на пару с Капустиным интересные люди .

Бюджет составляется/планируется под конкретные будущие задачи + расходы на "текучку".

Не исключаю , конечно, что на ваших предприятиях это по другому и ваш годовой бюджет планируется примерно так : 

- 12 млн - расходы на текучку 

- 57 млн - внедрение SAP 

- 48 млн - вдруг захочется странного.

Если ставится новая задача, то под неё выделяются дополнительные ресурсы. 

И  руководитель ИТ никогда не будет как Баба-Яга - "Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые."

Отдел ИТ может объяснить "хотельщикам" цену вопроса.

 "ЗА" или "ПРОТИВ"  отдел ИТ может ратовать только с точки зрения целесообразности внедрения/разработки новинок в плане общей концепции развития структуры ИТ предприятия.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

И  руководитель ИТ никогда не будет как Баба-​Яга - "Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые."

вот. Приходит оптимизитор, ему надо "просто сервер" без согласования своей разработки на управляющем комитете. Вот прям здесь и сейчас. 

- 12 млн - расходы на текучку 

бывали реальные ситуации, когда текучка съедалась на 80% в первые месяцы (ждали с прошлого года) и потом надо было экономить. Опять же, сервера в дата центр заказывались за 9 месяцев. И новые мощности вот просто взять не получится. Их тупо нет. И даже если клиент находит бюджет на железо, его просто взять негде. Ждать 9 месяцев. А по факту легко и 12-14. Сервера в дата центр должны быть в нужной спецификации и ближайшем магазине не купишь. Правда я сейчас рассказываю не про Москву а РКС. 

Расходы на текучку могут быть в объёме одной четвертой от заявок. 

У меня менеджер вел проект, так сервер ФСБ просто арестовало на 9 месяцев. На растаможке посчитали что подпадает под какой то закон и 9 месяцев (крипто чего то там) не могли документы все подготовить. 

 "ЗА" или "ПРОТИВ"  отдел ИТ может ратовать
только с точки зрения целесообразности
внедрения/разработки новинок в плане
общей концепции развития структуры ИТ
предприятия.

именно. 

Ситуация приближенная к реальной : вводят санкции против глубоководного шельфа. наши платформы хоть и мелководные, взяли и по ошибке внесли в список. Соответственно куча софта потенциально не рабочее. Использовать можно, а обновлять нельзя. Так как там одно на другое накручивается и софт надо обновлять, идет срочная задача: выделить сервера под "песочницу" геологам для нового софта. 4 блейда а лучше 6. Сколько из указанных Вами 12 млн на это уйдет? Правильно, минимум 17. И бюджет новый никто не даст. А если не выделишь вот прям здесь и сейчас - тут не оптимизаторы а высшее руководство с главном съест. Да есть бюджет и на форс мажор, но и не один форс мажор в жизни случается. Да и сервера опять же, нельзя взять и купить. Надо ждать и думать об этом постоянно. 

Аватар пользователя Капустин Степан

Приходит оптимизитор, ему надо "просто сервер"

Не бывает так, чтобы оптимизатор появился на ровном месте. Точнее, бывает ровно в одном случае - есть сотрудник, которому решительно нечем заняться. Видел таких: у них идеи фонтанами брызжут... Делать они сами ничего не могут, что спасает. Если хоть что-то могут - тогда все еще хуже. Таких немного и они очень быстро вычисляются из общей массы: у них идеи часто из разных областей. У правильных - из одной области: он работает на одной работе, не на трех. Не может, скажем, сварщик фонтанировать идеями из области дизайна рекламного плаката, обработки углепластика и работы ходовой охотничьего вездехода директора. Одна-две идеи не из своей области у рационализатора появиться может, но никак не фонтаны.

Итак, появился нормальный оптимизатор. Это значит ровно одно - где-то появилась проблема, узкое место. Оптимизатор - сварщик, он в этих ваших процессах, бюджетах ни ухом, ни рылом. Оторвите свою ж..у от кресла, отставьте свой кофий и пойдите, выясните, в чем там дело. Там дело, чаще всего, выеденного яйца не стоит, если прихватить проблему на старте.

В общем, как с больным зубом: если побежал к врачу при первом неудобстве во рту - полчасика  в кабинетике и счастливый бежишь домой; а отнесся "да ладно, я его водкой..." - операция и год-полтора ходишь на лечения и рентгены, а потом еще и к косметологу - шрамы от операций на морде маскировать.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Вы не замечаете, что в одном абзаце уже сами себе противоречите?

Не бывает так, чтобы оптимизатор появился на ровном месте.

и

бывает ровно в одном случае - есть сотрудник, которому решительно нечем заняться.

у меня оптимизаторы появлялись потому что я работу не работаю (хотя я в общем то и указал "оптимизацию от девушки" и почему не дал сервер для консолидации объёма информации). А вот у Вас все пучком. Но это другое. Я понял. Все вокруг мудаки, один Вы д'Артаньян. КОНЕЧНО. 

Аватар пользователя Капустин Степан

Надо обратить внимание на что удобно.

А что сотрудников, которым решительно нечем заняться - единицы, вы, конечно, не заметили. Правильно, это удобнее: оптимизатор - значит, ему нечем заняться, значит пусть идет лесом. Я тут лучше кофеек под кондейчиком...

Я еще раз повторю: "оптимизация от девушки" - это решение проблемы, поставленной перед конкретным работником этим самым работником. Потому как его все просто бросили - задача поставлена, вот и решай. Вот они, эти работники /девочки, мальчики, дедки, бабки - не суть важно/, решают задачу как могут. Они, внезапно, не знают языков программирования, они не в курсе за архитектуру баз данных... Они что-то знают про Excel...

Не хотели решать проблему девушки - получите и распишитесь: вот вам куча немасштабируемых Excel-таблиц, живите с этим и стоните.

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Я еще раз повторю: "оптимизация от девушки" - это решение проблемы, поставленной перед конкретным работником этим самым работником. Потому как его все просто бросили - задача поставлена, вот и решай. Вот они, эти работники /девочки, мальчики, дедки, бабки - не суть важно/, решают задачу как могут. Они, внезапно, не знают языков программирования, они не в курсе за архитектуру баз данных... Они что-​то знают про Excel...

Давайте ближе к "природе". Не оптимизаторы, а энтузиасты - люди с повышенным содержанием железа в организме ( по народному - жило в ж...). 

Такой энтузиаст берется за хобот и приводится к его ( энтузиаста ) начальнику. При нем он излагает свои идеи , начальник энтузиаста резюмирует - "Да годная идея , нам в наших бизнес/производственных процессах было бы полезно". После этого начальник энтузиаста дает ему задание на подробное описание планируемого процесса для последующей постановки задачи отделу ИТ. Потом , а иногда и никогда smile1.gif , отдел ИТ делает примерную оценку стоимости хотелок и получает ВЫХЛОП=Кайф от хотелок/Цена доработок.

И с этим транспорантом и с песнями вся компания идет к финансовому директору - получать люлей согласование доп.расходов.

Примерно таким образом происходит противоестественный отбор энтузиастов.

 

Понятно что встречаются жесткие варианты типа дочка учредителя, которую посадили куда-нить в финансовый/юридический отдел.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Это правильный подход. Тут могут сделать следующим образом: берут на контракт (да и в целом в штат, но это сложнее) такого умника, и он чего то хреначит втихушку. 

Так как за 20 лет было куча реорганизаций и увольнений, то остаются дырочки в системе безопасности. К примеру, дали одним энтузиастам сервер. Да так хорошо у них получилось что им целый отдел сделали (4-е человек). Смогли всем сэкономить компании большую. кучу денег. .Все счастливы. Но они ведь не остановились и за 7 лет столько нахерачили, что просто писец. Куча процессов, документации ноль. Все держится в голове исключительно двух человек (скорее полтора). Для понимания, под их нагрузку уже лезвие брали. 

Часто политики не соблюдаются, отслеживание в части доступов в соотвентствии со штатным расписанием выполняется с регулярными косяками. К безопасности тоже куча вопросов. 

И вот приходит следующий оптимизиатор, ему уже сервер не дают. Но зато ему дают втихушку место на сервере предыдущие оптимизаторы. 4-е года и опять куча процессов компании завязано и на эти поделки. Это все кстати до меня было. 

ПРи чем, им уже нужна служба поддержки, обучать пользователей. Они сами не рады уже всему этому счастью. Хотят передать в ИТ. А как передать? Мы принимаем с документацией и инструкциями. Переписывать или разбираться тоже возможностей нет. Клинч. И они не рады и на аудитах все двойки получают. Потому что жопа. Но продолжают хреначить новые фичи. 

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Переписывать или разбираться тоже возможностей нет. Клинч. И они не рады и на аудитах все двойки получают. Потому что жопа. Но продолжают хреначить новые фичи. 

И наступает момент когда "бизнесу" приходит понимание что лучше сейчас заплатить большие деньги чем потом влететь на огромные.

После чего нанимается фирма работающая на относительно стандартных распространенных инструментах, которая переписывает все с нуля.

Аватар пользователя Советчик
Советчик(5 лет 12 месяцев)

Ну на самом деле реструктуризация процессов связанная с ростом масштабов фирмы - совершенно обычное дело во всех областях. ИТ здесь не исключение. То что было нормально для шараш-монтаж уже не прокатит для сети таких же шараш-монтажей. Просто в силу ограниченной масштабируемости используемых решений. И платить за новое придется в любом случае.

Комментарий администрации:  
*** Уличен в антисоветской лжи и набросах - https://aftershock.news/?q=comment/7625227#comment-7625227 ***
Скрытый комментарий Капустин Степан (без обсуждения)
Аватар пользователя Капустин Степан

Но они ведь не остановились и за 7 лет столько нахерачили, что просто писец. Куча процессов, документации ноль.

Вот именно об этом и речь: а вы эти семь лет что делали? Кто вам не давал взять проект в свои мозолистые руки? Сами же пишете: сэкономили кучу денег. Значит, делали что-то реально нужное. Цельных семь лет. Сами. Как могут и как умеют.

И вот мы видим стон и жалобы...

Аватар пользователя Капустин Степан

Давайте ближе к "природе". Не оптимизаторы, а энтузиасты - люди с повышенным содержанием железа в организме ( по народному - жило в ж...).

Давайте.

Оптимизатор из разряда "шило в ж..е" - это именно о них я и написал:

Точнее, бывает ровно в одном случае - есть сотрудник, которому решительно нечем заняться. Видел таких: у них идеи фонтанами брызжут... Делать они сами ничего не могут, что спасает. Если хоть что-то могут - тогда все еще хуже. Таких немного и они очень быстро вычисляются из общей массы: у них идеи часто из разных областей.

За всю свою многолетнюю практику /более четверти века/ такого видел ровно одного. Причем как раз наихудшую ипостась - он что-то умел. И, что еще хуже, кое-что знал.

Его бесполезно было брать за хобот - язык у него подвешен был как надо, обрывки знаний позволяли оформить словесный поток и даже был способен примерно распланировать процесс. К оценке стоимости нормального проекта вполне мог приложить собственную оценку, в разы ниже. Т.е. получалось, что вроде бы решает реальную задачу и куда лучше асушников и итшников вместе взятых /я с ним столкнулся как раз на совместной задаче: взять данные с приборов, закопить их в базе данных, нескольким потребителям дать возможность смотреть данные в реальном времени, печать отчетов/. Вот в данном случае он предложил не делать сбор данных с приборов - производитель приборов предоставляет свою программу сбора данных /однопользовательскую - показать возможности/, в базу данных ничего не писать /в той программе есть своя, своего закрытого формата/, не делать отчеты /в той программе есть свои/... Все что надо было сделать - предоставить компьютеры всем потребителям, сеть между ними, и TeamViewer. Это все - копейки, по сравнению с нормальным вариантом. Правда, на второй день эксплуатации кто-то из операторов /кому надо было только смотреть данные/ нажал кнопочку и стер все архивы и шаблоны отчетов: программа однопользовательская, потому там никаких  защитных функций не было как класса... И сутки работы огромного цеха пошли в металлолом - ну кто ж допустит к использованию ответственные детали, которые неизвестно на каких режимах обрабатывались.

Гораздо чаще встречались правильные - которые только предлагали идеи по улучшению, облегчению собственного труда. Только предлагали. Своему начальству, нам, асушникам... А мы вместе уже готовили обоснование, ТЗ с разделением функций... Часто - помогали местным готовить документы для введения изменений в техпроцесс. И вот со всем пакетом уже шли к большому начальству...

Обычно никаких свистелок и перделок у нас не предлагают /или такие свистелки отсеиваются на уровне "начальник рационализатора"/ - до нас такое не доходит. Все, что предлагается, так или иначе облегчает труд или уменьшает вредный человеческий фактор: люди - самое слабое звено, они жутко ленивы - если есть возможность сделать вид выполненности работы не выполняя ее, они обязательно это сделают. Максимум - вводя улучшение тут, ухудшали где-то там. Это нормально - скажем, сварщик не обязан знать, как функционирует система управления, как формируются те или иные данные, как они передаются... Или улучшение требовало огромных усилий, не соответствующих ожидаемому улучшению.

Даже более того. У нас ежегодно проводятся конкурсы рационализаторов. Вот как раз для нормальных. Чтобы выявлять проблемы на ранних стадиях, не доводя до реальных головняков.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

А что не так? Естественно сервера денег стоят. СУБД лицензии оракла и мискрософта inHouse стоят дорого. При этом, за бюджетом на лицензии и железо руководство постоянно следит и требует снижения. Суммы не буду говорить (коммерческая информация да и не помню уже), но они очень серьезные были. И всем направо и налево выдавать сервера с СУБД - нет. Они денег стоят. 

Да, ИТ руководитель у которого бюджет на сервера и лицензии об этом говорит в первую очередь. Нужен сервер? где деньги брать под него. А если под сложные задачи в геологии требуется мощный вычислительный кластер, то там только сервера с ПО выйдут в очень круглую сумму. 

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

А что не так? Естественно сервера денег стоят. СУБД лицензии оракла и мискрософта inHouse стоят дорого. При этом, за бюджетом на лицензии и железо руководство постоянно следит и требует снижения

 

Следите за руками контекстом. Исходный посыл.

С помощью предложенной инженером-​конструктором программы /из конструкторского отдела на минуточку/ - время подбора сокращается до нескольких минут. Эту программу можно еще ускорить в разы, добавить полезного функционала: все прошлые разработки прописать - та-​дам - в базу данных. НО! Отдел ИТ резко против: сервера же денег стоют, СУБД тоже недешевые.

 Типа пчелы против меда. Против никак не начальник ИТ, а "руководство которое постоянно следит и требует снижения"

Прям вижу такую картину маслом, касторовым, заходит директор в отдел ИТ:

- Слушай,Вася, бухгалтерия плачется что все медленно работает. Счет-фактуры по 15 минут формируются , квартальный отчет по 4 часа делается. Оборот растет и прибыль тоже, может прикупим пару-тройку сервачков? Базу на SQL пересадим, часть пользователей на терминал?

Вася в ответ:

- Да идут они лесом". Сервера же денег стоют, СУБД тоже недешевые. Деды ваще на dbf-ах работали и эти обойдутся.

 

Мне всего два раза встречались начальники ИТ, которые были "резко против" - один раз в кунсткамере Петра Великого, второй раз в музее мадам Тюссо , начальник ИТ  стоял как раз между Дракулой и Мусолини.

Повторюсь единственная реальная причина  "резко против" - это зоопарк систем.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Там я еще сразу не заметил, у него в профиле написано что он программист. Но по его же утверждению, не в ИТ. Понятно что бардак на Уралвагонзаводе. 

Слушай,Вася, бухгалтерия плачется что все медленно работает. Счет-​фактуры по 15 минут формируются , квартальный отчет по 4 часа делается. Оборот растет и прибыль тоже, может прикупим пару-​тройку сервачков? Базу на SQL пересадим, часть пользователей на терминал?

на пресловутом OEBS на внедрении тестировал зарплатный квиток. Понимаю, что время линейно растет от кол-ва квитков. Протестил, четко 55 секунд на кол-во квитков. Внедряем, внимание на Сибирьтелекоме. 30+ тысяч сотрудников. То есть, понимаю что время формирования квитков на всех сотрудников поставит колом сервер (19 дней только квитки). 

Говорю программисту: у тебя руки из жопы надо переписать. Сначала выгружаешь агрегированные данные и по ним уже потом формируешь зарплатные листки. Самое забавное, что ни программист меня не понял, ни руководитель проектной группы. Могу ошибаться, но по-моему были из Открытых технологий. Типа одна из ведущих консалтинговых компаний России. Коры. А могли бы сервера прикупить.

Коллега у меня рассказывал: устроился архитектором в швейцарский аукционный дом какой то. В самом начале ему устроили экскурсию во Францию (разработчики в России и Франции). Ок, слетал, посмотрел на дата центр где ему показывали сервера за туеву хучу баксов или евро.

Потом он переписал одну (!!!) функцию, и нагрузка в пике упала примерно в три раза. То есть, по сути стали не нужны больше половины серверов. 

Бывает. 

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Сначала выгружаешь агрегированные данные и по ним уже потом формируешь зарплатные листки. Самое забавное, что ни программист меня не понял, ни руководитель проектной группы.

Гыыы.

Во времена когда продукция компании M$ считалась бесплатной и в моду вошли самописки, довелось переписывать зарплату для одной конторки, человек на тысячу.

Перевели с dbf на Interbase. Отдали свое творчество на тестирование у бухию. Они попроверяли - вроде все что надо есть, тока ЗП не считается.

Приходим выяснять - оказывается после нажатия кнопки "Расчет" нет, как обычно, "часиков" на полчаса. Расчет шел менее 3 сек.

Добавили окошко "Расчет окончен". smile1.gif

Скрытый комментарий Капустин Степан (без обсуждения)
Аватар пользователя Капустин Степан

Там я еще сразу не заметил, у него в профиле написано что он программист. Но по его же утверждению, не в ИТ. Понятно что бардак на Уралвагонзаводе.

Вы представляете, программисты нужны не только в ИТ. В жизни есть не только базы данных и чатики. Вы даже представить себе не можете, сколько программ крутится "на земле" в производстве. И сколько тут самых разных программистов... Есть даже программисты в технологическом отделе: они пишут технологические программы для станков.

Аватар пользователя rst0
rst0(12 лет 4 месяца)

так еще и кого то откатов лишил)

Аватар пользователя Капустин Степан

Повторюсь единственная реальная причина  "резко против" - это зоопарк систем.

Значит, причина нереальная. Ибо зоопарк систем лечится элементарно просто - тетеньку-разработчицу похвалить, программу ее стереть, взять у нее алгоритм /он не сложный - лист А4 весьма немелким почерком/ и поручить своим программистам сделать как надо. Даже за алгоритм платить не надо - он не тетенькой придуман, он стандартный.

Но по факту мы имеем: начальник ИТ против. Просто против. Даже в той ее версии, что была представлена на конференции и никаких серверов не требует.

Аватар пользователя rst0
rst0(12 лет 4 месяца)

у вас залежи слешей, что девать некуда и вы их случайным образом по тексту раскидываете? читать тяжело

 

Аватар пользователя Serj800
Serj800(11 лет 1 месяц)

Я на своём веку повидал тоже всякого, и зоопарк, и единообразного разнообразия. На глубине от 10 лет, всё обычно превращается в хаос.  Если нет системы норм контроля. Такой я видел только на режимных предприятиях, связанных с военными. Во всяких федеральных агентствах и ведомствах процветает зоопарк и неразбериха. Потому как меняются руководители, меняются исполнители, уходят ответственные, зарплаты не очень высокие, тендеры проводятся и т д.

Также повидал сделанные на коленке средства малой автоматизации на базе excel или access.  На базе таких штук работали отделы, а то и целые предприятия. В какой-то момент они начинали накрываться медным тазом, из-за накопленных ошибок, которые "разработчики" в силу отсутствия знания, или времени не могли исправить или развить дальше. Приходил я, который всё может, и вдыхал в это поделие второе дыхание. Переводя, например, на клиент серверную архитектуру. сервером становилась какая-нибудь взрослая СУБД, а клиентом так и оставался карманный access. И всё могло работать дальше и приносить прибыль конторе. 

Сейчас я работаю в большом отечественном холдинге, чисто sql dev. Вот казалось бы всё хорошо аджайл, спринты, тфс, но.. Начиналось всё хорошо, а вот сейчас руководство "оптимизировано" штатную структуру. И сократило персонал по минимуму. Порезали аналитиков, тестировщиков, разработчиков не трогали у нас и так недобор и текучка. Даже должность тимлида упразднили.

В итоге теперь все задачи на разработку, не проходят проработку аналитиками, которые переведут мыслеформы заказчика в четкое ТЗ, напрямую к разработчикам. Причем много супер срочно, с приоритетом 0, наличие в разработке задача приоритетом 0, это не нормально, а наличие одновременно нескольких задач, на одних и тех же людей с таким приоритетом, это ненормально в степени кол-ва таких задач. Зачастую это напоминает бег по кругу, поскольку бешенный принтер печатает эти бесконечные доработки, которые порой противоречат тому что было сделано раньшеи опять нужно время, чтобы согласовать, что делать в этом случае.

Раньше все эти доработки, которые шли в реализацию попадали в ТЗ, то есть все укладывалось в изначальное тз, актуализируя его на текущее состояние и новый человек придя мог поднять документ изучить его, открыв параллельно реализацию понять что к чему и почему. Сейчас же такой возможности нет.  И я прекрасно понимаю, что если уволюсь я, что человек который придет на мое место ничего толком не поймёт и будет мастерить костыли, чтобы работало.

Аватар пользователя LLORD
LLORD(9 лет 1 месяц)

Когда речь о больших системных процессах, то, безусловно, никого туда подпускать на пушечный выстрел нельзя.

Когда речь о мелочах, решающих рутину конкретного человека - почему бы и нет? На прошлой работе нужно было XML-ки из Росреестра переводить в читаемый вид, никаких программ (на тот момент), которые бы это делали не было, сайты по переводу были, но они работали медленно. Попросил коллегу из ИТ чем-то помочь, он за пару дней написал прогу, которая за 2-3 минуты переводила около 1000 выписок в читаемый вид. Были сложные выписки (порядка 25%, которые не переводились его программой), их уже через сайт преобразовывали (а там скорость 3 выписки в минуту). На другой работе нужно было регулярно считать неустойку по 44-ФЗ, сам себе написал формулу в Excel, времени экономило массу, вся контора пользовалась. А когда пришла проверка из контрольного управления, возник спор, кто правильнее считает (т.к. наши сотрудники подозрительно быстро считали), но наши победили :) [к слову, когда писал эту формулу, нашел ошибку в законе, там были условия до 50% и больше 50%, а точно 50% не было]

И последняя история как анекдот. Воронежский филиал компании "Гарант", 2001 год, есть девочка типа секретаря в обязанности которой входит заполнять договоры на поставку программы, так она постоянно косячила, ее постоянно ругали, но на ту мизерную зарплату никто бы не пошел. Предложил ей сделать шаблон в Word, чтобы она просто заполняла поля, выбирала варианты из выпадающего списка и пр. Согласилась, сделал ей шаблон, попробовала и выдала вердикт: "Я договор делаю 30 минут и в это время меня никто не трогает, а с твоим шаблоном я его сделаю за 5 и тогда мне поручат дополнительные обязанности". Вот так я не стал программистом :)

Аватар пользователя Циклоп
Циклоп(11 лет 1 месяц)

Прекрасный обзор проблемы. И да, в юриспруденции все точно так же. Но

И вот тут хотел бы отметить главное отличие российской компании в которой я работал от западной: в российской никакому оптимизатору не получится пропихнуть свою разработку мимо ИТ. Если ИТ сказало нет, то значит нет. А вот в иностранной есть разные способы, как пропихнуть. Через директоров, через свой личный бюджет или через низкую дисциплину. 

- бывает по-всякому и там, и там)))

Аватар пользователя Советчик
Советчик(5 лет 12 месяцев)

Мое любимое выражение по этому поводу "Автоматизация бардака - приводит к автоматизированному бардаку". Поэтому начинаем с упорядочивания и регламентирования практической деятельности сотрудников. Вот когда будет понятно кто чем и зачем занимается - тогда и приходите со своим "оптимизаторством". А до тех пор пор - нах с пляжа.

Комментарий администрации:  
*** Уличен в антисоветской лжи и набросах - https://aftershock.news/?q=comment/7625227#comment-7625227 ***
Аватар пользователя Serj800
Serj800(11 лет 1 месяц)

Без внятного ТЗ результат ХЗ

 

Аватар пользователя Советчик
Советчик(5 лет 12 месяцев)

Я знаю это выражение. Вот только у заказчиков обычно полностью отсутствует понимание как пишется ТЗ. Поэтому до их мозга оно не доходит. Отсекается ещё на уровне ушей.

Комментарий администрации:  
*** Уличен в антисоветской лжи и набросах - https://aftershock.news/?q=comment/7625227#comment-7625227 ***
Аватар пользователя Serj800
Serj800(11 лет 1 месяц)

С этим не спорю. Поэтому зачастую автоматизация и обречена. Т.к. исполнитель прикрывает свой зад, а заказчику вешается лапша на уши, что он получит то что хочет. А когда получает продукт, то не доволен. А ему и показывают тз, в котором все ходы записаны и стоит подпись заказчика. Проходили.

Поэтомк заказчику и нужен спец, который проверит тз на вшивость и настоит на том, чтобы в из было то, что нужно заказчику.  Но с людьми с такими компетенциями сложно. Человек должен разбираться досконально в бизнес-процессе, ну а также в it, хотя бы на уровне понимания возможностей внедряемого инструмента. Как показывает практика, для небольших предприятий это возможно, когда совладелец/владелец бизнеса имеет техническое образование  и может адекватно оценить тз.

Аватар пользователя Капустин Степан

Вот только у заказчиков обычно полностью отсутствует понимание как пишется ТЗ.

Я вам секрет страшный открою: заказчик не должен писать ТЗ. Он его должен только согласовать.  Максимум - описать технологический процесс, какие данные и с какой точностью от этого процесса ему требуются.

А писать ТЗ должен исполнитель - он лучше всех знает, что и как делать.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Вы в очередной раз показываете свою некомпетентность. ТЗ может писать кто угодно. Это может быть стороння организация. Если идешь на тендер, ТЗ уже должно быть готово. Как вариант, можно тендерить отдельно ТЗ.

Если в составе заказчика есть компетентные специалисты, могут писать сами ТЗ и привлечь для отдельных разделов сторонних специалистов. Вариантов много. 

В любом случае, для учета специфики предприятия требуется привлекать специалистов заказчика. Так что оптимально, когда ТЗ пишется совместно. 

Более того, от грамотно написанного ТЗ зависит чаще всего объём работы. Поэтому ТЗ часто вообще отдельно тендерится. А кто будет постом исполнителем - решит лишь следующий тендер. 

Так что утверждать 

А писать ТЗ должен исполнитель - он лучше всех знает, что и как делать.

это демонстрация своей некомпетентности. 

 

Аватар пользователя Капустин Степан

Если идешь на тендер, ТЗ уже должно быть готово.

Да. И я видел, что туда пишут...

Не знает заказчик, что ему надо. Точнее, знает "сделайте большую красную кнопку, нажав на которую нам было бы хорошо". Если заказчик "продвинутый", то будет еще описание процесса, в результате которого заказчику становится хорошо. Причем описание будет примерно такое "мы кладем эту загогулину вот на эту плитку, нажимаем пимпочку, загорается лампочка". Чтобы по такому "ТЗ" сделать что-то внятное...

Самое свеженькое: немцам выкатили ТЗ, в котором одно из требований звучало "признаки брака по ГОСТ хххх". Пока немцы возились - мы тоже поработали на ниве модернизации почти такого же оборудования и нам было выкачено точно такое же ТЗ. Но нам оно не понравилось, и мы его переработали. Лично только по пункту "признаки брака" месяц из технологов мозги вынимал. Наше ТЗ стало больше раз в десять. Прошло какое-то время, наступило время сдачи проектов. Сначала была наша очередь "ой, а вот тут у вас сильно все неправильно, мы принимать не будем". Мы такие "вот это - ТЗ, а вот это - ваши подписи, а вот тут - все признаки расписаны, давайте составлять акт, что мы сделали не так". И все, пыл цеховых товарищей сильно пошел на убыль... А потом были немцы... Они отмотались только тем, что мол санкции и все такое.

А почему? А потому, что в ГОСТ признаки изложены для людей. Скажем, "сильная вибрация" - это  как понимать? Какая величина размаха параметра будет означать "сильная"? 1 тс? 2? Или может быть 50? Люди смотрят на картинку - вот такой ширины линия - это "сильная", а если меньше - нет. Ну так та линия самописцем нарисована, компьютером так не получится.

В общем, в ГОСТ написано "куча орехов" и картинка нарисована, как выглядит куча. А надо - сколько конкретно орехов есть куча - два, три или пять.

Не исправлен пока тот ГОСТ очень приличного возраста под компьютерную технику. Единственно чего пока добились - ввели в него разрешение использовать не только обычные самописцы.

от грамотно написанного ТЗ зависит чаще всего объём работы

Совершенно верно.

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Вы мне опять жалуетесь своими проблемами. И сообщаете про свои ошибки в ТЗ, допущенные из за вашей некомпетентности. 

А вначале меня же оскорбляли. 

Гениально. Супер. 

Аватар пользователя Капустин Степан

Я жалуюсь???

П...ц. Нет слов...

Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Если в составе заказчика есть компетентные специалисты, могут писать сами ТЗ и привлечь для отдельных разделов сторонних специалистов. Вариантов много. 

У нас обычно написание ТЗ выглядело так.

Начальство, либо с его подачи инициатор темы, излагает хотелки.

Потом с этими "хотелками" специально обученные люди делают "флюрографию" рабочих мест - беседы по процессам , узнать "Кто на ком стоял".

Кстати, обычно на этом этапе делается много открытий, вплоть до того что уже есть какое-то решение по некоторым вопросам данной задачи, но его забросили/забыли по неясной причине.

Потом "Писатель ТЗ" компонует полученный материал , мы делаем примерную оценку  и идем с этим к заказчику - утрясать детали и цены.

Причем неважно это "внутренний" или "внешний" заказ.

Аватар пользователя Советчик
Советчик(5 лет 12 месяцев)

Смешно. Заказчику не нужно знать откуда и какие данные передаются. Ему нужно решение стоящей перед ним проблемы. Да-да. Заказчику продается не некий ПП, а решение стоящей перед ним проблемы. А каким образом она будет решена - ему абсолютно неважно. Важно её решение в заданных рамках.

Поэтому нормальное ТЗ пишется в терминах заказчика. И никак иначе. Причем пишется аналитиком понимающим процессы (бизнес, производственные и пр.) заказчика.

А разрядность передаваемых данных это не про ТЗ. Это про постановку задачи исполнителю.

Комментарий администрации:  
*** Уличен в антисоветской лжи и набросах - https://aftershock.news/?q=comment/7625227#comment-7625227 ***
Аватар пользователя Барсук
Барсук(3 года 1 месяц)

Заказчику не нужно знать откуда и какие данные передаются. Ему нужно решение стоящей перед ним проблемы

Самое классное ТЗ от заказчика, которое у нас было - "Где мои деньги?" 

Оптовая торговля продуктами питания с передачей товара между точками, возвратами, уценкой, списанием и недобросовестными экспедиторами.

Аватар пользователя Тех Алекс
Тех Алекс(8 лет 10 месяцев)

У Анисьи Геленджик затопило.

Аватар пользователя Anisiya
Anisiya(9 лет 3 месяца)

Я ответила ниже. Правда, торопливо. Но тем не менее. А вот проблемы потопа меня не волнуют. 

Аватар пользователя ovod
ovod(11 лет 10 месяцев)

Как-то странно у вас там все организовано - ит-отдел принимает решение реализовывать ли фичу или нет. А где совещание с руководителем, ит-шниками, инициатором фичи, где как раз все базовые вопросы обсуждается: кто это будет делать, сколько это займет времени, сколько потребуется ресурсов, различные подводные камни, целесообразность и т.д и руководитель принимать всё-таки должен решение, а не подсылать девочек и оптимизаторов в ит-отдел после какой-то устной договоренности. Тогда никто никого не будет считать мудаком, если ответственность  за принять/отклонить будет возлагать на себя управленец. 

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

До выноса на руководство, обсуждается на уровне специалистов. 

 

Аватар пользователя ovod
ovod(11 лет 10 месяцев)

Если руководство поставило задачу обсудить возможность реализации предложения , то все равно должна быть обратная связь для него - если нельзя, то почему; если технически можно - то, что для этого надо, т.е. опять же в любом случае - какое то совещание. Не сами же специалисты должны между собой решать?

Аватар пользователя brekotin
brekotin(9 лет 1 месяц)

Ну так я и объяснял обычно. Ровно то что в статье написано. Обычно правда примеры приводил ещё из жизни, которые были им знакомы. На сайте ж не могу. Разглашение. 

Аватар пользователя Anisiya
Anisiya(9 лет 3 месяца)

Вот и я посмеялась. Организационно все происходит не так. Мало того, потребность в оптимизации должны озвучить сначала руководители соответствующих служб, а не те, кто желает к ним залезть грязными ручками. 

Страницы