Desarrollador en solitario en una startup [cerrado]

Todo lo que mencionaste suena bastante común en el desarrollo de software y/o trabajar en una empresa nueva (por lo que escuché), sin mencionar la combinación de los dos y ser el único desarrollador sin (aparentemente) ninguna persona a la que informar.

Algunas soluciones posibles:

• Trata de administrar mejor tu tiempo. No estoy seguro de si esto se aplica a usted, pero un desarrollador que cambia constantemente entre tareas o es interrumpido, a menudo carece de una productividad óptima, ya que realmente necesita dedicar un poco de tiempo a algo para aumentar la velocidad. Lo que me lleva a...

• Trate de administrar mejor a las personas. Definitivamente no soy el experto en esto, pero tal vez podría intentar recibir todo menos las tareas más urgentes por correo electrónico o mediante reuniones formales (programadas por correo electrónico, posiblemente programadas para que sucedan en algunos momentos preferidos durante el día ) causando muchas menos interrupciones. Esto supone que no trata los correos electrónicos a medida que llegan (ya que esto tiene el mismo problema), sino en algunos puntos predefinidos durante el día.

  Me imagino que también necesitará, de una forma u otra, señalar que no podrá ocuparse de las tareas asignadas por ciertas personas de inmediato, ya que tiene tareas más urgentes que atender, ocasionalmente reprograme las tareas si hay algo más urgente. surge y prioriza las tareas asignadas por diferentes personas, ya que es bastante probable que no discutan la prioridad de sus tareas entre ellos, dejándote hacer eso, o que trabajes hasta la muerte para tratar de mantener a todos felices.

  Lo anterior puede ser difícil de hacer, especialmente considerando que la mayoría/todas las personas que le asignan estas tareas probablemente sean personas mayores, por lo que es posible que necesite ayuda...

• Ve a hablar con tu jefe. La mayoría de la gente sería comprensiva y trataría de llegar a algún tipo de arreglo que funcionara para todos. Ellos tal vez:

  • Consíguete otro desarrollador. La misma cantidad de trabajo, el doble de trabajadores - buen plan.

  • Ayude con parte/la mayoría/toda la parte de "Tratar de administrar mejor a las personas" manteniendo una conversación informal con las partes correspondientes, o implementando algún marco formal para programar su tiempo (y tal vez el tiempo de otros empleados de manera similar). guión). Esto podría implicar tratar de...

  • Consíguete un director de proyecto. Lo más probable es que también sea alguien con otras responsabilidades (posiblemente ya trabajando allí), ya que no es muy probable que alguien solo administre su tiempo, a menos que usted sea la gerencia. Lo ideal sería que fuera alguien que sepa lo suficiente sobre el desarrollo de software, ya que una queja muy, muy común es que los demás simplemente no "entienden": esperan cosas irrazonables, no entienden por qué las cosas tardan tanto, etc. Tener a alguien que conozca la jerga empresarial para explicar estas cosas en términos comprensibles para todos los demás, mientras elimina la mayoría de sus distracciones (ya que las personas deberían hablar con el gerente del proyecto, en lugar de hablar con usted directamente, para programar su tiempo) debería ayudar mucho.

• Solo espera. Las empresas emergentes no son empresas emergentes para siempre. Definitivamente puede esperar muchas horas en muchas empresas emergentes, pero, si la empresa tiene éxito, debería cosechar las recompensas a lo grande. Ahora bien, no estoy diciendo que debas trabajar hasta la muerte tampoco: trabajar demasiadas horas durante largos períodos de tiempo es perjudicial para la productividad; tendrás que averiguar si puedes encontrar un equilibrio aceptable entre trabajar una cantidad de horas sostenible y haciendo la cantidad requerida de trabajo.

• Abandonar. Como se mencionó anteriormente, los problemas que tiene son bastante comunes y no necesariamente algo que pueda cambiar en un rol determinado, por lo que, si todo lo demás falla, es posible que no tenga otra opción que presentar su renuncia.

Hablar

Si eres un desarrollador independiente en una startup, entonces la 'gestión de las partes interesadas' es una situación completamente diferente de lo que suele ser en las grandes empresas. No debería haber tantos de ellos: colóquelos en la misma habitación y hablen.

¡ Esa charla es una gran cosa para la compañía en esta etapa! La puesta en marcha necesita muchas cosas técnicas para hacer; y eres (por el momento) el motor principal de una startup tecnológica. El orden y las prioridades de los proyectos tecnológicos son una decisión clave de alto nivel que afecta en gran medida a toda la empresa. "Hacer todos los proyectos a la vez por igual" puede ser una estrategia muy estúpida si no puedes hacer todos los proyectos.

Estima conociendo tus circunstancias

Sabe que tiene X proyectos paralelos y ya ha visto cómo tienden a aparecer grandes tareas inmediatas de mantenimiento/corrección de errores. Si hace estimaciones, tenga eso en cuenta: una tarea de cuatro horas no se realizará esta noche, porque tiene que terminar la tarea actual que llevará hasta el almuerzo, corregir algunos errores que llevarán de 0 a 3 horas y hacer eso. otra tarea para ese otro proyecto que prometiste ayer; así que ni siquiera comenzarás esa tarea de cuatro horas esta noche.

Acostumbrarse a él

En un futuro previsible, el medio ambiente será exactamente así. Lo único que podría cambiar es su propia comprensión y la comprensión de sus compañeros de equipo.

Habrá esos cambios rápidos en los requisitos y el desperdicio de trabajo semiacabado; habrá una necesidad de estimar rápidamente (¿estimar? ¡prototipo!) ideas que no existían hace una hora; la necesidad de hacer cosas imposibles lo antes posible; e iteraciones cortas con muchos entregables. Eso no cambiará. Sin embargo, la incapacidad de hacer todo no te convierte en un mal trabajador para este puesto (a menos que te rompa psicológicamente).

Cambio de efecto

Como único desarrollador de una startup, debería poder influir en la forma en que se realizan los proyectos técnicos allí. Si no lo es, bueno, a menos que el statu quo sea excelente (y parece que no lo es), entonces debería salir antes de sacrificar su salud y cordura sin una buena razón; pero deberías poder cambiar las cosas.

Puede cambiar las expectativas: comprenda su tiempo, no prometa demasiado, no se queme y mantenga a los demás informados incluso de las verdades desagradables. Si prometiste que X se hará mañana, pero las cosas más importantes te llevarán hoy, mañana y el día siguiente también, está bien; en una startup todo el mundo sabría (¿debería?) saber esas otras cosas y entenderlas; pero debe mantenerlos informados de que en realidad X no se hará para que puedan replanificar en consecuencia. Es de esperar, al igual que tiene que cambiar los planes porque los requisitos cambian constantemente, probablemente se utilicen para hacer lo mismo.

Puede cambiar la forma en que trabaja: 'moverse rápido y romper cosas' es un estilo de trabajo muy diferente de 'verificar tres veces cada entrega en busca de errores tipográficos'; en una startup puede ser beneficioso (y necesario) sacrificar calidad para ganar tiempo. A menudo, un prototipo mínimo que se mantiene unido con hilo y goma de mascar puede ser suficiente. La deuda técnica puede ser una carga real, pero a veces es la estrategia adecuada asumir una deuda técnica a sabiendas: hay muchas empresas emergentes exitosas que necesitaban desechar y reemplazar los horribles sistemas de código+que tenían inicialmente; pero no tendrían éxito si se hubieran tomado el tiempo de construirlos correctamente la primera vez.

Puede cambiar el enfoque: en una puesta en marcha, habrá muchas cosas que parecerán necesarias con urgencia y prioridad n.º 1. Aproximadamente la mitad de esas cosas no se harán de todos modos, y sobrevivirá otro año sin ellas, pero si elige incorrectamente, la puesta en marcha fallará. Probablemente sea más una decisión de quien lo contrató, pero es muy probable que la mitad de los proyectos deban posponerse para que la otra mitad se haga más rápido y mejor.

Creo que el mayor problema que tienes es el hecho de que estás trabajando en estos proyectos y no hay una estructura o dirección clara. Lo peor del mundo es una vez que comienzas a construir algo en lo que pensaste mucho y la gente viene y comienza a exigirte más.

Podría intentar modularizar todo lo que hace y construir para la reutilización y documentarlo a fondo. Cuando los gerentes o los clientes acuden a usted y le solicitan muchas funciones, debe poder decir que no. Sé que siente que necesita complacer a todos, pero no debe ser 100 % flexible al implementar nuevas funciones que no se pensaron detenidamente. A la larga, esto afectará los productos en los que está trabajando.

Debe tomar el control y exigir resultados claros y solo permitir pequeños cambios en cada sprint para que no afecte los objetivos que estableció para esa semana. Además, ¿trabajas los fines de semana? Entiendo la dedicación, y también solía hacerlo, pero el fin de semana está ahí para tomar un descanso o trabajar en las cosas que amas y que te ayudarán a largo plazo, no solo un proyecto estúpido que tienes. no será capaz de mostrar o utilizar para aprender un montón de cosas nuevas.

Entonces, al final, planifique mejor, no tome todas las sugerencias y explique cómo esto afecta la calidad de su proyecto. Apuesto a que muchas de esas cosas no son realmente necesarias. Planifícalos para otro sprint más adelante. Tome a sus gerentes o a su cliente y tenga una larga discusión explicando el proceso que tiene implementado y cómo estas perturbaciones afectan la calidad de su trabajo. Si el gerente no es técnico, siéntese con él y explíquele todas estas cosas. Entonces podría entender cómo funciona el proyecto, aprender algo nuevo y tal vez juntos puedan encontrar una mejor manera de hacer las cosas.

Espero que esto ayude. :)

¿Es normal tener lo que describí arriba?

Sí. Muy. Uno de los grandes desafíos de la ingeniería de software (y de la ingeniería en general) es determinar estimaciones de tiempo razonables para las solicitudes de trabajo. Trabajar en estrecha colaboración con las partes interesadas para acordar expectativas razonables.

¿Cómo puedo manejar la situación para que todos estén felices?

No se puede complacer a todas las personas todo el tiempo. Siempre habrá más demandas, y eso es bueno. Simplemente haga lo mejor que pueda, sea lo más productivo posible mientras mitiga la deuda técnica y relájese con el resultado. Alta intención, bajo apego. Además, obtenga el equilibrio adecuado entre la obligación con su empleador y la obligación con su propia salud y bienestar.

Esto es lo que, en mi opinión, querrás hacer:

Documenta todo.

Si no está familiarizado con la elaboración de documentos de diseño, considere este un buen momento para agregar esa habilidad a su currículum. He trabajado en trabajos como este y lo que absolutamente debe hacer, antes de hacer cualquier otra cosa, es elaborar un documento de diseño que explique en detalle todos los escenarios de casos de uso que pueda imaginar, hable sobre todo el final. campanas y silbatos de usuario que su cliente quiere que agregue, e incluso (si puede administrarlo) proporciona un marco de tiempo general de cuándo proporcionará qué entregables.

Según mi experiencia, esta es, con mucho, la parte más importante de este proceso. Me doy cuenta de que los que no son expertos en tecnología no siempre disfrutarán de reunirse con usted para decidir de antemano qué botones deben estar en una página o lo que sea ("¡ese es SU trabajo!"), pero al menos, el hecho de que haya puesto este documento juntos significa que más adelante, cuando su cliente le diga que quiere agregar las funciones X, Y y Z, puede decirle "está bien, claro, puedo hacerlo, pero hará que este producto tome [cantidad de tiempo] más tiempo para desarrollarse.

Ah, sí, ¿y cuándo se agregan estas funciones? Póngalos en el documento de diseño y haga que el cliente apruebe los cambios.

Me doy cuenta de que, como desarrollador, esto se siente como mucho tiempo extra haciendo algo que en realidad no es programación y, por lo tanto, no se siente ni productivo ni divertido, pero míralo de esta manera: tu documento de diseño servirá como algo similar al esquema de el libro que vas a escribir. Nadie va a "leer" el libro en el sentido clásico del término, pero lo van a usar y es importante saber exactamente de qué va a tratar ese libro antes de empezar a escribirlo.

Proporcione los entregables tan pronto como pueda.

Lo que quiero decir aquí no es que debas cumplir con el cronograma, porque por supuesto que quieres hacer eso (y por lo que parece, puede que no sea algo fácil de hacer de todos modos). Lo que quiero decir es, tratar de conseguir algoDígale a su cliente que puede revisar y aprobar/solicitar cambios lo más rápido posible. Si está diseñando una página web o una aplicación WPF, por ejemplo, consígales una estructura alámbrica tan pronto como sea posible. A medida que lo conecte y agregue funciones, preséntelos a su cliente tan pronto como los termine para que puedan probarlos (advertencia: algunas personas simplemente no probarán cosas hasta que se activen o estén a punto de hacerlo, así que no confíe en esto, sin embargo, puede usar esto como una oportunidad para decir "Le presenté la función X hace 3 semanas. Puedo cambiar la forma en que funciona con seguridad, pero esto tomará X cantidad de tiempo adicional".

Trate el desarrollo, las pruebas y el diseño como partes interrelacionadas de un proceso más amplio, no como etapas que pueda despejar.

Me sorprende cuando los desarrolladores hacen esto, y no digo que lo hagan, pero es necesario decirlo: el momento de refactorizar el código es siempre que tenga la oportunidad, el momento de rediseñar es cuando el cliente solicita algo que no puede proporcionar en el diseño actual, y el momento de la prueba es siempre que esté programando. Me doy cuenta de que este método puede crear código de espagueti, pero es por eso que refactoriza.

Además, si usted es el único desarrollador en su empresa, sus compañeros de trabajo/clientes no sabrán cuál es el "proceso de desarrollo". Tendrán requisitos que quieren que cumplas. A veces, a la mitad del trabajo, se darán cuenta de que un requisito que le dieron debe ser más sólido, o que la forma en que resolvió un problema crea problemas no funcionales que no expresaron al principio.

Nunca digas "No puedo".

Bueno, supongo que si quieren que diseñes una nueva versión de Call of Duty tú solo en 2 semanas, puedes decir que no puedes hacerlo en esa cantidad de tiempo. Pero lo que quiero decir es: si tus clientes/compañeros de trabajo te dan una función, no les digas que no se puede hacer. Si va a ser difícil implementarlo en su diseño existente, avíseles que necesitará refactorizar un poco y que llevará más tiempo (trate de proporcionar un tiempo exacto; si se excede o se queda corto, siempre puede ajustar eso más tarde). Si literalmente no sabe cómo hacer algo, aconseje que necesitará investigar la solución y que les dará una estimación del tiempo adicional dentro de uno o dos días. Si hay una limitación física que le impide hacer lo que quiere, o si lo que quiere violaría algún otro principio ("oye,

Comunicarse constantemente.

Si puede manejarlo, una breve reunión diaria de estilo "scrum" de 10-15 minutos en la que discuta brevemente en qué está trabajando y tal vez obtenga algunas aclaraciones menores es buena incluso con los que no son desarrolladores . Sé que a veces puedes entrar en ese "infierno de reuniones" en el que pasas más tiempo hablando con la gente sobre lo que quieren que dándoselo, pero en general creo que los programadores tienden a equivocarse y agachar la cabeza. y simplemente hacer las cosas, por lo que no es una mala idea tal vez empujarse hacia la verificación constante con sus partes interesadas.

Por lo menos, una reunión semanal o dos veces por semana en la que presente lo que ha hecho hasta ahora y discuta los desafíos que se avecinan debería lograr algunas cosas:

1. Te ayudará a cultivar tus propias habilidades de comunicación (por no decir que aún no eres un buen comunicador, pero esto es algo en lo que todos los desarrolladores pueden y deben trabajar).

2. Le dará a su cliente/compañeros de trabajo la confianza de que a. sabes lo que estás haciendo y b. entiendes sus necesidades.

3. Si se atrasa en algo, o si hay un cambio importante que de repente es necesario, usted y sus clientes/compañeros de trabajo no se sentirán sorprendidos por esto.

De todos modos, eso es lo que tengo. Míralo como un desafío y una oportunidad, no como algo que necesariamente hará que te arranques los pelos. Trabajar con personas que no son expertas en tecnología puede ser una maldición (a veces te piden que hagas cosas que son casi imposibles y no entienden por qué no puedes simplemente hacerlas) pero también una bendición (a veces la pequeña adición más pequeña que tomó todos los 5 minutos para codificar pueden hacerte sentir y parecer un héroe total).

Aquí hay algunas respuestas excelentes sobre la gestión de los requisitos, pero también me gustaría resaltar que tendrá que gestionarse a sí mismo y a las partes interesadas.

Por ejemplo, trabajar los fines de semana no es una solución ni siquiera a corto/mediano plazo. Dan Cook tiene un excelente resumen de la investigación sobre la productividad en la Presentación de las Reglas de Productividad . El TL;DR se resume en un gráfico en esa página y dice que 40 horas a la semana es lo óptimo para la productividad a largo plazo: solo toma un mes de 60 horas a la semana antes de que la fatiga le cueste la productividad adicional (y está trabajando 60 horas a la semana para lograr 40 horas de trabajo), y en las próximas 4 semanas perderá tanta productividad como ganó en las primeras 4.

Puede haber una cultura muy machista en torno a las empresas emergentes, pero eso no significa que sea correcto.

Ejecución, inicio exitoso es N% de idea y (100-N)% de ejecución , es decir, su suposición acerca de aprender cosas nuevas generalmente era incorrecta.

New Stuff, presumiblemente estás trabajando en algo nuevo, por lo que una suposición sobre los marcos existentes, etc., también es bastante defectuosa.

Negocios, la puesta en marcha se define típicamente como un intento de encontrar un modelo de negocio repetible y escalable . Es decir, no se trata de su código, ni siquiera de quién lo codifica, ni siquiera se trata estrictamente de lo que hace, se trata de cómo se recibe, cómo encaja (idealmente interrumpe) el ecosistema existente.

¡Adaptar! Finalmente, para ser un emprendedor exitoso, debe adaptarse, debe anticipar el esfuerzo de desarrollo requerido y cambiar el rol de desarrollador a, digamos, RRHH para encontrar algunos buenos programadores , o gerente para cuidar a los desarrolladores junior y pasantes, o subcontratar especialista si parte del código se realiza fuera de las instalaciones, o administrador de sistemas cuando sea necesario o un portavoz para promover su inicio en una conferencia.

Es de esperar que tenga una participación en esta empresa consistente con ser uno de los fundadores o el primer empleado o desarrollador único o cto (su publicación no especificó). Verifique si ese es el caso y, de lo contrario, solicite a sus fundadores que ajusten su posición fiscal. Si fallan, déjalo lo antes posible.

Finalmente, las nuevas empresas son cosas diferentes para diferentes personas, mira esa película sobre la historia de Apple , para algunos es dinero (después de bastardos), para otros es novedad y excelencia en ingeniería (a menudo jodida), pero para otros es una gran experiencia y para otros todavía es Una Forma de Vida. Las startups no son para todos, pero cualquiera es libre de intentarlo. Esa es la belleza 😼

Hombre, esta publicación trae recuerdos de trabajos pasados. Poniéndose todo sentimental.

Si tengo un consejo es este: PRIORIZAR. La mayoría de las cosas que la gente quiere de ti simplemente no se van a hacer; solo hay tantas horas en el día y solo uno de ustedes. Priorice y trabaje primero en las cosas más importantes: los proyectos que obtendrán la mejor relación de retorno del tiempo invertido.