В конце концов инженеру пришлось уступить перед ультиматумом генерального директора: лучше перейти на новый механизм расчетов, чем потерять место. На следующий день он пришел на службу, включил компьютер и запустил программу. Трудился спокойно и прилежно, но поначалу медленно. В перерыве он пошел на производство и покурил с рабочими. Он не жаловался на необходимость пользоваться программой (видимо, опасаясь последствий), но тот факт, что он ее принял, не остался незамеченным. Возможно, его пример показал другим, что стоит без лишних возражений перейти на автоматику. Или рабочие решили: раз уж главный инженер не смог воспрепятствовать введению автоматизации, им тоже следует идти в ногу со временем.
Два важных вывода относительно перемен
Тот подслушанный разговор стал для меня поворотным моментом и изменил мой взгляд на свою работу. Он также преподал мне два важных урока, касающиеся перемен.
■ Любая перемена может быть позитивной для одних людей и негативной для других. Я не просто написала компьютерный код – я изменила способ работы сотрудников и, не исключено, их отношение к своему труду и даже условия жизни.
■ Перемены – процесс социальный. Изменения способны оказать влияние на отношения, статус, самоидентификацию и оценку собственной компетенции и значимости. Обучение происходит через взаимодействие с другими людьми. То, как мы откликаемся на идею, воздействует на окружающих.
Затем я перешла на работу программистом в крупную финансовую компанию, условно назовем ее Bradley's. Это был довольно значительный карьерный шаг – из маленькой семейной производственной фирмы в непрестижном пригороде в организацию, входящую в список Fortune 100 (и 100 лучших компаний для работы), со штаб-квартирой в небоскребе на Манхэттене и десятками тысяч сотрудников по всему миру. Рекордному количеству прибыльных подразделений Bradley's завидовала вся отрасль, и бренд был широко известен. Меня взяли в группу, которая писала код для отчетности по акциям и облигациям. Здесь те, кто использовал программы, приветствовали нашу систему автоматизации сотен счетов, связанных с ежедневными покупками, продажами и обновлением биржевого курса. На новом месте я переключила свое внимание на другой тип перемен.
Через несколько месяцев у меня возникли определенные идеи, как можно повысить эффективность работы программистов. В числе прочего я предложила систему визуализации данных. Я прикрепила на стену большой график, отражающий последовательность и взаимозависимость всех программ, которые запускались каждый вечер. Когда какая-либо программа обрушивалась или же с ее работой возникали проблемы, требующие срочного решения, я отмечала ее цветной кнопкой. Вскоре у нас появились данные для анализа.
Я уверена, что в других подразделениях и филиалах нашей фирмы кто-то уже располагал этими сведениями, но для нас они прежде были недоступны. Мы с моими сотрудниками стали уделять особое внимание программам, которые часто сбоили. Мы начали придавать большее значение тестированию, и когда обнаруживали запутанный код, то подчищали его.
Другое незначительное изменение включало отображение структуры каждой программы. Мне даже не приходилось самой изучать и графически изображать структуру; нужно было всего лишь выбрать параметры и сделать распечатку. Voilà! Это небольшое нововведение облегчило новичкам знакомство с последовательностью выполнения программы, а также помогло быстрее обнаруживать ошибки в программах. К тому же это требовало гораздо меньше времени, чем просмотр всего текста программы в поисках заголовков подпрограмм.
Некоторые перемены я могла внедрить, не получая разрешения начальства, без выделения бюджета и не убеждая никого в том, что это хорошая идея: просто немного приспособила работу к условиям и смоделировала изменения, которые хотела бы видеть. Эти небольшие поправки часто имели существенное значение.
В конце концов я перешла в Bradley's на управленческую должность. Теперь я больше не проводила дни напролет, вычисляя, как заставить компьютер совершать те или иные действия, и попутно внося маленькие изменения. Моей основной работой стала трансформация условий для обеспечения более продуктивной деятельности (наряду с составлением бюджета, написанием отчетов, проведением совещаний и решением моря административных вопросов). Мои возможности изучать людей и перемены снова расширились.
Видеть общую картину
Будучи менеджером, я обладала определенными полномочиями и инструментами контроля. И очень скоро почувствовала, что, как только дело доходило до введения изменений, этих полномочий мне оказывалось недостаточно. Когда я говорила людям, что они должны выполнять работу иначе, это не имело действия. Нужно было объяснять контекст и предоставлять информацию, а также слушать и учиться. Обеспечения условий тоже не всегда было достаточно. Требовалось научиться оказывать влияние на процессы, происходившие за пределами моей группы.
Одно из нововведений, осуществленных мной самостоятельно, предполагало работу с другими менеджерами по развитию над расчетом проектов. Мы заметили – трудно было этого не заметить, – что наш отдел информационных технологий сплошь и рядом не выполняет обязательства по бюджету и не укладывается в оговоренные сроки. Большинство проектов превышало бюджет на 200 %, а работу мы сдавали с существенным опозданием. Результаты в Bradley's были даже хуже, чем официальная отраслевая статистика, производившая удручающее впечатление. Учитывая, что очень немногие проекты достигали своих плановых показателей, на определенном уровне эти неудачи были полностью предсказуемы. И все же каждая очередная вызывала небольшой скандал со взаимными обвинениями и предупреждениями, что такое не должно повториться.
Мы проанализировали как можно больше данных и выявили интересную тенденцию. Чем крупнее проект, тем с большей вероятностью он выйдет за рамки бюджета и нарушит сроки сдачи и тем значительнее погрешности. Проекты, предполагающие привлечение новых технологий, команд, не имеющих знаний в предметной области, и посвященные разработке новых продуктов, гарантированно превышали предварительные оценки по бюджету и срокам. Те проекты, которые ближе подходили к изначальным прогнозам, были либо небольшими, либо не очень сложными, даже если отличались трудоемкостью. То есть ключевую роль играли тип и масштаб проекта, а не его руководитель.
Такая тенденция наблюдалась во всем подразделении в течение нескольких лет. Основываясь на этих данных, мы установили категории сложности и коэффициенты достоверности. Нашей задачей было ввести не точечную, а интервальную оценку и включить критерий достоверности. Мы предположили, что два этих фактора будут отражать существующую неопределенность.
Наш эксперимент стал шагом в правильном направлении, основанным на знаниях и вдумчивом анализе ситуации. Мы нашли единомышленников, заинтересовавшихся нашей идеей, но не особенно продвинулись. Ни составители бюджета, ни те, кто распоряжается средствами, не приняли интервальной оценки. Финансисты хотели знать точные цифры, а бюджетная система могла воспринять только одну конкретную сумму.
Мы осознали, что при нашей ограниченной сфере влияния и недостатке официального статуса вряд ли сможем договориться с руководителем сметной группы, а также получить финансирование для модификации бюджетной системы таким образом, чтобы она могла воспринимать интервальную оценку. Поэтому мы продолжили с помощью этих категорий управлять ожиданиями в локальных масштабах и искали другие пути, чтобы сделать неизбежный перерасход менее неожиданным для тех, кто не вовлечен в непосредственный рабочий процесс.
Тем временем руководители IT-отдела взялись именно за эту проблему превышения бюджета и срыва сроков. Они имели полномочия использовать традиционные пути воздействия – поощрения, увольнения и наем работников, трудовой распорядок, управление производственным процессом, материальные стимулы – и их активно применяли. В течение нескольких лет наши боссы прилагали усилия, чтобы изменить результаты проектов. Как менеджер по развитию, я должна была наблюдать и за исполнением их распоряжений, и за тем, к чему это приведет.
