Заряженные на результат. Культура высокой эффективности на практике

Работа Salesforce.com строилась по принципу конвейера. Одна группа сотрудников встречалась с клиентами, выясняя их потребности. Другая создавала перспективные проекты конкретного программного обеспечения. Третья группа писала программы, четвертая их проверяла, а пятая производила итоговый продукт. Но координация между группами и отделами сильно хромала. Изменения, часто вносившиеся в последнюю минуту, приводили к настоящей катастрофе.

Стив Грин, менеджер по производству, заметил, что коллеги начали винить в неудачах друг друга. «Сломалась модель работы, а не люди, – понял Стив. – Необходимо было починить модель, а не просто требовать безошибочных действий».

Salesforce.com попыталась запретить изменения конечного продукта еще на стадии производства, чтобы не допускать переделок в последний момент. От каждого служащего и группы требовали четко спланированной работы и ее результатов на полгода вперед. Но ничего не помогало. Индустрия программного обеспечения развивалась гораздо быстрее, чем изготавливались заказанные проекты, и никто не мог представить, с какими вызовами придется столкнуться при производстве очередного продукта. Стратегии, отрицающие адаптивные подходы во имя тактических, обрекают себя на неудачу. В IT-сфере волатильность особенно остра.

И тогда Грин решился на очень смелый шаг. Вместе с коллегой Крисом Фраем он обратился к Паркеру Харрису, соучредителю Salesforce.com, и предложил реорганизовать каждое рабочее место в соответствии с принципом гибкости.

Принцип гибкости был разработан в 2001 году на встрече 17 программистов и инженеров в области программного обеспечения. Специалистов волновала заметная утрата адаптивного подхода в их профессиональной среде. Производство подменило здравые суждения в ущерб работе. Эти программисты составили и разместили в интернете «Манифест гибкости»: его символом стал рисунок, на котором компьютерщики окружили ослепительно белую классную доску{258}. Картинка напоминала известное изображение отцов-основателей Декларации независимости США, которое можно увидеть в американских учебниках истории. В манифесте провозглашался революционный подход: с момента его принятия программисты должны работать только в составе команд. Конечный продукт – программы и приложения – должны делать «имеющие глубокую мотивацию индивидуумы. Им нужно всего лишь создать необходимые условия и оказать поддержку. И еще – им нужно верить. Верить в то, что они качественно выполнят свою работу»{259}. Таким образом они переформатировали собственное дело, максимально повышая абсолютную мотивацию и адаптивную эффективность.

Грин задумал опробовать новый принцип гибкости в Salesforce.com на небольшой независимой группе. По его мнению, эта идея относилась к группе «черепах» и компанию не следовало подвергать риску, внедряя ее быстрыми темпами. Но Паркер смотрел на вещи иначе: он полагал, что Salesforce.com в глубоком кризисе, и хотел «большого потрясения». Ему требовался «заяц».

Через три месяца весь производственный отдел компании состоял сплошь из «гибких команд»{260}. Еще через полтора года Salesforce.com полностью обновила процесс производства.

Был разрушен привычный конвейер, и вместо него заработали «игровые площадки». Теперь задания группам программистов раздавали не вышестоящие менеджеры. Сотрудников распределили в команды примерно по 10 человек, включавшие менеджеров по производству, конструкторов, программистов, специалистов по качеству и других профессионалов, без которых нельзя было превратить идею в конечный продукт. Команды работали в одном помещении и проводили вместе много времени, основываясь на другом принципе манифеста: «лучшей формой общения в коллективе становятся личные контакты». Такой взгляд на полный цикл производства позволил максимально использовать мотив цели в работе и проектах.

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