Пилотный проект призван был определить, насколько все это экономически оправданно. Используя эмпирический метод разработки программного обеспечения, вице-президент мог бы это быстро оценить. Также можно было бы в ходе пилотного проекта создать наиболее важную часть приложения. Вице-президент предположил, что ему нужно только три итерации разработки программного обеспечения. Для этого необходимы три разработчика и бюджет в 125 тысяч долларов.
Чтобы получить одобрение пилотного проекта, он приготовил презентацию, с которой направился к руководству, менеджерам своего отдела и в IT-отдел. Он обсудил с ними, что именно хотел бы сделать. Первый слайд презентации устанавливал цель пилотного проекта: определить, будет ли это приложение для смартфона хорошей инвестицией для организации. Он показал, как приложение встраивается в бизнес-стратегии организации, и бегло описал суть эмпирического процесса разработки – как это работает и почему он хочет его попробовать. Затем шло описание всего проекта. Он рассказал, что результатом пилотного проекта может стать работающее приложение, которое в дальнейшем можно совершенствовать. Полная стоимость приложения может быть экстраполирована на основании данных трехмесячного пилотного проекта. Также вице-президент и вся организация получат шанс понять, подходит ли эмпирический процесс для их компании.
Он немного подправил свой план по результатам замечаний, в частности добавил в команду разработки проекта менеджера из IT-отдела, который имел опыт работы с итеративным, инкрементальным процессом разработки программного обеспечения. Это увеличило бюджет до 170 тысяч долларов, но могло помочь IT-отделу дать оценку эмпирическому процессу разработки. Представитель IT-отдела должен был стать менеджером пилотного проекта. При наличии свободного времени ему также следовало помогать команде разработчиков с тестированием приложения.
Вице-президент получил одобрение при условии, что все заинтересованные лица в его отделе и в IT-отделе смогут проверять динамику в разработке приложения каждый месяц.
Формирование команды
Когда пилотный проект одобрили, первым шагом стало формирование команды с участием проект-менеджера из IT-отдела. Изначально было решено делать проект только своими силами, без привлечения сторонних разработчиков. Затем в компании выяснили, кто из сотрудников подходит для участия в пилотном проекте. О том, можно ли сотрудника считать хорошим разработчиком, можно узнать по его способности создать инкремент программного обеспечения. И конечно, лучше, если это станет ясно через месяц после начала разработки, чем по окончании 12 месяцев каскадного проекта. В итоге была создана IT-команда, каждый член которой отвечал определенным требованиям.
1. Понимает, как создать программное обеспечение, используя технологии, необходимые для пилотного проекта.
2. Имеет все необходимые навыки для разработки законченного фрагмента приложения.
3. Осведомлен об итеративно-инкрементальном процессе разработки. По крайней мере один участник команды должен иметь опыт создания программ этим методом, чтобы направлять других.
4. Каждый участник команды должен быть добровольцем, а не призывником.
5. Участник должен быть увлечен проектом.
Менеджер проекта помог обеспечить соответствующую обстановку для проведения пилотного проекта. В связи с тем что разработчики должны превращать в программное обеспечение идеи именно вице-президента, они организовали рабочее пространство в непосредственной близости от его кабинета. Менеджер проекта также предложил некоторые шаги.
1. Рабочее пространство должно быть организовано таким образом, чтобы все члены команды могли легко видеть, слышать друг друга и друг с другом эффективно взаимодействовать. Это позволит быстро обнаруживать и устранять недопонимания. Рабочее пространство должно быть открытым, без разделяющих перегородок.
2. Флипчарты и лекционные доски в рабочем пространстве могут помочь членам команды визуализировать возможности и найти идеи. Пространство должно обеспечивать место для работы и хранения инструментов на всем протяжении создания пилотного проекта.
3. Члены команды должны работать полный день, так как частично задействованные члены команды могут быть недоступны, когда в них нуждаются остальные. Даже когда они доступны, они могут продолжать думать о других обязанностях.
4. Вся работа должна быть ограничена обычным рабочим временем. Превращение требований в готовый к использованию инкремент программного обеспечения требует решения проблем. Отправляя членов команды по домам в конце обычного рабочего дня, вы позволяете их подсознанию найти новые подходы и обнаружить ошибки.
Итак, вице-президент сформировал команду, состоящую из него, менеджера проекта и трех разработчиков программного обеспечения.
Создание послания, притягивающего членов команды
Иногда очень сложно привлечь к проекту хороших разработчиков. Вы можете испытать такие проблемы, если люди не понимают, что эта задача значит для них. Каждый будущий участник команды должен понимать цель и масштаб работы в пилотном проекте.
Послание компании Curaspan, отталкивающее потенциальных сотрудников. Вот вам пример. Онлайн-приложение компании Curaspan используют больницы для передачи документов пациентов после выписки на реабилитацию или другие долгосрочные мероприятия, выполняемые после госпитализации. У компании Curaspan возникли проблемы. Это приложение было создано более десяти лет назад, и его работа стала неприемлемо медленной. Звонки в службу поддержки клиентов стали практически непрерывными.
Эдвина Миллера взяли на позицию вице-президента по управлению продуктами компании. Ранее он перевел несколько компаний на эмпирический метод разработки программного обеспечения. Руководство Curaspan ожидало, что он это сделает и в их компании. Миллер начал набор разработчиков для создания следующего поколения программного обеспечения. В поиске сотрудников он пошел по обычному пути: старые знакомые, люди, известные в индустрии, и агентства по набору персонала. Он просматривал резюме и приглашал подходящих людей на собеседование. Он сделал несколько предложений соискателям, но ни одно не было принято.
Проблема заключалась в том, что руководство и разработчики в Curaspan не были убеждены в том, что эмпирический подход правильный, и не понимали его. Отсутствие у них стратегической приверженности, незнание работы, которую люди будут делать, и их антипатия к эмпирическим процессам пугали соискателей. Даже в условиях экономического кризиса хорошие разработчики находили альтернативные предложения трудоустройства.
Люди чувствуют хорошие вещи. Даже если вы собираетесь экспериментировать с тем, чего вы не делали раньше, то должны создать четкое послание для людей, которых вы хотите привлечь (внутри организации или вне ее). Опишите перспективы и то, что вы для этого сделаете.
Рассредоточенная команда в Iron Mountain. Iron Mountain Digital – это компания по хранению и управлению данными стоимостью 3,1 миллиарда долларов. Она предоставляет услуги по внеофисному хранению резервных цифровых данных с помощью продукта LiveVault. В 2006 году продукт LiveVault испытывал трудности. Новая версия программного обеспечения не выходила более 12 месяцев. Отдельные люди в LiveVault читали об эмпирическом методе разработки программного обеспечения Scrum, но по-прежнему использовали старые методы. Не зная этих трудностей, маркетинговое крыло компании Iron Mountain заключило контракт с Microsoft в июне 2007 года. Microsoft обеспечивала своих пользователей программным обеспечением, постоянно создающим резервные копии. Резервные копии создавались на локальном сервере, и в Microsoft хотели предложить внеофисное хранение резервных данных в LiveVault в качестве альтернативы.
