Главная Случайная страница


Полезное:

Как сделать разговор полезным и приятным Как сделать объемную звезду своими руками Как сделать то, что делать не хочется? Как сделать погремушку Как сделать так чтобы женщины сами знакомились с вами Как сделать идею коммерческой Как сделать хорошую растяжку ног? Как сделать наш разум здоровым? Как сделать, чтобы люди обманывали меньше Вопрос 4. Как сделать так, чтобы вас уважали и ценили? Как сделать лучше себе и другим людям Как сделать свидание интересным?


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Пилотные проекты





 

Пилотный проект – это такой, в котором вы откладываете в сторону толстый том стандартов и пробуете новый, неизученный метод. Новый метод вам не знаком, поэтому поначалу можно ожидать низкой производительности. Такова цена изменений. Обратная сторона медали – повышение производительности в результате применения нового метода. Кроме того, добавляется ещё эффект Готорна – прирост энергии и интерес, наполняющий людей, когда они изучают что-то новое и непривычное.

Могут ли эти два плюса перевесить минус кривой обучения? Было бы безрассудством предполагать, что могут всегда. Большое значение имеет природа вносимых изменений, а также продолжительность проекта, способности его участников, степень веры людей в изучаемый метод.

По нашему опыту пилотные проекты тяготеют к средней производительности, превышающей средние показатели. Это означает, что затраты на проект будут, вероятно, меньше, если вы решите сделать проект пилотным, то есть решите использовать какой-то новый метод.

Означает ли это, что все проекты должны быть пилотными? Ваша организация окажется в хорошей компании, если примет подобный подход за правило; здесь и Fujitsu, и части Southern Company Services, и некоторые подразделения IBM. В любом случае смысла больше в том, чтобы все проекты были пилотными, чем в том, чтобы таких проектов вообще не было.

Существует два возражения против любой расширенной программы пилотных проектов:

• Что делать, если закончатся новые идеи?

• Не усложнится ли ещё более сопутствующая деятельность (поддержка продукта, обучение клиентов и т. д.), если мы начнём поставлять не устойчивую продукцию?

Первое возражение имеет смысл лишь в теории. Большинству организаций после десятилетних испытаний новых подходов редко (если вообще) приходится волноваться из-за того, что новые подходы закончатся. Если начать исследовать все хорошие идеи, на которые мы не обращали внимание в шестидесятых, затем перейти к семидесятым и восьмидесятым, то к моменту, когда исследование завершится, пройдёт ещё десятилетие и появятся многочисленные новые идеи.

Что касается проблемы неустойчивых продуктов, то почему бы не признать, что такая проблема существует даже в случае следования жёстким стандартам? Существующая стандартизация привела к документальной стабильности продуктов, но никак не к осмысленной функциональной стабильности. Иначе говоря, стандартизация в основном затронула бумажную работу, связанную с продуктами, но не сами продукты. Если же бумажный вариант проекта немного отличается от стандартного, то серьёзных неудобств это не вызовет.

Одно предостережение по поводу пилотных проектов: не экспериментируйте более чем с одним технологическим аспектом в пределах проекта. Несмотря на все разговоры о важности стандартов, просто удивительно, насколько часто руководители забывают обо всяких стандартах в редких пилотных проектах. Они часто испытывают новые аппаратные средства, новые программы, новые процедуры контроля качества, матричное руководство, а ещё новые методы создания прототипов – и все в одном проекте.

Разумный подход к пилотному проекту – разрешить изменить лишь одну составляющую процесса. В здоровой среде участники проекта поймут, что экспериментировать с одним новым методом в каждом проекте – это нормально, но в целом следует всегда придерживаться стандарта.

 

 

Военные игры [67]

 

За четыре года существования наших военных манёвров разработчиков мы узнали, что иногда жёсткое состязание, в котором нет проигравших, может стать замечательным источником созидательного беспорядка. Наши игры ориентированы на сообщество разработчиков программного обеспечения, но идею можно применять практически в любой области. Независимо от рода вашей деятельности, возможность испробовать себя в решении специализированных задач и сравнить свои результаты со статистикой производительности коллег может быть весьма интересной. (Конечно же, такой опыт приятен лишь при наличии гарантий конфиденциальности, описанных в главе 8. Вы должны быть уверены, что результаты состязаний не будут использованы против вас.)

Военные манёвры помогают вам оценить свои плюсы и минусы по относительной шкале, помогают организации выявить свои плюсы и минусы в глобальном масштабе. По этим причинам две из наших клиентских компаний разработали программу по ежегодному проведению военных манёвров, чтобы позволить своим сотрудникам измерять рост собственной квалификации с течением времени. Раз в год сотрудники подвергают себя конфиденциальным испытаниям (в чем-то это похоже на медосмотр).

С целью стимуляции творческого беспорядка наиболее эффективная из разновидностей военных игр предлагает участникам объединяться в команды. Ниже приведена одна из формул таких манёвров, которую мы применяли до некоторой степени успешно (и с огромным интересом):

1. Подберите маленький проект по разработке или чётко поставленную задачу; это будет ваш подопытный кролик. Лучший выбор – реальная для вашей организации задача, требующая от одного до двух человеко-месяцев работы. Выбирайте проблему, обладающую новизной, не простую, но при этом широко задействующую рабочие навыки ваших сотрудников.

2. Подготовьте проект обычным образом – опубликуйте техническое задание.

3. Объявите о проведении двадцатичетырехчасового состязания в ближайшие выходные. Постарайтесь объяснить всем, что вы не экономите за счёт выходных своих сотрудников. Объясните, что состязание проводится на выходных, чтобы команды могли свободно чувствовать себя на рабочих местах, а не из соображений экономии на человеческих ресурсах. Предложите участникам объединиться в команды по четыре человека и участвовать в состязании на совершенно добровольной основе.

4. Распространите техническое задание заранее, наряду с правилами и целями состязания.

5. В день состязания только его участники должны присутствовать в офисе. Позаботьтесь, чтобы у них было все необходимое: еда, компьютеры, кушетки, копировальные аппараты, конференц-залы – все что угодно.

6. Все команды должны выполнять одну и ту же работу, причём в отведённое для состязания время.

7. Подготовьте добровольцев, которые будут следить за соблюдением правил, предотвращать фатальные осложнения и устраивать большой шум по поводу каждого промежуточного финиша.

8. Ищите возможности сделать каждого победителем в определённом смысле – по общему времени работы, по надёжности продукта, по оригинальности решений. Создавайте много шума вокруг каждого достижения.

9. Установите победивший продукт или же несколько продуктов-победителей одновременно. Внимательно следите за временем стабильной работы продукта, количеством изъянов, уровнем дружественности продукта к пользователю, стоимостью изменений и любыми другими параметрами, определяющими успех проекта. Сообщайте значимые данные командам.

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

Приведём некоторые соображения по поводу опытов вроде проектных состязаний. Во-первых, подобные мероприятия стоят денег. Не надейтесь, что ваши сотрудники, словно под гипнозом, за выходные создадут нечто, что в противном случае пришлось бы оплачивать по полной ставке. Проектное состязание обойдётся вам в несколько раз дороже, чем проведение того же проекта в рабочее время. Во-вторых, не пожалейте времени на подготовку чёткой постановки задачи, на обучение своих ассистентов к этому мероприятию, на создание многочисленных промежуточных финишей. В-третьих, приложите усилия, чтобы соразмерить масштаб проекта с выделенным на его выполнение временем (мало кто получит удовольствие, если все команды окажутся побеждёнными или если состязание закончится через час после начала). Наконец, изыщите возможность щедро потратиться на кормление участников (в одном из состязаний мы заказали пикник-ланч из одного нью-йоркского ресторана, устроили обед с доставкой, а потом, в два часа ночи, затащили всех в китайский квартал перекусить.)

Продолжение проекта ночью каким-то образом лишь добавляет всем удовольствия. Людям нравится повод утомляться вместе, отгонять сон и позволять коллегам видеть себя лохматыми, небритыми, помятыми и раздражительными, без грима и притворства. И это сильнее привязывает участников проекта друг к другу.

 

«В ходе мероприятия я заметил, как [68] прикорнула на коврике в приёмной. Я знал её много лет и всегда считал немного чопорной. Но с этого момента я стал относиться к ней иначе. Я стал иначе относиться ко всем. Мы прошли через это вместе».

(Из обсуждения состязания)

 

Date: 2015-09-05; view: 337; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию