En este año de crisis, son muchos los desarrolladores / programadores que se lanzan (debido a la falta de trabajo) al desarrollo de una Startup. Hablo por experiencia propia que no existe una actividad más recomendable y fortificante. El trabajo y esfuerzo que desarrollareis se verá recompensado bien en forma de la creacción de una empresa innovadora o bien en forma de un currículum diferencial.
Este tipo de “iniciativas” me valió conseguir el puesto de director de proyecto en una mediana empresa, hace ya un par de años y ahora mismo me encuentro volviendo a mis orígenes, pensando ideas innovadoras independientes sobre las cuales lanzarme.
Ahi van una serie de consejos practicos:
1. No te desesperes y atiende únicamente a tus desarrollos, no al resto de tareas.
Como el único desarrollador, es muy tentador llegar a encontrarse técnicamente indefenso debido a la cantidad de diferentes tareas a realizar. Eso sería un gran error pudiendo incluso paralizar la empresa.
Los programadores! = Soporte técnico y un equipo de desarrolladores no hacen un departamento de TI. Instalación de software, creación de una red, el cambio de copia en el sitio, etc no es necesariamente el trabajo de los desarrolladores.
2. Casi ningún cambio es sencillo y trivial.
Yo solía decir: “esto debe ser un cambio bastante trivial,” mucho más de lo debido. Sólo porque algo es lógico y tiene sentido, no significa que la estructura de código pueda apoyarlo. De lo que puedo decir, no hay nada más frustrante para un ingeniero que nos soliciten la actualización de funcionalidades con el pensamiento de que sean “sencillas”, puesto que debido a la situación y estructura del código planteada, esto podrá ser así o nó!
3. La regla 90/10.
Al empezar el desarrollo de un programa o aplicación de software, podemos hacer casi lo que queramos porque no está limitado por lo que ya has construido. Así que el primer 90% pasa muy rápido, y puedes ver un montón de progresos tangibles. Se pasa de la nada a un modelo muy rápidamente, y es emocionante.
Para la realización del otro 10% se tarda una eternidad, siendo difícil para los no ingenieros darse cuenta de los progresos realizados puesto que casi siempre consisten en pequeños detalles y correcciones de funcionalidad.
Tenga el dato del 10% muy en cuenta para planificar el tiempo de desarrollo de los proyectos.
4. Software nunca se acaba.
El software es como un organismo vivo. La aplicación cambia y se transforma, añadiéndose características y modificaciones constantemente.
La aplicación necesita ser actualizada, corrección de vulnerabilidades mediante parches más o menos estables, y los errores deben de ser subsanados. Este punto es importante tenerlo en cuenta para no desesperar y continuar siempre al pie del cañon, tomatelo con filosofía y administra bien tu tiempo puesto que este tipo de tareas es lo más desagradable que tiene que hacer un programador.
5. Los no ingenieros (compañeros) no son “diseñadores” de forma casual.
Es fácil decir: “ya que no escribo código, yo estoy a cargo de diseñar el sitio y mejorar la experiencia del usuario.” Y después de decir eso, es fácil establecerse un montón de roles para ayudar al resto del equipo.

Esto será contraproducente y solamente traerá quebraderos de cabeza, puesto que ninguna de las tareas de las que se ocupe estará bien realiadas, necesitando una constante supervisión por parte del ingeniero. No es tanto un arte como una ciencia para diseñar y trabajar las experiencias del usuario, que toma tanto tiempo para dominarlas , como dominar las habilidades más técnicas de programación.
Creo que la mayoría de los compañeros no técnicos al trabajar en su primera compañía de Internet conocen estos impulsos. Debido a que no son técnicos, quieren ayudar en cualquier otro aspecto.
Ellos no son autoridades en el diseño y el producto, de hecho, podría fácilmente significar lo contrario. “No asuma automáticamente que los ingenieros no pueden diseñar!”
6. Efuércese por hacer entender al equipo la parte técnica.
No intente ser más técnico de lo que se requiere ya que perderá toda credibilidad. Sea honesto acerca de sus habilidades técnicas, realmente pidiendo ayuda y esforzarse al máximo para contribuir, ya que de esta manera involucrará al equipo completo en las fases de planificación de la arquitectura o resolución de algún problema concreto.