Из PM-ов в разрабы. Шаг назад для продвижения вперёд

Вступление

Меня зовут Илья, и 2 года назад я из проектных менеджеров в ИТ (они же PM-ы) переквалифицировался в Java-разработчики. Так получилось (как ни странно), что бОльшую часть круга моего общения составляют ИТ-шники. И, наверное, в 99% случаев обсуждения карьерного трека за кружкой пива/кофе многие удивленно спрашивают меня: «Ничего себе? Из PM-ов в разрабы? Какой редкий кейс! А почему? А ведь обычно наоборот – из разрабов в PM-ы? А это дауншифтинг или нет?». Такое количество вопросов и интерес к этой теме навели меня на мысль написать статью о том, как я «докатился до разработческой жизни» из PM, что меня сподвигло, чем руководствовался. Так что, если и вас одолевает подобный интерес, смело читайте далее!

Цели

Для чего я пишу эту статью:

1. Во-первых, интересно познакомиться с коллегами с аналогичным или похожим опытом, которые тоже «перепрыгнули» из PM-ского карьерного трека в девелоперский, узнать их мотивацию, применяемые ими подходы.

2. Во-вторых, хочется дать материал, стартовую точку для тех, кто, как и я, в какой-то момент понял, что сугубо менеджерский трек карьерного развития – это не для него. Чтобы показать, что такое тоже бывает, что это реализуемо и перспективно, и что если вам это интересно – смело составляйте личный план и реализовывайте его!

Небольшой дисклеймер. Все, описанное далее в статье, – мои личные взгляды на работу PM-ом и разработчиком, пропущенные через призму субъективизма, личного опыта и опыта знакомых мне коллег PM-ов и разработчиков. Допускаю, что где-то и у кого-то деятельность PM-а или разработчика заключается в чем-то другом. Как справедливо и то, что перечисляемые мной минусы и плюсы – это минусы и плюсы в первую очередь для меня, и, на самом деле, это совсем не минусы для кого-то другого – а даже наоборот, эффективный инструмент профессионального роста и карьерного продвижения!

О нелегкой доле PM-ов

В конце не такого далекого 2020 года я понял, что работать PM-ом мне становится все скучнее, да и в целом я двигаюсь не туда, куда мне хочется. На тот момент я проработал PM-ом уже порядка 4 лет и находился на senior-позиции в менеджерском треке, а под моим управлением находилась пара крупных проектов с большими компаниями.

В то же время я начал задумываться о том:

• получаю ли я от текущей профессиональной деятельности то, что представлял себе на ранних карьерных стадиях как с точки зрения специфики деятельности, так и с точки зрения эмоционального удовлетворения?

• как развивать свою карьеру далее, в каком направлении двигаться, какие шаги предпринимать?

В определенный момент я взялся и спокойно в несколько подходов обдумал, что меня в текущей деятельности PM-ом не устраивает на данный момент, а также кем в трудовой сфере (должность, тип и сфера занятости компании, уровень дохода, объем и спектр полномочий) я хотел бы себя видеть лет через 10-20 и какими путями можно было бы туда добраться. Почитывание на досуге Герберта Шилдта, а также просмотр хайповых роликов про Кремниевую долину и БигТех дополнительно триггерили меня на предмет того, куда и как можно расти и развиваться дальше.

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

Минусы быть PM-ом

1. Много работы с документами

Стандарт PMI PMBoK (Project Management Body Of Knowledge) сам по себе предполагает под собой ведение большого количества различных документов: устав и план проекта, множество других планов, реестров, журналов и т.д.. Очевидно, что в реальности весь объем документов из PMBoK никто, наверное, и не поддерживает. Тем не менее проектной документации, которую необходимо на протяжении ведения всего проекта поддерживать в актуальном виде, предостаточно.

А еще есть пресейлы и договорная работа. И это тоже ощутимый объем коммерческих предложений и договоров. А ведь зачастую PM-ы начинают работать с клиентом уже на этапе предпродажи вместе с сейлзами.

А есть еще более специфичная проектная документация – спецификация требований, техническое задание, проектное решение, интеграционное решение и т.д. – и, по-хорошему, PM-у надо бы в ней очень неплохо ориентироваться, обсуждая нюансы проекта с аналитиками, разработчиками, QA и клиентом.

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

2. Много звонков и митингов

Отчасти, это особенность работы любого специалиста со словом «менеджер» или «руководитель» в названии должности. Если ты не занимаешься документами, то ты на митинге!

Применительно к проектному менеджеру – как минимум 1-2 митинга в день у тебя точно будет. Как минимум. Бывают дни, когда ты просто не покидаешь переговорку – бесконечная череда звонков, митингов, встреч: с разработчиками, с аналитиками, с QA, с другими проектными менеджерами, и с клиентами, конечно же! А ведь потом результаты митингов должны быть обязательно задокументированы и отработаны (см. п.1 про документирование!) – иначе митинг прошел впустую.

Клиенты могут находиться в разных часовых поясах, а значит и PM-у приходится подбирать более удобные варианты, чтобы состыковаться с клиентом – рано утром, в обед, отменить “silence day” и т.д. Такова специфика.

И даже неисправимые экстраверты в какой-то момент могут спечься от такого объема общения.

3. Стрессы

Управление проектами – это работа с людьми. Много работы с разными людьми. У всех стейкхолдеров свои интересы, которые не всегда совпадают с интересами проекта, твоей компании. Общаться приходится много, очень много (см. п.2 про общение). Значительная часть общения проходит в виде дискуссий, обсуждений, убеждения, разрешения противоречий и поиска конструктивного решения – и это нормально, это специфика!

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

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

4. Типичность задач

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

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

5. Мало техники и технологий

Если брать ИТ в целом, то PM-ский трек – это один из самых «неайтишных» треков в принципе.

С разработчиками, админами и DevOps все понятно.

С тестировщиками и QA, в принципе, тоже: даже «мануальщики» с какого-то момента начинают работать с БД, разбираться с SQL-запросами, с XML/YAML и прочими конфигами, возможно, кто-то даже успевает познакомиться с service discovery и контейнеризацией/оркестрацией, потихоньку двигаются в сторону кода и автоматизации тестирования (а то и разработки!), изучения различных технологий.

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

Меня все большее отдаление от «техники» вводило в печаль.

6. Неуниверсальность, заточка под предметную область

PM хорош, когда он может достойно представить компанию в общении с клиентом и качественно вести проект. Сильный аналитик не всегда будет рядом, поэтому глубокое знание предметной области – обязательный аспект квалифицированного проектного менеджера в моем понимании. Однако, как показывает практика, такая глубокая заточка под конкретную предметную область со временем снижает ликвидность специалиста на рынке труда. Компании из финтеха охотнее возьмут на рынке PM-а с опытом в финтехе, нежели во внедрении СЭД или геймдеве. В то же время компании из области автоматизации специфических бизнес-процессов зачастую сознательно ищут специалистов с такой узкой экспертизой, чтобы максимально эффективно решать свои бизнес-задачи. Более, того, порой взять «джуна» или стажера и обучить его своей предметной области с чистого листа, либо взрастить PM-а внутри компании из QA или разработчика – проще и эффективнее, а иногда и вообще единственный реалистичный сценарий, если домен компании сложный или уникальный.

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

7. Мало вариаций карьерного развития

Наблюдения показывают, что у PM-ов не так много вариаций для карьерного развития. Самый вероятный кейс со следующей ступенькой - портфельный менеджер (управляет портфелем проектов). Еще менее техническая ступень.

Куда дальше? Возможно, дальше в руководство (руководитель проектного отдела, направления, R&D подразделения, позиции С-уровня и т.д.).

Возможно также переквалифицироваться в продакт-трек, если наработана сильная экспертиза в продукте и бизнес-домене.

Кстати, интересный топик, с радостью почитаю в комментариях про альтернативные кейсы.

О плюсах быть PM-ом в сравнении с разработчиком, а также о плюсах и минусах быть разработчиком я напишу ниже в разделе «Результаты», это будет наиболее логично – т.к. на этом этапе у меня уже будет опыт нахождения «по обе стороны баррикад».

Путь в разработчики

Важно отметить, что, хоть я и «свитчер», однако «свитчер» в рамках ИТ-сферы. Т.е. у меня уже была университетская база из области Computer Science, были базовые знания по компьютерным технологиям, базам данных, сетям, алгоритмизации, и даже небольшой опыт в работе с C-подобными языками программирования. А также, благодаря 6 годам на тот момент опыта в ИТ (как QA и PM), у меня уже было в целом неплохое понимание организационных нюансов и построения процессов разработки.

Технические шаги

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

В качестве целевого языка я выбрал Java. Причины:

1. Не хотелось на первом этапе радикально менять бизнес-домен, а разработка под корпоративного заказчика – это зачастую именно Java.

2. Высокий спрос на «джавистов» по результатам исследований различных карьерных порталов.

3. Предположил, что после Java будет проще «расширять полянку» путем изучения родственных Kotlin, C++ с возможностью поизучать языки в сравнении, с возможностью поменять бизнес-домен и т.д.

4. В компании, где я трудился PM-ом, – отличная Java-экспертиза, всегда можно было обратиться к коллегам за советом.

Как изучал язык:

1. Штудировал книги Герберта Шилдта «Java. Полное руководство» и Брюса Эккеля «Философия Java».

2. Параллельно с чтением книг проходил Javarush. Читал диаметрально противоположные отзывы об этом ресурсе. Лично мне ресурс понравился своим структурированным подходом и постепенным нарастанием сложности. Докачался на нем до 30 уровня, а потом получил оффер в компанию и забросил ресурс.

3. Работал над pet-проектом.

4. Летом 2021 года мой университетский друг (Коля, привет!) подкинул мне идею поступить в Лабораторию EPAM, которая на тот момент еще была открыта в Санкт-Петербурге. Поступил, занимался с июля по ноябрь 2021. Но подробнее о Лаборатории – ниже.

Про EPAM

Кто-то из друзей друга Николая закинул мое резюме в Лабораторию. Из Лаборатории мне позвонили и пригласили позаниматься, если пройду входной отбор. Условия были очень заманчивые – занимаюсь бесплатно и в то же время не обязан по итогам обучения устраиваться в штат к EPAM. Прошел входное техническое тестирование, техническое собеседование и тест на знание английского языка (3 составляющие отбора). Заниматься можно было гибко – вечерами после работы и по выходным. Каждый день были митинги с командой для «сверки часов». Мы в команде из таких же студентов Лаборатории занимались учебным проектом – писали на Java наколеночную имитацию банковских процессов с использованием сервлетов, JSP, Spring, Spring Boot, PostgreSQL. Процесс разработки был построен по Agile. Доступы к корпоративным системам предоставлялись. Это был отличный опыт – поработать с незнакомыми людьми под руководством опытных менторов – действующих разработчиков EPAM. Что касается времени – как правило у меня были свободные часы с 22:00 до 01:00 по будням, а также мог посвещать занятиям выходные – в это время я и занимался в Лаборатории. Заниматься в EPAM я прекратил, потому что получил оффер на должность джуна-разработчика из компании, в которую и трудоустроился.

Организационные шаги

Я понимал, что ухожу с senior-позиции на junior-позицию. Поэтому держал в уме временную просадку по финансам. Определенные опасения, конечно же, у меня присутствовали. Однако я решил, что грамотное планирование может снизить любые риски и способно решать любые задачи - поэтому к моменту Х по максимуму была рефинансирована ипотека, отданы все долги, подготовлена хорошая подушка на 1,5 года безработной жизни семьи.

Дауншифтинг

Многие спрашивают, а не дауншифтинг ли это был?

Если рассуждать с точки зрения позиции и должности – определенно, дауншифтинг. Я уходил с senior-позиции на junior-позицию, зона ответственности и масштаб принятия решений существенно схлопывались. Но, как показала практика, не надолго :) Примерно через год трудоустройства зону ответственности удалось существенно расширить, но это уже тема для отдельной статьи.

Если рассуждать с точки зрения финансов, в моем случае – дауншифтинг, но временный. На горизонте нескольких месяцев финансовый гэп удалось закрыть и решить все финансовые задачи.

Результаты

От идеи стать разработчиком до заветной должности «младшего инженера-программиста» мне пришлось пройти путь в 1,5 года. Возможно, кому-то это покажется слишком долгим промежутком времени. Однако в моем случае мне удалось относительно безболезненно для здоровья и ментального самочувствия совмещать основную работу, подготовку к переходу в разработчики, и даже автошколу, стараясь не забывать о семейных делах типа ремонта.

Признаться, в последние месяцы было очень непросто. Начиная с июля 2021 у меня практически не было времени на отдых – по будням я работал на основной работе, в остальное время занимался в Лаборатории EPAM, продолжал решать задачки на Javarush, читал Эккеля, занимался домашними делами. Конечно, долгое время в таком ритме жить сложновато, поэтому, оглядываясь назад, я бы заложил больше времени на подготовку и готовился в более щадящем режиме в последние месяцы. Девиз «лучший отдых – это смена рода деятельности» способен приносить плоды, но не при игре вдолгую :)

Вот уже 2 года я работаю на dev-позиции. За это время удалось продвинуться где-то до «middle+» грейда в конкретной компании. На данный момент также лидирую один из проектов компании, закрываю в рамках него вопросы технической реализации – по-простому говоря, представитель от технической команды, в т.ч. в работе с клиентом.

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

Плюсы быть разработчиком

1. Мало работы с документами

Повседневной работы с документами в том объеме и формате, как в бытность PM-ом, практически нет. А если и есть, то это зачастую чтение требований и ТЗ, в целях их реализации в коде.

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

Но это очень нечасто, а технический характер таковых статей даже добавляет интереса и позволяет лучше систематизировать знания. Потому что «передавая знания другим, обучаешься сам»!

2. Мало звонков и митингов

Звонков и митингов стало на порядок меньше. А те, что есть, в основном носят технический характер.

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

Таким образом высвободилось значительное количество времени на так называемую deep work – неотрывную работу с глубоким погружением. Иногда удается практически без отрыва погружаться в сложные задачи на день-два.

3. Стрессы

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

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

На дальней дистанции меньшее количество работы типа «человек-человек» свело количество стресса до минимума.

4. Разнообразие задач

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

Возможно, когда-то этот поток уникальных и интересных задач и исчерпается – однако, с учетом стремительного развития технологий, горизонта я пока не вижу. Либо в этот момент необходимо будет уже готовиться и двигаться в архитекторы, например :)

5. Много техники и технологий

Техники и технологий – много. Они разнообразны и повседневны. Более того, постоянно находится что-то, чего ты не знаешь, что предстоит изучить и освоить.

6. Универсальность, мало зависимости от предметной области

Если основные козыри PM-а – это его знание предметной области и софт-скиллс, то ключевой инструментарий разработчика – это его хард-скиллс и софт-скиллс. Знание предметной области, безусловно, будет плюсом для разработчика при продвижении внутри компании. Вместе с тем, говоря о продвижении посредством смены компании, судя по опыту моих знакомых разработчиков и моему собственному, на собеседованиях разработчиков интервьюеры чаще всего заинтересованы именно в широте технического мышления, в готовности к решению нестандартных задач, в первую очередь технического характера. И, конечно же, в таких уже «маст-хэв» софт-скиллах как разумная инициативность, умение работать в команде, конструктивность, ориентированность на развитие и т.д.

Мой предыдущий опыт и бизнес-домен особо никого никогда не интересовал, и в рамках собеседований мы никогда не возвращались к бизнесовым вопросам после моего краткого представления.

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

7. Много карьерных путей

Вариаций карьерного развития из разработчика я вижу множество, например:

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

• Идти в тим-лиды и тех-лиды;

• Развиваться в сторону архитектуры и solutions-направления;

• Идти в PM-ский трек, либо в продакт-трек, либо в работу с клиентом в роли account-менеджера и т.д.;

• Расти дальше в сторону менеджерских позиций а-ля руководитель R&D, PMO и так далее;

• Остаться разработчиком, но перейти в другую сферу разработки или на другой технологический стек;

• Перейти в смежный технологический трек – автоматизация QA, DevOps, data-science, а хороший разработческий бэк-граунд должен ощутимо помочь в этом.

Тут я пока окончательно не определился. Ближайшая цель - дорасти до senior-а, а там скорректирую план.

Плюсы быть PM-ом (или по чему я скучаю из PM-ской жизни)

1. Больший объем влияния на результат

Будучи PM-ом величина влияния, так называемый «импакт», на проект, на тот или иной вариант реализации какой-нибудь функциональности существенно выше. От твоего решения может зависеть, как та или иная фича будет выглядеть в проде, как ей будут пользоваться конечные потребители.

Также у PM-а короче «плечо» взаимодействия с руководством, в т.ч. с руководством компании (зависит от величины компании), что предоставляет возможность непосредственно участвовать в принятии и реализации значимых решений в масштабе не только проекта, но и компании в целом.

У среднестатистического разработчика, конечно же, величина «импакта» ощутимо ниже.

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

2. Командировки

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

Полезные PM-ские скиллы в бытность разработчиком

За время работы разработчиком отмечу, что и предыдущий опыт работы PM-ом оказался очень полезен:

• Во-первых, работа PM-ом научила смотреть за пределы технических рамок реализации задачи, делая упор в первую очередь на потребности и нужды бизнеса и клиента;

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

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

«Вредные» PM-ские привычки

Став разработчиком, очень важно избавиться от некоторых «вредных» привычек из прошлой жизни. И в первую очередь – оставить попытки контролировать весь процесс! Теперь это не в вашей зоне ответственности.

Дайте PM-у и другим специалистам сделать свою работу. Не нужно подстраховывать их на каждом шагу. Не нужно пытаться подстелить всем соломку на регулярной основе. Понятно, что в критические моменты и иногда такая помощь как «организовать митинг», «превентивно сходить к QA и попросить заранее проверить какие-то конкретные кейсы», «проконтролировать, что специалисты поддержки правильно применили инструкцию», «уточнить у PM-а, а точно ли подсветили клиенту, что...» – это полезно. Однако делать это на постоянной основе не стоит – сфокусируйтесь на своей зоне ответственности и не мешайте людям делать свою работу.

Лично мне это на первых порах очень мешало, я никак не мог отпустить ситуацию и не пойти к кому-нибудь со своими «подстраховочными» советами и комментариями :)

Персональные открытия в части деятельности разработчика

Поработав разработчиком, начинаешь более ясно понимать:

1. Почему важно своевременно работать с техдолгом и почему время от времени на эту работу необходимо выделять ресурс;

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

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

4. Как важно уделять должное время архитектурной проработке решения на ранних стадиях.

Рекомендации по процессу перехода в разработчики

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

Какие основные советы и рекомендации я бы дал по итогам своего «проекта по переходу в разработчики»:

1. Если есть желание – пробуйте! Ваше желание в данной ситуации – это самое главное. А все остальное – лишь контекст, который можно планировать, и риски, которыми можно управлять.

2. Не бойтесь финансовых последствий – планируйте их и управляйте ими. Грамотно распланируйте свои финансовые поступления и траты на период подготовки и на период переходного этапа. Сформируйте комфортную подушку безопасности – минимум на полгода-год безработной жизни. Да, наверняка, процесс перехода из-за этого растянется, зато у вас появятся личные и семейные финансовые гарантии.

3. Не рубите с плеча и не бросайте все, уходя в неизвестность. Помните: сначала новый оффер на руках – потом увольнение!

4. Не отчаивайтесь, если вам отказали уже несколько десятков раз. Я тоже получил оффер, наверное, после сотни отправленных резюме (из которых ответили хорошо если на 20, притом позвали на собеседование всего лишь около 5-7 раз). В конце концов каждое собеседование – это хороший источник материала для подготовки к следующему собеседованию :)

5. Дисциплина и постоянство – основа подготовки.

В наставлениях самураям «Тикубасё» сказано:

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

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

Пробуйте, планируйте – и при должном старании и усердии у вас все обязательно получится!