Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы
Image via ShutterstockМеня зовут Михаил Завилейский. Формально я — генеральный директор DataArt. Но, на самом деле, просто из один многочисленных руководителей компании — ведь самого главного начальника у нас нет. В DataArt я отвечаю за организационное развитие. До прихода сюда 10 лет работал в IT — в основном программистом, но также немного и менеджером.
В этой статье мы поговорим о карьере. Я расскажу, что происходит с программистами, которые почему-то хотят перестать работать инженерами. Сказанное будет относиться также к тестировщикам, инженерам качества, автоматизаторам и другим смежным специалистам. Мы посмотрим, куда могут двигаться такие специалисты.
Причины перехода
Я полагаю, что причины того, что многие люди со временем меняют специализацию, — это возрастные изменения нашего мозга. Согласно разным научным исследованиям, логический интеллект у большинства с возрастом слабеет и мало у кого усиливается. Так, в современной математике и физике большая часть самых важных открытий делается в молодом возрасте, и опыт не может заменить возрастное снижение живости ума.
Опыт, тем не менее, помогает лучше угадывать, что нужно клиенту; также растет эмоциональный интеллект, развивается лучшее понимание мира и отрасли — оказывается, такие навыки могут отлично пригодиться в других областях IТ-индустрии.
Наша индустрия развивается от содержательно сложных проектов к разнообразно сложным. Почти все содержательно сложные проекты (когда ясно, что именно нужно сделать, но сделать это трудно) были реализованы в IТ-индустрии уже много раз: так, было создано много хороших бухгалтерий, банковских систем; встроенные программы работают в машинах, самолетах — всё это уже есть.
Сегодняшние же задачи характеризуются тем, что мир становится разнообразней и понять, что нужно делать, становится всё сложнее, ведь не всегда понятно, чем отличается одно от другого. Так, если вы пишете
И вот здесь можно совершить переход от программирования к тем специальностям, которые помогают понять, что нужно сделать.
Карьера инженера
Вот типичный карьерный путь программиста, тестировщика или другого IT-специалиста:
Итак, кто-то начинает работать с младшей позиции. На самом деле, джуниор отличается от синьора главным образом тем, что обычно получает часть компенсации своего труда не деньгами, а опытом и обучением. Таким образом, на джуниорах компании зарабатывают больше, а джуниор выбирает компанию правильно, если там может многому научиться. По сути, отличия между джуниором и синьором на 80% — в психологических качествах, и лишь на 20% — в знаниях и опыте.
Пожалуй, самый лучший совет по развитию в себе «синьорности» — всегда думать не о том, что я делаю, а о том, кто мой клиент и кого я обслуживаю. Синьор — тот, кто всё понимает и делает сам, не требует никакого присмотра, сам собой управляет и умеет себя продавать. Если с вами удобно работать, и от вас всегда получают хороший предсказуемый результат, у вас будет репутация синьора. Если вы умнее всех, но взбалмошны — останетесь гениальным джуниором.
Продуктовым компаниям приходится бороться за удержание синьоров, так как последние обладают действительно большим объёмом навыков, но устают, им надоедает заниматься одним и тем же. Сервисные же компании могут предоставить разнообразие, но на синьорах очень трудно заработать — их всегда не хватает, зарплаты всегда очень рыночные, и синьор находится в балансе с окружающей средой.
Конечно, синьору может быть интересно бесконечно долго, но, как показывает опыт, многие из них перемещаются на другие позиции:
— Эксперт;
— BC — business consultant (бизнес-консультант);
— PM — project manager (менеджер проектов);
— SM — sales manager (менеджер по продажам);
— AM — account manager (аккаунт-менеджер);
— OM — operations manager (операционный менеджер).
Перемещение инженеров на такие позиции происходит, как правило, естественным путём — когда в компании появляется возможность делать то, чего ты не делал раньше.
А теперь попробую рассказать, как управлять сменой своей профессии, и поделюсь наблюдениями, какие ключевые факторы определяют развитие в том или ином направлении.
Репутация, а затем квалификация
Как я себе представляю профессионала? На мой взгляд, профессионал состоит из двух частей:
1) Квалификация — умения, опыт, навыки;
2) Репутация — то, что о нем знают окружающие.
По моим наблюдениям, большая часть профессионалов предпочитает качать квалификацию. Они изучают новые движки, читают книги по программированию, участвуют в состязаниях программистов — в общем, повышают профессиональную квалификацию всеми возможными способами. Большинство представляют свою карьеру именно так: «Я всему научусь, окружающие увидят, как хорошо я всё делаю, и меня повысят». Но, как показывает опыт, обычно людей не слишком интересуют другие люди (разве что, другими интересуются профессиональные менеджеры, ответственные за развитие персонала). Люди обычно полагают, что всё, что происходит без их прямого вмешательства, происходит само собой. Например, если вы написали идеальный код, — ну, вам повезло, просто так получилось. И вашей заслуги в этом никто не увидит, если только вы сами не расскажете о трудностях, которые пришлось преодолеть.
Как вас видят другие — очень важно для карьерного развития. А другие воспринимают вас через свой непосредственный опыт, а не через то, что вы сами о себе знаете. Это значит, что всё время нужно заниматься самопиаром и делать это даже вперед профессионального развития.
Отсюда — первое правило развития: Репутация должна опережать квалификацию.
Проявить себя
По-настоящему мы учимся, только делая что-нибудь. А чтобы нам доверили что-нибудь делать, нам должны поверить, чтобы мы с этим справимся. У компании и у людей новые навыки появляются тогда, когда их «по ошибке» просят сделать что-нибудь такое, что они еще до этого никогда не делали. Конечно, так делать не надо (это рискованно), но иногда что-нибудь новое мы учимся делать именно так. И, если мы хотим быстро развиваться, можем эти ошибки провоцировать, чтобы нам доверили что-то сложное. Именно по такому пути зачастую происходит самое интересное карьерное развитие в компании.
Я могу это смело утверждать, потому что довольно редко, по моим наблюдениям, хорошие инженеры становятся хорошими менеджерами легко. Менеджером может стать и хороший, и плохой программист. Однако у не очень хорошего программиста будет выше мотивация перейти в менеджеры. Сейчас я забегу немного вперед и проиллюстрирую это примером пути продавца.
Итак, однажды у нас в компании появился не очень хороший коллега-программист. Я познакомился с ним, когда он вызвал команду ОС «удалить всё из текущего каталога» из сервера приложений (тогда это был ASP) — так он удалил из «system32» всё, что можно было удалить. После этого сервер продолжал работать какое-то время (файлы, которые в тот момент использовались, не удалились), но он никогда не перезагрузился бы и скоро упал, как только захотел бы сделать что-нибудь новое и загрузить какой-нибудь dll из system32.
Я уже не помню, чем закончилась эта история. Но, как бы то ни было, этот коллега продолжил развиваться в компании, но сильных технических задач ему уже не доверяли. Зато ему всегда больше всех было надо, чтобы всё было хорошо: он никогда не верил, что нельзя сделать хорошо ту или иную вещь, или что заказчик не может быть удовлетворен. Таким образом, его репутация складывалась из так называемых soft skills, социальных навыков. Мы знали, что мышление у него не слишком инженерное, но зато клиент-ориентированное, результат-ориентированное, в чем-то то перфекционистское, — при этом он отличный партнер, который помогал команде показывать лучший результат. Теперь, по прошествии 18 лет, этот человек, Алексей Миллер, сидит в Нью-Йорке, возглавляет все продажи в DataArt.
Бывает, что мы можем проявить себя гораздо лучше не в кодировании, а в чем-то другом. Это совершенно нормально — в современном IТ-мире для этого есть очень много возможностей.
Изменение мотивации
Однако на этом пути нас подстерегают некоторые ловушки. Несмотря на то, что я никогда не был очень хорошим программистом, я никогда в жизни не был счастливее от работы, чем в те времена, когда работал просто инженером. Почему? Потому что когда после долгой и трудной работы у меня всё запускалось и работало отлично, я испытывал яркое и естественное удовольствие. При этом я знал, что это сделал именно я, и сделал хорошо.
Есть чудесный цикл, поддерживающий всех профессионалов счастливыми, который я назвал «do-check-enjoy» («сделать-проверить-радоваться»). Мы что-то делаем, мы можем это проверить, и нам даже не нужно постороннее мнение — мы видим, что мы это сделали круто. Такие события, повышающие самооценку, случаются постоянно. Один из моих любимых авторов, Дэвид Майстер, писал, что самооценка у всех профессионалов исходно занижена — именно это из-за этого профессионалы несчастливы на простой работе, а постоянно стараются учиться чему-то новому, создавать для себя новые вызовы и что-то себе доказывать. Я могу сказать, что это совершенно точно относится ко мне и к большому количеству моих коллег. Цикл «do-check-enjoy» действительно дает много счастья. И чем больше ты начинаешь смещаться в сторону более сложных и коллективных ролей, тем меньше остается возможностей наслаждаться этим циклом.
У меня нет хорошего примера на этот счет из области IТ, но я могу привести отличный пример из области медицины, который приводят все врачи, когда читают лекции по деонтологии (медицинской этике). Однажды известного врача, впервые в мире сделавшего пересадку сердца и сделавшего много таких операций впоследствии, Кристиана Барнарда, спросили: «Доктор, спасли ли вы чью-либо жизнь наверняка?» Доктор Барнард ответил, что не знает, но всё-таки одну жизнь он точно уж спас. Он рассказал, как в молодости поехал лечить одного фермера, болеющего пневмонией и находящегося в тяжелом состоянии. Жена фермера не верила в благоприятный исход и хотела прибегнуть к народному средству: убить козу и завернуть фермера в ее шкуру. Однако доктор Барнард сказал, что сначала он всё же еще попытается спасти жизнь фермера средствами общепринятой медицины. В итоге доктор Барнард сумел за одну ночь спасти фермера, и, выйдя наутро из дома, проходя мимо козы, которую хотели убить, произнес: «Коза, я спас тебе жизнь!»
Этот пример показывает, как непросто быть врачом: нужно тешить себя мыслям, что ты действительно помогаешь людям, хотя обычно даже не знаешь, наверняка это или нет. А если ты инженер, точно знаешь, что такой-то код заработал в 10 раз быстрее, — и это факт. Если же ты менеджер, продавец или аналитик (а это — командная работа), увидеть результат своих действий вне взаимодействия с большим количеством людей невозможно. Если никто ничего не слил, всё получилось, все молодцы, и ты, наверное, тоже. А когда что-то пошло плохо, иногда знаешь, что это точно твоя вина.
Таким образом, потеря ощущения, что ты делаешь свою работу точно хорошо, — главный демотивирующий фактор при перемещении с роли программиста на другие позиции в IТ. Это важно понимать. Если при переходе на коллективную работу мы будем тешить себя иллюзиями, что всё, что сделано хорошо, сделано мной — будем плохими менеджерами, плохими руководителями и плохими консультантами. Вместо этого нам нужно осознавать, что мы работаем в коллективе, и это — данность. Как доктор Барнард, мы должны понимать, что мы, может быть, когда-нибудь сможем спасти жизнь козы, но не более того.
Это качественное изменение — с представлением, что мы сами себя сможем продолжать оценивать и гордиться собой, придется проститься. Другими словами, нужно распрощаться с инженерским комплексом неполноценности, который толкал нас что-то себе постоянно доказывать. Вместо этого нужно будет развивать уверенность в себе, и это — самое важное при переходе с программистской позиции на менеджерскую.
Путь эксперта
Одна из самых сладких для разработчиков возможность — стать экспертом. Роль идеального IТ-эксперта лежит где-то на пересечении трех возможных ролей:
— Decision maker — тот, кто принимает решения. Эти люди берут на себя ответственность.
— Узкий эксперт — тот, кто знает, как работают те или иные вещи. Или, что даже важнее, часто эксперты знают очень много про то, как вещи не работают. Ведь есть много способов делать вещи заведомо неправильно. И хороший эксперт, как минимум, должен помочь избежать заведомых ошибок. Эксперты, как правило, помогают вне ключевой компетенции той деятельности, в который вы работаете, то есть вам нужен эксперт там, где вы не разбираетесь сами. Эксперт, как и decision maker, берет на себя ответственность в значительной степени, ведь он рискует репутацией.
— Консультант — тот, кто способствует процессу принятия решения своим клиентом. Консультант может что-то знать, но консультант не должен использовать свои знания для того, чтобы принять решение за своего клиента. Вместо этого консультант использует свои знания, чтобы помочь определиться клиенту, показать ему разные перспективы. В этой ситуации хороший консультант может действительно помочь принять решение, а плохой консультант может так всё запутать, что принять решение будет еще труднее, чем до общения с ним.
В IТ в работе с бизнес-заказчиками нужна, в идеале, роль, которая лежит на пересечении этих трех, — и это самая сложная роль. Такого рода людей очень мало.
Например, мы разрабатываем для какой-либо компании индустриальное программное решение. В этом случае есть много областей, где клиент более компетентен, чем мы. Тогда мы должны выступать в роли консультанта, не грузить клиента лишними переживаниями, а способствовать процессу принятия решения — это во многом социальная роль.
В более технической же области, где вы компетентны более, чем заказчик, взять на себя ответственность и принять решение должны именно вы. То есть вы должны выступить в роли эксперта. Если же вы предоставите заказчику набор возможных вариантов и посоветуете ему принимать решение самому, в случае незрелого клиента, это будет манипуляцией, потому что он будет выбирать между вариантами, отличия которых ему самому не очень понятны. В итоге он окажется ответственным за непонятный ему самому выбор. Зрелый же клиент просто откажется так работать.
Если же ситуация предполагает большое количество людей, важно помочь правильно определить границы ответственности, и это — самое трудное. Сейчас самые развитые компании, работающие в IТ, стараются перейти от продажи часов и усилий к продаже решений. Связано это с тем, что мы никогда не произведем столько же часов, сколько производится в Индии или Китае, ведь часы работы, которые стоят в 5 — 10 раз дороже, чем те же часы в Азии, продать очень трудно. Поэтому все компании хотят, чтобы цена формировалась в зависимости от ценности услуги для клиента, а не количества потраченных часов. И здесь, конечно, границы ответственности, о которой нужно договориться заказчику и исполнителю заказа, — большой вопрос. Умение нащупывать эту границу — высший уровень в бизнесе и управлении.
Теперь еще пара комментариев, кто такой эксперт. Есть неправильное понимание эксперта — когда считают, что эксперт — это просто тот, кто самый умный или просто что-то лучше знает. Но это не всегда так. Чтобы быть экспертом, нужно знать очень много в какой-то узкой области.
Также важно, что эксперт — не соревновательная роль. Эксперт — не тот, кто самый упрямый, не тот, кто всех всегда переспорит (хотя такой человек и может сделать себе репутацию эксперта, но такие люди играют разрушительную для компании роль). Эксперт — тот, кто опытен, уверен, но, несмотря на это, остается восприимчивым, может быстро менять своё мнение, если узнает, что он неправ.
Наконец, эксперт должен быть позитивен — не в том смысле, конечно, что он всегда улыбается. Позитивный человек в данном случае — тот, кто дает конструктивные формулировки, видит положительные возможности, а не только проблемы и трудности.
Позитивные формулировки, к сожалению, обычно не удаются инженерам — вместо этого они предпочитают говорить о трудностях и проблемах, которые надо решить. А позитивные формулировки, конечно, работают намного лучше негативных. Вместо описания трудностей в отрасли или слов, что клиенту нужно делать всё по-другому, можно говорить клиенту, что мы поможем ему заработать миллион долларов. Для успешной работы с клиентом нужно, сохраняя уверенность и восприимчивость, учиться делать позитивные формулировки. Если научиться это делать, ваша репутация в области консалтинга вырастет колоссально и легко обгонит ваши профессиональные знания.
Те, кто сейчас формально являются экспертами и консультантами, на самом деле не понимают индустрию лучше всех. Просто они хорошо владеют такими техниками. В итоге их знание индустрии всё-таки растет очень быстро — с ними устанавливают доверительные отношения, они работают и узнают, как всё работает на самом деле.
Путь менеджера проектов
Роль менеджера проектов — самая естественная для бывших программистов. К ней иногда приходят через промежуточную роль лидера команды. Менеджер проектов должен уметь огромное количество вещей. Картинка, которую я нашел в интернете, описывает необходимые навыки менеджера проектов:
Однако самое главное среди этих слов я не наше. Чем отличается управление проектами от любого другого менеджмента? Тем, что проект однажды заканчивается, у него есть конечная цель. Поэтому основная роль менеджера проектов — добиться конечной цели проекта. Конечная же цель проекта — получить одобрение заказчика, попасть в его ожидания.
Поэтому управление ожиданиями — самая главная функция менеджера проектов, в отличие от остальных менеджеров в сфере IТ.
Таким образом, менеджер проектов всегда думает о конце проекта, о том, попадет ли он в ожидание. Ожиданиями нужно управлять, двигать их, потому что редко ожидания, что были в начале проекта, останутся такими же и к концу проекта. Ведь откуда появились гибкие методы разработки? Когда проекты длятся много месяцев, в современном мире за это время всё меняется. Соответственно, меняются и ожидания. Работа современного менеджера проекта — гонка за движущейся целью.
Менеджер проектов это не тот, кто нарисовал план и строго ему следует, а талантливый человек, который понимает, что ожидаемый результат подвижен, будучи зависим от разных факторов, и в соответствии с этим постоянно вносит изменения в план и управляет ресурсами, стараясь попасть в цель на пересечении многих изменчивых факторов. Менеджер проектов — не тот, кто просто управляет подчиненными (хотя сейчас идеальная команда — team of peers, команда равных, где нет явных начальников), а тот, кто влияет на огромное количество людей вокруг и на их представления, что нужно делать, — так, чтобы они сошлись в одной точке и остались довольны друг другом. Это — самое важное.
Если мы строим дом и постоянно меняем требования, дом получится странным и дело, скорее всего, добром не кончится. Если мы работаем с материальным миром, мы должны держать план более или менее устойчивым. В разработке же ПО у нас есть достаточно много свободы, и очень редко получается, чтобы длительный проект оставался стабильным. Чаще всего это — постоянный поток возможностей что-то изменить.
Например, я, когда был менеджером проектов, всегда начинал с того, что проверял степень свободы, — старался выяснить, что могу поменять. Для этого старался немного поменять план проекта, спросить об изменениях в бюджете, чуть-чуть подвигать сроки, чтобы просто посмотреть, как на это реагируют клиент и все остальные. Это позволяло быть готовым к тому, чтобы действительно что-то поменять, когда изменения нужно будет внести. Если это становится нормой, можно сохранять хорошие отношения в ходе проекта и легко вносить нужные изменения.
Если же клиент воспринимает любые изменения в штыки, нужно быть устойчивым и обстоятельным по отношению к любым просьбам об изменении объема проекта. Если идти на поводу у таких просьб, всё для этого проекта может закончиться плачевно. Например, в гибкой методологии разработки один из главных принципов — «fail early», согласно которому неуспех должен случиться как можно раньше. В общении с клиентами из бизнес-культуры очень важно как можно быстрее проверить все возможные засады, которые могут привести к разрушению отношений.
Для менеджеров проектов понимание, что они влияют на огромное количество людей вокруг и занимаются широкой координацией, а не управлением и защитой изначального плана, — главный вызов сегодняшней индустрии. Ведь многие ребята, которые пытаются стать менеджерами проектов, полагают, что хороший план проекта, хорошие оценки затрат, правильные процедуры защитят их от неопределенности окружающего мира. Нет, не защитят. Вместо этого мы должны учиться извлекать из неопределенности достаточное количество преимуществ, чтобы они компенсировали случающиеся у нас проблемы.
Путь продавца
Это — самый трудный путь и, по моим наблюдениям, самый непопулярный среди бывших программистов. Во-первых, это связано с тем, что продавец не обязан быть компетентным в инженерном деле, и поэтому продавцы часто приходят с других позиций и мест. Во-вторых, у инженера, в отличие от продавца, эффективность труда намного выше. Хороший инженер не может себе позволить допускать большой процент брака, на мой взгляд, у хорошего инженера более 90 % работы выполняется очень успешно. У продавца же производительность труда намного меньше: при большом количестве потенциальных покупателей лишь немногие что-то у вас покупают. В норме подписывают контракт менее 10 % контактов, попавших в поле зрения продавца. Поэтому инженеру обычно психологически очень трудно перейти в продажи, не насмотревшись на процесс продаж и не привыкнув.
Поэтому в роли продавца, как нигде, чрезвычайно важна ни на чем не основанная крепкая уверенность в себе и вера, что то, что ты делаешь, — правильно. Другими словами, важно, чтобы самооценка продавца не слишком зависела от успехов и неудач, да и вообще от чего-либо определенного — ведь самооценку, зависящую от чего-либо, всегда можно чем-либо подорвать. Для всех менеджерских ролей, и особенно для роли продавца, очень важен принцип доктора Хауса, который не всегда прав, но всегда уверен в себе, потому что по-другому ему трудно работать.
Так что перед тем как перейти на позицию продавца, очень важно запастись уверенностью в себе — тем более, чтобы понять, насколько вы хороший продавец, понадобится не менее двух лет (тогда как синьор в одной технологии может стать пусть не самым лучшим, но всё же синьором в другой технологии всего за три-шесть месяцев).
Путь аккаунт-менеджера
Есть огромное количество вещей, которые происходят в аккаунт-менеджменте. Это передний рубеж, на которым узнают, что нужно сделать, чтобы заработать денег. Аккаунт-менеджмент связан, в первую очередь, не с развитием каких-то навыков и умений, а с тем, как вы думаете, как используете воображение.
Классическая инженерная команда держит в фокусе внимания программное решение, которое она разрабатывает. Команда же аккаунт-менеджеров стремится развить индустриальное понимание. Если, например, мы имеем дело с разработкой банковской системы, она должна обладать такой-то производительностью, такой-то надежностью, должна быть совместима с такими-то протоколами — иначе она не взлетит. Индустриальное знание помогает понимать, как это обычно работает и чего от нас ждут. Обычно от нас ждут какой-то функциональности и помощи конкретному бизнесу в конкретной индустрии, ждут решения типичных бизнес-задач, которые были сформулированы и описаны в спецификациях, а не идеального кода в больших объёмах.
Самое крутое — бизнес-мышление, которое позволяет думать вместе с клиентом или даже без клиента, как сделать хорошо. Бизнес-мышление позволяет делать внешние и внутренние стартапы, получать бюджеты там, где их не было, позволяет убедить клиента сделать что-то большое и новое и рискнуть чем-то. Часто говорят, что бизнес-мышление присуще людям, которые в конце видят деньги и понимают, как до них дойти. В каком-то смысле это верно, но в современном мире денег всё больше, но в то же время всё больше и страхов отсутствия взаимопонимания. Поэтому те, кто работает в аккаунт-менеджменте на высшем уровне, производят смыслы: задаются вопросом «а какой смысл делать такой-то проект?». Если привести аргументацию, что смысл в этом есть, все делают этот проект.
Умение находить и создавать смыслы — главный атрибут бизнес-мышления. Если вы хотите убедить человека что-то делать, попробуйте рассказать ему, в чем смысл. Если люди понимают, что вы предлагаете, и соглашаются с этим, видят в этом смысл, вы производите смыслы и можете двигаться к высотам аккаунт-менеджмента. А большинство старается выяснить смысл, думая, что он есть у кого-то в голове. Это чуть ниже бизнес-мышления — индустриальный уровень.
Путь операционного менеджера
Наконец, меньшинство из коллег становятся руководителями компании — операционными менеджерами. Как говорил мой преподаватель с физфака, «мы производим большое количество обученных физике людей и воспроизводим небольшое количество себе подобных, которые двигают науку вперед». Руководители, менеджеры компании тоже этим занимаются. Они производят большое количество инженеров (это похоже на обучение и развитие), и определенное количество попадает на операционные должности.
На операционных должностях важно понимать, какова культура компании и чего от вас ждут. В очень простой классификации, все операционные менеджеры, на мой взгляд, делятся на три категории: хозяева, начальники и сервисы.
Хозяин — тот, кто упрощает жизнь остальным менеджерам и бизнесменам компании. Он закрывает свою зону ответственности, он — главная и часто единственная точка контакта. С ним можно договориться, и на него можно положиться — всё просто и хорошо. Это не всегда эффективно, так как хозяин зачастую не желает выносить сор из избы, не использует оптимально все ресурсы компании, плохо взаимодействует с другими функциями, но зато упрощает жизнь других менеджеров компании.
Начальник — классическое иерархическое лицо, указания которого выполняешь, а затем отсылаешь ему отчёты о проделанной работе. Иерархии в нашей жизни работают, и ничего плохого в этом нет. Но, к сожалению, с начальником, чаще всего, возникает деструктивная игра — если мы делаем всё хорошо, у нас возникает представление: «Это именно я всё делаю, а он только командует». Если мы сделали что-то плохо, думаем: «Я-то делаю всё хорошо, просто это он дурацкие указания дает».
В психологическом смысле начальник нам полезен — мы присваиваем заслуге себе, а ответственность за неудачи переносим на него. Элементы этой психологической игры я вокруг встречаю постоянно. Многие даже стараются найти начальников вокруг себя. Я и на себе ощущаю это давление — от тебя ждут, что ты включишься в эту игру. Включаться или не включаться — выбор каждого, так как каждому удобно работать по своей модели.
Сервис — это менеджер, который просто помогает сотрудникам делать их работу. Я считаю, что в IТ для многих продвинутых компаний сервисная модель — самая привлекательная. Согласно этой модели, на компанию, занимающуюся разработкой заказного ПО, можно смотреть как на компанию, которая сводит инженеров с потребителями их работы, и обслуживает весь этот процесс. Поэтому всё, включая управление капиталом, корпоративное управление, кадровое управление, финансы и т. д. — просто сервисы, которые обеспечивают сотрудникам рабочий процесс. Это, конечно, радикальная модель, но мне она нравится — при ней ты не делаешь ничего лишнего, пока тебя не попросили.
Но, конечно, на самом деле всё не так просто: нужно всё же объяснять людям, что можно попросить и зачем, убеждать людей пользоваться сервисами, иначе ничего работать не будет. Мне кажется, что сервисный взгляд на корпоративные функции выглядит перспективным и интересным, хотя и имеет свои издержки — всем нравится, когда нас обслуживают, и, если совсем впасть в сервисную моду, есть опасность, что все будут пытаться сесть друг другу на шею. Поэтому к вопросу нужно подойти цивилизованно — научить людей «правильно» пользоваться сервисами, что важнее всего в реализации сервисного подхода.
В любой компании все вышеупомянутые функции могут сочетаться, разные люди будут ближе к той или иной роли, но, если вы движетесь к руководящей позиции, такая классификация поможет вам разобраться с точки зрения самоидентификации, где вам удобнее. Если вам неудобно командовать, вы вышли из управления проектами, где использовали влияние на окружающих, вам подойдёт сервисная модель. Если же вам хочется вернуть себе радость от мысли, что именно я сделал то или иное хорошо, быть вам хозяином. А начальником вы и так станете, если не будете делать ничего особенного: ведь выстраивание иерархий — самое естественное поведение в корпоративном мире, которое складывается само собой.
