|
 К сожалению, некоторые люди уверены, что существует идеальное программное обеспечение для управления временем, решающее все проблемы с составлением графика. Данную проблему нельзя преодолеть лишь с помощью технологии, в ней играет роль привычка, не считая непредсказуемую сущность разработки программного обеспечения (например, знаете ли вы, сколько ошибок может обнаружиться в вашем ПО после его выпуска на рынок?).
Учебник PRINCE2 утверждает, что сотрудник способен продуктивно работать лишь 3,5 дней в неделю (из общего числа 5 дней). Остальное время занимают такие задачи, как совещания, ответы на звонки, посещение прощальных вечеринок коллег и прочее. Руководство компании считает, что персонал способен продуктивно работать 4,5 дня в неделю; это абсолютная фантазия; желание, чтобы нечто соответствовало действительности, не делает это реальным. Вероятно, при этом неправильно применяется закона Паркинсона.
Закон Паркинсона гласит, что люди используют все время, данное им на выполнение задачи (например, складывание 1000 журналов в пачку может занять 2 часа, но если дать человеку 4 часа на выполнение этого, он потратит 4 часа). Данный принцип часто неверно понимается в том плане, что от людей можно получать больше, если давить на них, заставлять их укладываться в невероятные сроки. Такой подход может дать краткосрочный выигрыш, но также приводит к унынию персонала и повышенной текучести.
Есть более надежные способы повышения производительности (например, наём временного системного администратора вместо использования программистов для выполнения работы техподдержки). Закон Паркинсона полезен лишь для вас самих – его нельзя переносить на других людей.
Время программиста хорошо планируется с помощью метода доказательного планирования Джоула Сполски, заключающегося в неожиданном снятии с задания, дающем сильный эффект. В одной компании данная практика была общепринятой (т.е. программисты снимались с задания для выполнения другого задания). Результат был предусмотрен графиком, имевшим недостоверные сроки сдачи, но все же график выполнял свое назначение, так как производилось отслеживание задач.
С целью устранения данной проблемы была придумана система, основанная на теории критического пути, названная ‘главный/вспомогательный программист'. Рассмотрим пример ее действия; у вас есть два программиста в проекте. Один из них называется главным и имеет 20 часов выделенной работы, другой называется вспомогательным, он имеет 10 часов работы. Если появятся 5 часов новой работы, они передаются вспомогательному программисту. Вспомогательный теперь будет отставать на 5 часов от главного, но все же он может закончить свою работу раньше главного. Проект не может считаться завершенным, пока главный не закончит все свою работу, поэтому можно умышленно дать главному программисту больше работы, чем его товарищу (например, в соотношении 65:35).
Есть компания, успешно управляющая временем с помощью простых решений для своих частных условий. Здесь назначают центрального контролера времени: если требуется заставить программиста работать над чем-то, то его приходится бронировать через контролера времени. Это делается путем подачи запроса на выделение pecypca по электронной почте. Простая сводка рабочего задания выглядит так:
• Имя клиента: Blue Widgets Inc.
• Имя задания: устранение ошибки, идентификатор: 59
• Предпочтительное лицо: Майкл Смит
• Когда он будет готов: 11:00 вторник (26-е июля)
• Срок завершения задания: 5:00 вторник (26-е июля)
• Расчетное количество часов: 1-2 часа
• Приоритет: нормальный
Контролер времени использует данную информацию для ввода новой записи в календарь программиста в Microsoft Outlook. Когда программист придет на работу, он увидит, что ему предстоит несколько часов устранять ошибки. Данная система не идеальна, но намного лучше подхода «бегать и ликвидировать пожары», применяемого в других местах.
Следует отметить, что 'имя задания' ссылается на идентификатор ошибки, система разрешения проблем абсолютно необходима любой фирме разработки ПО. Руководитель проекта должен выделять время на устранение ошибок в спокойные периоды в течение всей недели и в подходящие контрольные точки (например, между основными этапами).
Первоначально ошибки должны передаваться непосредственно руководителю проекта, а не программистам. Исходя из этого, руководитель проекта определяет приоритеты и перераспределяет ошибки или добавление незначительных характеристик, они должны передаваться программистам отдельными порциями, а не всей кучей сразу.
Еще одной идеей, предложенной данной компанией, является создание должности под названием ‘обслуживающий программист'. Задачей данного программиста является выполнение исправлений и изменений в старых проектах.
Это позволяет программистам начинать работать над новыми проектами, не беспокоясь, что их в любое время могут вытащить для устранения ошибок в проекте, над которым они работали в прошлом году.
Лучше всего для устранения ошибки подходит тот, кто изначально ее запрограммировал, но спустя год его польза сходит на нет. Обслуживающему программисту придется потрудиться, чтобы понять бизнес-правила сложной программной системы, которой они не занимались, они больше подходят для более простого обслуживания вебсайтов.
Вы поймете, что ваш график проекта хорошо работает, если программисты приходят к вам с вопросами каждые несколько дней, они знают, что нужно делать дальше, и не теряют темп. Другой признак – после окончания проекта появляется очень мало зарегистрированных проблем, касающихся отсутствующей функциональности (т.е. программисты не забывают запрограммировать элементы).
Часто плохое управление временем не является результатом плохого составления графиков, а обусловлено проблемой в управлении проектами. За назначение приоритетов отвечает руководитель проекта, а не программисты или управляющий текущими операциями. Здесь наблюдаются настоящие проблемы, когда высшее руководство назначает приоритеты без понимания опосредованного воздействия на другие проекты. Люди слишком много беспокоятся о сроках сдачи, в то время как они должны больше переживать о потере времени, вызываемой недостаточно оптимальными методами планирования.
Примечания
Реально оценивайте наличие ресурсов. Нужно учитывать выходные и праздничные дни и время, затрачиваемое людьми на не связанную с проектами деятельность. Средняя рабочая неделя равняется лишь 4 дням после учета выходных и праздников, обучения, болезней, и т.д. Из этих 4 дней, как минимум еще полдня тратится на другие обязанности даже преданным персоналом - например, проверка качества других проектов, линейное руководство и совещания.
|
