Доброго времени суток, дорогой читатель!
Сегодня я хотел бы рассказать о построении командной работы. Как оказалось зачастую это ставит в тупик любой проект.
Начнем с того, что тимлид должен хорошо понимать способности команды с которой работает. А именно:
1) Кол-во времени, которое каждый участник может посвятить проекту над которым ведется работа. И речь сейчас не о сотрудниках, работающих на ставке, а о команде энтузиастов, решивших начать свой собственный проект.
2) Уровень и области знаний, каждого из участников проекта.
3) Способность быстро переключаться с одной задачи на другую, для оперативного решения возникших проблем.
Если Тимлид не изучил должным образом вверенную ему команду, будет постоянная путаница, неразбериха и , как итог, большое количество проблем. Проект зайдет в тупик и будет очень долго из него выходить, если не развалиться полностью.
Построение команды должно начинаться с ее изучения!
Отличным решением будет посидеть в уютной обстановке, за чашечкой кофе и пообщаться с каждым из участников проекта.Желательно по отдельности. Выяснить его(ее) слабые и сильные стороны. Обсудить видение проекта. Узнать и, возможно, записать его предполагаемый график работы над проектом. Отталкиваясь от полученной информации можно построить "Дорожную карту" проекта, выставить дедлайны по задачам.
Любой человек должен быть взаимозаменяем!
Если выставлена задача для конкретного человека, должна быть подстраховка. Вам необходимо найти еще одного участника в группе, который в случае непредвиденных обстоятельств(болезнь к примеру) сможет доделать указанную задачу. Если такого человека нет - им должен стать Тимлид. И не важно, что он программист, а не дизайнер или филолог.
Да, Тимлид и чтец, и жнец, и на дуде игрец!
Если вы не готовы пахать и/или думать наперед, вам не стоит браться за управление проектом. Если у вас времени для работы над проектом меньше чем у вашей команды - зачем вы взяли на себя эти обязанности?
Строить командную работу надо с себя!
ВАЖНО!
Тимлид - не банальный генератор идей!!!!
Задачами управляющего проектом, является все(!!!) что касается проекта, а не только генерация идей и нарезка задач. В случае если у кого-то, возникла проблема с кодом - Вы решаете эту проблему. Если у дизайнера проблемы с текстурами - Вы это решаете. Если специалист в иной области не может вывести какую-то формулу - Вы ее выводите, несмотря на то, что практически (или совсем) не разбираетесь в этой области. Садитесь за учебники, журналы, читаете статьи в интернете, изучаете область и выводите. Если для этого вам предстоит не спать пару дней - значит вы должны не спать, но вывести эту формулу, написать этот код и прикрепить эти долбаные текстуры.