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