Tiempo de finalización en una empresa donde los supervisores no saben programar [duplicado]

Si los vendedores también son los que están a cargo, puedes decir: "Bien, puedo ir con tu agenda. ¿Qué características o responsabilidades te gustaría que sacrificara para cumplir tu fecha límite?" De esa manera, no está diciendo "no" a las personas a cargo, pero no se está comprometiendo con cosas imposibles. La decisión está en sus manos cómo manejar el negocio. Si quieren dejar otras cosas para hacer tiempo para los cambios, déjelos.

EDITAR: Necesitamos respetar y someternos a aquellos que están en autoridad, mientras seguimos haciendo nuestro trabajo con excelencia. La única forma de hacerlo es con humildad. Trabajaré en lo que sea que mi jefe quiera que trabaje, pero solo puedo hacer mucho. Cuando le dices que está con una actitud de sumisión, está en una mejor posición para tomar mejores decisiones y querrá más empleados como tú.

Asegúrese de que estas cosas estén documentadas también para explicar por qué los compromisos no son razonables y cómo se resolvió la situación. Puede ayudar a los compañeros de trabajo a enfrentar situaciones similares en el futuro.

En mi experiencia, el personal de ventas piensa que todo es una negociación en la que uno se encuentra en algún punto intermedio. Básicamente es así como funcionan. Intentan vender un producto a un cliente y preguntar alto, el cliente ofrece precios bajos y al final un precio que ambas partes acuerdan se convierte en el acuerdo.

También llevan esta mentalidad al piso de trabajo. Suponen que estás pidiendo demasiadas horas, así que intentarán discutir algunas de las horas, como en una negociación.

Dar estimaciones exactas, solo me ha dado dolores de cabeza.

Lo que puedes hacer es seguir adelante: otorga una estimación más alta donde puedan eliminar algo durante la "negociación" y, al final, acabar con las horas que realmente te cuesta hacer.

¡No les muestres sus errores!

Intente argumentar mejor qué cambios realiza, proporcione estimaciones más detalladas. Haga una sugerencia como "Podemos hacer esto en sus X horas en lugar de las mías Y horas, si vamos a dar pruebas de software para externalizar". O "Podemos hacerlo más rápido, si excluimos esta parte de la funcionalidad solicitada".

"Después de darles el horario, comienzan diciendo que puedes hacerlo en la XX vez, lo que difiere mucho de mi plan". En primer lugar pregúnteles cómo calcularon su XX vez.

Sugiérales que se haga un registro de su estimación y su estimación. Luego puede comparar lo real con las predicciones y ver quién es más preciso.

Diga "Estoy a la altura de mi estimación". Y luego, por supuesto, alcanzar su estimación. Cuando suceda tres veces, probablemente confiarán en ti.

"Cuando me preguntan cuánto tiempo quiero para un cambio"

En ese punto deténlos. No es la cantidad de tiempo que quieres . Es la cantidad de tiempo que usted necesita . Si insisten, deles tanto el tiempo que desees como el mínimo que necesites.

También puede ayudar a mantener una medida muy visible de la deuda técnica incurrida debido a todos los accesos directos forzados por las Ventas. Nikolay es ampliamente optimista en cuanto a que puedes influir en las ventas por hablar, cuando su comportamiento actual les otorga bonificaciones.

De hecho, si las ventas están realmente impulsadas por tales incentivos, entonces debes tener esto en cuenta al formular tu respuesta. "Característica no confirmada por Ingeniería" es una razón perfectamente válida para cancelar una solicitud de venta.

Para alejarse de su preocupación con las horas, cambie el juego. En lugar de estimar el tiempo, estime la complejidad en relación con un determinado caso de uso que forma una línea de base.

Mencionas que tienes un enfoque ágil, ¿por qué no pruebas Scrum?

En otras palabras, haga Sprints cortos, dígales que "sí, en una semana podré desarrollar tres de sus cinco características", luego asegúrese de cumplir con esas tres características. Haga que prioricen los cambios / características / errores y que trabajen estrictamente en ese orden. (Por supuesto que hay más.)

Enséñeles sobre el triángulo de hierro del tiempo, costo, calidad y alcance. Arreglas tres y la cuarta es el área del triángulo y, por lo tanto, una función de las otras. Supongo que es probable que sea más importante al final cuando esté entregando, cuánto cuesta y, con suerte, que entregue con calidad que exactamente lo que está entregando.

Este es un gran error para los proyectos liderados por ventas / consultoría y es una situación difícil. Este es a menudo un problema de cómo opera la compañía.

Es un caso clásico de cola tratando de mover al perro, los vendedores haciendo lo que pueden para cerrar la venta, prometiendo al mundo en características y garantizando una escala de tiempo absurda, el proceso de desarrollo de software y todo lo demás. .

O bien lo escucharán o no lo harán, no es necesariamente un hecho que no entiendan, lo más probable es que lo sepan bien, pero lo único que les importa es cerrar la venta, obtener el negocio y preocuparse por él. plazos más tarde.

Dicho esto, los clientes pueden ser una molestia en la parte posterior, quieren que las cosas se realicen de forma económica y quieren saber cuándo se hará. Y quieren un descuento para arrancar.

Una forma de mitigar esto es tener un técnico involucrado en las reuniones de ventas. Ahora bien, esto no es necesariamente factible en todas las empresas, pero puede ser la única manera de al menos tratar de reinar en los vendedores.

Podría ayudar a diferenciar entre cuánto tiempo tomará algo y cuánto tiempo se cargará. Cuánto tiempo tomará algo es una decisión técnica, no tienen base para estar en desacuerdo con usted, sea terco. Cuánto quieren cobrar los vendedores por ese tiempo es su decisión y su responsabilidad de venderle al cliente.

Aparte de eso, los incentivos deben ser resueltos o siempre estarás luchando en una batalla cuesta arriba. Si los bonos de venta no se pagan por el valor total de la venta, sino por la diferencia entre el valor de la venta y el costo de la entrega, tienen un incentivo para escucharlo.

Si quieren reducir el calendario, pregúnteles qué funciones quieren que se les deje de lado y cuál es su prioridad.

Luego trabaje en las funciones en orden de prioridad y dígales que pueden tener el producto cuando lo deseen, pero no contendrá todas las funciones que solicitaron hasta la fecha de finalización que especificó inicialmente.

Si es un problema persistente, ¿qué tal si se asigna un representante de ventas al equipo de desarrollo durante una semana o dos? Déles un libro sobre el lenguaje de programación X y dígales que lo hagan en su estimado. El 99% de las veces fallarán miserablemente, y se resistirá a cuestionar sus estimaciones nuevamente. También pueden tener una idea de lo que se necesita para hacer un desarrollo de software y darse cuenta de que no están ayudando en el proceso.

Aclare que está estimando la cantidad de tiempo que tomará, no prometiendo que terminará en ese tiempo, y que conseguir que baje el número no es nada más que convencerte de mentirles. En realidad, no hará que el software se haga más rápido por arte de magia.

Pregúnteles cuánto bien sería convencer a una mujer para que reduzca su estimación de su embarazo de 9 meses a 7 meses.

Mejor aún, consigue un gerente de producto. Los vendedores vincularán su producto a nudos que persiguen comisiones, ya que tienen pocos incentivos para preocuparse por el producto en general y todos los incentivos para perseguir la venta actual.

Hay dos problemas, que deben ser desentendidos.

1. Deje de cotizar a tiempo, comience a cotizar en dólares. Esto rápidamente les permite hacer un análisis de costo / beneficio, y le permite agregar una cita estándar de "tiempo para analizar". El tiempo es demasiado difícil, porque no refleja la cantidad real de trabajo realizado (cuarenta horas se pueden realizar en un día, cinco días o tres semanas), y es demasiado fácil no empujar el ciclo de lanzamiento presupuestado de nuevo para tal solicitud.

2. Proporcione al personal de ventas una entrada de solicitud para el ciclo de desarrollo (preferiblemente una interfaz no humana, para ahorrar tiempo (medido en dinero)).

El personal de ventas tiende a pensar en términos de (si tengo X, puedo cerrar esta venta). Sus solicitudes a menudo no son coherentes con la arquitectura actual del producto, pero son coherentes con la necesidad actual de un cliente.

Indique a la fuerza de ventas que dichas solicitudes son vitales para su producto y, como tal, necesita para no perderlas en la "solicitud rápida, le llevará más tiempo que el período de interés, abandonar la solicitud, repetir "ciclo. Tales solicitudes deben ser capturadas, analizadas, priorizadas, integradas en el producto, probadas y liberadas en el próximo ciclo de lanzamiento.

Luego haz una copia de seguridad de tus palabras con acciones. Acorte el ciclo de lanzamiento a menos de dos meses, indique qué elementos estarán en el lanzamiento y cumpla con sus plazos. No eduque al personal de ventas acerca de las razones internas por las que esto es necesario, solo haga un análisis de lo que cuesta una solicitud de fuera de ciclo (en dólares) y el riesgo (dólares adicionales y porcentaje de ocurrencias) Si un problema supera la complejidad mínima. Luego pregúntele a la persona de ventas si la venta es lo suficientemente grande como para respaldar la solicitud fuera de ciclo.

Una vez que tienen un proceso para una solicitud dentro del ciclo, y tienen una idea de cuánto cuesta manejar una solicitud fuera de ciclo, es muy probable que pueda convertir su solicitud fuera de ciclo en una solicitud dentro del ciclo, o determinar que la solicitud fuera de ciclo es lo suficientemente rentable como para justificar el gasto.

Bueno, espero que para comprometerme con un trabajo, se entienda que usted y las ventas deben estar de acuerdo en cumplir con los requisitos y valga la pena.

Haga hincapié en que, a menos que usted y las Ventas puedan ponerse de acuerdo, no pueden realizar la venta y el trabajo no se realiza, por lo que debe acordar una contraoferta para el cliente (especificaciones más pequeñas, plazos más largos, etc.) o de lo contrario necesitan encontrar otro cliente.

No tiene sentido firmar un contrato con un cliente que sabe que no puede cumplir, solo terminará ocupando el tiempo de todos y corre el riesgo de perder al cliente y a otros, y es posible que ni siquiera obtenga el dinero para el trabajo.

Si cree que sus estimaciones son precisas y la historia refleja que utilizan esto.

Cuando digan que tienes XX vez, revisa tu estimación eliminando características hasta que llegue a este momento. No saques las pruebas.

Entonces es una negociación sobre características y tiempo, no solo tiempo, lo que la historia dice que no puedes cambiar. Si insisten en negar con el tiempo, comience a negociar los bonos por alcanzar dicho tiempo (si su equipo está dispuesto a trabajar las horas extra para llegar allí). Digamos que podemos hacer el tiempo que desees, pero te costará un bono de $ 1000 para llegar allí

Recuérdeles que el desarrollo de software es como una fábrica y que la fábrica es capaz de producir X en Y cantidad de tiempo. Vuelve a la bonificación, puede trabajar horas extras, pero va a costar. No lo llames tiempo extra tampoco o simplemente te matarán. Necesita ser escrito también. X producto por Y fecha para Z bonus. También puede insistir en un día libre después de que el equipo se consuma después de eso. También tenga en el contrato que agregar funciones o correcciones de errores en un X% del tiempo normal agregará tiempo para la programación.

No puedes cambiar la hora, solo sacar funciones.

He visto mucho de esta división negativa y posicional en mi carrera y creo que la mejor manera de trabajar es ser lo más honesto y transparente posible. (Se deben evitar las frases negativas como "el comportamiento es estúpido", "no tener idea", "no se puede hacer". Busque soluciones / causas raíz).

Primero, parece que todos están empleando negociación de posición (book ). Quieren lo que quieren y tú quieres lo que quieres. Pero, ¿qué es lo que realmente está impulsando? Mira lo que impulsa su posición y el objetivo. P.ej. Las ventas solo quieren sacar el producto lo más rápido posible para hacer más ventas y ayudar a las ganancias de la empresa. ¿Qué está mal con eso? Y por su parte, simplemente desea crear el software de mejor calidad que pueda. Así que solo necesitas encontrar un terreno intermedio . Creo que la mejor manera de hacerlo es la educación, la honestidad y la transparencia. Trátelos como parte de su equipo y no como "nosotros contra ellos".

Los métodos Agile y Scrum intentan incorporar esto en todo el proceso. Ciertos aspectos de Scrum se encargan de esto muy bien:

1. Un propietario del producto que prioriza las características y elige lo que va en cada sprint. Esta persona es parte del equipo . Esta debe ser una persona que tenga en mente las mejores intenciones de los clientes. p.ej. Esto podría ser una persona de ventas o supervisor. Participan regularmente en la decisión de lo que entra en el producto, por lo que hay una gran motivación y responsabilidad (aprenderán a NO esforzarse por el tiempo frente a la calidad / características)
2. Todas las partes interesadas también son miembros del equipo, simplemente no logran el control en el backlog / sprints / timeline. Trátelos como tales y ellos pueden aprender cómo se calculan las estimaciones y la complejidad hereditaria del desarrollo de software.
3. Un scrum master trabaja para mejorar el proceso a lo largo del tiempo. No se espera que sea instantáneamente scrum, ya que eso no es razonable en ninguna situación. Trabajan para eliminar obstáculos para todos los miembros del equipo (y la compañía).

En resumen, solo sé honesto, positivo y trata de educar: eventualmente mejorará. Incluso si no sigues oficialmente Agile / Scrum, lee algunos textos para comprender mejor estos conceptos y motivaciones.

Otro enfoque sería hacer que les resulte imposible no ver POR QUÉ / CÓMO está dando las estimaciones.

Dado que usted es responsable del proceso de desarrollo, ¿por qué no hace un seguimiento de la velocidad del equipo y los muestra, basándose en sus iteraciones anteriores, por qué no cumple con su fecha límite? Creo que es simple: "nuestra velocidad actual es X, y tenemos Y puntos de historia para esta iteración".