¿Hay alguna forma de combatir las ventas que se comprometen constantemente? [cerrado]

120

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.

Shawn D.
fuente
49
¿Por qué se adjunta su nombre al producto cuando no es usted quien se compromete? Si la compañía quiere sacar un software mal terminado, ese es su derecho, pero no hay razón para que asumas la responsabilidad personal de una decisión que ni siquiera tomaste.
44
@Giorgio jaja buena :)
ell
3
@ShawnD. ¡Por la horda!
Kalamane
3
@ell: Gracias. Bueno, creo que es una mala gestión tratar de exprimir más trabajo de los desarrolladores de lo que realmente pueden ofrecer. Hay una complejidad inherente en cada proyecto y si asigna muy pocos recursos, terminará con un mal software o no entregará a tiempo. Es tarea de una buena administración reconocer esto y planificar en consecuencia. Lo mejor es si el gerente también es un buen desarrollador.
Giorgio
3
Compre The Clean Coder. Léalo (lo devoré en un fin de semana) y aplique las ideas vigorosamente a su carrera. Su trabajo es dar un "No" honesto si el trabajo no se puede hacer. Si no lo haces, no tendrás a quién culpar excepto a ti mismo. Sé que el riesgo de perder el empleo podría influir en ser lo suficientemente valiente para ser honesto. Pero la otra cara se ve obligada a 80 horas semanales para cumplir con un compromiso totalmente infundado.
Michael Brown el

Respuestas:

147

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.

Malfist
fuente
6060
+1 por defenderte a ti mismo. Los desarrolladores que se dejan caminar por todos lados es exactamente lo que permite que persistan las culturas de fábricas de explotación.
31
Agregaré que mientras esto funciona, desea minimizar el daño que esto puede causar la relación con el cliente. Tan pronto como tenga una fecha límite irrazonable, debe ser sincero y hacerle saber al vendedor que simplemente no va a suceder, para que puedan tratar con el cliente en consecuencia.
GSto
40
Desafortunadamente, en muchos lugares esto hará que el único desarrollador que solo trabaja horas "razonables" parezca no ser un "jugador de equipo" que no ayuda a cumplir los objetivos. Es probable que sean los primeros contra la pared cuando se reducen los tamaños de los equipos. También podría simplemente buscar trabajo para un empleador más razonable. Esta táctica de "trabajar para gobernar" solo funcionará si todos los desarrolladores están a bordo.
FrustratedWithFormsDesigner
20
@FrustratedWithFormsDesigner ¿A quién le importa si te ven como no un jugador de equipo? Si no les gustas, pueden liberarte de ese horrible lugar y puedes buscar otra cosa mientras recoges el desempleo por un tiempo. Además, no es como si las ventas y la administración en ese momento estuvieran preocupadas por el bien del "equipo" al esperar horas extras obligatorias para ellos. Me sorprende que los desarrolladores con habilidades comercializables y deseadas se sometan a este tipo de acoso administrativo. Si puede ser despedido o renunciar y hacer otro trabajo en menos de 3 meses, entonces USTED tiene todo el poder.
maple_shaft
66
@FrustratedWithFormsDesigner: Habiendo enfrentado personalmente el alto riesgo de falla por sobrecompromiso, puedo recomendar buscar un nuevo trabajo tan pronto como sepa que las cosas comienzan a ponerse temblorosas. Porque si estás marcado como un mal jugador de equipo, te sientes casi agotado con todo el tiempo extra, hay muchas posibilidades de que tu llamado "equipo" te apuñale por la espalda y finalmente te despidan, incluso si intentaste con todas tus fuerzas. Buscar un trabajo, ya que todavía tiene uno, es una situación mucho mejor para usted que buscar un trabajo mientras no tiene uno que no le dará buenas referencias.
Spoike
96

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 .

revs sbi
fuente
1
Asegúrese de conocer la diferencia entre una estimación y un compromiso: blog.mountaingoatsoftware.com/… Parece que a ellos tampoco les importa, pero una vez que lo hacen, conocer la diferencia es útil.
StuperUser
26
+1 por mostrarles la estimación . Además, un punto que me gustaría aprovechar en esta publicación: incluso en entornos de empresas de la marcha de la muerte, se desaconseja proporcionar trabajo de forma gratuita a los clientes (es decir, todo ese tiempo extra no remunerado), porque la empresa podría haber estado haciendo eso mucho más dinero del mismo trabajo si hubieran estado cobrando al cliente por ello. Señalar que el exceso de compromiso de las ventas está perdiendo el dinero de la compañía podría marcar la diferencia.
55
Un proyecto que falla no le enseña a la gerencia nada en una cultura como la descrita. Dado que los vendedores traen el dinero en efectivo y los desarrolladores son solo un gasto necesario , siempre se culpará a los desarrolladores por no trabajar lo suficiente si los vendedores venden en exceso.
Mark Booth el
2
Sí. Entonces, cuando las ventas lleguen a usted sin una especificación, insista en una antes de aceptar estimar, o deles un rango de estimación adecuado en función del nivel de detalle que brinden. Esto generalmente será algo así como "entre una y treinta semanas".
PeterAllenWebb
2
@ Mark Booth: Es por eso que necesita monetizar los costos de desarrollo. Claro, el desarrollo es un gasto necesario, pero no es el único. Y, en general, la gestión no entienden que el trabajo de ventas es vender por encima del costo; Cualquier idiota puede vender por debajo del costo.
MSalters
52

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.

Chris B. Behrens
fuente
46
+1 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.
Gilbert Le Blanc
12
Esto animaría a los desarrolladores a lanzar basura no probada.
quant_dev
55
Un gerente de ventas me compró el almuerzo una vez y recibió una comisión multimillonaria por un proyecto que me esperaba en una muerte de cinco semanas. No puedo decir que me hizo sentir mucho mejor acerca de la situación.
Dan Ray
77
@quant_dev: cada situación alienta a los desarrolladores a lanzar basura no probada, excepto las pruebas. Esa es una pregunta separada.
Chris B. Behrens
18
La forma más fácil de ajustar los incentivos es restar el costo de las horas extras del monto del acuerdo antes de pagar el porcentaje de comisión.
robertc
26

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).

RichardM
fuente
2
+1 para una suma precisa y de alto nivel. La gestión del producto debe estar involucrada, pero más adelante comprometerse y verse mal puede ser necesario para la supervivencia continua de la empresa.
maple_shaft
Es bueno decir cosas como esta, pero no es un consejo real que pueda ayudar a resolver el problema actual del OP. ¿Qué pasos podrían tomar para llegar a esta mejor posición?
FrustratedWithFormsDesigner
@FrustratedWithFormsDesigner Además de hablar con la gerencia sobre la necesidad de una mejor entrada de Gestión del producto en las discusiones de ventas, bueno ... nada se puede hacer como desarrollador. Este tipo de empresas se establecen en sus formas y cualquier cosa que no sea un cambio de dirección no cambiará nada.
maple_shaft
1
Lamentablemente, en muchas empresas, la opinión de los "gurús / estrellas de rock" de ventas a menudo tiene más peso que la de la gestión de productos, que a veces simplemente no son lo suficientemente fuertes como para presentar su caso a la alta dirección. Descubrí que muchas personas de ventas creen que, independientemente del tiempo estimado por los desarrolladores, será demasiado pesimista y al menos se puede reducir a la mitad fácilmente.
dodgy_coder
El personal de ventas recibe mucho más prestigio que los desarrolladores, ya que están mucho más vinculados a la corriente entrante de cheques de los clientes. Esto es cierto incluso en compañías de software donde los desarrolladores son posiblemente muy importantes, pero no tan importantes como los vendedores que "traen a casa el tocino". Desafortunadamente, así es como lo verán prácticamente todos los CEO / MD, etc.
CraigTP
21

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.

eje de arce
fuente
2
Estoy de acuerdo en que es más difícil para las compañías más pequeñas poner pan sobre la mesa. Aún así, está mal (escandaloso) que las ventas obtengan comisiones por el esfuerzo adicional de los desarrolladores. La gerencia necesita reconocer y luego rectificar esta situación o siempre tendrán una alta rotación de desarrolladores.
semaj
16
+ 1 "No
tengas el
2
¿Qué pasa con 45 horas? ¿No cantaste un contrato de 40 horas?
sbi
14
@sbi: Puede que te sorprenda. Donde yo trabajo, de hecho, se nos exigió cantar el contrato. De hecho, tomó alrededor de 40 horas cantar todo. (había mucha letra pequeña). Era particularmente malo, porque tengo una voz pobre para cantar.
Matthew Scouten el
3
@MatthewScouten ¿cuántos idiomas hablas?
Jim
11

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.

Jé Queue
fuente
66
Esto solo funciona si se le permite al OP ver la característica potencial y dar una estimación antes de que los vendedores intenten vender. Suena como el PO no tiene ni siquiera tienen la oportunidad : "Here is the committed feature set and here is the committed release date".
FrustratedWithFormsDesigner
2
El problema con esto es que los vendedores a menudo asumen que agregaste una contingencia y es por eso que se comprometen a una fecha límite anterior.
dodgy_coder
Tal vez su comisión completa debería basarse en una entrega a tiempo y, tal vez, ser recuperada por un porcentaje del exceso de tiempo invertido del desarrollador. Eso alinearía el interés de la compañía con las ventas.
PeterAllenWebb
10

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.

Caleb
fuente
No puedo hacer el # 4, claramente lo sabes. Las ventas persiguen 100 veces las perspectivas de cualquier contrato activo dado.
Jé Queue
2
Re 4: Solía ​​trabajar en una empresa donde el personal de ventas se iba a las 17.00, 1 hora antes que los demás. No creó sentimientos agradables entre las ventas y el resto de la fuerza laboral.
quant_dev
2
@Xepoch Si van a casa antes que los programadores, entonces obviamente no están demasiado ocupados para tachar algunos manuscritos iluminados.
Brian Gordon el
1
@Graham, escribí "estrategias que puedes usar", pero de hecho, estas son realmente estrategias que la administración podría usar si consideran que el compromiso excesivo perpetuo es un problema que realmente necesita ser resuelto. El # 1 podría, de hecho, ser el más razonable. El hecho de que trabaje con salario no significa que no es elegible para horas extras, bonos o tiempo de compensación. Recibí los tres en diferentes momentos mientras trabajaba como asalariado. Del mismo modo, cambiar la estructura de compensación para vendedores no es imposible; Con frecuencia, las compañías ofrecen incentivos o desincentivos para cambiar el comportamiento de los vendedores.
Caleb
1
De acuerdo con Caleb. Además, por lo general, los clientes a los que se les ha retrasado el plazo y reducido el alcance no están contentos y tienden a retrasarse en el pago. No debe suponerse que este tipo de cosas no afectan el resultado final. De hecho, a menudo es necesario que los gerentes y las ventas aumenten el alcance sin facturar más para calmar a un cliente enojado. Debe acercarse a la gerencia con la promesa de que puede ayudar a que los clientes dejen de enojarse y de oponerse, o al menos que suceda mucho menos. Esto no es un sueño imposible. Lo he visto EN LA VIDA REAL.
PeterAllenWebb
8

Dejar

Ya hay muchas sugerencias sensatas en las respuestas, que con suerte pueden ayudar a resolver esta relación disfuncional. Pero al final, 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.

Nathan Long
fuente
Leí un buen libro sobre esto una vez llamado Nunca trabajes para un imbécil. Me sorprende que esté agotado, pero Amazon todavía ha usado copias: amazon.com/gp/product/0880297484/?tag=resingnet-20
Tom Resing
6

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.

Wyatt Barnett
fuente
44
Y si no lo implementan, tampoco tienen trabajo. No puedo aprobar esta visión del programador como soporte para el personal de ventas.
Agos
@Agos: punto justo. Por otro lado, ¿qué posibilidades hay de que lo contraten en otro lugar si lo despiden por negarse a trabajar? Y qué tan dispuestos están la mayoría de las tiendas a contratar al próximo tipo que irá a las marchas de la muerte.
Wyatt Barnett
Si alguien quiere tomar un trabajo de marcha de la muerte, o continuar en él, ese es su problema. La compañía para la que trabajan pronto se quedará solo con las personas que NO PUEDEN SALIR, a menudo porque no tienen la habilidad y la experiencia para llevarse a otro lado. Los desarrolladores calificados están cada vez menos separados que los vendedores calificados. Merecen ser tratados con al menos tanta deferencia.
PeterAllenWebb
5

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.

MattBelanger
fuente
8
Pero muéstreles lo que pueden tener en cuatro semanas. Quizás puedan tener todas las pantallas con la mitad de los campos, o algo así. O tres de los cinco flujos de trabajo clave. Pregunte en cuál de esos tres debería trabajar. Que sea "su" problema.
sdg
1
Excelente punto, Robert Martin habla mucho acerca de ser firme en las estimaciones en Clean Coder, que proporciona el único antídoto razonable para una gestión irrazonable. Siempre esté ansioso por ofrecer todo lo que pueda, pero nunca acepte un objetivo, o incluso "hacer lo mejor" para cumplirlo, cuando no se pueda lograr de manera razonable. Es su trabajo advertir sobre las limitaciones. Tú eres el que puede verlos.
PeterAllenWebb
4

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.

pdr
fuente
3

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.

Joel Brown
fuente
¿Por qué es imposible desarrollar una reputación como una tienda de desarrollo de caballos de batalla sólida que ofrezca realismo en lugar de afirmar que hace magia? Quiero decir, ¿no hay clientes por ahí que no sean idiotas y que realmente entiendan las cosas de las que estamos hablando?
Brian Gordon el
Estoy seguro de que el sentido común es tan común entre los clientes de la tienda de desarrollo como lo es en la población general. Yo diría que cada cliente, tenga sentido o no, notará la brecha entre lo que se promete y lo que se entrega, o al menos la brecha entre lo que esperaban y lo que se entregó. Los sensibles seguirán volviendo cuando esa brecha sea pequeña o inexistente. El resto solo comprará la cotización más barata, como siempre.
Joel Brown el
3
"La naturaleza misma de las ventas es un compromiso excesivo". Discrepar. La naturaleza de las ventas es proyectar sus productos y servicios de la mejor manera posible, venderlos en cada oportunidad disponible y crear más oportunidades. Un historial de entregas a tiempo y por debajo del presupuesto podría ser una gran ventaja en todas estas situaciones. Incluso si una estimación externa del esfuerzo de desarrollo tiene que recortarse de las estimaciones técnicas reales hechas internamente para hacer una venta estratégica, eso no debería ser una excusa para imponerlas internamente a los desarrolladores. Eso no es profesional.
PeterAllenWebb
2

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.

Dan McGrath
fuente
2

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.

brmore
fuente
2

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.

EMPUJONCITO
fuente
2

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.

authentictech
fuente
1

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.

SoylentGray
fuente
solo aumentarán el paquete de trabajo por "punto" (pero no la duración de cada "punto" en una iteración) hasta el punto donde se ajuste al alcance y al presupuesto / línea de tiempo que pueden vender.
Jwenting
Los puntos por historia son asignados por los desarrolladores, no por el equipo de ventas o negocios.
SoylentGray
1

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.

KeithS
fuente
Ahh, pero los vendedores son expertos en el arte de la negociación y los ingenieros no. ¡Por eso están en ventas y nosotros en ingeniería! En mi experiencia, la mayoría de las personas técnicas simplemente asienten con la cabeza (no ayuda que las estimaciones sean susceptibles al sesgo de anclaje ). Es realmente difícil para las personas técnicas decir que tomará más tiempo de lo que alguien piensa porque saben que puede convertirse fácilmente en una reflexión sobre su capacidad. "¿Crees que tomará dos semanas? Joe dijo que puede hacerlo en poco más de uno".
Scott Whitlock
1
Si Joe dice que puede hacerlo en poco más de una semana, entonces Joe sufrirá por el trabajo. Si Joe falla, las ventas aprenderán a rellenar sus estimaciones. Si Joe logra tener éxito, probablemente no queriendo pasar otra semana de 80 horas nunca más, ajustará sus propias estimaciones. Si nada de esto sucede, Joe será despedido por no cumplir con sus compromisos demasiadas veces, o se agotará y dejará de trabajar. Si está seguro de que Joe está vendiendo demasiado, entonces llame al farol. Simplemente no seas Joe; no vale la pena (vale, vale, MUY POCO vale la pena).
KeithS
El punto completo de la estimación ágil es que el precio es correcto y el ritmo es sostenible. Esas son cosas que tienen valor para un cliente; saber cuánto costará REALMENTE, y cuánto tiempo REALMENTE tomará, y que obtendrán lo que pidieron por ese precio y esa cantidad de tiempo, vale mucho más que una promesa de "superaremos cualquier precio" .
KeithS
1

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.

jim
fuente
¿Rápido y barato?
IAdapter
entonces no me va bien.
Jim
Creo que no les importa que sea bueno, sino solo para venderlo.
IAdapter
mientras sepan eso ... que así sea.
Jim
2
se preocupan acerca de que sea buena, que sólo te culparán para el proyecto en su defecto, cuando el cliente no está contento ...
jwenting
-1

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

Aaronaught
fuente
-1

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!

Tom Resing
fuente