Название классное, но можно сказать, что это еще не все… солнце. Вопрос: в чем ошибаются как технические, так и нетехнические люди? Прочти и узнай!

Теневые ИТ

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

В настоящее время все крупные компании являются технологическими компаниями, даже если они ими не являются. Это уже даже не мнение, а факт.

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

«Гражданский застройщик»

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

Мой опыт

Если вы просмотрите другие мои посты и ссылки, вы, вероятно, поймете, что я тоже являюсь разработчиком в Shadow IT. (Или так, или, знаете, вы только что прочитали заголовок. Но я уверен, что вы прошлись по моим ссылкам 😉.)

Тогда

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

Проблема «теневых ИТ» не нова, но некоторые компании уже давно начали обучать больше «гражданских разработчиков». В моем случае у меня было недельное обучение MS Access (тогда я уже был «парнем в Excel»), и в качестве сноски, поскольку учитель мог пройти все, что им было нужно, был один класс по VBA (оглядываясь назад , хотя он был… визуальным, он был намного меньше основного!).

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

Если вам это знакомо, вы, вероятно, помните мой первый пост, потому что это была отупляющая работа по кликам, копированию и вставке до тошноты. Я повернулся к своей начальнице и сказал: Возможно, я смогу это автоматизировать, и, поскольку терять было особо нечего, она сказала: Давай. Итак, моим первым приложением стал инструмент веб-автоматизации, написанный на VBA и Excel.

Во втором случае я автоматизировал отправку электронной почты (представьте себе прямую почтовую рассылку), и только эти два сэкономили тысячи часов моему отделу, являются яркими примерами Shadow IT и помогли мне стать полноправным программистом. И все, что я знал тогда, это VBA (самые основы программирования), серьезно! Я, наверное, ничего не знал, кроме присваиваний, if, циклов и goto (да, в VBA есть goto и я этим злоупотреблял).

Сегодня

После VBA я прошел через несколько языков и фреймворков: Java, JSP, jQuery, Angular, Python и, наконец, мой текущий хлеб с маслом Javascript, Typescript, React и Node.

Сегодня я считаю себя программистом (для меня каждый программист пишет код, но не каждый, кто пишет код, является программистом), и я стремлюсь поставлять качественное программное обеспечение даже со всеми ограничениями, которые корпоративные ИТ налагают на теневые ИТ-команды.

Мне приходится бороться с прокси, предназначенными для сотрудников, не являющихся разработчиками, документацией и внутренними API, о которых они на самом деле не хотят, чтобы мы что-либо знали (например, аутентификация LDAP и даже доступ к базовым таблицам из внутренних озер данных). Когда что-то изменится, теневые ИТ-команды узнают об этом последними, и только потому, что люди приходят с жалобами на то, что что-то начинает ломаться.

Хотя вы думаете, что я жалуюсь (может быть, немного), это заставило меня быть гибким и сосредоточиться на решении проблем. Помимо программирования, мне приходилось делать много «штучек» DevOps на наших серверах и учиться, делая, ломая и исправляя вещи, одновременно поддерживая дюжину приложений и электронных таблиц Excel с макросами.

Самый большой извлеченный урок

Наконец, отвечая на вопрос, который я задал первым: в чем ошибаются как технические, так и нетехнические люди?

Программирование — это всего лишь инструмент для решения проблем. Не больше, не меньше.

Техническая сторона

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

Последний пост я даже говорил об этом!

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

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

Не техническая сторона

С другой стороны, у нас есть люди, которые могут быть технологически безграмотны, которые не знают, что можно или нельзя делать, и которые иногда думают, что все почти волшебно, так что можно просто «перетащить» и готово», так что это легко сделать, не так ли?». (Хотелось бы, чтобы это была просто гипербола.)

Они также слишком сосредотачиваются на своей версии того, чего хотят, а не на реальной проблеме. В конце концов, всем нам нравится иметь новую блестящую игрушку, не так ли? А некоторые в высшем руководстве любят хвастаться, что «они придумали…».

Да, большое количество раскрывающихся списков нормализовало бы данные, избегало грубых человеческих ошибок и сокращало время… но зачем вообще нажимать?

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

Сторона теневого (ИТ) разработчика

Я вижу обе стороны. И лично у меня осталось то, чему я научился в бизнес-школе, и весь опыт программирования.

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

  • Кто отвечает за этот процесс и как он осуществляется в настоящее время?
  • Какие «уловки и советы» они передают новым людям, выполняющим эту работу?
  • Как эта маленькая шестеренка помещается внутри большой машины?
  • Кто должен будет использовать решение?
  • Каков наилучший сценарий с минимальным объемом работы?
  • И какие исключения, которые, возможно, нужно сделать по-другому? Являются ли они даже одним и тем же процессом? (Примечание: иногда может показаться, но на самом деле это разные вещи.)

Одни только эти вопросы дадут вам представление о том, как это могло бы быть в идеальном мире.

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

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

ААД

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

🤷

Фото на обложке David Werbrouck на Unsplash