Из PM-ов в разрабы. Шаг назад для продвижения вперёд
Вступление
Меня зовут Илья, и 2 года назад я из проектных менеджеров в ИТ (они же PM-ы) переквалифицировался в Java-разработчики. Так получилось (как ни странно), что бОльшую часть круга моего общения составляют ИТ-шники. И, наверное, в 99% случаев обсуждения карьерного трека за кружкой пива/кофе многие удивленно спрашивают меня: «Ничего себе? Из PM-ов в разрабы? Какой редкий кейс! А почему? А ведь обычно наоборот — из разрабов в PM-ы? А это дауншифтинг или нет?». Такое количество вопросов и интерес к этой теме навели меня на мысль написать статью о том, как я «докатился до разработческой жизни» из PM, что меня сподвигло, чем руководствовался. Так что, если и вас одолевает подобный интерес, смело читайте далее!
Цели
Для чего я пишу эту статью:
Во-первых, интересно познакомиться с коллегами с аналогичным или похожим опытом, которые тоже «перепрыгнули» из PM-ского карьерного трека в девелоперский, узнать их мотивацию, применяемые ими подходы.
Во-вторых, хочется дать материал, стартовую точку для тех, кто, как и я, в какой-то момент понял, что сугубо менеджерский трек карьерного развития — это не для него. Чтобы показать, что такое тоже бывает, что это реализуемо и перспективно, и что если вам это интересно — смело составляйте личный план и реализовывайте его!
Небольшой дисклеймер. Все, описанное далее в статье, — мои личные взгляды на работу 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. Причины:
Не хотелось на первом этапе радикально менять бизнес-домен, а разработка под корпоративного заказчика — это зачастую именно Java.
Высокий спрос на «джавистов» по результатам исследований различных карьерных порталов.
Предположил, что после Java будет проще «расширять полянку» путем изучения родственных Kotlin, C++ с возможностью поизучать языки в сравнении, с возможностью поменять бизнес-домен и т.д.
В компании, где я трудился PM-ом, — отличная Java-экспертиза, всегда можно было обратиться к коллегам за советом.
Как изучал язык:
Штудировал книги Герберта Шилдта «Java. Полное руководство» и Брюса Эккеля «Философия Java».
Параллельно с чтением книг проходил Javarush. Читал диаметрально противоположные отзывы об этом ресурсе. Лично мне ресурс понравился своим структурированным подходом и постепенным нарастанием сложности. Докачался на нем до 30 уровня, а потом получил оффер в компанию и забросил ресурс.
Работал над pet-проектом.
Летом 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-а, а точно ли подсветили клиенту, что…» — это полезно. Однако делать это на постоянной основе не стоит — сфокусируйтесь на своей зоне ответственности и не мешайте людям делать свою работу.
Лично мне это на первых порах очень мешало, я никак не мог отпустить ситуацию и не пойти к кому-нибудь со своими «подстраховочными» советами и комментариями :)
Персональные открытия в части деятельности разработчика
Поработав разработчиком, начинаешь более ясно понимать:
Почему важно своевременно работать с техдолгом и почему время от времени на эту работу необходимо выделять ресурс;
Почему разработчики дают такие большие сроки, когда задача выглядит совсем небольшой или, наоборот, почему такую большую бизнесовую задачу разработчики недооценивают и закладывают мало ресурсов. Нюансы, особенности и проблемы оценивания задач предстают более ясно и остро, особенно, когда дашь оценку сам и не уложишься в нее.
Как бы я сам организовал процедуру оценивания задач с учетом понимания потребностей и менеджерской, и девелоперской сторон (но это, явно, не тема данной статьи).
Как важно уделять должное время архитектурной проработке решения на ранних стадиях.
Рекомендации по процессу перехода в разработчики
Как показал личный опыт, сменить род и направление своей рабочей деятельности — это вполне доступная опция, как минимум внутри ИТ-сферы — так точно! По сути все, что для этого нужно — неизменное желание, четкий план, который, конечно же, можно и нужно корректировать с поправкой на меняющуюся ситуацию, а также дисциплина для следования этому плану.
Какие основные советы и рекомендации я бы дал по итогам своего «проекта по переходу в разработчики»:
Если есть желание — пробуйте! Ваше желание в данной ситуации — это самое главное. А все остальное — лишь контекст, который можно планировать, и риски, которыми можно управлять.
Не бойтесь финансовых последствий — планируйте их и управляйте ими. Грамотно распланируйте свои финансовые поступления и траты на период подготовки и на период переходного этапа. Сформируйте комфортную подушку безопасности — минимум на полгода-год безработной жизни. Да, наверняка, процесс перехода из-за этого растянется, зато у вас появятся личные и семейные финансовые гарантии.
Не рубите с плеча и не бросайте все, уходя в неизвестность. Помните: сначала новый оффер на руках — потом увольнение!
Не отчаивайтесь, если вам отказали уже несколько десятков раз. Я тоже получил оффер, наверное, после сотни отправленных резюме (из которых ответили хорошо если на 20, притом позвали на собеседование всего лишь около 5–7 раз). В конце концов каждое собеседование — это хороший источник материала для подготовки к следующему собеседованию :)
Дисциплина и постоянство — основа подготовки.
В наставлениях самураям «Тикубасё» сказано:
В этом переменчивом мире наш путь — это путь дисциплины. Так уж устроен наш мир, что даже одно из десяти наших желаний не сбывается так, как мы бы этого хотели. Наверное даже у Императора не все получается так, как ему хотелось бы.
Составить план действий относительно просто — сложнее находить в себе волю и самообладание изо дня в день, из месяца в месяц регулярно следовать ему, анализировать эффективность, корректировать план, чтобы достичь поставленных целей. Однако дисциплина приносит плоды, потому что организация всегда бьет талант, если талант не организован должным образом, конечно :).
Пробуйте, планируйте — и при должном старании и усердии у вас все обязательно получится!
