К ним относится основной состав группы (см. главу 4): менеджер проекта, разработчики, тестировщики, специалисты по обучению пользователей и технологи.
• Не посвящайте собрание решению частных проблем
Собрания часто становятся местом встречи нескольких участников группы, которые хотят обсудить свои проблемы. Несомненно, эти проблемы важны и требуют разрешения, но контрольное собрание — не место для «мозговой атаки», решения технических и других серьёзных вопросов. Если попытаться охватить проблемы всех участников группы, то лучшую часть дня придётся потратить на собрания, при этом значительная часть времени остальных участников группы будет потеряна зря: люди должны знать суть решения, а не его подробности.
Должен ли каждый разработчик отсиживать на собрании, посвящённой новому формату электронной справки? Должен ли каждый тестировщик выслушивать, как разработчики обсуждают набор изменений в API? Нет. Если проблему нельзя решить за две минуты, для её решения надо провести отдельное собрание, пригласив только тех, кого эта проблема касается. Решения, выработанные на собраниях, посвящённых частным проблемам, следует доложить на общем контрольном собрании. Не используйте общегрупповые контрольные собрания для решения частных проблем.
Столь же неправильно докладывать на контрольном собрании о всех задачах, над которыми пришлось работать за неделю. Нужно лишь сказать, идёт ли разработка проекта по намеченному пути. Если нет, надо перечислить причины, всё остальное несущественно.
• Не затягивайте собрание
Контрольные собрания должны быть краткими и проводиться чаще. Рекомендуется проводить их хотя бы раз в неделю, предоставляя каждому участнику группы пять минут на доклад о состоянии дел в вверенной ему области с учётом вышеописанных требований. Организатор собрания (обычно это менеджер проекта) должен поддерживать обсуждение в определённом русле и не позволять ему переходить на отвлечённые темы. Однако все важные вопросы, поднятые любым участником группы, следует внести в список проблем проекта.
• Ведите список нерешённых проблем
Во время реализации проекта обычно возникают проблемы, которые надо решать. Чтобы не забыть о них, в главе 5 я рекомендовал регистрировать такие проблемы, назначать ответственных за их решение и обязательно разъяснять найденное решение другим. Аналогичную концепцию можно применить при проведении контрольных собраний. На собраниях проводится анализ нерешённых проблем, назначаются ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.
Из собственного опыта
В преддверии завершения важного промежугочного этапа сотрудники компании NuMega должны были сообща устранять последние неполадки и ошибки. Чтобы гарантированно обеспечить себя актуальной информацией, мы составили список неполадок, упорядоченный сначала по их приоритету, а затем — по именам ответственных за их устранение. Каждый участник контрольного собрания получал копию этого списка (позже печатные списки были заменены подключёнными к сети лэптопами, что позволило работать прямо из системы). Такие обзоры позволили мобилизовать всю группу на решение важных проблем и устранение ошибок, сдерживавших работу других или бывших источником особого риска. Интенсивное общение имеет очень большое значение на завершающих стадиях работы над проектом, бета-версией или новым выпуском программы.
«Управление мимоходом»
Очень полезна технология «управления мимоходом» (Managing by Walking Around, MBWA). Контрольные собрания — формальность, но менеджер проекта и ведущие специалисты, даже просто находясь в группе, могут встречаться с участниками для неформального обсуждения тех или иных проблем.
• Каждый видит, что менеджер проекта участвует в работе и заботится об успехе проекта. Он не собирается отгородиться от исполнителей проекта цифрами, графиками и рисунками, управляя проектом лишь через компьютер. При таком подходе менеджер проекта и ведущие специалисты становятся доступнее, и с ними можно быстро и без проблем обмениваться информацией.
• Люди часто ощущают дискомфорт, выступая на контрольных собраниях. Удивительно, что во время беседы тет-а-тет за чашкой кофе они высказывают такие мысли, о которых скорее всего даже не заикнулись бы на групповом собрании.
• Такая практика допускает спонтанное обсуждение важных предметов и проблем, в ходе которого часто рождаются совершенно новые подходы к их решению. Замечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно поощрять внеплановое, неформальное и нерегламентированное общение.
• Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отрываться от компьютера и покидать свой офис. Но происходят просто удивительные вещи, когда кто-то мимоходом спрашивает их: «как идут базисные тесты?», «что нового с проблемой X?» или «ну как, уже заканчиваем второй этап?»
• Хороший менеджер проекта и ведущий специалист обязательно проводит некоторое время наедине с участниками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию. Одного короткого визита участника по какому-нибудь личному или рабочему вопросу достаточно для поддержания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при реализации проекта прежде, чем они возникнут. Если вы не хотите получить неприятный сюрприз во время контрольного собрания или, что ещё хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками группы и с каждым по отдельности.
Обмен информацией
Менеджер проекта и ведущие специалисты должны эффективно взаимодействовать друг с другом и с другими членами группы, поскольку совместное переживание главных успехов и неудач имеет решающее значение для прогресса проекта. Поскольку как успехи, так и неудачи одинаково важны, рассмотрим те и другие.
• Успехи
Отмечайте каждый крупный успех и делайте его достоянием группы. Это важное доказательство того, что проект живёт и здравствует. Поэтому, создав ежедневную сборку программы, первый вариант установочной процедуры или закончив важную функцию ПО, не забудьте разослать участникам группы поздравления по электронной почте, разделив со всеми это радостное событие. В торжества по поводу особо важных событий необходимо вовлекать большую часть коллектива: отделение или даже весь персонал компании.
• Неудачи
Неудачи необходимо как можно скорее обнаруживать, сообщать о них всем участникам команды и устранять.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73
• Не посвящайте собрание решению частных проблем
Собрания часто становятся местом встречи нескольких участников группы, которые хотят обсудить свои проблемы. Несомненно, эти проблемы важны и требуют разрешения, но контрольное собрание — не место для «мозговой атаки», решения технических и других серьёзных вопросов. Если попытаться охватить проблемы всех участников группы, то лучшую часть дня придётся потратить на собрания, при этом значительная часть времени остальных участников группы будет потеряна зря: люди должны знать суть решения, а не его подробности.
Должен ли каждый разработчик отсиживать на собрании, посвящённой новому формату электронной справки? Должен ли каждый тестировщик выслушивать, как разработчики обсуждают набор изменений в API? Нет. Если проблему нельзя решить за две минуты, для её решения надо провести отдельное собрание, пригласив только тех, кого эта проблема касается. Решения, выработанные на собраниях, посвящённых частным проблемам, следует доложить на общем контрольном собрании. Не используйте общегрупповые контрольные собрания для решения частных проблем.
Столь же неправильно докладывать на контрольном собрании о всех задачах, над которыми пришлось работать за неделю. Нужно лишь сказать, идёт ли разработка проекта по намеченному пути. Если нет, надо перечислить причины, всё остальное несущественно.
• Не затягивайте собрание
Контрольные собрания должны быть краткими и проводиться чаще. Рекомендуется проводить их хотя бы раз в неделю, предоставляя каждому участнику группы пять минут на доклад о состоянии дел в вверенной ему области с учётом вышеописанных требований. Организатор собрания (обычно это менеджер проекта) должен поддерживать обсуждение в определённом русле и не позволять ему переходить на отвлечённые темы. Однако все важные вопросы, поднятые любым участником группы, следует внести в список проблем проекта.
• Ведите список нерешённых проблем
Во время реализации проекта обычно возникают проблемы, которые надо решать. Чтобы не забыть о них, в главе 5 я рекомендовал регистрировать такие проблемы, назначать ответственных за их решение и обязательно разъяснять найденное решение другим. Аналогичную концепцию можно применить при проведении контрольных собраний. На собраниях проводится анализ нерешённых проблем, назначаются ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.
Из собственного опыта
В преддверии завершения важного промежугочного этапа сотрудники компании NuMega должны были сообща устранять последние неполадки и ошибки. Чтобы гарантированно обеспечить себя актуальной информацией, мы составили список неполадок, упорядоченный сначала по их приоритету, а затем — по именам ответственных за их устранение. Каждый участник контрольного собрания получал копию этого списка (позже печатные списки были заменены подключёнными к сети лэптопами, что позволило работать прямо из системы). Такие обзоры позволили мобилизовать всю группу на решение важных проблем и устранение ошибок, сдерживавших работу других или бывших источником особого риска. Интенсивное общение имеет очень большое значение на завершающих стадиях работы над проектом, бета-версией или новым выпуском программы.
«Управление мимоходом»
Очень полезна технология «управления мимоходом» (Managing by Walking Around, MBWA). Контрольные собрания — формальность, но менеджер проекта и ведущие специалисты, даже просто находясь в группе, могут встречаться с участниками для неформального обсуждения тех или иных проблем.
• Каждый видит, что менеджер проекта участвует в работе и заботится об успехе проекта. Он не собирается отгородиться от исполнителей проекта цифрами, графиками и рисунками, управляя проектом лишь через компьютер. При таком подходе менеджер проекта и ведущие специалисты становятся доступнее, и с ними можно быстро и без проблем обмениваться информацией.
• Люди часто ощущают дискомфорт, выступая на контрольных собраниях. Удивительно, что во время беседы тет-а-тет за чашкой кофе они высказывают такие мысли, о которых скорее всего даже не заикнулись бы на групповом собрании.
• Такая практика допускает спонтанное обсуждение важных предметов и проблем, в ходе которого часто рождаются совершенно новые подходы к их решению. Замечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно поощрять внеплановое, неформальное и нерегламентированное общение.
• Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отрываться от компьютера и покидать свой офис. Но происходят просто удивительные вещи, когда кто-то мимоходом спрашивает их: «как идут базисные тесты?», «что нового с проблемой X?» или «ну как, уже заканчиваем второй этап?»
• Хороший менеджер проекта и ведущий специалист обязательно проводит некоторое время наедине с участниками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию. Одного короткого визита участника по какому-нибудь личному или рабочему вопросу достаточно для поддержания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при реализации проекта прежде, чем они возникнут. Если вы не хотите получить неприятный сюрприз во время контрольного собрания или, что ещё хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками группы и с каждым по отдельности.
Обмен информацией
Менеджер проекта и ведущие специалисты должны эффективно взаимодействовать друг с другом и с другими членами группы, поскольку совместное переживание главных успехов и неудач имеет решающее значение для прогресса проекта. Поскольку как успехи, так и неудачи одинаково важны, рассмотрим те и другие.
• Успехи
Отмечайте каждый крупный успех и делайте его достоянием группы. Это важное доказательство того, что проект живёт и здравствует. Поэтому, создав ежедневную сборку программы, первый вариант установочной процедуры или закончив важную функцию ПО, не забудьте разослать участникам группы поздравления по электронной почте, разделив со всеми это радостное событие. В торжества по поводу особо важных событий необходимо вовлекать большую часть коллектива: отделение или даже весь персонал компании.
• Неудачи
Неудачи необходимо как можно скорее обнаруживать, сообщать о них всем участникам команды и устранять.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73