Счастливый конец одной истории плавно перетекает в напряжённое начало другой истории. Наконец, после некоторого числа утомительных собеседований, приходит оффер. На этом бесплатная работа по поиску этой самой работы перетекает в нечто более-менее оплачиваемое. Ты выходишь полный энтузиазма, готовый привнести много новых идей, с выпирающей решимостью сделать мир лучше… Но компания к этому не готова. И преодоление этого препятствия становится первым, и, зачастую, самым сложным заданием на новой работе.                                                    Мой первый опыт работы программистом начался с того, что я, после прохождения интервью, пришёл на небольшой завод, где программистов до меня не было. На меня смотрели как на чудного зверя. Да и я сам был ещё совсем джуном, хотя мне уже было 32 года. Не, программировать я умел – я всё-таки по образованию программист. Но я не работал программистом, да и стек поизучал на предыдущем месте от нечего делать. Разработкой MES-системы занимался подрядчик, который решил по-тихому свалить, ссылаясь на занятость другими проектами. Поэтому меня и взяли в срочном порядке. А взяли юного падавана только лишь потому, что других вариантов не было – всё-таки город, в котором происходило действие был относительно небольшим. Моим менторством номинально занимался тот самый подрядчик, но делал это нерегулярно и «на отвали». Самое главное, что сделал мой работодатель тогда – не мешал и не требовал немедленного результата. Про меня в конторе мало кто знал. А я в это время с помощью интернета и такой-то матери изучал проект и нарабатывал базовые знания по стеку, коих оказалось так мало вначале… Конечно, для конторы я был котом в мешке. Да что там говорить, я для самого себя был кот в мешке. И если бы тогда на меня давили за результат, то я бы им так и остался.  Приняли меня туда как сисадмина – такой ставки попросту не было. Деньги поначалу платились в конверте, так как работа сисадминов оплачивалась скромнее. Менторства не было от слова «совсем». После мне помогали сотрудники, показывая, как работает система – аналитики не было тоже. Но мне нужна была эта работа – у меня были долги, плюс только родилась дочь, деваться некуда было. Так и начался мой опыт программиста, где я один был за всю команду – и менеджера проекта, и DevOps`а, и аналитика… Подобный случай с отсутствием менторства был спустя почти год после увольнения с этой работы, когда был мой первый опыт удалённой работы. Мне дали проект, дали немаленькую задачу и сказали делать. Естественно, я её правильно не смог оценить и сильно просрочил, но сделал всё хорошо. И после стал одним из ведущих разработчиков на этом проекте. Где-то отсутствует менторство новых сотрудников совсем. И при должном отношении руководства и сотрудников к работе это не мешает успешной работе. Но это чревато уходом не готовых к таким испытаниям сотрудников и злоупотреблениями от недобросовестных работников. Например, во втором примере одного из сотрудников в итоге уволили. Но такое увольнение несёт репутационные и финансовые риски работодателю. Есть очень токсичные компании, у которых просто не заморачиваются с такими мелочами, как адаптацией новоприбывших. В предыдущей истории я рассказывал про градообразующее предприятие. Там я узнал, что рабочее место можно наследовать. Туда действительно стояла очередь за забором тех, кто хотел туда устроиться, но среди них не было программистов. Именно поэтому меня туда и взяли, хотя стек технологий вообще не совпадал с тем, что я когда-либо использовал. Там я и ушёл во фронтэнд. Первый мой рабочий день начался с того, что мне выделили стул. Именно на нём мне пришлось просидеть весь день, так как остальное в срочном порядке выделялось. Через день меня определили в команду, ещё через неделю дали компьютер. А ещё через две недели из-за отсутствия результата перевели на другой проект. Тот проект я уже сделал полностью. Это было малофункциональное мобильное приложение на Angular. Задание давал менеджер, вышедший из производства и проработавший на этом месте больше 20 лет, причём с вытекающими замашками. Все его боялись, прилетевший в тебя степлер на совещании являлся нормальным делом. Сдал я ему проект только тогда, когда он наигрался с ним, делая изменения, а потом их откатывая и делая обратно. Был ещё один работодатель, с которым я принял решение расстаться на испытательном сроке. Сам проект был написан отвратительно, жутко тормозил (фронт!) и был чрезвычайно переусложнён. Вектор в сторону выполнения задач постоянно менялся. Задача ставилась, потом отменялась, потом видоизменялась и опять отменялась. Любое высказанное мнение напрямую владельцу считалось дерзостью. И, что самое грустное, остальная команда (два человека) вела себя подобным образом.  Тут трудно предположить, что можно улучшить. Проще подобных мест избегать. Две компании у меня были очень похожие по внутреннему устройству, поэтому выделю их вместе в отдельную главу, хотя работу я выполнял разную. В первой я ещё не работал программистом, но от нечего делать им стал на следующей работе. Во второй меня брали в основном для экспертизы работ подрядчиков, так как почти вся разработка выполнялась вне конторы.  Главное сходство – это количество начальников. В первой компании было 33 отдела на 100 сотрудников. Во второй – на 450 сотрудников 96 отделов, плюс 11 групп советников генерального директора. И, естественно, это сопровождалось очень сложной иерархией отделов, начальников, директоров, заместителей… То есть, одни начальники и начальники начальников. А работать некому. В такой сложной иерархии естественен дубляж обязанностей между несколькими отделами. А если за что-то отвечают несколько людей, то не отвечает никто. Постоянно находились те, кто перетягивал одеяло на себя, не забывая при этом перекладывать ответственность. Ну и чем должны заниматься начальники? Все вырабатывали стратегии, следили за эффективностью выполняемой работы и проводили совещания. В итоге, это выливалось в микроменеджмент, изматывающую бюрократию, перегрузкой исполнителей и в бесконечные бесполезные болтушки. Главной инициативой во второй компании стали дни тишины, когда тебе из других отделов не мог назначить совещание. Там же мне запретили проводить экспертизу работы подрядчиков, так как это относится к управлению разработкой, а, так как я был не начальником, то я этого не имел права делать. Ещё один из сопутствующих признаков таких компаний – финансовые проблемы. И это логично, ибо все ресурсы тратятся не на итоговый результат, а на поддержку бюрократического аппарата.  Что тут можно улучшить? Естественно, оптимизировать количество отделов и их функционал. Но это легче сказать, чем сделать. Ведь в процессе оптимизации очень легко можно прийти к тому, что нужно оптимизировать себя. И на это должна быть сильная воля высших руководителей, чего не стоит ожидать, так как уже допущено подобное.  Да, это так. И это хорошо, мы же не розовые «Телепузики», где все танцуют под одну песенку и ложатся спать ровно с заходом солнца. Солнце за гору садится, Телепузик спать ложится... Естественно, менторство в компании должно быть. Но трудно разработать один стандарт для всех, так как все с разными должностными обязанностями и компетенциями. Но всё-таки нужно предусмотреть ответственность проводящих приём и адаптацию новых сотрудников. Так же, как и поддержку тех, кто работает. Начальство в первую очередь должно работать с людьми, со своими подчинёнными, а уже потом заниматься разработкой стратегий и прочими вещами. На моей текущей работе, например, моим непосредственным руководителем проводится отличнейшая вещь – это личная встреча раз в две недели просто для разговора про работу и не только. В условиях удалённой работы это критически важно. Например, благодаря таким встречам появились эти статьи. А вот приём на работу, конечно, можно улучшить. Во-первых, долгая проверка службы безопасности, когда должен выдаться оффер и остались только они. Некоторые соискатели оффера не дожидаются. Ещё затягивается предоставление доступов, хотя уже добиваемся понимания важности решения этого вопроса.  ---- Вот теперь мы адаптировались и начинается уже настоящая упорная работа. Пора и мне уже написать что-то техническое…