Если клиент не интересуется проектом, то этот проект подвергается опасности, еще не начавшись. Если у клиента нет времени рассказать, зачем ты пишешь для него эту программу, то, возможно, ее вообще не стоит писать.
В двух красивых фразах, которые вы успеете сказать в лифте, должна быть заключена суть проекта или идеи. Необходимо рассказать, что собой представляет проект, для чего он нужен и почему стоит купить именно его.
Для [адресат сообщения]. Объясняется, на кого ориентирован проект или кому он мог бы принести пользу. ♦ Который [утверждение о необходимости или о предоставляющейся возможности]. Расширенное представление проблемы или потребности, стоящей перед клиентом. ♦ Это [название продукта]. Проект начинается с присвоения имени. Название важно, так как оно помогает понять ваши намерения. ♦ Относится к [категория продукта]. Объясняется, чем, по сути, является данный продукт или услуга и какова полезная нагрузка проекта.
Что, если начинать каждый проект вот так? Предположим, в начале каждого проекта вы вместе с командой пытаетесь ответить на четыре простых вопроса о себе. • В чем я особенно хорош? • Как я привык работать? • Что я ценю? • Каких результатов можно от меня ожидать?
Как бы я ни обожал тот дух и те принципы, на основе которых работает гибкая команда, не имеющая формально распределенных ролей, должен признаться, что попытка пригласить глубоко консервативную команду разработчиков и сообщить ее членам, что им нужно «самоорганизоваться», на практике у меня никогда не срабатывала.
Иными словами, пусть аналитик знает, что разработчик имеет полное право беседовать с клиентом (это даже приветствуется). Пусть тестировщики не удивляются тому, что разработчику придется написать немало автоматизированных тестов. А если в вашем проекте не будет специального разработчика пользовательских интерфейсов, это не означает, что никто не собирается заниматься юзабилити и дизайном. Разумеется, все это будет сделано, только другими людьми, которые исполняют в гибком проекте сразу несколько ролей.
Разумеется, индивидуальная ответственность развивается только в командах, наделенных реальной полнотой полномочий. Давая команде право самостоятельно принимать решения и делать то, что она считает нужным, вы освобождаете пространство для инициативы и работы по собственному усмотрению. Люди начинают решать проблемы, не дожидаясь, пока им позволят это сделать.
Итак, как добиться самоорганизации своей команды? ♦ Команда допускается к планированию, оцениванию и может распоряжаться проектом. ♦ Вы не придаете особого значения ролям и их названиям, а сосредотачиваетесь на бесперебойном производстве функциональных, протестированных программ. ♦ Вы ищете людей, способных брать на себя инициативу, то есть тех, кто сам прокладывает себе путь, а не сидит и не дожидается остальных.
Качество выполнения гибкого проекта от начала до конца – задача всей команды. Отдела обеспечения качества (Quality Assurance, QA) нет, качество обеспечиваете вы сами, когда проводите анализ, пишете код или управляете проектом. Качество гарантируется на каждом шагу, поэтому в гибком проекте вы не услышите вопроса: «И как отдел гарантии качества проморгал эту ошибку?»
