Las empresas más grandes generalmente tienen el problema de que no es posible escribir todos los programas que los empleados desean (para ahorrar tiempo y optimizar los procesos) debido a la falta de personal y dinero.

Luego, algunas personas que tengan (al menos alguna) experiencia en codificación crearán programas ocultos (o estudiantes / pasantes baratos ...). En algunas circunstancias, estas aplicaciones cobrarán importancia y se extenderán de un usuario a todo un departamento.

Luego está el punto crítico: ¿Quién mantendrá la aplicación, agregará nuevas características, ...? Y esta aplicación es crítica. Es necesario. Pero el interno ha dejado la compañía. Nadie sabe cómo funciona. Solo tiene un montón de fuentes y algún tipo de documentación.

¿Tiene sentido intentar controlar o prohibir el desarrollo de aplicaciones hechas ad-hoc fuera del departamento de TI (con la excepción de cosas menores como las macros de Excel)?

Solía ​​trabajar para una empresa donde cada aplicación que les dimos nos llevó a la pregunta: ¿podemos exportar estos datos a Excel?

Después de un tiempo, decidí que tenía que saber por qué estaban obsesionados con las exportaciones de Excel para todo. Resultó que muchos departamentos tenían una persona que era experta en Excel y que podía escribir una aplicación de análisis de datos útil en poco tiempo. Estas aplicaciones se extenderían por todo el departamento como incendios forestales y nosotros, los técnicos, no teníamos ni idea de que existían.

¿Por qué no vinieron a nosotros primero? Debido a que había una reputación de que el equipo técnico tenía demasiado que hacer y, si lo solicitaban, podrían (si tenían suerte) hacer que se pusieran en cola seis meses después.

Esa no fue una acusación injusta y nunca nos pidieron que admitiéramos sus aplicaciones de Excel, por lo que nadie realmente pensó que era un problema. Cuando estos desarrolladores de Excel se fueron, siempre lograron encontrar a alguien más para recogerlo.

Se podría argumentar que significaba que estábamos priorizando incorrectamente, que no se estaba haciendo un trabajo importante. Pero diría que liberó a los desarrolladores mejor pagados para hacer un trabajo más difícil. ¿Qué puede doler?

Ahora , prohibiría el software que actualiza la base de datos que se escribe fuera del equipo de desarrollo. Y me negaría a admitir aplicaciones escritas fuera del equipo de desarrollo. Pero no trataría de prohibir que todo el software fuera escrito por la propia empresa, y con gusto escribiría exportaciones de datos para permitirles hacerlo (siempre y cuando eso no exponga datos que no deberían ver, obviamente )

Creo que a la gente le falta el punto general aquí:

Si no le gusta todo el desarrollo personalizado que está sucediendo, prohibir que resuelva el problema incorrecto; en su lugar, debe preguntarse por qué están pasando por TI, no solo decirles que no está permitido. Recuerde que usted (TI) existe para ayudarlos a hacer mejor su trabajo, y que las personas no usan el software porque es genial, ordenado o nuevo, lo usan porque resuelve un problema que tienen.

¿Por qué se crean estas aplicaciones en primer lugar?

En todos los casos que he visto, hay una razón común:

Los grupos empresariales priorizan sus propias necesidades por encima de las mismas necesidades en el contexto de toda la empresa.

El marketing solo es responsable del marketing, por lo que las iniciativas que benefician sus objetivos les parecen críticas, mientras se consideran esponjosas para otros grupos, y tienden a tener una prioridad más baja cuando se trata de recursos limitados como TI. La priorización solo entra en juego cuando desean usar un recurso compartido: si mantienen el proyecto completamente dentro de su propio departamento, solo el jefe del departamento debe preocuparse por el presupuesto y el cronograma.

No hay razón para que prohíba este tipo de desarrollo, dentro de lo razonable: alivia las restricciones sobre los recursos compartidos (principalmente TI) y permite que cada grupo se capacite para resolver sus propios problemas (ya que las personas con conocimientos en Excel avanzado son bastante comunes, Dado que este es un problema común, la mayoría de los departamentos tienen al menos uno).

Sin embargo, no se puede esperar que resuelva ningún problema que surja de estas aplicaciones o que las respalde después de que el desarrollador original abandone la empresa. Como se menciona en otra publicación, esto no impide que el gran jefe le exija que lo apoye, pero si se mantiene atento a los tipos de aplicaciones o procesos personalizados, puede sentir cuándo algo se vuelve crítico y usted podría necesitar involucrarse para llevarlo "internamente". Además, si algo se conecta y modifica sistemas que están bajo el control de TI, entonces TI debe participar, aunque solo sea para garantizar la seguridad e integridad de sus sistemas centrales; sin embargo, si es algo limitado al escritorio de un usuario, ¿por qué sentir la necesidad? para prohibirlo?

Pero aquí hay algo para recordar: cada aplicación personalizada que se ha desarrollado fuera de TI corresponde a una necesidad que TI no satisface . Puede haber una buena razón por la que no se cumplen: no es una prioridad en la empresa, un problema muy especializado, no es tan bueno como otras opciones, un lenguaje personalizado que su personal de TI no conoce, etc., y la falta de participación de TI puede ser legítimo, pero estas soluciones se crearon porque algunos departamentos tenían una necesidad que TI no podía (o no quería) satisfacer.

Intente ayudarlos a resolver sus problemas, y si no tiene el tiempo o los recursos, déjelos resolverlos por su cuenta. Exigir un lenguaje que tenga una curva de aprendizaje empinada, con el único propósito de mantener a las personas fuera de su negocio, solo sirve para mejorar la actitud elitista que la mayoría de los usuarios comerciales perciben que TI tiene, y al final, ese tipo de actitud de élite solo conduce a Más del mismo problema, ya que los usuarios tienen miedo de acercarse a TI y están convencidos de que TI no entiende sus necesidades o deseos. Abra la relación: comprender lo que necesitan es la única forma de evitar que lo rodeen.

También se debe considerar el caso de las empresas en las que el departamento de TI contiene personas incompetentes, mientras que la aplicación oculta sería creada por un desarrollador hábil que tiene un trabajo no desarrollador dentro de la empresa. En mi experiencia, esos casos son extremadamente frecuentes.

Imagine que tiene un doble perfil de desarrollador de software y contador. Te contratan como contador porque esta era una oportunidad para que obtengas un trabajo bien remunerado. Rápidamente ve que sus colegas (y ahora usted) pasan horas haciendo cosas repetitivas que un programa puede hacer en unos segundos.

Pasas algunas tardes para escribir la aplicación que hará todo el trabajo. Lo muestra en su computadora portátil personal a sus colegas, y ellos lo encuentran muy útil. Desea instalarlo en las PC de la empresa, pero debe contar con el acuerdo del departamento de TI. Usted lo solicita, pero lo rechazan porque no admitirían su aplicación.

¿No suena estúpido?

Aparte de este caso particular, el problema con el soporte no es muy diferente del que muchas empresas encuentran con todo  el software, incluso uno escrito dentro del departamento de TI: si el departamento de TI no aplica las mejores prácticas, el código estará mal / no documentado, escrito por personas sin experiencia que no se preocupan por el mantenimiento y que se fueron hace años.

Para concluir, la pregunta principal es la rentabilidad . Si a usted, el departamento de TI, se le pide que mantenga una aplicación desarrollada por un empleado que no comprende las reglas más básicas del desarrollo de software, no importa cuán agradable sea esta tarea, aún debe hacerlo si trae una gran cantidad de dinero a la empresa . O lo reescribe desde cero si es la forma más económica de hacer las cosas.

No puedes controlarlo completamente ...

Yo diría que nunca se puede controlar TOTALMENTE, ya que los empleados siempre tendrán medios para producir código falso y difundirlo por medios alternativos. Por lo tanto, no sirve de nada obsesionarse demasiado con él, una vez que ha redactado y aplicado algunas reglas y procesos básicos, y ha configurado algunas herramientas.

La idea es que sea lo más atractivo posible para las personas respetar estas reglas y usar estas herramientas, en lugar de hacer que sea tan imposible hacer cosas nuevas que no produzcan nada.

Pero puedes crear un entorno amigable con el código

Muchas empresas, a menudo muy grandes, hacen esto. Un buen ejemplo es Google, para el cual los representantes han dicho que usan un solo SCM para toda la compañía, para que todos puedan monitorear y mirar el código de otros.

Te recomiendo que hagas lo siguiente:

• dar acceso público a algunas áreas de su SCM,
• facilitan la solicitud de acceso a la integración continua y a los servidores de inspección continua,
• alentar a las personas a crear trabajos de construcción para sus herramientas.

El problema es entonces la proliferación de tecnologías. Obviamente, algunos preferirán usar X sobre Y y es entonces cuando se hace más difícil que encajen dentro de su arquitectura. Sin embargo, no es imposible, y si quieren que se mantenga su código, probablemente obtendrán una milla extra si, bueno, es solo una milla.

También podría adoptar una postura más arbitraria y decidir que solo se permiten el lenguaje L y la Pila S, pero luego obtendrá algunas cosas rebeldes aquí y allá, por lo que le recomendaría ampliarlo un poco. Algunos sistemas de CI harán maravillas con algunos complementos, si sus empleados están dispuestos a escribir un poco de código de pegamento o algunos scripts de configuración para que encajen.

Dar a los equipos algo de libertad

Es importante dar a los equipos algo de libertad para ir por capricho y comenzar algunos pequeños proyectos nuevos con cosas experimentales. Los mantiene alerta y usted, al igual que lo obliga a considerar estas tecnologías, en lugar de quedarse atrapado en una pila para siempre hasta que le cause problemas.

Así que asegúrese de que tengan la capacidad de instalar sus propios sistemas para probar sus proyectos favoritos. Pero asegúrese de que se acostumbren a hablar con TI al respecto.

Habla con TI, haz que participen

Es mucho mejor si sus empleados desarrollan el reflejo de enviar una solicitud por correo electrónico a TI y les preguntan si pueden configurar algo para ellos y adaptarse. Serán rechazados la mayor parte del tiempo, pero al menos hay una noción de control y de quién debería estar a cargo y le da a TI cierta visibilidad sobre las demandas de los diferentes equipos.

Una vez que los proyectos recogen una masa más crítica, puede solicitar nuevamente y lo reconsiderarán. La comunicación es clave, y debe tener sus equipos de desarrolladores, consultores, personal de soporte de TI o cualquier persona que trabaje con código para trabajar juntos. Ninguno de ellos quiere programas extraviados, por lo que es lo mejor para todos. Es mucho más fácil hacer cumplir las reglas si las respaldan ellos mismos.

No puede detener estas aplicaciones "ocultas" porque las personas las hacen para resolver problemas comerciales del mundo real. Todo lo que puede hacer es ayudarlos a hacerlo de la manera "correcta". Y por "correcto" me refiero a hacer que las aplicaciones se puedan mantener después de que la persona que las inicia se haya ido. Recomiendo usar el lenguaje sugerido en Up o Out : necesito que documente este proceso en detalle para que cualquier Yahoo pueda entenderlo dentro de un año a partir de su partida. Ayuda para configurar el control de versiones (y mostrarles cómo usarlo), un wiki (para mantener notas informales sobre cómo se hace realmente el trabajo) y un sistema simple de seguimiento de errores. Si desea hacer las cosas realmente ingeniosas, configure la integración continua en un servidor de repuesto (si tiene uno).

Verá el gran deseo de la integración de Excel (o al menos importar / exportar) porque todas las escuelas de negocios ahora enseñan Excel y es una herramienta importante utilizada en muchos cursos de negocios.

Sarbanes-Oxley y una legislación similar fuera de los EE. UU., Combinada con leyes de privacidad y políticas y procesos de privacidad y seguridad autoimpuestos internamente, son el "martillo" que puede y a menudo se utiliza para reprimir el fenómeno de las TI en la sombra.

Tan pronto como la información de identificación personal del cliente o empleado (o cualquier dato que no desee obtener) comience a circular en estas hojas de cálculo, tiene un accidente a la espera de que suceda.

Del mismo modo, tan pronto como uno de estos proyectos de TI de skunkworks tome esa hoja de cálculo de Excel y la use como los datos detrás de una aplicación web externa que está pirateada, tendrás a tu CIO y CEO irrumpiendo en la oficina de quien haya creado esa aplicación en Un fin de semana viene a explicar las consecuencias.

Y luego está el problema de que cuando observa estos esfuerzos multiplicados en los cientos (o miles) de departamentos en una empresa Fortune 500, pronto descubre que su empresa tiene más de 100 bases de datos "maestras" de clientes. Sus clientes comienzan a quejarse de que actualizaron su información de contacto en un lugar, pero todavía está desactualizada en otros 10, o de que ni siquiera sabe cuánto negocio hace con sus socios importantes porque la información se extiende a través de 10 shadow Bases de datos de TI.

Todo esto da lugar a procesos onerosos de cumplimiento y auditoría que no son divertidos para nadie, pero son los hechos concretos de la vida de TI en un entorno empresarial.

Una buena estrategia es analizar todos los departamentos que lo están haciendo y defender su inversión en TI paralela a TI adecuada, argumentando que TI puede lograr una economía de escala y hacer que esto funcione de manera más eficiente que la actual. modelo de skunkworks distribuido ad-hoc. Esto puede ser una venta difícil en un entorno donde las limitaciones de presupuesto de TI y la velocidad de entrega dieron lugar a los trabajos de skunkworks en primer lugar, pero combinados con los riesgos de auditoría / fiduciarios pueden ser un buen golpe de uno o dos.

La decisión de escribir una nueva solicitud a menudo se basa en un análisis de costo beneficio de la solicitud; así como el valor general para el negocio. Todo esto teniendo en cuenta muchos otros factores, como los recursos de TI disponibles, el alcance de la solicitud, los objetivos comerciales y la dirección, por nombrar algunos. Muchas veces se rechaza una solicitud de departamento específica porque el gerente / director del departamento no ha podido mostrar un ROI razonable o simplemente no sigue el proceso establecido.

Independientemente de la razón, el "Departamento de TI" es a menudo el chivo expiatorio, incluso si la decisión estaba fuera de su control. Por lo tanto, aunque la denegación de la solicitud no se refleje mal en el departamento de TI, la percepción a menudo es completamente diferente.

A pesar de esto, encontrará aplicaciones deshonestas en casi todas las organizaciones empresariales del mundo. Algunos bien escritos y otros bien, contienen código que nunca debería haber visto la luz del día.

Si bien debemos hacer todo lo que podamos razonablemente para satisfacer las necesidades de nuestros clientes internos, hay momentos en los que simplemente no podemos. Cuando eso suceda, buscarán otro lugar para abordar su problema.

Si el grupo de TI participa activamente en el proyecto, podemos exigir el cumplimiento de nuestros estándares, ayudar al consultor a seguir las pautas de codificación interna y comprender las interacciones y demandas de las aplicaciones con nuestros sistemas (base de datos, red, firewall, ...). Sin esa participación, nos quedaremos cortos y pasaremos una gran cantidad de tiempo tratando de descubrir por qué nuestros sistemas de producción no cumplen con los SLA.

Ya sea que el departamento de TI los apruebe y los apoye o no, pueden y tendrán un impacto directo en términos de soporte, compromisos de OLA y SLA que cualquier departamento de TI mide.

Están prohibidos en nuestra empresa por estos motivos:

• Macros Excel protegidas con contraseña donde la única persona que conoce la contraseña ha abandonado la empresa,
• Ser responsabilizado por informes incorrectos escritos por personas sin experiencia porque es TI '
• Se le pide que modifique un informe que nunca hemos visto o escuchado antes.

Entiendo que puede ser frustrante para los usuarios cuando TI está ocupado, y pueden estar inclinados a "hacerlo ellos mismos". Pero TI no se hace responsable de las cosas que no sabe, incluso si existen, y si nadie es responsable de TI en general, entonces hay grandes problemas por delante.

Si hay un problema aquí, es con el departamento de TI.

No hay nada de malo en permitir que las personas con conocimiento especializado en negocios / dominios manipulen y procesen sus propios datos.

El departamento de TI debe reconocer esto y respaldarlo. Al proporcionar interfaces reutilizables, entregar datos en formatos convenientes como EXCEL o Access DB, y proporcionar herramientas flexibles (COGNOS, Jasper Reports, etc.).

El departamento de TI también necesita repensar sus prioridades: está allí para servir a la empresa, no para implementar la última metodología o instalar el hardware más atractivo.

Una frustración que sienten muchas empresas, o departamentos de empresas, es que sus departamentos de TI se interponen en el camino y les dificultan hacer su trabajo o hacer cosas nuevas. Esto lleva a los departamentos, que sienten que están siendo retenidos por las políticas de TI, a intentar resolver sus propios problemas. La comunicación es clave. Si los departamentos están trabajando en TI, lo que realmente tiene es un problema de TI. No puede permitirse ser visto como el enemigo. Las empresas, y especialmente los departamentos de TI, deben darse cuenta de que necesitan trabajar juntos en lugar de enfrentarse entre sí. Si los departamentos se comunican con su personal de TI (especialmente aquellos que deberían tener supervisión) y les dicen sus necesidades y cómo están trabajando para resolver sus propios problemas, Al menos, TI tendrá la opción de ayudar a resolver problemas en lugar de averiguar después de que ocurra una crisis. Mantenerlo al tanto.

Casi siempre existe una necesidad válida de estas herramientas especiales, ya sean aplicaciones u hojas de cálculo. Un departamento de TI tiene dos opciones. Pueden ser habilitadores o deshabilitantes. En mi experiencia, los discapacitados pierden porque se interponen en el camino de las necesidades comerciales válidas y se convierten en un enemigo común. Los habilitadores, por otro lado, realmente ayudan a un negocio.

Esto no significa que el desarrollo financiado por el departamento deba tener un reinado gratuito. Se deben cumplir algunos requisitos, como los siguientes:

• Todo el código debe estar regularmente comprometido con un sistema de control de versiones ejecutado por TI. TI debería crear libremente cuentas y directorios para que esto sea posible. Incluso puede querer proporcionar alguna instrucción.
• Cualquier cosa que involucre PII (información de identificación personal), autenticación, autorización, criptografía, datos protegidos por ley o datos que la empresa considere críticos debe involucrar y ser aprobado por un consultor de TI. El consultor de TI / debe proporcionar asistencia, bibliotecas, etc. para proteger adecuadamente el negocio al tiempo que permite el desarrollo de aplicaciones.
• Las bases de datos primarias deben estar protegidas. Dependiendo de la base de datos, el acceso de lectura debería ser relativamente fácil de obtener y el acceso de escritura más difícil. Es posible que TI deba proporcionar cuentas, registros o auditorías.

La habilitación tiene muchos beneficios.

• TI aprende más sobre cómo satisfacer las necesidades de sus clientes. Esto lleva a una mejor priorización y a compartir.
• Se ve como un amigo y un beneficio, en lugar de un problema.
• Se satisfacen las necesidades comerciales reales.
• Los datos comerciales están adecuadamente protegidos porque TI estaba involucrado, evitando la necesidad de puertas traseras.
• Las herramientas de departamento no se pierden debido a la rotación y pueden trasladarse más fácilmente a TI, si es necesario.

No pude evitar identificarme contigo. El problema que describe parece ser universal, abarcando culturas, idiomas y continentes.

Las cosas que puedes hacer:

• Restrinja la creación de cuentas de bases de datos , solicitando la aprobación de un supervisor. Obligarlos a usar una máquina local como servidor de base de datos o escribir las aplicaciones para que sean independientes, disminuye en gran medida su utilidad.

• Haga que todos los pasantes de carreras relacionadas con TI se contraten solo a través de TI .

• Restringir a través de la política del sistema operativo la instalación de software . Toda instalación de software debe canalizarse a través de la mesa de ayuda de TI, lo que requiere la aprobación de un supervisor. De esa manera, la instalación de algo como MS Access, PHP, Visual Basic, etc., será más difícil de pasar desapercibida.

• Emitir una política que indique que cada nuevo desarrollo, para recibir soporte, debe estar escrito, por ejemplo , Java, C #, C ++ o cualquier otro lenguaje que requiera una curva de aprendizaje pronunciada . De esa manera, reduce el universo de personas con "un cierto conocimiento de programación" para perder el tiempo.

• Los requisitos que las personas deben tener en cuenta son las "soluciones de Excel" en la empresa, ya que eso refleja las necesidades de TI de la empresa.

• Implementación de un almacén de datos y una herramienta de informes y minería de datos amigable para el usuario final . De esta forma, reduce la necesidad de pequeñas aplicaciones personalizadas escritas en prácticas.

Pero: ni una sola cosa que haga superará una llamada telefónica de un Gran Jefe , llamando al Gerente de TI y pidiéndole que apoye la aplicación que realizó un interno.

Una forma en que mi empresa ayuda en este tipo de situaciones es no ser independiente del lenguaje. Si desea que se considere una aplicación / programa, debe estar en un idioma de nuestra elección (java). Podemos estirar un poco las reglas para algunos JQuery o js, ​​pero necesitaría ser una aplicación bien compuesta que satisfaga una necesidad crítica. No venga y diga "Tengo esta aplicación PHP que necesito que me aloje" porque probablemente solo le entreguen una hoja de políticas.

Es importante cortar las cosas antes de que sean demasiado grandes, porque una vez que estén, es mejor tener a alguien a quien pueda dedicar a aprenderlo o reescribirlo. Porque una vez que esa gran peluca de arriba decida que le gusta, es probable que nunca la elimines en mi experiencia.

¡La arrogancia de los geeks!

En muchos casos, los usuarios comerciales pueden usar las herramientas para hacer cosas que las personas de TI no entienden. Esto no es porque sean intrínsecamente malos, sino porque conocen el negocio, cómo funciona y cómo les gustaría que funcionara.

Por ejemplo, una compañía de software desarrolló una aplicación para optimizar (por costo) el acceso a las fuentes de datos del mercado. En el último momento, proporcionaron un complemento de Excel para que los usuarios pudieran acceder al último precio de la acción a través de una hoja de cálculo. Avance rápido un año y casi todos los operadores de la compañía para la que trabajé tenían una o más hojas de cálculo increíblemente complejas para respaldar su estrategia comercial. De vez en cuando tendrían un problema con las macros y pedirían ayuda a uno de los chicos de TI, la mayoría se negó (¡y se preguntan por qué el negocio nos odia!). Sin embargo, tuve una oportunidad y, aunque pude solucionar problemas técnicos con varios parámetros de función y referencias circulares, puedo decir honestamente que no tenía la menor idea de lo que realmente hacía toda la hoja de cálculo. No porque estuvieran mal organizados o mal programados, sino porque no tenía el conocimiento o la experiencia para apreciar la sutileza de lo que los comerciantes intentaban lograr. Además, estimaría un proyecto de TI de más de 5 años para replicar la funcionalidad de una de estas hojas de cálculo en un lenguaje de programación "adecuado" como un proyecto de TI estándar.