Насчёт прокачки — оно не очень хорошая идея. Тут не прокачка нужна, а склад души, что ли… Вообще, программисту и ПМу обычно нужны прямо противоположные качества (почитайте Рейнвотера, у него это прописано). А если уж сильно нужно «превращать» (а не прокачивать) кого-то из команды, попробуйте спросить, кто из ваших программистов готов стать руководителем проектов, если ему при этом уменьшат зарплату (хотя бы немного). Если таковые найдутся — присматривайтесь к ним, они и есть потенциальные руководители.
К сожалению, не имел опыта руководить большой командой (максимум — 9 человек, включая программистов, QA, аналитика и меня). Поэтому пост написан именно с этой точки зрения.
Где-то читал (по-моему в теории FDD), что большие команды стоит разбивать на несколько маленьких и ставить во главу каждой грамотного тимлида — этакая иерархия получается. Но это исключительно теория. Поскольку сам с большими командами не сталкивался, то рассуждать на эту тему не берусь.
А что касается «непопулярных» решений, так их приходится принимать и в маленьких командах, к сожалению.
Ну, по большому счёту, хотебось бы понять, насколько это согласуется с практикой в других командах. Возможно, у кого-то появятся дополнительные идеи, которыми я сам смогу воспользоваться.
Тут немного не о том я хотел сказать. Прежде чем дать оценку задачи я, в большинстве случаев, спрошу у программиста (а потом оценю реалистичность и введу коррективы, если посчитаю нужным). И потенциальному пользователю показывать систему обязательно. И это — факт.
В слове про сроки ключевое слово было не «сроки» а «договариваться с заказчиком», а под тестированием понимается реальный процесс QA с составлением грамотных багрепортов и т.д. Здесь я хотел сказать, что каждый должен делать свою работу. Ну не заставлять же, в самом деле, маркетологов багрепорты писать в трекер.
Где-то читал (по-моему в теории FDD), что большие команды стоит разбивать на несколько маленьких и ставить во главу каждой грамотного тимлида — этакая иерархия получается. Но это исключительно теория. Поскольку сам с большими командами не сталкивался, то рассуждать на эту тему не берусь.
А что касается «непопулярных» решений, так их приходится принимать и в маленьких командах, к сожалению.
В слове про сроки ключевое слово было не «сроки» а «договариваться с заказчиком», а под тестированием понимается реальный процесс QA с составлением грамотных багрепортов и т.д. Здесь я хотел сказать, что каждый должен делать свою работу. Ну не заставлять же, в самом деле, маркетологов багрепорты писать в трекер.