Поговорим о том, что в значительной мере стало причиной создания концепции IT~BP — конфликт бизнеса и инженеров, участником которого, то с одной, то с другой стороны оказывались основатели в течение 10+ лет. Если у вас есть похожий опыт, пожалуйста, напишите в комментарии своё мнение и точку зрения на обсуждаемое в этом посте.
Есть 1 аспект, который каждый день подливает масла в огонь. О нём читайте ниже.
Сегодня поделимся взглядом на происходящее с точки зрения инженеров и IТ-специалистов. Покажем, как бизнес по разным причинам оказывается на пути деградации целых IТ-команд, сам того не подозревая.
Конечно же, чтобы мы могли понять точку зрения, нам необходимо свериться в понимании персоны инженера.
Выглядит так, что стать инженером достаточно сложно. По факту, воспитание хорошего специалиста начинается за школьной партой. Затем институт, либо университет, с очень даже не символической нагрузкой. От качества заложенной базы зависит уровень сложности решаемых специалистом задач и скорость их решения.
Информационные технологии — это комплексная область, требующая системного мышления, определённой глубины и объёма знаний, поставленного логического аппарата и хорошей самодисциплины, так как компьютер логических ошибок не прощает. Кроме того, работа профессионала в области IТ связана, одновременно, и с творчеством. А это требует очень разнопланового развития.
IТ стремительно развивается. И нужно весьма быстро бежать, чтобы оставаться на месте. Хороший инженер вынужден уметь быстро и эффективно учиться. Более того, он любит это делать. И будет этим заниматься в своё свободное время.
А ещё нужно уметь четко выразить свою мысль на компьютеропонятном языке. Причём компьютер выполнит ровно то, что ему скажет программист. На страх и риск этого самого программиста. Всё это, конечно, даётся не просто и требует высокой концентрации во время работы. Мы думаем, что профессиональная деформация в виде гиперконцентрации появляется именно таким образом.
Делаем вывод, что настоящий инженер — это высококвалифицированный, упорный и замотивированный на решение сложных задач человек с хорошо поставленным мышлением. И применять его нужно соответствующим образом. А с этим чаще всего, и возникают проблемы, которые подкидывают заметную долю дров в пожар разбираемого нами конфликта. Ниже распишем самые распространённые причины.
- Отсутствие ощущения полезности и применимости в своей работе. Зачастую, разработчиков держат подальше от бизнеса и информации о том, что с ним происходит. Делают это, даже почти всегда, из добрых побуждений. «Зачем их грузить этой информацией, им всё равно не интересно»; или «ребята далеки от этого, потом дольше на вопросы отвечать будем»; а ещё хлеще «ой, ребята, распереживаются, будут хуже работать или так расстроятся что уйдут»; или совсем катастрофическое «зачем им цифры нашего успеха — вдруг больше попросят денег». А ещё бывает, что разработчик несколько месяцев участвовал в проекте, а потом оказалось, что он не пригодился. Ну просто не подумали о применимости в самом начале. Или стартап (в который многие рвутся) не полетел. А что в этот момент с инженером? Сначала он горит, вкладывает душу в первый проект, затрачивает массу энергии на успех проекта. А ему не рассказывают о его успехе или даже о провале после попытки запустить. И да, проект может быть бизнес-бесполезным, но технически совершенным. Или может проект просто сразу лёг в стол. Потом попадается второй такой проект. Третий. Следующий и так далее. Всё это приводит сначала к смене работодателя, в порыве найти другое отношение, однако не везёт в среднем чаще, чем находится осознанная команда. Так начинается путь к тотальному выгоранию и разочарованию в сфере. А значит и отсутствию инициативы и безразличного отношения к нанявшему его бизнесу.
- Следующая ситуация очень часто происходит в компаниях, для которых IT — часть клиентских проектов, на которых бизнес зарабатывает уже в операциях, или в заказной разработке. Продажа проекта не всегда ведётся с привлечением технического специалиста. Как следствие, в IТ-команду приносится задача, которую, например, сделать в уже зафиксированный бюджет и сроки с приемлемым качеством просто невозможно. Скорее всего это приводит к давлению со стороны бизнеса («ЕСЛИ НЕ СДЕЛАЕТЕ, ТО ПО ВАШЕЙ МИЛОСТИ, МЫ ЗАВАЛИМ ПРОЕКТ»), под которым команде приходится лепить гору костылей, лишь бы подписать акты с заказчиком. Такая работа не доставляет удовольствия. И либо человек уходит, либо привыкает делать откровенную халтуру. А это самое страшное, ведь обжигаясь в этой компании, он отправится «дуть на молоко» и в следующую компанию, заранее предвзято относясь к представителям бизнеса.
- Некоторые компании же организовывают работу с IТ-командами и инженерами как с линейным персоналом или операционными департаментами. Часто такое бывает в корпоративном секторе. Команду разработки погружают в сложные и долгие процессы, требующие согласования всего чего угодно. Всё это может сопровождаться какими-то политическими играми, в которые играть инженеры точно не хотят (мы разобрали их мотивацию выше). Но это не значит, что они не злятся, оказавшись втянутыми в это. И сначала они просто злятся, а потом начинают заниматься саботажем, пытаясь сигнализировать хоть кому-то, кто может заметить, что в процессе есть явные сбои, и его пора менять. Часто и это не срабатывает или приводит не к тому результату. Хороший инженер просто меняет работу. Он и так сейчас востребован везде. А в компании остаются либо неплохие специалисты с убитой самооценкой, которые просто работают как исполнители за стабильную зарплату, не прикладывая к процессу голову, либо просто недоучки. Последние, кстати, тем не менее умеют хорошо прятать свою некомпетентность за всё теми же злосчастными процессами.
Считаем это 3-мя основными причинами, которые только увеличивают масштаб конфликта представителей бизнеса и инженеров. Усугубляет происходящее то, как бизнес видит итоги⤵️
- Ему нужно решить какую-то задачу в мире digital.
- Он не знает как это делается, как это решают другие.
- Значит нужен партнёр, который расскажет, покажет, подскажет и подстрахует.
- А вместо этого перед ним чаще всего оказывается исполнитель, которому что ни скажи, он сделает. А когда наступят последствия кивнёт на ТЗ.
- Когда новых способов разрешения проблемы не видно, бизнес усиливает давление и всё идёт по кругу.
Как же всего этого избежать или начать снижать риски? На это отвечает концепция IT~BP.
- Отнеситесь к инженерам как к тем, на кого они учились. Дайте возможность проявить экспертизу, основываясь на реалистичных вводных и настоящих проблемах и целях бизнеса.
- Поделитесь доступной обратной связью бизнеса, клиентов и пользователей о проделанной командой работе. Будьте честны и полны в своей коммуникации. Если относиться к сотрудникам как к детям, они в них превратятся.
- Перед стартом разработки уделите время целеполаганию и синхронизации всех сторон, задействованных в проекте.
- Результаты тезисов 1-3 позволят вам избавиться от манипуляций во взаимодействии и вести диалог без переводчиков. Фраза: «это сложно, не буду объяснять, ты всё равно не поймешь» просто улетучится. Как следствие сэкономите время и энергию, которые больше пригодятся в деле достижения бизнес-целей.
- Вводя регламенты деятельности IТ-команд, помните о навыках и восприятии людей, которых собираетесь в них поместить. Определите бизнес-пользу от этого и действуйте соразмерно имеющимся целям.
И да, мы не говорим, что все прошедшие путь из рассуждения об Инженерах таковыми являются. Скорее соответствие указанным параметрам делает человека Инженером. То есть тем, кто:
- не любит дилетантство;
- достигает результата;
- понимает бизнес-заказчика и его цель;
- задаёт соответствующие вопросы;
- предлагает разные варианты решений;
- готов брать ответственность за их реализацию.
И если взаимодействовать с этими людьми, как описано в рекомендациях, бизнес и инженеры начинают работать как единая команда с общей целью, помогая, а не мешая друг другу. При этом инженеры самостоятельно и оптимально решают технические вопросы, не забывая узнать, как это может отразиться на бизнесе. То есть работают, как партнёры, а не исполнители.
Что с этого получают сами инженеры? Возможность спокойно работать и получать удовольствие от результатов своего труда, которыми можно гордится. Возможность, если делаешь что-то во второй либо третий раз, то сделать это лучше и быстрее. Пусть это будет уже сотый многокилометровый железнодорожный мост в карьере, но он будет сделан на порядок быстрее и дешевле, и будет в разы надежней, чем тот первый, самый обычный.
На испытаниях моста инженер не будет стоять в сторонке, а по старой традиции — под мостом. Потому, что плохо он не делает. И не заставляет других рисковать за себя.