Господа.
Хочу описать ситуацию с ведением проекта и увидеть замечания.
Команда разработчиков с тим лидом находится здесь.
Проджект менеджер находится в Европе, голландец.
1.Постановка задачи. PM написал изначально небольшой документ technical specification, в котором некоторая функциональность описана на словах. После бесед с заказчиком PM добавляет и меняет эту логику. Причем просто в письмах. Причем непосредственно каждому разработчику ставится задание, да еще не очень то объясняется что именно должно быть получено, но говорится примерно следующее - добавь в такую-то таблицу форин кей на такую-ту. При этом тим лид в лучшем случае бывает в СС письма.
Часто разработка функциональности происходит таким образом. девелопер делает очередное ценное указание PMa и видит, что чего-то не хватает явно. Он спрашивает в письме или по yahoo -чтото тут типа не так. Тогда PM говорит - "hm, good point. Add foreign key bla-bla-id in the table bla-bla".Девелопер делает, и если чтото у него не получается, он спрашивает тим лида, как добавить этот bla-bla-id. team lead, который разрабатывал структуру базы и основные модули приложения, видит, что этот foreign key вообще-то не к месту там, но указание уже как бы сделано от PM и девелопер его выполняет. Если б у него получилось, то тим лид вообще не узнал бы об этом изменении в базе. 
Вопрос - нормальная ли это ситуация,и, если нет, то как должно быть организовано взаимоействие команды, тим лида и проджект менеджера? У кого какие обычно обязанности и ответственность?

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

3.PM непосредственно распределяет, кто из разработчиков должен исправлять какой баг.
При этом он дает исправлять девелоперу А код в части, разработанной девелопером В. Часто это ухудшает код.
Вопрос - правильно ли давать исправлять чужой код? Должен это делать проджект менеджер или тим лид?

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

Спасибо.

Вообще.. ПМ по определению не должен знать из каких полей состоят таблицы. Он вообще то менеджер.
Я даже считаю что разработчику трудно стать хорошим ПМ'ом, потому как ПМ это больше не техник, а гуманитарий
ну и по пунктам
1.

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

У нас есть такое понятие как codeviewer - более опятный по отношению к разработчику чел, который просматривает код перед тем как заурыть багу. Если ему что то не нравиться, то он пишет комент что именно. вообще, в частном случае им может быть и тим_лид, но не факт. Это дело у нас автоматизированно. и ведется лог того, что кто кому писал
3.

ну я об этом и говрю. 99% что ваш PM быший программист.


PS: если бы:
а) мне говорило моё начальство в какую таблицу вставить какое поле, то я думаю, что меня бы уже уволили.
б) мой PM (но он на самом деле не ПМ да и я не лид - нас двое на проекте, он получает описание пожеланий или багов - передает их мне а я уже думаю что с ними делать) за меня говорилл бы мне как решать ту или иную проблему - меня бы уже уволили.

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


PPS: а ваще.. тот ли раздел. Где то я видал на винграде специальный раздел по ведению проектов

Это сообщение отредактировал(а) DEER - 9.1.2008, 19:21

oson, это надо писать в "Управлении Проектами" ;)


По теме: пипец   

Во-первых(не аксиома, а лишь моё видение из соображений удобности):
У вас какой-то прям-таки agile спонтанный 

Требование к ПМу должно быть первейшее - взаимодействие через тимлидов. Пусть даже инструкции "девелопер А, добавь ки В в таблицу С", но они должны проходить через тимлида и он должен владеть ситуацией.

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

Я думаю, ему лучше выступать в качестве Product Ownera. 
Он выдаёт требования и даже немного распределяет их. Но все его требования складываются в бэклоги. Девелопер А там поглядит что ему надо сделать, но все остальные тоже смогут поглядеть что он делает и как.

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

Тогда "добавь ключ" трансформируется в багу/задачу/запись в бэклоге "надо добавить ключ, чтоб ...."
Тогда тимлди и все другие могут поглядеть и обдумать чем это грозит. И вовремя предложить иное решение.
А девелопер должен сообщать тимлиду, если что-то проходит мимо него.

Заведите вторую багзиллу для этой общей инфы. Али ещё какую тулзу.
И если бумажек у вас мало - тогда должно быть хорошее взаимодействие в команде устное.

Устраивайте "планёрки" в начале дня. Очень короткие. Каждый оглашает что делал, что сделал, что ему повелели сделать и какие траблы есть/могут быть. Все слушают, вылавливают интересное для себя, обнаруживают нестыковки(типа "какойнахек форейн ки в эту таблицу???"). Если такие нестыковки появились нлпанёрке - заинтерсованные лица сразу после планёрки устраивают обсуждение этого вопроса с(возможно) онлайн перепиской с ПМ(я бы назвал его ПО)

Это если голландец согласен что-то менять. Возможно, ему нравится быть царьком. Тогда он сознательно не пойдёт на облегчение и упрощение 

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

Добавлено через 2 минуты и 9 секунд

Хорошо если бывшый. Судя по описанию - он и работает программистом. Просто часть работы выдаёт другим.

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

Точно сформулировал.

Ну, тут всё зависит от решимости тимлида (твоей, как я понял). Если есть решимость, да ещё и команда за тебя - можно прямо наступить на больной мозоль РМу сказав, что позиция "крайнего" тебя не устраивает. Есть несколько вариантов:

•  вы расходитесь и живёте дальше раздельно
•  РМ сильно увеличивает материальную заинтересованность тимлида чтобы компенсировать своё жгучее желание лезть во все дыры
•  РМ соглашается работать по-нормальному и действует через тимлида; причём за тимлидом (по уму) должно оставаться решение о том, кто именно будет писать/исправлять что-либо (он ближе - ему, как и жирафу, виднее)

Бывает иногда озарение наступает.  

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

Однако есть такой аспект. ПМ может так поступать, если он не уверен в ведущем программисте. Тогда он старается держать под контролем всё. 

Говорить с шефом ПМа следует только в крайнем случае, когда невозможно достичь компромисса, и из-за этого появляется риск провала проекта. Но надо отдавать себе отчет, что результатом разговора могут быть перемены, которые тебе не понравятся. И при этом все равно  прыжок через голову начальника (а ПМ - он твой начальник? или он как бы в другой иерархии?) - это не очень хорошо. 

Эээ... мне подумалось что

потому как енто:

по невнимательности прочитал как "шефу/проджект менеджеру"