Administración de centros de informática

Primera Edicin
OCE-0620
ADMINISTRACIN DE CENTROS DE INFORMTICA
Manual Terico| Luis Fernando Zelaya Iras
Administracin de Centros de Informtica
Manual Terico
INDICE
I DICE ---------------------------------------------------------------------------------------------------------------------- 2 1 CO CEPTOS BSICOS DE ADMI ISTRACI 1.1 1.2 1.3 1.4 1.5 1.6 2 --------------------------------------------------------- 4
DEFINICIN --------------------------------------------------------------------------------------------------------- 4 LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA? ------------------------------------------------------- 4 RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS -------------------------------------------------- 5 CARACTERSTICAS DE LA ADMINISTRACIN ------------------------------------------------------------------ 5 OBJETIVOS DE LA ADMINISTRACIN ---------------------------------------------------------------------------- 6 PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES ------------------------------------------------------ 6
SISTEMA DE EMPRESA Y SISTEMA DE ADMI ISTRACI --------------------------------------- 7 2.1 2.2 2.3 SISTEMAS DE EMPRESA ------------------------------------------------------------------------------------------- 7 SISTEMAS DE ADMINISTRACIN --------------------------------------------------------------------------------- 9 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS ------------------------------------ 12
3 4
EL GERE TE DE I FORMTICA -------------------------------------------------------------------------- 13 PLA EACI ESTRATGICA Y OPERATIVA --------------------------------------------------------- 14 4.1 4.2 4.3 4.4 4.5 CONCEPTO DE PLANEACIN ------------------------------------------------------------------------------------- 14 OBJETIVOS DE LA PLANEACIN--------------------------------------------------------------------------------- 15 DEFINICIONES DE LOS COMPONENTES DE LA PLANEACIN ------------------------------------------------- 15 ESTRUCTURA DE UN PLAN ESTRATGICO --------------------------------------------------------------------- 19 ESTRUCTURA DE UN PLAN OPERATIVO------------------------------------------------------------------------ 20
PLA EACI E U CE TRO DE I FORMTICA -------------------------------------------------- 23 5.1 5.2 5.3 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 23 COMO MANEJAR LAS PLANIFICACIONES IMPOSIBLES -------------------------------------------------------- 23 COMO GANAR TIEMPO EN UNA PLANIFICACIN DE ACTIVIDADES DEL CENTRO DE INFORMTICA --- 25
ORGA IZACI ------------------------------------------------------------------------------------------------- 28 6.1 6.2 6.3 DEFINICIN -------------------------------------------------------------------------------------------------------- 28 PASOS DE LA ORGANIZACIN ----------------------------------------------------------------------------------- 28 ESTRUCTURA ORGANIZACIONAL ------------------------------------------------------------------------------- 28
ORGA IZACI : EQUIPOS DE TRABAJO E CE TROS DE I FORMTICA -------------- 31 7.1 7.2 7.3 7.4 DEFINICIN -------------------------------------------------------------------------------------------------------- 31 GRUPOS Y EQUIPOS ----------------------------------------------------------------------------------------------- 31 CREACIN DE UN EQUIPO DE ALTO RENDIMIENTO ----------------------------------------------------------- 31 CAUSAS DE FALLO DE LOS EQUIPOS --------------------------------------------------------------------------- 33
8 ORGA IZACI : ESTRUCTURA DE EQUIPOS DE TRABAJO E CE TROS DE I FORMTICA --------------------------------------------------------------------------------------------------------- 35 8.1 8.2 8.3 9 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 35 TIPOS DE EQUIPOS ------------------------------------------------------------------------------------------------ 35 MODELOS DE EQUIPO -------------------------------------------------------------------------------------------- 37
MOTIVACI ---------------------------------------------------------------------------------------------------- 40 9.1 9.2 9.3 9.4 9.5 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 40 MOTIVACIONES TPICAS DEL INFORMTICO ------------------------------------------------------------------ 40 CINCO FACTORES PRINCIPALES DE MOTIVACIN ------------------------------------------------------------- 41 USO DE OTROS FACTORES DE MOTIVACIN ------------------------------------------------------------------- 43 DESTRUCTORES DE LA MORAL ---------------------------------------------------------------------------------- 44
10
LIDERAZGO ------------------------------------------------------------------------------------------------------ 46
2/86
Manual Terico
10.1 10.2 10.3 11
INTRODUCCIN ---------------------------------------------------------------------------------------------------- 46 DEFINICIN DE LIDERAZGO ------------------------------------------------------------------------------------- 46 TENDENCIAS DEL LIDERAZGO ---------------------------------------------------------------------------------- 47
COMU ICACI ------------------------------------------------------------------------------------------------ 49 11.1 11.2 11.3 11.4 11.5 11.6 11.7 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 49 MODELO DE COMUNICACIN ----------------------------------------------------------------------------------- 49 EL MENSAJE-------------------------------------------------------------------------------------------------------- 50 FORMAS DE COMUNICACIN ------------------------------------------------------------------------------------ 50 TIPOS DE COMUNICACIN --------------------------------------------------------------------------------------- 51 DIRECCIONES DE LA COMUNICACIN --------------------------------------------------------------------- 51 COMO MEJORAR LOS PROCESOS DE COMUNICACIN --------------------------------------------------- 51
12
CO TROL ---------------------------------------------------------------------------------------------------------- 53 12.1 12.2 12.3 DEFINICIN -------------------------------------------------------------------------------------------------------- 53 CONTROLES GENERALES EN EL CENTRO DE INFORMTICA ------------------------------------------------ 53 ESTNDARES EN LOS CENTROS DE INFORMTICA ----------------------------------------------------------- 55
13
CO TROL: PROTECCI DE DATOS, HARDWARE Y SOFTWARE ---------------------------- 60 13.1 13.2 13.3 13.4 13.5 13.6 INTRODUCCIN A LA PROTECCIN DE LOS DATOS ----------------------------------------------------------- 60 POLTICAS Y PROCEDIMIENTOS --------------------------------------------------------------------------------- 60 PROTECCIN DE LOS DATOS: POLTICAS DE RESPALDOS --------------------------------------------------- 60 PROTECCIN DE LOS DATOS: POLTICA DE REVISIN DE BITCORA -------------------------------------- 62 PROTECCIN DEL SOFTWARE: POLTICAS EN LA ADQUISICIN DE LICENCIAS DE SOFTWARE --------- 62 PROTECCIN DEL HARDWARE: POLTICAS DE SEGURIDAD FSICA DEL CENTRO ----------------------- 63
14
ADMI ISTRACI DE PROYECTOS I FORMTICOS --------------------------------------------- 65 14.1 14.2 14.3 14.4 14.5 14.6 14.7 INTRODUCCIN ---------------------------------------------------------------------------------------------------- 65 ESTRATEGIA BSICA PARA EL DESARROLLO DE PROYECTOS INFORMTICOS --------------------------- 65 LAS CUATRO DIMENSIONES DE UN PROYECTO INFORMTICO --------------------------------------------- 66 BUSCANDO UN DESARROLLO EFICIENTE DE PROYECTOS INFORMTICOS -------------------------------- 68 ERRORES CLSICOS EN LA ADMINISTRACIN DE PROYECTOS INFORMTICOS --------------------------- 68 BASES DEL DESARROLLO DE PROYECTOS INFORMTICOS ------------------------------------------------- 74 GESTIN DE RIESGOS --------------------------------------------------------------------------------------------- 81
3/86
Manual Terico
1 CONCEPTOS BSICOS DE ADMINISTRACIN

1.1 DEFINICIN
Esta es una de las definiciones ms sencillas de administracin: Administracin es lograr que las cosas se hagan mediante otras personas . Estas es una definicin muy acertada an y cuando cause la impresin entre los legos en administracin de que los administradores no hacen nada, por aquello de que el administrador no est fsicamente trabajando, olvidando que lo que un administrador hace es llevar a la prctica las funciones bsicas de la administracin que son: Planeacin, Organizacin, Direccin y Control. A esas funciones se les conoce como proceso administrativo. E.F.L. Brech dice que: Administracin es el proceso social que lleva consigo la responsabilidad de planear y regular de forma eficiente las operaciones de una empresa para lograr un propsito dado. Koontz y ODonnell dan la siguiente definicin: Administracin es la direccin de un organismo social y su efectividad en alcanzar objetivos, fundada en la habilidad de conducir a sus integrantes. Puede deducirse, de esta y la anterior definicin, que hay dos elementos son los cuales es imposible hablar de administracin: personas y objetivos. As que es imposible encontrar una administracin sin objetivos definidos, aunque es frecuente encontrar empresas sin objetivos. Una descripcin ms detallada del proceso administrativo se logra definiendo cada una de las funciones como una respuesta a las siguientes preguntas: PREVISIN: Qu puede hacerse? PLANEACIN: Qu se va a hacer? ORGANIZACIN: Cmo se va a hacer? INTEGRACIN: Con qu se va a hacer? DIRECCIN: Ver que se haga CONTROL: Cmo se est realizando?
1.2 LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA?

Dentro de los diferentes conceptos de administracin existe una vieja controversia en cuanto a considerar la administracin como una ciencia o como una tcnica. Una definicin de las mismas nos puede ayudar a formar nuestro propio concepto. La ciencia... Nos ensea a conocer Busca la verdad Descubre Descubre principios La tcnica... Nos ensea a hacer Busca la eficiencia Crea Establece reglas 4/86
Manual Terico
En cada una de esas definiciones encontramos elementos que se aplican a la administracin, ya que esta rene conocimiento, tiene principios subyacentes y busca la verdad mediante el mtodo cientfico, pero a la vez busca la eficiencia, crea y establece reglas. De hecho, la administracin no solo rene conocimiento, sino que tambin lo aplica. Por tanto puede concluirse que la administracin es una ciencia y una tcnica.
1.3 RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS

La administracin se relaciona con otras ciencias en diversos aspectos: Aspecto sociolgico: Ya que de la sociologa toma los siguientes principios: divisin del trabajo, unidad de fin, unidad de mando, coordinacin de actividades y medios de accin. Aspecto econmico: La economa ensea a la administracin la mejor manera de aprovechar los recursos de que dispone y al organismo productivo le permite conocer las tendencias estadsticas, las fuentes de abastecimiento, los medios de comunicacin, los mercados locales e internacionales y los medios de distribucin. Aspecto legal: El derecho proporciona a la administracin la estructura jurdica de los organismos sociales. Aspecto psicolgico: La sociologa proporciona a la administracin los medios de motivar la conducta de los miembros componentes del grupo, de manera tal que, en el aspecto interno se logre la adecuada comunidad de ideas y coordinacin de actividades. En el aspecto interno se usa la sicologa para el trato con los clientes, la promocin de ventas, publicidad, etc. En el aspecto moral se dan reglas para guiar la conducta de las personas, recurdese que la administracin es una actividad, su prctica se llama administrar y quien la realiza es el administrador; sin embargo, la tarea de administrar consiste esencialmente en utilizar con eficiencia los esfuerzos del grupo, y el hecho de que la administracin sea una actividad de grupo y no individual resalta la importancia de este aspecto.
1.4 CARACTERSTICAS DE LA ADMINISTRACIN

Entre las caractersticas de la administracin deben sealarse las siguientes: 1. Universalidad: Porque se da dondequiera que haya un grupo social con fines comunes. 2. Unidad: Porque si bien es cierto que el proceso administrativo consta de varios elementos, constituye un fenmeno que es nico y se da en todo momento. 3. Es trascendental: En una empresa se desarrollan diversas funciones tales como: produccin, ventas, finanzas, etc. Y cada una de ellas requiere de especialistas en la materia; pero si cada uno de ellos se coloca frente a un grupo de personas para planear, organizar, dirigir o controlar esas funciones, en ese preciso momento se convierte un administrador. En consecuencia, el fenmeno administrativo es trascendental ya que acompaa a otras funciones o ir acompaado de ellas, pero ser especfico y distinto de los dems. 5/86
Manual Terico
1.5 OBJETIVOS DE LA ADMINISTRACIN

Para que exista un sentido de satisfaccin debe existir un objetivo, lo que da un propsito al esfuerzo; adems el objetivo debe tener un significado y un valor; as que la definicin de un objetivo es: Objetivo Administrativo es una meta que se fija, que requiere un campo de accin definido y que sugiere la orientacin para los esfuerzos de un dirigente. Hay cuatro elementos en esta definicin: 1. Meta 2. Campo de accin 3. Definicin de la accin 4. Orientacin. La falta de objetivos hace que la administracin sea innecesariamente difcil, si es que se puede hablar en rigor de administracin, as que los objetivos bsicos son un prerrequisito para determinar cualquier curso de accin y deben ser definidos con claridad para que los comprendan todos los miembros de la empresa.
1.6 PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES

Las reas de problemas que enfrentan los gerentes son las siguientes: a. Desarrollo y mejoramiento de los objetivos b. Mejoramiento de los recursos, principalmente los humanos c. Finanzas d. tica administrativa e. Efectividad de los medios de comunicacin. Especficamente los problemas que enfrentan los gerentes estn particularmente relacionados con: a. Dificultad para obtener informacin contable y financiera b. Costos, utilizacin de planes de costos estandarizados c. Toma de decisiones, uso de la investigacin de operaciones d. Capacitacin y desarrollo de empleados. e. Obtencin de financiamiento f. Actitud en el trabajo, determinar lo que los empleados piensan de la empresa g. Diseo de productos y servicios que llenen los requisitos del mercado y de la empresa h. Planeacin de la produccin, lotes econmicos, inventarios adecuados y utilizacin ptima de maquinaria y equipo. i. Control de calidad j. Reclutamiento y seleccin de personal k. Administracin de sueldos y salarios
6/86
Manual Terico
2 SISTEMA DE EMPRESA Y SISTEMA DE ADMINISTRACIN

2.1 SISTEMAS
DE EMPRESA El estudio de las empresas y la administracin puede afrontarse desde un punto de vista de sistemas. El sistema de empresa, a su vez, puede abordarse desde dos ngulos: el esttico y el dinmico. El enfoque esttico es el estudio de los componentes del sistema de empresa y su interdependencia. Por otra parte, el anlisis de la administracin y del funcionamiento de la empresa representa el enfoque dinmico. Los dos enfoques con complementarios y permiten un mejor conocimiento de la empresa. Los sistemas de empresa pueden agruparse en tres categoras bsicas: a. Sistemas de empresa industrial b. Sistemas de empresa comercial c. Sistemas de empresa de servicios En nuestro caso particular nos interesa estudiar un centro de informtica, el cual corresponde con los sistemas de empresa de servicios. Estudiaremos ahora el centro de informtica utilizando los dos enfoques.
2.1.1 ENFOQUE ESTTICO

Un centro de informtica es una pequea empresa de servicios dentro de la empresa madre y como tal tiene una serie de componentes que se interrelacionan para darle un funcionamiento sistemtico. Estos componentes suelen ser: servicios de fabricacin, de aprovisionamiento, mercadotecnia (si! Informtica debe vender sus productos), finanzas y personal; adems el sistema centro de informtica se compone de: la estructura organizacional, los administradores y los empleados. Un centro de informtica, visto desde un enfoque esttico puede representarse grficamente de la siguiente manera:
7/86
Manual Terico
Componentes del Sistema de un Centro de Informtica

Recursos Financieros Recursos Humanos
PRODUCCIN
estudio de necesidades
concepcin del servicio
desarrollo e implantacin
concepcin del procedimiento
Mercadotecnia Consumidores
Recursos Materiales
El funcionamiento de este sistema puede resumirse en el ciclo principal, el cual constituye el corazn del mismo. A partir del estudio de necesidades el centro de informtica se forma una idea del servicio solicitado y es capaz de planificar la manera en que ese servicio ser producido. Seguidamente disea el servicio, lo desarrolla y lo pone a disposicin del cliente o consumidor, mejor conocido en este caso como usuario. El sistema de produccin de servicios informticos se alimenta de recursos financieros, humanos y materiales que le son provistos por la empresa para su funcionamiento.
2.1.2 ENFOQUE DINMICO

El enfoque dinmico se concentra ms en el flujo de la produccin del servicio que en los componentes que componen el sistema de empresa. El flujo de la produccin es un ciclo operacional que la empresa, o , en nuestro caso, el centro de informtica, cumple para lograr la produccin de servicios solicitados por las diferentes reas de la empresa. Los centros de informtica realizan un mnimo tareas rutinarias, sus principales acciones pueden calificarse de pequeos proyectos de produccin de servicios, que siguen un ciclo operacional que tiene principio y final y que es reactivado en la medida en que se van recibiendo nuevos requerimientos. El ciclo operacional de un centro de informtica puede representarse grficamente as:
8/86
Manual Terico
Concepcin de productos y procedimientos
Previsiones
Planificacin de la produccin
Puesta en marcha
Reclutamiento y ajuste del personal Fabricacin
Aprovisionamiento
Ciclo Operacional del sistema de centro de informtica Obviamente, el ciclo operacional se inicia con la concepcin del los productos a producir (servicios informticos) y con la definicin de los procedimientos a seguir para producirlos. Seguidamente habr que estimar cuales y cuantos sern los insumos que se utilizarn productos que se van a producir, para proceder al aprovisionamiento de los mismos. Una vez que se cuente con todos los recursos necesarios se procede a la fabricacin (desarrollo) y finalmente a la entrega y puesta en marcha del servicio producido. La llegada de nuevos requerimientos hace que retornemos al principio del ciclo.
2.2 SISTEMAS DE ADMINISTRACIN

Los sistemas de administracin son 100% dinmicos. Se refieren a procesos y no a estructuras. Ms que estar formados por componentes, estn formados por subsistema, que se interrelacionan entre s para ejecutar las funciones del proceso administrativo. El sistema de administracin puede representarse as:
SISTEMA DE CONTROL
SUBSISTEMA DE ORGANIZACION ADMINISTRATIVA SISTEMA ORGANIZACIONAL SUBSISTEMA DE INFORMACIN Informaciones Operacionales Informaciones de Control
SISTEMA OPERACIONAL
Sistema de Administracin
9/86
Manual Terico
El sistema operacional es la base del sistema administrativo, de all provienen las informaciones operacionales y de control que retroalimentan a la empresa y dan una idea sobre el rendimiento. Adems, lo ms importante, all es donde se producen los servicios.
2.2.1 SISTEMA DE CONTROL

Los sistemas de administracin se componen de subsistemas que se encargan de ejecutar las funciones bsicas del proceso administrativo. Todos ellos requieren de un agentes humanos y materiales para ejecutar su funcin y tienen un procedimiento para cumplir su objetivo. El primero de ellos es el sistema de control que est compuesto por los siguientes elementos:
2.2.1.1.1.1.1 Agente Humano Administrador Director Director Adjunto Responsable Agente Fsico Equipo Sistemas Otros
Funcin: Administrar eficaz y racionalmente los recursos Procedimiento:
Insumos (Datos)
Identificacin de Variables
Determinacin de un valor para cada variable
Eleccin de una solucin
Medicin de resultados Producto (Plan Estratgico, Polticas y reglas, Decisiones, Informacin)
Evaluacin de las variaciones
Sistema de Control
La funcin del sistema de control es administrar eficazmente los recursos, materiales, humanos y financieros de una unidad productiva. Esto significa aplicar el proceso administrativo. Se trata aqu de definir los objetivos, establecer los 10/86
Manual Terico
medios para alcanzarlos, medir los resultados, evaluar las variaciones y tomar las decisiones correctivas que sean necesarias. Los agentes humanos que intervienen en el sistema de control son los administradores de todos los niveles jerrquicos.
2.2.2 SISTEMA OPERACIONAL

Su misin es ejecutar los trabajos que le confa el sistema de control. Estos trabajos tienen como finalidad realizar un producto determinado. En el caso de un centro de informtica, se busca obtener un servicio informtico. El sistema operacional est compuesto por los siguientes elementos:
2.2.2.1.1.1.1 Agente Humano Obreros Tcnicos Analistas Agente Fsico Equipo Sistemas Herramientas Otros
Funcin: Realizar un producto terminado Procedimiento:
Insumos (Datos, Materiales, Productos semiterminados Energa, etc.)
Procedimiento de Produccin
Producto o servicio terminado (Sistemas de informacin, Redes construidas, Equipo reparado, etc.)
Sistema Operacional
El procedimiento de produccin vara de acuerdo a las caractersticas tcnicas del servicio a producir. La caracterstica fundamental de ese procedimiento es que debe permitir la produccin del servicio de manera eficiente, con la calidad requerida a un costo mnimo.
2.2.3 SISTEMA ORGANIZACIONAL

Su misin es implantar las estructuras administrativas y operacionales necesarias para el buen funcionamiento del sistema de empresa. Su producto tiene dos aspectos: la organizacin social y la informacin. a. El subsistema de organizacin social: Comprende el conjunto de estructuras jerrquicas de la empresa que definen las relaciones entre los miembros del personal. Estas relaciones se representan mediante un diagrama llamado organigrama administrativo, el cual permite visualizar las lneas de autoridad y de comunicacin en el seno de la empresa. Este organigrama suele acompaarse de un manual que describe las polticas, reglas y funciones de cada dependencia y puesto dentro de las unidades de la estructura. 11/86
Manual Terico
b. El subsistema de informacin: Este es el conjunto de informes relativos a las actividades del sistema operacional y los informes de control, y permite al sistema de control evaluar las operaciones. El subsistema de informacin constituye un puente entre el sistema de control y el sistema operativo. El sistema organizacional est compuesto de los siguientes elementos:
2.2.3.1.1.1.1 Agente Humano Directores Asesores Analistas Agente Fsico Equipo Sistemas Otros
Funcin: Implantar estructuras organizacionales y operacionales Procedimiento:
Insumos (Datos concernientes a los objetivos y los recursos)
Proceso de anlisis y resolucin de problemas
Proceso de concepcin de sistemas
Producto (Organigrama administrativo, Manual de organizacin, Sistemas de informacin internos)
Sistema Organizacional
2.3 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS

En esencia, para la creacin de servicios informticos en necesario tener en cuenta que los siguientes elementos deben ser orquestados (sin excepcin) para construir servicios slidos y tiles: ESTRUCTURA OBJETIVOS ELEMENTOS ENTRADAS PROCESO REALIZADO SALIDAS GEREENTE/PRESI DENTE, SUBGERENTES, GERENTES FUNCION ALES GENER AR PRODUCTOS DE UTILIDAD Y SATISFACCIN DEL USU ARI O PERSON AS, I NSTAL ACI ONES, EQUIPO, DINERO, MATERI ALES
MATERI ALES, I NFORM ACI N, ENERG A
CONVERTI R PARTES Y M ATERI AS PRIMAS EN BIENES TERMINADOS,

PREST AR SERVI CIOS Y SUMINI STRAR I NFORM ACI N
PRODUCTOS, I NFORM ACI N, SERVICIOS
12/86
Manual Terico
3 EL GERENTE DE INFORMTICA
El puesto de gerente de informtica es de mucha responsabilidad. La mejor preparacin que puede tener una persona para este puesto se basa en tres clases de experiencia: Una formacin universitaria en materia informtica Experiencia en el rea informtica (desarrollo y administracin de sistemas de informacin particularmente), y Experiencia en la gerencia de lnea de nivel medio. No basta la educacin, ni la experiencia tcnica para ser un buen gerente. Tienen importancia extrema las habilidades de trato con la gente. El siguiente cuadro muestra una clasificacin de la importancia que tiene cada una de las cualidades (o habilidades) que debe reunir un gerente de informtica, comparando con la importancia que cada una tiene en un gerente de un rea meramente administrativa.
HABILIDAD CONOCIMIENTO TOTAL DE LA COMPA A Y SUS
OBJETIVOS CLASIFICADA POR EJECUTIVOS EN INFORMTICA CLASIFICADA POR EJECUTIVOS GENERALES
2 6 1
1 2 3
CAPACIDAD DE COMUNICARSE CON EFICACIA, EN

FORMA ORAL Y POR ESCRITO
RELACIONES CON LOS OTROS DEPARTAMENTOS

QUE UTILIZAN LOS SERVICIOS QUE OFRECE LA UNIDAD DE INFORMTICA
CAPACIDAD DE DIRIGIR PROYECTOS RELACIONES CON LA ALTA GERENCIA RELACIONES CON LOS SUBORDINADOS CONOCIMIENTO
DE LAS INFORMACIN UTILIZADAS JUZG AR DISEOS TECNOLOGAS DE
4 3 5 8 7
4 5 6 7 8
CAPACIDAD DE DISEAR SERVICIOS Y ANALIZAR Y
Esta clasificacin, que est basada en entrevistas con gerentes de informtica en todo Estados Unidos, revela que la jornada del gerente de informtica es a las de ejecutivos de otras reas en el sentido de que realizan muchas actividades diferentes y sobre todo porque (aunque parezca sorprendente) durante la jornada no tienen contacto con la parte medular de sus actividades: la computadora. En cambio, pasan das hablando con los usuarios de los servicios a crear y ofrecer, y planeando como mejorarlos. Estas dos actividades primarias se combinan con varias otras, entre ellas: asuntos legales, administracin de personal del departamento y una avalancha de material de lectura. Esta situacin se presenta, obviamente, dependiendo de la etapa de crecimiento en la que est cada empresa. 13/86
Manual Terico
4 PLANEACIN ESTRATGICA Y OPERATIVA

4.1 CONCEPTO DE PLANEACIN
Cada erudito en administracin tiene su propio concepto de lo que es la planeacin. Examinar varios de ellos puede llevarnos a formar nuestro propio concepto: Planeacin es el diseo de un futuro deseado y de formas efectivas de convertirlo en realidad. 4.1.1.1.1.1.1.1 Russell Ackoff Planeacin es un proceso que empieza con objetivos, define estrategias, polticas y planes detallados para lograrlos, que establece la organizacin para implementar decisiones, e incluye una revisin de actuacin y retroalimentacin para iniciar un nuevo ciclo de planeacin. 4.1.1.1.1.1.1.2 George Steiner Planeacin es el proceso continuo de tomar decisiones empresariales presentes en forma sistemtica y con el mejor crecimiento posible de su futuridad, organizando sistemticamente los esfuerzos necesarios para llevar a cabo estas decisiones contra las expectativas mediante retroalimentacin organizada y sistemtica. 4.1.1.1.1.1.1.3 Peter Drucker La planeacin llena el vaco entre donde estamos y donde queremos ir y su tarea es exactamente minimizar los riesgos a la vez que se obtienen ventajas de las oportunidades. 4.1.1.1.1.1.1.4 Annimo La combinacin de estos elementos nos llevan a determinar el contenido de la planeacin, es decir, todo lo que tiene que estar claro para que la empresa pueda echar a andar un plan que le lleva hacia donde quiere llegar:
Contenido de la Planeacin
Dnde estamos? a dnde queremos ir? a dnde podemos llegar? a dnde debemos llegar? Cmo podemos llegar? Cundo queremos llegar? Quin es el responsable? Cunto costar? Anlisis de Fortalezas y Debilidades Objetivos/Metas Visin de la organizacin Misin de la organizacin Polticas/Estrategias Programacin de Actividades Planeacin organizacin operativa de la
Recursos Humanos y financieros?
14/86
Manual Terico
4.2 OBJETIVOS DE LA PLANEACIN

Los objetivos de la planeacin son: a. Proporcionar una imagen clara de lo que la empresa desea. b. Traducir la visin de la empresa en planes, metas y objetivos, los cuales adems debern ser fieles a la misin de la misma. c. Aumentar la responsabilidad y el compromiso total de la empresa a travs de la definicin exacta de lo que se va a hacer. d. Establecer una base sobre la cual pueda evaluarse el desempeo de la organizacin en general y del personal en particular, en todos los niveles (directivo, administrativo y operativo).
4.3 DEFINICIONES DE LOS COMPONENTES DE LA PLANEACIN

Los conceptos anteriores ameritan la aclaracin de algunas definiciones: Anlisis FODA: Las siglas FODA significan Fortalezas, Oportunidades, Debilidades y Amenazas,. Este anlisis se hace antes de cualquier proceso de planeacin para determinar: e. Fortalezas: son los puntos fuertes al interior de la organizacin, sus ventajas competitivas. Podran ser, por ejemplo: La excelente formacin acadmica de sus empleados, la tecnologa que se posee, etc. f. Oportunidades: son las situaciones que se dan al exterior de la organizacin y que pueden redundar en beneficios o posiciones favorables para la misma. Por ejemplo: La aprobacin de un proyecto de cooperacin tcnica para la organizacin, la aprobacin de intercambios de tecnologa con otras instituciones, el perfeccionamiento de la tecnologa de internet y el surgimiento de ebusiness, etc. g. Debilidades: son los puntos dbiles que se tienen en el interior de la organizacin y que limitan la posibilidad de fijarse altas expectativas en una planificacin. Estas pueden ser: Limitaciones logsticas para el desarrollo de las actividades, escasez de recursos financieros, base tecnolgica deficiente, etc. h. Amenazas: son las situaciones que se dan al exterior de la organizacin y que pueden afectar negativamente a la misma. Podran ser, por ejemplo: Cancelacin de ayuda internacional para proyectos relacionados con tecnologa, aparicin de tecnologas que permitan la violacin de la seguridad de los sistemas, etc. Obviamente, un plan estratgico, y su consecuente plan operativo, debe orientarse a explotar las fortalezas, aprovechar las oportunidades, eliminar las debilidades y anular las amenazas. Visin: Es la expresin de lo que la organizacin aspira a ser al cabo de un plazo determinado. Es imaginar y construir una idea del futuro deseado. Es la inspiracin que seala el camino a seguir en la planeacin. La visin de un centro de informtica podra ser: 15/86
Manual Terico
El centro de informtica ser en el plazo de cinco aos la fuente nica, segura y confiable de informacin para toda la organizacin, la cual estar completamente automatizada y comunicada de forma electrnica a nivel nacional. Misin: Es la razn de ser de la organizacin, en base a lo que se espera de ella. La misin proporciona las pautas para el diseo de un plan estratgico. Ejemplo de misin1: Proveer a la Direccin Ejecutiva de Ingresos los servicios informticos integrales que incluyen el desarrollo e implantacin de sistemas de informacin, construccin de infraestructura de comunicaciones y soporte tcnico a los usuarios de equipo y programas informticos . Objetivos: Son los fines que se pretenden alcanzar en un futuro determinado para la accin y el xito deseado. Puede ser en forma total de la empresa o en alguna de sus reas o secciones. Los objetivos se definen en dos niveles: generales y especficos. Ejemplos de objetivo general: Contar con sistemas de informacin eficientes que provean informacin oportuna y confiable a todos los niveles en la DEI. Ejemplo de objetivos especficos: Establecer en la Divisin de Informtica una estructura eficiente y ajustada a los grandes objetivos de la institucin. Institucionalizar un sistema de informacin tributaria automatizado que haga ms eficientes las actividades en las reas de Recaudacin, Fiscalizacin, Cuenta Corriente, Reclamos, Cobranzas, Estadsticas. Integrar de manera automatizada la informacin tributaria y aduanera a nivel nacional Metas: Representan la cuantificacin de los objetivos. Son los resultados deseados (expresados cuantitativamente en forma precisa) necesarios para cumplir el objetivo de cada programa. Son medibles y limitadas en tiempo, es decir que se ajustan a un calendario de trabajo. Ejemplo de metas: A septiembre del 2000 estar completo el proceso de reestructuracin de la Divisin de Informtica A septiembre del 2001 tener implantado y operando el SIT en las reas de : Recaudacin, Fiscalizacin, Cuenta Corriente, Reclamos, Cobranzas, Estadsticas, con informacin base depurada en un 100% A diciembre del 2002 tener completamente integrado los sistemas SIT y SIDUNEA con una cobertura a nivel nacional de un 100%.
La mayora de los ejemplos que aqu se mencionan han sido tomados del Plan Estratgico y Operativo de la Direccin Ejecutiva de Ingresos, formulado en mayo del 2000.
16/86
Manual Terico
Polticas: Son las normas generales que sirven de gua al pensamiento y la accin. Las polticas se apoyan en los objetivos y comprometen a la direccin a seguir un curso de accin determinado para alcanzar objetivos especficos y tienen que establecerse tomando en cuenta la eficiencia de la empresa. Ejemplos de polticas: Toda inversin en hardware y software que exceda el valor de Lps.100,000 deber ser sometida al Procedimiento de Compras del Estado. Todo el personal que se contrate para el proyecto de desarrollo e implantacin del SIT deber tener un ttulo de educacin superior en el rea de informtica. El personal contratado por organismos internacionales que labore dentro de la institucin se regir bajo las normas laborales establecidas para el resto de los empleados de la institucin Estrategias: Es el arte de emplear las destrezas y recursos de una empresa para lograr sus objetivos bsicos en las condiciones ms ventajosas. Las estrategias muestran la direccin y empleo general de recursos y esfuerzos. Ejemplos de estrategias: La Direccin Ejecutiva de Ingresos desarrollar e implementar, sistemas de informacin integrados, modernos, eficientes, confiables y que gocen de aceptacin y credibilidad con la participacin de los usuarios, facilitadores y consultores internacionales. La institucin contratar de manera permanente recursos humanos con formacin slida en informtica y de acuerdo a perfiles previamente definidos para facilitar la implantacin de sistemas con el fin de dar un mejor servicio a las distintas dependencias. La institucin financiar sus proyectos informticos a travs de prstamos y donaciones de organismos internacionales. Programas: Son esquemas en donde se establece, la secuencia de actividades que habrn de realizarse para lograr objetivos y el tiempo requerido para efectuar cada una de sus partes y todos aquellos eventos involucrados en su consecucin2. Presupuestos: Son los planes de todas o algunas de las fases de actividad del grupo social expresado en trminos econmicos, junto con la comprobacin de la realizacin de dicho plan. Actividades: Son acciones concretas diseadas para lograr las metas. Ejemplos de actividades: Revisar y actualizar el estudio tcnico mediante el cual se propone la reestructuracin de la Divisin de Informtica
La herramienta ms utilizada para la representacin de un programa es el cronograma, el cual hace un mayor nfasis en el tiempo en que las actividades van a realizarse.
2
17/86
Manual Terico
Proceder con la reestructuracin de la Divisin de Informtica ejecutando las actividades incluidas en el estudio tcnico que se refiere al proceso de reubicacin del personal, reasignacin de funciones y contratacin de nuevo personal Integrar los equipos o comisiones de trabajo cuya responsabilidad principal ser realizar un diagnstico completo sobre la situacin real actual de las reas de: Recaudacin, Fiscalizacin, Cta. Cte., Reclamos, Cobranzas, Estadsticas Realizar un estudio para determinar la mejor forma de lograr la integracin de los sistemas SIT y SIDUNEA
18/86
Manual Terico
4.4 ESTRUCTURA DE UN PLAN ESTRATGICO

Un plan estratgico puede estructurase de la siguiente manera:
4.4.1.1.1.1.1.1.1
PLAN ESTRATGICO
<Empresa YYY>
<Mes inicio> del <Ao inicio> a <Mes final> del <Ao Final> VISIN <...> MISIN <...> OBJETIVO GENERAL <...> ESTRATEGIAS 1. ... 2. ... 3. ...
OBJETIVOS ESPECIFICOS
4. ... 5. ... 6. ...

METAS ACTIVIDADES ESTRATGICAS
1. ... 2. ... 3 . ...
1. ... 2. ... 3 . ...
1. ... 2 . ... 3 . ...
19/86
Manual Terico
4.5 ESTRUCTURA DE UN PLAN OPERATIVO
4.5.1.1.1.1.1.1.1
PLAN OPERATIVO ANUAL

<Empresa YYY>
<Mes inicio> del <Ao inicio> a <Mes inicio> del <Ao final>
Perodo Descripcin de la Actividad Desde Cronograma (May - Abr) Recursos Requeridos
Humanos Materiales Financieros
Hasta M J J A S O N D E F M A Responsable
Observaciones
Actividad 1 Actividad 2
02/05/00 08/05/00
Funcionario X Soporte Funcionario Z
Equipo de100,000 Administrativ cmputo o Soporte Equipo de180,000 Administrativ cmputo o
09/05/00 15/05/00
Actividad 3 Actividad 4
16/06/00 31/12/01 16/06/00 31/12/00
IDEM
IDEM
IDEM
IDEM
Funcionario Y Consultor
Materiales y200,000 equipo de oficina
20/86
Manual Terico
21/86
Manual Terico
5 PLANEACIN EN UN CENTRO DE INFORMTICA

5.1 INTRODUCCIN
La mayora de las personas relacionadas con sistemas de informacin, inclusive los gerentes de informtica no controlan su propia planificacin. Las planificaciones se transmiten como los 10 Mandamientos, desde arriba, ya sea esto la gerencia general, el gerente financiero, el de marketing, etc. Lo ms grave es que estos jefes, por considerar nicamente sus fines sin conocer las limitaciones que puedan sufrirse suelen plantear planificaciones imposibles. Y estas planificaciones son el mayor problema del rea de informtica. Otro problema que se afronta es que, al no estar el centro de informtica familiarizado con la actividad de planeacin, se suele incurrir en significativas prdidas de tiempo en actividades perjudiciales e improductivas, produciendo retrasos difciles de justificar ante los que exigen resultados al rea de informtica.
5.2 COMO MANEJAR LAS PLANIFICACIONES IMPOSIBLES

La mayora de las actividades del centro de informtica se desarrollan bajo un concepto de proyecto, y generalmente el rea que solicita el proyecto desea que el mismo se desarrolle lo ms pronto posible . Casi siempre, la demanda del desarrollo rpido de una tarea en informtica llega procedente de los usuarios o clientes o desde los altos cargos. Todos ellos son clientes del centro de informtica y pueden aplicar una enorme presin para hacer que un proyecto informtico se desarrolle ms rpido, pero en ocasiones lo que necesitan realmente es un menor costo o un menor riesgo. Simplemente no saben como pedir las cosas o no saben que esas cosas no estn ligadas con la velocidad mxima de desarrollo. Antes de orientar el proyecto hacia una planificacin ms corta, en vez de orientarlo hacia el menor costo o la mejor funcionalidad, hay que descubrir que es lo que realmente se necesita. Hay varias apariencias de desarrollo rpido que parecen clamar por la mxima velocidad de desarrollo, pero lo que realmente pide es otra cosa, como ser: i. Evitar retrasos: Lo que el cliente desea realmente es asegurarse de que el proyecto terminar ajustndose a los plazos y presupuestos previsto. La solucin no est en correr, sino en aplicar una mejor gestin de riesgos, hacer una estimacin realista de los tiempos y recursos a utilizar y mantener un permanente control sobre las actividades. j. Predecibilidad: En muchos casos los clientes desean coordinar la parte de desarrollo de software de un proyecto con previsiones de beneficios, marketing, planificacin del personal y, quizs, otros proyectos de software. Aunque pueden pedir mxima velocidad al centro de informtica lo que realmente estn demandando es una predecibilidad suficientemente buena para poder coordinar los esfuerzos relacionados. En este caso, en lugar de sacrificar la planeacin y forzar el desarrollo del proyecto, se debe centrar esfuerzos en lograr un
23/86
Manual Terico
desarrollo eficiente y hacer hincapi en los mtodos que reduzcan los riesgos, para no incurrir en retrasos. k. Menor Coste: No es raro que los clientes quieran minimizar el costo del proyecto informtico. En estos casos hablarn de terminar pronto el proyecto, pero, en realidad, harn nfasis en su preocupacin por el presupuesto y no en la planificacin. Aunque resulte lgico suponer que la planificacin corta del proyecto es tambin la ms barata, los mtodos que minimizan el costo y la planificacin son diferentes. Alargar un poco la planificacin por encima de la inicial y disminuir el tamao del equipo puede reducir el costo total de un proyecto. l. Fecha fija de prdida de valor: Hay ocasiones en que el beneficio a obtener del desarrollo de un proyecto informtico desciende paulatinamente a lo largo del tiempo, y en ocasiones desciende precipitadamente pasado un cierto tiempo. Pinsese por ejemplo en una compaa de ventas de servicio de telefona satelital queriendo implantar su sistema automatizado de ventas y servicio al cliente antes que lo haga la competencia y que esta acapare los clientes importantes. Si existe un punto en el que el valor o beneficio de un proyecto desciende precipitadamente , parece lgico decir: Necesitamos toda la velocidad posible de desarrollo para estar seguros de que entregaremos el producto antes de ese punto. Sin embargo, la necesidad de acelerar el desarrollo depende realmente del tiempo que se tenga para realizar el proyecto, y del tiempo necesario para desarrollarlo eficientemente. Si se puede completar el proyecto antes de la fecha de perdida de valor, utilizando mtodos eficientes, en lugar de mtodos acelerados, hay que hacerlo, centrndose en la reduccin de riesgos y no en la velocidad de desarrollo. Esto ofrece una mayor posibilidad de terminar el proyecto a tiempo. m. Deseo de horas extras gratuitas: No es muy frecuente, pero en algunas ocasiones el inters del cliente o directivo por acelerar un proyecto informtico enmascara el deseo de obtener una ganancia econmica en forma de tiempo extra gratuito del personal de informtica. Esta circunstancia es fcil de distinguir, ya que el cliente insistir en la importancia de la planeacin y, simultneamente, se negar a ofrecer el soporte necesario para mejorar la velocidad de desarrollo por cualquier otro medio que no sean las horas extras sin remunerar. El cliente no insistir en tener ms personal, mejorar las herramientas de hardware y software u otros tipos de soporte. En verdadero caso de necesidad de reducir el tiempo del proyecto el cliente estar dispuesto a considerar cualquier medio para reducir la planificacin. La solucin para manejar, o mejor dicho evitar, las planificaciones imposibles, consiste en lograr el perfecto equilibrio de tres factores: la planificacin, el costo y el producto. Un tringulo de equilibrio entre planificacin, costo y producto es algo bsico para la gestin de proyectos en el centro de informtica. En el extremo del producto se incluyen la calidad y todos los atributos relacionados con el 24/86
Manual Terico
producto, incluyendo prestaciones, complejidad, usabilidad, facilidad de modificacin, mantenimiento, tasa de errores y dems. Lograr ese equilibrio es una tarea difcil ya que, como acertadamente lo dice Watts Humphrey Con raras excepciones, la estimacin de recursos y la planificacin iniciales son inaceptables. Esto no se debe a que el personal de informtica sea irresponsable, sino a que, generalmente, los usuarios desean ms de lo que pueden abarcar. Si el trabajo no entra en la planificacin y recursos disponibles, tiene que reducirse, o bien tienen que incrementarse el tiempo y los recursos. Es apropiado representar grficamente este tringulo para demostrar la importancia de lograr el equilibrio:
Planificacin
Para mantener equilibrado el tringulo hay que calibrar la planificacin el costo y el producto. Si se desea incidir en la esquina del producto, tendr que incrementarse el costo, la planificacin o ambos. Con las dems combinaciones pasa lo mismo. Si se desea modificar uno de los vrtices del tringulo, se tendr que modificar al menos uno de los otros para mantenerlo equilibrado. Una tcnica para equilibrar el tringulo mediante concenso entre informtica y el cliente es dar al cliente uno o dos vrtices a controlar. El otro lo controla informtica. De manera que si un cliente se centra en los vrtices producto y costo, Informtica se centra en explicar como resulta afectada la planificacin y, en lo posible, de equilibrar el tringulo manipulando ese vrtice. De igual manera si el cliente se fija nicamente en el producto, Informtica puede darle una gran variedad de opciones de costo y planificacin.
5.3 COMO
GANAR TIEMPO EN UNA PLANIFICACIN DE ACTIVIDADES DEL CENTRO DE INFORMTICA
Estudios hechos en Estados Unidos demuestran que las reas de informtica tienen una eficiencia menor al 50%. El tiempo restante se gasta en actividades improductivas , como el uso de herramientas de productividad que no funcionan, la reparacin de mdulos desarrollados de forma descuidada, trabajo perdido debido a la falta de control de configuracin, entre otras causas. 25/86
Producto
Costo
Manual Terico
Dnde se puede ahorrar tiempo?. Podemos ganar tiempo si lo recuramos de algunas de las siguientes reas donde los desperdicios son muy frecuentes: a. Trabajo repetido: Repetir requerimientos, diseo y cdigo defectuoso puede consumir generalmente de un 40 a un 50% del costo total de un proyecto informtico. La correccin temprana de defectos, cuando resultan menos costosos de corregir y cuando las correcciones evitan una repeticin posterior del trabajo ofrece una oportunidad potente para reducir el tiempo. b. Cambio de prestaciones del producto: El cambio de prestaciones puede deberse a cambios en los requerimientos por parte del cliente o meticulosidad por parte del informtico. Un proyecto normal experimenta al menos un 25% de cambios a lo largo de su desarrollo, lo que aade al menos un 25% ms de esfuerzo. No limitar los cambios en los requerimientos a los estrictamente necesarios es un error clsico que afecta enormemente el tiempo de la planificacin. Eliminar o minimizar el cambio de prestaciones ayuda mucho a eliminar los retrasos globales en la planificacin. c. Especificacin de requerimientos: Esta actividad se da antes del inicio formal de proyecto, al menos antes de la participacin fuerte de Informtica en el mismo, y es ms abierta que el resto, por lo que es posible desperdiciar grandes cantidades de tiempo en ella. Un moderado sentido de urgencia durante la recopilacin de requerimientos puede evitar una sensacin total de pnico al final del proyecto. d. El inicio difuso: El tiempo total necesario para desarrollar un proyecto informtico va desde el punto en que el proyecto es solo una visin en la mente de alguien hasta que el producto terminado est en manos del cliente. Algn tiempo despus de que el proyecto es una visin se toma la decisin de comenzar. El tiempo entre ambos eventos puede ser muy largo, y, sin embargo,, en la mente del cliente es tiempo puede formar parte del tiempo previsto para el proyecto. Esto es un inicio difuso el cual puede consumir gran parte del tiempo destinado para el proyecto. Como no se realizan controles formales (no hay planificacin, ni presupuesto, ni metas, ni objetivos) durante este perodo el progresos es difcil de controlar. En el inicio difuso se puede perder tiempo por estas razones: Nadie tiene asignada la responsabilidad del desarrollo del proyecto. No existe sensacin de urgencia para tomar la decisin de comenzar/no comenzar el proyecto. Los aspectos clave en la viabilidad del proyecto no pueden ser explorados hasta que se apruebe el presupuesto del proyecto. El proyecto debe esperar un ciclo anual de aprobacin de proyectos y presupuestos.
26/86
Manual Terico
El equipo que desarrolla el proyecto no es el mismo que trabaj para su aprobacin. Al preparar el equipo de desarrollo, familiarizarlo con el producto y encargarle la tarea se pierde tiempo y empuje. El esfuerzo empleado en el inicio de un proyecto suele ser bajo, pero el costo del retraso puede ser alto. La nica forma de recuperar un mes perdido en el inicio difuso es acortar en un mes el desarrollo del proyecto en su fase final, y hacer esto al final cuesta ms que hacerlo al inicio. Aprovechar el tiempo al inicio del proyecto representa una de las oportunidades ms econmicas y efectivas ganar tiempo en la planificacin de proyectos informticos.
27/86
Manual Terico
6 ORGANIZACIN
6.1 DEFINICIN
Una Organizacin es un patrn de relaciones, muchas relaciones simultneas entrelazadas, por medio de las cuales las personas, bajo el mando de los gerentes, persiguen metas comunes establecidas en la planeacin. Las metas que los administradores desarrollan en funcin de la planificacin suelen ser ambiciosas y de largo alcance. Los gerentes quieren estar seguros de que sus organizaciones podrn aguantar mucho tiempo. Por su parte, los miembros de una organizacin necesitan un marco estable y comprensible en el cual puedan trabajar unidos para alcanzar las metas de la organizacin. La funcin gerencial de Organizacin implica tomar decisiones para crear este tipo de marco, de manera tal que las organizaciones puedan durar desde el presente hasta un futuro de mediano y largo plazo.
6.2 PASOS DE LA ORGANIZACIN

A pesar de lo enunciado anteriormente, organizar es una funcin gerencial permanente. Las estrategias pueden cambiar, el entorno tambin y la eficacia y eficiencia de las actividades de la organizacin pueden no estar acorde con el nivel que los gerentes querran. Sea que se este consituyendo una organizacin nueva, que se est modificando una existente o que se cambien radicalmente las relaciones de una organizacin, hay cuatro pasos bsicos que el gerente debe dar para construir una organizacin: a. Divisin del Trabajo: Dividir la carga de trabajo entera en tareas que puedan ser ejecutadas, en forma lgica y cmoda, por personas o grupos. b. Departamentalizacin: Combinar las tareas de forma lgica y eficiente. La agrupacin de los empleados y tareas. c. Jerarqua: Especificar quien depende de quin en la organizacin. d. Coordinacin: Establecer mecanismos para integrar las actividades de los departamentos en un todo congruente y para vigilar la eficacia de dicha integracin.
6.3 ESTRUCTURA ORGANIZACIONAL

La estructura organizacional se refiere a la forma en que se dividen, agrupan y coordinan las actividades de la organizacin en cuanto a las relaciones entre los gerentes y los empleados, entre gerentes y gerentes y ente empleado y empleados. Los departamentos de una organizacin se pueden estructurar formalmente en en tres formas bsicas: por funcin, por producto/mercado, o en forma de matriz.
6.3.1 ESTRUCTURA ORGANIZACIONAL DE UN CENTRO DE INFORMTICA

Cualquiera de las tres formas bsicas de organizacin aplica para los centros informtica de una empresa, y ser esta la que decidir cual forma se ajusta 28/86
Manual Terico
mejor a sus necesidades, segn la importancia estratgica que tenga el centro o departamento de informtica.
6.3.1.1 Organizacin Funcional

Esta organizacin rene, en un departamento a todos los que se dedican a una actividad o varias relacionadas, que se llaman funciones. Por ejemplo, un centro de informtica dividido por funciones puede tener la siguiente estructura:
Compaa XYZ
Estructura Organizacional Centro de Informtica Gerente de Informtica
Seccin de Soporte a Usuarios
Seccin de Desarrollo de Sistemas
Seccin de Admon. de Sistemas y Operaciones
Seccin de Comunicaciones
Es probable que la organizacin funcional sea la manera ms lgica y bsica de departamentalizacin. Una ventaja importante es que facilita mucho la supervisin, pues cada gerente debe ser experto solo en una gama limitada de habilidades. Adems la estructura funcional facilita el movimiento de las habilidades especializadas para usarlas en los puntos donde ms se necesitan, aprovechando con eficiencia los recursos especializados. Por supuesto, esta forma de organizacin conlleva sus desventajas, entre ellas: a. Es ms difcil determinar la responsabilidad y juzgar los resultados de un proyecto informtico. b. La coordinacin de funciones de los miembros de la organizacin se puede convertir en un serio problema para los gerentes de informtica.
6.3.1.2 Organizacin por Producto/Servicio/Regin

Rene en una unidad de trabajo a todos los que participan en la produccin e implantacin de una solucin informtica, a todos los que estn en una cierta zona geogrfica o a todos los que tratan con un cierto tipo de cliente(usuario). En un centro de informtica esta organizacin podra ser as:
29/86
Manual Terico
Compaa XYZ
Estructura Organizacional Centro de Informtica Gerente de Informtica
Equipo de Proyecto Sistema Administrativo
Equipo de Proyecto Sistema de Produccin/ Ventas
Equipo de Proyecto de Sistema de Informacin Estadstica
Equipo de Proyecto de E-Business/Ecommerce
La mayor parte de las empresas grandes, con grandes sistemas, tienen este tipo de organizacin. Dentro de cada una de esas unidades hay una estructura funcional como la definida anteriormente. Cuando la departamentalizacin de una empresa se torna demasiado compleja para coordinar la estructura funcional, la gerencia de informtica crear estas divisiones semiautnomas. En cada divisin los gerentes y empleados disean, desarrollan e implantan sus propios servicios o productos.
6.3.1.3 Organizacin Matricial

Es un producto hbrido que trata de combinar los beneficios de los dos tipos de diseo a la vez que pretende evitar sus inconvenientes. Una organizacin de tipo matricial cuenta con los dos tipos de estructura al mismo tiempo. Los empleados tienen, de hecho, dos jefes, es decir, trabajan con dos cadenas de mando. Una cadena de mando corresponde a las funciones y otra a los proyectos especficos (divisiones) a las que est asignado. La diferencia radica en el tipo de autoridad que ejerce cada gerente. En estas estructuras el gerente funcional ejerce autoridad en cuanto a la definicin de polticas, condiciones de trabajo, estndares y normas en general que regulan el trabajo del empleado. Por su parte, el gerente de divisin/producto, tiene la misin fundamental de asegurarse que los productos y servicios se estn produciendo, acorde con los estndares establecidos por la gerencia funcional. La desventaja es que no todo mundo se adapta bien al sistema matricial . Los miembros del equipo, para ser efectivos, deben contar adems con buenas habilidades interpersonales y ser flexibles y cooperativos. Adems la moral se puede ver afectada de manera negativa cuando el personal se reordena, una vez terminado un proyecto, y se inician otros nuevos. Por ltimo, si las jerarquas no estn establecidas con solidez y comunicadas con eficiencia, existe el peligro, en opinin de algunos analistas, de que las directrices contradictorias y las responsabilidades mal definidas aten las manos de los gerentes. 30/86
Manual Terico
7 ORGANIZACIN: EQUIPOS DE TRABAJO EN CENTROS DE INFORMTICA

7.1 DEFINICIN
Un equipo es un nmero de personas pequeo con habilidades complementarias, que estn comprometidas en un propsito, objetivos de rendimiento y con un enfoque comn, en el que todos sean responsables ante todos. Si las mentes trabajan juntas, a veces el total puede ser mayor que la suma de las partes. Si las mentes estn en desacuerdo el resultado puede ser menor. Un equipo existe siempre que dos cabezas juntas funcionan mejor que cada una por separado.
7.2 GRUPOS Y EQUIPOS

No todos los grupos son equipos. Algunos proyectos se pueden llevar a cabo por un grupo de personas que cooperan pero que no forman un equipo. Algunos proyectos no llegan al nivel de compromiso que supone un equipo. Adems del compromiso los miembros de un equipo unido y bien conformado trabajan duro, se divierten con su trabajo y emplean gran parte de su tiempo centrndose en los objetivos del proyecto.
7.3 CREACIN DE UN EQUIPO DE ALTO RENDIMIENTO

Un equipo con gran cohesin y alto rendimiento tiene las siguientes caractersticas: Alta visin u objetivo compartidos: Una visin comn crea confianza entre los miembros del equipo, porque todos trabajan para llegar al mismo objetivo. Tambin ayuda a que el equipo se mantenga concentrado y a evitar que se pierda tiempo debido a errores. La visin tambin necesita ser elevada para que surta un efecto de motivacin. El equipo necesita que se le presente un desafo, una misin. Sentido de identidad del equipo: A medida que los miembros del equipo trabajan juntos hacia su visin comienzan a percibir una sensacin de identidad del equipo. Las compaas inteligentes refuerzan el sentido de identidad del equipo proporcionando camisetas del equipo, block de notas, tasas, o cualquier implemento que identifique al equipo como una entidad legtima. La satisfaccin proviene de los logros del equipo. Los objetivos comunes se consideran ms importantes que los personales. Tienen la oportunidad de conseguir con el equipo algo que individualmente no conseguiran. Estructura dirigida por resultados: Los equipos se pueden estructurar de forma que se obtenga una salida ptima, o se pueden estructurar de forma que sea casi imposible que produzcan algo. Para los proyectos informticos se necesita estructura el equipo teniendo en cuenta la mxima velocidad de desarrollo. Las cuatro caractersticas fundamentales de una estructura de equipo dirigida por resultados son: 31/86
Manual Terico
a. Las tareas deben ser claras y todos deben ser responsables de su trabajo en todo momento. b. El equipo debe tener un sistema de comunicacin efectivo que admita el libre flujo de informacin entre los miembros del equipo. c. El equipo debe tener algn medio de control sobre el rendimiento individual y la realimentacin. Debe saber a quin recompensar, quien necesita desarrollarse individualmente y quin puede asumir mayor responsabilidad en el futuro. d. Las decisiones se deben tomar, si es posible, basndose en hechos ms que en opiniones subjetivas. Miembros competentes del equipo: Suele escogerse a los miembros del equipo por las razones equivocadas. Por ejemplo: porque tienen un cierto inters en el proyecto, porque cobran poco o, lo ms normal, porque simplemente estn disponibles. Los miembros del equipo deben elegirse comprobando quienes poseen estas tres clases de aptitudes: a. Habilidades tcnicas especficas: rea de aplicacin, plataforma, metodologas y herramientas informticas (lenguajes de programacin, sistemas operativos, etc.). b. Un fuerte deseo de colaborar. c. Habilidades de colaboracin especficas que son necesarias para trabajar eficientemente con otros. Compromiso con el equipo: Las caractersticas de visin, reto e identidad del equipo se funden en el rea del compromiso. En un equipo efectivo, sus miembros se comprometen con el equipo. Hacen sacrificios personales por el equipo que no haran para las grandes organizaciones. Confianza mutua: La confianza consta de cuatro componentes: a. b. c. d. Honestidad Franqueza Firmeza Respeto
Si se infringe uno de estos elementos, aunque sea solo una vez, la confianza se rompe. Interdependencia entre los miembros: Los miembros del equipo confan en la fuerza individual de los dems, y hacen todo lo que sea mejor para el equipo. Todos sienten que tienen posibilidades de contribuir y que su contribucin es importante. Todos participan en las decisiones. Comunicacin efectiva: Los miembros de los equipos unidos estn al corriente constantemente de lo que les sucede a los dems. Tienen cuidado de comprobar que todos les entienden cuando hablan, y su comunicacin se beneficia del hecho de que muestran una visin comn y un sentido de identidad. Sensacin de autonoma: Una de las razones por las que los proyectos, o los equipos de trabajo, funciona tan bien, es porque se les da a los miembros la 32/86
Manual Terico
oportunidad de hacer lo que crean conveniente. Pueden trabajar sin interferencias. El equipo puede cometer algunos errores, pero las ventajas en motivacin compensarn los errores. Sentido de refuerzo: La organizacin no se limita a permitirles hacer todo lo que piensan que es correcto, sino que les apoya a la hora de llevarlo a cabo. Un caso comn en el que los equipos no reciben un refuerzo positivo se produce cuando no se compran elementos menores necesarios para ser efectivos. Tamao reducido del equipo: Si se puede mantener un equipo unido a lo largo de varios proyectos, se puede aumentar el tamao del equipo, siempre que sus miembros compartan una cultura profundamente arraigada. Alto nivel de disfrute: No todo equipo que se divierte es productivo, pero la mayora de los equipos productivos son divertidos. A los informticos les gusta ser productivos. Adems, las personas, por naturaleza emplean ms tiempo en hacer cosas que les divierten que las que no les divierten.
7.4 CAUSAS DE FALLO DE LOS EQUIPOS

Algunas de las razones por las que fallan los equipos son: Falta de visin comn: Las organicaciones impiden a veces la cohesin de los equipos echando abajo sus ideas. Cuando la idea se viene abajo, el equipo tambin. Falta de identidad: Sin uno o ms miembros estuvieran trabajando de forma individual en lugar de formar parte del equipo. Falta de reconocimiento: Algunas veces los miembros de un equipo ponen su corazn y su alma solo para encontrar que su esfuerzo no se aprecia. Barreras de la productividad: Las personas no pueden sobrevivir si el entorno no contiene suficiente oxgeno, y los equipos no pueden sobrevivir si se les impide realizar su trabajo. Comunicacin ineficiente: Las barreras de la comunicacin incluyen: falta de correo electrnico, insuficiencia de salas de conferencias y separacin de los miembros del equipo en lugares geogrficamente dispersos. Falta de confianza: Una razn por la que normalmente los equipos no se conforman dentro de las organizaciones burocrticas es porque las organizaciones estn basadas en la falta de confianza. Los gerentes que prestan ms atencin a los detalles de administracin del equipo que a los resultados que consiguen, demuestran falta de confianza. Personas problemticas: Estas personas son fciles de identificar, solo hay que evaluar las siguientes caractersticas y determinar si la persona en cuestin las tiene: a. Ocultan su ignorancia en vez de intentar aprender de sus compaeros de equipo. b. Tienen un deseo excesivo de intimidad c. Son reservados
33/86
Manual Terico
d. Se quejan de las decisiones del equipo y continan revisando antiguas discusiones despus de que el equipo las ha terminado. e. Los otros miembros del equipo se ren o se quejan de la misma persona. f. No se ponen a trabajar en las actividades del equipo. No hay que tener temor de echar a una persona que no tiene mayor inters en el equipo ya que: a. Es raro ver un problema importante provocado por falta de experiencia. Es casi siempre cuestin de actitud, y las actitudes son difciles de cambiar. b. Cuanto ms tiempo se mantiene a una persona problemtica, esta persona adquirir ms legitimidad a travs de contactos casuales con otros grupos y directivos, un crecimiento de la base de cdigo que la persona tiene que mantener, etc.
34/86
Manual Terico
8 ORGANIZACIN: ESTRUCTURA DE EQUIPOS DE TRABAJO EN CENTROS DE INFORMTICA

8.1 INTRODUCCIN
Aunque se tenga personal formado, motivado y acostumbrado a trabajar duro, una estructura errnea del equipo puede minar el esfuerzo en lugar de lograr un desempeo exitoso. Una mala estructura del equipo puede aumentar el tiempo para desarrollar un proyecto, reducir la calidad, deteriorar la moral, incrementar los cambios de personal y llevar a la cancelacin de proyectos.
8.2 TIPOS DE EQUIPOS

8.2.1 CLASIFICANDO SEGN EL CRITERIO DE OBJETIVO GENERAL
La primera consideracin al organizar un equipo es determinar el objetivo general del mismo. Los objetivos generales de un equipo en el rea de informtica son: Resolucin de Problemas Creatividad Ejecucin tctica Una vez identificado el objetivo ms general del equipo, se prepara una estructura de equipo que haga hincapi en la caracterstica ms importante para este tipo de equipo. Equipo para resolucin de problemas: Un grupo de programadores intentando diagnosticar un nuevo defecto del software formaran un equipo de este tipo. Los miembros de este equipo deben ser: de confianza, inteligentes y pragmticos. Este tipo de grupo est ms ocupado en cuestiones muy especficas. Equipo para creatividad: El objetivo de un equipo de este tipo es explorar posibilidades y alternativas. Un grupo de programadores que est sentando nuevas bases en aplicaciones multimedia sera un tipo de equipo para creatividad. Los miembros de este equipo necesitan: estar motivados, ser independientes, creativos y persistentes. Equipo para ejecucin tctica: Un equipo de este tipo se centra en la ejecucin de un plan bien definido. Un equipo de software trabajando sobre una actualizacin bien definida de un producto, en la que el propsito no es definir nuevas bases, sino poner caractersticas bien conocidas en manos de los usuarios tan pronto como sea posible, es un buen ejemplo de este tipo de equipo. Los miembros de un equipo para ejecucin tctica necesitan tener: sentido de la urgencia de su misin, estar ms interesados en la accin que en la intelectualizacin esotrica y ser leales al equipo. El siguiente cuadro resume los objetivos de los equipos y las estructuras de equipo que soportan dichos objetivos:
35/86
Manual Terico
Objetivo General
Resolucin de Problemas
Caracterstica Dominante Ejemplo tpico en un centro de informtica nfasis en el Proyecto Confianza Mantenimiento corrector en sistemas en marcha Centrado en cuestiones especficas
Creatividad
Autonoma Desarrollo de un nuevo producto Explorar posibilidades y alternativas
Ejecucin Tctica
Claridad Desarrollo de una actualizacin de un producto Tareas muy centradas con funciones claras. Marcadas por un claro xito o fracaso Cascada, cascada modificada, entrega por etapas, diso para planificacin, diseo para herramientas Leales, comprometidos, dispuestos a la accin, con sentido de urgencia, responsables Equipo de negocios, equipo con programador jefe, equipo de prestaciones, equipo SWAT, equipo profesional de atletismo
Modelos apropiados del ciclo de vida
Codificar y corregir, espiral
Criterios de seleccin del equipo
Inteligentes, desenvueltos, sensibles, alta INTEGRIDAD Equipo de negocios, equipo de bsqueda y rescate, equipo SWAT
Modelos apropiados equipo de Software
de
Prototipado evolutivo, entrega evolutiva, espiral, diseo para planificacin, disemo para herramientas Cerebrales, independientes, pensadores con iniciativa, tenaces Equipo de negocios, equipo con programador en jefe, equipo en la sombra, equipo de prestaciones, equipo de teatro
8.2.2 CARACTERSTICAS ADICIONALES PARA EL DISEO DE EQUIPOS

Hay cuatro caractersticas de la estructura de equipos que parecen caracterizar todos los tipos de equipos que funcionan con efectividad: Papeles y responsabilidades claras: En un equipo de alto rendimiento, todo el mundo cuenta y cada uno sabe lo que debe hacer. Monitorizacin del rendimiento individual y retroalimentacin: La otra cara de las responsabilidades consiste en que los miembros del equipo necesitan saber si estn trabajando de acuerdo a las expectativas del equipo. El equipo necesita disponer de mecanismos para que sus miembros sepan en qu aspectos tienen un rendimiento aceptable y cuales son los que necesitan mejorar. Comunicacin efectiva: La informacin debe ser fcil de consultar. Reservar la informacin es malo para la moral de un equipo. Toda la informacin relevante debe estar disponible para todos. Adems los miembros del equipo necesitan tener oportunidad de plantear cuestiones que no estn en la agenda formal del grupo. Y debe mantenerse una historia de las cuestiones planteadas y las decisiones tomadas. Toma de decisiones basada en hechos: Los juicios subjetivos pueden minar la moral de un equipo. Los miembros del equipo necesitan comprender las bases de todas las decisiones que les afectan.
36/86
Manual Terico
8.3 MODELOS DE EQUIPO

8.3.1 EQUIPO DE NEGOCIOS
Es la estructura ms comn: un grupo de iguales encabezado por un jefe tcnico. Aparte del jefe tcnico todos los miembros del equipo tienen el mismo estatus diferencindose en su mbito de experiencia: bases de datos, grficos, interfases de usuario, redes, comunicaciones o lenguajes de programacin, por ejemplo. Generalmente, el jefe es elegido por su experiencia tcnica y no por su eficacia como gestor. Habitualmente el jefe es responsable de tomar decisiones finales sobre cuestiones tcnicas. Este modelo funciona bien con grupos pequeos, que llevan juntos mucho tiempo y que pueden estructurar sus relaciones con el tiempo. Es adaptable a todos los tipos de equipo (resolucin de problemas, creatividad y ejecucin tcnica), pero casi siempre es posible encontrar un modelo mejor para cada situacin particular.
8.3.2 EQUIPO CON PROGRAMADOR JEFE

Ms orientado a los proyectos de software. Saca partido del hecho de que algunos tcnicos son 10 veces ms productivos que otros. La estrella del equipo es el programador jefe. Esta persona hace la especificacin completa, todo el diseo, escribe la mayor parte de los programas y es responsable final de prcticamente todas las decisiones del proyecto. El resto de los miembros del equipo son libres de especializarse, crendose algunos papeles como los siguientes: Programador de reserva. El otro yo del programador jefe. Crtico, ayudante de investigacin y contacto tcnico con los grupos externos (usuarios). Administrador. Gestiona cuestiones administrativas, como dinero, personal, espacio y equipos. Herrero. Responsable de crear herramientas solicitadas por el programador jefe (utileras, macros, programas especiales, etc.). Abogado del lenguaje. Responde preguntas tericas complicadas acerca de las herramientas que se estn utilizando. Esta estructura es adecuada para algunos proyectos de creatividad ya que teniendo un cerebro al frente se mantiene la integridad conceptual de la solucin buscada, y para proyectos de ejecucin tctica en los que el programador jefe resulta ser una especie de dictador que implante las condiciones ms adecuadas para culminar con xito el proyecto. Sin embargo, es un modelo difcil de implantar ya que requiere una superestrella que desea trabajar excepcionalmente duro, que apenas tiene otros intereses y que est dispuesto a trabajar jornada doble. La mayora de las organizaciones carece de elementos como este.
37/86
Manual Terico
8.3.3 EQUIPO EN LA SOMBRA

Aglutina un grupo de tcnicos creativos y con talento, se les pone en una situacin en la que son liberados de restricciones burocrticas y se les da la libertad de desarrollar e innovar. La directiva no desea saber detalles de cmo trabajan, solo quieren saber que lo estn haciendo. Este modelo tiene la ventaja de crear una sensacin de propiedad y compromiso. El efecto motivacional puede ser impresionante. Tiene la desventaja de no ofrecer mucha visibilidad del progreso del equipo. Los equipos en la sombra son adecuados para proyectos exploratorios en los que la creatividad es absolutamente importante. Un equipo de estos no es una estructura rpida cuando se necesita resolver un problema claramente definido, o cuando se necesita ejecutar un plan bien entendido.
8.3.4 EQUIPO DE PRESTACIONES

El desarrollo, el control de calidad, la documentacin, la gestin del programa y el marketing estn organizados con las estructuras jerrquicas tradicionales de responsabilidad. Los analistas informan al jefe de analistas, los programadores al jefe de programadores, los tcnicos de hardware y software informan al responsable de soporte tcnico, etc. El equipo de prestaciones se hace responsable sobre la parte del producto que le corresponde. Los equipos de prestaciones presentan ventajas de potenciacin, facilidad de seguimiento y equilibrio. Los equipos de prestaciones resultan adecuados para proyectos de resolucin de problemas, ya que ofrecen el refuerzo y la facilidad de seguimiento necesarios para resolver las cuestiones planteadas de forma expedita.
8.3.5 EQUIPO DE BSQUEDA Y RESCATE

Se centra en resolver un problema especfico. Necesita conocer ntimamente el terreno donde busca, necesita estar listo para actuar en el momento en que se le requiera. Combina un conocimiento especializado de herramientas de hardware y software especficas con un conocimiento igualmente especializado del entorno de la empresa. Debe tener la capacidad de responder inmediatamente. Obviamente es el ms apropiado para equipos orientados a la resolucin de problemas. Est demasiado dirigido a problemas bsicos como para soportar mucha creatividad, y est demasiado orientado a corto plazo como para soportar la ejecucin tctica.
8.3.6 EQUIPO SWAT

Esta basado en equipos policacos o militares SWAT significa armas y tcticas especiales (special weapons and tactics). En este tipo de equipo, cada miembro est entrenado especialmente en un tema. La idea bsica de este equipo es reunir un grupo de personas con slida formacin en una herramienta o mtodo determinado, y dedicarlas a un problema que se adapta perfectamente a ser resuelto con esa herramienta o mtodo.
38/86
Manual Terico
Dicha herramienta o mtodo puede ser: un lenguaje de programacin (Delphi, PowerBuilder, Visual Basic, etc.), un DBMS (Oracle, Informix, Parados, etc), un sistema operativo (NT, Unix, etc.) o cualquier otra herramienta informtica. Estos grupos son generalmente permanentes. Son muy adecuados para proyectos de ejecucin tctica, ya que su trabajo no consiste en ser creativos, sino en implementar una solucin dentro de los lmites de una herramienta o metodologa que conocen a la perfeccin. Tambin funcionan para grupos de solucin de problemas.
8.3.7 EQUIPO DEPORTIVO

El presidente de un equipo deportivo gestiona las decisiones entre bastidores. Decisiones importantes, estratgicamente hablando, pero no es l quien patea la pelota. Los hinchas no van a ver al presidente, ven a los jugadores. De forma similar el responsable del software es importante, pero no por sus capacidades de desarrollo. El papel del responsable es despejar el camino de obstculos y permitir que los desarrolladores trabajen en forma eficiente. Los desarrolladores podran crear un producto sin el responsable, pero el responsable no hara nada sin los desarrolladores. Los equipos deportivos tienen papeles altamente especializados. Un pitcher no dice Ya me cans de ser pitcher, ahora quiero se catcher. En los equipos de software que adoptan este modelo sucede lo mismo. Este modelo se aplica mejor a los proyectos de ejecucin tctica, que hacen nfasis en los papeles altamente especializados.
8.3.8 EQUIPO DE TEATRO

Este modelo se caracteriza por una fuerte direccin y una gran negociacin de los papeles del proyecto. El papel central del proyecto es ocupado por el director quien mantiene una visin del producto y asigna a la gente responsabilidades en reas individuales. Los participantes pueden adaptar sus papeles como les dicten sus propios instintos. Pero no pueden llevar demasiado lejos sus propias ideas, evitando colisionar con la visin del director. La visin del director debe prevalecer para la buena marcha del proyecto. En el modelo de teatro, no se asigna a las personas al proyecto. Se participa en una audicin y se acepta un papel. Antes de aceptar el papel hay una larga negociacin. Este modelo es particularmente apropiado para equipos informticos dominados por fuertes personalidades. Se aplica a proyectos de creatividad en los que se necesita, sin embargo, mantener un control algo estricto. Este modelo se aplica en proyectos multimedia. Antes los proyectos de software requeran varios desarrolladores de software, ahora tienen que integrar las contribuciones de diseadores grficos, escritores, productores de video, editores, ilustradores y varios desarrolladores de software.
39/86
Manual Terico
9 MOTIVACIN
9.1 INTRODUCCIN
El desarrollo de trabajo en el rea de informtica, particularmente proyectos, requiere de alcanzar un equilibrio en el manejo de cuatro factores: personas, proceso, producto y tecnologa. Entre ellas las personas son las que ofrecen la mayor posibilidad de mejorar el tiempo y la calidad del proyecto. La motivacin es, indudablemente, la mayor influencia individual sobre como trabajan las personas. La motivacin es un factor intangible y, como tal, es difcil de cuantificar.
9.2 MOTIVACIONES TPICAS DEL INFORMTICO

Personas diferentes se motivan con factores diferentes, y los informticos no se motivan siempre con los mismos factores que sus directivos ni con los mismos factores que las personas en general. Comparados con las personas en general, los informticos estn mucho ms motivados por la posibilidad de superacin, su vida personal, la oportunidad de ejercer supervisin tcnica y las relaciones interpersonales con sus semejantes. Los informticos, a diferencia de las personas en general, estn menos motivados por su posicin social, relaciones interpersonales con los subordinados, responsabilidad y reconocimiento. Comparados con sus directivos, los informticos estn un poco ms motivados por la posibilidad de superacin, vida personal y oportunidad de supervisin tcnica. Los informticos estn mucho menos motivados por la responsabilidad, reconocimiento y relaciones interpersonales con los subordinados. Si Ud. Es directivo e intenta motivar a los informticos de igual forma que le gustara que le motivaran a Ud., realmente fallar. Si se desea motivar a los informticos, debe hacerse hincapi en los estmulos tcnicos, autonoma, posibilidad de aprender, utilizar nuevas tcnicas y correr en la planificacin (adems de respetar sus vidas familiares). El siguiente cuadro no muestra una verdad absoluta sino una tendencia que puede observarse en la comparacin de la jerarqua de motivaciones para informticos, directivos de los informticos y personas en general: INFORMTICOS
1) REALIZACIN 2) POSIBILIDAD DE SUPERACIN 3) EL PROPIO TRABAJO 4) VIDA PERSONAL 5) OPORTUNIDAD DE
SUPERVISIN TCNICA
DIRECTIVOS DE INFORMTICOS
1) RESPONSABILIDAD 2) REALIZACIN 3) EL PROPIO TRABAJO 4) RECONOCIMIENTO 5) POSIBILIDAD DE SUPERACIN 6) RELACIONES
INTERPERSONALES, SUBORDINADOS
PERSONAS EN GENERAL
1) REALIZACIN 2) RECONOCIMIENTO 3) EL PROPIO TRABAJO 4) RESPONSABILIDAD 5) ASCENSO 6) SALARIO 7) POSIBILIDAD DE SUPERACIN 8) RELACIONES INTERPERSONALES,
SUBORDINADOS
6) ASCENSO 7) RELACIONES
INTERPERSONALES, IGUAL NIVEL
7) RELACIONES
INTERPERSONALES, IGUAL
40/86
Manual Terico
INFORMTICOS
8) RECONOCIMIENTO 9) SALARIO 10) RESPONSABILIDAD 11) RELACIONES
INTERPERSONALES, SUPERIORES 12) SEGURIDAD EN EL TRABAJO 13) RELACIONES INTERPERSONALES, SUBORDINADOS
DIRECTIVOS DE INFORMTICOS
NIVEL
PERSONAS EN GENERAL
9) POSICIN SOCIAL 10) RELACIONES INTERPERSONALES, SUPERIORES 11) RELACIONES INTERPERSONALES, IGUAL
NIVEL
8) ASCENSO 9) SAL ARIO 10) RELACIONES

INTERPERSONALES, SUPERIORES 11) POLTICAS DE LA COMPAA Y DE ADMINISTRACIN
12) OPORTUNIDAD DE
SUPERVISIN TCNIC A
12) SEGURIDAD EN EL TRABAJO 13) OPORTUNIDAD DE

SUPERVISIN TCNICA
13) POLTICAS DE L A COMPAA Y

DE ADMINISTRACIN
14) POLTICAS DE LA COMPA A Y

DE ADMINISTRACIN
15) CONDICIONES DE TRABAJO 16) POSICIN SOCIAL
14) POSICIN SOCIAL 15) VIDA PERSONAL 16) CONDICIONES DE TRABAJO
14) CONDICIONES DE TRABAJO 15) VIDA PERSONAL 16) SEGURIDAD EN EL TRABAJO
Estos factores, obviamente, pueden variar. Por ejemplo, la seguridad en el trabajo puede tomar mayor relevancia en sociedades en las que la amenaza de desempleo es mayor.
9.3 CINCO FACTORES PRINCIPALES DE MOTIVACIN

9.3.1 REALIZACIN
A los informticos les gusta trabajar. La mejor forma de motivarlos es darles un entorno que les facilite centrarse en lo que ms les gusta hacer. Hay ciertos subfactores que promueven la realizacin:
9.3.1.1 Propiedad
Las personas trabajan ms duro para lograr sus propios objetivos que para alcanzar los de otras personas. Hay que procurar que los informticos creen sus propias planificaciones, que tomen propiedad de sus planificaciones, asegurando as su adhesin.
9.3.1.2 Definicin de objetivos

Si se establece un objetivo del tiempo de desarrollo trabajarn realmente los informticos para conseguirlo? Si conocen como calza ese objetivo con otros, y si el conjunto de objetivos es razonable, la respuesta es S,. Los informticos no pueden responder a objetivos que cambian diariamente o que son imposibles de cumplir en conjunto. Definir demasiados objetivos al mismo tiempo es un problema comn, diluyndose el tiempo en demasiadas prioridades. Para obtener mejores resultados, se selecciona un objetivo y se deja claro que ese es el ms importante.
9.3.2 POSIBILIDAD DE SUPERACIN

Uno de los aspectos ms excitantes de ser informtico es trabajar en un campo que est cambiando constantemente. Cada da hay que aprender algo para 41/86
Manual Terico
estar actualizado, y la mitad de lo que hoy se necesita para trabajar ser anticuado dentro de tres aos. Una organizacin puede influir en esta motivacin dando a los informticos las oportunidades de crecer en sus proyectos. Esto requiere alinear los objetivos de crecimiento de la organizacin con los objetivos de superacin individuales. Una organizacin puede mostrar inters en el progreso profesional de sus informticos de cualquiera de estas formas: Financiando cursos de desarrollo profesional Dando tiempo para asistir a cursos o clases Financiando la compra de libros profesionales Asignando los informticos a proyectos que aumentaran su experiencia Asignando un tutor a cada informtico nuevo Evitando presiones excesivas en la planificacin
9.3.3 EL TRABAJO EN S
Cinco dimensiones del trabajo en s contribuyen a la motivacin. Las tres primeras contribuyen a ver el significado que las personas encuentran en su trabajo: La diversidad de tcnicas: Es el grado en que el trabajo requiere que ejercite una serie de tcnicas, de forma que pueda evitar el aburrimiento y la fatiga. La identidad de la tarea: Es el grado en que su trabajo requiere que cubra una parte completa, identificable de su trabajo. Que se sienta que la participacin es importante. La importancia de las tareas: es el grado en el que el trabajo del informtico afecta a otras personas y contribuye al bienestar social. La cuata caracterstica contribuye al sentimiento de responsabilidad sobre el resultado del trabajo: Autonoma: Es el grado en el que el informtico tiene control sobre los medios y mtodos que utiliza para realizar su trabajo, el sentimiento de ser su propio jefe, y el margen de maniobra del que dispone. La quinta y ltima caracterstica contribuye al conocimiento de las personas sobre el resultado de sus actividades: Retroalimentacin del trabajo: Es el grado en que la realizacin del trabajo en s proporciona informacin clara y directa sobre cmo es de efectivo. El desarrollo de software, por ejemplo proporciona una gran retroalimentacin; es posible ver si el programa funciona cuando se ejecuta. Finalmente, es importante que la organizacin propicie un ambiente que de la oportunidad de centrarse en el trabajo en s.
9.3.4 VIDA PERSONAL

La vida personal es el cuarto factor en importancia para la motivacin de un informtico. La prioridad que tiene este factor para un directivo es diferente de la que tiene para un informtico y es, junto a la responsabilidad uno de los factores ms difciles de comprender para un directivo. Un resultado de esa disparidad es que los directivos premian en ocasiones a sus mejores empleados asignndoles proyectos ms complejos y de mayor presin. 42/86
Manual Terico
Para lo directivos, la responsabilidad extra sera un placer, y la disminucin de la vida personal no importara mucho. Para el informtico esto sera ms bien un castigo. Una empresa no puede hacer mucho para explotar este factor motivacional, excepto por: Planificar los proyectos de una manera realista, respetar los perodos de vacaciones y fiestas, y siendo susceptibles a peticiones ocasionales de tiempo libre durante el trabajo.
9.3.5 OPORTUNIDAD DE SUPERVISIN TCNICA

Una oportunidad de este tipo implica que el informtico ha alcanzado un nivel de experiencia tcnica suficiente para dirigir a otros. Para un directivo, una oportunidad de supervisin tcnica probablemente representara un paso atrs; el directivo ya est supervisando a otros, y, de hecho, est contento de no tener que supervisar los detalles tcnicos.
9.4 USO DE OTROS FACTORES DE MOTIVACIN

Aparte de los cinco factores principales de motivacin, hay otros factores que se pueden utilizar para motivar al equipo:
9.4.1 PREMIOS E INCENTIVOS

Cenas de reconocimiento con ejecutivos de la compaa, pagos extraordinarios, gratificaciones de vacaciones, obsequios de agradecimiento, cursos especiales (fuera del lugar de trabajo) y ceremonias de premios, entre otros. Los informticos se cansan de trabajar para compaas desagradecidas, por tanto, los premios son una motivacin importante a largo plazo. Es importante dar un premio como un reconocimiento ms que como un incentivo. El trabajo en s debe ser el motivador ms importante, as que cuando ms nfasis se de al premio como un incentivo, se pierde ms la motivacin potencial a largo plazo y permanente de la satisfaccin al trabajo.
9.4.2 PROYECTOS PILOTO

Uno de los ms famosos experimentos sobre motivacin y productividad se realiz entre 1927 y 1932, en la empresa Hawthorne Works of the Western Electric Company en Chicago. Su objetivo era determinar el efecto de la iluminacin en la productividad. Primero aumentaron la luz y la productividad subi. Luego bajaron las luces y la productividad subi nuevamente. Finalmente dejaron las luces constantes y la productividad volvi a subir. Conclusin: Bueno, obviamente la iluminacin no tena nada que ver con los niveles de luz. Pero si se descubri que el simple hecho de haber hecho el experimento haba aumentado la productividad. Este fenmeno se ha conocido desde entonces como el efecto Hawthorne, el cual ensea que es motivante desarrollar cada proyecto como un experimento, como un proyecto piloto. Hay que intentar una nueva metodologa en cada proyecto nuevo y asegurarse que el equipo sepa y entienda que es un proyecto piloto. 43/86
Manual Terico
9.5 DESTRUCTORES DE LA MORAL

9.5.1 AUSENCIA DE FACTORES DE HIGIENE
Los factores de higiene son las condiciones bsicas que un trabajador necesita para trabajar efectivamente. En el mejor caso, los factores de higiene no crean descontento. En el peor caso, su ausencia crea descontento. Estos son solo algunos de los factores de higiene que condicionan el desempeo de los informticos: Condiciones ambientales apropiadas. Espacio adecuado Intimidad suficiente Tranquilidad para poder concentrarse Acceso a equipo de oficina Acceso no restringido a las computadora Equipo informtico actualizado Reparacin inmediata o casi inmediata de equipo en mal estado. Disponibilidad de infraestructura de comunicaciones Hardware adecuado Manuales de referencia y publicaciones pertinentes Libros de consulta y ayudas de referencia en lnea Formacin mnima en software, metodologa y herramientas. Copias legales del software. Libertad para escoger el horario de trabajo.
9.5.2 MANIPULACIN DE LA DIRECTIVA

Los informticos son susceptibles a ser manipulados por los directivos, a pesar de que su deseo es que se les trate de forma sincera. Algunos directivos intentan manipular a los informticos estableciendo fechas lmite falsas, y la mayora de los informticos pueden oler una fecha lmite falsa a 100 metros. Los directivos que se esfuerzan por no proporcionar detalles sobre porqu una fecha lmite es importante, debern recordar que sus explicaciones pueden ser desalentadoras para los informticos.
9.5.3 PRESIN EXCESIVA DE LA PLANIFICACIN

Muchas veces los directivos, y las personas de la empresa en general, no ven la cantidad de trabajo que los informticos estn realizando, de forma que piensan que no estn haciendo mucho y que hay que asignarles ms trabajo. En realidad, los informticos suelen estar extremadamente automotivados, trabajan duro, muchas horas, y encontrarse acusados de holgazanear es muy desalentador.
9.5.4 PARTICIPACIN DE DIRECTIVOS SIN PREPARACIN TCNICA

Los informticos pueden ser motivados por directivos tcnicamente incapaces, siempre que estos reconozcan que no tienen preparacin tcnica y que limiten el control del proyecto a decisiones no tcnicas. Si intentan meterse en decisiones tcnicas que no comprenden, se convertirn en el blanco de las bromas del 44/86
Manual Terico
equipo de desarrollo, y la mayora de las personas no pueden ser motivadas por alguien a quien no respetan.
9.5.5 NO INVOLUCRAR A LOS INFORMTICOS EN DECISIONES QUE LES AFECTAN

Tales como: Compromiso con nuevas planificaciones Modificaciones a las caractersticas de lo productos informticos que se desarrollan en el departamento. Contratar a nuevos miembros del equipo Designar a informticos para otras tareas (por breves que sean) ajenas al proyecto en que est trabajando actualmente. Cambiar la oficina Cambiar el hardware Cambiar el software.
9.5.6 BARRERAS A LA PRODUCTIVIDAD

El equipo debe centrarse en el trabajo en vez de salvar las distracciones.
9.5.7 BAJA CALIDAD

Los informticos derivan parte del su amor propio a partir de los productos que desarrollan. Si desarrollan un producto de gran calidad se sienten bien. Si el directivo insiste en disminuir la calidad, para ganar tiempo y recursos, est reduciendo tambin la motivacin por orgullo de propiedad.
45/86
Manual Terico
10 LIDERAZGO
10.1 INTRODUCCIN
La visin que tienen en general los trabajadores de su jefe es que ordenan, mandan, deciden, dicen lo que se debe hacer, imponen criterios, distribuyen el trabajo, controlan y supervisan las tareas. La preocupacin de los directivos y mando debera estar centrada en crear una imagen tal, que sus subordinados lo catalogaran como un colaborador ms, orientador, escucha de su gente, generador de confianza; aceptado naturalmente por el grupo, buen comunicador persona que apoye y ayude, que transmite seguridad. El mando que es lder trabaja para ser aceptado por su carisma y su servicio a un equipo que compra ayuda y orientacin para cumplir con las metas prefijadas que se han negociado previamente. El lder es el respaldo del equipo, el que potencia a las personas para que se desarrollen sus inquietudes, iniciativas y creatividad. Fomenta la responsabilidad, el espritu de equipo, el desarrollo personal, y, especialmente, es el artesano de la creacin de un espritu de pertenencia que une a los colaboradores para decidir las medidas a tomar.
10.2 DEFINICIN DE LIDERAZGO

Rallph M. Stogdill, en su resumen de teoras e investigacin del liderazgo, seala que existen casi tantas definiciones del liderazgo como personas que han tratado de definir el concepto. Aqu, se entender el liderazgo gerencial como: el proceso de dirigir las actividades laborales de los miembros de un grupo y de influir en ellas Esta definicin tiene cuatro implicaciones importantes: En primer trmino, el liderazgo involucra a otras personas; a los empleados o seguidores. Los miembros del grupo; dada su voluntad para aceptar las rdenes del lder, ayudan a definir la posicin del lder y permiten que transcurra el proceso del liderazgo; sino hubiera a quien mandar, las cualidades del liderazgo seran irrelevante. En segundo el liderazgo entraa una distribucin desigual del poder entre los lderes y los miembros del grupo. Los miembros del grupo no carecen de poder; pueden dar forma, y de hecho lo hacen, a las actividades del grupo de distintas maneras. Sin embargo, por regla general, el lder tendr ms poder. El tercer aspecto del liderazgo es la capacidad para usar las diferentes formas del poder para influir en la conducta de los seguidores, de diferentes maneras. De hecho algunos lderes han influido en los soldados para que mataran y algunos lderes han influido en los empleados para que hicieran 46/86
Manual Terico
sacrificios personales para provecho de la compaa. El poder para influir nos lleva al cuarto aspecto del liderazgo. El cuarto aspecto es una combinacin de los tres primeros, pero reconoce que el liderazgo es cuestin de valores. James MC Gregor Burns argumenta que el lder que para por alto los componentes morales del liderazgo pasar a la historia como un malandrn o algo peor. El liderazgo moral se refiere a los valores y requiere que se ofrezca a los seguidores suficiente informacin sobre las alternativas para que, cuando llegue el momento de responder a la propuesta del liderazgo de un lder, puedan elegir con inteligencia. Chiavenato, Idalberto (1993), Destaca lo siguiente: Liderazgo es la influencia interpersonal ejercida en una situacin, dirigida a travs del proceso de comunicacin humana a la consecucin de uno o diversos objetivos especficos Cabe sealar que aunque el liderazgo guarda una gran relacin con la administracin y el primero es muy importante para la segunda, el concepto de liderazgo no es igual al de administracin. Warren Bennis, al escribir sobre el liderazgo, a efecto de exagerar la diferencia, ha dicho que la mayor parte de las organizaciones estn sobreadministradas y sublideradas. Una persona quizs sea un gerente eficaz, buen planificador y administrador, justo y organizado, pero carente de las habilidades del lder para motivar. Otras personas tal vez sean lder eficaces, con habilidad para desatar el entusiasmo y la devolucin, pero carente de las habilidades administrativas para canalizar la energa que desatan en otros. Ante los desafos del compromiso dinmico del mundo actual de las organizaciones, muchas de ellas estn apreciando ms a los gerentes que tambin tiene habilidades de lderes. El liderazgo es importante en una institucin, as como en un centro de informtica, porque: Es importante por ser la capacidad de un jefe para guiar y dirigir. Una organizacin puede tener una planeacin adecuada, control y procedimiento de organizacin y no sobrevivir a la falta de un lder apropiado. Es vital para la supervivencia de cualquier negocio u organizacin. Por lo contrario, muchas organizaciones con una planeacin deficiente y malas tcnicas de organizacin y control han sobrevivido debido a la presencia de un liderazgo dinmico.
10.3 TENDENCIAS DEL LIDERAZGO

A medida que cambian las condiciones y las personas, cambian los estilos de liderazgo. Actualmente la gente busca nuevos tipos de lder que le ayuden a lograr sus metas. Histricamente han existido cinco edades del liderazgo (y actualmente estamos en un periodo de transicin hacia la sexta). Ellas son:
47/86
Manual Terico
10.3.1
EDAD DEL LIDERAZGO DE CONQUISTA
Durante este perodo la principal amenaza era la conquista. La gente buscaba el jefe omnipotente; el mandatario desptico y dominante que prometiera a la gente seguridad a cambio de su lealtad y sus impuestos.
10.3.2
EDAD DEL LIDERAZGO COMERCIAL.
A comienzo de la edad industrial, la seguridad ya no era la funcin principal de liderazgo la gente empezaba a buscar aquellos que pudieran indicarle como levantar su nivel de vida.
10.3.3
EDAD DEL LIDERAZGO DE ORGANIZACIN
Se elevaron los estndares de vida y eran ms fciles de alcanzar. La gente comenz a buscar un sitio a donde pertenecer. La medida del liderazgo se convirti en la capacidad de organizarse.
10.3.4
EDAD DEL LIDERAZGO E INNOVACIN
A medida que se incrementa la taza de innovacin, con frecuencia los productos y mtodos se volvan obsoletos antes de salir de la junta de planeacin. Los lderes del momento eran aquellos que eran extremadamente innovadores y podan manejar los problemas de la creciente celeridad de la obsolescencia.
10.3.5
EDAD DEL LIDERAZGO DE LA INFORMACIN
Las tres ltimas edades se han desarrollado extremadamente rpido (empez en la dcada del 20). Se ha hecho evidente que en ninguna compaa puede sobrevivir sin lderes que entiendan o sepan como se maneja la informacin. El lder moderno de la informacin es aquella persona que mejor la procesa, aquella que la interpreta ms inteligentemente y la utiliza en la forma ms moderna y creativa.
10.3.6
LIDERAZGO EN LA NUEVA EDAD
Las caractersticas del liderazgo que describiremos, han permanecido casi constante durante todo el siglo pasado. Pero con la mayor honestidad, no podemos predecir qu habilidades especiales van ha necesitar nuestros lderes en el futuro. Podemos hacer solo conjeturas probables. Los lderes necesitan saber como se utilizan las nuevas tecnologas, van ha necesitar saber como pensar para poder analizar y sintetizar eficazmente la informacin que estn recibiendo, a pesar de la nueva tecnologa, su dedicacin debe seguir enfocada en el individuo. Sabrn que los lderes dirigen gente, no cosas, nmeros o proyectos. Tendrn que ser capaces de suministrar la que la gente quiera con el fin de motivar a quienes estn dirigiendo. Tendrn que desarrolla su capacidad de escuchar para describir lo que la gente desea. Y tendrn que desarrollar su capacidad de proyectar, tanto a corto como a largo plazo, para conservar un margen de competencia.
48/86
Manual Terico
11 COMUNICACIN
11.1 INTRODUCCIN
En este capitulo se analiza el tema de la comunicacin trmino que refleja el inters de transmitir informacin, ideas, sentimientos, pensamientos, conceptos con el fin de que sean entendidos y que tengan la posibilidad de ser aplicados en algo de inters comn o particular.
11.1.1
QU ES LA COMUNICACIN?
La comunicacin es la facultad que tiene el ser vivo de transmitir a otro u otros, informaciones, sentimientos y vivencias. En toda comunicacin tiene que haber un emisor, un mensaje y un receptor.
11.1.2
CMO NOS COMUNICAMOS?
Cuando hablamos de seres vivos, no nos referimos tan slo a los humanos, ya que desde los insectos hasta los grandes mamferos tienen dicha facultad, siendo el hombre el nico ser que puede comunicarse por va oral; mientras que los dems, lo hacen por sonidos (pjaros, cuadrpedos, delfines, ballenas) , friccin de elementos de su cuerpo (grillos, chicharras) o por accin (formacin de vuelo de las abejas, posicin del cuerpo de perros o venados, formacin de nado de los peces). Los mamferos, incluido el hombre, tambin tienen la caracterstica de comunicarse por el tacto (contacto corporal). El proceso de la comunicacin se da a travs de una fuente (informacin), la codificacin, el mensaje, el canal, la decodificacin, el receptor y la retroalimentacin.
11.2 MODELO DE COMUNICACIN

El modelo bsico de comunicacin se compone de los siguientes elementos:
Canal de seales
Fuente
Codificador
Decodificador
Receptor
Mensaje: Qu vamos a decir, a quin se lo vamos a decir, cmo se lo vamos a decir y por qu se lo vamos a decir. En el grfico anterior el mensaje es lo que fluye a travs de las lneas que unen cada uno de los elementos. Fuente: Es el emisor del mensaje. Codificador: Acta sobre el mensaje para convertirlo en seales que acepte el canal. 49/86
Manual Terico
Canal de seales: Transportan las seales codificadas. Decodificador: Acta sobre las seales recibidas para extraer el mensaje en una forma que el receptor pueda utilizar. Receptor: Es el que recibe el mensaje en la forma en que la extrae el decodificador. Alrededor de estos elementos estn las fuentes de ruido que son los hechos externos introducen las seales de interferencia, y que pueden distorsionar el mensaje en cualquiera de sus etapas a partir de que el mensaje sale de la fuente. Una vez recibido y entendido el mensaje, el receptor prepara una respuesta, lo que se conoce como retroalimentacin, en la que l se convierte en la fuente y el emisor se convierte en receptor.
11.3 EL MENSAJE
En toda comunicacin el emisor proyecta un mensaje que es recibido por el receptor. Esta es la triloga de la comunicacin. EMISOR MENSAJE RECEPTOR
En el momento de recibir el mensaje, el receptor inicia un proceso mental por el cual lo decodifica y toma una actitud, sea de reaccin o de asimilacin. Aqu se inicia la gran diferencia entre el animal y el hombre. En ese momento intervienen dos elementos: La Carga Emocional: En todo mensaje, el emisor proyecta una carga emocional, la cual puede ser considerada como simptica, antiptica, aptica o emptica. La percepcin: La gran diferencia entre el animal y el hombre en cuanto a la comunicacin se refiere, es que el ser humano adems de recibir la comunicacin, la percibe y la discierne. Es decir, la asimila y, de acuerdo a los estereotipos, prejuicios y cargas emocionales, crea una actitud frente a ella, despus de lo cual proyecta la respuesta o la retroalimenta. Es la diferencia entre ver y mirar, or y escuchar o tocar y palpar.
11.4 FORMAS DE COMUNICACIN

La comunicacin puede estructurarse de forma: Directa: Es la comunicacin que se desarrolla entre el emisor y el receptor o receptores en forma personal, con o sin ayuda de herramientas. Es llamada tambin comunicacin boca-odo. (Hablar frente a frente, charlas, conferencias, etc. Indirecta: Es aquella donde la comunicacin est basada en una herramienta o instrumento ya que el emisor y el perceptor estn a distancia. La comunicacin indirecta puede ser personal o colectiva. 50/86
Manual Terico
Indirecta/personal: Se desarrolla con la ayuda de una herramienta o instrumento (hablar por telfono, enviar una comunicacin impresa, radioaficionados, correo electrnico, chat por internet, etc.) Indirecta/colectiva: El emisor se comunica con un grupo de receptores ayudado por una herramienta o instrumento (peridicos, televisin, radio, cine, libros, pgina web, videos, etc.). Se le conoce tambin como comunicacin social o de masas.
11.5 TIPOS DE COMUNICACIN

La interrelacin de las personas en una institucin puede ser catalogada as: Formal: Es aquella comunicacin cuyo contenido est referido a aspectos laborales. En general, sta comunicacin utiliza la escritura como medio (Comunicados, memoranda, etc.. La velocidad es lenta debido a que tiene que cumplir todas las formalidades burocrticas. Informal: Es aquel tipo de comunicacin cuyo contenido, a pesar de ser de aspectos laborales, utiliza canales no oficiales. (Reunin alrededor del botelln de agua, encuentros en los pasillos, etc.). Es ms veloz que la formal. Rumores: Es la comunicacin informal que recorre la institucin sin respetar canales y a la velocidad de la luz.
11.6 DIRECCIONES DE LA COMUNICACIN

Existen direcciones en la comunicacin: Vertical Descendente: Puede realizarse de manera descendente que va de los puestos gerenciales a los niveles ms bajos, por ejemplo: el notificar a los operarios de produccin que debido a su esfuerzo la empresa logro grandes utilidades y que se llevaran a la bolsa un bono. Esta noticia, probablemente, se les har llegar a travs de un memorando. Vertical Ascendente: la comunicacin adems se lleva a cabo de manera ascendente, de manera contraria a la anterior, haciendo que las personas de un puesto inferior hagan llegar sus quejas o sugerencias a su jefe inmediato a la direccin general si as lo requiere el caso. En una comunicacin corporativa ptima, debera existir la comunicacin vertical ascendente. Horizontal: Se desarrolla entre los empleados de un mismo nivel corporativo. Muy pocas veces utiliza las canales oficiales y es totalmente informal. Tambin es conocida como comunicacin plana.
11.7 COMO MEJORAR LOS PROCESOS DE COMUNICACIN

La diferencia entre una comunicacin efectiva y una inefectiva puede radicar en el grado en que las partes que se comunican manejen debidamente cuatro aspectos del proceso de la comunicacin: las diferencias de percepcin, las emociones, las incongruencias entre la comunicacin verbal y no verbal y la confianza (o desconfianza) previa de las partes.
51/86
Manual Terico
Diferencias de Percepcin: Es uno de los obstculos ms comunes para la comunicacin. Las personas que tienen diferentes antecedentes, en cuanto a conocimientos y experiencias, suelen percibir el mismo fenmeno desde diferentes perspectivas. Las diferencias de percepcin pueden guardar tambin una estrecha relacin con las diferencias de lenguaje, las diferencias de sexo, etc. Para superar las diferencias de percepcin el mensaje se debe exponer de manera tal que lo puedan entender todos los tipos de receptores. Siempre que se pueda debe obtenerse informacin de los antecedentes de las personas con las que se establecer comunicacin. Hay que completar la situacin desde el punto de vista de la otra parte (empata). Es muy til pedirle al receptor que confirme los puntos bsicos del mensaje. Adems se debe tener la sensibilidad para encontrar diversas alternativas al emitir un mensaje. En ocasiones, incluso u pequeo cambio en la formulacin del mensaje puede tener consecuencias muy positivas. Reacciones emocionales: Ira, amor, odio, defensiva, celos, miedo, vergenza. Todas estas emociones influyen en la manera en que los mensajes son interpretados. Por ejemplo, si estamos en un ambiente donde sentimos la amenaza de perder poder o prestigio, quiz perdamos la capacidad de interpretar correctamente los mensajes y respondamos de forma defensiva o agresiva. La mejor manera de manejar las emociones es aceptarlas como parte del proceso de comunicacin y tratar de entenderlas cuando causan problemas. Si los empleados estn agresivos o molestos hay que hacer que hablen de lo que les preocupa y y prestar atencin a lo que dicen. Comunicacin verbal y no verbal: No solo existe la comunicacin oral y escrita. Debemos poner especial cuidado en la influencia de factores no verbales, tales como: movimientos corporales, ropa, la distancia entre una persona y su interlocutor, la postura, los gestos, las expresiones faciales, los movimientos de los ojos y el contacto corporal. Confianza/Desconfianza: El hecho de que el receptor confe o desconfe de un mensaje est en funcin, en gran medida de la credibilidad que el emisor tenga en la mente del receptor. En trminos generales, la credibilidad de un gerente ser mucha si los dems lo perciben como una persona conocedora, confiable y verdaderamente interesada en el bienestar de los dems. La credibilidad es resultado de un proceso en el que la honradez, el juicio equilibrado y las buenas intenciones de una persona son reconocidos por los dems.
52/86
Manual Terico
12 CONTROL
12.1 DEFINICIN
El control es la funcin administrativa mediante la cual se comprueba que lo planificado se est cumpliendo de acuerdo a lo esperado. Mediante el control se previenen problemas y obstculos al desempeo o se corrigen fallas encontradas en las actividades ya realizadas. Es por eso que el control puede clasificarse como: Preventivo o proactivo: Mediante el cual se detectan los problemas o fallas antes de que estas produzcan una anomala o retraso a las actividades programadas. Correctivo: Que es el que detecta fallas en las actividades y sugieren su correccin. En los centros de informtica, para efectos de control, es importante la definicin de estndares de desempeo, que establezcan medidas contra las cuales comparar los resultados obtenidos. Adems es importante el establecimiento de controles generales en el departamento de informtica que sirvan para supervisar y evaluar las actuaciones de los empleados del departamento.
12.2 CONTROLES GENERALES EN EL CENTRO DE INFORMTICA

Pueden identificarse cinco tipos de controles generales en los centros de informtica: Controles orientados a las actividades del centro y al personal que las realiza: Estos controles se centran en la planificacin, la organizacin del departamento y las operaciones del departamento. Examina las funciones gerenciales normales que llevan a cabos los gerentes de informtica y los lderes de proyecto (Planear, organizar, dirigir y controlar las actividades relacionadas con los objetivos del departamento). Los controles de este tipo pueden incluir: a. Presentacin peridica de informes de tareas realizadas. b. Comparacin de dichos informes con los cronogramas de tareas elaborados en la planificacin, auxilindose de herramientas con los diagramas de GANTT y PERT para determinar desviaciones en los tiempos, con especial nfasis en la ruta crtica. c. Supervisin peridica en el campo de trabajo. d. Evaluaciones del desempeo. Controles de Procedimientos de Sistemas y Programas: Se pueden disear los procedimientos para controlar el proceso de revisin de sistemas y programas, as como los procedimiento de correccin y ajustes de fallas en los sistemas. El nivel de documentacin que se genera en el centro de informtica es muy importante. Incluye diseos tcnico, manuales de operacin y manuales de usuario. Con demasiada frecuencia, este aspecto importante es ignorado por 53/86
Manual Terico
el personal informtico que suele dar mayor prioridad a labores que implican un mayor reto. En resumen, las categoras bsicas de controles para procedimientos de sistemas y programas, cubren: a. Mtodos y Procedimientos para el desarrollo de sistemas (o para cualquier otro tipo de producto que se desarrolle en el centro de informtica). b. Procedimientos administrativos en los que estn basados los sistemas y productos creados en el centro. c. Procedimientos y estndares generales de programacin. d. Procedimientos de revisin correccin y modificacin de sistemas. e. Documentacin bsica (Diseos tcnicos, Organigramas, Diagramas, Manuales de operacin y Manuales de usuario). Controles interconstruidos de hardware y software: Los incorporan los fabricantes de hardware y software para verificar la confiabilidad del equipo de computacin y su sistema operativo. De ordinario, incluyen verificaciones de paridad, verificaciones de duplicacin, control de sobreflujo, controles y alarmas de sistema operativo, mecanismos de auto apagado, controles predeterminados de acceso a dispositivos, etc. Controles del Centro de Informtica en s: En este tipo de control pueden definirse como normas de comportamiento para la gente que labora en el centro de informtica o que tiene alguna vinculacin con el mismo, de disposiciones como las siguientes: a. Como regla, cualquiera que no est involucrado en las operaciones o programacin de sistemas deber ser escoltado en todo momento al cuarto donde estn los servidores principales. b. Se restringe el acceso a la biblioteca de cintas, discos y otros respaldos al personal del departamento de Administracin del Sistema. Los mecanismos de control que suelen regir el comportamiento de un departamento suelen incluir: a. Horarios de trabajo. b. Controles de entrada y salida. c. Formularios para solicitud de permisos o reportes de inasistencias, entro otros. Controles de Seguridad: Bsicamente, los controles de seguridad cubren contingencias no cubiertas adecuadamente por otros controles. Deben estar estandarizados para todas las operaciones diarias, en caso contrario se presentarn dificultades operativas y acciones correctivas inconsistentes. Los centros de informtica suelen contar con controles de seguridad que incluyen: a. Bitcoras en los sistemas. b. Mecanismos para prevencin y recuperacin en caso de fallas en el sistema elctrico. c. Mecanismos de proteccin contra incendios. 54/86
Manual Terico
d. Mecanismos de proteccin ambiental.
12.3 ESTNDARES EN LOS CENTROS DE INFORMTICA

Un punto de arranque para el control efectivo en un centro de informtica es el establecimiento de estndares de desempeo adecuados, tanto para el rea de desarrollo de sistemas, como para las reas de administracin de sistemas, operaciones y soporte a clientes.
12.3.1
EL PORQU DE LOS ESTNDARES EN LOS CENTROS DE INFORMTICA
La razn de ser de un Centro de Informtica es proporcionar servicios al usuario. El administrador del centro debe velar porque los servicios se desarrollen en forma adecuada, se entreguen en un tiempo oportuno y se operen de forma efectiva. Los estndares definen aspectos clave de los servicios provistos al usuario tales como: Qu incluye el servicio? Cmo se desarrollar el servicio? Cmo se evaluar el servicio? Quin proveer el servicio y cmo? Los estndares sirven como un medio para la comunicacin de las expectativas de la gerencia y de los usuarios. Las actividades de planeacin, organizacin, direccin y control de la gerencia reciben un gran apoyo derivado de esta mayor comunicacin. Los estndares para el desarrollo de productos informticos pueden ser la herramienta ms til para medir la productividad del centro de informtica. A travs de la aplicacin adecuada de estndares adecuados, los recursos (tiempo del personal, tiempo mquina, etc.) requeridos para desarrollar proyectos informticos se puede reducir enormemente.
12.3.2
EL VALOR DE LOS ESTNDARES EN UN CENTRO DE INFORMTICA
El valor de los estndares en los centros de informtica resulta obvio cuando se consideran los siguientes hechos: En una centro de informtica tpico se dedican entre el 60 y el 75% de los recursos totales en el mantenimiento y mejora de los sistemas existentes. Una buena documentacin de sistemas y el cumplimiento de estndares durante el desarrollo original reducir drsticamente tanto el mantenimiento como las necesidades requeridas. En el rea de sistemas, el agregar nuevas aplicaciones a sistemas ya existentes, incrementa los costos de una manera proporcionalmente mayor que al inicio del diseo original. Los problemas principales son documentacin pobre e inflexibilidad de los sistemas. Los factores anteriores, combinados con el incremento en la demanda de servicios y productos informticos ocasiona retrasos de meses, y hasta aos, en el desarrollo de nuevos proyectos. Cada mes que pasa sin la implementacin de nuevos sistemas redunda en prdida de oportunidades (y quizs econmicas) para los usuarios potenciales de los sistemas. 55/86
Manual Terico
12.3.3
AREAS TPICAS DE CONTROL DONDE SE APLICAN ESTNDARES
Antes de profundizar en los estndares tpicos de control en los centros de informtica, es til definir los lineamientos principales para el establecimiento de estndares en las actividades del desarrollo de sistemas: 1. Estndares distintos son apropiados para diferentes productos informticos. Los factores que se considerarn en la aplicacin de estndares deben incluir si el sistema es en lote o interactivo, que tipo de hardware puede ser usado, la naturaleza del sistema, en caso de software, la frecuencia de operacin (diaria, semanal, mensual), y el programa y presupuesto para desarrollo. 2. Los estndares caen generalmente en estas tres categoras: a. Requerimientos absolutos que deben ser cumplidos b. Requerimientos negociables que pueden o no ser necesarios, o c. Prcticas recomendadas que sera til seguir, pero que no son obligatorias. 3. Los encargados de desarrollar las actividades y proyectos en el centro de informtica deben estar claros acerca de cuales son los estndares que se espera que cumplan antes de comenzar su trabajo. Las cuatro reas especficas de preocupacin para el gerente de informtica , y que requieren la aplicacin de estndares son: Planeacin de recursos: La gerencia debe desarrollar programas para proyectos u operaciones, as como planes de persona, realistas. El uso de estndares vlidos permite determinar los recursos necesarios para cada funcin asociada con un proyecto u operacin especficos. Un centro de informtica tpico tiene un retraso de 12 a 30 meses y est luchando continuamente por asignar prioridades. La planeacin ms importante de recursos que la organizacin puede realizar es la de tomar la decisin correcta acerca de los recursos que deben ser comprometidos y a qu nivel de esfuerzo. La efectividad y la respuesta pueden mejorar enormemente mediante el establecimiento de estndares para la asignacin de prioridades. Por ejemplo: a. Una organizacin puede adoptar la poltica de que los sistema de informacin que permita a la organizacin cumplir con un requisito legal o de gobierno tendrn la prioridad ms alta b. Que los que darn un beneficio cuantificable como resultado de un aumento neto en las utilidades o una reduccin en los gastos operativos tengan prioridad dos, y, obviamente se realizan primero los que ofrezcan una tasa de retorno proyectada ms elevada c. Finalmente debe asignarse prioridad tres a los proyectos con beneficios intangibles. Si los beneficios no compensan los costos no debe realizarse el proyecto. Garanta de calidad: Los estndares ayudan a asegurar que un nivel de calidad especificado por el gerente/usuario sea obtenido en el desarrollo de productos y servicios desarrollados por el centro de informtica. 56/86
Manual Terico
Las formas adecuadas para asegurar una adecuada garanta de calidad son dos: a. Hacer que el equipo de informticos asignados a la tarea y los usuarios del producto o servicio solicitado definan los criterios para una terminacin exitosa del proyecto, antes de que se haga el primer esfuerzo. Los criterios para el xito debern ser documentados y aprobados por ambos grupos. b. Establecer puntos de verificacin de calidad durante toda la vida del proyecto. Los puntos de verificacin deben ser definidos con tal certeza que cada uno de los participantes sepa con certeza qu es lo que va a ser evaluado en cada uno de los puntos de verificacin y qu es lo que constituye una calidad aceptable. Siempre es importante hacer que los estndares sean lo suficientemente flexibles y que ofrezcan posibilidades de expansin. Reduccin de costos: Los estndares proporcionan lineamientos que se seguirn por terceros para el logro de un objetivo. Ayudan a especificar cmo se debe llevar a cabo una labor con base en el anlisis cuidadoso de experiencias anteriores, ayudando de esta forma a otros a evitar formas menos efectivas y eficientes. Tres tipos bsicos de estndares pueden ayudar a reducir los costos del desarrollo de productos informticos: a. Identificar claramente las tareas que se deben realizar durante cada una de las fases de ciclo de vida del proyecto. Esto asegurar que se hagan slo las cosas correctas y que la terminacin de cada fase representa un trabajo completo y exhaustivo de todo lo que se deba hacer hasta ese momento. b. Usar unidades modulares para la construccin de soluciones informticas. Esto tiene que ver ms que todo con el software. Por ejemplo: La lgica bsica de un procesamiento para efectuar una actualizacin de un archivo puede disearse de manera tal que resulte aplicable a un archivo empleados, a uno de clientes y as sucesivamente. La idea es tener elementos de soluciones informticas generalizados, documentados, depurados y almacenados que puedan reutilizarse fcilmente en futuros productos. c. Permitir que todo el que desarrolla productos y servicios informticos tenga acceso, preferiblemente en lnea a todo el material necesario para realizar su trabajo. Debe contarse con material de referencia de buena calidad. La clave para un uso efectivo de de los materiales de referencia est en el conocimiento de la informacin con que se cuenta y la posibilidad de un acceso rpido a dicha informacin en el momento adecuado. Evaluacin de desempeo: Los estndares ayudan a definir una base para comparar el desempeo individual contra las expectativas del gerente o del usuario. El personal informtico debe ser evaluado fundamentalmente en cuanto a tres factores: 57/86
Manual Terico
a. Son aceptables para los usuarios los productos o servicios diseados?. Para llegar a una conclusin al respecto los usuarios deben haber convenido los criterios para considerar satisfactorio el producto o servicio. b. Se complet el esfuerzo del desarrollo de los productos o servicios dentro del presupuesto?. c. Se complet el esfuerzo del desarrollo de los productos o servicios de acuerdo al programa?. Se debe definir claramente cuando es la fecha de terminacin, la cual puede ser: cuando el se termina la construccin del producto, cuando el usuario est debidamente entrenado para su uso o cuando el producto comienza a dar frutos satisfactoriamente.
12.3.4 ESTNDARES PARA CONTROLAR LAS OPERACIONES DEL CENTRO DE INFORMTICA

El centro de informtica es una organizacin de servicio, y como tal debe ser muy sensible a dos consideraciones clave para cualquier organizacin de este tipo: Cules son las demandas del usuario del sistema, tanto actuales como a futuro? Cmo se pueden satisfacer estas demandas en la forma ms eficiente en costo y efectiva en relacin a las necesidades? Si el centro de informtica se ve a s mismo como una organizacin de servicio, deber contar con un proceso de revisin continua del desempeo para asegurar el cumplimento de las necesidades de servicio actuales y futuras de forma eficiente en cuanto a costo y eficiente en cuanto a la satisfaccin de la necesidad. El proceso de revisin del desempeo deber incluir las siguientes actividades: Evaluar que tan efectiva y eficientemente se estn satisfaciendo las necesidades actuales de servicio. Esta revisin deber abarcar todos los aspectos de las operaciones: procesamiento y procedimientos de entrada, asignacin de etapas a las labores, distribucin de las salidas y la relacin con los usuarios. Lo usuarios y el personal del centro de informtica debern compartir ideas respecto a reas problemticas y posibilidades para mejorarlas. Se debe hacer un esfuerzo por identificar necesidades especficas de servicio que no estn siendo satisfechas. Medir la utilizacin actual de recursos y determinar la capacidad excedente actual: Se debern determinar el nmero de turnos, horas por turno y personal por turno. A qu actividades dedican estas personas su tiempo? En cuanto al equipo, existe una gran cantidad de dispositivos de monitoreo para el hardware y software que miden la utilizacin de CPU, memoria unidades de disco, etc. Muchos centro de informtica cuentan con un grupo de desempeo que emplea estos monitores para ayudar a obtener el mejor desempeo con el equipo actual y recomendar actualizaciones de hardware y software. Determinar necesidades de servicio a futuro y efectuar la planeacin de recursos para satisfacer estas necesidades:: Los largos tiempos de entrega, 58/86
Manual Terico
asociados con la obtencin de equipo, el rpido crecimiento de los negocios y la dificultad de obtener fondos, son algunas de las razones por las que una planeacin exitosa de recursos requiere pensarse con una anticipacin de tres a cinco aos. Lo anterior requiere una excelente comunicacin entre usuarios e informticos para que ambos estn concientes de las aplicaciones que, posiblemente aparezcan dentro del horizonte de planeacin. Tambin requiere que se mantenga al corriente en cuanto a nuevo equipo y tecnologa.
59/86
Manual Terico
13 CONTROL: PROTECCIN DE DATOS, HARDWARE Y SOFTWARE

13.1 INTRODUCCIN A LA PROTECCIN DE LOS DATOS
Los datos son uno de los recursos ms valiosos de las organizaciones, y, aunque son intangibles, necesitan ser controlados con el mismo cuidado que los dems inventarios de la organizacin. Se debe tener presente que la responsabilidad de los datos es compartida conjuntamente por alguna funcin determinada de la organizacin y la direccin de informtica. En todo centro de informtica debe contarse con una serie de polticas que permitan la mejor operacin de los sistemas.
13.2 POLTICAS Y PROCEDIMIENTOS

Las polticas existentes deben estar actualizadas en todas las actividades, estar debidamente documentadas y ser del conocimiento del personal. No contar con polticas y procedimientos actualizados que rijan la administracin del rea de informtica podra ocasionar: Administracin inadecuada de la operacin Relajamiento en el cumplimiento de las obligaciones del personal Inadecuada revisin de labores Las polticas y procedimientos deben incluir los siguientes puntos: Seguridad de la informacin (fsica y lgica) Adquisicin de hardware y software Operacin del centro de cmputo Es recomendable que se documenten todos los procedimientos de las diversas actividades. Junto con las normas y polticas esos procedimientos forman los manuales de operacin. Al proceder de esta manera se obtienen las siguientes ventajas: Se tiene una base uniforme, estable y formal para capacitacin, consulta y supervisin y se fomenta la eficiencia del personal en sus funciones. Ante la rotacin del personal, se evita el desvirtuamiento de las normas y procedimientos originales creados Se precisa la responsabilidad individual de los participantes en una operacin, en caso de errores y omisiones.
13.3 PROTECCIN DE LOS DATOS: POLTICAS DE RESPALDOS

Los respaldos de la informacin deben realizarse mensual, semanal o diariamente y se deben observar los siguientes puntos: Contar con polticas formales por escrito para efectuar los respaldos mensuales, semanales y diarios de informacin.
60/86
Manual Terico
Todos los medios magnticos de respaldo no deben estar almacenados en un mismo lugar, aunque se tengan los medios magnticos de operacin en el centro, por lo que si hubiera una contingencia grave (incendio, inundacin) no se tendra riesgo de perder parte o la totalidad de informacin, ya que se cuenta con otro lugar de respaldos. Debe tenerse acceso restringido al rea en donde se tienen almacenados los medios magnticos, tanto de operacin como de respaldo. Se deben tener almacenadas las cintas por fecha, concepto y consecutivo, y es conveniente elaborar y actualizar la relacin sobre las cintas, el contenido de los datos de registro y los responsables de efectuarlos. Se debe contar con una poltica que indique los procedimientos a seguir en cuanto al almacenamiento de las cintas de respaldo en un lugar diferente de la ubicacin del centro, en donde se pueda tener acceso las 24 horas del da y donde se designen los responsables de mantener actualizada la informacin vital de la organizacin. No contar con estas polticas de respaldo puede provocar que haya riesgo de prdida de informacin en caso de alguna contingencia y no tener una disponibilidad inmediata de la informacin de respaldo para recuperar la informacin y conseguir la continuidad en la organizacin. Se debe elaborar por escrito una serie de polticas y procedimientos para la elaboracin de los respaldos, contemplando los pasos a seguir, la informacin que debe ser respaldada, segn el perodo correspondiente (mensual, semestral o anual), as como el personal asignado para cada caso. Tambin se debe especificar la forma de etiquetacin, nomenclatura, pruebas, rotacin de cintas, los nombres de los responsables de efectuar los respaldos y las cintas que sern designadas para ser resguardadas fuera de las instalaciones. Tambin se debe tener una relacin por escrito de la ubicacin y el contenido de las cintas, que debe ser entregada al responsable de la seguridad del centro, as como al gerente del rea de informtica.
61/86
Manual Terico
13.4 PROTECCIN DE LOS DATOS: POLTICA DE REVISIN DE BITCORA

Deben existir bitcoras de operacin en las que se registren los procesos realizados, los resultados de su ejecucin, la concurrencia de errores, los procesos ejecutados en el equipo y la manera en que concluyeron. No contar con una poltica de revisin de bitcoras de operacin de los diferentes procesos puede ocasionar problemas como: Carecer de bases para el rastreo de errores de procesamiento Falta de parmetros de evaluacin respecto al funcionamiento del equipo y del departamento de sistemas Ausencia de controles en cuanto al registro de seguimiento de problemas Falta de parmetros para determinar las causas de una falla significativa en el sistema y dar seguimiento a su correccin Dependencia del personal para solucin de errores Los errores pueden presentarse de forma recurrente y no ser detectados, lo cual causa prdidas de tiempo en la correccin. Puede presentarse una prdida de tiempo al no programarse adecuadamente las funciones, lo que tiene como consecuencia una confusin en el rea respecto a los procesos que ya se han realizado y los que se deban realizar. Es necesario establecer una poltica de revisin de las bitcoras de operacin, asignando responsables por proceso y funcin, lo que traera como beneficio detectar y corregir a buen tiempo los errores recurrentes y poder tomar medidas preventivas para que estos ya no se presenten.
13.5 PROTECCIN
DEL SOFTWARE: LICENCIAS DE SOFTWARE
POLTICAS
EN LA ADQUISICIN DE
Todas las organizaciones deben tener un inventario de las licencias de software actualizado, que asegure que toda la paquetera y software en general sea legal y est amparada por una licencia, para evitar posibles problemas legales por pago de derechos de uso y explotacin del software. Al no contar con las licencias correspondientes, no se le puede exigir al proveedor el servicio de soporte o actualizacin de software, ya que para poder contar con estos servicios es necesario presentar las licencias de adquisicin o el nmero de serie instalado dentro de la licencia, el cual se encuentra clasificado en una base de datos dentro de los equipos del proveedor. Es muy fcil detectar si la licencia es pirata o ya venci. Por ello es muy importante: Actualizar el inventario de hardware y software, sealando los paquetes que se tienen instalados por mquina y verificando que cada uno de estos est amparado por una licencia.
62/86
Manual Terico
En caso de no contar con las licencias, es necesario contactar al proveedor del software o del paquete en cuestin para actualizarlas o adquirirlas lo ms pronto posible. Elaborar un plan verificador de software, para revisar que no se instale paquetera pirata Designar una persona responsable del rea de informtica para guardar y tener actualizadas las licencias Promover un plan de concientizacin entre el personal con el fin de que no se instale paquetera pirata en las mquinas propiedad de la empresa, y aplicar sanciones al personal que no acate estas medidas.
13.6 PROTECCIN CENTRO
DEL
HARDWARE: POLTICAS
DE
SEGURIDAD FSICA
DEL
Deben existir polticas y procedimientos que describan los aspectos de seguridad mnimos que deben regir dentro del departamento de informtica. Se deben observar los siguientes puntos: El acceso al centro debe estar restringido por una puerta, la cual contar con una chapa adecuada de seguridad, o con un dispositivo electrnico de control de acceso. Se deben tener dispositivos adecuados de deteccin de humo, as como extinguidores para incendios. Se debe tener proteccin en los servidores para que no puedan ser desconectados accidental o intencionalmente y provocar as serios daos al equipo. Deben existir documentos o carteles que indiquen las normas de seguridad mnima que deben observarse al estar en el centro. El personal operativo no debe permitir el acceso a personal ajeno al departamento. Los equipos que se utilizan para limpieza dentro del centro no deben estar directamente conectados a los toma corrientes a los que estn conectados los equipos de cmputo y los servidores. Los equipos elctricos, interruptores o de comunicacin no deben estar al alcance de cualquier persona. Hay que elaborar polticas formales de seguridad y disear las caractersticas para el centro, por lo que se recomienda lo siguiente: Seguridad fsica del centro de cmputo. Disear un lugar exclusivo y adecuado para los equipos centrales. Implementar dispositivos adecuados para la prevencin y extincin de incendios que garanticen la salvaguarda del equipo y la informacin que se encuentre en el centro. Acceso al centro de cmputo. El acceso al centro de cmputo debe estar restringido por llaves electrnicas, chapas magnticas, etc. Adems es necesario que se implemente algn procedimiento de control de acceso para personal no autorizado a las instalaciones. Se 63/86
Manual Terico
debe realizar una difusin correcta de las polticas y procedimientos de seguridad fsica, con el objetivo de que el personal conozca las responsabilidades y las acciones que les corresponde. Plan de contingencias. Que permita que los sistemas sigan funcionando en caso de algn siniestro o en caso de una huelga, o un imprevisto de cualquier ndole. Un plan de contingencia debe contener los siguientes controles: Delegacin de funciones y entrenamiento de personal Resumen de actividades a seguir en caso de contingencias Estudio detallado de las contingencias que, de acuerdo a la zona geogrfica, tienen ms probabilidad de ocurrir y los impactos que cada una ocasionara. Realizar un estudio de tiempo estimado de restablecimiento de operaciones de acuerdo con una determinada contingencia, as como un estudio de consecuencias potenciales que se desprenderan por la inoperatividad de los sistemas. Identificar las aplicaciones y archivos de datos crticos para la operacin de servicios computacionales, as como, determinar las prioridades de restablecimiento de estos. Se deben incluir especificaciones de hardware y software, tiempo de procesamiento, programa, archivos y documentacin de programas y operacin. Proveer los lineamientos necesarios para el restablecimiento de operaciones a partir de los respaldos de informacin. Desarrollo de pruebas peridicas del plan de contingencia, as como el establecimiento de niveles de autoridad y responsabilidades para garantizar el buen resultado de la prueba. Establecer procedimientos y responsabilidades para mantener el plan de contingencias. Procedimientos o planes para la reconstruccin de centro despus de una contingencia. Establecimiento de procedimientos manuales de operacin por parte de los usuarios para restablecer operaciones mientras se recuperan los sistemas. Lineamientos para garantizar que dicho plan sea aprobado y actualizado peridicamente.
64/86
Manual Terico
14 ADMINISTRACIN DE PROYECTOS INFORMTICOS

14.1 INTRODUCCIN
Los proyectos son planes especficos de accin dirigidos a la solucin de un problema especfico y que cuenta con recursos exclusivos y un tiempo predeterminado. Ms que lograr un objetivo, cumplir una misin o alcanzar una visin, con el proyecto lo que se busca es un producto especfico. Se coordinan recursos, se establecen actividades y el tiempo para lograrlas con el fin de crear algo, un producto. En el rea de informtica la mayor parte del trabajo se desarrolla en base a proyectos, ya que, a diferencia de otras reas de servicio de la empresa, los servicios que presta el centro de informtica son casi siempre diferentes. No son servicios permanentes o rutinarios, sino nuevas necesidades con caractersticas distintas cada vez (pinsese en el desarrollo del software, por ejemplo). Por tanto, cada nuevo requerimiento suele plantearse como un nuevo proyecto a desarrollar. Sumado a esto hay que decir que la gerencia y los usuarios exigen que los proyectos informtico se desarrollen con rapidez, y en la medida de lo posible esto debe cumplirse y para ello existen tres maneras de afrontar un proyecto informtico: Mejorando la velocidad de desarrollo del proyecto. Ventaja: Permite la entrega rpida del producto solicitado. Desventaja: Se corre un mayor riesgo Reduciendo el riesgo en base a una planificacin ms detallada. Ventaja: Se evitan retrasos por imprevistos. Desventaja: Se avanza ms lento. Haciendo visible el progreso. Ventaja: Permite disipar la impresin de que se est trabajando lento. Desventaja: Realmente se est trabajando ms lento. En las siguientes pginas se ampliar ms sobre la mejor manera de emprender proyectos informticos, definiendo estrategias y consideraciones a tener para su mejor desarrollo.
14.2 ESTRATEGIA BSICA INFORMTICOS
PARA
EL
DESARROLLO
DE
PROYECTOS
Si tomsemos 100 msicos de gran calidad y prestigio y los pusiramos en una orquesta sin director no sonaran como una orquesta de calidad. Indicar a esos msicos que hagan lo mejor que puedan no les ayudara a saber si deben ir ms rpido o ms lento. En el desarrollo de proyectos informticos suele darse un desperdicio similar de talento. Equipos de desarrolladores inteligentes y dedicados utilizan las tcnicas mejores y ms recientes y siguen sin poder alcanzar sus objetivos. Para lograr un desarrollo exitoso de proyectos informticos debe plantearse una estrategia basada en cuatro elementos: e. Evitar los errores clsicos f. Aplicar las bases del desarrollo 65/86
Manual Terico
g. Gestionar los riesgos para evitar un retorno catastrfico h. Basarse en la planificacin. La consideracin de estos cuatro elementos constituye la estrategia bsica para el desarrollo exitoso de un proyecto informtico.
14.3 LAS CUATRO DIMENSIONES DE UN PROYECTO INFORMTICO

Un proyecto informtico se desarrolla a travs de cuatro dimensiones principales: Personas, Proceso, Producto y Tecnologa. Las organizaciones ms efectivas en el desarrollo de proyectos informticos optimizan simultneamente las cuatro dimensiones.
14.3.1
PERSONAS
O podramos decir peopleware. La tecnologa no es la respuesta. Los proyectos ms exitosos son los que sacan provecho del potencial humano de los informticos. Cualquier organizacin que trate seriamente de mejorar la productividad debe ocuparse primero de temas relacionados con el personal, como la motivacin, el equipo de trabajo, seleccin del personal y formacin. Seleccin de personal para equipos de proyectos informticos: Los cinco principios para la seleccin de personal son: i. Mximo talento. Usar poco, pero buen personal. j. Trabajo adecuado. Asignar tareas segn la habilidad y motivacin de la gente disponible. k. Progresin profesional. Ayudar a la gente a actualizarse por si misma en vez de obligarles a trabajar donde ms experiencia tienen o donde son ms necesarios. Equilibrado del equipo. Seleccionar a gente que se complemente y armonice con los dems. m. Eliminar la inadaptacin. Eliminar y reemplazar a los miembros problemticos lo antes posible. Organizacin del equipo: Los administradores de centros de informtica sacan provecho de la estructura de sus equipos para que concuerden con el tamao del proyecto, las caractersticas del producto y los objetivos de planificacin. Motivacin: Una persona que carece de motivacin no va a querer trabajar duro y prefiere dejarse llevar. La motivacin es potencialmente el aliado ms fuerte para el desarrollo exitoso de un proyecto informtico. l.
14.3.2
PROCESO
Centrarse en el proceso, procurando hacerlo cada vez ms eficiente puede ser de gran utilidad para el desarrollo de un proyecto. La clave est en optimizarlos y hacerlos ms giles, ya que en muchos casos se cae en el error de convertir los procesos en algo agobiante, rgido y burocrtico. Para lograr procesos tiles y eficientes se necesita: a. Evitar la repeticin de trabajo. Si en las ltimas etapas del proyecto hay un cambio en los requerimientos, es necesario redisear, recodificar y 66/86
Manual Terico
b.
c.
d. e. f. g.
volver a hacer las pruebas. Si ha habido problemas en el diseo que no se descubren hasta la prueba, se debe volver al diseo detallado y la codificacin y comenzar de nuevo. Una de las mejores formas de ahorrar tiempo en los proyectos informticos es orientar el proceso de forma que se evite hacer la misma cosa dos veces. Control de calidad. Tiene dos objetivos principales. El primero es asegurarse de que el producto tiene un nivel de calidad aceptable. El segundo objetivo es detectar los errores del proceso en el momento en que haya que emplear menos tiempo (y menos diseo) para corregirlos. Bases del desarrollo. Hay que definir estndares. A pesar de que los mtodos estndares en rea de la informtica como la ingeniera de software, entre otras, para el anlisis, diseo, construccin, integracin y pruebas no van a hacer andar el plan por si solas, pueden evitar que los proyectos se queden fuera de control. La mitad del desafo en el desarrollo de proyectos informticos consiste en evitar el desastre y esta es un rea en la que sobresale la aplicacin de estndares. Gestin de riesgos. Es una de las tcnicas especficas que se centran en evitar el desastre. Atencin a los recursos. El objetivo es asegurarse de que cada da se hace todo el trabajo posible. Planificacin del ciclo de vida. De manera tal que se sepa desde y hasta cuando se utilizarn los recursos en el proyecto. Orientacin al cliente. Los informticos han aprendido que desarrollar proyectos a partir de la especificacin solo es la mitad del trabajo. La otra mitad es ayudar al cliente a definir el producto que desea. Mtodos como la entrega por etapas, entrega evolutiva, prototipado evolutivo, prototipado deshechable y negociacin conveniente aportan ventajas en esta rea.
14.3.3
PRODUCTO
La dimensin ms tangible del cuarteto es la dimensin producto, y ocuparse del tamao y caractersticas del producto plantea enormes oportunidades de reducir la planificacin. Al reducir el conjunto de prestaciones del producto se reduce el plan. El total en la reduccin sobre el plan que se obtiene al ajustar en el tamao y las caractersticas del producto slo se ve limitado por el concepto de producto que tiene el cliente y la creatividad de equipo. Las siguientes caractersticas del producto determinan la rapidez y eficiencia con que el mismo ser desarrollado: Tamao de producto. Puesto que el esfuerzo para construir el producto se incrementa exponencialmente ms rpido que el tamao del producto en s, la reduccin del tamao mejorar la velocidad del desarrollo en la misma proporcin. Caractersticas del producto. Tales como: Rendimiento, uso de memoria, robustez y fiabilidad. 67/86
Manual Terico
14.3.4
TECNOLOGA
Una forma rpida de desarrollar proyectos eficaces y eficientes es pasar de usar herramientas menos efectivas a otras ms efectivas. En la historia del desarrollo de software, por ejemplo, uno de los cambios de mayor influencia fue el paso de lenguajes de bajo nivel a lenguajes de alto nivel.
14.3.5
SINERGIA
Hay un momento en que ocuparse de la gente, el proceso, el producto y la tecnologa se convierte en un todo. Lo que debe buscarse es que los resultados alcanzables combinando estos cuatro elementos sean mayores a la suma de los mismos.
14.4 BUSCANDO UN DESARROLLO EFICIENTE DE PROYECTOS INFORMTICOS

Hay diversos enfoques acerca de cmo debe emprenderse un proyecto informtico. He aqu una comparacin de ellos: EFECTO DEL ENFOQUE DE DESARROLLO EN EL.. Enfoque de Desarrollo Mtodo Normal ...Plan Medio ...Costo Medio ...Producto Medio
Desarrollo Eficiente (equilibrio de Mejor que la Mejor que la Mejor que la costo, plan y funcionalidad) media media media Desarrollo eficiente (orientado al Mucho Algo mejor Algo mejor mejor plan) mejor que la que la que la media media media Desarrollo rpido a fondo El ms corto Peor que la Peor que la posible media media
De ms est decir que el mejor enfoque es el segundo, ya que con el se logra un equilibrio, mejorando en las tres categoras (Plan, costo y producto). Mucha gente alcanza sus objetivos de planificacin solamente evitando los errores clsicos, sentando las bases para el desarrollo y gestionando los riesgos. Descubren que despus de todo no necesitaban un proyecto rpido, solo necesitaban organizarse!. Esa es la clave.
14.5 ERRORES
CLSICOS INFORMTICOS
EN
LA
ADMINISTRACIN
DE
PROYECTOS
Algunas tcnicas de desarrollo de proyectos informticos han sido elegidas con tanta frecuencia, por tanta gente, con resultados tan malos y predecibles que son dignas de ser llamada errores clsicos. Muchos de los errores tienen una apariencia seductora. Necesitamos salvar un proyecto retrasado? metamos ms gente! tenemos que reducir el plan? Planifiquemos de forma ms agresiva! algunos de los miembros clave incomodan al resto del equipo? Esperemos a que se acabe el proyecto para despedirlo! hay que acelerar el proyecto para 68/86
Manual Terico
acabar? Tomemos cuantos informticos hayan disponibles y que comiencen lo antes posible! Los informticos, directivos y clientes normalmente tienen buenas razones para tomar las decisiones que toman, y la apariencia seductora de los errores clsicos es una de las razones de que esos errores se cometan tan a menudo. Pero debido a que se han cometido muchas veces sus consecuencias se han hecho fciles de predecir. Para facilitar su estudio se ha dividido la lista empleando las dimensiones de un proyecto informtico: personas, proceso, producto y tecnologa.
14.5.1
PERSONAS
A continuacin aparecen algunos errores clsicos relacionados con las personas: n. Motivacin dbil. Muchas veces los directivos toman decisiones que minan la moral como ser: dar nimos a diario al principio, para pedir horas extras a la mitad, o irse de vacaciones cuando el equipo est incluso trabajando horas extras, dar recompensas de poco valor, etc. o. Personal mediocre. Despus de la motivacin, la capacidad individual de los miembros del equipo y sus relaciones como equipo tienen la mayor influencia en la productividad. Muchas veces los directivos contratan al personal que est disponible ms pronto (y a menor costo) en lugar de basarse en un perfil de capacidad en consonancia con las necesidades del proyecto. p. Empleados problemticos incontrolados. Un fallo al tomar una decisin acerca del empleado problemtico es una de las quejas ms comunes del los miembros del equipo con respecto a sus superiores. Una manzana podrida puede estropear el proyecto completo. q. Hazaas. Algunos informticos ponen un gran nfasis en la realizacin de hazaas en los proyectos. Pero lo que hacen tiene ms de malo que de bueno. Es mejor tener progresos firmes y consistentes, que desarrollar proyectos en tiempo y esfuerzo record, los cuales, si bien son meritorios, corren un riesgo extremo. r. Aadir ms personal a un proyecto retrasado. Este es quizs el ms clsico de los errores clsicos. Cuando un proyecto se alarga, aadir ms gente puede quitar ms productividad a los miembros del equipo de la que aaden los nuevos miembros s. Oficinas repletas y ruidosas. La mayora de los informticos consideran sus condiciones de trabajo como insatisfactorias. Cerca del 60% de ellos considera que no tienen suficiente silencio ni privacidad. t. Fricciones entre los usuarios y los informticos. A los clientes puede parecerles que los informticos no cooperan cuando rehsan comprometerse con el plan propuesto por los clientes o cuando fallan al entregar lo prometido. Por su parte a los informticos puede parecerles que los clientes no son razonables cuando insisten en planes irreales o cambios en los requerimientos despus de que estos han sido fijados. El principal efecto de estas fricciones es la mala comunicacin, y los efectos secundarios de la mala comunicacin incluyen el pobre 69/86
Manual Terico
u.
v.
w.
x.
y.
entendimiento de los requerimientos, el pobre diseo de la interfaz de usuario y, en el peor de los casos, el rechazo del cliente hacia el producto. Adems, remediar estas fricciones consume tiempo y distraen tanto a desarrolladores como a clientes, del trabajo real en el proyecto. Expectativas poco realistas. El gerente de proyectos informticos debe tener el valor y la firmeza de corregir una expectativa irrealista del cliente. Este problema tiene variantes, ya que en algunos casos son los directivos del proyecto quienes se buscan problemas al pedir recursos y proponer plazos basndose en estimaciones demasiado optimistas. Falta de un promotor efectivo del proyecto. Para soportar muchos de los aspectos del desarrollo exitoso de proyectos informticos es necesario un promotor de alto nivel, particularmente para: hacer una planificacin realista, llevar el control de cambios e introducir nuevos mtodos de desarrollo. Sin un promotor ejecutivo efectivo el resto de personal de alto nivel de la institucin puede forzar a que se acepten plazos irreales o hacer cambios que debiliten el proyecto. Falta de participacin de los implicados. Las personas que deben participar en el proyecto incluyen: promotores, ejecutivos, responsables del equipo, miembros del equipo, personal de ventas, usuarios finales, clientes, y cualquiera que juegue algn papel en el proyecto. Falta de participacin del usuario. Los proyectos que no implican al usuario desde el principio corren el riesgo de ser imprecisos en cuanto a requerimientos y vulnerables a que se consuma tiempo en prestaciones descubiertas demasiado tarde. Ilusiones. Las ilusiones no son solo optimismo. Realmente consisten en cerrar los ojos y esperar que todo funciones cuando no se tienen bases razonables para pensar que ser as. Las ilusiones al principio del proyecto llevan a grandes explosiones al final.
14.5.2
PROCESO
Los errores relacionados con el proceso retrasan los proyectos, malgastando el esfuerzo y talento del personal. A continuacin se enumeran algunos de los peores errores relacionados con el proceso: a. Planificacin excesivamente optimista. Fijar un plan excesivamente optimista predispone a que el proyecto falle por infravalorar el alcance del proyecto, afectando la planificacin efectiva, y reduciendo las actividades crticas para el desarrollo, como el anlisis de requerimientos o el diseo. Tambin supone una excesiva presin para los desarrolladores, quienes a largo plazo se ven afectados en su moral y su productividad. b. Gestin de riesgos insuficiente. Hay que dejar tiempo y recursos de reservas para afrontar los imprevistos. Con solo que vaya mal una cosa se retrasar el proyecto. c. Fallos de los contratados. Las compaas contratan a veces la realizacin de partes de un proyecto cuando tienen demasiada prisa hacer el trabajo en casa. Pero los contratados frecuentemente 70/86
Manual Terico
d. e.
f.
g.
h.
i.
j.
k.
l.
entregan su trabajo tarde, con una calidad inaceptable o que falla al no coincidir con la especificacin. Riesgos como requerimientos mal definidos pueden ser enormes cuando se contrata a alguien externo, y esto puede ocasionar retrasos en el proyecto en lugar de acelerarlo. Planificacin insuficiente. Si no se planifica para tener un proyecto exitoso, no se puede esperar que el mismo se de. Abandono de las planificacin bajo presin. Es comn en el rea de informtica el hacer planes y abandonarlos en cuanto se presenta un problema. A partir de ese punto el trabajo no tiene coordinacin ni elegancia. Se falla en no crear un plan alternativo o no tener un plan de contingencias. Prdida de tiempo en el inicio difuso. Es mucho ms fcil, barato y menos arriesgado suprimir unas pocas semanas o meses del inicio difuso en vez de comprimir el plan de desarrollo en ese mismo tiempo. Escatimar en las actividades iniciales. Los proyectos que se aceleran intentando acortar las actividades no esenciales suelen terminar mal. Por ejemplo, en un proyecto de desarrollo de software es comn acortar actividades como el anlisis de requerimientos, la arquitectura y el diseo, dado que estos no producen cdigo. Es comn que cuando se pregunta por el diseo en un proyecto desastroso el responsable diga No hemos tenido tiempo de hacer el diseo. Diseo inadecuado. Un caso especial de escatimar en las actividades iniciales es diseo inadecuado. Proyectos acelerados generan un diseo indeterminado, dominado por las conveniencias ms que por la calidad requerida. Escatimar en el control de la calidad. En los proyectos que se hacen con prisa suele cortarse por lo sano, eliminando las revisiones, la planificacin de pruebas y realizando solo actividades superficiales. Esto es contraproducente. A la larga, acortar en un da las actividades de control de calidad al comienzo del proyecto probablemente supondr de 3 a 10 das de actividades finales. Control insuficiente de la directiva. Sobre todo cuando hay poco control para detectar a tiempo los signos de posibles retrasos en el plan, ya sea porque no se definieron al principio o porque se abandonaron en el camino. Convergencia prematura o excesivamente frecuente. Bastante antes de la fecha en que se haya programado entregar un producto, hay un impulso para preparar el producto para la entrega, mejorar el rendimiento del producto, imprimir la documentacin final, registrar las ayudas, etc. En proyectos hechos con prisa hay una tendencia a forzar prematuramente la convergencia. Estos intentos son prdida de tiempo y prolongan el plan. Omitir tareas necesarias en la estimacin. El esfuerzo omitido suele aumentar el plan de desarrollo en un 20 o 30 %.
71/86
Manual Terico
m. Planificar ponerse al da ms adelante. Si se ha trabajado 3 meses en un proyecto y se ha logrado nicamente lo correspondiente a 2 meses Qu hacer? En muchos proyectos se plantea recuperar el retraso ms tarde, pero nunca se hace. En realidad se aprende ms sobre el producto conforme se est construyendo, incluyendo ms sobre lo que llevar su construccin. Estos conocimientos necesitan reflejarse en una reestimacin del plan. n. Desarrollo a destajo. Algunas organizaciones piensan que el desarrollo de actividades libre, tal como salga, al mejor criterio de cada informtico es el camino para el desarrollo de proyectos informticos. Grave error.
14.5.3
PRODUCTO
Estos son los errores clsicos relacionados con la forma en que se define un producto: a. Exceso de requerimientos. Algunos proyectos tienen ms requerimientos de los que realmente necesitan, desde el mismo inicio. Hay que identificar las prestaciones complejas, ya que por regla general estas suelen ser las de menos inters para el usuario, y las que requieren ms trabajo para el informtico. b. Cambio de las prestaciones. Incluso si se han evitado los requerimientos excesivos, los proyectos sufren un promedio del 255 de cambios en los requerimientos a lo largo de su vida. Y esto puede ser grave si se trabaja con plazos y recursos ajustados. c. Informticos meticulosos. Los informticos encuentran fascinante la nueva tecnologa, y a veces estn ansiosos por probar nuevas prestaciones de sus herramientas, las necesite o no el producto solicitado. El esfuerzo requerido para disear, implementar, probar, documentar, o mantener estas prestaciones innecesarias alarga el plan. d. Estira y encoge en la negociacin. Suele suceder que un directivo apruebe el retraso de un plan de un proyecto porque se haya dado cuenta de que el plan estaba errado, pero que despus aada nuevas tareas al mismo plan. Esto, obviamente, solo puede ir en detrimento del plan. e. Desarrollo orientado a la investigacin. Caso particular del desarrollo de software. Si el proyecto fuerza los lmites de la informtica porque necesita la creacin de nuevos algoritmos o nuevas tcnicas de computacin, no estamos desarrollando software, estamos investigando en software. Los planes de desarrollo de software deben ser razonablemente predecibles.
14.5.4
TECNOLOGA
El resto de los errores clsicos estn relacionados con el uso correcto o incorrecto de la tecnologa: a. Sndrome de la panacea. Cuando el equipo del proyecto se aferra solo a una nueva tcnica, tecnologa o proceso rgido, y espera resolver con ello sus problemas, est inevitablemente equivocado. 72/86
Manual Terico
b. Sobreestimacin de las ventajas del empleo de nuevas herramientas. Los beneficios de las nuevas tcnicas son parcialmente desplazados por las curvas de aprendizaje que llevan asociadas y aprender a utilizar nuevas tcnicas para aprovecharlas al mximo lleva tiempo. Las nuevas tcnicas, adems, suponen nuevos riesgos que solo se descubren con su uso. Un caso especial de sobreestimaciones de las mejoras se produce cuando se reutilizan cdigo o materiales de proyectos anteriores. Este tipo de reutilizacin suele ser efectiva pero no se gana tanto tiempo como se espera. c. Cambiar de herramientas a mitad de proyecto. Es un viejo recurso que funciona raramente. Puede tener sentido actualizar incrementalmente, dentro de una misma lnea de productos (versin 1.0 a versin 2.0). Pero a medio camino, la curva de aprendizaje, rehacer el trabajo y los inevitables errores, anulan cualquier posible beneficio. d. Falta de control automtico del cdigo fuente. De nuevo hablando de software. Sin l, si dos desarrolladores estn trabajando en la misma parte del programa, deben coordinar su trabajo manualmente. Pero invariablemente, alguno sobrescribir el trabajo del otro.
73/86
Manual Terico
14.6 BASES DEL DESARROLLO DE PROYECTOS INFORMTICOS

Los fundamentos tienen al menos tanta influencia como los tcnicos en la planificacin de desarrollos. La gestin normalmente controla las tres magnitudes del tringulo de equilibrio clsico (planificacin, costo y producto). Los fundamentos de gestin consisten en determinar el tamao del producto (incluyendo funcionalidad, complejidad y otras caractersticas del producto), asignando los recursos apropiados a un producto de ese tamao, creando un plan para aplicar esos recursos y luego controlando y dirigiendo esos recursos para impedir que el proyecto se desve.
14.6.1
14.6.1.1
BASES DE GESTIN
Estimacin y planificacin
Los proyectos bien ejecutados pasan por tres etapas bsicas para crear una planificacin. Primero se estima el tamao del proyecto, luego se estima el esfuerzo necesario para construir un producto con ese tamao y por ltimo se realiza una planificacin, basndose en la estimacin de esfuerzo. La planificacin y estimacin son las bases de desarrollo porque una estimacin incorrecta reduce la eficiencia en el desarrollo. Una estimacin correcta es una condicin necesaria para la planificacin efectiva, que adems es esencial para un desarrollo eficiente. La planificacin de un proyecto informtico incluye las actividades siguientes: Estimacin y planificacin Determinar el nmero de personas que deben participar en el equipo del proyecto, que habilidades tcnicas son necesarias, cuando aumentar el nmero de personas y quien participar. Decidir como organizar el equipo Elegir el modelo de ciclo de vida que se va a utilizar (proyecto de software) Gestin de riesgos Tomar decisiones estratgicas, tales como controlar el conjunto de prestaciones del producto y decidir si hay que comprar o crear algunas partes del producto.
14.6.1.2
Seguimiento
Una vez que se haya planificado el proyecto hay que seguir el proceso de desarrollo para comprobar que se est cumpliendo el plan previsto: que satisface sus objetivos de planificacin, coste y calidad. Normalmente el control de seguimiento en el nivel de gestin incluye: listas de tareas, reuniones e informes sobre el estado, revisiones de hitos, informes de presupuestos y dems gestiones. El control de seguimiento en el nivel tcnico normalmente incluye las intervenciones y revisiones tcnicas y las entradas de calidad que controlan si los hitos se consideran terminados.
74/86
Manual Terico
El seguimiento es fundamental. Si no existe no se puede saber si el pan se est llevando a cabo ni lo que se debera hacer despus. Tampoco habra forma de controlar los riesgos.
14.6.1.3
Medidas
Una de las formas de progresar en centro de informtica, a largo plazo es recoger datos mtricos para analizar la calidad y productividad de los productos y servicios creados. Prcticamente todos los proyectos recogen datos sobre los costos y la planificacin. Pero estos datos son limitados y no ayudan mucho a reducir los costes o a disminuir la planificacin. Recoger ms datos puede suponer mucho ms tiempo. Si adems de datos de costo y planificacin se obtienen datos histricos como el tamao de los programas en lneas de cdigo, o en cualquier otra medida, se tendrn las bases para la planificacin de proyectos futuros, que siempre es mejor que el instinto. Cuando el jefe diga: Pueden desarrollar este producto en 9 meses?, podremos decir: Nunca organizacin nunca ha desarrollado un producto de ese tamao en menos de 11 meses y el tiempo medio para tal producto es de 13 meses. Para realizar el desarrollo de forma eficiente se necesita tener conocimientos bsicos sobre las medidas o mtricas del software.
14.6.2
14.6.2.1
BASES TCNICAS
Gestin de requerimientos
Es el proceso que consiste en reunir requerimientos; plasmarlos en un documento, correo electrnico, cuaderno de interfaz de usuario, prototipo ejecutable o cualquier otro formato; hacer un seguimiento del diseo y del servicio informtico a producir; y gestionar los cambios para el resto del proyecto. Es muy comn que los desarrolladores se lamenten de los problemas asociados a los mtodos de gestin de requerimientos tradicionales, siendo la mayora de ellos demasiado rgidos. Algunos mtodos pueden ser demasiado rgidos, pero la alternativa que ofrecen suele ser peor. Un estudio realizado en ms de 8,000 proyectos encontr que las tres razones principales por la que los proyectos eran entregados tarde, por encima del presupuesto y con menos funcionalidad de la que se esperaba se deban a fallas en la gestin de requerimientos: falta de informacin del usuario, requerimientos incompletos y cambios en los requerimientos. El xito de la gestin de requerimientos depende del conocimiento de suficientes mtodos diferentes, de forma que es posible escoger los ms apropiados para un proyecto especfico. En el caso de un proyecto de desarrollo de software. Las bases de la gestin de requerimientos son: Metodologas de anlisis de requerimientos, incluyendo anlisis estructurado, anlisis estructurado de datos y anlisis orientado a objetos. 75/86
Manual Terico
Mtodos para crear el modelo del sistema, como diagramas de clases, diagramas de flujos de datos, diagramas entidad-relacin, notacin del diccionario de datos y diagramas de estado-transicin. Mtodos de comunicacin, como el Desarrollo Conjunto de Aplicaciones (JAD), prototipazo de la interfaz del usuario y mtodos generales de entrevistas. Las relaciones entre la gestin de requerimientos y los diferentes modelos del ciclo de vida, incluyendo prototipazo evolutivo, entrega por etapas, espiral, cascada y codificar y corregir. La gestin de requerimientos proporciona de dos formas diferentes una gran influencia en la velocidad de desarrollo de un servicio informtico: a) En primer lugar, la recogida de requerimientos es un paso que tiende a hacerse sin prisas, comparado con otras actividades del desarrollo del servicio. Si este paso se acelera, sin perjudicar la calidad, se puede disminuir en conjunto el tiempo de desarrollo. b) En segundo lugar, obtener un requerimiento como es debido en el primer paso normalmente cuesta de 50 a 200 veces menos que si se espera a las fases de construccin o mantenimiento.
14.6.2.2
Diseo
Del mismo modo que tiene sentido crear una serie de bocetos antes de construir una casa, tiene sentido crear una arquitectura y un diseo antes de construir un servicio informtico. Un error de diseo que no se detecta hasta la fase de comprobacin, necesita 10 veces ms tiempo para arreglarlo que si se detectara en la fase de diseo. Los temas bsicos cuando se habla de arquitectura y diseo son: Principales estilos de diseo (como diseo orientado aobjetos, diseo estructurado, diseo orientado a la estructura de datos). Conceptos fundamentales del diseo (como ocultamiento de informacin, modularidad, abstraccin, encapsulacin, cohesin, asociacin, jerarqua, herencia, polimorfismo, algoritmos bsicos y estructuras de datos bsicas). Enfoques de diseo estndar en reas generalmente duras (incluyendo manejo de excepciones, internacionalizacin y localizacin, portabilidad, almacenamiento de cadenas, entrada/salida, gestin de memoria, almacenamiento de datos, diseo de bases de datos, rendimiento y reutilizacin). Consideraciones de diseo propias del servicio informtico que se est produciendo (aplicaciones financieras, aplicaciones cientficas, sistemas en tiempo real, software de seguridasd crtica, entre otros). Esquemas de arquitectura (como organizacin de subsistemas, niveles, estilos de comunicacin de subsistemas, etc.) Uso de herramientas para diseo. Es posible contruir un servicio informtico sin disearlo primero. Sin embargo, el diseo es la base de la construccin, planificacin, seguimiento y control del proyecto, y ese diseo efectivo es imprescindible para conseguir la velocidad mxima de desarrollo. 76/86
Manual Terico
14.6.2.3
Construccin
En el momento en que se llega la construccin ya se ha llevado a cabo la mayor parte del trabajo para el xito o fracaso del proyecto. Tanto la gestin de requerimientos como el diseo ofrecen una mayor influencia en el desarrollo de un servicio informtico que la construccin. En estas actividades los cambios pequeos pueden marcar una gran diferencia en la planificacin. La construccin no ofrece muchas posibilidades de reduccin, pero el trabajo de construccin es tan detallado y laborioso que es importante hacerlo bien. Si en un principio la calidad del servicio no es ptima es casi imposible volver hacia atrs y mejorarla. No es efectivo hacerlo dos veces. Aunque la construccin es una actividad de bajo nivel, se presenta la posibilidad de perder el tiempo en cosas poco eficientes o de despistarse en tareas que, aunque no son crticas, consumen tiempo. Por ejemplo, se puede perder tiempo en depurar cdigo intil, o ejecutar con esmero pequeas secciones del sistema antes de saber si es necesario afinarlas. Los malos mtodos de construccin pueden introducir errores sutiles que pueden requerir das o incluso semanas para encontrarlos y corregirlos. A veces se puede perder tanto tiempo en encontrar un error de un programa como en tener que volver a disear o implementar un mdulo mal diseado. Las bases de la construccin incluyen los temas siguientes: Mtodos de codificacin (incluyen las variables y funciones, presentacin y la denominacin de documentacin). Conceptos relativos a los datos (incluyendo el mbito, persistencia y momento de asignacin). Directrices para utilizar tipos de datos especficos (incluyendo los nmeros en general, enteros, punto flotante, caracteres, cadenas de caracteres, volanos, constantes, vectores y punteros). Conceptos relativos al control (incluyendo la organizacin lineal del cdigo, uso de condicionales, control de bucles, utilizacin de expresiones booleanas, control de la complejidad y utilizacin de estructuras de control poco usuales, como goto, return y procedimientos recursivos). Aserciones y otros mtodos de deteccin de errores, centrados en el cdigo. Reglas para compactar cdigo dentro de rutinas, mdulos, clases y archivos. Mtodos de depueracin y comprobacin de unidades. Estrategias de integracin (como la integracin incremental y desarrollo evolutivo). Estrategias y mtodos para afinamiento del cdigo. Las ventajas, inconvenientes y detalles del lenguaje de programacin que se est utilizando. Uso de herramientas de construccin (incluyendo entornos de programacin, soporte para grupos de trabajo, como correo electrnico y el control del cdigo fuente, bibliotecas de cdigo y generadores de cdigo).
77/86
Manual Terico
Algunas de las bases anteriores requieren tiempo, aunque en la vida del proyecto en general ahorran tiempo. Es mejor ir ms despacio pero ser ms cuidadoso, ya que hay bastantes servicios informticos que tienen demasiados fallos y tienen que volver a hacerse. Las buenas construcciones previenen la creacin de nidos de ratas de cdigo indescifrable, que hacen que el proyecto se pare lenta y ruidosamente cuando una persona se enferma, cuando se descubre un fallo crtico o, simplemente, cuando se necesita hacer algn cambio. De esta manera se mejoran las previsiones y el control que se tiene sobre el proyecto y se incrementa la probabilidad de entregarlo a tiempo.
14.6.3
BASES DEL CONTROL DE CALIDAD
Al igual que las bases de gestin y tcnicas, las bases de control de calidad proporcionan un apoyo fundamental para obtener la mxima eficiencia y eficacia en el desarrollo de un servicio informtico. Cuando un producto informtico tiene demasiados errores, los desarrolladores emplean ms tiempo corrigindolo que construyndolo. La clave principal para no cometer errores es prestar atencin a las bases de control de calidad desde el primer da. Algunos proyectos intentan ahorrar tiempo reduciendo el tiempo que se emplea en el diseo y las revisiones peridicas. Otros (que van retrasados) intentan recuperar el tiempo perdido reduciendo las pruebas, lo cual es bastante sensible para la reduccin porque normalmente es el camino crtico al final del proyecto. Estas son algunas de las peores decisiones que una persona que desea realizar en forma eficiente y eficaz un producto informtico puede tomar, porque al aumentar la calidad (desde el punto de vista de menor tasa de defectos) se reduce el tiempo de desarrollo. Pocas son las organizaciones que tienen una tasa de defectos extremadamente baja. Los proyectos que se realizan con prisas son particularmente vulnerables a engaos en cuanto al nivel de calidad del que lo desarrolla. Cuando se tienen prisas se hacen recortes porque solo faltan 30 das para la entrega. En vez de escribir un mdulo de impresin completamente distinto, se hace a partir del mdulo de visualizacin en pantalla. Se sabe que el diseo es malo, que no es ampliable o de mantenimiento fcil, pero no hay tiempo de hacerlo bien. Se tienen prisas por terminar el producto, de forma que uno se siente obligado a tomar el camino ms corto. Tres meses ms tarde el producto an no se ha terminado, y empiezan a aparecer los problemas derivados de esos recortes. Se encuentra con que los usuarios no estn contentos con la forma de imprimir, y que la nica manera de satisfacer sus requerimientos es aumentando significativamente la funcionabilidad del mdulo de impresin. Desafortunadamente, hace tres meses el mdulo de impresin y el de visualizacin en pantalla se han ido entrelazando. Redisear el mdulo de impresin y separarlo del de visualizacin es una operacin difcil, que consume tiempo y es susceptible a errores.
78/86
Manual Terico
El resultado es que en un proyecto que se supona que prestaba especial atencin al desarrollo de una planificacin lo ms corta posible, se pierde el tiempo en las actividades siguientes: Disear e implementar el mdulo de impresin ya que la mayora del cdigo se deshechar. El tiempo que se emple en la prueba y depuracin del mdulo de impresin tambin se desperdici. El tiempo adicional que se debe emplear para separar el mdulo de impresin del mdulo de visualizacin por pantalla. Se debe emplear tiempo de prueba y depuracin adicional en asegurar que el cdigo de visualizacin que se ha modificado sigue funcionando despus de separarlo del mdulo de impresin. El nuevo mdulo de impresin, que debera haberse diseado como una parte integral del sistema, se ha diseado fuera del sistema existente. Todo esto sucede, cuando el nico coste necesario (si se hubieran tomado las decisiones apropiadas en el momento correcto) era el diseo e implementacin del mdulo de impresin, Este ejemplo es bastante comn. El nmero de defectos que se presentan cuando los informticos lanzan productos bajo una excesiva presin es hasta cuatro veces mayor. En los proyectos que tienen problemas de planificacin, se suelen obsesionar por por trabajar ms duro, en vez de trabajar de la forma ms ingeniosa. Prestar atencin a la calidad es como si fuera un lujo. Decidir al principio de un proyecto no centrarse en la deteccin de errores equivale a la decisin de posponer la deteccin de defectos hasta ms tarde, cuando ser ms cara y consumir ms tiempo. No es una decisin racional cuando el tiempo apremia. Si se pueden prevenir o detectar los defectos y eliminarlos pronto se obtiene una ventaja significativa en la planificacin. Los estudios han demostrado que revisar errores de requerimientos, diseo y producto desarrollado normalmente consume del 40 al 50% de del coste total del desarrollo del producto. Como regla emprica, cada hora que se emplea en prevenir defectos reduce el tiempo empleado en la recuperacin de 3 a 10 horas. En el peor caso, revisar un problema de requerimientos, una vez que el producto est en funcionamiento, normalmente cuesta de 50 a 200 veces ms que lo que costara revisar el problema cuando est en fase de requerimientos. Dado que ms del 60% de los errores se dan en tiempo de diseo, se pueden ahorrar grandes cantidades de tiempo detectando los errores antes de hacer la prueba del producto.
14.6.4
14.6.4.1
MTODOS PARA EL CONTROL DE CALIDAD

Prueba
El mtodo ms comn de control de calidad es indudablemente la prueba de ejecucin: encontrar errores al ejecutar el programa y ver lo que hace. Las dos clases ms comunes de pruebas de ejecucin son las pruebas individuales, en las cuales el informtico comprueba su propio producto para verificar si funciona correctamente, y las pruebas del sistema, en las que un probador independiente comprueba si el sistema funciona como se esperaba. 79/86
Manual Terico
La eficacia de las pruebas vara enormemente. La prueba individual puede encontrar del 10 al 50% de los defectos de un programa, y la prueba del sistema del 20 al 60% . Al unir las dos, la tasa acumulada de deteccin de defectos suele ser menor del 60%. Los errores que no se localizan se pueden encontrar por otras tcnicas de deteccin de errores, probablemente cuando el producto ya est en funcionamiento. La prueba es la oveja negra en lo que respecta mtodos de control de calidad y velocidad de desarrollo. Realmente se puede hacer tan mal como para retrasar la entrega de un producto, pero si se hace bien puede descubrir que la calidad del producto es demasiado baja para lanzarlo y que el mismo debe rretrasarse hasta se pueda mejorar. La mejor forma de fomentar la prueba, para poder entregar el producto lo ms pronto posible, es preparar un plan antes de obtener las malas noticias; establecer la prueba de forma que si se dan malas noticias, la prueba permita lanzar el producto tan pronto como sea posible.
14.6.4.2
Revisiones fsicas
Incluyen toda clase de revisiones que se utilizan para detectar defectos en requeimientos, diso, cdigo, casos de prueba o cualquier otro artefacto del proyecto. Las revisiones varan en cuanto a nivel de formalidad y eficacia y juegan un papel ms crtico en la velocidad del desarrollo que las pruebas. Entre los tipos de revisiones ms comunes estn:
14.6.4.3
Reuniones
Las reuniones informales son el tipo ms comn de revisin. El trmino reunin se define aproximadamente y se refiere a cualquier tipo de reunin en la que dos o ms desarrolladores de proyectos revisan el trabajo tcnico con el objetivo de mejorar la calidad y detectar errores antes de la prueba. Una reunin puede detectar un defecto en los requerimientos, en tiempo de especificacin, antes de que se realice el diseo o se cree el producto. Con este mtodo pueden detectarse entre el 30 y 70% de los errores en un proyecto informtico.
14.6.4.4
Inspecciones
Las inspecciones son un tipo de revisin tcnica formal, que ha demostrado ser extremadamente efectivo en la deteccin de errores de un proyecto. Con las inspecciones, los desarrolladores reciben una preparacin especial y juegan un papel especfico durante las mismas. El moderador se vuelca a trabajar en el producto para inspeccionarlo antes de la reunin de inspeccin. Los revisores examinan el producto antes de la reunin y utilizan listas de control para estimular su revisin. Durante la reunin de inspeccin, el autor normalmente comenta el material inspeccionado, los revisores identifican los errores y el secretario guarda los errores. Despus de la revisin el moderador genera ujn informe sobre la inspeccin, describiendo cada uno de los defectos e indicando lo que se har con ellos.
80/86
Manual Terico
Al igual que en las reuniones, las inspecciones se pueden utilizar para detectar defectos antes de la prueba. Se pueden utilizar para detectar errores en requerimientos, prototipos de interfaz de usuarios, diseo, cdigo, etc. Las inspecciones encuentran entre un 60 y 90% de defectos en un proyecto informtico.
14.7 GESTIN DE RIESGOS

Si quiere apostar seguro vaya a Las Vegas y juegue a las mquinas tragamonedas. Los casinos han calculado minuciosamente las probabilidades y han determinado que pueden obtener beneficios incluso cuando las mquinas paguen hasta el 97% del dinero que entra en ellas, es decir que recuperar el 97% de lo que invierta (el costo de su diversin ser un 3%). Si no le gustan las tragamonedas, pruebe jugar blackjack y contar las cartas para aprovecharse de las probabilidades. Si Las Vegas le resulta aburrida, los proyectos informticos pueden ser el juego apropiado para Ud. Los proyectos de software incluyen un amplio conjunto de riesgos que intimidara hasta a los ms osados apostadores de Las Vegas. Cambios en los requerimientos del usuario, mala estimacin de la planificacin, personal contratado poco fiable, falta de experiencia en la gestin, problemas de personal, problemas con la tecnologa, cambio de las leyes del gobierno, entre otros, son solo algunos de los riesgos que se corren en un proyecto informtico. La probabilidad de que un proyecto complejo finalice en el tiempo estimado tiende a cero. Hay una serie de mtodos de gestin de riesgos que pueden prevenir desastres como estos, y que le harn aprender mucho de ellos antes de lo que aprendera a contar las cartas en el blackjack. El control de riesgos tiene una serie de problemas. Los proyectos que llevan un control efectivo son menos excitantes que los que no lo hacen. Perder el miedo que supone tener que decirle a su jefe que el proyecto tiene que retrasarse tres meses por un problema que nunca haba mencionado. Dejar de ser un hroe por trabajar noches y fines de semana durante seis meses sin descanso. El control de riesgos en proyectos informticos es un tema relativamente nuevo, pero ya existe informacin suficiente como para estudiarlo a profundidad. En este captulo nos limitaremos a analizar los riesgos en la planificacin ignorando los riesgos sobre costos y produccin.
14.7.1
ELEMENTOS DE LA GESTIN DE RIESGOS
La funcin de la gestin de riesgos en los proyectos informticos es identificar, estudiar y eliminar las fuentes de riesgo antes de que empiecen a amenazar la finalizacin satisfactoria de un proyecto informtico. Hay varios niveles en la gestin de riesgos: 1. Control de crisis: Apagar el fuego; controlar los riesgos solo cuando se han convertido en problemas 81/86
Manual Terico
2. Arreglar cada error: Detectar y reaccionar rpidamente ante cualquier riesgo, pero solo despus de que se ha producido. 3. Mitigacin de riesgos: planificar con antelacin el tiempo que necesitara para cubrir riesgos en caso de que ocurran, pero no intentar eliminarlos inicialmente. 4. Prevencin: Crear y llevar a cabo un plan como parte del proyecto para identificar los riesgos y evitar que se conviertan en problemas. 5. Eliminacin de las causas principales: Identificar y eliminar los factores que puedan hacer posible la presencia de algn tipo de riesgo.
14.7.2
ESTIMACIN DE RIESGOS
Esta tarea se compone de tres partes: Identificacin de riesgos: genera una lista de riesgos capaces de romper la planificacin del proyecto. Anlisis de riesgos: Mide la posibilidad y el impacto de cada riesgo y los niveles de riesgo de los mtodos alternativos. Asignacin de prioridades a los riesgos: genera una lista de riesgos ordenados por su impacto. Esta lista sirve como base para el control de riesgos.
14.7.3
CONTROL DE RIESGOS
Esta tarea tambin se compone de de tres partes: Planificacin de la gestin de riesgos: Genera un plan para tratar cada riesgo significativo. Tambin asegura que los planes para la gestin de riesgos de cada uno de los riesgos individuales son consistentes entre s y con el plan del proyecto. Resolucin de riesgos: es la ejecucin del plan para resolver cada uno de los riesgos significativos. Monitorizacin de riesgos: Es la supervisin del progreso de las actividades de anulacin de elementos de riesgo.
14.7.4
IDENTIFICACIN DE RIESGOS
El primer paso en la gestin de riesgos es la identificacin de los factores que introducen un riesgo en un proyecto informtico. Los riesgos ms habituales en un proyecto informtico son: 1. Cambios en los requerimientos 2. Meticulosidad en requerimientos o de los informticos que realizarn el proyecto. 3. Escatimar en la calidad 4. Planificaciones demasiados optimistas 5. Diseo inadecuado 6. Sndrome de la panacea 7. Desarrollo orientado a la investigacin 8. Personal mediocre 9. Errores en la contratacin de outsourcing o personal externo 82/86
Manual Terico
10. Diferencias entre los informticos y los usuarios Otros riesgos que vale la pena identificar pueden clasificarse as: En la planificacin: 1. Planificacin que no incluye tareas necesarias. 2. La planificacin se ha basado en la utilizacin de personas especficas que no estn disponibles 3. Presin excesiva en la planificacin reduce la productividad 4. Un retraso en una tarea produce retrasos en cascada en tareas dependientes Organizacin y gestin: 1. El proyecto carece de un promotor efectivo en los superiores 2. El proyecto languidece en el inicio difuso 3. Los despidos y reducciones en la plantilla reducen la capacidad del equipo 4. La Direccin insiste en tomar decisiones tcnicas que alargan el tiempo de desarrollo 5. Las tareas no tcnicas encargadas a terceros toman ms tiempo del esperado (aprobacin de presupuesto, aprobacin de adquisicin de materiales, etc.) Entorno de desarrollo: 1. Los espacios no estn disponibles en el momento necesario 2. Los espacios estn disponibles pero no son adecuados 3. Los espacios estn sobreutilizados, son ruidosos o distraen 4. Las herramientas de desarrollo no estn disponibles en el momento deseado 5. Las herramientas de desarrollo no funcionan como se esperaba o no proporcionan las prestaciones previstas 6. La curva de aprendizaje para la nueva herramienta es ms larga de lo esperado. Usuarios finales: 1. Los usuarios finales insisten en nuevos requerimientos 2. En el ltimo momento a los usuarios finales no les gusta el producto 3. Los usuarios no tienen la infraestructura necesaria 4. Las herramientas de soporte y entorno que tiene el usuario no son compatibles Producto: 1. El requisito de trabajar con varios sistemas operativos necesita ms tiempo del esperado. 2. Trabajar en un entorno de hardware y software desconocido causa problemas imprevistos 83/86
Manual Terico
3. Requisitos rgidos de compatibilidad con el sistema existente necesitan un trabajo extra de comprobacin diseo e implementacin. Personal: 1. La contratacin tarda ms de lo esperado 2. Dificultades en la relacin entre la direccin y el equipo de informticos 3. Falta de motivacin y moral reduce la productividad 4. La falta de especializacin necesaria aumenta los defecto y la necesidad de repetir el trabajo 5. El personal abandona el proyecto antes de su finalizacin 6. Se necesitan personas con habilidades muy especficas que no estn disponibles Obviamente, hay ms, muchos ms!
14.7.5
ANLISIS DE RIESGOS
Una vez que se hayan identificado los riesgos de un proyecto, el siguiente paso es analizar cada riesgo para determinar su impacto. Se puede utilizar el anlisis de riesgos para poder elegir entre varias alternativas de desarrollo, o para gestionar los riesgos asociados con una alternativa que haya elegido. Utilizando el mtodo de Exposicin a Riesgos se estiman la probabilidad de que un riesgo se cristalice, el tiempo que se perdera si eso sucediera y, consecuentemente, la prdida a la que estamos expuestos. Un ejemplo de tabla de estimacin de riesgos es la siguiente:
RIESGO PLANIFICACIN DEMASIADO OPTIMISTA AADIR UN REQUISITO PARA LA ACTUALIZACIN
AUTOMTICA DESDE EL MAINFRAME
PROBABILIDAD DE
PRDIDA
MAGNITUD DE
LA PRDIDA
EXPOSICIN A
RIESGO
50% 5% 35% 15% 25% 10% 30%
5 20 8 15 4 2 5
2. 5 1. 0 2. 8 2. 25 1 0. 2 1. 5
EL USUARIO AADE NUEVAS CARACTERSTICAS DISEO INADECUADO (HAY QUE VOLVER A DISEAR) LA APROBACIN DEL PROYECTO TARDA MS DE LO
ESPERADO
LOS RECURSOS NO ESTN DISPONIBLES EN SU

MOMENTO
LAS NUEVAS HERRAMIENTAS DE PROGRAMACIN NO

PRODUCEN EL AHORRO PROMETIDO
Tanto las probabilidades como la magnitud son estimaciones subjetivas. Pero puede mejorarse su exactitud. He aqu algunas ideas: Disponer de la persona que est ms familiarizada con el proyecto para que estime la probabilidad de cada riesgo. 84/86
Manual Terico
Usar tcnicas de concenso en grupo. Cada persona estima individualmente cada riesgo y luego se discute hasta llegar a una convergencia Utilizar calibracin mediante adjetivos. Primero cada persona elige el nivel de riesgo entre una serie de frases como: muy probable, bastante probable, improbable, muy improbable. Despus se cuantifican estas estimaciones.
14.7.6
CONTROL DE RIESGOS
Una vez identificados los riesgos hay que estar preparado para controlarlos. A continuacin se describen los mtodos de control de los 10 riesgos ms habituales que se enumeraron anteriormente:
RIESGO 1. CAMBIO DE PRESTACIONES MTODOS DE CONTROL USO DE TCNICAS ORIENTADAS AL CLIENTE USO DE TCNICAS DE DESARROLLO INCREMENTAL CONTROL DEL CONJUNTO DE PRESTACIONES DISEO ORIENTADO AL CAMBIO FILTRADO DE REQUERIMIENTOS DESARROLLO CON VENTANAS TEMPORALES CONTROL DEL CONJUNTO DE PRESTACIONES ENTREGA POR ETAPAS PROTOTIPOS DESHECHABLES DEJAR TIEMPO PARA LAS ACTIVIDADES DE CONTROL DE
CALIDAD
2. REQUERIMIENTOS SUPERFLUOS
O PERSONAL INFORMTICO METICULOSO
3. RECORTE DE LA CALIDAD
PRESTAR ATENCIN A LAS BASES DE CONTROL DE CALIDAD 4. PLANIFICACIN DEMASIADO

OPTIMISTA
UTILIZACIN
DE TCNICAS DE ESTIMACIN, ESTIMADORES Y HERRAMIENTAS DE ESTIMACIN
VARIOS
NEGOCIACIONES CONVENIENTES TCNICAS DE DESARROLLO INCREMENTAL 5. DISEO INADECUADO 6. SNDROME DE LA PANACEA DESTINAR TIEMPO SUFICIENTE PARA LA ACTIVIDAD DE DISEO PROGRAMAR LAS INSPECCIONES DE DISEO SER ESCPTICO SOBRE LOS PROBLEMAS DE PRODUCTIVIDAD CONFIGURAR UN PROGRAMA DE MEDIDAS DE SOFTWARE CONFIGURAR UN GRUPO DE HERRAMIENTAS DE SOFTWARE 7. DESARROLLO ORIENTADO A
LA INVESTIGACIN
NO INTENTE INVESTIGAR Y MAXIMIZAR LA VELOCIDAD DE

DESARROLLO AL MISMO TIEMPO
8. PERSONAL MEDIOCRE
PERSONAL CON TALENTO CONTRATAR Y PLANIFICAR LOS MIEMBROS CLAVES DEL EQUIPO
MUCHO ANTES DE QUE COMIENCE EL PROYECTO
PREPARACIN Y CAPACITACIN 9. ERRORES EN LA

CONTRATACIN DE OUTSOURCING O PERSONAL EXTERNO
PEDIR REFERENCIAS ESTIMAR LA CAPACIDAD DEL PERSONAL CONTRATADO ANTES DE

CONTRATARLO
85/86
Manual Terico
RIESGO 10. DIFERENCIAS ENTRE LOS

INFORMTICOS Y LOS USUARIOS
MTODOS DE CONTROL TENER BUENAS RELACIONES CON EL PERSONAL CONTRATADO UTILIZAR TCNICAS ORIENTADAS AL CLIENTE
86/86

Administración de centros de informática

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Administración de centros de informática

Uploaded by

Copyright:

Available Formats

Primera Edicin

ADMINISTRACIN DE CENTROS DE INFORMTICA

Manual Terico| Luis Fernando Zelaya Iras

Administracin de Centros de Informtica

Administracin de Centros de Informtica

10.1 10.2 10.3 11

Administracin de Centros de Informtica

1 CONCEPTOS BSICOS DE ADMINISTRACIN

1.2 LA ADMINISTRACIN UNA CIENCIA O UNA TCNICA?

Administracin de Centros de Informtica

1.3 RELACIN DE LA ADMINISTRACIN CON OTRAS CIENCIAS

1.4 CARACTERSTICAS DE LA ADMINISTRACIN

Administracin de Centros de Informtica

1.5 OBJETIVOS DE LA ADMINISTRACIN

1.6 PROBLEMAS ESPECFICOS DE LOS ADMINISTRADORES

Administracin de Centros de Informtica

2 SISTEMA DE EMPRESA Y SISTEMA DE ADMINISTRACIN

2.1.1 ENFOQUE ESTTICO

Administracin de Centros de Informtica

Componentes del Sistema de un Centro de Informtica

concepcin del servicio

concepcin del procedimiento

2.1.2 ENFOQUE DINMICO

Administracin de Centros de Informtica

Concepcin de productos y procedimientos

Reclutamiento y ajuste del personal Fabricacin

2.2 SISTEMAS DE ADMINISTRACIN

Administracin de Centros de Informtica

2.2.1 SISTEMA DE CONTROL

Funcin: Administrar eficaz y racionalmente los recursos Procedimiento:

Determinacin de un valor para cada variable

Eleccin de una solucin

Medicin de resultados Producto (Plan Estratgico, Polticas y reglas, Decisiones, Informacin)

Evaluacin de las variaciones

Administracin de Centros de Informtica

2.2.2 SISTEMA OPERACIONAL

Funcin: Realizar un producto terminado Procedimiento:

Insumos (Datos, Materiales, Productos semiterminados Energa, etc.)

2.2.3 SISTEMA ORGANIZACIONAL

Administracin de Centros de Informtica

Funcin: Implantar estructuras organizacionales y operacionales Procedimiento:

Insumos (Datos concernientes a los objetivos y los recursos)

Proceso de anlisis y resolucin de problemas

Proceso de concepcin de sistemas

Producto (Organigrama administrativo, Manual de organizacin, Sistemas de informacin internos)

2.3 ELEMENTOS PARA LA CONSTRUCCIN DE SERVICIOS INFORMTICOS

CONVERTI R PARTES Y M ATERI AS PRIMAS EN BIENES TERMINADOS,

PRODUCTOS, I NFORM ACI N, SERVICIOS

Administracin de Centros de Informtica

CAPACIDAD DE COMUNICARSE CON EFICACIA, EN

RELACIONES CON LOS OTROS DEPARTAMENTOS

CAPACIDAD DE DISEAR SERVICIOS Y ANALIZAR Y

Administracin de Centros de Informtica

4 PLANEACIN ESTRATGICA Y OPERATIVA

Recursos Humanos y financieros?

Administracin de Centros de Informtica

4.2 OBJETIVOS DE LA PLANEACIN

4.3 DEFINICIONES DE LOS COMPONENTES DE LA PLANEACIN

Administracin de Centros de Informtica

Administracin de Centros de Informtica

Administracin de Centros de Informtica

Administracin de Centros de Informtica

4.4 ESTRUCTURA DE UN PLAN ESTRATGICO