estimation - tag - tipos de etiquetas jsp
¿Cómo le explicas a un vendedor que la programación es realmente difícil y lleva tiempo (8)
Éste puede ser un buen libro para que los que no son programadores comprendan algunos de estos problemas y las dificultades de los requisitos fuera de control:
A menudo trabajo con tipos de ventas y marketing que no pueden entender cómo usar Excel, y mucho menos comprender el alcance de sus solicitudes desde una perspectiva técnica. Por supuesto, no sería justo esperar que lo hagan, pero eso todavía me deja un problema.
¿Cuál es la mejor manera de mostrar los tipos de mercadeo y ventas que han pedido para algo que requiere mucha programación compleja y algo de paciencia?
¿Podría compartir ejemplos de problemas y soluciones?
¿Podría recomendar libros sobre este tema?
¡Gracias!
Asegúrese de comprender sus problemas también. A menudo, las personas aportan soluciones a la mesa ("necesitamos esta característica") en lugar de comenzar con las necesidades del negocio raíz. Cuanto más comprenda el problema, más probabilidades tendrá de sugerir un compromiso.
En ocasiones me han dicho que cierta característica grande es absolutamente esencial, pero he podido implementar soluciones mucho más simples que solucionan sustancialmente el problema. A veces, estas soluciones provisionales se han convertido en características vitales, con la misma frecuencia he podido eliminarlas dos versiones más tarde sin que nadie se dé cuenta.
Con toda seriedad, creo que lo mejor es decirles que algunas cosas son complejas y requieren una resolución de problemas, análisis y diseño complejos. Existe una brecha entre lo que hacen y lo que hace el programador y es desafortunado que nunca comprenderán todas las implicaciones. A veces solo tienes que ser firme y explicar que puede llevar mucho tiempo.
Quizás un desglose de la tarea en subtareas y darles estimaciones puede ayudar.
Divida el problema en tantas tareas subdivididas como sea posible. Proporcione una estimación por artículo en horas al lado de cada uno.
Cuando piensan en un proyecto como un todo, parece simple. Sin embargo, cuando vean cada cosa individual que se debe hacer y la cantidad de horas que requerirá cada elemento, lo pondrán en términos que los empresarios pueden entender. De repente, la solución de software que quieren ya no es una "caja negra" para ellos y ahora tienen una idea del proceso.
Si está buscando libros, le sugiero la Estimación de software - Desmitificar el arte negro .
En mi experiencia, cada vez que comencé a explicarle a los vendedores en el pasado por qué una tarea toma una cierta cantidad de tiempo, rápidamente admiten que realmente no quieren saber los detalles técnicos, y estoy de acuerdo con eso. Por lo general, no quiero que me expliquen por qué aún no han conseguido esa gran venta después de n días. Para hacer un trabajo eficaz, todos tienen su propia área de responsabilidad. Solo asegúrese de que su relación con el personal de ventas para el que proporciona estimaciones sea buena y que confíe en su capacidad para realizar estimaciones adecuadas y razonables y realizar el trabajo. En mi humilde opinión, no debería haber necesidad de explicar y razonar una estimación en cada detalle, pero si existe, diría que el verdadero problema está en otra parte.
Y estoy totalmente de acuerdo con "Depende" arriba.
Estoy de acuerdo con Simucal en el sentido de que los gerentes tienden a mejorar cuando se divide un problema en horas, en lugar de hacerlo en tareas de programación. Por ejemplo, diciéndole a tu jefe, "eso debería tomar alrededor de dos horas para completar, pero tengo algunas otras cosas que tengo que completar primero, así que debería tenerlas para mañana". es mucho más útil que decir: "Bueno, primero tengo que diseñar una interfaz para comunicarme entre objetos, y luego crear las clases para implementar la interfaz, y así sucesivamente". Los gerentes entienden lo que pueden ver, por lo que siempre que pueda explicar su tarea en términos de los efectos del usuario final, es probable que tenga más éxito.
Dicho esto, no permita que su gerente lo intimide para hacer promesas que no puede cumplir. Quizás sepan que lo único que quieren escuchar es "Lo tendré al final del día", pero si saben que no se puede hacer, no digan que sí, con la esperanza de que si lo tienen. para ellos en algún momento en los próximos días, que será "lo suficientemente cerca". Si comienzas a factorizar el tiempo para diseñar y probar y les das estimaciones apropiadas, eventualmente comenzarán a comprender cuánto tiempo lleva completar ciertos tipos de tareas, y dejarán de esperar que todo se haga antes de ayer.
También noté que los resultados tangibles a lo largo del camino tienden a poner sus nervios en reposo (temporalmente, al menos). Mi jefe comienza a exigir resultados terminados cuando empieza a sentir pánico en cuanto a si una tarea se completará a tiempo o no. Sin embargo, cuando puede "ver" la progresión paso a paso, entonces es más probable que entienda que, de hecho, estamos progresando, aunque todavía no esté en el producto final.
Además, al comenzar este proceso, trate de ver las cosas desde su punto de vista y comprenda que hasta que llegue el momento en que pueda dedicar el tiempo que cree que es necesario, es posible que tenga que encontrar un medio feliz. Llegó un momento en mi experiencia en el que necesitaba desarrollar un objeto Cache, y si bien me hubiera gustado tomar varias semanas para diseñar e implementar un caché extensible y configurable que pudiera distribuirse ampliamente en múltiples aplicaciones, tuve que limitarme a la tarea a mano. Solo asegúrate de que si decides escalar o seguir adelante con un diseño miope, asegúrate de que esté bien documentado para que puedas volver atrás y solucionarlo cuando tengas tiempo (o para que otro desarrollador pueda retomar el tren de pensamiento que no pudo terminar). Además, no sacrifique los buenos estándares de codificación y estilo, ya que esto también hará que su código sea más fácil de mantener y actualizar correctamente en el futuro.
¡Buena suerte!
Tenía un amigo que podía hacer el Cubo de Rubik en segundos.
Eso me hizo pensar en esta forma de explicarle a mi gerente por qué nuestro último proyecto ¡FALLÓ!
Olivier tarda un promedio de 10 segundos en ordenar completamente todos los colores de un cubo de Rubik de 3x3 después de mirarlo durante aproximadamente 5 segundos.
Si le pides que haga una estimación de cuánto tiempo llevará ordenarlo, le das el cubo, enciendes el reloj y después de 5 segundos dirá:
"OK, tan pronto como empiece, terminaré en 10 segundos"
sonríes y dices: "¡Comienza!" Después de 3 segundos, le pides que se detenga, le das otro cubo de Rubik y dices ... elige este en su lugar ...
4 segundos después de que inicia el segundo cubo de Rubik, ¿cuánto tiempo crees que tardará en ordenar el primero?
Si respondió aproximadamente 7 segundos, felicitaciones: ¡es el material de la alta gerencia!
(y Olivier tendría derecho a obligarlo a comer los cubos)
La computadora hará lo que le indicó que haga, no lo que usted quiere que haga.
Cualquier forma de abstracción necesita ser traducida a los detalles exactos.
fuente http://c2.com/cgi/wiki?TeachMeToSmoke
Teacher: "It''s hard to express ourselves clearly. You''re a smoker, right?
Are you pretty good at it? [Student nods.]
Let''s pretend I''m a man from Mars and you are going to teach me to smoke.
Do you have a fresh pack? Let''s start with that.
[Takes pack.] OK, now tell me what to do."
Student: "Tear open the pack."
T: [Tears pack to shreds. Cigarettes fly everywhere.]
S: "No, no, tear off the top of the pack!"
T: "OK, sorry, do you have another pack? No? OK, let''s just start with this cigarette. [Picks one up.]
S: "Put it in your mouth."
T: [Puts whole cigarette in mouth.]
S: "No, no, just put the end in your mouth!"
T: "Sorry." [Tears filter off, puts whole filter in mouth.]
S: "No, no, don''t tear the cigarette, just hold it between your lips!"
T: "Oh, sorry, give me another one." [Places new cig sideways between lips.]
... y así. Puedes jugar el juego por un largo tiempo. Es difícil dar instrucciones claras, incluso cuando conoces el dominio. La programación durará mucho tiempo. - RonJeffries