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

Более того, когда я смотрю на распределение своего рабочего временя, я понимаю что себе я могу оставить очччень маленькую часть работы (как девелопер).

В чем мы похожи - меня тоже посещают вопросы, на своем ли я месте? Туда ли я влез? Не лучше ли перейти обратно в чистый девелопмент?
Думаю, не нужно. Мне нравится эта область деятельности, но есть много проблем с текущими активностями (одна из острых, к слову, описана тут). С контролем тоже проблема... Много проблем.

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

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

Если же тебе все таки придется дальше продолжать, то надо бы немного подковаться. Ты читал "Как пасти котов"? Если нет, рекомендую начать с этой книжки.

да, еще. это в корне неверно. С заказчиком должен работать аналитик или менеджер. В проекте должен быть single point of contact для заказчика. 

А как же Agile и прочие XP? 
По крайней мере XP предполагает наличие рядом заказчика. Чуть ли не за одним компом сидеть предлагается
Или я что-то не правильно понимаю?


Это сообщение отредактировал(а) sandello - 14.4.2008, 16:38

А вы используете Agile методологию для разработки? Если просто дать девелоперам общаться с клиентом, будет хаос   

Там смысл в том, что заказчик является частью команды, но все равно должен быть кто-то, кто с ним общается.

Понятия не имею, что мы используем  
Как раз пытаюсь разобраться, как надо и навести порядок. Хаос я уже получил.
Идеологически мне близок процесс, описанный Ларманом. А что такое Agile - я еще не разобрался.

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

но все равно ИМХО ты должен быть спецом своего дела, но надо знать ньюансы: платформ, возможностей и т.д. для более оптималного описания проекта!

Хочу уберечь сразу от неверных суждений. IT руководитель, будь то менеджер проекта или IT-Директор не обязаны быть профессиональными программистами в прошлом. Это, к сожалению, совковый подход: начальник цеха - лучший токарь.

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

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

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

Можно для начала закончить курсы по управлению проектами, например, такие:
http://veulearning.com/courses/procurement...-effectiveness/
В процессе мысленно применять информацию к тем проектам, которые в твоем поле зрения на работе. Думать, как бы ты вышел из этой ситуации, как бы поступил в той. Наблюдать, как это делают другие, и что можно было бы сделать иначе. Использовать любую возможность набраться опыта. Ну и тд ))) Удачи!

Так прикольно читать форум разработчиков 
Я и не думал, что вы в некоторых вопросах завидуете нам, менеджерам.
Очень многие менеджеры завидуют вам по многим факторам, включая по зарплате, а вы завидуете нам 

Но если хотите стать менеджером, то сначала, все таки нужно учиться и я приглашаю вас на 7 поток курса "Управление проектами" http://kursrik.ru/pm

Если что, спрашивайте, готов ответить по всем вопросам 

ИМХО на другом берегу трава всегда зеленее =)

програмеры завидуют манагерам, манагеры завидуют програмерам.

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

Завидовать - нет. Но есть как минимум один фактор, который у менеджеров гораздо менее ограничен - это рост. Менеджер более-менее универсален, может менять отрасль, искать работу менеджера более высокого уровня и т.п. Разработчик не ограничен в росте "вширь", но с вертикальным - есть потолок.

Не соглашусь с вами.
Есть заработчик -ведущий разработчик - тимлид - технический директор
Между прочим, тимлид и технический директор это топовые позиции в компании и для того, чтобы вырасти до этих позиций, нужно иметь компетенции руководителя тоже.
Именно исходя из этого мы и сделали курс для тимлидов http://kursrik.ru/courses/teamlead/ 

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