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

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

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

Имеет ли смысл пытаться контролировать или запрещать разработку приложений, выполняемую за пределами ИТ-отдела (за исключением незначительных вещей, таких как макросы Excel)?

Раньше я работал в компании, где каждое приложение, которое мы им давали, вызывало вопрос: можем ли мы экспортировать эти данные в Excel?

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

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

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

Можно утверждать, что это означало, что мы неправильно расставили приоритеты, что важная работа не была выполнена. Но я бы сказал, что это позволило более высокооплачиваемым разработчикам выполнять более сложную работу. Что это может повредить?

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

Я думаю, что люди упускают общий смысл здесь:

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

Почему эти приложения создаются в первую очередь?

Во всех случаях, которые я видел, есть общая причина:

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

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

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

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

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

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

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

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

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

Разве это не звучит глупо?

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

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

Вы не можете полностью контролировать это ...

Я бы сказал, что вы никогда не сможете ПОЛНОСТЬЮ контролировать его, поскольку у сотрудников всегда будут средства для создания мошеннического кода и распространения его альтернативными способами. Так что не стоит слишком много зацикливаться на этом, если вы разработали и внедрили несколько основных правил и процессов и настроили несколько инструментов.

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

Но вы можете создать дружественную к коду среду

Многие компании, зачастую очень крупные, делают это. Хорошим примером является Google, представители которого заявили, что используют единый SCM для всей компании, чтобы каждый мог отслеживать и просматривать чужой код.

Я бы порекомендовал вам сделать следующее:

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

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

Вы также можете занять более произвольную позицию и решить, что разрешены только языки L и Stack S, но тогда вы получите кое-какие мошеннические вещи, поэтому я бы порекомендовал немного их расширить. Некоторые CI-системы могут творить чудеса с несколькими плагинами, если ваши сотрудники готовы написать немного кода для склеивания или некоторые скрипты конфигурации, чтобы заставить их соответствовать.

Дайте командам свободу

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

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

Поговори с ИТ, вовлеки их

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

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

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

Вы увидите огромное желание интеграции с Excel (или, по крайней мере, импорта / экспорта), потому что все бизнес-школы сейчас преподают Excel, и это основной инструмент, используемый во многих бизнес-курсах.

Сарбейнс-Оксли и аналогичные законы за пределами США в сочетании с законами о конфиденциальности и внутренне самостоятельно устанавливаемыми процессами и политиками конфиденциальности и безопасности являются «молотком», который может и часто используется для подавления явления теневых ИТ.

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

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

Кроме того, возникает проблема, заключающаяся в том, что, когда вы посмотрите на эти усилия, умноженные на сотни (или тысячи) отделов на предприятии из списка Fortune 500, вы вскоре обнаружите, что ваше предприятие имеет более 100 клиентских «основных» баз данных. Ваши клиенты начинают жаловаться на то, что они обновили свои контактные данные в одном месте, но в 10 других они все еще устарели, или что вы даже не знаете, как много вы работаете со своими крупными партнерами, потому что информация распространяется по 10 теням. ИТ базы данных.

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

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

Решение о написании нового приложения часто основывается на анализе затрат и выгод запроса; а также общая ценность для бизнеса. Принимая во внимание многие другие факторы, такие как доступные ИТ-ресурсы, объем запроса, бизнес-цели и направления, это лишь некоторые из них. Часто в конкретном запросе отделов отказывают, потому что менеджер / директор отдела не показывает разумную рентабельность инвестиций или просто не следует установленному процессу.

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

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

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

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

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

Они запрещены в нашей компании по следующим причинам:

• Защищенные паролем Excel макросы, где единственный человек, который знает пароль покинул компанию,
• Нести ответственность за неверные отчеты, написанные неопытными людьми, потому что это ИТ
• Нас попросили изменить отчет, который мы никогда не видели и не слышали раньше.

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

Если есть проблема здесь, это с отделом ИТ.

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

ИТ-отдел должен признать это и поддержать его. Предоставляя повторно используемые интерфейсы, предоставляя данные в удобных форматах, таких как EXCEL или Access DB, и предоставляя гибкие инструменты (COGNOS, Jasper Reports и т. Д.).

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

Разочарование многих компаний или отделов в компаниях состоит в том, что их ИТ-отделы мешают им выполнять свою работу или делать что-то новое. Это приводит к тому, что департаменты, которые чувствуют, что их сдерживают ИТ-политики, пытаются решить свои собственные проблемы. Общение является ключевым. Если отделы работают над ИТ, то у вас действительно есть проблемы с ИТ. ЭТО не может позволить себе быть врагом. Компании, и особенно ИТ-отделы, должны понимать, что им нужно работать вместе, а не друг против друга. Если отделы общаются со своими ИТ-специалистами (особенно теми, кто должен осуществлять надзор) и рассказывают им о своих потребностях и о том, как они работают над решением своих собственных проблем, По крайней мере, у ИТ-специалистов будет возможность помочь решить проблемы, а не узнавать после того, как наступит кризис. Держите это в курсе.

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

Это не означает, что разработка, финансируемая отделом, должна быть свободна. Необходимо соблюдать некоторые требования, такие как следующие:

• Весь код должен регулярно передаваться в систему контроля версий, управляемую ИТ. ИТ должны свободно создавать учетные записи и каталоги, чтобы сделать это возможным. Это может даже хотеть дать некоторую инструкцию.
• Все, что включает в себя PII (личную информацию), аутентификацию, авторизацию, криптографию, данные, защищенные законом, или данные, которые бизнес считает важными, должно включать и быть одобрено консультантом из ИТ. ИТ / консультант должен предоставить помощь, библиотеки и т. Д., Чтобы должным образом защитить бизнес и обеспечить разработку приложений.
• Первичные базы данных должны быть защищены. В зависимости от базы данных доступ для чтения должен быть относительно легким, а доступ для записи - более сложным. ИТ может потребоваться предоставить учетные записи, ведение журнала или аудит.

Включение имеет много преимуществ.

• ИТ узнает больше о том, как удовлетворить потребности своих клиентов. Это приводит к лучшей расстановке приоритетов и обмену.
• Это рассматривается как друг и выгода, а не проблема.
• Реальные деловые потребности удовлетворены.
• Бизнес-данные должным образом защищены, потому что были задействованы ИТ, что исключает необходимость в задних дверях.
• Инструменты Deparment не теряются из-за оборота и могут быть легко перенесены в IT, если это необходимо.

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

Вещи, которые вы можете сделать:

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

• Сделайте так, чтобы все стажеры, связанные с ИТ, работали только через ИТ

• Ограничение через ОС политикой установки программного обеспечения . Каждая установка программного обеспечения должна проходить через службу поддержки ИТ, требуя одобрения руководителя. Таким образом, установка чего-то вроде MS Access, PHP, Visual Basic и т. Д. Будет труднее пройти незамеченной.

• Выпустите политику, утверждающую, что каждая новая разработка, чтобы получить поддержку, должна быть написана, скажем, на Java, C #, C ++ или любом другом языке, который потребовал бы крутой кривой обучения . Таким образом, вы сводите мир людей с «определенными знаниями в программировании» к беспорядкам.

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

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

Но: ни одна вещь, которую вы делаете, не превзойдет по силе телефонный звонок от Большого Шефа , который позвонит ИТ-менеджеру и попросит его поддержать приложение, созданное стажером.

Один из способов, которым моя компания помогает в подобных ситуациях, - не быть независимым от языка. Если вы хотите, чтобы приложение / программа даже рассматривалось, оно должно быть на выбранном нами языке (java). Мы можем немного расширить правила для некоторых JQuery или js, но это должно быть хорошо составленное приложение, которое удовлетворяет критически важную потребность. Не приходите и не говорите: «У меня есть это PHP-приложение, которое мне нужно, чтобы вы разместили для меня», потому что вам, вероятно, просто передадут лист политики.

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

Высокомерие вундеркиндов!

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

Например, компания-разработчик разработала приложение для оптимизации (за плату) доступа к рыночным потокам данных. Позже они предоставили плагин для Excel, чтобы пользователи могли получить доступ к последней цене акций через электронную таблицу. Перенесемся на один год вперед, и почти у каждого трейдера в компании, на которую я работал, была одна или несколько невероятно сложных таблиц для поддержки их торговой стратегии. Время от времени у них возникали проблемы с макросами, и они обращались за помощью к одному из ИТ-специалистов, большинство отказывалось (и им было интересно, почему бизнес нас ненавидит!). Однако у меня был шанс, и хотя я мог исправить технические проблемы с различными параметрами функций и циклическими ссылками, я могу честно сказать, что у меня не было ни малейшего понятия, что на самом деле сделала вся таблица. Не потому, что они были плохо составлены или плохо запрограммированы, а потому, что у меня не было знаний или опыта, чтобы оценить тонкость того, чего пытались достичь трейдеры. Кроме того, я бы оценил проект на 5 человек в год плюс ИТ, чтобы воспроизвести функциональность одной из этих электронных таблиц на «правильном» языке программирования в качестве стандартного ИТ-проекта.