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

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

,,Работает на моей машине/политической системе”

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

Например, вы создали приложение с определенным фреймворком, оно работает, но ваш коллега считает, что другой фреймворк был бы лучше, и предлагает вам его переписать. Вы уверены, что это способ создать его, но она все еще стоит на своем, что вы делаете?

Первое — понять, почему она так думает. Это сделает дискуссию более рациональной. Во время учёбы мне приходилось читать много литературы, с которой я не был согласен (например, отец коммунизма Карл Маркс), но всё же я её читал, чтобы лучше дискутировать с людьми, которые верят в этих авторов. Хоть я и не верю в коммунизм, теперь у меня были бы лучшие аргументы против него. То же самое и в ИТ. Выслушайте, что говорит ваш коллега, каковы его аргументы. Тогда вам будет легче прийти к общему мнению и, надеюсь, без особых ссор.

«Если есть ошибка, я могу ее исправить» или «Если есть преступление, есть закон, который может это исправить». Есть ли на самом деле?

В инженерии, если мы получаем ошибку, мы знаем, что для нее есть исправление, и в большинстве случаев есть единственное решение для ее решения. Что, если в обществе возникнет проблема — есть ли решение и для нее?

Допустим, есть рост употребления наркотиков. Кто-то скажет, что решение проблемы — это усиление контроля над наркотиками, другие — легализацию наркотиков. Какой выбрать? Чтобы решить политическую проблему, вам нужно поговорить (правило № 1) и тщательно обдумать свое решение. И даже тогда вы не можете быть уверены, что это правильно.

Это научило меня тому, что когда вы сталкиваетесь с проблемой, например с ошибкой, иногда, прежде чем прыгать в код, может быть разумнее сначала подумать о ней в более широком масштабе. Скажем, какая-то функция работает не так, как должна. Было бы разумно сначала поговорить с клиентом. Может быть, эту фичу нужно полностью убрать и ее даже не стоит исправлять, а может быть, это «не баг, а фича» и оставить как есть (меньше работы знаете ли!). В любом случае обсуждение и обсуждение перед погружением в программирование может сэкономить ваше время, энергию и сделать разработку более быстрой, дешевой и более устойчивой.

,,В зависимости от обстоятельств» — как в IT, так и в политике

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

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

Представьте, что вы политик и решили дать бесплатное образование. Решение было одним из многих различных решений для улучшения образования, но вы выбрали это. Большой. Прошло несколько лет, вы добились реформы образования, но как вы оцениваете, работает ли она? У вас могут быть требования, по которым вы его оцениваете, но, в конце концов, важно мнение людей, и оно всегда зависит — кто-то будет доволен, кто-то может разозлиться. Если большинство недовольны, вам, возможно, даже придется отказаться от вашей реформы. Но, может быть, и в бизнесе есть такие случаи?

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

Заключение

Хотя политика не так уж близка к ИТ, она достаточно близка к бизнесу. Оба работают на людей, предъявляют изменяющиеся требования и требуют адаптации к изменяющимся ситуациям. Программирование — более жесткая сфера, основанная на истинности или ложности, но она работает для бизнеса и, в конце концов, должна принимать постоянно меняющуюся бизнес-логику, ориентированную на людей. Я думаю, что понимание этого для разработчика может сэкономить много времени как бизнесу, так и самим разработчикам.