Здравствуйте, CEMb, Вы писали:
CEM>Я тут (будучи вроде программистом) работал менеджером проекта, извлёк довольно интересный опыт: CEM>- Руководитель проекта не должен вообще лезть в технические детали проекта. Звучит парадоксально, да?
Вот как раз я слышал, что есть 2 точки зрения:
-тимлид занимается только менеджерскими вещами
-тимлид пишет код
И еще:
-тим лид 70% времени занят налаживанием отношений, связей с коллегами вертикально(так понял, боссом и бизнесом), горизонтально(так понял с такой же должностью)
CEM>Лучше быть экспертом, чем не быть, но что нужно бизнесу — вам никто не скажет. Бизнес делается так: CEM>1. Вы садитесь и за 2 недели делаете прототип. Если вы не смогли сделать за 2 недели прототип — повод серьёзно задуматься о пробелах в технической области.
Меня больше интересует опыт разработки долгоиграющих корпоративных приложений. Где выстроенный бизнес. Где на заведение очередной фичи, релиза нужно согласование. Где уже нет прототипов, а есть поддержка и развития надежного продукта. У вас есть такой опыт? Могли бы поделиться, какие в этом случае приоритеты, особенности?
Про записывать. Записывал. Выходило с точностью до минуты записей 12(переключений контекста) чем занимаюсь в день(плюс перерывы на обед, разминка, общение с семьей по телефону).
Получалось, что очень много текущих дел, переписок, вопросов поддержки разноплановой инфраструктуры(попыток выяснить как оно там работает и почему сейчас что то отвалилось) и немного разработки. Совсем чуть-чуть.
A>Вот как раз я слышал, что есть 2 точки зрения: A>-тимлид занимается только менеджерскими вещами A>-тимлид пишет код
тимлид всё равно должен хорошо врубаться в код и ревьювить его весь, даже если не пишет
A>Меня больше интересует опыт разработки долгоиграющих корпоративных приложений. Где выстроенный бизнес. Где на заведение очередной фичи, релиза нужно согласование. Где уже нет прототипов, а есть поддержка и развития надежного продукта.
там все равно есть прототипы, постоянно и много, потому что всё время решается вопрос, куда дальше идти — просто приходится делить время между ними и поддержкой
если вдруг этот процесс останавливается — продукт перешел в стадию умирания
Здравствуйте, avovana, Вы писали:
A>Вот как раз я слышал, что есть 2 точки зрения: A>-тимлид занимается только менеджерскими вещами A>-тимлид пишет код
Тимлид пишет код. Тимлид это самый хороший технический специалист в команде разработчиков. Программист-лидер. И это надо использовать по максимуму: он занимается только техническими вопросами.
Менеджерскими вещами занимаются специально выделенные люди, чтобы технари не отвлекались.
A>-тим лид 70% времени занят налаживанием отношений, связей с коллегами вертикально(так понял, боссом и бизнесом), горизонтально(так понял с такой же должностью)
Нет, надо разделять. Отношениями занимается кто-то, только не тимлид, у него и так дел много.
У нас на прошлой работе был отличный тимлид-архитектор, и он сильно страдал, когда у нас одно время не было менеджера проектов, потому что всё это свалилось на него — вот такого быть не должно. Но как тимлид, он всегда участвовал в переговорах с другими отделами и начальниками по техническим вопросам, если это можно назвать налаживанием отношений.
A>Меня больше интересует опыт разработки долгоиграющих корпоративных приложений. Где выстроенный бизнес. Где на заведение очередной фичи, релиза нужно согласование. Где уже нет прототипов, а есть поддержка и развития надежного продукта. У вас есть такой опыт? Могли бы поделиться, какие в этом случае приоритеты, особенности?
Есть опыт, но вопрос сильно абстрактный, и я работал в стане программистов, поэтому у меня было своё видение, как надо развивать продукт, оно не совпадало с правильным
А вообще всё было устроено так:
1. За приоритеты по развитию отвечают аналитики. Это люди, которые общаются с пользователями/заказчиками и вырабатывают концепции, как оно всё должно работать. С другой стороны они общаются с архитекторами/тимлидами на тему возможностей реализации, как лучше сделать, и так далее. На основе этого аналитики создают задачи. Аналитики должны обладать базовыми техническими знаниями по своим продуктам, чтобы отсекать сразу задачи типа "хочу квадратные колёса". Сейчас завели ещё такую должность, как Product Owner, эээ… я слаб в определениях, но это больше похоже на аналитика с уклоном в сторону пользователя и ограничением на конкретные продукты(типа, как заказчик, но внутренний и умный). Тогда как аналитики работают со всем спектром продуктов и потоковом режиме. Как-то так.
2. Техподдержка. Эти ребята формируют второй поток задач, исходя из багов, недоделок и пожелалок, проводят анализ по критичности.
0. Вот тут вступает в работу менеджер проектов, который разгребает эти два потока, определяет приоритеты, общается с разрабами, формирует графики релизов, бодается с начальством и заказчиками на счёт критичности/актуальности сроков и очерёдности. Он же следит за процессом разработки и сроками, за отношениями в команде, решает вопросы, не связанные конкретно с техническими проблемами.
Так у нас было на прошлой работе. Теперь всё несколько иначе.
A>Получалось, что очень много текущих дел, переписок, вопросов поддержки разноплановой инфраструктуры(попыток выяснить как оно там работает и почему сейчас что то отвалилось) и немного разработки. Совсем чуть-чуть.
У нас на прошлой работе давали такие советы: отключать (рабочий) телефон и (рабочую) почту на конкретные часы. Предупредить коллег об этом. А потом у нас было даже примерно так: 4 дня работы, 5-й день на разгребание каких-то сопутствующих вопросов.
Здравствуйте, avovana, Вы писали:
CEM>>Я тут (будучи вроде программистом) работал менеджером проекта, извлёк довольно интересный опыт: CEM>>- Руководитель проекта не должен вообще лезть в технические детали проекта. Звучит парадоксально, да?
A>Вот как раз я слышал, что есть 2 точки зрения: A>-тимлид занимается только менеджерскими вещами A>-тимлид пишет код
Доводилось сталкиваться с двумя подходами к роли/должности "тим-лидер":
1. Наиболее распространенный. Тим-лидер -- это признанный (в том числе и на административном уровне) лидер небольшой команды разработчиков более-менее одинаковой специализации. В прошлом (и отчасти в нынешнем) опытный и хорошо зарекомендовавший себя программист, под которого (вокруг которого) и была образована команда. Основная ответственность -- это обеспечение высокого качества технических решений для задач, которые возлагаются на команду. Способ достижения -- распределение этих самых задач между членами команды, контроль за их выполнением, помощь при выполнении, обучении и поддержке самых слабых/юных участников. Поскольку основный выхлоп от команды -- это код, то работа с кодом является частью работы тим-лида. Что-то тим-лид может писать сам. Но если в команде 5 и более человек, то на написание кода у тим-лида может не быть времени, больше он будет тратить на чтение и ревью кода, на общение как внутри команды, так вне ее. Как правило, тим-лид не обладает хоть сколько-нибудь выраженными административными полномочиями. Его права и возможности ограничиваются раздачей заданий внутри команды и влиянием на то, что команда выдает как результат своей работы (например, если какой-то из участников команды заявляет, что такая-то задача готова, то тим-лид может это заявление отменить, если сочтет, что это не так). Как правило, тим-лиды не распоряжаются бюджетами, не могут напрямую повышать/понижать зарплаты членов команды, не могут своей властью кого-то повысить и т.д. Все это делается опосредовано через вышестоящих менеджеров (т.е. при необходимости кого-то премировать или повысить, тим-лидер договаривается об этом в соответствии с процессами, принятыми в компании). При этом многие тим-лиды и не стремяться иметь эти полномочия (что вообще достаточно характерно для программистов, т.к. многие из них на практике стремяться держаться от менеджерских обязанностей подальше).
2. Довольно редкий, но, тем не менее, встречающийся. Тим-лидер -- это руководитель разношерстной команды, сформированной под решение конкретной задачи. Например, у компании был какой-то продукт, но под некого богатого заказчика было решено сделать кастомную версию продукта именно под этого заказчика. Под это дело выделили проджект-менеджера, которому могли выдать команду аналитиков и команду разработчиков. Проджект-менеджер отвечает за удовлетворение заказчика, сроки и бюджеты, но кто-то должен рулить и самой разработкой. Вот этим как раз и будет заниматься тим-лидер, у которого в подчинении будет сколько-то программистов/тестировщиков/внедренцев, руками которых и будет создаваться кастомная версия продукта. В таком подходе тим-лидер отвечает за то, что и как делает вся команда разработки проекта. Включая и процесс разработки, и процесс тестировани, и процесс внедрения/запуска. Административных полномочий (как и ответственности) у тим-лида в этом подходе будет больше, чем в описанном выше. При этом данная роль очень похожа на роль технического лидера (tech lead). Но, имхо, различия между tech и team lead при этом состоят в следующем:
* роль tech lead-а подразумевает наличие большого проекта с применением различных технологий внутри, реализацией которого занимаются несколько команд. Поэтому tech lead выступает в роли дирижера, который следит за тем, чтобы никто не играл свою собственную игру и все развивалось в одном общем русле. Если же проект небольшой и команда маленькая, то для этого достаточно team lead-а;
* tech lead -- это уже атрибут большой компании с выстроенными процессами, тогда как team lead с широкими административными полномочиями -- это либо признак "небольшой, динамично развивающейся компании" (с), либо же речь идет о какой-то экспериментальной (исследовательской) разработке внутри большой комании (по типу: "стрельнет -- хорошо, нет -- не страшно"). Либо, как вариант, маленькая команда в аутсорсинговой компании, выделенная под небольшого, но выгодного, клиента.
-----
Скорее всего, если речь идет про крупные компании с устоявшимися процессами разработки и большими, давно разрабатываемыми продуктами, то тим-лид -- это хороший разработчик, вокруг которого есть команда, и этот разработчик все еще работает с кодом (хотя не обязательно много программирует сам).
Здравствуйте, avovana, Вы писали:
A>Самому хотелось стать руководителем, называться тем самым популярным и манящим "тимлидером" — зная как правильно налаживать процессы в команде, вести людей говоря о ценностях, помогать и не навязывать мнение, не отнимать самостоятельности и т.п. A>И сейчас, получается, погружаюсь в предметную/бизнес область. Как я понял, это очень важно для правильных решений.
Очень важно. И как только вы начнете постигать тонкости, вы уже не должны быть в роли тимлида!
Иначе вас ждет интересный разворот: вы будете грести за слабых/навеньких кодеров, прорабатывать архитектуру, работать с бизнес-требованиями, думать о высшем благе заказчика больше чем он сам.
В то же время, вокруг вас будет происходить следующее: босс компании, где вы работаете будет спокойно сидеть на марже с вас и разработчиков. Ваш "менеджер" проектов тоже будет получать свой процентный интерес, и при этом гонять кофеек смотря как вы старательно крутите белечье колесо. Архитектора как отдельной должности не будет, как и бизнес-аналитиков. Все вы да вы в должности тимлида.
Абсолютная выгода. Вы, будете выполнять практически всю ключевую для успеха работу за очень скромную плату!
Подумайте, оно вам надо? Если да, то может и стоит попробовать. Но вы должны понимать, что с таким набором качеств и умений вам выгоднее делать свою компанию, за исключением случая, когда ваша работа адекватно оплачивается как: з/п старшего разработчика + з/п тимлида + з/п бизнес-аналитика + з/п архитектора + з/п проектного менеджера.
A>работа адекватно оплачивается как: A * з/п старшего разработчика + B * з/п тимлида + C * з/п бизнес-аналитика + D * з/п архитектора + E * з/п проектного менеджера.
ты коэффициенты потерял — какую часть времени тратить на работу в определенной должности
понятно что если такой чел будет работать просто за среднюю по рынку, то он сам себе злобный папа карло, но и складывать все зарплаты вместе тоже неверно.
Здравствуйте, Muxa, Вы писали:
M>понятно что если такой чел будет работать просто за среднюю по рынку, то он сам себе злобный папа карло, но и складывать все зарплаты вместе тоже неверно.
Не соглашусь. Если человек один закрывает эти должности с такой же производительностью, как это делали бы отдельные люди, он претендует на соответствующую оплату.
Как пример: работа архитектора к рутине мало имеет отношения, и он может целыми днями ломать голову, но потом за час накидать решение когда оно созреет. Сколько он потратил времени на работу, несколько дней или час?
То, что некоторые "тимлиды" способны дать решение по архитектуре "за час", не значит что они потратили на это только его. Это значит, что они думают и перебирают варианты даже когда спят, едят, дома и по дороге. Такие люди работают головой практически 24 часа в сутки. Но да, "обезьянка" ведь нажимала на клавиши в течение часа, зачем ей платить. Будем эксплуатировать её, а потом выкинем на помоечку когда выдохнется.
