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

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

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

Хорошие рекомендации по составлению графиков и распределению времени приводит на своем сайте Джойл Спольски (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! Потому что эти ребята выпуск своего продукта по нескольку раз не отодвигали…