Переход из разработчика в аналитика/архитектора/руководителя проекта. Каковы плюсы и минусы?

Question

[oleg_vd]

В каких случаях и на каком этапе карьеры разработчику стоит задуматься о переходе в:
1) Аналитика
2) Архитектора
3) Руководителя проекта
Какие плюсы и минусы у каждого из вариантов?
Особенно интересно послушать ответы тех, кто совершал прямой или обратный переход.

Answer 1

[Валентин]

2) Архитектора

Толковый архитектор по сути технический (ну или продуктовый) РП. Остальное - просто проектировщик.

3) Руководителя проекта

Когда надоедает смотреть, как ломаются и мухлюют менеджеры.

Какие плюсы и минусы у каждого из вариантов?

Аналитики слишком разные бывают и у всех все по разному. А на счёт РП и Архитектора готовьтесь к тому, что будете в рабочее время только сидеть на ВКС или на очных встречах, а непосредственную работу делать после рабочего времени. Также предстоит очень много читать (нормально, если читаешь 100-150 страниц в день). Ну и умение планировать задачи, добиваться их выполнения от совершенно рандомных людей, с вами никак несвязанных.

Answer 2

[Иван Шумов]

Ну, сам просил)

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

Во-вторых, надо ответить на вопрос "а чего я хочу". Без понимания какие активности нравится делать и какие не нравится - все это мука.

В-третьих, какой именно архитектор? Software, System, Solution, Enterprise, Business или какой-то другой? Надо понимать что это одна из самых молодых сфер и нет общего понимания на рынке. Кому-то нужен локальный CTO, кому-то консультант, кому-то прокачанный разработчик, а кому-то вообще pre-sale manager. И это даже по ходу интервью не всегда можно понять верно. Стоит почитать ITABoK хотябы поверхностно.

В-четвертых, а какой аналитик? Их тоже 100500 штук разных и у всех работа своя. Кто-то работает с данными, кто-то с бизнесом и от бизнеса работодателя многое зависит.

Про руководителя проекта это вообще отдельно. Это менеджерская работа и ты ее либо можешь делать или нет.

Вне зависимости от выбора одного из этих направлений обязательно:

1. Желать перевести до 90% своего времени в коммуникацию
   
2. Иметь сильные софт-скилы
   
3. Иметь сильные навыки презентации
   
4. Понять что-такое целеполагание и как достигаются цели
   
5. Перестать делать "работу" и начать слушать бизнес
   
6. Быть про-активным, а не реактивным
   

это я так, самый очевидный список набросал

Answer 3

[Saboteur]

В каких случаях и на каком этапе карьеры разработчику стоит задуматься о переходе в:

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

1) Аналитика

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

2) Архитектора

Желательно после достижения уровня senior

3) Руководителя проекта

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

Какие плюсы и минусы у каждого из вариантов?

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

Answer 4

[xmoonlight]

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

Плюсы-минусы: постепенно забываешь про код и всё, что с ним связано; познаёшь бизнес-требования и бизнес-рынок, учишься общаться с людьми в команде и с заказчиками.
При переходе обратно - всё ровно наоборот.

Answer 5

[Пума Тайланд]

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