Журнал «Компьютерра» N 32 от 5 сентября 2006 года

Каждый из нас обменивает свое собственное время на что-либо. Самый распространенный способ потратить время - это купить на него деньги. Так поступают, пожалуй, все работающие люди, точно так же поступает и Василий. Работая программистом, он за свои 176 часов (при восьмичасовом рабочем дне) ежемесячно приобретает… ну, допустим, штуку вечнозеленых. О том, в каком городе и в какой организации ему это удается, уточнять не будем. У него остается еще 304 непотраченных часа в месяц, так что продолжим их делить. Время нерабочее делится на время околорабочее и на досуг. Околорабочее отнимает в среднем по четыре часа каждый будний день - это время от утреннего будильника до прихода на работу плюс время на то, чтобы прийти после работы в себя. Васе ведь надо добраться до дома, покушать, поваляться полчасика на диванчике, чтобы утрамбовать вертящиеся в голове мысли… А оставшиеся 52 часа в неделю - это его досуг. Два шестнадцатичасовых выходных и пять четырехчасовых вечеров тратятся на общение с друзьями и с подругами, на просмотр фильмов и телепередач, на чтение журналов, на домашние дела и прочие мелкие преобразования собственного информационного и физического пространства, направленные в основном в сторону отдыха и получения удовольствий. Если мы сейчас вдруг возьмем и начнем советовать Васе, как ему следует распоряжаться своим досугом, то у нас появится шанс оказаться именно там, куда Вася нас пошлет после наших указаний. Так что оставшаяся часть статьи посвящена вопросу о том, как не дать проектам и идеям задохнуться в дефиците самого дефицитного ресурса.

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

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

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

Однако Василию все-таки следует научиться планировать свое время. Во-первых, потому, что когда существует множество вещей, коими надо заняться, их просто невозможно удержать в голове все. А забыть о чем-нибудь - это почти всегда неприятно… Во-вторых, потому, что до тех пор, пока проект не будет распланирован хотя бы в общих чертах, вряд ли можно судить о его выполнимости. В-третьих, потому, что даже если суровая действительность ехидно насмехается над составленными графиками, эти графики будут по-прежнему отражать список работ, которые необходимо выполнить, и будут по-прежнему помогать выделить среди них приоритетные. В общем, пусть Вася дочитывает эту статью, а мы перейдем от вопроса «зачем?» к вопросу «как?».

Хорошие рекомендации по составлению графиков и распределению времени приводит на своем сайте Джойл Спольски (Joel Spolsky), известный программист, бизнесмен и публицист из Нью-Йорка. Суть его рекомендаций можно свести к следующим основным пунктам:

Для распределения собственного времени в рамках работы над конкретными проектами не подходят монстрообразные инструменты а-ля Microsoft Project. Гораздо лучше использовать простые табличные инструменты, такие как Microsoft Excel, или сервисы Web 2.0, аналогичные описанному ниже Voo2Do, которые не будут отвлекать от процесса составления расписания сложностью своего интерфейса.

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

Расписание должно быть простым. Джоэл предлагает составлять его в виде удобной и понятной таблицы, в которой всего семь столбцов: проект, задание в рамках проекта, приоритет задания, первоначальная оценка времени работы над заданием в часах, текущая оценка этого времени, количество уже потраченных на задание часов, и наконец, количество часов, которое еще предстоит на него потратить. Шестой и седьмой столбцы в сумме должны составлять пятый. Две оценки общего времени работы (первоначальная и текущая) нужны для того, чтобы работала обратная связь. Они помогают понять те иллюзии, которыми вы руководствовались при составлении графика, и таким образом с каждым разом улучшают качество планирования времени. Один из законов Мерфи применительно к программированию гласит: если программу мыслилось написать за N часов, то реально она будет написана за рN часов. Это нормально, если для первых графиков соотношение между четвертым и пятым столбцами таблицы окажется именно таким. Обратная связь помогает его уменьшать.

Каждый проект должен состоять из нескольких заданий. В примере, приведенном на рис. 1, таким проектом является добавление проверки орфографии, которое разбито на три задания. В этом же примере путем сравнения 4-го и 5-го столбцов видно, как изменилась оценка времени работы над каждым из заданий после начала работы.

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

График работы над проектом может составлять только тот программист, который собирается сам писать код. Любые попытки навязывания графиков «сверху» обречены на провал. И ни в коем случае нельзя позволить менеджерскому составу изменять оценку времени работы над заданиями. Графики служат для распределения собственного времени, и если начальство вносит в график коррективы, то иногда даже лучше жить при двух графиках. В одном начальство будет рисовать свои цифры, а другой, собственный, должен быть более реалистичным.

Если у вас есть охапка деревянных чурбанов, и эта охапка ну никак не желает залезать в предназначенную для нее коробку, то выбор у вас небольшой: либо вы берете коробку побольше, либо выкидываете несколько чурбанов из охапки, упаковывая оставшиеся в коробку. Но вы никак не можете уменьшить размер деревянных чурбанов, а если вы думаете, что можете, то вы просто обманываете себя. То же самое и с планированием времени. Если вы хотите выпустить релиз через шесть месяцев, а по расписанию необходимо еще двенадцать, то имейте в виду, что время работы над выполнением каждого задания невозможно сократить. Либо вы отодвигаете дату релиза на подальше, либо убираете из расписания часть заданий. Второе, вообще говоря, более разумно, так как выгоднее выпустить в срок менее функциональный продукт, чем откладывать его выпуск. Поясним на простом примере с игровыми приставками. Что лучше: Microsoft Xbox 360 или Sony PlayStation 3? В теории PlayStation 3 лучше - там и процессор Cell, и Blu-ray-привод… но деньги-то ведь сейчас делает Microsoft! Потому что эти ребята выпуск своего продукта по нескольку раз не отодвигали…