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

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

Тоді є критичний момент: Хто підтримуватиме додаток, додавати нові функції, ...? І ця програма є критичною. Це потрібно. Але стажер покинув компанію. Ніхто не знає, як це працює. У вас є лише купа джерел і якась документація.

Чи має сенс намагатися контролювати чи забороняти розробку додатків, які проводяться поза межами ІТ-відділу (за винятком незначних матеріалів, таких як макроси Excel)?

Раніше я працював у компанії, де кожен додаток, який ми їм надали, призвів до питання: Чи можна експортувати ці дані в Excel?

Через деякий час я вирішив, що мушу знати, чому вони одержимі експортом Excel на все. Виявилося, що у багатьох відділах була одна людина, яка була експертом у програмі Excel та могла за один раз написати корисну програму для аналізу даних. Ці додатки поширюватимуться навколо відділу, як пожежа, і ми, техники, не мали уявлення, що вони навіть існують.

Чому вони не прийшли до нас першими? Оскільки була репутація, що технічній команді було занадто багато чого зробити, і, якщо вони попросять її, вони можуть (якщо пощастить) отримати її в чергу через півроку.

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

Ви можете стверджувати, що це означає, що ми визначали пріоритет неправильно, що важлива робота не була виконана. Але я б заперечував, що це звільнило більш високооплачуваних розробників зробити складнішу роботу. Що може нашкодити?

Тепер я заборонив би програмне забезпечення, яке оновлює написання бази даних поза командою розробників. І я б відмовився підтримувати програми, написані за межами команди розробників. Але я б не намагався заборонити всьому програмному забезпеченню писати самим бізнесом, і я б із задоволенням писав експорт даних, щоб надати їм можливість робити це (поки це не викриває дані, які вони не повинні бачити, очевидно ).

Я думаю, що тут людей не вистачає загальної точки зору:

Якщо вам не подобається вся спеціальна розробка, що відбувається, забороняючи це вирішувати неправильну проблему - натомість слід запитувати, чому вони їдуть навколо ІТ, а не просто говорити їм, що це заборонено. Пам'ятайте, що ви (ІТ) існуєте, щоб допомогти їм краще виконувати свою роботу, і що люди не використовують програмне забезпечення, оскільки воно круте чи акуратне чи нове, вони використовують його, оскільки це вирішує проблему, яку вони мають.

Чому ці додатки створюються в першу чергу?

У всіх випадках, які я бачив, є загальна причина:

Бізнес-групи надають пріоритет власним потребам, вищим, ніж ті самі потреби, пріоритетні у контексті всієї компанії

Маркетинг несе відповідальність лише за маркетинг, тому ініціативи, які приносять користь їхнім цілям, здаються для них критичними, хоча вони вважаються пухкими для інших груп, і, як правило, надають пріоритет нижчим, якщо мова йде про обмежені ресурси, такі як ІТ. Визначення пріоритетів грає лише тоді, коли вони хочуть використовувати спільний ресурс - якщо вони зберігають проект повністю у власному підрозділі, тоді про бюджет і терміни повинен піклуватися лише керівник відділу.

Немає жодних причин, я б забороняв такий розвиток подій, а не через розум - це полегшує обмеження щодо спільних ресурсів (головним чином, ІТ), і дозволяє кожній групі надавати їм можливість вирішувати власні проблеми (оскільки люди, розбираючись у розширеному Excel, досить поширені, оскільки це поширена проблема, у більшості відділів є принаймні один).

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

Але ось що слід пам’ятати: кожен користувацький додаток, розроблений поза межами ІТ, відповідає потребі, яку ІТ не задовольняє . Можливо, є вагома причина, що їх не дотримуються - не пріоритет у компанії, дуже спеціалізована проблема, не так добре, як інші варіанти, спеціальна мова, яку ваші ІТ-люди не знають тощо, - і відсутність залучення до ІТ може бути законні, але ці рішення були створені тому, що в департаменті була потреба, яку ІТ не міг (або не хотів) задовольнити.

Спробуйте допомогти їм вирішити свої проблеми, і якщо у вас немає часу або ресурсів, дозвольте їм вирішити їх самостійно. Обмеження якоїсь мови, що має круту криву навчання, єдина мета - утримати людей від вашого бізнесу, служить лише для посилення елітарного ставлення більшості бізнес-користувачів, які сприймають ІТ, і врешті-решт, таке елітарне ставлення призводить лише до Більш того ж проблема, оскільки користувачі побоюються наблизитись до ІТ та впевнені, що ІТ не розуміє їх потреб чи бажань. Відкрийте стосунки - розуміння того, що їм потрібно, - це єдиний спосіб уберегти їх від вас.

Слід також розглянути випадок компаній, в яких ІТ-відділ містить некомпетентних людей, тоді як прихований додаток буде створений вмілим розробником, який має роботу не розробника в компанії. На мій досвід, такі випадки є надзвичайно частими.

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

Ви проводите кілька вечорів, щоб написати додаток, яке зробить всю роботу. Ви показуєте його на особистому ноутбуці колегам, і вони вважають це дуже корисним. Ви хочете встановити його на ПК компанії, але вам слід мати згоду відділу ІТ. Ви просите його, але вони відхиляють його, оскільки вони не підтримують вашу заявку.

Це не звучить нерозумно?

Окрім цього конкретного випадку, проблема з підтримкою не сильно відрізняється від багатьох компаній, які стикаються з усім  програмним забезпеченням, навіть тим, що написано в ІТ-відділі: якщо ІТ-відділ не застосовує кращих практик, код буде погано / не задокументований, написані недосвідченими людьми, які не піклуються про технічне обслуговування та які пішли років тому.

На закінчення головне питання - це рентабельність . Якщо вас, відділ інформаційних технологій, попросять підтримувати додаток, розроблений канцеляристом, який не розуміє найосновніших правил розробки програмного забезпечення, неважливо, наскільки це приємне це завдання, ви все одно повинні це робити, якщо це приносить багато грошей компанії . Або ви переписуєте це з нуля, якщо це найдешевший спосіб зробити справи.

Ви не можете повністю контролювати це ...

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

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

Але ви можете створити зручне для коду середовище

Багато компаній, часто дуже великих, роблять це. Хороший приклад - Google, представники якого заявили, що використовують єдиний SCM для всієї компанії, щоб кожен міг відстежувати та переглядати код інших.

Я рекомендую вам зробити наступне:

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

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

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

Дайте командам трохи свободи

Важливо дати командам трохи свободи йти на примхи та починати невеликі нові проекти з експериментальних речей. Це тримає їх на ногах, і ви так само, як і змушує вас розглядати ці технології, а не залишатися в стопі назавжди, поки це не спричинить для вас проблем.

Тому переконайтеся, що вони мають можливість встановлювати власні системи для тестування своїх домашніх проектів. Але переконайтеся, що вони звикли спілкуватися з ІТ про це.

Поговоріть з ІТ, залучіть їх

Набагато краще, якщо ваші співробітники розвинуть рефлекс зйомки запиту електронної пошти на ІТ та запитають, чи зможуть вони щось налаштувати для них та вмістити. Вони будуть відхилятися більшу частину часу, але, принаймні, є поняття контролю та того, хто повинен бути відповідальним, і надає ІТ певну видимість на вимоги різних команд.

Як тільки проекти наберуть більш критичну масу, ви можете подати запит ще раз, і вони переглянуть. Комунікація є ключовою, і вам потрібно мати спільну команду розробників, консультантів, службу ІТ-підтримки або будь-кого, хто займається кодом. Ніхто з них не хоче бродячих програм, тому це в усіх інтересах. Набагато простіше застосовувати правила, якщо вони самі створюють резервні копії.

Ви не можете зупинити ці "приховані" програми, оскільки люди змушують їх вирішувати бізнес-проблеми. Все, що ви можете зробити, це допомогти їм зробити це "правильним" способом. І під "правильним" я маю на увазі зробити так, щоб додатки могли підтримуватися після того, як людина, яка їх запускає, пішла. Я рекомендую використовувати мову, запропоновану в розділі " Вгору" або "Вихід" : Мені потрібно, щоб ви детально задокументували цей процес, щоб будь-який Yahoo міг зрозуміти це через рік з моменту виходу. Допоможіть налаштувати контроль версій (і показати їм, як ним користуватися), вікі (для зберігання неформальних приміток про те, як працює насправді) та просту систему відстеження помилок. Якщо ви хочете зробити речі справді гладкими, налаштуйте постійну інтеграцію на запасному сервері (якщо у вас є).

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

Сарбанес-Окслі та подібне законодавство за межами США, в поєднанні із законами про конфіденційність та внутрішніми процесами та політикою конфіденційності, пов'язаними з конфіденційністю та безпекою, - це "молоток", який може і часто використовується для стримування явища тіньових ІТ.

Як тільки інформація про клієнта або службовця (або будь-які дані, які ви не бажаєте отримувати) почне розповсюджуватись у цих електронних таблицях, у вас трапиться ДТП.

Так само, як тільки один із цих ІТ-проектів скунктури візьме цю електронну таблицю Excel і використає її як дані за зовнішньою веб-програмою, яка зламається, ви отримаєте, щоб ваш CIO та генеральний директор увійшли в офіс того, хто створив цю програму в вихідні, що приходять пояснити наслідки.

І тоді виникає проблема, коли, дивлячись на ці зусилля, помножені на сотні (або тисячі) відділів на підприємстві Fortune 500, ви незабаром виявите, що ваше підприємство має понад 100 клієнтських "майстерних" баз даних. Ваші клієнти починають скаржитися на те, що вони оновили свою контактну інформацію в одному місці, але вона ще застаріла в 10 інших, або що ви навіть не знаєте, який бізнес ви робите зі своїми великими партнерами, оскільки інформація поширюється через 10 тіней. ІТ-бази даних.

Все це породжує важкі процеси дотримання та аудиту, які нікому не цікаві, але є важкими фактами життя ІТ у підприємницькому середовищі.

Гарною стратегією є перегляд усіх департаментів, які займаються цим, і зробити справу, щоб перекласти свої інвестиції в тіньові ІТ в належні ІТ, зробивши аргумент, що ІТ може досягти економії масштабу і зробити цю роботу ефективніше, ніж нинішня спеціальна модель розподілених скунсерів. Це може бути важким продажем в умовах, коли обмеження в ІТ-бюджеті та швидкість доставки спричинили в першу чергу скункс-роботи, але в поєднанні з аудиторськими / довірчими ризиками можуть зробити хороший удар-два.

Рішення написати нову заявку часто ґрунтується на аналізі запиту на користь вигоди; а також загальну цінність для бізнесу. Все, беручи до уваги багато інших драйверів, таких як доступні ІТ-ресурси, обсяг запиту, бізнес-цілі та напрямок, лише декілька. Часто в конкретному запиті департаменту відмовляють, оскільки менеджер / директор департаменту не виявив розумної рентабельності інвестицій або просто не дотримується встановленого процесу.

Незалежно від причини, "ІТ-відділ" часто є козлом відпущення, навіть якщо рішення було поза їх контролем. Таким чином, навіть якщо відмова в запиті може не погано відображатися на ІТ-відділі, його сприйняття часто зовсім інше.

Незважаючи на це, ви знайдете шахрайські програми майже в кожній бізнес-організації в світі. Деякі добре написані та інші, що добре, містять код, який ніколи не повинен побачити світло дня.

Хоча ми повинні робити все, що можемо, щоб задовольнити внутрішні потреби клієнтів, буває, що ми просто не можемо. Коли це станеться, вони будуть шукати в іншому місці, щоб вирішити свою проблему.

Якщо ІТ-група бере активну участь у проекті, то ми можемо вимагати дотримання наших стандартів, допомогти консультанту дотримуватися внутрішніх правил кодування, зрозуміти взаємодію програм та вимоги до наших систем (база даних, мережа, брандмауер,…). Без цієї участі нас не вистачить і витратим багато часу, намагаючись з'ясувати, чому наші виробничі системи не відповідають умовам угоди.

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

Вони заборонені в нашій компанії з таких причин:

• Excel Macros, захищений паролем, коли єдиний, хто знає пароль, покинув компанію,
• Нести відповідальність за неправильні звіти, написані недосвідченими людьми, оскільки це ІТ "
• Попросили змінити звіт, про який ми ніколи не бачили і не чули.

Я розумію, що це може бути неприємно для користувачів, коли ІТ зайняті, і вони можуть схильні до «просто зробити це самі». Але ІТ не може нести відповідальність за речі, про які він навіть не знає, і якщо ніхто не несе відповідальності за загальний ІТ, то попереду великі проблеми.

Якщо тут є проблема, це з відділом ІТ.

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

ІТ-відділу потрібно це визнати і підтримати. Забезпечуючи інтерфейси для повторного використання, передачу даних у зручних форматах, таких як EXCEL або Access DB, та надання гнучких інструментів (COGNOS, Jasper Reports тощо).

ІТ-відділу також потрібно переглянути свої пріоритети - саме він може служити бізнесу, а не застосовувати новітні методики або встановлювати найсексуальніші апаратури.

Розчарування багатьох компаній або відділів компаній полягає в тому, що їх ІТ-підрозділи перешкоджають роботі і ускладнюють роботу над ними або роблять нові речі. Це змушує департаменти, які відчувають, ніби їх стримує ІТ-політика, намагатися вирішити власні проблеми. Комунікація є ключовою. Якщо відділи працюють навколо ІТ, то у вас насправді є проблема ІТ. ІТ не може дозволити собі сприйматись як ворога. Компанії, і особливо відділи ІТ, повинні усвідомити, що їм потрібно працювати разом, а не один проти одного. Якщо відділи спілкуються зі своїм ІТ-персоналом (особливо тими, хто повинен мати нагляд) і розповідають їм про свої потреби та про те, як вони працюють над вирішенням власних проблем, Принаймні, ІТ матиме можливість допомагати вирішувати проблеми, а не з'ясовувати їх після того, як настане криза. Зберігайте ІТ в циклі.

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

Це не означає, що розвиток, який фінансується департаментом, повинен надавати безкоштовне управління. Слід виконувати деякі вимоги, такі як:

• Весь код повинен регулярно встановлюватися в системі управління версіями, керованою ІТ. ІТ повинні вільно створювати акаунти та каталоги, щоб зробити це можливим. ІТ може навіть захотіти дати якусь інструкцію.
• Все, що включає PII (особисту інформацію), автентифікацію, авторизацію, криптографію, захищені законом дані або дані, які бізнес вважає критичними, має включати та затверджувати консультантом із ІТ. ІТ / консультант повинен надати допомогу, бібліотеки тощо, щоб належним чином захистити бізнес, одночасно сприяючи розробці додатків.
• Первинні бази даних повинні бути захищені. Залежно від бази даних, доступ до читання повинен бути порівняно легким для отримання доступу та запису. ІТ може знадобитися забезпечити облікові записи, ведення журналів або аудит.

Увімкнення має багато переваг.

• ІТ дізнається більше про задоволення потреб своїх клієнтів. Це призводить до кращого визначення пріоритетності та спільного використання.
• ІТ сприймається як друг і користь, а не проблема.
• Реальні потреби бізнесу задовольняються.
• Дані про бізнес є належним чином захищені, оскільки задіяні ІТ, що запобігає необхідності використання задніх дверей.
• Інструменти департаменту не втрачаються завдяки обороту і, за потреби, їх легше перенести в ІТ.

Я не міг не познайомитися з тобою. Проблема, яку ви описуєте, здається універсальною, охоплює культури, мови та континенти.

Те, що ви можете зробити:

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

• Зробіть так, щоб усі практикуючі професії, пов'язані з ІТ, були укладені лише через ІТ .

• Обмеження за допомогою політики ОС встановлення програмного забезпечення . Кожна установка програмного забезпечення повинна бути спрямована через службу технічної підтримки ІТ, вимагаючи схвалення керівника. Таким чином, встановлення чогось типу MS Access, PHP, Visual Basic тощо, буде складніше пройти непомітно.

• Випустіть політику, в якій зазначається, що кожна нова розробка, щоб отримати підтримку, повинна бути написана на, скажімо, Java, C #, C ++ , або будь-якій іншій мові, яка потребує крутої кривої навчання . Таким чином ви зменшуєте всесвіт людей з "певними знаннями програмування", щоб возитися.

• Ці вимоги люди повинні дивитися на «вирішенні Excel» навколо компанії, тому що це відображає ІТ - потреби корпорації.

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

Але: жодна річ, яку ви робите, не виграє телефонний дзвінок від Великого начальника , зателефонувавши ІТ-менеджеру і попросивши його підтримати додаток, який зробив стажист.

Один із способів, яким моя компанія допомагає в таких ситуаціях, - це не бути мовними агностиками. Якщо ви хочете, щоб програма / програма навіть розглядалася, вона повинна бути мовою, яку ми обираємо (Java). Ми можемо трохи розтягнути правила для деяких JQuery або js, але це повинно бути добре складеним додатком, яке задовольнило критичну потребу. Не приходьте і не кажіть: "У мене є ця програма PHP, що мені потрібно, щоб ви розмістили для мене", тому що вам, ймовірно, просто вручать лист з полісами.

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

Нахабність Гіків!

У багатьох випадках ділові користувачі можуть використовувати інструменти, щоб робити речі, які ІТ-люди не розуміють. Це не тому, що їм по суті погано, а тому, що вони знають бізнес, як він працює і як вони хотіли б, щоб він працював.

Наприклад, програмна компанія розробила додаток для оптимізації (за вартістю) доступу до каналів даних ринку. Згодом вони надали плагін Excel, щоб користувачі могли отримати доступ до останньої ціни акцій через електронну таблицю. Швидкий вперед один рік, і майже кожен трейдер в компанії, в якій я працював, мав одну або кілька неймовірно складних електронних таблиць для підтримки своєї торгової стратегії. Раз у раз у них виникнуть проблеми з макрокомандами, і просять когось із ІТ-хлопців про допомогу, більшість відмовились (і вони задаються питанням, чому бізнес ненавидить нас!). Однак у мене були проблеми, і, хоча я міг виправити технічні проблеми з різними параметрами функції та циркулярними посиланнями, я, чесно можу сказати, не мав найменшого поняття, що насправді робила вся електронна таблиця. Не тому, що вони були погано складені або погано запрограмовані, а тому, що я не мав знань чи досвіду, щоб оцінити тонкість того, що намагалися досягти торговці. Крім того, я вважаю, що 5-ти чоловічий рік плюс ІТ-проект для тиражування функціональності однієї з цих електронних таблиць "правильною" мовою програмування як стандартний ІТ-проект.