Страница:
• Ведите список нерешённых проблем
Во время реализации проекта обычно возникают проблемы, которые надо решать. Чтобы не забыть о них, в главе 5 я рекомендовал регистрировать такие проблемы, назначать ответственных за их решение и обязательно разъяснять найденное решение другим. Аналогичную концепцию можно применить при проведении контрольных собраний. На собраниях проводится анализ нерешённых проблем, назначаются ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.
Из собственного опыта
В преддверии завершения важного промежугочного этапа сотрудники компании NuMega должны были сообща устранять последние неполадки и ошибки. Чтобы гарантированно обеспечить себя актуальной информацией, мы составили список неполадок, упорядоченный сначала по их приоритету, а затем — по именам ответственных за их устранение. Каждый участник контрольного собрания получал копию этого списка (позже печатные списки были заменены подключёнными к сети лэптопами, что позволило работать прямо из системы). Такие обзоры позволили мобилизовать всю группу на решение важных проблем и устранение ошибок, сдерживавших работу других или бывших источником особого риска. Интенсивное общение имеет очень большое значение на завершающих стадиях работы над проектом, бета-версией или новым выпуском программы.
• Каждый видит, что менеджер проекта участвует в работе и заботится об успехе проекта. Он не собирается отгородиться от исполнителей проекта цифрами, графиками и рисунками, управляя проектом лишь через компьютер. При таком подходе менеджер проекта и ведущие специалисты становятся доступнее, и с ними можно быстро и без проблем обмениваться информацией.
• Люди часто ощущают дискомфорт, выступая на контрольных собраниях. Удивительно, что во время беседы тет-а-тет за чашкой кофе они высказывают такие мысли, о которых скорее всего даже не заикнулись бы на групповом собрании.
• Такая практика допускает спонтанное обсуждение важных предметов и проблем, в ходе которого часто рождаются совершенно новые подходы к их решению. Замечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно поощрять внеплановое, неформальное и нерегламентированное общение.
• Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отрываться от компьютера и покидать свой офис. Но происходят просто удивительные вещи, когда кто-то мимоходом спрашивает их: «как идут базисные тесты?», «что нового с проблемой X?» или «ну как, уже заканчиваем второй этап?»
• Хороший менеджер проекта и ведущий специалист обязательно проводит некоторое время наедине с участниками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию. Одного короткого визита участника по какому-нибудь личному или рабочему вопросу достаточно для поддержания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при реализации проекта прежде, чем они возникнут. Если вы не хотите получить неприятный сюрприз во время контрольного собрания или, что ещё хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками группы и с каждым по отдельности.
• Успехи
Отмечайте каждый крупный успех и делайте его достоянием группы. Это важное доказательство того, что проект живёт и здравствует. Поэтому, создав ежедневную сборку программы, первый вариант установочной процедуры или закончив важную функцию ПО, не забудьте разослать участникам группы поздравления по электронной почте, разделив со всеми это радостное событие. В торжества по поводу особо важных событий необходимо вовлекать большую часть коллектива: отделение или даже весь персонал компании.
• Неудачи
Неудачи необходимо как можно скорее обнаруживать, сообщать о них всем участникам команды и устранять. Не стоит ожидать от команды абсолютно безупречной работы. Знайте: проблемы возникнут непременно. Работа команды заключается в том, чтобы как можно скорее найти их и решить. Худший способ борьбы с проблемами — замалчивать их или вовсе не признавать их существования, так как это не поможет ни решить проблему, ни вернуть проект на намеченный путь.
Чтобы не допустить этого, менеджер проекта и ведущие специалисты должны быть доступны и открыты для общения. Если у члена команды возникает ощущение, что неудачи или проблемы не получат профессионального решения, сокрытие проблемы и неверие в её существование станет хроническим источником бед.
Внесение изменений
Общие проблемы и решения
Глава 13
Ценность бета-тестирования
Во время реализации проекта обычно возникают проблемы, которые надо решать. Чтобы не забыть о них, в главе 5 я рекомендовал регистрировать такие проблемы, назначать ответственных за их решение и обязательно разъяснять найденное решение другим. Аналогичную концепцию можно применить при проведении контрольных собраний. На собраниях проводится анализ нерешённых проблем, назначаются ответственные за их решение и устанавливаются сроки. Таким образом, каждый будет знать, что все проблемы будут рассмотрены и решены.
Из собственного опыта
В преддверии завершения важного промежугочного этапа сотрудники компании NuMega должны были сообща устранять последние неполадки и ошибки. Чтобы гарантированно обеспечить себя актуальной информацией, мы составили список неполадок, упорядоченный сначала по их приоритету, а затем — по именам ответственных за их устранение. Каждый участник контрольного собрания получал копию этого списка (позже печатные списки были заменены подключёнными к сети лэптопами, что позволило работать прямо из системы). Такие обзоры позволили мобилизовать всю группу на решение важных проблем и устранение ошибок, сдерживавших работу других или бывших источником особого риска. Интенсивное общение имеет очень большое значение на завершающих стадиях работы над проектом, бета-версией или новым выпуском программы.
«Управление мимоходом»
Очень полезна технология «управления мимоходом» (Managing by Walking Around, MBWA). Контрольные собрания — формальность, но менеджер проекта и ведущие специалисты, даже просто находясь в группе, могут встречаться с участниками для неформального обсуждения тех или иных проблем.• Каждый видит, что менеджер проекта участвует в работе и заботится об успехе проекта. Он не собирается отгородиться от исполнителей проекта цифрами, графиками и рисунками, управляя проектом лишь через компьютер. При таком подходе менеджер проекта и ведущие специалисты становятся доступнее, и с ними можно быстро и без проблем обмениваться информацией.
• Люди часто ощущают дискомфорт, выступая на контрольных собраниях. Удивительно, что во время беседы тет-а-тет за чашкой кофе они высказывают такие мысли, о которых скорее всего даже не заикнулись бы на групповом собрании.
• Такая практика допускает спонтанное обсуждение важных предметов и проблем, в ходе которого часто рождаются совершенно новые подходы к их решению. Замечательные идеи не рождаются в два часа пополудни каждый понедельник. Чтобы они возникали, нужно поощрять внеплановое, неформальное и нерегламентированное общение.
• Поскольку почти все ведущие специалисты когда-то были просто инженерами, они очень не любят отрываться от компьютера и покидать свой офис. Но происходят просто удивительные вещи, когда кто-то мимоходом спрашивает их: «как идут базисные тесты?», «что нового с проблемой X?» или «ну как, уже заканчиваем второй этап?»
• Хороший менеджер проекта и ведущий специалист обязательно проводит некоторое время наедине с участниками группы. Такие встречи не обязательно должны быть формальными или проводиться по расписанию. Одного короткого визита участника по какому-нибудь личному или рабочему вопросу достаточно для поддержания сосредоточенной и слаженной работы. Кроме того, это замечательный способ избавиться от проблем с кадрами или иных трудностей при реализации проекта прежде, чем они возникнут. Если вы не хотите получить неприятный сюрприз во время контрольного собрания или, что ещё хуже, накануне сдачи проекта, как можно чаще общайтесь со всеми участниками группы и с каждым по отдельности.
Обмен информацией
Менеджер проекта и ведущие специалисты должны эффективно взаимодействовать друг с другом и с другими членами группы, поскольку совместное переживание главных успехов и неудач имеет решающее значение для прогресса проекта. Поскольку как успехи, так и неудачи одинаково важны, рассмотрим те и другие.• Успехи
Отмечайте каждый крупный успех и делайте его достоянием группы. Это важное доказательство того, что проект живёт и здравствует. Поэтому, создав ежедневную сборку программы, первый вариант установочной процедуры или закончив важную функцию ПО, не забудьте разослать участникам группы поздравления по электронной почте, разделив со всеми это радостное событие. В торжества по поводу особо важных событий необходимо вовлекать большую часть коллектива: отделение или даже весь персонал компании.
• Неудачи
Неудачи необходимо как можно скорее обнаруживать, сообщать о них всем участникам команды и устранять. Не стоит ожидать от команды абсолютно безупречной работы. Знайте: проблемы возникнут непременно. Работа команды заключается в том, чтобы как можно скорее найти их и решить. Худший способ борьбы с проблемами — замалчивать их или вовсе не признавать их существования, так как это не поможет ни решить проблему, ни вернуть проект на намеченный путь.
Чтобы не допустить этого, менеджер проекта и ведущие специалисты должны быть доступны и открыты для общения. Если у члена команды возникает ощущение, что неудачи или проблемы не получат профессионального решения, сокрытие проблемы и неверие в её существование станет хроническим источником бед.
Внесение изменений
Беспроблемных проектов не бывает. Конечно, есть надежда, что «навигационная система» заранее предупредит о трудностях. Это поможет ликвидировать их, прежде чем они перерастут в серьёзные проблемы. Однако чтобы устранить отклонение проекта от намеченного пути, потребуется изменить направление работы и, возможно, увеличивать её темп. Посмотрим, как можно это сделать…
• Собирайте факты, но не перестарайтесь с их анализом
Часто решение принимают на основе впечатлений, эмоций или единичного случая, а не анализа набора неопровержимых фактов. Прежде чем вносить в проект изменения, убедитесь в их абсолютной необходимости. В частности, не позволяйте эмоциональным утверждениями типа «Программа виснет на каждом шагу» стать причиной отказа от реализации половины функций программы и переброски дополнительных ресурсов на тестирование. Прежде чем действовать, соберите факты. При каких условиях происходит зависание? Кто сообщает о зависаниях? Как часто они происходят? Вполне возможно, выяснится, что все эти зависания связаны с заурядными ошибками, устранёнными ещё на прошлой неделе.
С другой стороны, постарайтесь не попасть в ловушку «паралича анализа». Не убивайте недели на анализ проблем лишь затем, чтобы оказалось, что момент для исправления упущен. Например, если после долгих раздумий так и не удалось собрать достаточно данных, чтобы решиться на изменение какой-то функции, примите решение немедленно, исходя из текущих знаний.
• Вовлекайте в обсуждение проблемы других специалистов
Собрав факты, обязательно обсудите проблему с ключевыми специалистами группы, включая разработчиков, тестировщиков, специалистов по инженерной психологии, технологов и менеджеров по продукции. Проводите «мозговые штурмы», проверяя различные идеи, и обсуждайте альтернативы. Если решение касается других членов команды, дайте им шанс поучаствовать в обсуждении. Приняв решение (даже если решено ничего не предпринимать), известите о нём каждого. Держите команду в курсе всех важных изменений и их причин, а также планов действий на будущее. Плохая информированность об изменениях проекта ведёт к падению боевого духа коллектива.
• Используйте помощь других групп при разработке и тестировании
Часто, когда возникает необходимость что-то добавить, подправить или проверить, все участники группы, как назло, оказываются по уши занятыми своими делами и ни у кого просто нет времени. В этом случае нужно подумать о привлечении дополнительных сотрудников. Если есть свободные люди из отдела технической поддержки, справочного бюро, специалисты по выпуску или продаже или другие члены команды по созданию продукта, обязательно попросите их помочь.
Из собственного опыта
В NuMega группа технической поддержки часто используется для подстраховки при разработке программ. В службе поддержки компании много ярких личностей, которые хотели бы повысить свой опыт разработчиков. Мы дали им возможность поработать над созданием самых настоящих программ, а они в свою очередь помогли группе разработчиков не выбиться из плана. Естественно, такая помощь часто означала для членов группы технической поддержки сверхурочную работу, но они почти всегда были готовы потратить несколько лишних часов, чтобы помочь разработчикам и приобрести дополнительный опыт. Кроме того, это возможность сделать карьеру. Благодаря полученному опыту и оказанной ими помощи, участники группы технической поддержки завоевали уважение разработчиков и энергично продвигались на должности разработчиков. Это ещё одна причина нанимать стоящих людей на любую должность.
• Нанимайте консультантов и исполнителей
Следует подумать о найме консультантов и исполнителей для выполнения чётко определённой и относительно краткосрочной работы. Ваша задача — закрыть критические участки проекта, на которые не хватает собственных кадров. Но остерегайтесь использования консультантов в качестве ведущих специалистов, так как они, скорее всего, покинут группу по завершении проекта.
• Лучше отказаться от части функций, чем расширятъ план
При необходимости подумайте об отказе от некоторых функций программы. Если приоритетные функции определены и их реализация запланирована на ранних этапах работы над проектом, вполне можно отказаться от ряда второстепенных функций. Прежде чем решиться на расширение плана, рассмотрите возможность исключения ряда функций второго или третьего плана. Отказ от реализации некоторых функций позволяет разгрузить все группы и снизить риск срыва. Расширение плана лишь повышает риск срыва даты выхода продукта. Тривиальное добавление новых функций, не имеющих значения для успеха ПО — не самое мудрое решение: важнее вовремя выпустить продукт, чем реализовать все второстепенные функции.
Вот примеры хороших вопросов, на которые нужно ответить при поступлении предложения о реализации новой функции.
• Какая часть прибыли будет потеряна, если отказаться от реализации новой функции?
• Скольким клиентами будет полезна новая функция?
• Не сорвёт ли (или подвергнет риску) новая функция срок выхода продукта?
• Снизится ли конкурентоспособность продукта без этой функции?
• Какому риску подвергнется качество продукта при отсутствии новой функции?
• Какое влияние окажет новая функция на использование программы, документацию, а также на процессы её сборки и установки?
Это не означает, что нужно отказаться от изменений вообще, — просто всегда нужно быть уверенным, что выгода от изменения намного больше расходов на её реализацию.
• Завершить очередной этап в срок
Если очередной этап работы близится к концу и при этом есть ощущение, что можно не уложиться в сроки, нужно начинать сверхурочную работу уже сейчас, а не позже. Как сказано выше, не следует дожидаться начала следующего этапа, чтобы обнаружить проблемы с завершением текущего. Если чувствуете, что план может быть сорван, лучше приложить дополнительные усилия раньше, чем позже.
• Наверстать упущениое
Если не удалось уложиться в срок при выполнении промежуточного этапа работы, упущенное придётся навёрстывать. Помимо этого, нужно завершить следующий этап в срок. Если вы всерьёз хотите вовремя закончить работу над проектом, приложите дополнительные усилия уже сейчас.
• Справиться с возросшей конкуренцией
Если на рынке произошли серьёзные изменения, чтобы достигнуть успеха или просто не быть вытесненным конкурентами, реализацию проекта придётся ускорить. При этом, возможно, придётся добавлять новые функции к продукту или ужать план на месяц. Это потребует от всей группы полной самоотдачи.
Прежде чем просить кого бы то ни было посвятить проекту дополнительное время, убедитесь, что ваша просьба обоснованна. Постоянно прося команду об изменении графика работы или штурмуя каждую проблему работой в сверхурочное время, вы быстро исчерпаете продуктивность и эффективность команды. Нельзя заставлять людей слишком долго и слишком много работать сверхурочно. Этот подход следует использовать для навёрстывания упущенного или для адекватной реакции на внешние события, но нельзя делать сверхурочные частью нормального графика работы.
• Определите продолжительность сверхурочных работ
Необходимо чётко определить продолжительность периода сверхурочной работы — он не может быть открытым или неопределённым. Следует поставить конечную задачу: уложиться в заданный срок или достичь определённого конечного результата;
• Создайте комфорт
Сверхурочная работа должна доставлять удовольствие. Обязательно предлагайте питание работающим во время обеденного перерыва, а также тем, кто задерживается на работе допоздна. Следите за тем, чтобы работники могли взять из дома всё необходимое для работы. Организуйте максимально комфортабельную рабочую среду для тех, кто не может работать дома, а также организуйте для них беспрепятственный вход и выход из офиса по окончании обычного рабочего дня. Следует подумать об организации дополнительного обслуживания, например, привлечения посыльных для разных поручений или возможности сдать вещи в химчистку, чтобы помочь сотрудникам сохранить силы и сосредоточиться на работе.
• Поддерживайте боевой дух
Когда от группы требуется самоотдача, проследите, чтобы все её участники работали сообща: все остаются, все помогают и вносят свой вклад. Если не нужно писать новый код, займите людей тестированием. Если нечего тестировать, бросьте всех на редактирование документации. Общая преданность делу и общая ответственность теснее сплотит группу и способствует развитию духа товарищества.
Из собственного опыта
В начале истории компании NuMega нам нередко приходилось работать сверхурочно. Мы часто работали по ночам и в выходные. Чтобы скрасить это время, дочь одного из сотрудников взялась готовить для нас. Она как раз училась стряпать и хотела попрактиковаться на нас. К счастью, у неё был талант и ей помогала мама. Конечно, свою пиццу мы получали тоже, но приготовленные ею обеды помогали нарушить однообразие.
Когда работы было особенно много, как правило, все работали сверхурочно, оставаясь после работы. Это было весёлое время, и часто сверхурочные часы превращались в вечеринку. Хотя людям приходилось жертвовать собственным временем и допоздна задерживаться на работе, все знали, для чего это делается, и верили, что наша работа важна для успеха общего дела. Когда работа была закончена, мы решили пригласить на празднование нового выпуска своих родственников. Мы понимали, какие неудобства сверхурочная работа доставила нашим семьям, и хотели как-то отблагодарить их за проявленное терпение.
• Информируйте о прогрессе
Если людям приходится много работать сверхурочно, они обязательно должны знать, что именно они являются двигателем проекта. Как менеджер проекта или ведущий специалист, вы должны показать команде, что их усилия оправдываются.
• Благодарите за труд
Это можно делать на собраниях или при личных встречах с отличившимися. Подумайте о специальных футболках, подарках и других наградах за особые заслуги. Непременно позаботьтесь, чтобы все работающие сверхурочно ощущали признательность за свой труд. Не забывайте и об их семьях. Все это отражается в первую очередь на них, и следует найти способ отблагодарить членов семей сотрудников за их жертвы.
Смена курса
Анализируя возможность изменения существенных элементов проекта (функций, технологии, платформ или плана реализации), нужно обязательно придерживаться следующих правил. Они помогут избежать неприятностей и принять правильное решение.• Собирайте факты, но не перестарайтесь с их анализом
Часто решение принимают на основе впечатлений, эмоций или единичного случая, а не анализа набора неопровержимых фактов. Прежде чем вносить в проект изменения, убедитесь в их абсолютной необходимости. В частности, не позволяйте эмоциональным утверждениями типа «Программа виснет на каждом шагу» стать причиной отказа от реализации половины функций программы и переброски дополнительных ресурсов на тестирование. Прежде чем действовать, соберите факты. При каких условиях происходит зависание? Кто сообщает о зависаниях? Как часто они происходят? Вполне возможно, выяснится, что все эти зависания связаны с заурядными ошибками, устранёнными ещё на прошлой неделе.
С другой стороны, постарайтесь не попасть в ловушку «паралича анализа». Не убивайте недели на анализ проблем лишь затем, чтобы оказалось, что момент для исправления упущен. Например, если после долгих раздумий так и не удалось собрать достаточно данных, чтобы решиться на изменение какой-то функции, примите решение немедленно, исходя из текущих знаний.
• Вовлекайте в обсуждение проблемы других специалистов
Собрав факты, обязательно обсудите проблему с ключевыми специалистами группы, включая разработчиков, тестировщиков, специалистов по инженерной психологии, технологов и менеджеров по продукции. Проводите «мозговые штурмы», проверяя различные идеи, и обсуждайте альтернативы. Если решение касается других членов команды, дайте им шанс поучаствовать в обсуждении. Приняв решение (даже если решено ничего не предпринимать), известите о нём каждого. Держите команду в курсе всех важных изменений и их причин, а также планов действий на будущее. Плохая информированность об изменениях проекта ведёт к падению боевого духа коллектива.
• Используйте помощь других групп при разработке и тестировании
Часто, когда возникает необходимость что-то добавить, подправить или проверить, все участники группы, как назло, оказываются по уши занятыми своими делами и ни у кого просто нет времени. В этом случае нужно подумать о привлечении дополнительных сотрудников. Если есть свободные люди из отдела технической поддержки, справочного бюро, специалисты по выпуску или продаже или другие члены команды по созданию продукта, обязательно попросите их помочь.
Из собственного опыта
В NuMega группа технической поддержки часто используется для подстраховки при разработке программ. В службе поддержки компании много ярких личностей, которые хотели бы повысить свой опыт разработчиков. Мы дали им возможность поработать над созданием самых настоящих программ, а они в свою очередь помогли группе разработчиков не выбиться из плана. Естественно, такая помощь часто означала для членов группы технической поддержки сверхурочную работу, но они почти всегда были готовы потратить несколько лишних часов, чтобы помочь разработчикам и приобрести дополнительный опыт. Кроме того, это возможность сделать карьеру. Благодаря полученному опыту и оказанной ими помощи, участники группы технической поддержки завоевали уважение разработчиков и энергично продвигались на должности разработчиков. Это ещё одна причина нанимать стоящих людей на любую должность.
• Нанимайте консультантов и исполнителей
Следует подумать о найме консультантов и исполнителей для выполнения чётко определённой и относительно краткосрочной работы. Ваша задача — закрыть критические участки проекта, на которые не хватает собственных кадров. Но остерегайтесь использования консультантов в качестве ведущих специалистов, так как они, скорее всего, покинут группу по завершении проекта.
• Лучше отказаться от части функций, чем расширятъ план
При необходимости подумайте об отказе от некоторых функций программы. Если приоритетные функции определены и их реализация запланирована на ранних этапах работы над проектом, вполне можно отказаться от ряда второстепенных функций. Прежде чем решиться на расширение плана, рассмотрите возможность исключения ряда функций второго или третьего плана. Отказ от реализации некоторых функций позволяет разгрузить все группы и снизить риск срыва. Расширение плана лишь повышает риск срыва даты выхода продукта. Тривиальное добавление новых функций, не имеющих значения для успеха ПО — не самое мудрое решение: важнее вовремя выпустить продукт, чем реализовать все второстепенные функции.
Задавайте верные вопросы
Есть хороший способ решить, вносить или не вносить изменение. Для этого нужно спросить у себя: «А что, если я не стану этого делать?» Такие вопросы особенно полезны в борьбе с так называемым «дрейфом функций», который может существенно прибавить работы группе. Однако зачастую изменения вносят без солидного технического или экономического обоснования. Изменение может воплощать хорошую идею, но она может не стоить того риска, которому подвергает весь проект. Конечно, должен быть определённый уровень совершенствования функций, но не до такой степени, чтобы проект был захлестнут потоком мелких изменений. Всегда спрашивайте себя: «А что, если я не стану этого делать?» Это заставит сравнить цену отказа от изменения с ценой его реализации.Вот примеры хороших вопросов, на которые нужно ответить при поступлении предложения о реализации новой функции.
• Какая часть прибыли будет потеряна, если отказаться от реализации новой функции?
• Скольким клиентами будет полезна новая функция?
• Не сорвёт ли (или подвергнет риску) новая функция срок выхода продукта?
• Снизится ли конкурентоспособность продукта без этой функции?
• Какому риску подвергнется качество продукта при отсутствии новой функции?
• Какое влияние окажет новая функция на использование программы, документацию, а также на процессы её сборки и установки?
Это не означает, что нужно отказаться от изменений вообще, — просто всегда нужно быть уверенным, что выгода от изменения намного больше расходов на её реализацию.
Стремление к согласию не должно мешать принятию решений
Решать проблемы нужно как можно скорее, не позволяя им долго оставаться открытыми. Так или иначе, решение должно быть принято. Прийти к согласию — ваша задача, но помните, что она не всегда достижима. Кроме того, консенсус означает не единодушное согласие, но согласие большинства. Если после сбора информации и её анализа согласие все ещё не достигнуто (т.е. существуют разные мнения) абсолютно необходимо, чтобы менеджер проекта или один из его ведущих специалистов принял решение самостоятельно. Не откладывайте это и не проявляйте нерешительность — здесь нужна сильная рука лидера. Группе необходимо решение для продолжения работы, задержка с его принятием снижает мотивацию группы, и можно упустить благоприятный момент. Помните: лучше принять неверное решение, чем долго тянуть с его принятием и так никогда не узнать, что правильный выбор был совсем рядом.Смена темпа работы
Несмотря на самые благие намерения и усилия по планированию, порой приходится увеличивать темп работы, чтобы уложиться в сроки или отреагировать на изменившиеся условия. На первых порах сверхурочная работа требуется для решения большинства проектов; такая ситуация также типична для большинства проектов, которые нужно завершить в сжатые сроки, но бывают случаи, действительно требующие особой самотдачи, и речь здесь идёт не просто о паре лишних часов в неделю. Прежде чем принять решение об увеличении нагрузки на группу, нужно знать, когда это уместно и как делать это эффективно.Когда нужно увеличить нагрузку
Менеджеру проекта и ведущим специалистам очень важно знать, когда нужно проситъ команду или её участника о дополнительных усилиях. Чтобы эта просьба нашла отклик, её причины должны быть обоснованы, а задачи — ясны каждому. Дополнительная работа потребуется, если необходимо следующее:• Завершить очередной этап в срок
Если очередной этап работы близится к концу и при этом есть ощущение, что можно не уложиться в сроки, нужно начинать сверхурочную работу уже сейчас, а не позже. Как сказано выше, не следует дожидаться начала следующего этапа, чтобы обнаружить проблемы с завершением текущего. Если чувствуете, что план может быть сорван, лучше приложить дополнительные усилия раньше, чем позже.
• Наверстать упущениое
Если не удалось уложиться в срок при выполнении промежуточного этапа работы, упущенное придётся навёрстывать. Помимо этого, нужно завершить следующий этап в срок. Если вы всерьёз хотите вовремя закончить работу над проектом, приложите дополнительные усилия уже сейчас.
• Справиться с возросшей конкуренцией
Если на рынке произошли серьёзные изменения, чтобы достигнуть успеха или просто не быть вытесненным конкурентами, реализацию проекта придётся ускорить. При этом, возможно, придётся добавлять новые функции к продукту или ужать план на месяц. Это потребует от всей группы полной самоотдачи.
Прежде чем просить кого бы то ни было посвятить проекту дополнительное время, убедитесь, что ваша просьба обоснованна. Постоянно прося команду об изменении графика работы или штурмуя каждую проблему работой в сверхурочное время, вы быстро исчерпаете продуктивность и эффективность команды. Нельзя заставлять людей слишком долго и слишком много работать сверхурочно. Этот подход следует использовать для навёрстывания упущенного или для адекватной реакции на внешние события, но нельзя делать сверхурочные частью нормального графика работы.
Как увеличивать нагрузку
Сверхурочная работа может потребоваться от одного из участников команды, функционального подразделения или от команды целиком. Не важно, сколько людей и кто именно привлекается к сверхурочной работе, существует ряд основных правил, которых необходимо придерживаться.• Определите продолжительность сверхурочных работ
Необходимо чётко определить продолжительность периода сверхурочной работы — он не может быть открытым или неопределённым. Следует поставить конечную задачу: уложиться в заданный срок или достичь определённого конечного результата;
• Создайте комфорт
Сверхурочная работа должна доставлять удовольствие. Обязательно предлагайте питание работающим во время обеденного перерыва, а также тем, кто задерживается на работе допоздна. Следите за тем, чтобы работники могли взять из дома всё необходимое для работы. Организуйте максимально комфортабельную рабочую среду для тех, кто не может работать дома, а также организуйте для них беспрепятственный вход и выход из офиса по окончании обычного рабочего дня. Следует подумать об организации дополнительного обслуживания, например, привлечения посыльных для разных поручений или возможности сдать вещи в химчистку, чтобы помочь сотрудникам сохранить силы и сосредоточиться на работе.
• Поддерживайте боевой дух
Когда от группы требуется самоотдача, проследите, чтобы все её участники работали сообща: все остаются, все помогают и вносят свой вклад. Если не нужно писать новый код, займите людей тестированием. Если нечего тестировать, бросьте всех на редактирование документации. Общая преданность делу и общая ответственность теснее сплотит группу и способствует развитию духа товарищества.
Из собственного опыта
В начале истории компании NuMega нам нередко приходилось работать сверхурочно. Мы часто работали по ночам и в выходные. Чтобы скрасить это время, дочь одного из сотрудников взялась готовить для нас. Она как раз училась стряпать и хотела попрактиковаться на нас. К счастью, у неё был талант и ей помогала мама. Конечно, свою пиццу мы получали тоже, но приготовленные ею обеды помогали нарушить однообразие.
Когда работы было особенно много, как правило, все работали сверхурочно, оставаясь после работы. Это было весёлое время, и часто сверхурочные часы превращались в вечеринку. Хотя людям приходилось жертвовать собственным временем и допоздна задерживаться на работе, все знали, для чего это делается, и верили, что наша работа важна для успеха общего дела. Когда работа была закончена, мы решили пригласить на празднование нового выпуска своих родственников. Мы понимали, какие неудобства сверхурочная работа доставила нашим семьям, и хотели как-то отблагодарить их за проявленное терпение.
• Информируйте о прогрессе
Если людям приходится много работать сверхурочно, они обязательно должны знать, что именно они являются двигателем проекта. Как менеджер проекта или ведущий специалист, вы должны показать команде, что их усилия оправдываются.
• Благодарите за труд
Это можно делать на собраниях или при личных встречах с отличившимися. Подумайте о специальных футболках, подарках и других наградах за особые заслуги. Непременно позаботьтесь, чтобы все работающие сверхурочно ощущали признательность за свой труд. Не забывайте и об их семьях. Все это отражается в первую очередь на них, и следует найти способ отблагодарить членов семей сотрудников за их жертвы.
Общие проблемы и решения
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Из собственного опыта
В преддверии выпуска последней бета-версии одного из продуктов NuMega нам приходилось работать все ночи и выходные напролёт. К сожалению, нельзя сказать, что наш сервер был с нами солидарен: в течение дня он постоянно зависал без видимых причин, останавливая при этом всю сеть. В результате мы не могли проводить сдачу разработанных фрагментов ПО и делать контрольные сборки, что просто убивало нашу производительность.
Проблемы продолжались в течение двух недель — чтобы избавиться от них, мы перепробовали все возможные средства. Наконец, мы подумали, что сервер перегревается, так как он стоял в старом помещении в самом центре здания (мы ведь только начинали!). Возможно, там плохая вентиляция, думали мы. На следующий день мы купили большой вентилятор на стойке и пару дней обдували им сервер, но — увы! — он продолжал виснуть.
Наконец мы поумнели настолько, что просто купили новый сервер. Если бы мы догадались поменять его в первые два дня, то смогли бы сэкономить три недели работы, времени и усилий.
Вы уверены, что завершили эту работу?
Вас никогда не спрашивали на контрольном собрании: «Вы уже закончили работу над Х?» На самом деле это очень расплывчатый вопрос, однозначный ответ на который дать очень трудно. Означает ли это, что код написан и его можно скомпилировать? Или реализованная функция нормально работала пару раз, когда вы пытались использовать её? А, может быть, выполнено блочное тестирование программы на всех поддерживаемых платформах и конфигурациях? А что это означает для тестировщиков из соседнего отдела? Обязательно заведите для себя определение «законченной» работы, и ознакомьте с ним всех, иначе вы запросто обнаружите людей, в поте лица работающих над тем, что вы «закончили» несколько недель назад.Борьба с нехваткой оборудования
Один из главных грехов фазы исполнения проекта — задержка работы из-за «нехватки оборудования». Если разработчику понадобится более ёмкий жёсткий диск, техническому писателю — новая мышь, а тестировщику — программа для мониторинга, следует доставить их немедленно. Никакие мелочи и пустяки не должны задерживать работу над проектами или снижать эффективность команды. Менеджер проекта должен неусыпно заботиться о личных нуждах, проблемах и потребностях каждого члена группы.Из собственного опыта
В преддверии выпуска последней бета-версии одного из продуктов NuMega нам приходилось работать все ночи и выходные напролёт. К сожалению, нельзя сказать, что наш сервер был с нами солидарен: в течение дня он постоянно зависал без видимых причин, останавливая при этом всю сеть. В результате мы не могли проводить сдачу разработанных фрагментов ПО и делать контрольные сборки, что просто убивало нашу производительность.
Проблемы продолжались в течение двух недель — чтобы избавиться от них, мы перепробовали все возможные средства. Наконец, мы подумали, что сервер перегревается, так как он стоял в старом помещении в самом центре здания (мы ведь только начинали!). Возможно, там плохая вентиляция, думали мы. На следующий день мы купили большой вентилятор на стойке и пару дней обдували им сервер, но — увы! — он продолжал виснуть.
Наконец мы поумнели настолько, что просто купили новый сервер. Если бы мы догадались поменять его в первые два дня, то смогли бы сэкономить три недели работы, времени и усилий.
Навёрстывайте упущенное
Хотя мало кто будет спорить с тем, что выдерживать внутренние сроки очень важно, они не помогут составить план действий при угрозе срыва конечной даты. Если что-то пошло не так, нужно внести коррективы, чтобы вернуть проект на намеченный путь. Это ещё одна ситуация, когда менеджер проекта зарабатывает свой хлеб. Непременно контролируйте ход проекта по внутренним контрольным точкам, а если при исполнении промежуточных этапов не удаётся уложиться в срок, предпринимайте соответствующие действия.Миритесь с недостатками своих сотрудников
Человек несовершенен. Не исключено, что придётся столкнуться с людьми, которые не желают верить в существование проблем или дают рекомендации на основе неполной информации. Спесь, как и застенчивость, утомление, истощение сил или личные проблемы могут стать причиной разных трудностей. Поддерживая работу над проектом в нужном русле, приходится иметь дело не только с технологиями, но и с человеческими недостатками. Изучите сильные и слабые черты характера каждого участника группы и обязательно руководствуйтесь этими сведениями, принимая решения.
Глава 13
Бета-тестирование
Бета-тестирование — это процесс проверки ПО внешними силами. В начале программы бета-тестирования новое ПО рассылается реальным или потенциальным заказчикам (бета-тестерам) для изучения, оценки и предоставления отзыва о его работе. Задача — получить от бета-тестеров объективную оценку возможностей и качества ПО.
Бета-тестирование позволяет получить ценные сведения о готовности ПО, прежде чем оно попадает к заказчикам. Программы бета-тестирования являются решающим фактором успеха в начале развития компаний, когда объём ресурсов, выделенных под проекты, ограничен. Бета-тестирование, как никакой другой способ, позволяет эффективно организовать тестирование программы. Оно не только расширяет возможности группы разработчиков в сфере контроля качества, но и обеспечивает поступление из внешнего мира объективных и достоверных отзывов о возможностях вашего ПО.
С другой стороны, плохо проведённое бета-тестирование означает, что не только разработчики, но и бета-тестеры лишь зря потратили на него своё время. В этой главе мы обсудим ключевые аспекты проведения хорошей программы бета-тестирования и способы улучшения программных продуктов с помощью бета-тестирования.
Бета-тестирование позволяет получить ценные сведения о готовности ПО, прежде чем оно попадает к заказчикам. Программы бета-тестирования являются решающим фактором успеха в начале развития компаний, когда объём ресурсов, выделенных под проекты, ограничен. Бета-тестирование, как никакой другой способ, позволяет эффективно организовать тестирование программы. Оно не только расширяет возможности группы разработчиков в сфере контроля качества, но и обеспечивает поступление из внешнего мира объективных и достоверных отзывов о возможностях вашего ПО.
С другой стороны, плохо проведённое бета-тестирование означает, что не только разработчики, но и бета-тестеры лишь зря потратили на него своё время. В этой главе мы обсудим ключевые аспекты проведения хорошей программы бета-тестирования и способы улучшения программных продуктов с помощью бета-тестирования.
Ценность бета-тестирования
Прежде чем говорить о способах проведения хорошего бета-тестирования, обсудим, в чём вообще его польза. Не понимая ценности бета-тестирования или не веря в её существование, вы никогда не выделите достаточно времени и средств, чтобы провести его на должном уровне. Вот самые значительные аспекты пользы от бета-тестирования:
• Проверка ПО в условиях реального мира
Независимо от того, насколько хорошо проведено внутреннее тестирование, воспроизвести в полном объёме все испытания, проводимые многочисленными бета-тестерами, было бы чрезвычайно сложно (если такая задача вообще выполнима). Если вы не ошиблись с подбором бета-тестеров, они помогут проверить работу новой программы на широком спектре вычислительных платформ и в самых разных ситуациях, все разнообразие которых вы скорее всего никогда не смогли бы охватить. Поскольку бета-тестирование выполняется реальными пользователями в реальных условиях, они часто обнаруживают такие ошибки, которые никогда бы не были найдены без их помощи.
Хорошие бета-тестеры позволяют проверить готовность ПО к использованию прежде, чем оно будет отправлено заказчику. Эта информация сама по себе уже стоит усилий, затраченных на проведение бета-тестирования;
• Проверка ПО в условиях реального мира
Независимо от того, насколько хорошо проведено внутреннее тестирование, воспроизвести в полном объёме все испытания, проводимые многочисленными бета-тестерами, было бы чрезвычайно сложно (если такая задача вообще выполнима). Если вы не ошиблись с подбором бета-тестеров, они помогут проверить работу новой программы на широком спектре вычислительных платформ и в самых разных ситуациях, все разнообразие которых вы скорее всего никогда не смогли бы охватить. Поскольку бета-тестирование выполняется реальными пользователями в реальных условиях, они часто обнаруживают такие ошибки, которые никогда бы не были найдены без их помощи.
Хорошие бета-тестеры позволяют проверить готовность ПО к использованию прежде, чем оно будет отправлено заказчику. Эта информация сама по себе уже стоит усилий, затраченных на проведение бета-тестирования;