2009-11-10 7 views
7

He estado en el negocio de desarrollar hardware y software durante 19 años. En los primeros días, los proyectos y equipos en los que trabajaba eran más pequeños, mucho más efectivos y más divertidos.¿El software que se desarrolla en un equipo grande puede ser interesante y divertido?

El efecto de la entrada de un único desarrollador para el producto final y su éxito fue evidente para todos. Tuvimos contacto directo y retroalimentación de los clientes. Esto fue gratificante para nuestro trabajo y una forma muy efectiva de mejorar el producto.

Con los años, la complejidad de hardware y software aumenta y cada vez se necesita más gente para hacer las cosas a tiempo. La desventaja de la tendencia hacia equipos más grandes para mí es que la contribución de un único desarrollador al éxito del proyecto se hace cada vez más pequeña. Y perdemos el contacto con el mundo real de los usuarios y clientes debido a los crecientes departamentos de control de calidad cada vez más.

Siempre he disfrutado de mi trabajo y me he mantenido al tanto de las últimas tecnologías como OOP, UML, .NET y lo que sea. Ya trabajé algunos años como líder de equipo pero no me gustó mucho porque me perdí el desarrollo y la codificación.

Estoy frustrado por el hecho de que mi parte de la "cosa" en la que estamos trabajando se hace cada vez más pequeña y pierdo la visión general sobre ella y el contacto con el suelo. Por favor, no me entiendan mal, no quiero llorar por los viejos tiempos, pero para mí el trabajo en más submódulos especializados de un sistema gigante simplemente se vuelve cada vez más aburrido.

Me pregunto si estoy solo sintiéndome así y tal vez si tiene algún consejo sobre cómo devolver la diversión a mi trabajo. Y lo siento, no, no estoy interesado en trabajar en un proyecto de código abierto en mi tiempo libre. Nueve horas al día frente a una pantalla de computadora son suficientes, la vida es más que la codificación ...

Respuesta

3

También requiero interacción y comentarios del cliente . Sin embargo, un cliente puede ser muchas cosas. Mientras estoy satisfaciendo alguien (usuario final, jefe de equipo, gran jefe, etc.) entonces eso es suficiente para mí. La interacción en sí misma es el factor clave.

En cuanto a la sensación de orgullo y propiedad de tener un gran impacto en el sistema, una vez más es una cuestión de enfoque. Todavía está creando algo, incluso si es una pieza más pequeña del todo.

Hace mucho tiempo me di cuenta de que soy un pez pequeño en un gran estanque. Aprendiendo a sentirme feliz por mi lugar en ese estanque era la única solución.

¡IOW, es todo relativo!

+0

Comentarios e interacción, ¡buen punto! exactamente eso es lo que me estoy perdiendo. – chrmue

1

Para responder a la pregunta tal como aparece en el título: ¡No!

Me siento muy similar y hablé con muchos otros que piensan lo mismo. Según mi experiencia, los equipos pequeños son mucho más divertidos para trabajar y por eso (y algunas otras razones) son mucho más efectivos.

2

Supongo que todo depende, hay un grado de camaradería que viene con los equipos más pequeños y una menor posibilidad de colisión del ego. He experimentado ambos y ambos tienen sus ventajas y desventajas. Para ser sincero, mientras trabajaba en un equipo más grande, aprendí mucho de otros programadores, crees que sabes mucho, pero alguien siempre sabe más.

2

Todo depende del equipo y los egos de las personas.

Cuando trabajas en un equipo con problemas de ego, no importa cuán buena sea la tecnología o cuánta interacción obtienes con los clientes. Una manzana podrida puede agotar toda la diversión de trabajar en un proyecto por lo demás genial.

Por otro lado, si el equipo se ha gelificado, importa muy poco si la tecnología está desactualizada, o si el problema del negocio es aburrido. Trabajar en un sistema contable de back-office con VI y compiladores beta de C++ de 10 años de edad todavía puede ser estimulante cuando sientes que tus compañeros están en la misma pelea y te dan la espalda. Cuando aprendes de los demás y te escuchan cuando tienes un nuevo enfoque para probar. Cuando los desarrolladores controlan el proceso de creación/prueba/implementación para que esté cuerdo y mejore la vida (y los patrones de suspensión) del equipo de soporte. Cuando tus compañeros (y tú ellos) siempre están dispuestos a ayudar con un problema de lenguaje oscuro o trabajar a través de un error enloquecedor. Eso es lo que hace que la programación sea divertida e interesante independientemente de todo lo demás.

2

Es posible que desee considerar el cambio de las empresas a una empresa más pequeña en la que haya tenido un conjunto más amplio de responsabilidades, por una sola idea. Además, ¿qué cambios hay en el proceso que podrían ayudar con los puntos que no te gustan?

¿Tengo aquí la pregunta de qué quiere decir con grande? ¿Un equipo de 50 personas en un proyecto sería grande? ¿O es más como 1,000 para ser grande? En un nivel estoy pidiendo escala, ya que hay equipos más allá de los grandes si uno quiere ver a todos los desarrolladores que trabajan en los grandes productos de Microsoft, como Office y Windows, mientras que en el otro extremo del espectro están los equipos de desarrollo de una persona que hacen todo.

Respondería la respuesta de Kelly de que depende del equipo y de los egos para otro factor importante en las cosas. ¿Qué consideras divertido? ¿Está encontrando formas más eficientes de resolver problemas que tienen soluciones pobres? ¿Está conquistando un Millenium puzzle? ¿O es ver a alguien sonreír mientras usa su software lo que lo hace divertido? Muchas respuestas posibles diferentes y mientras puedo hacer sugerencias, qué tan buenas o malas son es totalmente para que interpretes.

No creo que estés solo detestando cómo a medida que una empresa madura, el proceso puede cambiar a medida que se agregan nuevas personas en diversos roles con una mayor burocracia y pérdida de agilidad, ya que pueden necesitar más firmas para lograr un cambio permitido o los desarrolladores pierden ese contacto con el cliente de su producto. Hay un espectro de varias formas de producir software y algunos lugares pueden tener menos procesos y centrarse en "solo hacer que funcione", mientras que otros lugares pueden desear que el proceso sea mucho más formal y organizado con 1,001 políticas para cada detalle. . ¿En qué final quieres estar trabajando?

+0

Considero un equipo de 20 desarrolladores trabajando en un proyecto de software tan grande. – chrmue

+0

He estado allí hace unos años, donde teníamos ~ 16 desarrolladores de aplicaciones para el usuario, ~ 3 desarrolladores de modelos de objetos y una pareja que estaba trabajando en el sistema heredado del que estábamos sacando a la empresa, para poder relacionarme con Hay muchos dolores, especialmente en cuanto a que hay mucho código para trabajar y duele si hay un cambio después de que el trabajo haya comenzado. –

1

Gracias a todos por sus respuestas interesantes y valiosos (y para corregir la gramática y la ortografía :-)

Usted me dio algunos puntos grandes que pensar:

  • La interacción que falta con custumers (sea cual sea "cliente" significa)
  • La interacción y la retroalimentación dentro del equipo de desarrolladores
  • Lo que significa diversión para mí. Creo que es más la sonrisa frente al usuario que el uso de tecnología de punta.
  • Cómo lidiar con los procesos a veces abrumadores.
  • Por último, pero no por eso menos importante, para encontrar mi cómodo lugar en el gran estanque. Puede que no sea en el que me estoy quedando en este momento ...
Cuestiones relacionadas