Consejos para Programadores de Forobeta

  • Autor Autor Think Big
  • Fecha de inicio Fecha de inicio
Think Big

Think Big

1
Ni
Verificación en dos pasos activada
Verificado por Whatsapp
Suscripción a IA
Hola,

Me gustaría compartiros una serie de consejos para los programadores de Forobeta.

Tengo amplia experiencia contratando programadores y creo que le puede servir de ayuda a más de uno al trabajar con clientes. He trabajado con más de 30 programadores hasta ahora.

Del 100% de los programadores que me contactan o contacto, al final acabo trabajando con el 10% y estas son algunas de las razones de por qué filtro tanto.

- Los tiempos de entrega de proyectos hay que respetarlos. A no ser que los requisitos del proyecto se modifiquen durante el transcurso del proyecto, el programador tiene que ser capaz de estimar un tiempo de entrega en base a las horas que le va a dedicar al día y a lo rápido que sea programando. Siempre se recomienda tener unos 3-5 días de margen por posibles imprevistos. No es profesional entregar un proyecto 2 semanas más tarde porque tu planificación no fue la correcta. La próxima vez es posible que no cuente contigo.

- Cuando un programador decide aceptar un proyecto, tiene que tener claro que es capaz de realizar todo lo que el cliente pide. El proceso de aprendizaje, por lo general, se recomienda hacerlo en el tiempo libre, no en proyectos de clientes. Si hay algo del proyecto que no sabes, alguna API que no manejas o algún lenguaje de programación que no entiendes, piénsatelo dos veces antes de aceptar el proyecto. No es agradable la situación de que en medio de un desarrollo, un programador te diga que no sabe como usar cierta tecnología.

- No te limites a lo básico. Hoy en día casi todos los programadores saben PHP, MySQL, HTML, CSS y JS. Cuando los sacas de ahí se pierden. El mundo de Internet avanza muy rápido y lo que hace 5 años se hacía con PHP, dentro de 5 años se va a hacer con NodeJS, lo que se hacía con MySQL, se hará con MongoDB o lo que se hacía con HTML, CSS y JS se hará con AngularJS por poner algún ejemplo. Existen otros lenguajes tipo Python, Ruby que también son interesantes. Si te diferencias del resto, podrás aceptar más trabajos y podrás cobrar más por tus trabajos.

- Hay que ser meticulosos con lo que el cliente pide y no asumir cosas. Si el cliente es específico en lo que quiere, no vale entregar algo "parecido". Si tienes cualquier duda porque los requisitos no son claros, es mejor aclararlo antes con el cliente, en vez de programar algo y que luego no sirva. Por lo general, los clientes no son programadores por lo que es posible que pasen cosas por alto. Conviene aclararlo antes de empezar los proyectos. Por supuesto, no olvidarse de requisitos que el cliente ha pedido y que no están implementados en el componente software.

- Si dispones de conocimiento por encima de la media, no dudes en valorar tu trabajo. Un cliente, si ve que el programador sabe de lo que habla, no le importa pagar un extra por tener un trabajo de calidad y menos tiempo. En mi caso, prefiero pagar $1K por un desarrollo y tenerlo en 20 días que pagar $500 y tenerlo en 2 meses. Probablemente el desarrollo de $1K me ahorrará más tiempo ya que el programador tiene más experiencia y sabe cómo hacer las cosas.

- La comunicación entre el programador y el cliente es un aspecto fundamental. En mi caso, uso tanto Skype como email. Si una persona quiere trabajar conmigo y tarda 3-4 días en responderme a Skype, queda totalmente descartada, da igual lo bueno que sea. Sin comunicación, los proyectos no avanzan. El email se debe usar nada más para pasar documentos, claves y contratos. Las dudas puntuales, por Skype mejor. Este es uno de los puntos que más me han hecho descartar programadores.

- Para proyectos grandes, es imprescindible trabajar con un organizador de tareas tipo Trello. Los desarrollos grandes se deben dividir en Sprints y cada Sprint en tareas. Debe haber movimiento en el dashboard desde la primera semana, no vale hacerlo todo en la última semana porque al final siempre hay imprevistos y modificaciones del cliente que hacen que se retrase el proyecto si se hace todo la última semana. El feedback del cliente es super importante.

- Me es indiferente si tienes un título universitario que dice que eres experto en computación o en informática. Lo que me vale es que sepas programar y que sepas desarrollar mi proyecto. Si eres una persona autodidacta que ha aprendido a programar por Internet, seguramente tengas más experiencia que licenciados que recién salen de la carrera. No contrato por título, contrato por conocimiento, por resultados.

- Tu localización geográfica me es indiferente, al igual que tu zona horaria. Si eres bueno, da igual que seas de Mexico, Argentina, Venezuela, Perú o España. El idioma entre LATAM y España no es un problema hoy en día.

- Un portfolio de proyectos o de código es esencial. Si no puedo ver trabajos tuyos previos, me da igual que me digas que eres bueno en X o en Y. No te conozco y la única forma de saber si eres bueno, es viendo proyectos previos. Valoro mucho que el programador tenga mentalidad open-source, eso significa que le gusta programar y que no tiene inconveniente en programar gratis para la comunidad. Esto no quiere decir ni mucho menos que no le pague, que quede claro. La programación es una pasión, no debe ser una obligación para ganarse el pan de cada día. Si dispones de proyectos similares a lo que el cliente pide, suma muchos puntos a la hora de tomar una decisión.

- Por último, si entras dentro de ese 10% de programadores que contrato, ten por seguro que me va a interesar trabajar contigo en el largo plazo y vas a tener un cliente que te va a ofrecer trabajos de forma constante. Si tú me haces ganar dinero, yo te hago ganar dinero, es así de simple. Yo corro con el riesgo de desarrollar algo sin saber cómo va a funcionar al 100%, por supuesto. La gente buena hay que cuidarla y valorarla 🙂

Espero que sirva de ayuda. Si algún programador quiere comentar algún punto, encantado de hacerlo.

Disculpad por el parrafazo, pero últimamente no estoy encontrando la calidad que me gustaría en los programadores. Todo esto es desde mi punto de vista.


ACTUALIZACIÓN: Tras trabajar con 30 programadores, aquí algunos datos de los motivos por el cuales no vuelvo a trabajar con ellos. Hay una diferencia increíble entre trabajar con buenos profesionales a trabajar con profesionales mediocres y malos.

ww9lUGo.png
 
Última edición:
Gracias por compartir tus experiencias trabajando con programadores. Seguramente empleare varios de tus consejos con mis clientes [emoji6]
 
Subo este tema para que más gente pueda verlo.
 
- No te limites a lo básico. Hoy en día casi todos los programadores saben PHP, MySQL, HTML, CSS y JS. Cuando los sacas de ahí se pierden. El mundo de Internet avanza muy rápido y lo que hace 5 años se hacía con PHP, dentro de 5 años se va a hacer con NodeJS, lo que se hacía con MySQL, se hará con MongoDB o lo que se hacía con HTML, CSS y JS se hará con AngularJS por poner algún ejemplo. Existen otros lenguajes tipo Python, Ruby que también son interesantes. Si te diferencias del resto, podrás aceptar más trabajos y podrás cobrar más por tus trabajos.
mmmm tienes razon , pero no significa que debemos aprender exactamente lo que dices pero tienes razon en no quedarnos en lo basico , debemos seguir aprendiendo mas lenguajes de programación y no quedarnos estancados..
En estos momentos estoy aprendiendo redes (CISCO).

de ahi todos son muy muy buenos mensajes el tiempo del trabajo , admito que siempre hay problemitas ejemplo les digo 5dias y paso los 5dias , cuando me paso de los 5 dias que le dije me contacto con el usuario me disculpo, casi no me pasa pero solo me paso maximo 1 día.

Tambien lo que dijiste en no aceptar trabajos si no tienes tiempo libre , por eso no trabajaba de programador hace unos meses atras , ahora recien me estoy desocupando y por eso estoy trabajando nuevamente.
lo que mas odio es que mis clientes piensen mal de mi , yo quiero darles la mejor calidad posible.

Lo que me falta es un portafolio de trabajo, tendre que hacerlo tarde o temprano 😕 .

thanks you.
exitos.
 
Última edición:
Desgraciadamente eso de dar tiempos siempre es un problema, pero con el tiempo vas aprendiendo a calcular mejor tus proyectos y también como bien comentas es mejor dejar unos dias de gracia y no dar un tiempo tratando de impresionar al cliente con lo rapido que le vas a entregar.

en mi trabajo manejo un equipo de programadores, algo que personalmente les critico es no buscar mas haya de lo que les enseñan en la escuela
 
mmmm tienes razon , pero no significa que debemos aprender exactamente lo que dices pero tienes razon en no quedarnos en lo basico , debemos seguir aprendiendo mas lenguajes de programación y no quedarnos estancados..
En estos momentos estoy aprendiendo redes (CISCO).

de ahi todos son muy muy buenos mensajes el tiempo del trabajo , admito que siempre hay problemitas ejemplo les digo 5dias y paso los 5dias , cuando me paso de los 5 dias que le dije me contacto con el usuario me disculpo, casi no me pasa pero solo me paso maximo 1 día.

Tambien lo que dijiste en no aceptar trabajos si no tienes tiempo libre , por eso no trabajaba de programador hace unos meses atras , ahora recien me estoy desocupando y por eso estoy trabajando nuevamente.
no que mas odio es que mis clientes piensen mal de mi , yo quiero darles la mejor calidad posible.

Lo que me falta es un portafolio de trabajo, tendre que hacerlo tarde o temprano 😕 .

thanks you.
exitos.

Sí, lo puse como un ejemplo de tecnologías a aprender. Está claro que puedes aprender lo que quieras, pero tienes que estar pendiente de hacia donde va la industria y qué lenguajes están usando las grandes webs (Facebook, Twitter, Google, LinkedIn, Pinterest etc.)

Claro, respecto al tiempo, si es 1 día, no pasa nada, pero es mucho mejor establecer tiempos de entrega concretos. En mi caso, penalizado el presupuesto si hay retraso, por lo que el programador tiene que tener muy claro cómo estimar y siempre sobreestimar un poco más por si acaso.

El portfolio de trabajos es la diferencia entre que te contraten 3 personas y te contraten 30, creemé.

Suerte!
 
En lo personal, si no tengo tiempo o si no manejo algo no tomo trabajos, si no manejo algo que me pide un cliente lo estudio en los tiempos libres, lo de portafolio para mi es algo complicado porque siempre son modificaciones a sitios o scripts pequeños.

Enviado desde mi Nexus 5 mediante Tapatalk
 
Excelente lo que escribiste, es muy bueno tener estos puntos de referencia (feedbacks) para saber como piensan ambas partes.
Gracias por tomarte el tiempo.
Saludos
 
En lo personal, si no tengo tiempo o si no manejo algo no tomo trabajos, si no manejo algo que me pide un cliente lo estudio en los tiempos libres, lo de portafolio para mi es algo complicado porque siempre son modificaciones a sitios o scripts pequeños.

Enviado desde mi Nexus 5 mediante Tapatalk

Trata de tomar un proyecto grande, dice mucho más que pequeños scripts. Si no consigues un proyecto grande, siempre puedes crear tu propio proyecto y mostrarlo a los futuros clientes.
 
Trata de tomar un proyecto grande, dice mucho más que pequeños scripts. Si no consigues un proyecto grande, siempre puedes crear tu propio proyecto y mostrarlo a los futuros clientes.
Estoy esperando la respuesta de un proyecto grande, voy a empezar a subir cosas a github para que vean como programo. Saludos.
 
Para programadores que hayan trabajo con varios clientes, ¿Qué herramientas os parecen las más adecuadas tanto para comunicarse con el cliente como para hacer un tracking de los Sprints?

Aquí dejo algunas:

- Trello
- Asana
- Jira
- Slack
- Skype
 
Para programadores que hayan trabajo con varios clientes, ¿Qué herramientas os parecen las más adecuadas tanto para comunicarse con el cliente como para hacer un tracking de los Sprints?

Aquí dejo algunas:

- Trello
- Asana
- Jira
- Slack
- Skype

el skype siempre sera indispensable a la hora de comunicacion, normalmente por ejemplo trello se suele usar como mesa de trabajo - documentacion de tareas

y si quieres algo muy especializado, ahi entra el tema de repositorios y controladores de versiones como github,bitbucket (pero ya esos casos suelen ser proyectos extensos solo o con equipo de desarrollo, y con alto presupuesto ya que en esos casos se suele gastar un 25-30% en pura documentacion

PD: recien leo el tema he andado muy ocupado
saludos
Carlos
 
el skype siempre sera indispensable a la hora de comunicacion, normalmente por ejemplo trello se suele usar como mesa de trabajo - documentacion de tareas

y si quieres algo muy especializado, ahi entra el tema de repositorios y controladores de versiones como github,bitbucket (pero ya esos casos suelen ser proyectos extensos solo o con equipo de desarrollo, y con alto presupuesto ya que en esos casos se suele gastar un 25-30% en pura documentacion

PD: recien leo el tema he andado muy ocupado
saludos
Carlos

¿En qué momento consideras bueno usar control de versiones? ¿Bitbucket tiene versión privada gratuita o es igual que GitHub que hay que pagar por alojar código privado?
 
Como dices del 100% solo el 8% hace lo que realmente pides, la espectativa sobre lo que uno quiere muere.
 
¿En qué momento consideras bueno usar control de versiones? ¿Bitbucket tiene versión privada gratuita o es igual que GitHub que hay que pagar por alojar código privado?
github es un sistema de control de versiones igual que bitbucket, pero bitbucket tiene la opción de crear tu repositorio privado gratis a cambio github tienes que pagar para crear un repositorio privado.

PD: relacionado al tema no suelo usar el skype al menos que se requiera. mi chat para proyectos es hipchat :encouragement:
 
github es un sistema de control de versiones igual que bitbucket, pero bitbucket tiene la opción de crear tu repositorio privado gratis a cambio github tienes que pagar para crear un repositorio privado.

PD: relacionado al tema no suelo usar el skype al menos que se requiera. mi chat para proyectos es hipchat :encouragement:
[MENTION=35258]Think Big[/MENTION] ahi te respondieron, github y bitbucket son repositorios GIT, pero el bitbucket tiene la opcion de poner privado los repositorios gratuitamente, aunque el github es mas amigable.

como dije antes el control de versiones es dependiendo, mayormente para sistemas grandes mantenibles en el tiempo, para un sistema pequeño se podria considerar perdida de tiempo, es algo que toca conversarlo siempre en los preparativos y en la fase de planificacion

tambien es bueno trabajar con metodologias o practicas como SCRUM

https://proyectosagiles.org/que-es-scrum/ te dejo este pequeño sitio q explica que es

saludos
 
hola,

para proyectos opensource considero mejor github, pero para lo que buscas te recomiendo mejor bitbucket, ambos tienen un historial de commits "cambios" donde puedes ver los ficheros que va creando-modificando el programador, no podrás probar código ni nada, pero si ver si hay progresos.

pero te lo recomiendo para proyectos medianos-grandes para tener un seguimiento, para hacer un script es más bien un atraso para el programador.

un saludo
 
Gracias [MENTION=127525]jsstoni[/MENTION] había oído hablar de HipChat ya que son de la misma compañía que BitBucket. ¿Has probado Slack y te quedas con HipChat?

Ya trabajo en Scrum [MENTION=139393]eduardocque[/MENTION]

Respecto a desarrollos de proyectos en servidores externos, ¿qué opinión tenéis?

¿Es fácil desarrollar un proyecto web en un servidor de desarrollo y luego migrarlo al servidor de producción manteniendo todo el tema de URLs y bases de datos correctamente?
 
Gracias [MENTION=127525]jsstoni[/MENTION] había oído hablar de HipChat ya que son de la misma compañía que BitBucket. ¿Has probado Slack y te quedas con HipChat?

Ya trabajo en Scrum [MENTION=139393]eduardocque[/MENTION]

Respecto a desarrollos de proyectos en servidores externos, ¿qué opinión tenéis?

¿Es fácil desarrollar un proyecto web en un servidor de desarrollo y luego migrarlo al servidor de producción manteniendo todo el tema de URLs y bases de datos correctamente?

lo mejor siempre sera trabajar bajo el entorno local o servidores de desarrollo (un xampp wamp), ya que el control del codigo es superior, depuradores de codigo,etc

en lo particular yo no subo sistema/script al remoto hasta que no este completado en mi servidor local, porque eso es 1 perdida de tiempo

ya en la etapa de Q&A es que se monta en el servidor de produccion para hacerle las pruebas finales y lanzarlo al publico

saludos
 
Eso fácilmente se puede aplicar al diseño gráfico....
 
Atrás
Arriba