COMPLEJIDAD GESTIN

Varias caractersticas de los emprendimientos basados en software complicar la gestin. En primer

lugar, software based sistemas son excepcionalmente compleja. De hecho, muchos coinciden en
que "el problema bsico de la computacin es el dominio de la complejidad. "2 porque los
desarrolladores de software

debe hacer frente a problemas complejos, que son individuos generalmente muy inteligentes y
complejas, que tambin complica la frmula de gestin. Aadir el hecho de que los desarrolladores
estn tratando de golpear una mudanza requisitos-y el objetivo por el usuario se obtiene una
mezcla voltil de los problemas de gestin. Estas y muchas otras influencias

contribuir a un fantsticamente alta tasa de fracaso entre software proyectos de desarrollo. El Caos
estudiar, publicado por el Standish Grupo, que se encuentra que el 26 por ciento de todos los
proyectos de software fracasan (abajo del 40 por ciento en 1997), pero el 46 por ciento sufren
costes y retrasos o reducido significativamente funcionalidad (frente al 33 por ciento en 1997) .1

________________________________________________________________

Por supuesto, incluso una revisin detallada de estos pueden

dejarle con la duda que hay de nuevo here.Not mucho-

esto es de sentido comn, la gestin bsica stuff.And

sin embargo, estos principios no se emplean comnmente. Si

que eran, no veramos esas altas tasas de fracaso.

EMPIEZA EN EL PIE DERECHO

Es difcil llamar a cualquiera de estos factores ms importantes,

ya que son todos crticos para el xito de

esfuerzos de desarrollo grandes. Sin embargo, conseguir un proyecto

configurar y empezar adecuadamente sin duda, lleva a esta

clase de factores. As como es difcil de cultivar fuerte

plantas en el suelo dbil, es casi imposible con xito

conducir un esfuerzo de desarrollo que se ha configurado de forma incorrecta.

Tom Field analiz dificultades en el desarrollo de software

esfuerzos y dieron 10 signos del proyecto de fortalecimiento institucional

fracasos-por lo menos siete de los cuales se determinan totalmente

antes de que un diseo se desarroll o una lnea de cdigo

se written.3 Por lo tanto, 70 por ciento de la de condena

actos se producen antes de que comience una acumulacin.

Aqu hay 10 signos del fracaso del proyecto es: 3

1. Los gerentes de proyecto no entienden los usuarios '

necesidades.

2. est mal definido el alcance del proyecto.

3. Cambios en el proyecto se gestionan mal.

4. Los cambios en la tecnologa elegida.

5. negocio necesita un cambio.

6. Los plazos son realistas.

7. Los usuarios son resistentes.

8. Patrocinio se pierde.

9. El proyecto carece de las personas con adecuada habilidades.

10. Gerentes ignoran las mejores prcticas y lecciones aprendido.

Dada esta informacin, qu podemos hacer para conseguir proyectos a un comienzo exitoso?

Establezca objetivos realistas y expectativas, para todo el mundo El primer objetivo en conseguir
un proyecto fuera de un buen comienzo es hacer que todos en la misma longitud de onda. Gestin,
usuarios, desarrolladores, y los diseadores deben todos tener expectativas realistas. En

El elemento ms importante en la seleccin de las personas es creacin de un entorno en el que

puedan sobresalir, y que le permite centrarse ms en la tecnologa de equipo dinmica. Usted no
quiere un equipo de clones, pero no quiero que la gente que son compatibles entre s y con el
entorno de la empresa y el equipo de usted se est esforzando para establecer. Por ejemplo, un
marriedwith-

nios y relajado, de nueve a cinco desarrollador podra no funcionar bien en un equipo de jvenes,
solteros, contundente siete-once desarrolladores. Este no quiere decir que el primero es cualquier
menos cualificado o productivo.

En realidad, eso desarrollador relajado puede producir mejor cdigo y ser ms productivos que el
resto de la grupo. Si usted piensa que la primera persona trae un calmante, centrado influencia sin
que ninguna de "lado", convirtindose en excesivamente frustrado, tal vez es una buena opcin
despus de todo. en

De todos modos, usted debe tomar estos factores en consideracin cuando la construccin de su
equipo. Siempre que sea posible, y por lo general es posible, involucre clientes y usuarios de la
development.Not slo puede esto ayudar a construir mayores niveles de confianza entre
desarrolladores y usuarios, sino que tambin pone de dominio expertos dentro de alcance de la
mano de los desarrolladores durante todo el desarrollo. Esto aumenta la probabilidad que va a
desarrollar un producto que satisfaga al usuario

requisitos.

Darle al equipo lo que creen que necesitan Una vez que usted ha construido un equipo fuerte,
debe siguiente dotarlo de un entorno que fomente la productividad y reduce al mnimo las
distracciones. En primer lugar, hacer su mejor para concertar tranquilas, oficinas productivas. Este
es a menudo imposible debido a la mayora de las realidades empresariales, pero un ambiente
cmodo oficina puede producir dramtica resultados. Ambientes altamente productivos contienen
pizarras blancas, reas de reuniones (formales e informales), zonas de oficinas privadas, y las
instalaciones de laboratorio flexibles y modernas.

Aadir elementos de confort tales como equipos de msica, reguladores de luz, mquinas de caf
y sillas cmodas; usted va a crear un ambiente donde la gente puede centrarse en su trabajo y
olvidarse del resto del mundo. Una vez que tenga un equipo con una oficina productiva espacio,
necesita el equipo adecuado. No lo hagas por cualquier razn escatima en equipo. La diferencia
entre mquinas con tecnologa de ltima generacin y desarrollo adecuado sistemas es menos de
$ 1,000. Usted probablemente pasar por lo menos 100.000 dlares al ao para mantener un buen
desarrollador, incluyendo salario, bonificaciones, beneficios, capacitacin y otros gastos
relacionados. Eso adicional $ 1.000 amortizado ms de dos aos representa menos

Calidad

No se puede volver atrs y aadir calidad. Para el momento Puedes calcular usted tiene un
problema de calidad, es probable que sea demasiado tarde para arreglarlo. Establecer
procedimientos y expectativas por los altos niveles de calidad antes de cualquier otra desarrollo
comienza y los desarrolladores de alquiler demostrado desarrollar alta calidad code.Have los
desarrolladores participan en las revisiones de cdigo a nivel de pares regulares y externa
revisiones.

Invariablemente, cuando un proyecto es de crucero a lo largo, todo el mundo se excita, los

informes de estado se ven muy bien, y la interfaz grfica es impresionante, todo va mal. Hay puede
ser un mal informe de prueba, una demo fallado, o una pequea por peticin de cambio por parte
del cliente que se convierte en la piedra que se inicia una avalancha. Arregla un bug, o hacer un
cambio, y causar dos ms. De repente, el equipo de desarrollo que estaba haciendo fantstico el
progreso est sumido en la reparacin y modificacin de cdigo que ha estado en el banco durante
meses.

Gestin Gestionar su producto ms de su personal. Despus de todo, el producto es lo que estn

vendiendo. As que, si su cultura corporativa puede manejarlo, no te preocupes los cdigos de
vestimenta o de horas de trabajo fijos. Reljese y deje que la gente entregar las cosas en el ltimo
minuto. Luego criticar su productos. Si los productos no son aceptables, se puede empezar a
trabajar con los individuos para mejorar su productos. El objetivo aqu es no hacer cuestiones
individuales problemas del equipo. El hecho de que una o dos personas Quieres entrar a las 10:00
am y trabajar hasta las 5:00 pm, abusando de la flexibilidad que se da, no significa usted debe
humedecer el ambiente para el conjunto equipo. Con demasiada frecuencia, el proyecto lleva
evitar confrontar la individuos y simplemente "arreglar" el problema mediante el establecimiento
de las reglas del equipo arbitrarias. Pronto, todo el mundo se quejaban de compaeros de trabajo
desviadas y la gestin estricta. Esos son los sonidos de impulso escapando. Enrolle algunas de estas
decisiones juntos, y el equipo pronto se enfocaron ms en evitar las reglas o acusar a los
delincuentes que en la produccin de un producto de calidad. Cuando usted tiene un problema
personal legtimo, tratar con l rpidamente. Si tiene que dejar que alguien ir, hacerlo rpidamente
y luego se reunir con su equipo para explicar lo que pas. Mientras usted est siendo

_____________________________________________-

protocolo. Mala decisin. Utilice siempre las bibliotecas comerciales cuando est disponible, y
nunca tratar de crear una nueva comunicacin protocolo. A lo sumo, que le costar una fortuna.

En el peor, se hundir su proyecto.

Las personas tambin hacen consistentemente malas decisiones en la seleccin de tecnologas. Por
ejemplo, cuntas personas eligi para desarrollar aplicaciones para la plataforma Next?

La mayora nunca terminaron sus aplicaciones antes de esa plataforma fue. Cuando usted toma
una fundamental tecnologa, ya sea un motor de base de datos, de funcionamiento protocolo del
sistema, o de comunicaciones, debe hacer un negocio y un anlisis tcnico. Si el la tecnologa no es
la captura de la cuota de mercado y si un empresa sana no lo soporta, usted est construyendo su
proyecto en un cimiento de arena.

Debido a que su previsin es falible, utilizar su diseo para aislar a s mismo de la tecnologa
subyacente.

Encapsular la interfaz de nuevo o tecnologas tanto como sea posible del lugar. Piense qu
tecnologas sern propensos a cambiar con el

toda la vida y disear la aplicacin de su producto para aislar a un nivel prctico y su cdigo de
esos cambios.

Usted tendr muchas oportunidades para hacer buenas decisiones como la que negocian las
necesidades del cliente.

Esforzarse para mover los requisitos de la complicado ", ha nunca hecho antes" categora a el
"estado all, hecho que" la categora. Menudo, los usuarios Solicitud de cosas que son
marginalmente valioso sin la comprensin de la complejidad. Explicar las ramificaciones de las
necesidades y requisitos complicados los cambios en trminos de costo y cronograma. Ayuda estas
personas le ayuden.

ANLISIS POST-MORTEM

Pocas empresas institucionalizar un proceso para aprender de sus errores. Si usted no toma tiempo
de averiguar lo que pas durante un proyecto, tanto el bien y el mal, que estn condenados a
repetirla.

Qu se puede aprender de un anlisis post-mortem?

En primer lugar, usted aprender por qu sus estimaciones de horario estaban fuera. La
compensacin de esos factores en la prxima proyecto mejorar dramticamente su estimacin
tcnicas. Un post-mortem tambin le ayudar a desarrollar un perfil de cmo su equipo y de la
empresa se desarrollan sistemas de software. La mayora de empresas y equipos tienen
personalidades que impactan fuertemente el desarrollo ciclo. Al pasar por post-mortem

____________________________________________________-

dominio. Sin embargo, esta no es una lista exhaustiva- muchos otros factores influyen en el xito
de la gestin de un esfuerzo de desarrollo de software. Pero si a dominar estos cinco, que
aumentan en gran medida las probabilidades de completar su proyecto a tiempo y dentro del
presupuesto. Igual de importante, a maximizar sus posibilidades de de hecho la entrega de algo
que sus usuarios quieren. v