Здравствуйте, Firstborn, Вы писали:
F>Здравствуйте, sharpcoder, Вы писали:
S>>Да, пришлось. 3 года назад был разработчиком, сейчас — управленческая должность, десятки подчиненных. S>>Мотивация — желание развиваться дальше (своего дальнейшего развития как программиста а не видел) и строить карьеру.
F>Хотелось бы уточнить:
F>Почему вы не видели своего дальнейшего развития как программиста?
Было ощущение что как программист и так уже все знаю и умею.
F>Что вы подразумеваете под "развитием" и "карьерой"?
Желание управлять своей жизнью, решать более амбициозные задачи, зарабатывать больше денег, иметь более высокий социальный статус, полчать более высокую отдачу от своих достижений.
E>Ну ... в моем случае TL/PM как раз и выполняет сервисные функции (и это именно обеспечение процесса, основная видимая роль заключается в том, чтобы избавить разработчиков от кучи бюрократии, в результате разработчик может сосредоточиться на работе). TL и PM достаточно легко может быть заменен другим, мало что изменится (отсюда особо много желающих на тимлидство аль ПМство не наблюдается). А вот архитектора и ведущих разработчиков (даже ведущих тестеров) уже заменить безболезненно не получится. И с какой такой кстати один из тимлидов с 5-ю подчиненными будет получать больше или столько же, что и архитектор всей системы, над которой трудится до черта народу из разных стран, на котором вообще все держится и который как раз и принимает ключевые решения, как-то непонятно. Вроде в России нахожусь.
Ваша команда — пример для подражания. Если нетрудно, черкните в личные сообщения, в какой компании и команде вы работаете. Без шуток: очень интересно, где в России уже достигли уровня развития софтверных компаний США начала 90х.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Firstborn, Вы писали:
BZ>>>приходилось — потому, что каждый человек должен отыскать свой уровень некомпетентности F>>Но ведь его можно искать на технической лесенке, либо на менеджерской...
BZ>на технической в нашем городе ничего не отыщешь. тут всего одна фирма делает коробочный софт
Но неужели технический путь развития возможен только в связи с разработкой коробочного софта?..
В нашей стране, например, есть только одна контора, которая этим занимается — но это не значит, что все хотят работать только там.
Здравствуйте, Firstborn, Вы писали:
BZ>>>>приходилось — потому, что каждый человек должен отыскать свой уровень некомпетентности F>>>Но ведь его можно искать на технической лесенке, либо на менеджерской...
BZ>>на технической в нашем городе ничего не отыщешь. тут всего одна фирма делает коробочный софт
F>Но неужели технический путь развития возможен только в связи с разработкой коробочного софта?.. F>В нашей стране, например, есть только одна контора, которая этим занимается — но это не значит, что все хотят работать только там.
но я-то не все понимаешь, когда ты пишешь коробочный софт — ты конкурируешь со всем миром. т.е. ты по самому своему положению вынужден выдумывать нечто новое, чтобы обойти конкурентов. когда ты пишешь заказной софт — ты конкурируешь с несколькими соседними конторами, в лучшем случае. поэтому основной упор идёт на эффективность процесса разработки, на максимальное использование "коробочных" решений. это не творчество, а быстрая сборка домов из готовых кубиков. и совершенствование здесь заключается в изучении номенклатуры кубиков. через несколько лет работы в такой области возникает ощщуение, что ты уже всё изучил, и все новые кубики будут отличаться только наклеенной на них картинкой. т.е. заказная разработка — это денежная, но неинтересная в девелоперском плане работа. вот люди и уходят в менеджеры
Здравствуйте, BulatZiganshin, Вы писали:
F>>Но неужели технический путь развития возможен только в связи с разработкой коробочного софта?..
BZ>но я-то не все понимаешь, когда ты пишешь коробочный софт — ты конкурируешь со всем миром. т.е. ты по самому своему положению вынужден выдумывать нечто новое, чтобы обойти конкурентов. когда ты пишешь заказной софт — ты конкурируешь с несколькими соседними конторами, в лучшем случае. поэтому основной упор идёт на эффективность процесса разработки, на максимальное использование "коробочных" решений. это не творчество, а быстрая сборка домов из готовых кубиков. и совершенствование здесь заключается в изучении номенклатуры кубиков. через несколько лет работы в такой области возникает ощщуение, что ты уже всё изучил, и все новые кубики будут отличаться только наклеенной на них картинкой. т.е. заказная разработка — это денежная, но неинтересная в девелоперском плане работа. вот люди и уходят в менеджеры
Имхо, всё это врено только в том сдучае, если коробочный софт ты пишешь в роли владельца компании, а не наёмного работника. То есть вы немного путаете разницу "коробочный — заказной софт" с разницей "своё дело — работа на дядю", нет?
Здравствуйте, Firstborn, Вы писали:
F>Имхо, всё это врено только в том сдучае, если коробочный софт ты пишешь в роли владельца компании, а не наёмного работника. То есть вы немного путаете разницу "коробочный — заказной софт" с разницей "своё дело — работа на дядю", нет?
не вижу никакой связи с директорством. вот смотри — есть у нас некая цнукциональность, которую легко добавить в программу, и есть, над которой нуждно поработать. менеджер заказной программы говорит:
— ага, вот то что попроще добавь — коиенты будут визжать от восторга, а что посложнее — фиг с ним, это не настолько изменит value программы, чтобы корячиться над этим год
что говорит менеджер прогораммы, конкурирующей на мировом рынке:
— то что попроще добавь конечно, но это и другие 100 наших конкурентов добавят без проблем. а ты вот сделай что-нибудь такое посложнее, на годик, чтобы большинству из них это было просто не по средствам, а оставшиеся от нас хотя бы на год отстали
т.е. ключевой фактор — с кем ты конкурируешь. чем выше планка твоего босса, тем более сложными вещами тебе придётся заниматься. можешь это рассматривать в качестве критерия принятия работы, если ты конечно стремишься к тому роду технического совершенства, которое выражается не в объёме заученных спецификаций
