Если вы просите команду выбросить результаты двухнедельного труда, нужно быть уверенным, что цена этого шага учтена в принятом решении. Нужно объяснить команде все причины, по которым вносимые изменения считаются правильными, и раскрыть факторы, подкрепляющие это убеждение. Пригласите, по возможности, кого-нибудь из команды поучаствовать в обсуждении, проводимом перед принятием окончательного решения.
Не бойтесь вносить изменения. Перемены ведут к улучшению, и они неизбежны. Однако существует множество различных вариантов изменений и много различных способов для руководителя по их внедрению в работу команды. Если раньше проект шел на запад, а теперь вдруг понадобилось, чтобы он пошел на север, для поворота команды на север от вас потребуются те же навыки, которые применялись для того, чтобы заставить команду двигаться на запад (хотя придется вдвое увеличить скорость и наполовину избавиться от формализма). Вернитесь к главам 3, 4, 11 и 12 и почитайте изложенные в них инструкции по руководству в условиях перемен.
Производственный конвейер по созданию программного кода
Прагматичный взгляд на миттельшпиль фокусируется на работе программистов, создающих код. Единственный способ поступательного движения связан с тем, что с каждой написанной строкой программного кода проект приближается к своему завершению (бесконечная возня с любимой функцией, ненужная оптимизация и тому подобное прогрессу не способствуют). До того как программисты приступят к созданию кода, либо они сами, либо кто-то другой затрачивает усилия на планирование и проектирование, целиком направленные на подготовку для них эффективной последовательности работ, выполняемых до тех пор, пока тикают часы проекта. Это называется производственным конвейером по созданию программного кода, для управления которым существует масса различных технологий.[84]
Следить за слаженным функционированием конвейера входит в обязанность руководителя проекта. Программисты и сами могут управлять работой конвейера, решая, кто чем должен заниматься,[85] но руководитель проекта все равно будет отвечать за то, чтобы команда программистов в процессе выполнения работ получала всю необходимую поддержку. Он может отслеживать ход процесса, проводить совещания, надоедать всем своими требованиями о выполнении принятых решений или в отдельных случаях заниматься устранением оставшихся проблем, касающихся замысла проекта[86] (рис. 14.4). Руководителю проекта, вероятно, придется действовать, опережая на несколько дней программиста, завершая подготовку замысла и «подпитывая» производственный конвейер. Если руководитель проекта отвечает за нескольких разработчиков, ему понадобится тщательнее распределять свое рабочее время, чтобы успеть справляться с запросами нескольких конвейеров (вот почему ведущий программист должен хотя бы часть этих функций взять на себя).
В книге «Web Project Management: Delivering Successful Commercial Web Sites» (Morgan Kaufmann, 2001) ее автор Эшли Фридлейн (Ashley Friedlein) назвал это краткое совещание с командой и детализацию следующей части предстоящей работы инструктажем. Он писал: «Для достижения максимальной эффективности и скорости разработки ваши инструктажи должны быть построены так, чтобы всегда опережать текущее состояние дел. Как только часть работы будет завершена, у вас должен быть наготове инструктаж, относящийся к следующей части». Эти инструктажи готовятся на основе технических условий (не утративших своей актуальности), но включают в себя все новое или измененное, о чем должны знать программисты. Без активного инструктирования программистов в ходе миттельшпиля может возникать любое количество факторов, препятствующих завершению работ и замедляющих движение конвейера; к этим факторам относятся проблемы потребительских качеств, проработка внешнего дизайна, работы, выполняемые другими программистами, проблемы рыночного характера, технические проблемы или какие-то внешние зависимости. Поскольку руководители проектов зачастую обладают самым разнообразным набором навыков, никто лучше их не справится с запуском конвейера, с частичным или полным решением проблем и со сглаживанием шероховатостей прежде, чем с ними придется иметь дело программистам. (Сюда же относят и выявление несостоятельных программистов, находящихся в состоянии ступора и либо не признающихся в этом, либо еще не разобравшихся в своем состоянии.)
Рис. 14.4. Окончательная детализация технических условий (замысла) может проверяться или завершаться параллельно руководителем проекта или проектировщиком. Это придает смысл понятию производственного конвейера по созданию программного кода
Успех этих дел определяется ответами на следующие четыре вопроса:
Какие работы находятся в стадии выполнения? Существуют ли проблемы, не позволяющие программистам завершить текущие работы? Если они существуют, их надо устранить (естественно, проблемы, а не работы). Для проекта это авральное состояние. Если программист не может активно создавать программный код, проект останавливается. Нет ничего более важного, чем решение проблемы, застопорившей работу программиста. Задайте ему простой вопрос: «Как я могу помочь тебе решить проблему?» Если вы можете помочь, программисты обязательно поставят вас в известность Если блокирующая работу проблема заключается в какой-то зависимости (например, Фрэд должен завершить работу 6, прежде чем Боб приступит к работе 7), рассмотрите возможность загрузить программиста другой работой, пока проблема не будет снята.
Обладает ли программист всеми знаниями и понятиями, необходимыми для того, чтобы текущая работа шла в русле технических условий? Всегда есть такие вопросы и пробелы, которые проявляются только в процессе выполнения работы. Способности к самостоятельному устранению таких пробелов у программистов развиты по-разному, у кого-то лучше, у кого-то хуже. Руководитель проекта или проектировщик должен быть способен сам или с чьей-нибудь помощью обнаружить и устранить эти пробелы. Иногда их можно предвидеть, к примеру, если в процессе обсуждения технических условий проблемы, касающиеся данной работы, так и остались нерешенными.
Какова следующая группа выполняемых работ? Вот тут-то и начинается настоящее управление конвейером: нужно всегда идти на шаг впереди программистов (см. рис. 14.4). Если текущие работы оформлены хорошо, нужно перенести внимание на следующие работы производственного конвейера. Эти следующие работы должны рассматриваться в качестве очередного наиболее важного этапа реализации проекта. Нужно всегда стараться сделать самую ответственную работу в первую очередь, даже если она окажется самой трудной. Для каждой ставящейся на конвейер работы нужно учесть возможность проблем, которые могут замедлить или застопорить работу программиста, когда он к ней приступит. Эти проблемы нужно выявить и разрешить.
Была ли реально завершена последняя работа? Этот вопрос касается выполненных работ. Кому-то нужно следить за результатами контрольной проверки работы и удостовериться в том, что она отвечает всем ожиданиям заказчика. Действительно ли последняя из выполненных работ наделила продукт требуемыми функциональностью и поведением? Согласна ли с этим команда тестировщиков? Прошли ли все блочные тесты? Занимается ли кто-нибудь элементарным обнаружением ошибок, чтобы отследить все упущения? Ежедневные сборки (которые будут рассмотрены в следующей главе) представляют собой простой способ отслеживания всех этих вопросов, поскольку всегда можно проверить текущее состояние проекта, обнаружить пробелы в законченном продукте и понять, что необходимо доработать. Чем сложнее работа, тем важнее становятся эти обстоятельства.
У одних программистов чувство ответственности за свой конвейер больше, у других – меньше. Многие будут тщательнее выискивать проблемы одного рода (технические) и стараться игнорировать или откладывать до поры до времени проблемы другого рода (относящиеся к бизнесу и политике). Частью ваших взаимоотношений с каждым программистом должно стать понимание, сколько сил вам нужно приложить, чтобы управлять его конвейером. Кем именно это будет сделано, не так уж и важно. Активно проверять качество работ может кто-то другой. (Это относится к назначению ролей, о чем рассказывалось в главе 9.)
Агрессивный и консервативный варианты производственного конвейера
Иногда конвейеру разработки кода нужно опережать команду программистов всего лишь на три работы (если на каждую работу требуется два дня, то на выполнение трех таких работ понадобится больше недели). Чтобы прийти к согласию по поводу следующей логической последовательности работ, вполне может хватить и свободной дискуссии между руководителем проекта и программистами. (Или, если есть главный критический путь или график Гантта, в котором отражены не только прошлые недели, конвейер можно загрузить с его помощью.) Таким образом, создается вполне достаточный по объему буфер, позволяющий программисту и руководителю проекта своевременно подобрать подходящую работу вместо той, которая застопорилась из-за той или иной не решенной своевременно проблемы, и продолжить выполнение, пока проблема не будет решена.
