Часть 1/3. Какие там «плюшки»? Часть 3/3. Какие типы работодателей существуют? Характеристики.
Подводные камни для новичка.
Первые подводные камни, собственно, могут начаться еще на собеседовании – например, проект новый, процесс собеседования еще не налажен, первый вопрос может быть «Есть ли у вас распечатанная копия вашего резюмеЭ» у иностранного представителя вообще этот процесс будет отлажен на вас как на одном из подопытных кроликов.
Вас также могут внезапно поставить на «конвейер»: провести сразу три этапа собеседования продолжительностью более часа каждый.
Это может вызвать проблемы, если вы не подготовились к собеседованию или если на этот день у вас запланированы другие собеседования.
Но это, кстати, правда.
Общие Соображения.
«Если кто-то виноват, то заранее ясно кто».
Во-первых , есть некая естественная тенденция при возникновении недоразумений (а что там было насчет управленческих и коммуникативных навыков?), трений и, особенно, конфликтов с участием новичка, трактовать их не в свою пользу.
Даже если новичок прав, причины его уволить все равно есть: «менеджер не может с ним работать», человек «не вписывается в неформальный корпоративный формат» или что-то в этом роде.
Если такое «не получилось» повторится с последующими, то либо через пару кандидатов они наконец-то поработают вместе с кем-то еще или задумаются, а может, «починят что-нибудь в консерватории».
В общем, если вы кто-то из начальства или «старожилы» из тех, к чьему мнению прислушиваются, вам «вдруг» что-то «не понравилось» или вы по каким-то причинам вызываете у него постоянное желание вас подразнить или задеть или продемонстрировать свое остроумие вместо ясного и четкого выражения того, что от тебя требуется, тогда если дело дойдет до дела, то понятно, кого будет проще уволить - новичка на испытательном сроке, за которого нужно платить три дня, или «более полноценный» сотрудник, которому нужно до расторжения трудового договора не по его инициативе платить за два-три месяца и с которым уже как-то сработало? А если за пару итераций все-таки найдут кого хотят и с кем работают, с вами спишут случай «мало ли».
И вопрос в том, хотите ли вы сами работать в такой среде.
«Вася бесконфликтный.
Это аксиома.
Если у вас с Васей конфликт, то виноваты только вы.
Это следствие аксиомы».
Примерно такая же ситуация, когда начальник на новом месте сразу говорит о себе (и о нем говорят другие начальники) как о «бесконфликтном» человеке: это всего лишь толстый намек на то, что если между вами возникнут недоразумения и конфликты, то виноваты вы заранее назначенные, а не «бесконфликтные».
Недоразумения, как ни странно (хотя, в целом, не странно), могут возникнуть буквально на ровном месте.
Например, в самом начале работы над проектом ведущий разработчик, назовем его «Петр», описывает, какие плагины для IDE следует установить.
Вы просите его списать всю IDE с уже установленными плагинами (время поджимает, вы, и не только вы, уже много раз читали «мотивационную вступительную записку», что нужно быстрее начать работать), он, за из соображений большей корректности вместо xml выдает xml-файл с сайтами обновлений плагинов, которые у него успешно работали полгода-год назад. Вы пытаетесь использовать этот файл уже 24 часа, и ничего не получается: один из плагинов больше не находится по указанному адресу и не может быть установлен, и в то же время все плагины, которые появляются после него в списке, не могут быть установлен.
Когда вы рассказываете об этом своему «бесконфликтному» начальнику, он отвечает, что «Петя» «не может давать плохих советов», и это, вероятно, ваши кривые руки.
( P.S: самокритика «посмертно»: тупо использовать неизвестный файл в непонятном месте — «некруто» (хотя частично оправдано тем, что «надо очень быстро»).
Вместо этого вам нужно уметь быстро разбираться в непонятных вопросах, используя Google и ассоциативное мышление.
По крайней мере можно было (в те же «бесплодные дни», возможно, на другой машине) 1) найти как устанавливать плагины по одному, 2) изолировать «недостающие» плагины 3) найти куда они «переехали» или установить что они отсутствовали на концах.
) Но может быть и наоборот – вы сразу сможете произвести впечатление особо «перспективного» сотрудника, которому, наоборот, будет предоставлена фора перед сотрудниками со стажем, «не зарекомендовавшими себя» (ибо Например, вас возьмут на должность ведущего Java-программиста в веб-проект даже при полном незнании языка Javascript (правда, если у вас есть опыт использования GWT, в котором знание Javascript не обязательно)).
Ну а при хорошем развитии коммуникативных навыков, в случае конфликта с руководителем, есть даже шанс объяснить вышестоящему начальству, что руководитель не прав.
Хотел написать, что не проще ли было бы это сделать до конфликта, но стало понятно, что до конфликта смысла обращаться в вышестоящие инстанции просто нет. Во-вторых , замечена «плохая примета»: если во время испытательного срока вам напомнят, что вы находитесь на испытательном сроке, то, скорее всего, его «завалят».
Подгипотеза - причина в том, что ее прохождение, в общем-то, не планировалось, точнее, было запланировано процентов на 30-60. Третий , то, что испытательный срок будет «завален», обычно становится понятно через две-три недели: все как-то странно идет наперекосяк, а элементарные вещи остаются непонятными (как будто их намеренно держат в состоянии «непонятности»).
Такой полный испытательный срок обычно занимает полтора месяца при «нормальном» стечении обстоятельств и два месяца, если есть фиксированная общая дата увольнения (подробнее я расскажу ниже).
Виды встречающихся подводных камней.
- Руководство плохо понимает, чего они хотят технически.
Теоретически такое встречается редко, но автор лично с таким столкнулся один раз.
Это был «затянувшийся стартап», финансирование которого продолжалось по доброй воле его финансового директора, который одновременно был одним из топ-менеджеров в одном агентстве недвижимости, для этого агентства одновременно обслуживалась эта компания и вместо ИТ отдел.
Компания хотела написать CIS, они хотели иметь для него GUI-модуль, который мог бы работать и как веб-клиент, и как «тяжелое» Swing-приложение (ни я, ни они не знали на тот момент понятия «Богатый клиент», это было начало 2005 года).
В итоге в качестве универсального промежуточного слоя автор выбрал некую обрезанную и модифицированную версию SwiXML. Работодатели не смогли четко сформулировать, что им нужно в качестве базы — веб-версия или свинг-версия.
Автор там был как минимум вторым в этой области, после него дело решили передать некоему аутсорсеру из Москвы.
В качестве некоторой самокритики «посмертно» можно сказать, что если бы автор был более опытным, возможно, он смог бы быстро найти и «продвинуть»/ «продать»/ «прокрасться»/ «навязать»/ «внедрить» решение по ним, но есть встречное подозрение, что, будучи таким умным, автор вряд ли соблазнился бы на эту вакансию ;-).
Однако через месяц после увольнения, из которых поиск работы занял последнюю неделю (остальные три недели были временной подработкой), автор нашел другую работу, где зарплата и четкость задач были выше.
- «Нужно человеку пять минут, чтобы его уволить».
Формулировка несколько утрирована, но как минимум пара разновидностей этого явления существует: 1) нужно временно занять чье-то место, чтобы потом перевести на него нужного человека, или 2) заранее нанимают больше людей, чем они планирую уйти.
Первый может быть, например, когда аутсорсинговая компания массово закрывает проекты из-за сокращения рынка, и вдруг ей удалось запустить один проект: удалось его «раскрутить» и найти заказчика.
В этом случае на проект нанимают одного «лишнего» человека, а то и, по настоянию опрашиваемого менеджера, человека, который находится чуть ниже уровня вакансии, а затем всячески скрывают от него «жуткий профессионал».
секреты», такие как автоматическое форматирование с помощью IDE, полуавтоматический рефакторинг и прочее «причесывание кода» ими — чтобы позволить человеку перерасти негатив в личное дело.
Вторая причина может сочетаться с первой и даже маскировать ее.
Подобный «агрессивный кадровый отбор» может практиковаться на постоянной основе – в частности, в некоторых ИТ-компаниях, обслуживающих интернет-беттинг: им нужны люди со специфическими навыками, которые, похоже, по мнению местных властей, невозможно развить, но можно выбрать только тех, у кого они уже есть.
В таких компаниях увольнение тоже поставлено на конвейер, есть фиксированные даты массовых увольнений и хитрая политика внесения предложений о работе: нужно, чтобы между предложением о работе и датой массовых увольнений было меньше (хотя бы на в неделю), чем максимальный юридически возможный испытательный срок — три месяца.
Если они решат «отказаться» от сотрудника даже спустя всего три недели, ему просто перестанут давать задания и могут держать его в таком странном «подвешенном» состоянии почти два месяца, оставшихся до даты массовых увольнений, официально не принимая во внимание за все это время действительно было принято давно решение об увольнении.
"Бонусом" к такому "кадровому конвейеру" является несколько "несправедливое" и в целом равнодушное отношение к новичкам: раз половину из них все равно увольняют, то "если мы кого-то зря обидели" - то это мелочь по большому счету.
схема вещей.
— Значит, тебе не повезло.
Значит, ты неудачник.
Убирайся! Корпорации не нужны неудачники!» Если в середине процесса выполнения задачи, на которую отведена неделя, вы вдруг вынуждены мигрировать с медленного компьютера, который вам дали сначала, на новый, иначе его отдадут в соседний отдел , а при миграции нужно скопировать ~100 ГиБ рабочих пространств, и при этом освоить работу на них в Windows 7 после XP - то это как раз такой случай.
- «Русский SCRUM, бессмысленный и беспощадный».
Автор столкнулся с этим осенью 2009 года в одной компании из "топ-10" софтверных компаний Санкт-Петербурга (однако через пару месяцев в этой компании начались массовые сокращения персонала - правильно: "по соглашению сторон" и с выплатой двухмесячной зарплаты в качестве выходного пособия).
Они следуют не столько «духу» метода SCRUM, сколько его «букве», и не везде, а произвольно, главным образом, когда это ситуативно наиболее противоречит духу и негативно влияет на результат. Команда набирается на 60-70% из людей, которые раньше не работали по методу SCRUM и в основном из новичков.
Недостатки «гибкой» и «водопадной» технологий удачно сочетаются: первые относятся к планированию малосерьезно — времени на него выделяется очень мало: часа на трехнедельный спринт с разделением задач на подзадачи нет. дольше пяти, а лучше двух-трех часов (всего в среднем около 10 секунд на планирование одной задачи), со второго — невозможность отступить от наспех спланированного и исправить ошибки планирования в ходе спринта.
Он служит источником «косяков», которые легко можно перевести на «кому надо» (с записью в личном деле), благодаря чему хорошо сочетается с практикой «принимать людей с запасом» из предыдущего пункта .
- «Повторяющийся» испытательный срок.
По окончании испытательного срока (да, целых три месяца) вам говорят, что вы им не подходите, но вы можете уволиться по собственному желанию и сразу написать заявление о приеме на работу — вас возьмут на работу.
И так все время.
- Недооцененные и «мутные» задачи.
Правильнее было бы назвать эту ловушку «пропастью скрытого расследования».
Когда и объем работ, и время, необходимое для их выполнения, должны быть результатом отдельного, заранее не предусмотренного, исследования, которое еще необходимо провести, и результат может иметь разброс в 10 раз или отличаться в разы 10 от значения, которое было установлено при первоначальной оценке.
Здесь в чистом виде существует «плавучая школа» (неизвестная новичку поначалу).
Упомянутый выше пункт о «недоразумениях и конфликтах» может сработать: когда сотрудник со сложившейся хорошей репутацией «натыкается» на такое задание, он с большей вероятностью поверит, что задание ранее было оценено неверно, чем новичок.
Да и такие задачи, как правило, ложатся на плечи новичков.
«Старожил» зачастую имеет право, не совсем формально, но по сути не просто «выбирать задачи по душе», а «расставлять для себя приоритеты» (исходя из своего опыта), что делать в первую очередь и что делать в первую очередь.
что делать в первую очередь.
во-вторых, расставить задачи в очередь и расставить приоритеты, какая задача, исходя из какой из них, по его мнению, более нужна и важна для проекта в целом и, выполнив какую из них, он сможет быстрее принести больше пользы проекту .
Очередь может так и не дойти до третьего-четвертого этапа, в том числе и из-за того, что включающая ее «сверхзадача» может быть перенесена с выбором другого способа ее решения, и тогда исходная задача оказывается сюрпризом! - исчезнет. Да, «старожилы», всячески пытающиеся «оттолкнуть» от себя столь «мутные» задачи, зачастую правы: дело имеет шанс обойтись обходным путем.
У новичка повышен риск «попасть» в такие «мины» еще и потому, что руководство может затаить скрытую мысль, что новый человек придет со свежим взглядом, и с этой новой точки зрения решение проблемы может показаться более простым и Быстрее.
Особенно «весело», если в ваш план на пробный период входит несколько заданий по неделе каждое, и первое, за которое вы возьметесь, окажется из серии «бездна скрытого расследования»: так вы сможете выполнить три с четвертью задания за дедлайн из четырех, иначе из четырех вы сделаете ноль с половиной проблем.
Чтобы «выкрутиться» и добиться максимального успеха, в такой ситуации нужны управленческие навыки (чего не ожидалось поначалу): заранее оценивать задачи на предмет обилия подводных камней (для этого нужно обладать навыками взлома задачи, покомпонентная оценка рисков и прочее планирование), «пробивая» себя первыми по очереди, те задачи, которые менее «мутны», обоснованно «прыгать» от задачи или добиваться ее перепланирования, если во время ее выполнения решения вдруг выяснилось, что это его «мутность», «перевернуть стрелки» субподрядчикам (типа постановщикам задач) и педалировать тезис о том, что это они вас подставляют (провоцируя) срывом сроков выполнения работ по за что вы несете ответственность.
Если у вас по каким-то причинам есть личная «точка» на «неконфликтность» (о чем говорилось выше), то это во многом связывает вам руки.
С другой стороны, «мутные» задачи — это тоже возможность ;-).
Шанс изучить новые технологии и приемы (например, запуск ELF-файлов из Tomcat в MSWS на виртуальной машине - надо не забыть убить дочерний процесс через 5 секунд, что непонятно как сделать, кроме как из специально запущенного параллельного потока) , попрактиковаться в (сверх)инжиниринге, например, в написании фреймворков на основе аннотаций.
Особенно если это не повлечет за собой увольнения в связи с непрохождением испытательного срока ;-) Также «навязывание мутных задач новичкам» хорошо вписывается в политику «кадрового конвейера» - «одновременно», поскольку половину из них все равно уволят. Но с другой стороны, это тоже можно рассматривать как своеобразное «боевое крещение».
Не особо большое, но для некоторых фатально значимое количество «мутных» задач появляется и в случае с «бессмысленным и беспощадным SCRUM» из предыдущего пункта.
Это не только задания из серии «бездна скрытого расследования», но и слишком зависимые от других задач (невозможно начать один раз, пока не будут решены другие), что поначалу не заметно или может быть намеренно не акцентировано.
Здесь нужно проявить изрядную оперативность на том кратком этапе, когда исполнители разбираются со своими задачами, чтобы у вас не остался аналогичный – последний – проблемный участок.
Здесь тоже нужно иметь некоторый опыт, которого обычно поначалу нет. Хотя, подозреваю, эта экзотика сохранялась и в 2009 году и ранее.
Пункт «Руководство плохо понимает, чего хотят технически» тоже можно считать утрированным вариантом этого пункта — вплоть до «ищем мидл-разработчика для выполнения задач ведущего архитектора».
А вообще, здесь главное не обольщаться такими вакансиями и уметь аргументированно и понятно объяснить людям, чего они «хотят за гроши» — они смогут понять.
- Общая «гнилость» конкретной узкой области работы.
Стоит выделить его в отдельный от предыдущего пункт. Работы разные.
Если организация большая и делает один большой продукт с вариациями, то велика вероятность, что у нее появятся направления работы с существенно разной «интересностью» задач и перспективами профессионального роста.
Не то чтобы это подводный камень специально «для новичка», но… Кто-то пишет ядро, а кто-то с таким же красивым ярлыком «Java-разработчик» срочно пытается выяснить, «почему эта хрень перестала работать у заказчика во время пробная эксплуатация, Да, блин, оно было написано неправильно и никогда не работало должным образом - меня спас механизм по умолчанию, но здесь последние изменения были внесены полгода назад, почему об этой ошибке сообщили только вчера??" и занимается реальным программированием в общей сложности три месяца в течение двух лет, из которых два месяца - на испытательном сроке, причем, по сути, толком не изучая систему, которую компания делает за пределами общего уровня.
И – сюрприз! Это вообще неудивительно - именно в таких сферах наблюдается повышенная текучесть кадров, люди уходят через полгода по собственному желанию (да-да, 146% по собственному желанию), а по теории вероятностей - новичок имеет наибольшие шансы оказаться именно в таком секторе.
Говорить об этом с начальством вообще бесполезно, наличие таких зон является объективным следствием того, как организована работа, эту работу кто-то должен делать в любом случае, «организация социальной справедливости» не является целью компании.
, компании тупо проще смириться с дополнительной работой.
затраты из-за текучести кадров в таких областях.
Направлений может быть немного, но они вносят основной вклад в общую текучесть кадров в компании, а также являются неизменно значимым источником вакансий.
- Общая «экзотика» новичка.
Редко, но.
Если вы "неформатированы" по какому-то критерию, например, возрасту - вам за 35, то есть еще одна причина предвзятости: стереотип "в 30 пора быть менеджером, а не программистом".
«и тем более, «не ищи работу иначе, как через личные связи» еще не испарилось; для некоторых вы превращаетесь в экзотического «неудачника», которого «не жалеют».
Здесь нужно быть готовым «объясниться» больше, чем обычно, «сломать шаблоны», «создать свой имидж» и показать другие грани коммуникативного балансирования.
С другой стороны, стоит ли оно того, ведь такие недоразумения были с самого начала?
- Меньшие недоразумения.
Из более мелких, менее опасных недоразумений хотелось бы отметить ситуацию, когда начальник, по его мнению, точно знает, как выполнить данное ему задание, а вы имеете больше опыта выполнения конкретно подобной работы и умеете сделайте это быстрее, но ваше начальство не оценит ваш метод. Например, необходимо интернационализировать русский веб-интерфейс на JSP (~150 файлов) - переместить куски текста в файлы ресурсов и заменить ссылками на них, руководство не знает о существовании макросов Word и настаивает на том, чтобы все необходимо делать вручную в «блокноте».
Здесь варианты могут быть разные - например, делай так, как говорит начальство, или делай так, как считаешь нужным сам, или делай так, как считаешь нужным, но начальство пока не видит, или «отстаивай» свой подход перед начальством.
Если все равно не получится.
Когда компания нанимает пять человек подряд на одну и ту же работу, и ни один из них в итоге не удерживается, то это выглядит не так плохо (по крайней мере, не так заметно), как если бы человек сменил пять мест работы и в итоге получил ни один из них.
не проводится.
Если вы (или «вы», но «крайним», конечно, все же оказались вы) «провалили» испытательный срок, то вам нужно подумать, как отразить это на следующих собеседованиях.
Этот эпизод трудовой деятельности вы можете отразить в своем резюме, его не обязательно упоминать (особенно, если записи в трудовой книжке нет), можно упомянуть устно, на втором или третьем этапе собеседования, вы можете начать упоминать его в резюме, но не сразу, а через пару мест работы (их вам еще предстоит получить!).
Если вы об этом не упоминаете, то нужно как-то объяснить, почему вы якобы в это время не работали (ага, человек уволился 22 мая во вторник - ни с понедельника, ни с конца месяца - по своему свободная воля, проработав год, и что-то вдруг ищу работу с 8 сентября).
Если по закону подлости причиной ухода с прежнего места работы была низкая, по вашему мнению, зарплата (ага, картина маслом: «оставила низкую зарплату в никуда»), то вам придется искать другое объяснение, в общем, определитесь, чего вы хотите лучше: репутации сотрудника, «провалившего» испытательный срок, или репутации сотрудника, склонного внезапно уволиться с работы «на ровном месте».
Если работа отражена в трудовой книжке или вы решили упомянуть о ней по другой причине, то нужно подумать, как объяснить причины ухода.
Если, например, вас попросили написать «самостоятельно» из-за плохого качества вашего кода и из-за того, что вы оказались лишним в команде (точнее, в команде заранее кто-то оказался лишним и этим "крайним" оказались вы, может быть от - потому что качество рабочего процесса, в том числе и качество кода, сознательно "пренебрегалось" везде, где только можно), и при собеседовании на очередное место работы вы скажете, что вы ушел из-за конфликта в коллективе, то тем самым прямо на этапе собеседования вы будете навешивать на себя ярлык «конфликтного», что может затруднить прохождение уже там испытательного срока ;-).
Ну, никто и не обещал, что маленькие хитрости будут совершенно бесплатными и никогда не дадут аукнуться ;-).
Тогда, через пару лет/места работы, «улучшив» качество кода, можно будет назвать (устно) «настоящую» причину.
И еще один положительный, и особенно важный для IT и Java аспект непрохождения испытательного срока — остаются знания о технологиях, методиках, платформах и библиотеках, получить которые иным способом было бы проблематично.
Что-то вроде заключения.
Выше уже мелькала фраза о «боевом крещении».
Это действительно так – если успешно пройти испытательный срок, то будет легче (по крайней мере, будет какая-то положительная репутация).
В целом, для успешного «боевого крещения» и преодоления стресса, связанного с встраиванием в новую структуру, желательно удовлетворить требования вакансии «146%», быть «на голову выше» требуемой работы .
Ведь требуемую производительность придется обеспечивать с учетом непредвиденных рисков, недоразумений, предвзятостей и других возможных мешающих и демотивирующих факторов.
Для этого нужно быть хотя бы немного менеджером: планирование и риски — это уже управленческие компетенции.
Еще пара советов.
Хорошо бы, чтобы все «чреватые» приказы, указания, объяснения, данные Вам и Ваши ответы на них, фиксировались В противном случае сначала тимлид устно попросит вас закоммитить непроверенный код, а потом менеджер проекта скажет, что тимлид не мог этого сказать.
И помните, что на тебя есть личное дело, где все ваши ошибки записаны - хотя оно и несколько предвзятое, в нем не будет написано откровенной проверяемой лжи или излишне оценочных суждений, выходящих за рамки делового стиля со степенью их оценки.
Прочесть, правда, тоже не дадут, хотя знать, какое направление работы над собой будет лучшим, было бы полезно.
Вы также должны быть внутренне готовы к тому, что испытательный срок может быть «сорван», в том числе и не по вашей вине.
В утешение можем сказать, что обычно, т.е.
более чем в 50% случаев такой неприятности все равно не случается ;-) Часть 1/3. Какие там «плюшки»? Часть 3/3. Какие типы работодателей существуют? Характеристики.
Теги: #java #работа #человеческие ресурсы #java
-
Простые Эфиры
19 Oct, 24 -
Mobile2.0 Универсальная Доступность
19 Oct, 24
