Estimar tiempos de desarrollo

[AzidRain]

A ver mis estimados delphineros...Voy a inicar un proyecto de software administrativo (gestión para los españoles) y aunque quisiera hacerlo como Dios manda (hacer análisis, diagramación, etc.) creo que no voy a poder hacerlo así y tendré que hacerlo como creo acostumbramos muchos..al vuelo.

Bien pues: El sistema en cuestion es para administración de empresas de autotransporte de carga consolidada (tipo paqueteria) y constara de lo sig .modulos:

* Facturacion
* Cuentas por pagar
* Cuentas por cobrar
* Bancos
* Tráfico
* Liquidación a operadores (gastos de viaje)
* Contabilidad
* Bodega (entradas y salidas)
* Rastreo de envíos y acuse de recibo
* Taller y llantas

Usando:

Delphi 6.0
Zeos
MySQL

Mas lo que se acumule.

Lo que me cuesta trabajo es estimar el tiempo de desarrollo ya que en función de eso es lo que voy a cobrar, cabe mencionar que es un desarrollo a medida pero con miras a poder venderlo después. Para evitar eso de modificaciones y adiciones interminables de un solo modulo planeo hacer una especie de "iteraciones" en el sistema completo, es decir, tratar de desarrollar todo aunque sea muy simple o "feo" y ya que funcione, volver a ir revisando los cambios que hayan salido durante el primer desarrollo y asi sucesivamente.

Planeo liberarlo Open Source al final una vez terminadas todas las modificaciones o "embellecimientos" y vender unicamente el soporte y mantenimiento del código.

A ver quien me ayuda a calcular un tiempo estimado...no hay prisa

Y claro aunque no es un hilo para el foro de "trabajo" si alguien quiere ayudar bienvenido...
Saludos.

[egostar]

Existe un modelo llamado COCOMO (http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm) donde puedes darte una idea sobre tu problematica, ve al apartado Estimación del esfuerzo que supongo es el que te interesa.

Obviamente, es un modelo llamese "ideal", pero recuerda que todo es relativo pero creo que si te puede ayudar mucho.

Saludos.

[Neftali [Germán.Estévez]]

...y aunque quisiera hacerlo como Dios manda ... ...y tendré que hacerlo como creo acostumbramos muchos..al vuelo.

¿Y la razón cual es?

Soy de la opinión de que "perder" un tiempo en un buen análisis, te reportará menos tiempo de programación.

[Neftali [Germán.Estévez]]

Lo que me cuesta trabajo es estimar el tiempo de desarrollo ya que en función de eso es lo que voy a cobrar...

Para esto hay un sistema que se conoce como "Métricas de Software" o "Métricas para Sistema Informáticos", que básicamente es un sistema empírico de calcular tiempos (y a partir de ahí costes y demás) de desarrollo de aplicaciones. Se supone que se hace un coste a partir del análisis y luego dependiendo del lenguage de programación (y algun otro parámetro) se evaluan tiempos, y costes de desarrollo.

A parte de eso, hay aplicaciones (como ya te han comentado) que te permiten hacer un análisis detallado, aunque no son sencillas. Ya te han comentado COCOMO; También puedes buscar información sobre CANTATA o CODECHECK.

Puedes darte una vuelta por la página de la "Asociación Española de Métricas en Sistema Informáticos (http://www.aemes.org/)"; Encontrarás mucha información y seguro que más referencias.

También puedes echarle un vistao a esta página (http://www.geocities.com/gimenezpy/); No es tan técnica, pero explica las cosas bastantes claras, e incluso tienen algun ejemplo práctico de estimación por puntos de función.

Y éste documento PDF (http://www.inegi.gob.mx/inegi/contenidos/espanol/prensa/Contenidos/Articulos/tecnologia/puntosxfuncion.pdf), también está muy bien. En el título reza: "No puedo controlar, lo que no puedo medir"

Si buscas por Internet, seguro que encuentras más...

[AzidRain]

Soy de la opinión de que "perder" un tiempo en un buen análisis, te reportará menos tiempo de programación.

Estoy totalmente de acuerdo ya ha habido variosc asos en que le invierto tiempo al análisis y a la hora de codificar todo es como en automático, pero en estos casos normalmente el cliente quiere ver resultados casi de inmediato y poco se entiende que implica hacer un análisis previo. En ocasiones el "análisis" según el cliente no es más que unas cuantas entrevistas y comentarios sobre lo que necesita y con eso hay que trabajar. Algunos incluso quieren un prototipo en unas cuantas semanas...Definitivamente un diseño a la medida implica mucho análisis pero esto a su vez requiere tiempo que se traduce en costos que muchos clientes no están dispuestos a pagar.

Otra cosa muy mala es que al menos aqui en Córdoba, México; el mercado esta muy devaluado gracias a muchas empresas y programadores que con tal de aprender en el intento ofrecen sus servicios muy baratos por lo que muchas veces un buen sistema, bien planeado y organizado les resulta muy caro a los clientes si lo comparan con lo que hacen otros (sin planeación, al "ahí se va", o con herramientas de cuarta ).

En fin, finalmente quisiera apoyarme en la experiencia de ustedes que probablemente han hecho alguno de los módulos por aqui mencionados.

[mamcx]

Estimar tiempos no es *tan* dificil. De hecho es muy, muy simple. Lo que pasa es que a veces uno le presta atencion a metodologias que estan hechas para tipos de desarrollo o tamaños de equipos de desarrollo diferentes... y no cuadran.


Yo he aplicado unas cuantas ideas y en casi todos los proyectos que he trabajado he acertado con un margen de error de 2 meses, que no esta mal ;):

- Primero, hay que tener un taller que se preste para ser productivo:

-- No es discutible el uso de control de codigo
-- No es discutible herramienta de guardar bugs y tareas

http://bdn.borland.com/article/33656

http://local.joelonsoftware.com/mediawiki/index.php/El_Test_de_Joel:_12_pasos_hacia_un_c%C3%B3digo_mejor#.C2.BFTienes_una_base_de_datos_para_los_bugs.3F

Armarse de herramientas y montar todo (al menos: subversion + bug tracking + probemos como es la vuelta) toma 1 semanita. Y paga todo el año en dividendos.

Aprender a usar nant, want o lo que sea y hacer el primer instalador en un solo tiro es 1 semanita, contando el producto mas grande que me ha tocado.

- Segundo, armar un cronograma es ASI DE FACIL:

http://www.joelonsoftware.com/articles/fog0000000245.html

Eso toma un par de minutos por cada punto y puede gastarse unos 3 o 4 dias. Pero es algo dinamico, porque al ir entrando en codigo o ir viendo la cosa se da uno cuenta que falto esto o aquello. Asi que vas actualizando.

Todo proyecto importante toma 1 año, minimo. Con esto, tendras una certeza de +/- 2 meses para la primera vez y eso si sos tan desorganizado e indisciplinado como yo...

-- Como hacer las especificaciones:

http://spanish.joelonsoftware.com/Articles/PainlessFunctionalSpecifi-2.html

[Neftali [Germán.Estévez]]

Estimar tiempos no es *tan* dificil. De hecho es muy, muy simple.
Hombre haciéndolo con tu sistema sí que es simple.
Tiempo de desarrollo = 1 año. ¡¡Y t' has quedao tan fresco!!



Yo he aplicado unas cuantas ideas...
...
==> Armarse de herramientas y montar todo... (al menos: subversion + bug tracking + probemos como es la vuelta) toma 1 semanita.
==> Aprender a usar nant, want o lo que sea y hacer el primer instalador en un solo tiro es 1 semanita, contando el producto mas grande que me ha tocado.
==>...Eso toma un par de minutos por cada punto y puede gastarse unos 3 o 4 dias.


Estamos hablando de Tiempos de Desarrollo de un proyecto.
El tema Subversión, control de Bugs, nant, want, ... está muy bien y tu artículo en BDN también, pero no creo que sean cosas que debas incluir en una temporización de un proyecto.
Estamos hablando de tiempos de desarrollo para cobrarle a un cliente debidamente especificados; No un papel que ponga:

Tiempo desarrollo = 1 año.
Precio = $$$$ €

Estás hablando de cosas que deberás tener montadas tú por tu cuenta si es que deseas utilizarlas, pero no tienen nada que ver con un proyecto, ni puedes cobrar por ellas a un cliente.

...Lo que pasa es que a veces uno le presta atencion a metodologias que estan hechas para tipos de desarrollo o tamaños de equipos de desarrollo diferentes... y no cuadran.

Sinceramente me parece un poco "despectivo" ese comentario respecto a este tipo de metodologías. Si estamos hablando de un proyecto de 1 año, no creo que sean desdeñables. Aunque está claro que con tu sistema siempre será más rápido de calcular.

[mamcx]

Hombre haciéndolo con tu sistema sí que es simple.
Tiempo de desarrollo = 1 año. ¡¡Y t' has quedao tan fresco!!


En mi experiencia, ese es un tiempo realista para un proyecto serio, y en base al tipo de aplicacion de la que se esta hablando no es para nada desfasado. Ahora, estoy hablando de un tiempo para un desarrollador solito o si acaso con otro.

Anteriormente y aun mas fresco, yo decia "En 3 meses esta!" e igual se demoraba 1 o 2 años. Es mejor ser pesimista y decir 1 año, y trabajar con ahinco y organizacion y sacarlo en 6 meses, que lo contrario ¿no?. Y como en el caso presente no hay ninguna informacion concreta ¿que mas se puede estimar? que se va a tomar mucho tiempo... puede que a la hora de la verdad sea menos pero hasta no sacar un calculo no se sabe.


Estamos hablando de Tiempos de Desarrollo de un proyecto.
El tema Subversión, control de Bugs, nant, want, ...


Bueno, pongamoslo de esta manera (ya se que toda comparacion es imperfecta):

Si vas a construir un carro y no tienes taller, no tienes planos, no tienes maquinaria adecuada, no tienes experiencia suficiente para saber que se necesita y todo tus trabajos anteriores han sido "machetazos"

VS.

Todo lo anterior

Quien se tomara *menos* tiempo? De verdad no influye el tipo de "taller" que se tenga? Quien puede mas? El del serrucho o el de la sierra electrica? Subversión, control de Bugs, nant, want (o sus alternativas) son sierras electricas.

Yo antes creia que estas cosas no valian o lo hacian por otras razones, pero he visto que tener un sistema de CVS y un lugar donde anotar los problemas, tareas y demas, automatizar los builds y las pruebas de errores son generadores de eficiencia y mejoran de forma realista los tiempos.

La primera vez que lo implemente, estaba atrasado 1 año en el desarrollo, no tenia la mas minima idea de que faltaba, no podia entregar nunca un instalador a tiempo, no sabia que errores tenia (mas alla de lo que tenia en memoria), tenia el jefe encima, los testers y estaba ya agotado de todo eso.

No teniendo nada mas que perder, le saque 1 mes a todo esto y logre terminar en unos 2 meses y llegue al punto de scar un instalador con 0 defectos (importantes) en menos de 15 minutos a cualquier hora del dia, cuando me lo pedian. Y por fin, pudimos saber y estimar cuando acabar y no me descache por mas de 1 mes, que no estuvo tan mal.

Asi que esas cosas son indicativos profundos de si se acaba o no en x tiempo? No tengo la mas minima duda.


Estás hablando de cosas que deberás tener montadas tú por tu cuenta si es que deseas utilizarlas, pero no tienen nada que ver con un proyecto, ni puedes cobrar por ellas a un cliente.


Claro, uno no le cobra a los clientes por tener esas herramientas (y las que recomende en el articulo como las que uso personalmente son todas gratuitas), pero el no tenerlas le pasa factura al cliente, de forma indirectas...


Sinceramente me parece un poco "despectivo" ese comentario respecto a este tipo de metodologías.

Aqui vale una aclaracion: No se cuales son las metodologias que se mencionaron y tampoco me referia a ellas... la verdad es que mas bien me acorde de cuando empeze hace mucho con la metodologio de Rational,la de cascada y otras que la verdad son practicamente imposibles para un equipo de menos de 5.

El comentario, en su espiritu, es acerca de verificar que la metodologia a elegir este adecuada para el tamaño y tipo de desarrollo.

--------------------

Ahora lo importante es entender que no es en si las "herramientas" o "metodologias" las que por si solas resuelven este tipo de problemas. Algo tan *simple* como hacer un cronograma de trabajo en excel ya es una gran mejora. Lo importante es hacerse a la mentalidad que si se puede, y no permitir que las excusas que abundan sean un impedimiento.

Resumiendo la idea que expone Joel, es hacer esto:

- Pones una descripcion general del proyecto, nada mas te das ideas...
- Sacas una lista de todas las tareas que haya que hacer. El truco es no poner tareas que uno diga "las hago en 1 semana" porque esas siempre son falsas. Mas bien tareas pequeñas (creo que la hago en 1 hora). Eso implica que la lista sera mas bien larga. Lo que implica que si no se quiere que sea *tan* larga entonces hay que recortarle. Luego, ese es un tiempo realista.

Le sumas vacaciones, tiempos enfermos, tiempos con problemas en el equipo, visitando a los padres , navegando en foros, hablando con clientes, hablando con la mama, etc...

Y ese es el verdadero tiempo.

Luego, ajustar la lista diariamente y anotar los avanzes.

Por ejemplo, esta es mi lista para esta semana:


Issue ID Component Type Priority Summary Status Resolution
PARA-42 Clases Internas Nueva caracteristica Normal Permitir envio noticias y eventos.... Asignado Sin resolver
BIZ-40 Clientes Vulcano Tarea Normal Hacer cambios desing center Asignado Sin resolver
BIZ-19 Clientes Vulcano Tarea Importante Pasar sitio tipalma En progres Sin resolver
THIS-35 Clases Nueva caracteristica Trivial Convertidor de imagenes Asignado Sin resolver
THIS-39 Clases Nueva caracteristica Trivial Empaquetador Asignado Sin resolver
THIS-38 Clases Nueva caracteristica Trivial Convertidor Texto Asignado Sin resolver
THIS-37 Clases Nueva caracteristica Trivial Convertidor documentos Asignado Sin resolver
THIS-36 Clases Nueva caracteristica Trivial Convertidor Video Asignado Sin resolver
THIS-34 Documentacion Nueva caracteristica Trivial Definicion del proyecto En progreso Sin resolver
PARA-24 Clases Internas Nueva caracteristica Importante Agregar ingreso y login para restaurantes Asignado Sin resolver 06 Nov 2006 12 Nov 2006
PARA-23 Clases Internas Nueva caracteristica Trivial Reestrucuturar entrada de categorias y tags Asignado Sin resolver 02 Nov 2006 30 Nov 2006
PARA-29 Clientes Nueva caracteristica Normal Envio de noticias a los visitantes Asignado Sin resolver 07 Nov 2006 09 Nov 2006
PARA-28 Clases Internas Nueva caracteristica Normal Habilitar jhonBot Asignado Sin resolver 09 Nov 2006 17 Nov 2006
PARA-26 Clientes Nueva caracteristica Trivial Pagos en linea Asignado Sin resolver 21 Nov 2006 10 Dec 2006
PARA-25 Clientes Nueva caracteristica Trivial Automatizar envio de informes a los clientes Asignado Sin resolver 13 Nov 2006 15 Nov 2006


Noten que tiene fecha de finalizacion, y en que etapa van. Aqui esta correcion de errores, tareas pendientes, cosas que me gustaria hacer (esas son las que no tienen fechas). A cada tarea le estimo un tiempo (nunca pongo una tarea que me gaste mas de 6 horas) y luego le voy poniendo cuanto me demoro...

[egostar]

Quien se tomara *menos* tiempo? De verdad no influye el tipo de "taller" que se tenga? Quien puede mas? El del serrucho o el de la sierra electrica? Subversión, control de Bugs, nant, want (o sus alternativas) son sierras electricas.

Pues esto también tiene sus asegunes,

Usando tu metáfora del serrucho y la sierra eléctrica

Tenemos lo siguiente:

El que usa el serrucho sabe perfectamente como usarlo en la madera
El que usa la sierra eléctrica sabe poco o nada de como usarlo en la madera

Surgen las siguientes preguntas:

1. ¿Quien será mas rápido para terminar el corte?
2. ¿A quien le quedará mejor el corte?
3. ¿Cuantas veces se tiene que cortar la madera para que quede un corte perfecto?

Entonces si podemos preguntar:

¿Quien se tomara *menos* tiempo?

Y yo agregaría, ¿Quien entregará un mejor trabajo?

Ahi al dejo para la reflexión.

Saludos

PD, Estuve tentado a abrir esto en una Encuesta :D :D :rolleyes:

[AzidRain]

Estoy de acuerdo, se supone que cuando uno ofrece sus servicios el cliente espera que contemos con lo necesario para llevarlo a cabo. Ya me veo platicándole de subversiones, iteraciones y demás a algún cliente. Normalmente te piden resultados en el menor tiempo posible, más aun si el cliente no tiene ni idea de la computadora salvo para entrar a su correo o ponerse a chatear.

Curiosamente en el caso de este sistema que tengo que hacer, una empresa grande http://www.macropro.com.mx (http://www.macropro.com.mx/) le ofreció su sistema, que de hecho es un paquete comercial y adivinen en que esta hecho...COBOL!! si como lo oyeron. Sobra decirles todo lo que se le puede mejorar usando Delphi.

Pero volviendo al tema, la metodología que utilice uno para llevar a cabo el proyecto es lo de menos, finalmente hay que decidir un tiempo razonable para llevarlo a cabo. En los desarrollos a medida el cliente sabe que no es como hacer una aplicación comercial porque el producto al final solo le servirá a él y contendrá todos los caprichitos de él y su gente; por ello es relativamente sencillo convencerlo de que se lleva su tiempo. Lo importante es que se vayan viendo avances concretos y que al final tengamos una aplicación que no le pida nada a una comercial.

En lo personal acostumbro hacer mis aplicaciones lo más "comerciales" posibles, es decir, con apariencia, íconos y demás dignos de cualquier paquete. Muchas veces esta es la única forma en que el cliente aprecia la calidad del trabajo sin importar que por dentro tenga implementados los mejores algoritmos creados hasta el momento. Claro que si uno tiene creatividad le puede añadir cosas novedosas o que no hacen otros sistemas (y deberían).

De ahi la dificultad de estimar tiempos correctamente, si estima uno muy bajo corre el riesgo de quedarse colgado que no de tiempo, asi que estoy de acuerdo con que hay que dar un margen razonable. Pero volvemos a lo mismo...que tiempo se requiere??.

Estamos hablando como decían en un post de " trabajar con ahínco"

[Casimiro Notevi]

Yo estoy total y absolutamente de acuerdo en lo que comenta mamcx, incluso iba a decir el mismo tiempo, pero pensé que más de uno se iba a exaltar. En mi caso, para un proyecto así, daría al menos 1 año y además cubriéndome las espaldas por si acaso se tarda más.
Porque no es algo simple lo que se tiene que hacer, son muchísimas cosas:

* Facturacion
* Cuentas por pagar
* Cuentas por cobrar
* Bancos
* Tráfico
* Liquidación a operadores (gastos de viaje)
* Contabilidad
* Bodega (entradas y salidas)
* Rastreo de envíos y acuse de recibo
* Taller y llantas
Tan sólo para una buena Contabilidad ya son varios meses.


Por supuesto, estamos hablando de un buen software, multiusuario, cliente/servidor, seguro, estable, rápido, ágil, presentable, profesional, bien acabado, con opciones de backups, configuración general, recuperación de bases de datos dañadas, un buen programa instalador (más aún si luego va a vender el soft a otros), ayudas, manual en línea, todo bien probado, afinado, etc...

Todavía se me pone la piel de gallina cuando recuerdo uno de mis primeros proyectos grandes... 4 meses le dije al cliente, le preparé un dossier muy completo con todo lo que iba a llevar, le hice un presupuesto y le especifiqué la forma de pago. Lo terminé justo en 4 meses... y un año, !!! me equivoqué en un año !!!
Fue la primera vez que me equivoqué al estimar un tiempo de entrega y me dije: "la primera vez... y la última". Desde entonces siempre doy tiempo con margen, hago un buen análisis y no me "pillo los dedos".

Y si alguien le entrega un presupuesto más barato y en menos tiempo... que lo haga el otro, ya lo sufrirá y al final puede incluso que al cabo de un año te vuelva a llamar para hacer algo decente porque estará escarmentado de haber elegido al otro. :D

[mamcx]

De ahi la dificultad de estimar tiempos correctamente, si estima uno muy bajo corre el riesgo de quedarse colgado que no de tiempo, asi que estoy de acuerdo con que hay que dar un margen razonable. Pero volvemos a lo mismo...que tiempo se requiere??.

Estamos hablando como decían en un post de " trabajar con ahínco"

El punto es, ESO NO SE SABE. Un año puede ser... seguro que 1 dia no es.

Como saber el tiempo? Prestale atencion a los enlaces que se te han dado. Empieza con el Joel que es el mas facil de digerir y luego sigue con los otros.

Como estimar. Es muy facil. Pero es un poco tedioso. Mejor pongamos un ejemplo (estimando una facturacion):

* Facturacion


Base de datos : Crear tabla Encabezado Facturas 30 minutos
Base de datos : Crear tabla Detalles Facturas 30 minutos
Clases : Crear clases de consultas genericas sql 2 horas
Clases : Crear manipulador de facturas 1 hora
Clases : Poner tabla facturaciones en modulo datos y configurar 5 minutos
Pruebas : Crear un metodo para llenar la tabla con datos prueba 10 minutos
Clases : Metodo calcular impuestos 30 minutos
Clases : Metodo calcular totales y subtotales 50 minutos
GUI : Armar formulario de facturacion y poner bonito 2 horas
GUI : Animar los calculos 1 hora
Pruebas : Probar crear, actualizar y borrar facturas 5 horas
Pruebas : Probar calculos sobre facturas con 1000 items 2 horas
Pruebas : Probar ingresos datos invalidos 5 horas
Clases : Cargar datos de cotizacion previa 1 hora
Pruebas : Cargar datos de cotizacion previa 1 hora
bla
bla
bla


Esto es una lista de pasos que hay que hacer para una facturacion (mas o menos) con tiempos aproximados de implementacion. Cuanto dio todo eso?

12 1/2 horas.

Eso es, tiempo de corrido, tiempo sicopata de un tipo como loco programando. Que le falta a esa lista? prioridades y fechas entre las cuales se hace la tarea. Ej:


Base de datos : Crear tabla Encabezado Facturas Crucial Hoy
Base de datos : Crear tabla Detalles Facturas Crucial Mañana
Clases : Metodo calcular impuestos Crucial El viernes
GUI : Animar los calculos Capricho Algun dia
bla
bla


Ahora si es una lista realista...

Se puede saber que GUI : Animar los calculos se puede desechar y se ahorra 1 hora que seguro se volveran 5. Se sabe que es mas importante y se hace primero y que esas 12 horas deben distribuirse entre hoy y el viernes.

Y aqui faltan muchos mas pasos. Y fueron tiempos que me invente, al azar y no reflejan lo que puedes hacer o puede hacer tu equipo. Y no tiene encuenta codigo y clases que puedas usar. Y no tiene en cuenta que para haber llegado a facturacion paso muchas cosas mas antes. Y no reflejan problemas de comunicacion entre tu equipo. No hay tiempos de integracion (juntar clases). No estan las tareas de reportes. No esta la documentacion. No estan las ayudas. No tienen en cuenta tiempos de vacaciones, festivos, horas de almuerzo, etc...

Verdad que se hace el ejercicio y se empieza a ver grandota la cosa?

Hacer la primera estimacion es la mas tediosa... pero a partir de alli todo se va facilito. La 2da reusa datos de la primera (como periodos que no se trabajan) y se obtiene experiencia que aumenta la exactitud.

Pero si lo analizas, es muy facil... solo que la 1era vez toma tiempo. Es solo cojer cada pedacito y se estima.

Cuanto se demora hacer el modulo de facturacion? Ni idea. Incluso si has hecho modulos de facturacion antes.

En cambio...

Cuanto demora hacer una tabla de encabezado y detalle? Aaaa... eso si se puede saber. 1 hora o 15 minutos... dependiendo de lo veloz de cada uno.

La moraleja es que los pasos *pequeños* son estimables. Los pasos grandes son *adivinatorios*. Hay que *adivinar* para hacer un modulo de facturacion pero si se puede *estimar* la creacion de una tabla.

[Héctor Randolph]

Y si alguien le entrega un presupuesto más barato y en menos tiempo... que lo haga el otro, ya lo sufrirá y al final puede incluso que al cabo de un año te vuelva a llamar para hacer algo decente porque estará escarmentado de haber elegido al otro.


Palabras muy sabias, si señor. :)

Estoy cansado de los clientes que todo lo quieren deprisa. :mad: De hecho voy a dejar mi empleo actual en tres o cuatro semanas por este motivo. Mi jefe inmediato es el que se encarga de determinar los tiempos de entrega y no tiene idea de cuánto se podría uno demorar. No sé porque razón siempre tiene en mente el número mágico "dos meses son suficientes" y al cabo de un tiempo todos trabajamos enfadados y no se diga los clientes que todo lo quieren para hoy mismo.

Por eso recomiendo no echen en saco roto lo dicho por Casimiro y por Mario, el decir un año puede sonar muy exagerado pero el que quiera azul celeste que le cueste.

Saludos

[AzidRain]

Desgraciadamente el que paga manda...toda la vida...aunque claro no por eso nos vamos a dejar ningunear verdad? A veces los clientes nos presentan verdaderos retos de esos que nos presentan como "yo quisiera tal cosa pero se que no se puede..." y uno pues claro, cae en la tentación de ofrecerse a hacerlo, y luego...zaz! Algo que pensabamos que estaba "papita" (fácil) se complica y lo terminanos en mas tiempo.

A mi me paso con una facturación en clipper alla por los años 90's, precisamente para esta misma empresa que les platicaba, el proyecto era para 6 meses y se llevo un año, y no por la dificultad sino por que se personalizó a tal grado que quedó más que a la medida de lo que necesitaban y claro...orgullosamente ese sistema no ha presentado una sola "caída" desde su implementación, mas de 10 años sin problemas (eso me ayudó para que mi cliente prefiera encargarme a mi los sistemas).

Finalmente estoy estimando un plazo de 18 meses por lo menos para tener un "prototipo" decente que funcione y haga lo más básico (sin adornitos ni nada) y todas las modificaciones o "mejoras" que se le ocurra a mi cliente se trabajaran después según prioridades. Para ello le ofrezco 12 meses mas tras la liberación para "soporte" y cosas pequeñitas que surjan. Trataré de convencerlo de que tendrá al final toda su empresa totalmente sistematizada y sobre todo controlada, cosa que ningún software comercial le puede ofrecer y a ver que tal me va...

Igual y pongo un post del tipo "Mi programa de gestion paso a paso..." como el que puso Delphitest de facturación...O mejor aun pongo el código disponible para quien lo quiera mediante GNU o algun esquema parecido

Veremos...

[Casimiro Notevi]

Palabras muy sabias, si señor. :)

Estoy cansado de los clientes que todo lo quieren deprisa. :mad: De hecho voy a dejar mi empleo actual en tres o cuatro semanas por este motivo. Mi jefe inmediato es el que se encarga de determinar los tiempos de entrega y no tiene idea de cuánto se podría uno demorar. No sé porque razón siempre tiene en mente el número mágico "dos meses son suficientes" y al cabo de un tiempo todos trabajamos enfadados y no se diga los clientes que todo lo quieren para hoy mismo.

Por eso recomiendo no echen en saco roto lo dicho por Casimiro y por Mario, el decir un año puede sonar muy exagerado pero el que quiera azul celeste que le cueste.

Saludos

Más sabe el sabio por viejo que por sabio :)


Por mucha prisa que tenga el cliente, siempre quieren todo para ya, le corresponde a uno mismo pararle los piés.

No recuerdo dónde leí que crear un programa es como el embarazo de una mujer, si tiene que tardar 9 meses, por muchas madres "en paralelo" que pongas, por muchos técnicos que añadas al proyecto, hagas lo que hagas... tardará 9 meses. :)

[Neftali [Germán.Estévez]]

En mi experiencia, ese es un tiempo realista para un proyecto serio, y en base al tipo de aplicacion de la que se esta hablando no es para nada desfasado.

...para un proyecto así, daría al menos 1 año...

En ningun momento he dicho que ese tiempo sea correcto o incorrecto; Lo que me asombra es la facilidad en estimar un tiempo de proyecto de 1 año (con el consiguiente presupuesto en €/$) con sólo ésta especificación:

//·······························································································
El sistema es para administración de empresas de autotransporte de carga consolidada (tipo paqueteria) y constara de lo sig .modulos:
* Facturacion
* Cuentas por pagar
* Cuentas por cobrar
* Bancos
* Tráfico
* Liquidación a operadores (gastos de viaje)
* Contabilidad
* Bodega (entradas y salidas)
* Rastreo de envíos y acuse de recibo
* Taller y llantas
...
Mas lo que se acumule.
//·······························································································
Alucino...:eek::eek::eek: (más aun estando la última frase ahí -subrayada-)
Que puede ser que luego sean 2 años o 6 meses.
==> Podemos decirle 3 años (por lo de curarnos en salud). ;)

...ese es un tiempo realista para un proyecto serio,...estoy hablando de un tiempo para un desarrollador solito o si acaso con otro.

Una leve diferencia, :o que debe afectar al tiempo (creo yo).


Mejor pongamos un ejemplo (estimando una facturacion):
...


Eso ya es otra cosa; Se puede discutir el método, mejorarlo, o utilizar otro, pero ya es algo; Al menos eso sí te dará una estimación y luego podrás argumentar tus tiempos, pero no se puede decir... "Por experiencia le echo un año..."


...Y si alguien le entrega un presupuesto más barato y en menos tiempo...


Creo que tan malo es lo uno como lo otro; Simplemente ambos son incorrectos. Uno trae unas consecuencias y el otro otras, pero una mala estimación nunca es buena; Y considero que es bueno "curarse en salud" con los tiempos, pero sobre un tiempo calculado de forma seria.

[Casimiro Notevi]

Y considero que es bueno "curarse en salud" con los tiempos, pero sobre un tiempo calculado de forma seria.

Por supuesto, antes hay que hacer un estudio en profundidad de lo que se va a hacer. Lo de decir "1 año" es porque con todo lo que se ha especificado, ese tiempo no hay quien se lo quite. (Teniendo en cuenta la poca información con la que contamos para calcularlo)

[AzidRain]

Por experiencia propia he visto que es mejor quedarse sobrado ya que así queda tiempo para implementar nuevas cosillas que en un principio ni a uno ni al cliente se le ocurrieron...A veces un sistema de 6 meses termina en un año pero el cliente queda más que satisfecho por toda la de cosas que se le logran mejorar con respecto a lo que pidió en un principio..Bueno claro, refiriéndonos a clientes de los que son "decentes" para pedir y piden solo lo que creen posible que hagamos (claro, no conocen nuestra capacidad :) ), lo malo es cuando te toca un cliente de los que piden como pedirle a Dios..entonces si cuidado con los tiempos

En el caso que propuse mi cliente me tiene en buen concepto y no tengo muchos problemas ya que siempre les ayudo con algunas pequeñeces y no les cobro como parte del servicio.

Como decia probablemente deje por aqui todo lo que se genere (código y demás) para ver si a alguien le sirve y asi si le piden alguna cosa de ahi pues le sea mas facil estimar sus tiempos pues ya lo tendria...:)

Saludos a todos y grax por los comentarios..