Parece que estoy atascado repetidamente en una situación en la que las fechas de lanzamiento se establecen no en base a nada técnico, sino porque alguien en Ventas se ha comprometido con un cliente para entonces. Basado en discusiones con amigos en desarrollo en otras compañías, parece ocurrir lo mismo.

"Aquí está el conjunto de características comprometidas y aquí está la fecha de lanzamiento comprometida", y es difícil discutir porque en este punto hay dinero en juego, y eso supera a todo.

En general, ¿hay alguna manera de retrasar esto? Si no fuera por esta versión, ¿qué pasa en el futuro? El problema que tengo es que la única forma en que veo una forma de hacerlo, y es haciendo lo mejor que puedo, pero lanzo el software 'tal cual', por así decirlo.

No quiero lanzar un software lleno de errores, ya que es mi nombre adjunto, pero hacer 80 horas semanales durante meses a la vez solo reivindica la fecha de lanzamiento establecida arbitrariamente.

editar: para el registro, no estoy haciendo 80 horas semanales ahora, solo eso me viene a la mente como lo que se requeriría para cubrir la función esperada establecida para la fecha de lanzamiento.

Deja de hacer las 80 horas semanales. Este es un refuerzo positivo . Debido a que están obteniendo el producto a tiempo con los costos esperados, continuarán haciéndolo, independientemente de lo que le haga.

Si no pueden presupuestar el tiempo correctamente, entonces es culpa de la gerencia. No es tuyo.

Permítales perder algunos plazos.

En general, ¿hay alguna manera de retrasar esto? Si no fuera por esta versión, ¿qué pasa en el futuro?

Por supuesto, hay: que fracasen mucho con este enfoque. Nada enseña más que fallar.

Haga una estimación usted mismo antes de comenzar y muéstreselo . Luego, haga lo mejor que pueda, escriba un buen código, deje de compensar su estupidez con su tiempo libre y, cuando se quejen después, recuérdeles la estimación del tiempo que les mostró, basándose en principios de ingeniería.

Y será mejor que comiences a hacer esto con el proyecto actual .

Si siguen culpándote por el problema, será mejor que comiences a buscar un nuevo trabajo, ya que nada los convencerá de que ellos son el problema.

Como una ocurrencia tardía, creo que esta pregunta realmente garantiza un enlace a la famosa historia de EA que aparece en uno de los libros de Joel: EA: The Human Story .

Esto generalmente ocurre debido a un incentivo perverso: a los vendedores se les paga por comisión, mientras que al personal de producción se le paga por salario. Los vendedores tienen varias palancas para trabajar: características, costo y fecha de entrega. Tienen un fuerte desincentivo para reducir el costo, ya que esto generalmente reduce su comisión, por lo que tienden a aumentar las características y la fecha de entrega (en términos de ser más temprano). Empujarán a aquellos lo más que puedan para cerrar el trato.

Intenta verlo desde su punto de vista, solo por un momento. También tienen una familia que alimentar, y si la diferencia entre cerrar una venta en la que he estado trabajando durante meses es solo recortar algunas semanas del horario, entonces es una tentación increíble, especialmente si no lo hago. Realmente entiendo lo que eso significa.

La tentación es decir "siempre fue así, y siempre será así". Pero un lugar donde trabajé tenía al menos una solución PROPUESTA, si no se implementaba ... un gerente finalmente levantó las manos y dijo: "si las horas extras de los programadores se están utilizando para cerrar una venta, entonces deberían recibir una parte de la Comisión." No se implementó, pero habría alineado los incentivos de todos más de cerca ... los programadores se habrían emocionado al enterarse de una nueva característica que tuvo que salir en poco tiempo, porque estarían anticipando la comisión, y el los vendedores tendrían MENOS posibilidades de crear esas circunstancias, porque tendrían menos probabilidades de trabajar en su beneficio.

El equipo de desarrollo debe ser consultado sobre estas decisiones o nunca saldrá de ese ciclo. Si no está administrando el equipo, uno de los gerentes de línea debe abogar por el equipo de desarrollo. Si son parte del problema, es posible que desee considerar otras opciones de empleo.

En términos generales, las ventas no deberían comprometerse a nada sin la aceptación de la Administración de productos, quienes obviamente deberían consultar con el equipo de desarrollo para conocer los plazos. Realmente no hay una buena excusa para pasar por alto esto en una empresa grande o pequeña porque, en última instancia, el equipo de ventas se preocupará por la entrega insuficiente (ya sea en calidad o alcance).

Esto es casi algo universal en las empresas más pequeñas, ya que tienen una mayor necesidad de cerrar un trato. Hasta que fui llevado a las reuniones de ventas en mi empresa, estaba amargado por esto, pero al menos puedo entender cómo y por qué sucede un poco más.

Los clientes lo quieren rápido y muchos jugarán duro para conseguirlo. Esto alienta a las ventas a cumplir con los compromisos de tiempo solo para obtener algo firmado. Un contrato firmado es oro porque puede adquirir capital o crédito utilizando uno. A veces es mejor tener un plazo ajustado que nada en lo que trabajar.

Otras veces, si se trata de un mercado caliente y hay muchos competidores, la empresa tiene la inminente necesidad de sacar un producto más rápido que todos los demás. Una empresa más grande o una con más capital siempre puede contratar más recursos, una más pequeña no puede.

Donde es escoria es cuando los plazos son verdaderamente artificiales y las ventas y la gerencia lo presionan para asegurarse grandes bonificaciones para ellos.

No tenga el hábito de trabajar más de 45 horas a la semana, es malo para su salud y eso es lo primero.

He trabajado en ambos lados de la casa. Recuerde que sin el personal de ventas no habría trabajos o proyectos posteriores.

Cómo combatir el exceso de compromiso de ventas : calcule, luego tome al menos un múltiplo del 130% (siempre planifique una contingencia mínima del 30%). Proporcionar y documentar dicho presupuesto. Tenga en cuenta que sus estimaciones de esfuerzo se reducirán en el proceso de ventas. Está bien, solo haga que la gerencia elimine del acuerdo de licencia / ventas / comisión cualquier reducción de esas horas. Si usted es una empresa pública, esto se vuelve complicado con VSOE , pero hasta que llegue a los vendedores con responsabilidad de contrato por adelantado durante su proceso de ventas, se convertirá en su responsabilidad más adelante.

Hay muchas estrategias que puede usar, pero generalmente necesitará la aprobación o aceptación de la administración.

1. Pague a los desarrolladores horas extras a una tasa mayor. Trabajar horas extra no es tan malo cuando ganas mucho dinero extra haciéndolo. Y si comienza a afectar la gestión de resultados de la compañía, aplicará presión a las ventas para hacer una mejor estimación del trabajo.

2. Pague a los vendedores en función de las ganancias en lugar de las ventas brutas Cada hora de trabajo que no incluyen en su estimación afecta negativamente su comisión.

3. Limite la cantidad de horas que los desarrolladores pueden trabajar a 40 (o cualquiera que sea la semana laboral estándar en su parte del mundo).

4. Haga que los vendedores trabajen cada hora que trabajan los desarrolladores. Si quieren que trabajes horas extra para hacer su proyecto, también tienen que estar allí. Encuentre algo útil para ellos, como escribir documentación o producir copias caligráficas e iluminadas a mano de Patrones de diseño y The C ++ Standard Template Library .

5. Haga que los desarrolladores estimen cada trabajo en lugar de dejar que los vendedores lo hagan. Al menos de esta manera obtienes cierta capacidad para hacer que el horario sea más razonable. Sin embargo, esta no es una gran solución ... los desarrolladores a menudo son terribles al estimar el trabajo requerido. Incluso si la estimación es razonable, los eventos imprevistos pueden evitar que alcance su objetivo. Además, todos tendemos a no trabajar al comienzo de un proyecto largo con la misma urgencia que hacemos cuando se acerca la fecha límite. Estos son los factores que motivan los cortos ciclos de desarrollo que los defensores de Agile propugnan.

6. Tome el enfoque "ágil" y rehúse comprometerse. Yendo ágil requerirá mucha más participación de los clientes, pero también puede dar al cliente una mayor flexibilidad, ya que no necesariamente tienen que comprometerse por adelantado a la forma final del proyecto tampoco. Las ventas pueden no estar contentas con eso al principio, pero pueden cambiar su tono cuando se dan cuenta de que puede proporcionar muchas oportunidades para vender más trabajo.

Creo que la solución menos atractiva es cualquier cosa que haga que el equipo de ventas se vea mal a los ojos de los clientes potenciales. El equipo de ventas es la cara de la empresa. Hacer que se vean mal perjudica a toda la empresa, y es posible que no resuelva el problema; pueden sentir que necesitan hacer un trato aún mejor para el cliente para recuperar su confianza.

Dejar

Ya hay muchas sugerencias sensatas en las respuestas, que con suerte pueden ayudar a resolver esta relación disfuncional. Pero al final, tú decides cuánto quieres trabajar.

Es fácil ser presionado por los compañeros de trabajo para que trabajen en exceso. Pero estás sacrificando tu vida personal cuando haces eso.

Esto es lo que puedes hacer:

• Dígale a su jefe: "He tenido que trabajar muchas más horas extras de las que quiero aquí. De ahora en adelante, no voy a trabajar más de X horas por mes".
• Como otros han sugerido, calcule cuántas horas tomarán las cosas por adelantado. Recuérdeles que "en mi límite de X horas por mes, probablemente no terminaré esto antes de la fecha límite". Ponga esto en un correo electrónico para su posterior consulta.
• Consulte ese correo electrónico cuando la fecha límite expire. "¿Ves? Según lo previsto, no podríamos cumplir este plazo en horas de trabajo razonables".
• Si continúan presionándolo para que trabaje horas extras y todos los esfuerzos de comunicación fallan, renuncie.

Experiencia personal

Renuncié a mi último trabajo porque siempre estaba trabajando horas extras y siempre me pedían que trabajara más. Les dije claramente en mi entrevista de salida que me gustaban muchas cosas sobre el trabajo, pero que no veía el final del tiempo extra a la vista.

También expresé claramente ese deseo en mi entrevista para mi nuevo trabajo, y recibí una respuesta entusiasta. Se han mantenido fieles a su palabra: rara vez me piden que trabaje horas extras aquí.

Mi antiguo empleador tiene una alta tasa de rotación de desarrolladores, y está encontrando más difícil reclutar estos días porque tienen una reputación de exceso de trabajo. Tal vez el costo adicional de reclutamiento y capacitación les dará una lección. Pero si no, no es mi problema.

Primero, recordemos que todos generalmente tenemos trabajos para respaldar los acuerdos que hacen los vendedores en lugar de construir un arte de programación técnicamente perfecto. Si no hacen los tratos, no tienes trabajo.

Dicho esto, el truco es encontrar formas de trabajar con las ventas para que todos se vean bien. Los procesos en los que el equipo técnico puede al menos expresar una opinión sobre las propuestas antes de que salgan por la puerta es clave. Encontrar formas creativas de manejar la compensación también ayuda mucho: si las ventas tienen que "dar propina" a la ingeniería cuando la ingeniería incurre en horas extraordinarias masivas haciendo que un horario poco realista funcione, parece reducir drásticamente la frecuencia de los proyectos de marcha de la muerte.

Esto es algo que debe llevar a su gerente (hay gerentes de desarrollo, ¿verdad?) Y explicar el problema. Es un cambio que debe suceder a nivel organizacional: las ventas deben ser aprobadas del desarrollo antes de comprometerse, y antes de que eso suceda, deben obtener esa dirección de sus jefes.

No hay nada que pueda hacer para que el cambio suceda, pero definitivamente debería informarlo a su gerente.

Además de tratar de cambiar la cultura (buena suerte), cada vez que se acercan a usted con una fecha límite que no puede cumplir, retroceda, con números. Desglose el proyecto y muéstreles su tiempo estimado. Si es un proyecto de seis semanas, díselo. Si se le ha prometido al cliente en cuatro semanas, no puede hacerlo y necesita difundir esa información lo más rápido posible. Con suerte, sus vendedores podrán volver al cliente y establecer mejores expectativas, o trabajar con usted para llegar a un conjunto de características aceptable más pequeño para entregar dentro de la línea de tiempo prometida, con las características adicionales que se agregarán más adelante.

Editar para agregar: no permita que reduzcan su estimación. Tenga la seguridad de que es correcto y cúmplalo. Ellos van a tratar de negociar con usted, pero no deje ellos.

Una sugerencia que aún no ha aparecido: retrospectivas .

No digas "no, no estoy haciendo horas extras", eso siempre alienta a otros desarrolladores a entrar en picado y hacerte quedar mal.

Pero dígale muy claramente a su gerencia que cada vez que tenga que hacer más de 40 horas a la semana para hacer un trabajo, todos los involucrados en el proyecto deben sentarse en una habitación después de que se entregue el producto , averiguar qué salió mal y qué podemos hacer para evitar que vuelva a suceder. O, mejor aún, cada proyecto debe tener una retrospectiva para discutir qué salió bien y qué salió mal.

Si tiene razón y los vendedores se comprometen demasiado, esto se aclarará muy rápidamente. Pero no te adelantes a la conclusión y no seas adversario antes del hecho. Hable sobre esto en términos de las cosas que su equipo puede hacer para entregar a tiempo sin horas extras.

Nunca se sabe, incluso puede encontrar mejoras en sus propios procesos que pueden hacer que la estimación del vendedor sea más factible.

No hay absolutamente ninguna manera de combatir esto por completo. La naturaleza misma de las ventas es un compromiso excesivo. Como representante de ventas, usted está allí para hacer que los posibles problemas del cliente desaparezcan mágicamente. Los buenos representantes de ventas solo exagerarán ligeramente, los malos se causarán una gran vergüenza.

Cualquier cosa que haga solo causará agravamiento o tensión entre el personal del producto y el personal de ventas (al menos). Puedes esforzarte mucho para evitar errores realmente malos por parte de tus representantes de ventas, pero al final del día, los desarrolladores y representantes de ventas reciben el pago de la misma cuenta bancaria. Su empresa tendrá éxito o fracasará como una unidad, por lo que comenzar una guerra civil con las ventas no ayudará.

Si tiene uno o más representantes de ventas que habitualmente se avergüenzan a sí mismos, entonces la gerencia de ventas se encargará del problema. Como desarrollador, no tendrá la influencia para hacer nada al respecto, por lo que debe concentrarse en ofrecer el mejor producto que pueda con el tiempo y los recursos que le brindan.

Es difícil responder sin conocer la estructura de su empresa.

Algunas herramientas generales para ayudar son:

• Tener un acuerdo sobre (pero los responsables, no las ventas) controles de calidad
• Tener una hoja de ruta del producto (interna y externa)

Al haber acordado los controles de calidad , tiene una razón impulsada por el negocio para no poder lanzar software con errores. Es posible que deba convencer a sus jefes de por qué esto es importante (con suerte no), pero hay mucha literatura disponible para ayudarlo.

Al tener una hoja de ruta de productos , las ventas saben lo que pueden y no pueden prometer a los clientes. Si quieren cambiar la hoja de ruta, tienen que plantearla con el Gerente de Producto / Gerente de Proyecto / Gerente de Desarrollo o con cualquier otra persona que la cambie.

Si prometen algo a un cliente que aún no se ha acordado, mala suerte. Esperemos que su hoja de ruta se base en datos del mercado sobre las necesidades del cliente. "¿Qué propone exactamente que descartemos de estas otras 8 características de alta prioridad que tenemos evidencia de que nuestra base de clientes necesita?"

Por último, como ya se esperaba, no trabaje 80 horas a la semana. Ni siquiera está ayudando a la empresa al hacerlo porque solo los está ayudando a cavar un hoyo más profundo.

No

Traté de hacer de esto una respuesta de dos letras y la pila no me dejaba ... pero la respuesta es

No

Lo cual, por supuesto, no es del todo cierto si usted posee / dirige la empresa. Si está en esa posición, puede arrastrar al equipo de ventas por los oídos y "hablar". Sin embargo, si sospecho que usted es simplemente una persona técnica "humilde", su único recurso es quejarse "ARRIBA" de la cadena de mando. Dicho esto, mi experiencia ha sido que en las empresas donde esto sucede, la gerencia es consciente de la situación y no le importa.

Muéstreles esta imagen (o esta ) y dígales que está trabajando con un triángulo imposible.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

En cualquier proyecto, si arreglas dos esquinas de estos tres:

• Hora
• Alcance
• Calidad

... entonces el tercero es el único flexible. Lo que lo hace imposible son las expectativas. Si siempre fijan el Tiempo demasiado corto y el Alcance demasiado grande, entonces la Calidad siempre sufrirá. En un proyecto ágil, las tres esquinas son más o menos flexibles.

(Descargo de responsabilidad: excluyo el factor Costo del triángulo del proyecto tradicional y hago de la Calidad la esquina. El Tiempo es el Costo en proyectos de software).

Espero que tenga éxito en su camino hacia una gestión de proyectos más ágil.

Algunas muy buenas respuestas aquí ya. Solo agregaré que no debe ser impulsado a cumplir sus plazos en detrimento suyo. Además, definitivamente hablaría con el vendedor y le recordaría que si él promete demasiado y la compañía no puede cumplir sus promesas, entonces él (y la compañía) no serán confiables en el futuro, perdiéndole futuras comisiones (y posiblemente su trabajo), por lo que le conviene ser realista (es decir, consultar con el personal de programación) para que gane confianza en la empresa. A corto plazo, puede ganar al ser poco realista, pero a largo plazo perderá al dañar su reputación con los clientes, su empleador y futuros empleadores a través de malas referencias.

Como los vendedores entienden el dinero más que cualquier otra cosa, hable con él en esos términos.

Con el desarrollo ágil vemos consultores vendiendo puntos por ~ 1000-1500 cada uno. Si puede cambiar el proceso de ventas a donde tienen que vender en función de la escala de puntos, entonces el equipo de ventas se verá obligado a trabajar con el equipo de desarrollo para obtener estimaciones razonables.

Todo se reduce a un punto crítico; Si no cree que puede mantener el ritmo necesario para cumplir con el cronograma de ventas prometido, no se comprometa con el trabajo. Si las ventas se exageran, no es su problema, hasta que acepte el trabajo. ENTONCES es tu problema. Recuérdele a su jefe que todo lo que tienen que hacer los vendedores es decir que sí y reciben el cheque; eres el que realmente cumple las promesas, así que si dices que no funcionará, tu jefe debería estar escuchando. Si tiene la mala fortuna de tener un gerente que escuche a su fuerza de ventas más que a su fuerza de desarrollo con respecto a lo que es y no es posible, entonces tiene el PHB de Dilbert-esque, y debería actualizar su currículum.

Esta es una razón por la que me gusta Agile; El equipo de desarrollo participa en el proceso desde las discusiones iniciales de diseño. Puede calibrar un "punto" desde ambos extremos; el equipo de desarrollo decide (explícita o empíricamente) aproximadamente cuánto desarrollo de horas hombre son inherentes a un punto, que la gerencia puede usar para calcular puntos por semana, puntos por mes, etc., lo que lleva a una cifra en dólares. En ese momento, su equipo de ventas ahora tiene cifras relacionadas con el costo y el tiempo requerido para que los niveles de personal actuales obtengan la cantidad actual de alcance. Si se comprometen en exceso una vez que tienen esos números, están fuera de combate.

Especifique el trabajo después de que se lo entreguen y hágales saber cuánto tiempo llevará. Luego, cuando canten al respecto, diles.

"Lamento que hayas hecho ese compromiso, pero dado los recursos a mi disposición, tomará X horas completarlo"

Haga esto cada vez ... funcionó para mí.

Básicamente diles que pueden tenerlo Rápido, Barato y Bueno, elige dos.

En realidad, hay un camino, un camino real, no un lugar vacío, pero puede que no te guste.

Haga que alguien del equipo de desarrollo participe en el proceso de ventas .

Ahora, obviamente, necesita a alguien con buenas habilidades con la gente, alguien a quien el personal de ventas no se mortificará por llevarse el viaje. Y esta persona necesita tener una amplia comprensión de los tipos de trabajo que realiza. Ellos no tienen que ser un ninja código, sólo necesitan una comprensión más leve de la codificación en general y su proceso de desarrollo, en particular, y ser razonablemente bueno para calcular el trabajo.

Este es realmente un trabajo para un analista de negocios o gerente de proyecto. Hay una razón por la cual estos trabajos pagan tan bien en muchas compañías; combinan dos conjuntos de habilidades muy importantes y distintas. Si no tienes un BA o PM real pero tienes un desarrollador o arquitecto senior con habilidades sociales, ellos también pueden hacerlo.

También debe proporcionar pautas claras para el personal de ventas. Efectivamente, usted (como en su equipo de desarrollo) está enviando a alguien para negociar en su nombre. Si no les das ningún parámetro, solo negociarán lo que les parezca bueno. Es por eso que siempre les das parámetros.

Una vez que comprenda el alcance del proyecto, calcule cuánto tiempo le gustaría tener para construir, probar, cambiar el alcance, etc., más una cierta cantidad de búfer, luego deles ese número junto con un "mínimo autorizado": el lo más bajo posible antes de poner el proyecto en grave riesgo. Espere que también reduzcan ese número en una cierta cantidad, así que haga que su mínimo sea un poco más alto de lo que realmente necesita ser.

Tenga la seguridad de que su gestión está haciendo lo mismo. El gerente de ventas no quiere que los asociados de ventas vendan negocios no rentables. Están entrando en cada negociación con un rango de números que corresponde a la rentabilidad objetivo y la rentabilidad mínima.

Puede que no sean sus gerentes, pero si documenta todo esto por escrito antes de que incluso comiencen a negociar, entonces está en un terreno mucho más firme con la alta gerencia cuando la gente comienza a hacer preguntas sobre por qué el proyecto está retrasado. Pero no se trata solo de CYA; el equipo de ventas honestamente no tiene idea de cuánto tiempo tomarán ciertas cosas, y usted les está haciendo un favor al brindarles información completa.

Otra cosa: no esperes que el equipo de ventas involucre a tu equipo solo por el placer de hacerlo. También necesita la aceptación del gerente de ventas y los ejecutivos. Realmente no debería ser demasiado difícil de conseguir, si lo enfocas desde una perspectiva de riesgo. No quieres vender el fracaso, ¿verdad? Piense en el costo para la reputación de la compañía. Piense en el costo de una demanda . Alguien técnico debe ser parte de cualquier negociación antes de que se pueda firmar un acuerdo.

Y si realmente, honestamente, no puede vender a la gerencia sobre la idea, ¿podría sugerirle encontrar un nuevo empleador? Porque el tuyo puede no estar mucho más tiempo de todos modos

Los desacuerdos como este normalmente son causados ​​por una falta de comunicación. O no entienden la presión que te ejercen o no entiendes lo que realmente piden. De cualquier manera, para resolver el problema, debe comprender la situación desde el otro punto de vista.

¿Alguna vez has intentado vender software? Puede que no parezca la mejor respuesta para muchos desarrolladores, pero hasta que lo haya intentado, será difícil ver el negocio desde el lado de las ventas. Si eres un gran desarrollador, escribe algo que realmente quieras escribir y véndelo. ¡Puede ver que tienen algunos puntos válidos o puede ver que no!