Программист должен решать проблемы бизнеса
Недавно вышла статья, мимо которой я не мог пройти — «Программист не должен решать задачи бизнеса». Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.
Лычки
Думаю стоит начать с лычек. К сожалению, 3 известнейших грейда не имеют четких определений, каждый человек и компания определяют требования индивидуально, границы которых размыты, а иногда это приобретает неожиданные обороты. Поэтому для начала стоит определить, что я понимаю под этими понятиями.
- Juinor — тут меньше всего проблем с определением, начинающий программист, который только-только выучил теорию, возможно, сделал пару pet проектов. Ну или только выпустился из университета.
- Middle — Middle — опытный программист. Разбирается, а не просто знает стек-технологии, которые использует каждый день.
- Senior — это опытный программист, который обладает большим разноплановым опытом, имеет «production» работы на нескольких стеках и обладает «насмотренностью», обладает опытом в смежных областях (например: я считаю нормой, когда Senior Web может обладает навыками администрирования), спокойно может перейти с одного фреймворка на другой или даже с языка на язык без сильной просадки.
Хочешь не хочешь
Программист, хочешь или не хочешь, решает проблемы бизнеса. Всегда, но есть редкие исключения. Нужно понимать, что работа по найму или работа на себя — это всегда товарно-денежные отношения. Бизнесу нужно получать прибыль, с этой прибыли в том числе платится зарплата сотрудникам. Из этого также следует, что для получения прибыли нужно решать проблемы (ну или можно сказать — решение задач бизнеса). Программисту же нужно на что-то жить, и желательно не плохо. Так же нужно понимать, что «пользу» бизнесу (или решать его проблемы) можно приносить по-разному — как косвенно, так и напрямую.
Как это происходит
Давайте разберем классический кейс, и на его примере посмотрим, как происходит решение проблем бизнеса. Прилетает задача — нужно сделать новый сайт, ничего особенного. Если упростить, то задача прилетает по такой цепочке: руководитель компании -> 1-& руководитель более низкого звена -> менеджер -> Тим Лид и дизайнер (как правило два разных отдела, поэтому задача ставиться параллельно) -> senior и/или сразу всем исполнителям. Есть два варианта дальнейших действий:
Кейс 1. Можно просто делать, что скажут, «тупо кодить» — то есть просто все делают в рамках своих прямых обязанностей — Тим Лид обсуждает с бизнесом и заводит задачки в джире, senior продумывает архитектуру и берет на себя наиболее сложные участки, junior верстает, а middle делает обычные задачи, возможно, и сложные вещи вместе с Senior (для упрощения, все Full Stack).
Кейс 2. Перед тем, как взять в работу, организуется несколько совещаний, на которых Senior с Тим лидом, дизайнерами и руководством обсуждают подробно проблему бизнеса. И даже не просто, как решить, а как решить эффективно для всех — и для бизнеса, и для разработчиков, и для дизайнеров. Находится золотая середина, устраивающая всех, и только после этого начинается уже собственно разработка.
Что в итоге?
В рамках первого варианта, когда все «тупо кодят» — в итоге решается проблема бизнеса. Другой вопрос, что она решается не эффективно — 100% срывы сроков, костыли, передача ответственности друг другу, потом, как правило, очень долгое исправление правок и добавление «новых пожеланий заказчика». Все потому, что делали задачу, как поставил ее бизнес. Никто не сказал, что так не нужно делать — все работали как «винтики» в рамках своих компетенций и не лезли решать проблему бизнеса. Здесь не было команды. После таких проектов, как правило, отношения к разработчикам не очень. Бизнесу важен результат. Умные руководители после этого как раз нанимают Senior, которые готовы решать проблемы бизнеса.
А теперь рассмотрим второй вариант. В этом случае максимальное количество подводных камней, которые случаются всегда, удалось решить командным взаимодействием. Не говоря уже о том, что разработчики могут кардинально изменить реализацию проектов, потому что бизнес может понимать неправильно что для этого нужно. Возможны ли в этом случае проблемы? Конечно, многое зависит от компетенций, но их точно будет несоизмеримо меньше. В этом случае также решается проблема бизнеса, но эффективно.
Инфраструктурные проекты
В комментариях к статье, ссылку на которую я приводил в самом начале, советуют перейти на инфраструктурные проекты. Что там как раз можно просто кодить. Это обманчиво. Разработчики так же решают проблемы бизнеса, внутренние. Это точно такие же товарно-денежные отношения. И проблемы такие же, как и при работе над внешним продуктом компании. Другой вопрос, что, как правило, инфраструктурные проекты пишут по первому кейсу. Отсюда и результат. Но даже здесь решаются проблемы бизнеса, и программист принимает участие в решениях.
Команда
Основное отличие первого и второго кейса даже не в реализации, а в команде. И под командой я подразумеваю не пару кодеров, которые реализуют проект, а всю компанию. В первом случае — просто отсутствие команды, во втором ее присутствие — все работают совместно, чтобы получился хороший результат. Понятно, что есть много допущений, но мир в целом не идеальный.
Решение проблем бизнеса != продажи
Я не знаю почему, но часто решение проблем связывают с продажами. Да, зачастую многие задачи с ними связаны, но это только один из факторов и зачастую не самый важный.
Программист не должен задумываться о том КАК будут продавать, но он должен задумываться о том ЧТО будут продавать. От принятия чисто архитектурных решений (которые зачастую Senior и продумывает), скорости отклика, логики работы, дизайна (да, перед его разработкой программисту НУЖНО участвовать в проектировании интерфейса) и т.п. — зависит качество конечного продукта. Даже инфраструктурный проект продают, но внутри компании. От качества конечного продукта зависит эффективность компании и соответственно персональные плюшки (не только материальные).
Исключения
В самом начале статьи, я говорил, что программист хочет не хочет — решает проблему бизнеса, но есть исключения. На мой взгляд единственное исключение, это pet проекты. То, что ты делаешь для себя. С натяжкой можно взять OpenSource, но там часто получается, что твой коммит решает проблему бизнеса, но не твоего.
Вывод
Программист ДОЛЖЕН решать проблемы бизнеса? Да, должен. На уровне своих компетенций, должности и опыта. Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить? Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.
Как программирование влияет на бизнес
Много ходит споров о том, какой стоит изучить язык программирования, чтобы сделать карьеру в сфере разработки. Но я глубоко убежден, что языком обязательный набор знаний не ограничивается. К сожалению, не все это понимают.
В обсуждениях задач бизнес и разработчики говорят на разных языках.
С точки зрения бизнеса совершенно не важно, на каком языке будет решена их задача. Бизнес не думает, а возможно, даже не знает о java, go, ruby и других языках и технологиях. Для разработчиков здорово, конечно, когда масштабный и интересный проект начинается с нуля и технологический стек выбирается командой. Но в реальном мире гораздо чаще происходит не так. Обычно в компании уже есть экспертиза в определенном стеке, от которой ИТ-руководству не хочется отказываться. Причины могут быть совершенно разные, от запрета на “зоопарк технологий” до личных предпочтений лиц принимающих решений. Встречаются и дополнительные факторы вроде потребности в интересных технологиях для команд, ради привлечения и удержания квалифицированных кадров.
Разработчики со своей стороны зачастую высказывают желание развиваться в определенном технологическом стеке. Подкрепляет это намерение большая разница между зарплатами для некоторых языков. Так и появляются люди, которые упорно живут, например, в рамках Java или Python (Go, Kotlin, Scala… список можно продолжать чуть ли не бесконечно) и даже Delphi, не пытаясь посмотреть, а что есть еще.
На мой взгляд, желание углубиться похвально. Но иногда “за деревьями теряется лес” — в процессе этого погружения специалист просто забывает о том, что для бизнеса технологии — лишь инструмент для решения своих задач. В итоге зашоренность на одном технологическом стеке в комплекте с врожденным перфекционизмом (“а давайте сделаем рефакторинг на полгода проекту, у которого нет серьезных планов по развитию, просто потому, что так будет красиво”) не самым лучшим образом отражаются на качестве принимаемых решений.
Моя точка зрения состоит в том, что конкретный язык программирования вторичен. Первичны общее понимание принципов разработки и умение решать проблемы бизнеса — знание подходов и паттернов, которые помогают систематизировать общую работу, опыт применения различных техник, в том числе командных. С таким багажом еще один язык, который нужен в данном конкретном проекте, освоить несложно. У меня перед глазами полно примеров того, как люди переквалифицируются на другие стеки в течении месяца — двух интенсивного обучения. Конечно, сложнее переключаться между языками с разными парадигмами, например с функциональных на объектно-ориентированные, но и здесь нет ничего невозможного, если человек не противится такому переключению “на уровне веры”.
Зная несколько языков, под каждую конкретную бизнес-задачу можно выбирать свой подход к решению — тот, что не просто подойдет, но будет оптимален в данном конкретном случае. И чем больше в арсенале разработчика база этих подходов (языков), тем получается шире взгляд на проблему и мотивированнее выбранный стек. Бизнесу, собственно, это и нужно — получать наиболее подходящее решение для своих задач.
А вот с глубоким знанием одного языка, но без способности решать бизнес-задачи специалист принесет пользу далеко не любой команде. Безусловно, в отдельных проектах глубокие знания “фишек” языка помогают команде в целом добиться большего перформанса. Но чаще член команды, знающий один язык, но не умеющий слушать бизнес, будет лишь тормозить коллег. И кстати, такой “ходячий справочник неочевидных возможностей” зачастую если и нужен в конкретной команде, то только один (делаем выводы о востребованности таких узких специалистов на рынке труда).
Умение решать бизнес-задачи — это на самом деле часть более глобальной сущности — всестороннего опыта работы. Получить его можно как с работодателем, так и в рамках домашних проектов. Правда, на мой взгляд, только бизнес-проекты (где есть заказчики, бюджеты, сроки) могут дать столь необходимую в подобных ситуациях обратную связь, оценивающую качество решения. А именно это определяет глубину полученного опыта. С домашними проектами такой обратной связи получить просто не от кого: ты сам что-то делаешь и в определенный момент решаешь для себя, что сделал хорошо. На этом все заканчивается. Но когда проект реализуется для бизнеса, недостаточно проработанное решение будет отправлено на доработку,
потом еще и еще раз, если это необходимо. И по ходу этих итераций ты неизбежно изучишь несколько подходов к задаче — получишь понимание более высокого уровня.
Программирование бизнесу: как мы делаем ЭТО?
Есть такая идиома в английском — «it’s not rocket science», буквально — «это не ракетостроение». Мы обычно в таких случаях говорим — «это не высшая математика». То есть: «Хэй, это же просто!». Не заумно, не заоблачно — доступно и понятно. Наша цель такова: клиентам должно быть понятно все то, что мы с помощью программирования делаем для их бизнеса. Наша работа не должна быть для них «загадкой», когда они даже не знают, за что именно платят.
Поэтому мы уверенно говорим: программирование it’s not rocket science для них и для нас. Это просто: просто оптимальный способ решения бизнес-задач с помощью наших умений и знаний.
Как это было устроено раньше?
Еще лет 10−15 назад у разработчиков (и у нас в том числе) преобладали задачи, связанные именно со спецификой программирования. Например, реализовать обмен сообщениями или почтовый сервис, написать блог или форум. Были специалисты, которые занимались написанием баз данных, организацией хранения информации и т. д. Подобные задачи относятся к инфраструктурным. Реальную выгоду от их решения пользователь, как правило, «пощупать» не может — но без них невозможно запустить ни один проект. Тогда, лет 10−15 назад, можно было считать, что программирование — это действительно «rocket science»: разработка шла на уровне технологии, а заказчик ни слова не понимал.
Факт: В Индии была широко распространена практика оценки труда программиста по количеству написанного им кода: чем больше строк — тем лучше специалист работает и, следовательно, выше оплачивается. Находчивые разработчики специально удлиняли все, что могли, тем самым породив еще одну идиому — «индусский код».
Как это работает сегодня?
C одной стороны, сегодня программирование — это кое-что «пострашнее» ракетостроения. В нем одна цель — чтобы ракета летела, а для программистов бизнес ставит столько невероятно разноплановых задач, как будто каждый из них ракетостроитель-вокалист-экзорцист, имеет водительские права для БелАЗа, черный пояс по дзюдо, кубок Сибири по рыбалке, научную степень экономиста и отлично печет печенюшки. (Ну хорошо, печенюшки иногда не нужны.)
Сейчас акцент смещается: базы данных, системы обмена сообщениями, библиотеки, фреймворки, платформы и многое другое уже «изобретено», оно работает и решает, буквально, все инфраструктурные задачи. Более того, вся эта система сейчас настолько развита, что если программист попытается реализовать что-то заново, то, наверняка, его «поделка» окажется менее качественной.
Поэтому акцент постепенно смещается от инфраструктурных задач в сторону бизнес-задач, решение которых необходимо конкретным пользователям. Миссия программиста сегодня не в том, чтобы просто написать код, а в том, чтобы собрать из существующих решений и инструментов тот проект, который будет удовлетворять потребности бизнеса.
Это и лежит в основе нашего рабочего манифеста: само программирование не так ценно, как решение задач с помощью программирования.
Как организована наша работа?
И пока программистов в вузах учат по-прежнему «писать код», профессиональная сфера требует от них уже немного других навыков, главный из которых – это коммуникация. У всех на устах, к примеру, философия Agile (от англ. «проворный»). По науке, это семейство «гибких» подходов к разработке программного обеспечения. По факту – это программирование, основанное на адекватности подхода к работе, человеческом отношении между разработчиком и клиентом и отлаженной коммуникации на всех уровнях.
Стереотип о «бородатых диких программистах», которые кодят, сидя в уединённой пещере, уходит в небытие. Напротив, бизнес-сообщество активно перенимает опыт и технологии работы (например, тот же agile) у IT-бизнеса. Оказалось, что эти вот «интроверты» отладили коммуникации с клиентом так, что у них есть чему поучиться.
— Сейчас перед нами стоит проблема ускорения процесса производства. Для ее решения необходимо, чтобы коммуникация шла напрямую. Многие детали проекта доступны только разработчику. И если тот не будет замотивирован выдавать заказчику обратную связь – проект будет страдать. Программисту никак нельзя действовать по принципу «мне сказали – я написал», необходимо вникать в то, как будут пользоваться его разработкой, уметь вовремя сообщить, что «так это работать не будет». Раньше на такую обратную связь часто «забивали», программистам говорили: «Ваше дело код писать». А сейчас к этому начинают прислушиваться, эффективная коммуникация рассматривается как один из главных источников ускорения производства. — Евгений Тюменцев, генеральный директор «Hello World! Technologies»
Согласно современным требованиям, программисту необходимо развивать не только его hard skills, то есть исключительно профессиональные навыки, но и soft skills, «мягкие навыки» – к ним относятся, в том числе, ответственность, учтивость, умение слушать, говорить и договариваться. Акценты смещаются, профессия программиста трансформируется — и, собственно, спрос с них уже не такой: «пишет код – и хорошо». Вопрос в том, решает он задачи или нет.
Мы в «Hello World! Technologies» не только пишем и говорим об этом, но и следуем своему манифесту и отвечаем на современные запросы бизнес-среды. И на примере своих кейсов показываем, как именно мы можем, применяя знания в области программирования, решать задачи, стоящие перед бизнесом.
Жизнь после кода. Из программистов в бизнес-консультанты, менеджеры, продавцы
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Т для многих продвинутых компаний сервисная модель — самая привлекательная. Согласно этой модели, на компанию, занимающуюся разработкой заказного ПО, можно смотреть как на компанию, которая сводит инженеров с потребителями их работы, и обслуживает весь этот процесс. Поэтому всё, включая управление капиталом, корпоративное управление, кадровое управление, финансы и т. д. — просто сервисы, которые обеспечивают сотрудникам рабочий процесс. Это, конечно, радикальная модель, но мне она нравится — при ней ты не делаешь ничего лишнего, пока тебя не попросили.
Но, конечно, на самом деле всё не так просто: нужно всё же объяснять людям, что можно попросить и зачем, убеждать людей пользоваться сервисами, иначе ничего работать не будет. Мне кажется, что сервисный взгляд на корпоративные функции выглядит перспективным и интересным, хотя и имеет свои издержки — всем нравится, когда нас обслуживают, и, если совсем впасть в сервисную моду, есть опасность, что все будут пытаться сесть друг другу на шею. Поэтому к вопросу нужно подойти цивилизованно — научить людей «правильно» пользоваться сервисами, что важнее всего в реализации сервисного подхода.
В любой компании все вышеупомянутые функции могут сочетаться, разные люди будут ближе к той или иной роли, но, если вы движетесь к руководящей позиции, такая классификация поможет вам разобраться с точки зрения самоидентификации, где вам удобнее. Если вам неудобно командовать, вы вышли из управления проектами, где использовали влияние на окружающих, вам подойдёт сервисная модель. Если же вам хочется вернуть себе радость от мысли, что именно я сделал то или иное хорошо, быть вам хозяином. А начальником вы и так станете, если не будете делать ничего особенного: ведь выстраивание иерархий — самое естественное поведение в корпоративном мире, которое складывается само собой.
�� Подобається Сподобалось 2
До обраного В обраному 1