Навеяно топиками о книге Rework, самой книгой и топиком "Почему программисты срывают сроки". Я постараюсь рассказать, почему за один месяц изменилось мое отношение к планированию и работе с командой, не без помощи книги от 37signals.Так случилось, что мне посчастливилось стать руководителем нового проекта в небольшой пока еще компании. Именно посчастливилось. В основном, потому что, положа руку на сердце, достаточного опыта для руководства каким бы то ни было проектом «с нуля» у меня нет. Да, мне пришлось по жизни заниматься разнообразными вещами, никак не связанными с профессией, но я бы не сказал, что они четко выражаются моей специализацией. То есть, назвать себя чисто верстальщиком, дизайнером, веб-программистом, менеджером, системным администратором, а уж тем более руководителем, я не могу. Вернее, не мог.
С самого начала мой неосознанный подход к работе был прост — что-то вроде «кто, если не мы». Так, я не мог пройти мимо возникшей проблемы, зная, что при этом простаивает все предприятие, или же она вызывает у меня чувство внутреннего дискомфорта. В небольшой команде особо остро чувствуется взаимодействие между людьми, поэтому в момент, когда один человек выпадает из общей цепочки, начинаются проблемы. Зачастую, именно мне приходилось их решать, в силу своей разносторонней
Так вот, подобные правила и опыт позволяют мне планировать работу небольшой команды, которая занимается довольно интересным и абсолютно новым для себя делом.
Учитывая, что условия, в которых мы сейчас работаем, почти схожи с «гаражными», в хорошем смысле слова, у меня появилась возможность опробовать несколько приемов, одна мысль о которых раньше казалась немыслимой.
Отказ от планирования
Естественно, сказка, когда ты можешь безрезультатно до посинения заниматься делом, приносящим тебе не только эмоциональное удовлетворение, но и подкрепляемое материально, невозможна. Лозунг «продукт будет выпущен, когда мы посчитаем его готовым» — по-моему, не более, чем публичный ход. Руководству и инвесторам нужны результаты, оправдание потраченного времени и финансов, поэтому разработчики еще до начала работы обременены по крайней мере первым показателем, запечатленным на бумаге. Задачи выражаются в часы, часы в задачи, и насколько это оправданно, сможет показать только время, мастерство руководителя и всех людей, принимавших участие в создании плана.
Почти одновременно с согласием руководства на разработку проекта я получил существенный довесок — необходимость разработать детализированный план работ по нему. От этапа к этапу, с четким описанием всех исполнителей и прогнозами по временным затратам. То есть от меня требовался план того, что сформировалось в моей собственной голове только лишь как идея.
Не скрою, на тот момент я считал этот подход единственно верным, и воспринял его с огромным энтузиазмом. Мысль однажды расчертить все до точки, а затем лишь следовать намеченному, изредка внося коррективы, конечно радует. Но я ошибался.
И главная, непростительная ошибка, как я понял, преследовала меня долгие годы, с самого начала работы в IT. Я довольно долго шел к этому знанию, от простых тезисов вроде «нельзя изучать новые технологии, когда начинаешь разрабатывать новый проект/сайт/программу». Сейчас моим лозунгом, не оправданием, а именно лозунгом становится фраза: «нельзя планировать то, чего ты еще никогда не делал».
Мысль проста до безобразия, но путь к ней оказался долог и тернист. Действительно, как программист, которому необходимо отказаться от привычного языка программирования и перейти в непривычную для себя область, может четко и однозначно ответить на вопрос «сколько займет создание этого модуля», если до этого он подобным не занимался? И найти подсказку, нагуглить что-то не получится — этого просто еще никто не делал. Приходится либо опираться на свой опыт, обозначать предполагаемый срок работы, а затем рвать тельняшку и трудоголить, пока задача не будет решена, скорее всего с опозданием. Либо честно ответить — не знаю, что не всегда позволяет самооценка.
Важно конечно сделать небольшую поправку — команда, в которой мы работаем, вполне сформировалась, поэтому перетасовывать состав и нанимать новых сотрудников — профессионалов в своей области, конечно полезно, но вот только окончательно сформулировать требование для такого человека очень тяжело — ведь до конца непонятно, какая часть работы станет в проекте основной. Причем, не снимая с себя ответственности, могу сказать, что неизвестность эта связана не с отсутствием хорошего планирования, а по большей части с «первопроходным» туманом в разработке. Выходит, я не могу составить хороший план, пока не начну разработку, а разработку нельзя начинать, пока не будет хорошего плана.
Выход один — можно лишь назначить некоторые вехи в работе. Конечно, они не должны быть оторваны от жизни, и за словами «пилотный запуск» должно скрываться четкое понимание требований, которые в него входят не только у руководителя, но и у команды.
Общение
Пока разработчик загружен своим небольшим участком работы, он оторван от внешнего мира. Все, что у него есть — входные и выходные параметры. Он знает, что должен делать его модуль или функция, или что угодно еще, для чего это необходимо, но остальная работа выпадает из поля зрения.
Мне исключительно не нравится такой подход. Когда разработчик интерфейсов поднимает голову от макетов и кода, он ошарашенно озирается по сторонам, пытаясь сравнить, что изменилось в продукте в несвязанных с его работой частях. Поэтому я не стесняюсь тратить время на нелюбимые совещания, и провожу их, проговаривая раз от раза, что представляет из себя проект на данном этапе развития, после чего каждый член команды четко понимает, что и для чего нужно. Помимо всего прочего, программист не стесняется в таком общении поправить разработчика баз данных и наоборот. Да и я сам выношу из него более четкое понимание и представление конечного результата нашей работы.
Для планирования такое живое общение — только плюс. Вместо сухого «совещательного» тона, я могу довольно точно и быстро понять, какая задача съедает слишком много времени и какой подход себя не оправдал. И вместо того, чтобы исправлять и заново строить планы, нам достаточно лишь импровизировать и быстро, фактически на ходу, подкорректировать направление движения.
Еще один немаловажный момент, который я встречал в литературе, но смог осознать лишь после прочтения Rework-а. Идея сама по себе не стоит и ломаного гроша. Если она была обдумана, посчитана, после чего легла на полку — грош ей цена. Поэтому стоит избегать этой вполне обоснованной боязни — поделиться с кем-то своими идеями, идеей проекта, над которым вы работаете. Страх потерять первенство в своей области можно преодолеть, потренировавшись на знакомых и друзьях. Они — самая благодарная публика, которая сможет довольно объективно отреагировать, а порой поделиться хорошим советом с вами. Не бойтесь — красть идею никто не будет, ведь для этого нужна реализация, а вы как раз ею и занимаетесь. Даже если на относительно ранних этапах кто-то начинает работу над аналогичным проектом — вы все равно на коне. Отметая мысль о коллективно-бессознательном, если вы любите свое дело, конкурентам останется лишь догонять, копируя вас.
Вместо выводов
Для того, чтобы осмелиться отказаться от планов, на которые очень непросто полагаться, мне потребовался месяц. Чтобы дойти до этой мысли — больше двух лет. Планы подстегивают, не дают расслабиться, но плохо мотивируют. Мы придумываем себе временные рамки, часто взятые из воздуха, в которые трудно уложиться. Любой сорванный план — это падение общего духа не только в команде. Даже если вы работаете фрилансером и затягиваете сроки, интерес к делу падает, после чего страдает качество. Я попробовал сказать планам нет и начать импровизировать. Посмотрим, во что это выльется.
