archivo

Archivos Mensuales: octubre 2009

Este término lo podréis encontrar en muchísimos libros.

La diferencia muchas veces entre un trabajo correcto y un trabajo excelente está en dedicarle esa porción de tiempo de más (la milla extra) para cuidar los detalles y minimizar el número de errores.

En mi opinión la diferencia no está solo en el talento, sino en las personas y organizaciones que son capaces de aplicar esta milla extra, ese factor diferencial que permite llegar más allá en el trabajo (en volumen y calidad) y/o en la evolución personal (autoformación).

La milla extra supone un esfuerzo, supone ir más allá del trabajo convencional. Esto implica un sacrificio, ya que estás cambiando tiempo libre por tiempo que estás dedicando a una ocupación. No obstante, esa milla extra es la que marca la diferencia, la que te permite subir escalones más deprisa y la que sin duda te devolverá con creces todo ese esfuerzo y sacrificio de más que has invertido.

He estado estos últimos días dándole vueltas sobre quién me dijo hace bastante tiempo, cuál era el requisito fundamental para él o ella para que un empleado de su empresa pasase a desempeñar el puesto de socio. No consigo acordarme de quién me lo dijo, pero sí que recuerdo qué es lo que me comentó.

Desde su punto de vista una persona estaba capacitada para ser socio si tenía el potencial suficiente para llevarse un porcentaje alto de su cartera de clientes si cambiaba de empresa, es decir, que los clientes no lo eran por la marca de la empresa sino por el trabajo y confianza que les daba este empleado.

Entiendo que no es lo único en que se fijan las empresas para darle a un empleado un puesto de carácter directivo, pero sí que me pareció un argumento bastante convincente.

El concepto de Inshore, es un concepto que ha venido de la mano de los dos modelos de centros de desarrollo de software tradicionales: Nearshore y Offshore, los cuales como ya he comentado en diferentes posts, se diferencian por motivos geográficos (para unas personas son unos motivos, para otras otros, en mi caso, el criterio es la distancia).

El Inshore maneja también criterios geográficos para diferencias del Nearshore, ya que hace referencia al establecimiento del centro de desarrollo de software en la misma localización geográfica (mismo municipio o misma provincia) que el centro destinatario del producto resultante.

La regla general que se aplica a estos modelos (no siempre se cumple) es que la distancia reduce la calidad del producto final y también los costes de desarrollo. Supuestamente, atendiendo a esta regla, un centro Inshore produciría resultados de gran calidad, pero también a unos costes de producción altos (o por lo menos similares a la competencia).

La calidad del resultado final depende de muchos factores, pero no necesariamente la distancia debería ser un factor decisivo, si se tiene un buen framework, una buena gestión y organización, una buena metodología y un buen equipo de técnicos. Como en todos los casos, no se puede decir qué una solución es óptima para todos los casos, ya que hay proyectos de desarrollo de software para los que puede resultar interesante el empleo de Offshore, otros Nearshore, otros Inshore y otros una combinación de los anteriores.

El Inshore sólo o combinado con el Nearshore o el Offshore, resulta muy adecuado para proyectos que requieren mucho contacto y feedback con el cliente, por lo que no resulta recomendable (entre otra cosa por los costes) estar desplazando continuamente técnicos y tampoco un umbral de latencia en la respuesta al cliente demasiado alto.

Hasta ahora sólo he trabajado con modelos Inshore puros o con el modelo combinado Inshore-Nearshore, con mejores resultados en los primeros casos que en los segundos, aunque también es cierto que se están mejorando las prestaciones en los últimos trabajos entregados utilizando el modelo Inshore-Nearshore.

Hace poco tuve la oportunidad de ver la película “Hackers 2: Operación Takedown”, la cual también recibe el nombre de Takedown (a secas) o Track Down que narra los años previos a la definitiva detención de Kevin Mitnick (nombre clave Cóndor), uno de los hackers y phreakers más famosos del mundo.

Hasta tanto llegó el mito de Mitnick, que en un documental que también vi hace poco llamado “Historia secreta de los piratas informáticos”, él mismo narra que tras su primera detención se le prohibía acercarse a un teléfono, porque en opinión del fiscal tenía la capacidad de provocar una guerra nuclear. Por cierto, recomiendo el documental aunque sólo sea para ver la parte dedicada a Steve Wozniak en la que se podrá entender mejor como fue el inicio de los ordenadores para uso personal (tampoco tiene desperdicio la primera parte dedicada al Capitán Crunch), cómo fue el inicio de Apple y como finalmente los intereses comerciales acabaron con el Homebrew Computer Club (club formado por amantes de la informática en el que se fabricaron ordenadores, otros componentes hardware y software y que tenía como base compartir globalmente el conocimiento) y en esa misma parte además entender cuál fue el origen del concepto hacker, que nada tiene que ver con las connotaciones negativas con las que se redefinió posteriormente.

Esta película es una adaptación de la novela Takedown, escrita por John Markoff (periodista que contribuyó a la fama de Mitnick y al que se le acusa tanto por el propio Mitnick como por sus seguidores de haber exagerado las acciones de éste y crear un mito y un estado de alarma que no se correspondía con la realidad) y Tsutomu Shimomura (un expero en seguridad informática que colaboró en el proceso de localización y detención de Mitnick).

Independientemente de que John Markoff contribuyese a construir el mito, tuvo también mucho que ver en la construcción del mismo que diferentes agencias federales de Estados Unidos lo estuvieran persiguiendo tres años, hasta que definitivamente lo detuvieron en 1995, teniendo en cuenta que lo acusaban de delitos muy serios.

Independientemente de que la película sea muy mejorable, esté basada en un libro que se basa en uno de los dos puntos de vista en esta historia y se le hayan incluido toques cinematográficos que muy bien podrían sobrar, os recomiendo que si tenéis la oportunidad la veais, ya que podréis ver en ella algunos ejemplos de combinación de técnica e ingeniería social.

Una vez que Mitnick quedó completamente liberado, creó su propia empresa consultora en seguridad informática y de la información, no dudo que sea capaz de hacer bien este trabajo, ya que entiendo que su experiencia, desde el otro lado le permite ver con mayor facilidad los resquicios existentes.

Como se puede apreciar en la película, por encima de la capacidad técnica de Mitnick (que era y es muy grande), se encontraba su extraordinaria capacidad para aplicar lo que se denomina Ingeniería Social y que tanto para él como para muchos expertos en seguridad es donde se encuentra el verdadero punto débil de la seguridad informática (estoy de acuerdo con ellos, porque cualquier barrera software y hardware que se ponga puede ser sorteada si se consigue la información necesaria aplicando técnicas de Ingeniería Social. Es decir, el problema de la seguridad informática se centra más en el factor humano que en el factor software o hardware (sin olvidar como es lógico estos últimos). Mitnick pudo comprobar esto de primera mano, ya que mucha de la información que conseguía recopilar para acceder a un sistema o incluso la misma información que quería conseguir la obtenía a través de llamadas telefónicas.

De hecho Mitnick, establece cuatro principios que son comunes a todas las personas (sacado de Wikipedia):

– Todos queremos ayudar.
– El primer movimiento siempre es de confianza hacia el otro.
– No nos gusta decir No.
– A todos nos gusta que nos alaben.

Pero, ¿en qué consiste exáctamente la Ingeniería Social aplicada al concepto de la seguridad informática? Es tan simple que asusta, consiste en obtener información mediante la manipulación de un tercero, aplicando técnicas como hacerse pasar por otra persona, como representante de una empresa, una empresa, etc…, la cual es directamente la que se busca o que puede servir de base para obtener otra información de carácter más confidencial o directamente para provocar fraudes (robos). Estas técnicas de ingeniería social se pueden aplicar hablando directamente con otra persona, a través del teléfono y a través de los medios que proporciona Internet (páginas web, correo electrónico (un ejemplo lo tenemos en el Phishing), mensajería instantánea, redes sociales, etc…).

Combatir la Ingeniería Social es difícil y requiere una importante concienciación de la ciudadanía en la misma (por ejemplo, en los inicios del Phishing seguro que había más gente que caía que ahora), esta concienciación se consigue mediante la información y la educación. No obstante, los timos han existido prácticamente desde siempre, se han adaptado al entorno (han migrado gran parte de ellos a Internet) y se seguirán realizando, además, por mucha información y educación que se reciba (además de no llegar a todo el mundo) es muy complicado que siempre estemos con la alarma puesta y ahí es donde está el problema.

¿No os ha pasado nunca que tras hablar con un operador/a de telemarketing te da la sensación de que le has facilitado demasiada información?, ¿no os ha pasado nunca que os ha llamado alguien al trabajo os ha preguntado cosas, le habéis dado una respuesta y al final no habéis preguntado ni quien era? Esto es una clara demostración de lo que comenta Mitnick, es decir, sin necesidad de mala fé por parte del interlocutor somos capaces de dar información que de alguna u otra forma podría ser utilizada para beneficio del mismo, ¿cuánto puede conseguir un “profesional” de la ingeniería social en obtener información que le resulta de interés?.

Tan o más importante como fichar bien es conseguir mantener en la organización a aquellos empleados que resultan un activo importante para la misma y esto cobra especial relevancia tanto en los momentos de vacas gordas, donde las empresas tienen mucho trabajo y hay ingresos suficientes como para invertir en personal y en los momentos actuales de crisis donde puede pasar que haya más personal que trabajo.

Las empresas no pueden hacer magia, es decir, si hay un empleado recibe una oferta de una empresa, la comunica a la suya (lo cual no tiene por qué hacerlo) y resulta imposible hacer una oferta mejor, probablemente se vaya, lo mismo pasará, pero al revés (la empresa prescindirá de sus servicios) si las pérdidas son importantes y se hace insostenible mantener el número de empleados. Pero entre estos extremos, donde la situación y las circunstancias pueden provocar la marcha de personal que puede ser importante para la organización, hay toda una gama de posibilidades en las que se puede producir esa fuga o pérdida de talento y que pueden ser evitables en muchos casos.

El hecho de que sean evitables no quiere decir que sea sencillo, de hecho se requiere un esfuerzo importante por parte de los jefes de proyecto, jefes de equipo, departamento de recursos humanos, en cuanto a conocer y tratar las inquietudes que tienen los empleados. Esto no quiere decir que tenga que haber barra libre y que se le tenga que decir que sí a todo lo que se pide, pero por lo menos es necesario tener la sensabilidad suficiente para escuchar y dar una respuesta razonable, ya que uno de los aspectos que más desgaste produce es la sensación de no tener voz o la imposibilidad de tenerla y tengo la sensación que aquellas organizaciones donde la rotación de personal (provocada por el personal) es mayor son aquellas en las que se trata al empleado más como a un robot que como a una persona.

Uno de los principales obstáculos con los que se encuentra la implantación de la firma electrónica en cualquier organización es la desconfianza que se crea tanto de manera interna como en las relaciones con terceros proveedores por utilizarse documentos electrónicos (o físicos si se desean imprimir), en los que no aparece la firma manuscrita.

Por esa razón, ya he comentado en otros artículos que es necesario planificar y realizar un correcto proceso de gestión del cambio que acompañe a la implantación de la firma electrónica en una organización.

Independientemente de que este proceso se ejecute, una herramienta que puede ser muy útil es la utilización de un software (un sitio web) en el que se puede verificar si el documento electrónico recibido se corresponde con el “original” que se firmó y si ha firmado quien indica el documento que se ha firmado. De la misma forma que sucede con el caso del portafirmas electrónico, la venta de este software junto a la plataforma de firma electrónica favorecerá sin duda la realización del negocio, teniendo en cuenta además que implementar esta herramienta tiene un coste muy bajo y sirve para cualquier implantación de la plataforma de firma electrónica.

Aunque no tenga nada que ver con los verificadores de firma electrónica, otra estrategia muy útil para que el documento que se ha firmado electrónicamente parezca más “sólido y consistente” se basa en poner en cada documento firmado electrónicamente un sello de firma, para ello (y contando la estrategia utilizada en mi organización) en un contenido del documento original reducido al 80% se pone al pie dicho sello, con los datos del firmante o firmantes (NIF, nombres y apellidos), la fecha y hora de la firma, un código que identifique unívocamente al documento firmado, el número de página (el documento firmado puede estar formado, como es lógico, por varias páginas) y un código de barras que puede estar construido siguiendo diferentes estrategias.

En la gestión de mis proyectos, otra de las lecciones que he aprendido es que todas las personas que participan en los mismos son importantes y por tanto hay que escuchar lo que se dice.

Hace poco, tomé una decisión sobre cómo debería desarrollarse una determinada funcionalidad en un sistema de información, poco tiempo después me llamó el jefe de proyectos de la empresa proveedora indicándome que una de las personas que da la asistencia a usuarios, recomendaba hacerlo de otra forma para reducir el impacto que iba a tener en los usuarios esa decisión. Una vez escuchada la recomendación, pensé de nuevo como desarrollar la funcionalidad y tomé la decisión de revocar la solución que había recomendado y adoptar la que me había sugerido la persona del equipo de asistencia a usuarios.

Esto es un ejemplo, como podría poneros muchísimos más, siempre estoy abierto a escuchar lo que tengan que decirme las personas que participan en mis proyectos, sin mirar galones. Unas veces tengo en consideración sus recomendaciones y otras no, pero si no escuchase, seguro que me habría equivocado mucho más que lo que me he equivocado hasta ahora.

Todo el mundo es importante en un proyecto y por ese motivo es conveniente transmitirlo y demostrarlo con hechos.