Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы

Image via Shutterstock

Меня зовут Михаил Завилейский. Формально я — генеральный директор DataArt. Но, на самом деле, просто из один многочисленных руководителей компании — ведь самого главного начальника у нас нет. В DataArt я отвечаю за организационное развитие. До прихода сюда 10 лет работал в IT — в основном программистом, но также немного и менеджером.

В этой статье мы поговорим о карьере. Я расскажу, что происходит с программистами, которые почему-то хотят перестать работать инженерами. Сказанное будет относиться также к тестировщикам, инженерам качества, автоматизаторам и другим смежным специалистам. Мы посмотрим, куда могут двигаться такие специалисты.

Причины перехода

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

Опыт, тем не менее, помогает лучше угадывать, что нужно клиенту; также растет эмоциональный интеллект, развивается лучшее понимание мира и отрасли — оказывается, такие навыки могут отлично пригодиться в других областях IТ-индустрии.

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

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

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

Карьера инженера

Вот типичный карьерный путь программиста, тестировщика или другого 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Т для многих продвинутых компаний сервисная модель — самая привлекательная. Согласно этой модели, на компанию, занимающуюся разработкой заказного ПО, можно смотреть как на компанию, которая сводит инженеров с потребителями их работы, и обслуживает весь этот процесс. Поэтому всё, включая управление капиталом, корпоративное управление, кадровое управление, финансы и т. д. — просто сервисы, которые обеспечивают сотрудникам рабочий процесс. Это, конечно, радикальная модель, но мне она нравится — при ней ты не делаешь ничего лишнего, пока тебя не попросили.

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

В любой компании все вышеупомянутые функции могут сочетаться, разные люди будут ближе к той или иной роли, но, если вы движетесь к руководящей позиции, такая классификация поможет вам разобраться с точки зрения самоидентификации, где вам удобнее. Если вам неудобно командовать, вы вышли из управления проектами, где использовали влияние на окружающих, вам подойдёт сервисная модель. Если же вам хочется вернуть себе радость от мысли, что именно я сделал то или иное хорошо, быть вам хозяином. А начальником вы и так станете, если не будете делать ничего особенного: ведь выстраивание иерархий — самое естественное поведение в корпоративном мире, которое складывается само собой.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn

Схожі статті




29 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

По сути, отличия между джуниором и синьором на 80% — в психологических качествах, и лишь на 20% — в знаниях и опыте.
Ну и чушью. 80/20 это как по объему? по весу? Каждый кто хоть раз работал в команде состоящей из сеньоров и джунов это знает. Да от психологический качеств практически на 100% зависит сколько ты знаний получишь , но ведь чтобы получить любые знания нужны соответсвующие психологические качества, А работодатель платит готов платить большую зп синьору не за психологию, а за знание и опыт — которые являются производными от внутренних качеств, и поэтому они не сравнимы

Понравилась статья, но я так и не понял к чему тут продавцы.
Остальные рассмотренные позиции менеджерские, и вроде понятен рост специалиста любой области до эксперта/менеджера.
А продажи, это просто другая область.
Та и комментарий про уверенность в контексте продаж не понятен. У продажников воронка продаж, а у технаря, если можно так выразиться, «воронка решений».
Если технарь делает понятные вещи, которые он кучу раз делал, то да, его кпд приближается к 80-90, но в жизни обычно каждая задача уникальная по своему, и далеко не всегда с первого раза правильное решение находится. Всегда есть какая-то доля изобретательства и фейлов пока верное решение найдешь. И вот здесь тоже нужная большая доля уверенности в себе и своих действиях, потому что после второй-третьей неудачной попытки могут руки сложиться. И в то время как продажнику за два часа можно сделать 50 звонков для своей воронки, то технарю зачастую этих двух часов не хватит даже на один промежуточный результат.

(Я и продажником был и сейчас кодер. Это вообще разное.)

Очень понравился структурный анализ. Учитывая то, что сейчас занимаюсь развитием курсов по подготовке менеджеров по продажам в ИТ, добавлю несколько комментариев:

— продавцам на самом деле очень тяжело, я в постоянном поиске тренеров и общался с самыми лучшими, кого смог найти в ИТ индустрии. Вот лишь несколько качеств, что определяют их успех:
— все задачи выполняются с позицией собственника, они хотят принимать решения за все процессы, что хоть как-то связаны с продажами, этим и объясняется неугасимая вера в успех даже после множества неудач
— они ну очень много знают — языки программирования на уровне зачем, где, как; структурирование и организацию рабочих процессов; домен клиента и все посление новости в нем; всех клиентов и ЛПР поименно, дни рождения и т.д. (тут, конечно, помогают органайзеры)))
— они не только интересно рассказывают, но и увлекательно слушают — хочется им рассказать все, что знаешь и убедиться, что собеседник остался доволен

— среди лучших продавцов не встретил ни одного бывшего инженера

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

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

Пользуясь случаем, приглашаю всех узнать больше о карьере менеджера попродажам в ИТ в следующий вторник — 16 февраля. Больше информации здесь www.facebook.com/events/503802076411431/

Если пост читают и скилованные продавцы — с радостью с вами пообщаюсь на предмет преподавания. Мы внедряем очень интересную методику обучения, вам это наверняка очень понравится))) Вот здесь про первый курс комплексного обучения
www.highschool.com.ua/it-experts-sales

Весьма правильные мысли с оговорками, в очередной раз, ввиду аутсорсности мышления автора.
1. «Возрастные изменения нашего мозга» — это не причина перехода от инженера к менеджеру. Если переходи обусловлен именно возрастом, то жалко этого заурядного менеджера. Его успех стремится к нулю на фоне лидеров рынка. Обычно, успешные менеджеры, ставшие таковыми после инженерного прошлого — это люди, которые изначально хотели больше, чем кодить, но нуждались в опыте.
2. «Сервисные же компании могут предоставить разнообразие» по сравнению с продуктовыми — это самое большое заблуждение аутсорсников. В продуктовой компании возможностей по реализации своих амбиций значительно больше.
а) потому что рост компании не ограничен заказчиком, а только возможностями развития компании на рынке.
б) компания способна выделять направления под эксперименты конкретных инициаторов.
в) каждый инженер, успешно превратившийся в менеджера продукта/направления/отдела влечет за собой создание десятков инженерных вакансий для реализации целей этого менеджера.
г) каждый менеджер, ставший у руля прибыльного направления компании становится обладателем доли акций компании и, с еще большим энтузиазмом, берется за работу.

Перечень позиций, на которые может перейти программист тоже весьма скупой. Видимо, такие компании, как Apple, MS и тд настолько далеки от наших реалий, что при анализе люди даже не задумываются кем были топы этих компаний в начале. Джобс тоже писал ПО для HP. Гейтс — сами знаете. А на сегодня интернет маркетинг вообще поддается тем, кто больше понимает техническую составляющую, т.к. продать товар легче тому, кто способен объяснить как это работает, либо вывернуть информацию так, чтоб она привлекала и удовлетворяла требования пользователя

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

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

Вместо этого мы должны учиться извлекать из неопределенности достаточное количество преимуществ, чтобы они компенсировали случающиеся у нас проблемы.
Це — гарно сформульовано!

Так. Цікаво. От у мене інша ситуація. З консультанта хочу стати програмістом. Можу навіть юніором з Django... Дивно? Та такі реалії Дніпропетровська. Як у тому анекдоті з «Золотої Рози»:
«Ой не надо здесь умничать. Здесь все біли еврейскими мальчиками».
Я маю на увазі ситуацію, коли
"
Керівник бізнесу: «Ми не розуміємося у цій царині, тому запросили консультанта»
Консультант: «Вам потрібно зробити оце й оце»
Керівник бізнесу: «Ні, нам це не потрібно! Запропонуйте те що нам потрібно»
;-)
"

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

В широком понимании Account Management — это широкая зона, покрывающая все отношения с внешними или внутреннми заказчиками, и отноести можно туда почти все менеджерские роли, В узком смысле всё зависит от компании и методологии, у нас Account Manager скорее собирательное навание «эникейщиков» в области отношений, часто они проксируют как раз PO/SM, если они у клиента и не тянут управление заморскими командами.

Из вашей же статьи

Есть огромное количество вещей, которые происходят в аккаунт-менеджменте. Это передний рубеж, на которым узнают, что нужно сделать, чтобы заработать денег.
Конечно, PO вполне себе подходит под это описание, но все-таки PO называют именно PO и именно в аджайле. В силу малого опыта я не берусь утверждать, но ни разу не слышал употребления термина за рамками аджайла, да и история возникновения термина по моим данным ведет именно к истокам аджайла.
С другой стороны, если под продуктом подразумевается сервис, который аутсорс предоставляет заказчику, то в таком случае аккаунт-менеджера можно называть и PO этого продукта. Только причем тут аджайл и смысл вообще в этих словесных играх?

Додайте ще що в великих організаціях при рості в бік менеджменту починаються цікаві (або не дуже) політичні ігри. Звісно до банків (за павуками) або держкорпорацій ІТ організаціям далеко але тим не менш.

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

Согласно разным научным исследованиям, логический интеллект у большинства с возрастом слабеет и мало у кого усиливается. Так, в современной математике и физике большая часть самых важных открытий делается в молодом возрасте, и опыт не может заменить возрастное снижение живости ума.
Это у кого как, но вот немного стастики:
The average age when awarded is 55 for all the Physics Laureates between 1901 and 2014. The most frequent age bracket for Physics Laureates is 45-49. Only one Physics Laureate has been under 30 years, that is Lawrence Bragg, 25 years old when he was awarded the Nobel Prize with his father in 1915.

Просто награды находят героев с большой задержкой. Но правил без исключений конечно нет.

Автор пробач, але мені не хочеться дочитувати цю статтю до кінця, ти зациклений на аутсорсінгу та аутстафінгу, але що ти скажеш про продуктові компанії? Головне продатись)))

Це просто усміхнуло —

Итак, однажды у нас в компании появился не очень хороший коллега-программист. Я познакомился с ним, когда он вызвал команду ОС “удалить всё из текущего каталога” из сервера приложений (тогда это был ASP) — так он удалил из “system32” всё, что можно было удалить. После этого сервер продолжал работать какое-то время (файлы, которые в тот момент использовались, не удалились), но он никогда не перезагрузился бы и скоро упал, как только захотел бы сделать что-нибудь новое и загрузить какой-нибудь dll из system32.

Насправді у вас в компанії появився гарний QA, який виявив серйозну проблему в секюріті, а програмісти у вас були такі собі, якщо позволяли ідентіті з веб сервера отримувати повний доступ до каталога віндовс.

Пробачте за тролінг, просто не міг стриматись)))

Всього найкращого

То было 18 лет назад, и даже ещё до официально рождения DataArt. Я тогда работал в крупном интернет-провайдере, который продавал и разработку сайтов — маленьких по $300, больших — по $500 (это не шутка, даже цифры точные), под девизом «остальное отобъётся на хоcтинге». Типичный e-commerce ставил в подсобку десктопосервер на колокейшен, «покупал пролраммиста» за 400-600 долларов в месяц и они творили что хотели и как хотели. В США было не лучше — когда в 1998 нам забывали дать пароли от машин клиента или аккаунта у провайдера, никаких проблем всё равно с деплойментом не возникало — безопасности не было вообще (особенно на MS стэке), зато были эпические админские пароли, до сих пор помню «AstralGod». на sa/domain admin. Всё смыло крахом доткомов в начале века, к 2003 и индустрия, и мы преобразились, впитав лучшее от традиционных компаний, рождённых вне пузыря, а потом начался процесс взаимного обогащения. Но это всё медленно — для многих крупных клиентов waterfall — самое свежее достижение в планировании до сих пор :).

Статья очень понравилась, спасибо за статью :)

Спасибо за отличную статью!

Отличная статья. Уверен она будет полезна многим. Ее ценность повышает то, что это выводы на основе личного, довольно богатого опыта, а не повторение известных истин. Михаил, спасибо. Если бы вашу эстафету по написанию статей, подхватили другие руководители, аудитория ресурса от этого только выиграла бы.

Дуже круто, дякуємо, з самоіндифікацією допомогло :)

Ключевое здесь:

для неинженеров

Спасибо. Хорошо написано !

крутая статья!

Отличная статья, легко читается.

Поэтому управление ожиданиями — самая главная функция менеджера проектов, в отличие от остальных менеджеров в сфере IТ.

Михаил, спасибо за понятную и полезную статью.
Управление ожиданиями (формально — stakeholder management) — одна из 10 областей знаний, которыми должен обладать менеджер проектов согласно PMBOK 5 (в ранних версиях это было частью управления коммуникациями).

Вот вам картинка получше для статьи mcmanus.co.za/...2015/03/PMBOK-graphic.jpg

Женя, спасибо! Я картинку искал страшную и неправильную, чтобы красивее перейти к управлению ожиданиями. Это вообще расшифровка живой презентации, отсюда особенности. А про PMBOOK — штука полезная и авторитетная, но уж больно всеобъемлющая ;)

Підписатись на коментарі