2008-09-24 10 views
6

Soy un ingeniero de software/líder del equipo de control de calidad realmente joven. He estado desarrollando software durante aproximadamente 2 años y durante 1 de esos años también he sido el jefe del equipo de QA en una empresa de desarrollo de software. Actualmente, sigo trabajando como líder del equipo de control de calidad/ingeniero de software para herramientas de control de calidad. Recientemente, me invitaron a unirme a un grupo de amigos y asociados a quienes les gustaría crear una empresa de software. Quieren que sea el arquitecto/líder tecnológico del software (un cliente especial de chat escrito en Java es todo lo que puedo decir al respecto). Soy muy bueno para aprender bajo fuego y aprendo mucho al hacerlo. Sin embargo, me preocupa que mi falta de experiencia haga que el proyecto falle (o al menos se desarrolle mal). Así que me pregunto ¿sugerirías que tome el puesto, haga lo mejor que pueda y aprenda sobre la marcha? ¿O sugerirías que me niegue?Arquitecto de software realmente joven

Si me sugiriera que tomara el puesto, ¿podría proporcionar uno o los recursos que serían buenos para un arquitecto principiante de Java?

+0

¡Espero que lo hayan hecho! – D3vtr0n

Respuesta

7

Como líder de equipo, su activo más importante no es su experiencia, sino el equipo con el que trabaja. Si conoces y confías en estos tipos o contratas a tu propio equipo, entonces, por supuesto, hazlo. Lea primero un libro sobre buenas contrataciones (Joel on Software tiene un buen pasaje al respecto) si va a contratar a alguien.

Está preguntando sobre ello en Stack Overflow, por lo que al menos tiene la actitud correcta al respecto. Pide ayuda cuando la necesites. No intente sobrecompensar su falta de experiencia al no hablar de problemas. El hecho de que usted no sepa la respuesta a un problema no significa que un gerente experimentado tampoco. Verifica tu ego en la puerta y haz el trabajo. Serás respetado más por eso de todos modos.

Si estás entrando en un equipo consolidado con problemas y problemas propios, entonces es cuando ser un gerente experimentado realmente es útil. Esto me parece una oportunidad perfecta para mí. Nunca vas a tener experiencia como gerente, sin administrar.

17
  1. Esfuérzate por ser el tipo más estúpido de la habitación.
  2. Si te enferma de miedo, hazlo. Si te enferma de terror, huye.
+1

No puedo hablar por Matt pero creo que quiere decir, elegir personas más inteligentes para trabajar. –

+1

¿Por qué # 1? El tipo más tonto de la sala tiene más que ganar. Imagine un gráfico de barras de los niveles de habilidad de los miembros del equipo que animan: salir tarde hacia la cima en el transcurso de un proyecto. El chico con el más pequeño al comienzo gana más. Aprendiendo ahora == $$ después. –

+1

El consejo más importante que recibí sobre mi carrera fue la regla del "idiota de la aldea". Si vienes a trabajar y dejas de sentirte como el idiota de la aldea, no estás aprendiendo nada. Es hora de moverse. –

0

Debe expresar sus ideas a su nuevo equipo. El hecho de que seas abierto al respecto es una gran ventaja, diría yo. Haz tu mejor esfuerzo y mantén tu enfoque: ¡la experiencia no lo es todo, especialmente cuando eres consciente de tus defectos!

3

no lo diré a hacerlo o no, pero ...

voy a decir que si se quiere mejorar realmente su conjunto de habilidades y avanzar en su carrera, que tendrá que tomar riesgos y dejar su zona de confort de vez en cuando.

Además, como Desarrolladores, aunque somos más optimistas con respecto a proyectos/líneas de tiempo, también somos a menudo pesimistas sobre nuestros propios conjuntos de habilidades/habilidades y nos enfocamos en lo que no sabemos en lugar de lo que hacemos.

Si tiene alguna pregunta, tendrá que hablar de esto con sus posibles socios comerciales.

0

Desde que utilizó las palabras de Java y arquitecto en la misma frase, puedo sugerir los materiales de estudio utilizados en la certificación SCEA? En particular, encontré que Core J2EE Patterns es un libro realmente útil para pensar en problemas arquitectónicos de mayor tamaño.

0

Sea abierto con todos los demás en el grupo y asegúrese de que todos estén al tanto de los riesgos y comprenda cuál es el "peor de los casos". También necesita sentirse cómodo con todo el tiempo extra que le dedicará a lo largo de la duración del proyecto para ponerse al día técnicamente.

También pregúntese si puede hacerlo financieramente si el proyecto de hecho falla.

Si todos siguen a bordo, ¡parece una buena experiencia de aprendizaje!

9

Hablando como alguien que dio el salto a ser arquitecto en una empresa pequeña Creo que los siguientes elementos podrían ayudar:

  1. Usted sabe más de lo que cree. El hecho de que nunca haya sido arquitecto antes no significa que no sepa lo suficiente para serlo.
  2. Como arquitecto, usted siempre necesita aprender y mantenerse al tanto de las tendencias y las tecnologías. Prepárate para hacer eso.
  3. Escucha. Los miembros del equipo tendrán buenas ideas que desafíen todos tus prejuicios.
  4. Especialmente en una compañía pequeña usted es teniendo que ser consciente de la política en un rol de arquitecto. No era consciente y me quemé como resultado. Esto puede afectar tus amistades.
  5. Las pequeñas empresas pueden pasar sorprendentemente rápido. Planifique esto y no tenga compromisos financieros que signifiquen que no puede estar sin trabajo por un corto tiempo.
0

No me preocuparía tanto por ser la causa potencial del fracaso de la empresa. Esté al tanto de sus preocupaciones, pero atempere eso con su habilidad (y deseo) de aprender.

Usted debe examinar los arreglos financieros y comerciales de los fundadores de la empresa. Diría que es mucho más probable que la empresa fracase por razones de "negocios", en lugar de razones tecnológicas.

0

Si puede unirse al grupo sin tener que dejar su trabajo, sería genial. Pero si tiene que elegir qué camino tomar y a quién despedir, solo usted puede tomar esa decisión. Sigue a tu corazón y nunca te perderás.

0

Según lo que ha dicho hasta ahora, este proyecto fallará. Diablos, la mayoría de los proyectos nuevos fallan. Si estás de acuerdo con eso, ¡adelante! Será una buena experiencia de aprendizaje para ti :) Solo asegúrate de no perder amigos íntimos al respecto.

1

No hay muchos recursos útiles e independientes en la arquitectura del software. Una vez que filtra el marketing de proveedores y las cosas de la torre de marfil de mano, parece que hay muy poco consejo práctico.

Una buena es Coding the Architecture que se concentra en las manos en la arquitectura, y tiene una buena cantidad de información para los desarrolladores que hacen la transición al arquitecto (información completa - He estado involucrado con esto de una manera pequeña).

Además, hay un simillar question sobre blogs de arquitectura con algunas muy buenas respuestas.

0

Encontré el libro de Craig Larman sobre el desarrollo iterativo de software realmente útil a través de los años. alt text

0

Como líder de equipo, debe ser bueno para sacar lo mejor de su equipo, así como también para aprender por su cuenta. Al mejorar sus propias habilidades al 100%, puede aumentar la productividad de su equipo en un 10%. Al mejorar la productividad del equipo al 100%, lo mejora ... 100% por supuesto.

Su valor para el inicio de su amigo no es solo su pura capacidad de codificación, sino también que lo conocen y confían en usted como socio. Obviamente para ellos ellos sienten que pueden contribuir con un valor real, así que mi sugerencia es que "lo falsifiquen hasta que lo logren" :)

Cuestiones relacionadas