Учет рабочего времени

Учет рабочего времениЖена моего брата как-то работала в крупной международной консалтинговой компании. V них рабочее время измерялось интервалами по шесть минут в течение всего рабочего дня, каждый день.

Они даже применяли специальный шифр для отслеживания использования рабочего времени: каждый сотрудник вводил его для заполнения формы индивидуального учета. Причем этот шифр не был 0, 9999 или что-либо легко запоминающееся, а нечто вроде 948247401299.

Поэтому и не нужно допускать, чтобы правила и условности, изобретенные бухгалтерским отделом, переносились на вашу работу над проектом.

Измеряйте, сколько работы еще осталось. Не обманывайте себя и свою команду, вводя фиктивные показатели работы. Используйте перечень задолженностей.

Спринты в методологии Scrum

В методе Scrum [Sch04] каждая итерация называется спринтом (sprint) и длится 30 дней. Перечень задолженностей 8 спринте содержит лишь те задачи, которые решаются в рамках текущей итерации, он показывает также, сколько времени требуется на завершение каждой задачи.

Ежедневно каждый член команды корректирует количество часов до окончательного решения своей задачи. В любой момент, если общее количество часов для всех задач превышает фактическое время до окончания спринта, эти задачи должны быть перенесены на следующую итерацию. Если же до завершения итерации осталось больше времени, чем требуется для данного набора задач, тогда можно добавить новые задачи в список. Заказчикам обычно это очень нравится.

На что это похоже

Это очень удобно: знать, что уже сделано, что осталось сделать и в какой последовательности.

Сохраняйте равновесие

Шести минутные единицы измерения времени слишком мелки и не подходят для гибких проектов.

Единицы длиной в неделю или месяц слишком велики и тоже не подходят для гибких проектов.

Сосредоточьтесь па выполнении функций, а не на календаре.

Если вы тратите слишком много времени на отслеживание того, сколько времени вы тратите на работу, так что у вас остается слишком мало времени собственно на работу над проектом, это значит, что вы тратите слишком много времени на отслеживание того, сколько времени вы тратите на работу. Все ясно?

Из сорока часов рабочей недели далеко не все часы можно посвятить работе над кодом по проекту. Совещания, телефонные звонки, e - mail и другая деятельность могут отнимать у вас довольно много рабочего времени.

Прислушайтесь к пользователям

"Пользователи всегда чем-то недовольны. Это не твоя вина, просто они слишком глупы и плохо читают это чертово руководство пользователя. Это не ошибка в программе, они просто не понимают ничего. Это их трудности”.

Энди как-то работал в одной крупной компании, которая занималась разработкой программных продуктов для высокопроизводительных рабочих станций под Unix. Это не та конфигурация, на которой вы можете просто запустить setup.exe или pkgadd, чтобы установить программное обеспечение. Нужно копировать файлы и настраивать различные параметры для конкретной рабочей станции.

Энди и его команда полагали, что все идет хорошо, пока однажды Энди, проходя мимо отдела техподдержки, не услышал, как инженер со смехом говорит заказчику по телефону: “Это не баг: вы сделали ту же ошибку, что и всё". И дело было вовсе не в этом одном инженере. Весь отдел от души смеялся над бедными, наивными и глупыми пользователями.

Наверняка, и вы попадали в ситуации, когда вам, несчастному пользователю, приходилось залезать в какой-нибудь загадочный системный файл и записывать в него не менее загадочный набор символов, чтобы заставить какое-либо приложение работать. Никаких сообщений об ошибке, ни падения системы, просто черный экран после внезапного сбоя приложения. Хорошо еще, если этот случай упоминается в инструкции по инсталляции продукта, но, скорее всего, примерно 80% пользователей не обратили на него внимания и потому стали объектом насмешек со стороны инженеров технической поддержки компании - разработчика.

Это баг! Когда что-нибудь ломается, пользователь должен получать максимально подробную информацию о случившемся. Черный экран или внезапное завершение процесса (без объяснений) недопустимы. Хуже того, в приведенном выше примере компания - разработчик получила реальную обратную связь от своих пользователей, но, вместо того чтобы заняться устранением проблемы, лишь смеется над несмышлеными клиентами!

Любая ошибка в программном продукте или в документации, или даже в нашем понимании поведения пользовательского сообщества это проблема самой команды разработчиков, а ни в коем случае не пользователей.

tel-icq