Книга: Заряженные на результат. Культура высокой эффективности на практике
Год, прожитый в опасности
Год, прожитый в опасности
К счастью, Джону нужно было всего лишь переформатировать режим работы и обязанности членов команды. Но иногда переделывать приходится целую организацию.
В 1999 году компания Salesforce.com создала частный портал, оказывающий услуги по программному обеспечению{256}. Быстрота и гибкость были их главными преимуществами. Salesforce.com обновляла продукт четыре раза в год, тогда как другие компании – только единожды{257}. В результате компания росла очень быстро.
Работа Salesforce.com строилась по принципу конвейера. Одна группа сотрудников встречалась с клиентами, выясняя их потребности. Другая создавала перспективные проекты конкретного программного обеспечения. Третья группа писала программы, четвертая их проверяла, а пятая производила итоговый продукт. Но координация между группами и отделами сильно хромала. Изменения, часто вносившиеся в последнюю минуту, приводили к настоящей катастрофе.
Стив Грин, менеджер по производству, заметил, что коллеги начали винить в неудачах друг друга. «Сломалась модель работы, а не люди, – понял Стив. – Необходимо было починить модель, а не просто требовать безошибочных действий».
Salesforce.com попыталась запретить изменения конечного продукта еще на стадии производства, чтобы не допускать переделок в последний момент. От каждого служащего и группы требовали четко спланированной работы и ее результатов на полгода вперед. Но ничего не помогало. Индустрия программного обеспечения развивалась гораздо быстрее, чем изготавливались заказанные проекты, и никто не мог представить, с какими вызовами придется столкнуться при производстве очередного продукта. Стратегии, отрицающие адаптивные подходы во имя тактических, обрекают себя на неудачу. В IT-сфере волатильность особенно остра.
И тогда Грин решился на очень смелый шаг. Вместе с коллегой Крисом Фраем он обратился к Паркеру Харрису, соучредителю Salesforce.com, и предложил реорганизовать каждое рабочее место в соответствии с принципом гибкости.
Принцип гибкости был разработан в 2001 году на встрече 17 программистов и инженеров в области программного обеспечения. Специалистов волновала заметная утрата адаптивного подхода в их профессиональной среде. Производство подменило здравые суждения в ущерб работе. Эти программисты составили и разместили в интернете «Манифест гибкости»: его символом стал рисунок, на котором компьютерщики окружили ослепительно белую классную доску{258}. Картинка напоминала известное изображение отцов-основателей Декларации независимости США, которое можно увидеть в американских учебниках истории. В манифесте провозглашался революционный подход: с момента его принятия программисты должны работать только в составе команд. Конечный продукт – программы и приложения – должны делать «имеющие глубокую мотивацию индивидуумы. Им нужно всего лишь создать необходимые условия и оказать поддержку. И еще – им нужно верить. Верить в то, что они качественно выполнят свою работу»{259}. Таким образом они переформатировали собственное дело, максимально повышая абсолютную мотивацию и адаптивную эффективность.
Грин задумал опробовать новый принцип гибкости в Salesforce.com на небольшой независимой группе. По его мнению, эта идея относилась к группе «черепах» и компанию не следовало подвергать риску, внедряя ее быстрыми темпами. Но Паркер смотрел на вещи иначе: он полагал, что Salesforce.com в глубоком кризисе, и хотел «большого потрясения». Ему требовался «заяц».
Через три месяца весь производственный отдел компании состоял сплошь из «гибких команд»{260}. Еще через полтора года Salesforce.com полностью обновила процесс производства.
Был разрушен привычный конвейер, и вместо него заработали «игровые площадки». Теперь задания группам программистов раздавали не вышестоящие менеджеры. Сотрудников распределили в команды примерно по 10 человек, включавшие менеджеров по производству, конструкторов, программистов, специалистов по качеству и других профессионалов, без которых нельзя было превратить идею в конечный продукт. Команды работали в одном помещении и проводили вместе много времени, основываясь на другом принципе манифеста: «лучшей формой общения в коллективе становятся личные контакты». Такой взгляд на полный цикл производства позволил максимально использовать мотив цели в работе и проектах.
Команды трудились на «спринтерских дистанциях – от двух до шести недель. Вначале группа определяла цель и представление о свойствах будущего продукта, затем намечала рабочие планы. Каждый член команды имел неограниченные возможности в решении любых вопросов. Все могли высказываться по поводу того, что и каким образом создавать. В итоге команда, как правило, имела законченное представление о продукте, готовом отправиться к потребителю. Проекты больше не пылились на полках, пока инженеры завершали работу над ними. В результате коллектив создателей сразу видел реальное воплощение своей цели. Продолжительность «спринтерских сессий» позволяла членам команды регулярно анализировать ход процесса, ускоряя производственный цикл там, где раньше требовались многие месяцы.
Принцип гибкости повышает абсолютную мотивацию у создателей программного обеспечения. Активизируются также мотивы игры и цели, поскольку члены команды знают, что вскоре увидят результат своего труда, а по ходу изготовления легко внесут необходимые изменения. Менеджер по производству, например, видит, как влияют на действия программистов и инженеров его решения, и адаптирует их, опираясь на обратную связь, которую получает от клиентов компании примерно раз в месяц. По окончании каждого «забега» группа обязательно дважды анализирует результаты работы: один разбор касается продукта, а второй – его создания и производства. Да и процесс совместного труда постоянно совершенствуется.
В такой схеме нет места косвенной мотивации, поскольку у команды нет формально наблюдающего менеджера. Один человек отвечает за соблюдение принципа гибкости и убирает возникающие препятствия. Резко снижается действие мотива инерции, и не только потому, что есть ответственный за устранение преград, а еще и потому, что группе из 10 человек работать гораздо проще, чем большой организации, состоящей из сотен, а иногда и тысяч людей.
Грин рассказывает об этих трансформациях в своей книге Year of Living Dangerously («Год, прожитый в опасности»){261}. Довольно долго не было ясно, сработают ли нововведения. Опросы сотрудников компании выявили даже претензии. «Создается впечатление, что мы больше говорим о принципах гибкости ‹…› чем работаем или обсуждаем дела компании», – было написано в одном комментарии{262}. «Язык этого манифеста просто смешон», – говорилось в другом.
Команды довольно упорно сопротивлялись ежедневным 15-минуткам, на которых каждой предлагалось обсудить текущее состояние дел. «Многие спрашивали, не лучше ли делать это по электронной почте», – вспоминает Грин. Но по мере врастания в незнакомые рабочие роли сотрудники стали воспринимать эти короткие встречи, пожалуй, как самую популярную часть новой практики. «Они создают ощущение общности, объединяют. Каждый член команды теперь в курсе всего, что в ней происходит. И если возникает препятствие или проблема, решение находится моментально».
К концу 2007 года результаты говорили сами за себя. Среднее время на разработку нового продукта сократилось на 61 %{263}. Компания наконец-то снова начала выполнять контрактные обязательства. И 94 % сотрудников Salesforce.com заявили, что будут рекомендовать другим принципы гибкости. Такое единодушие мнений очень примечательно, тем более потому, что его придерживаются не только в Salesforce.com. «Манифест гибкости» покорил Кремниевую долину. Некоторые компании, сделавшие его основой работы, увеличили производительность на 200–400 %!{264}
Иногда недостаточно изменить работу одного человека. Нужно трансформировать деятельность всех сотрудников.
- Система безопасности InterBase
- Факторы выгоды
- Общие рекомендации по безопасности
- Конфигурация безопасности для базы данных
- Вам очень пригодится «Разработка ценностных предложений», если…
- Благодарности
- Обеспечение безопасности библиотеки
- Глава 1 Стандарты и угрозы информационной безопасности
- Глава 3 Нормативные руководящие документы, назначение и задачи информационной безопасности России
- О технике безопасности
- Как узнать прогноз погоды?
- Благодарности.