IT для неайтишников: Инженеры в заложниках у бизнеса

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.

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

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

Чтобы стать хорошим специалистом в области информационных технологий, прежде всего нужно быть инженером. Когда я говорю об инженерах, то не имею в виду людей, у которых в дипломе о высшем образовании написано «инженер». В давние времена Российской Империи, когда наука о сопротивлении материалов была не так развита, как сейчас, инженер, который сконструировал и возвёл железнодорожный мост, считал себя обязанным стоять под ним во время его первого испытания. В те времена бывало, что неверно спроектированные мосты обрушались. Это сейчас всё стандартизировано, а тогда с этим было не очень.

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

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

Сталкиваясь с необходимостью решить сложную инженерную задачу, инженер встречается с потребностью найти ряд творческих технических решений. Хорошее решение доставляет инженеру точно такие же эмоции, как художнику создание шедевра. Ради этих эмоций инженер (и художник тоже) живёт и работает.

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

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

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

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

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

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

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

Затем специалиста знакомили с мобильной платформой компании, проводили ему какое-то обучение и садили на поток писать мобильные приложения, те же самые игры. Нормой считалась сдача одного приложения в 1-3 дня.

Вот есть компании, которые новую игру разрабатывают за один-два года, а тут всего за несколько дней. Как же такое получалось? Да просто выпускалось множество аналогов популярных игр, которые несколько оттягивали на себя аудиторию и монетизировали её за счёт рекламы. Таких приложений-клонов можно было клепать великое множество.

Конечно, внутри компании был небольшой коллектив, который разрабатывал платформу. Но это была лишь малая часть от общей массы разработчиков в компании.

После нескольких лет работы на таком конвейере выходили люди с практически нулевым опытом работы. Те разработчики, которые дорабатывали платформу, имели плохую карму и навыки работы не выше среднего.

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

Это не самая страшная бизнес-механика, она отбирает у человека всего лишь год-два на старте его карьеры. Ценных пару лет молодости.

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

Прежде всего, деньги нужно куда-то девать. Конечно, мы развиваем свой продукт и всякое такое, но много денег всё равно остаётся. Кроме этого, мы понимаем, что со временем поток денег будет иссякать, он не будет бесконечным, а к высоким доходам мы уже привыкли. Что делать и как диверсифицировать доходы?

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

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

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

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

Беда в том, что взлетает меньше 10% от всех стартапов, а человек выгорает за несколько таких итераций. То есть для бизнеса нормально, если взлетит одна из 10-20 идей, а вот исполнитель сможет пережить только несколько стартапов, пока не перегорит. Потом человек оглядывается назад, понимает, что былого драйва нет, он всю жизнь работал над простыми продуктами за небольшие деньги, у него нет хорошего опыта и навыков, которые он мог бы предложить рынку.

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

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

Конечно, бывает, что стартапы взлетают и «много денег» реально настаёт. Только везёт не всем. Часть из тех, кому так и не повезло, станут профессионально и эмоционально выгоревшими людьми, которые более не способны к эффективной работе.

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

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

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

Обычный заказчик новой социальной сети не обладает ни огромным бюджетом на маркетинг, ни нечестным конкурентным преимуществом. С деньгами всё понятно, а что с нечестным конкурентным преимуществом? Например, в нашем государстве пробовали создать социальную сеть для учёных, а чтобы ей хоть кто-то пользовался, тех учёных, что подают заявки на гранты либо заявки на конкурс для устройства на работу, обязали там регистрироваться. Люди зарегистрировались, заполнили профили, но пользоваться не стали.

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

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

Скорость профессионального выгорания на таких конвейерах ниже, чем на стартапах либо конвейерах типа «1 приложение за 2 дня», но тем не менее оно неумолимо прогрессирует. Человек думает, что он не сможет рассказывать своим детям, что его работа заключалась в том, чтобы делать двухсотую по счёту социальную сеть, которая никому не нужна.

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

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

Это более сложная и интересная модель, чем работа на конвейере. Заказная разработка на самом деле более широкая и сложная область, чем тиражирование унифицированных решений.

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

Если для бизнеса и инженера важно получить результат, то для среднего менеджмента важно отчитаться. Обычно благосостояние среднего менеджмента зависит не от результата, а от KPI. Для выполнения KPI нужен хороший отчёт. Вот именно хорошо отчитаться, чтобы сохранить/повысить своё благосостояние, и является целью среднего менеджмента.

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

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

В целом, представители бизнеса хорошо понимают, о чём это я. Для остальных анекдот про три конверта.

Кроме того, обыденной действительностью являются попытки со стороны среднего менеджмента отсечь управляющие центры от каналов объективной информации. Если стать единственным поставщиком информации для управляющего центра, то красивые отчеты будет делать гораздо проще.

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

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

Предположим, вы работает лидером команды разработки в крупном банке. Работа строится по Agile, активно используется Scrum, все поделены на стримы. И есть даже Agile-коуч, который учит всех правильно работать. Что же происходит в реальности?

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

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

То есть вашей задачей становится не достижение результата, не поставка ценности на продуктив, а сделать так, чтобы красная лампочка не загоралась. И на это будет работать вся система вокруг вас. Даже если вы захотите работать по-другому, то ваше окружение этого вам сделать не даст. Как бы сказал господин Адизес: «Не поднимай волну».

Через десять лет работы на отчёт, IT-специалист может оказаться никому не нужным. Так как в его работе уже нет ни смысла, ни результата, ни ценности.

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

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

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

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

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

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

• IT для неайтишников: Зачем оно нужно?
• IT для неайтишников: Какими бывают IT-шники? Часть 1
• IT для неайтишников: Какими бывают IT-шники? Часть 2
• IT для неайтишников: Какими бывают IT-шники? Часть 3
• IT для неайтишников: Какими бывают IT-шники? Часть 4
• IT для неайтишников: Какими бывают IT-шники? Часть 5
• IT для неайтишников: Какими бывают IT-шники? Часть 6
• IT для неайтишников: Какими бывают IT-шники? Часть 7
• IT для неайтишников: Какими бывают IT-шники? Часть 8
• IT для неайтишников: Куда исчезают программисты после 40 лет?
• IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
• IT для неайтишников: Технический долг или почему теперь всё так долго?
• IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
• IT для неайтишников: Инженеры в заложниках у бизнеса
• IT для неайтишников: Потеряли ключи от IT, что делать?
• Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
• Процессы в ИТ: Долго, дорого и не то
• Саморегуляция в ИТ: минимально допустимая эффективность работы
• Telegram-канал Записки ITBP (короткие сообщения)
• Канал на Дзен Записки ITBP (статьи среднего размера)