-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
То есть программировать придется самому ?
- Автор темы _RVK_
- Дата начала
_RVK_
Новичок
Дело не в этом. По своему опыту знаю что если есть задачи кодинга по проекту, время на организаторскую работу, планирование, архитектурные вещи, контроль качества, мониторниг производительности и тд. остается меньше чем необходимо, от этого страдает проект в целом. Мое имхо что тим-лидер должен быть освобожден от кодинга поумолчанию, хотя конечно часто некоторые архитектурные вещи никто лучше не напишет.а что, не царское это дело?
MiksIr
miksir@home:~$
эээ 
не, пофлудим Придирка не канает менеджеры ставят задачу тим-лидеру и от отвечает за ее исполнение, и с тим лида спросят за срыв срока и его будут штрафовать, если что.
Потому что срыв сроков по разработке - прямая вина тим лида И если тим лид ошибся в своих подчиненных или организаторских способностях или в умении оценивать сроки - значит пусть ночью сам садится и кодит. Этим и отличается тимлид с з/п от 100 от разрабочтика "с 9 до 18" а после хоть подоп за "от 50" =)
"выполнение задачи" - это не кодинг задачи, это процесс приводящий к решению этой задачи В том числе и планирование, QA и прочее
не, пофлудим Придирка не канает менеджеры ставят задачу тим-лидеру и от отвечает за ее исполнение, и с тим лида спросят за срыв срока и его будут штрафовать, если что.Потому что срыв сроков по разработке - прямая вина тим лида
И если тим лид ошибся в своих подчиненных или организаторских способностях или в умении оценивать сроки - значит пусть ночью сам садится и кодит. Этим и отличается тимлид с з/п от 100 от разрабочтика "с 9 до 18" а после хоть подоп за "от 50" =)"выполнение задачи" - это не кодинг задачи, это процесс приводящий к решению этой задачи
В том числе и планирование, QA и прочее 
Что-то вы в другую сторону пошли..
Толковый Архитектор не будет сидеть без дела, иначе у него умрет мозг
Если кто - не знал он тоже мышца
RVK - ты лучше вспомни что было в [цензура] до нашего прихода и как задачи начали
решаться через полгода (особенно время внедрения) :-Ь
Если тимлид не может договорится со своей командой разработки, значит что
он нифига не тимлид - а назначенный начальством смотритель
Толковый Архитектор не будет сидеть без дела, иначе у него умрет мозг
Если кто - не знал он тоже мышца
RVK - ты лучше вспомни что было в [цензура
] до нашего прихода и как задачи начали решаться через полгода (особенно время внедрения) :-Ь
Если тимлид не может договорится со своей командой разработки, значит что
он нифига не тимлид - а назначенный начальством смотритель
MiksIr
miksir@home:~$
Во-первых, кто у тим лида начальник Т.е. это все же вопрос орг структуры и адекватности отдельных людей, а не процесс Ну и потом, почему это у тим лида нет задач? Если тим лид не может написать себе в план задач, то то фиговый тим лид
Да и потом, план - это вообще что? Если вышестоящий (имеется введу не IT) начальник начинает интересоваться внутренним планом выполнения задач внутри IT, а не конечными результатами, то или это хреновый начальник или это хороший начальник понимающий в IT кухне, который не доверяет тим лиду (как правило если это новый человек).
Т.е. это все же вопрос орг структуры и адекватности отдельных людей, а не процесс Ну и потом, почему это у тим лида нет задач? Если тим лид не может написать себе в план задач, то то фиговый тим лид Да и потом, план - это вообще что? Если вышестоящий (имеется введу не IT) начальник начинает интересоваться внутренним планом выполнения задач внутри IT, а не конечными результатами, то или это хреновый начальник или это хороший начальник понимающий в IT кухне, который не доверяет тим лиду (как правило если это новый человек).
StUV
Это еще до тебя было И в другом департаменте. Там вед. программист не знал разницы между одинарными и двойными кавычками. Был мной уволен после аттестации , устроился нач. разработки с 3-мя подчиненными No comments.
А вообще проблема сейчас одна - отсутствие квалифицированных
веб-разработчиков. Вернее их две - если эти разработчики найдены,
они должны быть нацелены на решение бизнес задач, а не на изучение
как нам внедрить новую методику в проект или изучить новый язык программирования. Примеров можно приводить кучу
Это еще до тебя было
И в другом департаменте. Там вед. программист не знал разницы между одинарными и двойными кавычками. Был мной уволен после аттестации , устроился нач. разработки с 3-мя подчиненными No comments.А вообще проблема сейчас одна - отсутствие квалифицированных
веб-разработчиков. Вернее их две - если эти разработчики найдены,
они должны быть нацелены на решение бизнес задач, а не на изучение
как нам внедрить новую методику в проект или изучить новый язык программирования. Примеров можно приводить кучу
_RVK_
Новичок
Начальник обязательно должен интересоваться планом что бы хотя бы быть в курсе дела. Мало того, начальник (или заказчик как хотите) должен сам участвовать в планировании, ибо только он имеет право формулировать задачи и определить приоритет задач.
-~{}~ 09.09.08 19:00:
admin
Под твоим чутким руководством можно и горы свернуть, а не только какой-то там [цензура] поднять
-~{}~ 09.09.08 19:00:
admin
Под твоим чутким руководством можно и горы свернуть, а не только какой-то там [цензура] поднять
MiksIr
miksir@home:~$
Вы смешиваете план выполнения поставленных задач и внутренний план IT отдела - кто что будет делать для решения поставленной задачи.
Если от тим лидера требуют этот внутренний план, типа "вот покажи, кто и сколько времени будет работать из твоих подчиненных над моей задачей и что именно он будет деать", то это уже сигнал - что-то идет не так
Если от тим лидера требуют этот внутренний план, типа "вот покажи, кто и сколько времени будет работать из твоих подчиненных над моей задачей и что именно он будет деать", то это уже сигнал - что-то идет не так
StUV
Rotaredom
тут я с тобой не соглашусь
проектов много разных всяких - а программистов, владеющих всеми необходимыми технологиями, на рынке не так много и они уже "при деле"
если работать с аутсорсерами - тогда да, можно под каждый проект нанимать команду с соотв. опытом и все ОК
или если контора достаточно "толстая" для того, чтобы под каждое проектное направление держать отдельную команду профи нужной квалификации + для новых разработок нанимать новых сотрудников (_быстро_ это сделать - _очень_ дорого) и раскручивать/отбивать новые проекты достаточно быстро
в остальных случаях - дешевле исследовать новые направления, обучать сотрудников (самостоятельно, нанять консультантов, ...)
а у нас этих "остальных случаев" - большинство
--
ну и все зависит от долгосрочности проекта - нормальный программист разбирается с новой технологией/яп за месяц-два фулл-тайм, а на поиск/перекупку такого кадра может уйти пол-года и более
-~{}~ 10.09.08 10:31:
зы: что-то мы зафлудили работу окончательно =)
_RVK_
Новичок
Я ничего не слышал о внутренних планах. Для меня есть планы долгосрочные(квартальные планы, предварительные и тд) и планы итераций. Первый план составляется для заказчика, второй для программистов и заказчиков. Можно конечно планы итераций заказчику не показывать, но опыт показывает что приходится. Приходится потому, что заказчик волен в любой момент изменить список задач, и их приоритет, в руководствуясь своими бизнес-целями. Если сказать ему "Нет, эту задачу мы не сможем выполнить в ближайшие 2 недели так как все распланировано" он не поймет. Поэтому необходимо показать ему план, показать кто и чем занимается, и решить с ним терпит ли задача отсрочки, или её можно всунуть в план, передвинув менее приоритетные задачи на другую итерацию. Эти вопросы может решать только заказчик. Можно конечно составлять два плана, один с именами программистов, другой без, но и этот подход не очень хорош. Не секрет, что каждый программист имеет некую свою специализацию. Один хорошо разбирается в БД, другой в регах, третий лучше всех знает AJAX, и тд. (примеры с потолка конечно), и поэтому тим-лидер обязан предупредить заказчика что эту задачу быстрее всего решит Вася, но Вася занят такой-то задачей, и либо мы ставим эту задачу на Петю (если Васина более приоритетная, а Петина менее), но Петя будет её решать дольше, либо задачу делает быстро Вася, но его текущая задача переносится на следующую итерацию. Как мы видим заказчик должен быть в курсе того, кто чем занимается как минимум. И вот на этом этапе может появится вопрос типа:Автор оригинала: MiksIr
Вы смешиваете план выполнения поставленных задач и внутренний план IT отдела - кто что будет делать для решения поставленной задачи.
Если от тим лидера требуют этот внутренний план, типа "вот покажи, кто и сколько времени будет работать из твоих подчиненных над моей задачей и что именно он будет деать", то это уже сигнал - что-то идет не так
- Ром, давай не будем отвлекать ни Васю ни Петю, а задачу побыринькому решишь ты?
- Дык на мне задачи планирования, надо тут код пооптимизировать, поиск тормозит, нада на Сфинкс переходить....
- Да лан, это менее приоритетно, давай отложим, а то я потеряю много бабла, если задача не будет выполнена, и буду злой очень....
P.S. Может разделить тему?
-~{}~ 11.09.08 12:21:
И вот еще что. Заказчик может решать кто будет выполнять задачу. Только не бросайте в меня помидоры
Щас поясню. Итак идет планирование итирации, все сидят, заказчик обьявляет задачу, Вася грит - я сделаю.
- Вась, ну ты же никогда не занимался этим типом задач, Петя сделает намного быстрее - грит тим-лидер
- Да, но если я не начну, то никогда и не смогу делать задачи подобного типа, а вдруг Петя уволится, или в отпуск уйдет?
- Вась, но ты же все время будешь тормошить Петю, и мешать ему выполнять его задачу.
- Да, конечно, но он в этот момент сможет передать мне свой опыт.
И вот тут в дело вступает заказчик, который должен решить сможет ли он немного подождать воимя будующего более быстрого решения подобных задач, большей гибкости команды, и большей мотивированности сотрудников (ясно что Вася возьмется за новую задачу с большим энтузиазмом, чем Петя у которого подобные задачи уже в печенках сидят). Если задача мегасрочная, то все таки лучше отдать её Пете, а Вася пусть подождет следуюую, или поработает в паре с Петей, что опять же орпделяет заказчик, исходя из приоритетности Васиной задачи....
Вопщем вопрос планирования не такая простая штука....
StUV
Rotaredom
_RVK_
ты щас в какой-то ээ.... специфичной конторе
обычно заказчик до такого уровня не "опускается"
он и Васю с Петей никогда в глаза не видел, и что такое БД и тем-более - кто в ней лучше рубит - ему насрать.
А обосновывать заказчику увеличение сроков временем на обучение Васи/Пети/Коли новым для них технологиям - ваще гиблое дело =)
-~{}~ 11.09.08 15:35:
ps: те обоснования о которых ты говоришь - это и есть обоснования внутреннего планирования и в общем случае оно нужно в рамках проектной команды - т.е. при общении манагеров с технарями
заказчик в этом общении не участвует - он вникает в более крупные итерации, которые не разбиваются на БД/код/кеш/железо и т.п.... - ему интересны "бизнесовые итерации"
ты щас в какой-то ээ.... специфичной конторе
обычно заказчик до такого уровня не "опускается"
он и Васю с Петей никогда в глаза не видел, и что такое БД и тем-более - кто в ней лучше рубит - ему насрать.
А обосновывать заказчику увеличение сроков временем на обучение Васи/Пети/Коли новым для них технологиям - ваще гиблое дело =)
-~{}~ 11.09.08 15:35:
ps: те обоснования о которых ты говоришь - это и есть обоснования внутреннего планирования и в общем случае оно нужно в рамках проектной команды - т.е. при общении манагеров с технарями
заказчик в этом общении не участвует - он вникает в более крупные итерации, которые не разбиваются на БД/код/кеш/железо и т.п.... - ему интересны "бизнесовые итерации"
![Raziel[SD]](https://secure.gravatar.com/avatar/5bcf62e34d3825c80884f57d341fad2a?s=96){kind=avatar}
Raziel[SD]
untitled00
Видимо _RVK_ говорит о внутреннем заказчике, а ты о внешнем.
_RVK_
Новичок
Raziel[SD]
Да, конечно. Я говорю о том кто играет роль заказчика в команде. Это может быть проджект или продюссер. Тот человек кто говрит от лица заказчика.
-~{}~ 11.09.08 16:13:
StUV
Будь это прожект а не сам заказчик, это не важно, он соблюдает в этом случае бизнес-интересы заказчика, и получит по шапке если от босса, если эти интересы соблюдены не будут. В его же интересах интересоваться каждым аспектом разработки, что бы было что ответить начальству когда его спросят "а почему это делается столько то, а не столько то времени". И для того что бы знать ответы на эти вопросы, он должен не просить рассказать об этом тим-лидера когда пятух клюнет (куй че от меня допытается, мне что делать нечего), а сам участвовать непосредственно во всех вопросах планирования задач, быть составной и неотъемлемой частью команды. К сожалению, из за лени, большинство ПМ-ов не делают этого. Они думают что их задача вовремя сказать "сделайте это, и шоб готово было вчера". Они не понимают что все это серьезная и кропотливая работа.
Да, конечно. Я говорю о том кто играет роль заказчика в команде. Это может быть проджект или продюссер. Тот человек кто говрит от лица заказчика.
-~{}~ 11.09.08 16:13:
StUV
Будь это прожект а не сам заказчик, это не важно, он соблюдает в этом случае бизнес-интересы заказчика, и получит по шапке если от босса, если эти интересы соблюдены не будут. В его же интересах интересоваться каждым аспектом разработки, что бы было что ответить начальству когда его спросят "а почему это делается столько то, а не столько то времени". И для того что бы знать ответы на эти вопросы, он должен не просить рассказать об этом тим-лидера когда пятух клюнет (куй че от меня допытается, мне что делать нечего), а сам участвовать непосредственно во всех вопросах планирования задач, быть составной и неотъемлемой частью команды. К сожалению, из за лени, большинство ПМ-ов не делают этого. Они думают что их задача вовремя сказать "сделайте это, и шоб готово было вчера". Они не понимают что все это серьезная и кропотливая работа.