То есть программировать придется самому ?

[StUV]

Будь это прожект а не сам заказчик, это не важно

важно

если эти интересы соблюдены не будут

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

Если обучение заложено в сроки и заказчика эти сроки устраивают - то все ОК.

Но ни тимлид, ни прожект не будут аргументировать заказчику увеличение сроков техническими подробностями или проблемами команды

 

[_RVK_]

StUV
хорошему тим-лиду не придется обосновывать срыв сроков ничем

 

[StUV]

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

-~{}~ 11.09.08 16:42:

_RVK_
я не про срыв
я про планирование _до_ старта, когда не должно быть такого:

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

такие отмазки надо включить в терминологию понимаемую и _принимаемую_ заказчиком, а внутренние итерации его не волнуют

 

[_RVK_]

StUV
Вот пусть идут в ту самую контору.
Сказать я все что угодно могу но по долгосрочным планам я никаких гарантий не даю, ибо долгосрочные планы это сплошная фикция. У меня в штате нет ни одного Настродамуса. Я могу сказать примерное время, расписав задачи "покрупному" но в итоге реальные сроки выполнения конкретных задач разнятся очень сильно. А если совпадают, то это повод задуматься о том, что программер сделал все быстрее, а потом балду пинал.
Такой план конечно нужен, но он нужен не для того что бы показать точные сроки проекта, а для того что бы наметить путь от точки А в точку Б, с указанием всех остановочных пунктов. Это я всегда говорю заказчику сразу, и поэтому претензии принимаю только по краткосрочным планам. А с учетом того, что планы эти составляются и корректируются с участием заказчика (или его представителя), то и претензий не может быть никаких, так как все изменения плана происходят, в том числе и с его согласия.
Никакие пункты типа "обучение" ни в какие планы не вставляются, просто в зависимости от необходимости обучения корректируются сроки задачи изначально. Программист эти сроки называет сам, при всех остальных коллегах, в том числе и при заказчике, и если ему под эти сроки дается задача, то оправдываться придется только когда программист в названные им сроки не укладывается. Но при должном контроле нарушение сроков выявляется еще в ходе плана, и план корректируется исходя из текущих реалий. Вот так.

-~{}~ 11.09.08 17:11:

Да, и самое главное, сидеть по субботам/ночью и кодить из-за нарушения сроков это нонсенс при таком подходе. Если сроки горят, и об этом стало известно только сейчас, то возникает вопрос за что я зарплату тогда получаю?

 

[MiksIr]

План итераций? Вы про то, какие задачи будут взяты и сделаны, т.е. про Sprint backlog терминологией скрама? А где там место программистам? Заказчику, внутренний он или внешний, нужно знать одно - когда его задачи будут сделаны и как качественно. Кто конкретно над какой задачей трудится, что делает - программит, проектирует... да не волнует его.
А уже внутри команды это решайте на основе любой методики - хотите, тимлид распределяет, хотите - скрам.
Если вы показываете заказчику кто над какой задачей будет работать.. хм.. ну тогда это ваши проблемы, не нужно их делать общественными

-~{}~ 11.09.08 17:38:

Автор оригинала: StUV
тут я с тобой не соглашусь
проектов много разных всяких - а программистов, владеющих всеми необходимыми технологиями, на рынке не так много и они уже "при деле"

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

 

[_RVK_]

MiksIr
Пример такой. Дает тебе заказчик список задач, и грит, вот когда будет сделано?
- Через месяц
- Ок.

Приходит через неделю и грит

- Черт, ситуация на рынке изменилась, надо срочно делать вот такую шпуньку
- Дык все заняты.
- Отвлеки, надо сделать быстро.
- Ок

Приходишь к команде,
- Вася, бросай все, делай эту задачу.
- Ок.

Через месяц заказчик:
- Почему не сделали вот эту задачу, ты же обещал
- Дык мы делали мегаприоритетную задачу
- А почему эту не сделали, она тоже мегаприоритетная
- Так я дал задачу тому кто с ней быстрее и лучше справится, поэтому свою изначальную задачу он не успел....
- Ептильмоптиль, а почему ты выбрал эту мегаприоритетную задачу? Я потерял куча бабла, ты уволен!

Вот что получается когда заказчик не учавствует в планировании.

И заметьте, я под словом "заказчик" понимаю конечно не призедента корпорации, а его представителя, менеджера, маркетолога или ответственного. И чем тогда должен заниматься проджект менеджер, если не тем о чем я говорю?

 

[MiksIr]

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

Только причем тут раскрытие заказчику информации кто чем занимается? Напомню, изначально вы сформулировали "Начальник может посмотреть в план (его полное право), заметить что на тебе не стоит ни одной прикладной задачи, и полоскать тебе мозги, типа если бы ты кодил, могли бы сделать больше.".

 

[_RVK_]

MiksIr
Повторяю, под словом "заказчик" я понимаю проджект-менеджера. Или такой штатной единицы у вас нет? Если нет, все понятно. Если есть, тогда чем он занимается?

От первоначальной темы мы немного ушли, сознаю.

-~{}~ 11.09.08 18:19:

Кситати, Тим-лид не должен ставить задач, это делает проджект-менеджер ("заказчик").

 

[MiksIr]

А что меняется от того, что "заказчик" = "прожект"? Прожект тоже задачи ставит не программистам на прямую, а ставит их тим лиду, верно же? А тим лид уже расставляет задачи по разработчикам.
Вы когда за зарплатой приходите, не требуете же, что бы бухгалтерия отчиталась - какой бухгалтер считал з/п, какой за ней ездил, а какой - пересчитывал.

 

[_RVK_]

А что меняется от того, что "заказчик" = "прожект"? Прожект тоже задачи ставит не программистам на прямую, а ставит их тим лиду, верно же?

Нет неверно. Он учавствует в планировании вместе с тим-лидером, садится вот так рядышком и учавствует вместе со всеми программистами.

А тим лид уже расставляет задачи по разработчикам.

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

Вы когда за зарплатой приходите, не требуете же, что бы бухгалтерия отчиталась - какой бухгалтер считал з/п, какой за ней ездил, а какой - пересчитывал

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

-~{}~ 11.09.08 19:24:

Между прочим это главная беда, проджект скинул задачи тим-лиду и все, считает что работа сделана. Не понимаю кто такое вообще придумал.

 

[MiksIr]

предлагает, и задачи берут те кто хочет поработать над ней.

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

Он учавствует в планировании вместе с тим-лидером, садится вот так рядышком и учавствует вместе со всеми программистами.

И что он там делает? Задача такого человека - правильно проставить приоритеты, проконсультировать моменты по задаче... но никак не следить, что бы все программисты были загружены. Не указывать, кто и что должен прграммить. Опять же, этот человек может участвовать в планерке, если опять про скрам, ибо там нет тимлида... если тимлид есть - он с ним и общается.

Иногда требую, если зп дали неправильно.

Думается, пришли к человеку, который этим занимается и сказали - разберитесь. И он разобрался.
И потом, тут ключевое - сорванная задача. Если IT срывает сроки, косячит в задачах.. то любой руководитель придет и скажет - "что за х". Но это как раз попадает под случай, когда начальство интересуется - недоверие к тимлиду.

 

[_RVK_]

MiksIr
Стыдно не не понимаю что такое "скрам".
Гуглить не пытался ибо не интересно что там таким словом нгазвали. Все сказано выше, проверено, и оно работает очень эффективно. К сожалению, обьяснить почему оно так работает я не могу, ибо нужно пояснить множество как лежащих на виду, так и тонких моментов психологии, связаннных, в том числе, и с мотивацией сотрудников.
Но по моему опыту есть только одна причина по которой данная схема может не работать. Это нежелание проджект-менеджеров шевелить своей толстой задницей и работать так как они должны это делать. Во всем остальном (приходится за проджектов делать их работу, чему они несказанно рады) эта схема оправдала все ожидания, и наоборот, отход от неё ведет к серьезным проблемам. Проверено лично мной. Можете сомневаться в моем опыте, я не напрашиваюсь. Но все же советую прислушаться, авось полезные вещи все таки вразумеете.

 

[MiksIr]

Полезные вещи от человека, который гуглить не пытался, ибо не интересно?
Т.е. вы сами создали такую ситуацию, что прожект не понимает, чем конкретно вы занимаетесь, но видит что не кодите и по-этому очень ругаетесь... потом переживаете из-за этого... а потом советуете другим?
Что то я вас не понимаю... ладно, остановимся на том, что просто не удалось до меня, тупого, мысль донести

 

[_RVK_]

И не удержался, пример работы тим-лида, проджекта и программера
Приходит програмер к тим-лиду, и грит
- Слуш, сказали сделать феньку, но не пойму её гладкой делать или в пупырышках...
- Пойдем к проджекту
Программер спрашивает у проджекта:
- Феньку делать гладкой или в пупырышках?
- Ну в пупырышках будет выгоднее в плване прибыли.....
- А пупырышки делать большие или маленькие?
- Большие конечно!
Тим-лид:
- Большие не получица, сервера загнуца...
- Черт, а как сделать большие и шоб не загнулись?
- Ну можно сделать их синими, тогда не загнуца, или серверов купить но пока купишь пока развернешь...
- Синими некашероно.... но ладно, с серверами решим пока делаем синие пупырышки, потом либо сервера купим, либо поменьше пупырышки сделаем
- Хорошо, я пока еще попробую пооптимизировать, мож придумаю как пупырышки нжинксом раздавать....

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

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

-~{}~ 12.09.08 04:10:

Полезные вещи от человека, который гуглить не пытался, ибо не интересно?

Просто такие вещи описаны в уважаемой литературе, например в книгах по методологии XP, и кто там как и почему назвал потом, это мне не интересно, плагиат знаете ли....

 

[MiksIr]

скрам, это одна из методик XP )) ну вернее, опирается на принципы XP. XP - это скорее к разработке, а Скрам - это ближе к прожект-менеджменту с использованием XP.
А в вашем диалоге то.. зачем программер пошел к прожекту? что бы задать вопрос и постоять, помолчать?

 

[_RVK_]

Что бы не просто спроcить но и уточнить. Он бы мог сделать большие пупырышки, и сервера загнулись бы, или маленькие но заказчик был бы недоволен. А так он знает из первых уст зачем и почему делать их нужно большими и синими, а не красными как казалось на первый взгляд. А так же он понимает что их все равно позже сделают красными полюбому, и он сделает код гибче, что бы внедрение красных пупырышков было максимально простым. И он не будет за бытылкой пива хаить проджекта который, тупой, решил вдруг пупырышки синими сделать (где это видано, синие пупырышки?)

С кажите честно, Вы проджект-менеджер?

 

[MiksIr]

А названия, уважаемый, это как патерны... нужны, что бы на одном языке говорить. Ибо в вашей схеме тим лида нет, команда равноценна.
Так вот, даже в скраме прожект-менеджер (product owner) участвует в митингах... но опять же, его не волнует, кто и сколько будет работат и чем заниматься. Его задача - зная приоритетность задач, помочь составить Sprint backlog - задачи на следующую итерацию, выбрав их из общего списка. Его задача - разъяснять про пупырышки. Его _не_должно_ волновать, что кто будет делать для выполнения задачи.

-~{}~ 12.09.08 04:29:

С кажите честно, Вы проджект-менеджер?

Это так просто, свалить все на пиписьки Ах, ты программист, ну ничего, дорастешь. Ах, ты прожект... и как это вы работаете (а как мы работаем? =))
А я могу придумать.. м.. вам наверно лет 45-50 - обычно в этом возрасте ссылаются на уважаемые книжки, и боятся даже погуглить.. дабы случайно что-то не найти такое "ах, чем эти молодые д... развлекаются"
Давайте обойдемся без личностей.

 

[_RVK_]

Погуглил...
http://www.citforum.ru/SE/project/scrum/
Ничего нового не узнал. Похоже на XP но там используется другая терминология и есть различия в деталях. Но суть таже. Чем не нравится?

 

[MiksIr]

И еще одно.. давайте запихнем методики в ж, итак уже нафлудили, и вернемся к цитате

Начальник может посмотреть в план (его полное право), заметить что на тебе не стоит ни одной прикладной задачи, и полоскать тебе мозги, типа если бы ты кодил, могли бы сделать больше.

Где в вашей методике место этому плану и начальнику.

-~{}~ 12.09.08 04:37:

Чем не нравится?

Всем нравица.

Ай, ладна.. устала я. Начальнику привет, передаейте - пусть не подглядывает больше в план, а то команда обидица и уйдет

-~{}~ 12.09.08 04:40:

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

 

[_RVK_]

А я могу придумать.. м.. вам наверно лет 45-50

Спасибо Честно мне 26, но льстит что считают меня постарше возраста.

Его _не_должно_ волновать, что кто будет делать для выполнения задачи.

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

И не обижайтесь, может мне не повезло, но проджекты которых я знаю против таких идей даже если им показать на примере их эффективность. Некоторые мне говорили, что им нравится их работа потому что не надо ничего делать. Другие не так откровенны, но все равно ничего не делают. Реально работающих проджект-менеджеров я еще не встречал. Может на втором десятке опыта работы доведется встретить?