Интересно, много ли желающих найдется на 70К? PLI, JCL, HLASM ... при том что ASM за последние 10 лет изменился очень прилично по набору команд (расчет на "старичков" не прокатит, тем более вряд-ли они помнят макрокоманду SNAP). Или расчет на "молодость", которая за 2-6 месяцев натаскают?
То - сисадмин, а тут - надо просто знать как работать в zOS. Это же любая кухарка умеет. 70к явно много для сопровождения (а для разработки - занижен уровень требований).
ЗЫ Работодатель не хочет назначать оклад в зависимости от ответственности позиции? что будет, если код вовремя не поправить (сопровождение) или накосячить в приложении (разработка)? Каковы будут потери? Почему за это должен отвечать человек, с окладом в 2к грина?
Про "кухарку в zOS" это Вы как-то смело выступили...(кстати, Сталин с этой фразой, в свое время, несколько погорячился). С остальным согласен. ЗП Админа привел для сравнения. Заказчику есть смысл рассмотреть возможность привлечения спецов на неполное раб.время или в дистанционном варианте, правда, сие предложение - не бесспорно.
позвольте заметить - не И.В. Сталин, а В.И. Ленин И точная цитата звучит так: "Каждая кухарка должна научиться управлять государством" Сорри за оффтопик
Строго говоря, Ленин написал другую фразу в статье - «Удержат ли большевики государственную власть?», далее Сталин в работе "Вопросы Ленинизма" перефразировал и сократил цитату Ленина до общепринятой. Но это непринципиально для данной статьи.
То есть вы считаете, что разбираться в коде, который писали 10 лет, разные люди, с разным представлением о стиле - это легче, чем стряпать новое приложение с нуля? Понять зачем проверяются/устанавливаются биты по 20ти каким то полям и смещениям проще, чем при разработке по доке расставить биты туда и туда, для достижения эффекта?
Ну и да. Какой incoming rate? SLA?
Взять студента без знаний и учить(программа есть? Люди желающие делиться?) - это еще реально. Считать, что поддержка это легко - большая ошибка. Людей в возрасте уже не научить, а молодые через 3 года захотят перспектив, индивидуального плана развития и тд. Думаю Москве будет что им предложить.
В обычной жизни люди сначала учаться читать, и только потом писать. Не знаю почему, но в программировании все перевернуто с ног на голову, и совсем не редкость люди, умеющие писать [программы], но не умеющие [программы] читать... IMHO сопровождение требует значительно более высокой квалификации, нежели чем разработка с "нуля". На чистом листе можно писать все что угодно как угодно, а исправить как попало ранее написанный работающий код не получится. Не говоря уже о том, что при модификации нужно не только разобраться в бизнес-логике, часто запутанной и редко документированной, но и очень желательно при внесении изменений сохранить оригинальный стиль, чтобы код не выглядел как лоскутное одеяло.
Плюс еще необходим особый набор человеческих качеств.
Каждый новый приходящий считает свои долгом объявить, что это лапша-код и только он знает как переписать правильно. Несмотря на то, что его предшественник завершил переделку этой же функции с точно такими же словами. Потом "оно" заявляет, что тут исправить уже ничего нельзя и надо все выкинуть и переписать... на С#. То "оно" в порыве страсти начинает править все баги подряд, при этом не комментируя где и что было исправлено и сам фикс никак не может выйти. То "оно" вместо исправления ситуации пытается просто выдать сообщение, что мол плохо. Некоторые просто падают с дампом С1, там же все видно(!?). Потом "оно" пугается править даже строчку в функции (вдруг сломает то что работает) и создает копию всей функции на каждый новый случай.
Перечислять можно бесконечно. Если вы не удержали того молчаливого гения, который 10 лет один тянул весь ваш проект за гроши без единой прибавки - вам пора на курсы менеджмента учиться оценивать людей по достоинству.
мне тут как-то по случаю и по работе выпало поковырятся в куче кобольного американского кода (где-то 120 МB исходников вместе с JCL процедурами и заданиями). очень, очень приятно было наблюдать. Видно было, что явно не одна рука, стилевые различия чуствовались (ну авторство то там пофамильно указано, суть не в том - стилевые отличия в коде читались). Но приятно удивляла общая целостность огромного проекта, единообразие. Чувствовался серьёзный подход, навязанный силой большой группе людей на протяжении многих лет. Не первый раз американцы меня приятно удивляют, как профессионалы. Обидно, что при сталкивании с этим порядком, мятежная и широкая российская душа начала привностить нотки хаоса, действуя по принципу "нифига непонятно, ну американцы тупыеее", и не пытаясь разобраться, почему американцы так сделали, и что вряд ли они тупые, если комплекс работает десятилетиями успешно. Так что вопрос менеджмента в управлении разработкой - сами судите, на сколько важен. А как вам заявления партнёров, например: - документации у нас нет, а зачем она? заказчик не просил, а мы уж так давно работаем, что всё помним - у нас документации нет принципиально! у нас subject matter эксперты! Вот как это, а? И это заявляют ведущие лица, не кодеры. Менеджеры звена управления компаниями.
Вот я вижу, что на сайт пришел Алексей Редько, автор вакансии. Можете задать ему все наболевшие вопросы и высказать все, что думаете о том, 70тыр это много или мало. Идея насчет z/Master 2014 - очень хорошая, спасибо, Сергей. Ну и вообще спасибо всем высказавшимся.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]