Ninguno de los dos enfoques parece funcionar bien. Como desarrollador, no quiero pagar por tu tiempo para hacer algo que tú no puedes hacer. Los programadores me han engañado. Afirman que tienen experiencia en determinadas áreas, pero encuentro que realmente no es así. Un ejemplo sería un programador de vb que me dijera que conoce SQL y bases de datos. Es posible que puedan hacer que las aplicaciones se conecten, pero cuando un programador más competente en esta área revisa el código, resulta que están moviendo los datos de manera ineficiente y haciendo que el software se ralentice.
También tengo algunas dificultades con el enfoque que quiero adoptar. Muy a menudo los programadores quieren codificar lo que pueden hacer. En el caso de la ebanistería y la carpintería, este enfoque se utiliza en todas partes y es fácil de realizar y controlar. Me encuentro teniendo que decir lo que quiero una y otra vez y teniendo que rechazar lo que sugieren. Esta no es una buena sensación y suele ser una gran pérdida de tiempo. De vez en cuando encontraré un programador que haga lo que quiero. Generalmente ni siquiera entienden qué es lo que intento hacer. Cuando terminan y ven que todo funciona en conjunto, finalmente lo entienden. Para que situaciones como esta funcionen, debo explicar claramente y exactamente lo que quiero que suceda y lo que no debe suceder. Puede ser realmente difícil de hacer y cuando tratas con personas que no programan, como yo, tendrás problemas de comunicación y malentendidos. Los propietarios de negocios típicos no podrán explicar claramente lo que quieren. Tampoco van a entender que la codificación nunca se termina.
¿Quién realiza las pruebas y la depuración? Si el codificador lo hace, entonces no es un gasto fácilmente comprobable. Si la empresa lo hace, es posible que no sean tan minuciosos o que no comuniquen y documenten los problemas correctamente. Generalmente no es una buena idea que el programador de codificación sea también el gerente de desarrollo de un proyecto debido a conflictos de intereses y la falta de un punto de vista independiente. También es un problema que lo haga alguien que no tiene experiencia en ello, como el propietario de un negocio o un redactor. No lo documentan correctamente y muchas veces solicitan o dicen cosas que no significan nada en términos de programación.
Es, como mínimo, difícil contratar programadores honestos y trabajadores que puedan seguir instrucciones. Es aún más difícil encontrar los anteriores que no impulsarán un determinado enfoque porque se adapta a su codificación y experiencia. Esto es típico de toda codificación. Se debe codificar lo que es mejor para el negocio. No es una aplicación funcional que sea muy inferior a una aplicación funcional diferente que sea específica para las necesidades de las tiendas. Cada tienda es diferente y hay muchas variables a considerar.
Al crear una aplicación personalizada, se te ocurren ideas que crees que funcionarán, pero el uso práctico de la aplicación puede tener resultados diferentes. Esto se aplica a la eficiencia, la necesidad imprevista de codificación adicional y, a menudo, surgen mejores ideas al ver una aplicación que funciona y la necesidad de descartar todo y empezar de nuevo.
Las aplicaciones listas para usar, incluso si no son perfectas, a menudo son lo mejor para una empresa, ya que los costos de la programación personalizada pueden fácilmente superar los $100,000 y los ahorros que generan, si los hay, no justifican la inversión. Esto es muy difícil de ver para los dueños de negocios con anticipación y requieren un cuidadoso análisis de costos e investigación de antemano. Muchos son absorbidos cada vez más profundamente y los costos se vuelven asombrosos. Piensan que es responsabilidad del programador explicar claramente lo que van a obtener, pero la aplicación funcional real no cumple con sus expectativas. Esto deja un sabor amargo en la boca de los empresarios.
Los dueños de negocios también deben dedicar suficiente tiempo propio para terminar un proyecto. A menudo no tienen en cuenta estos costes. Pueden ser bastante grandes.
Por otro lado, los programadores tienen que preocuparse de que les paguen y de que no se aprovechen de ellos. Con demasiada frecuencia, la situación puede empeorar debido a que una persona sin experiencia o poco ética gestiona el proyecto. Ponen al programador en una situación incómoda en la que debe codificar más de forma gratuita para complacer al director del proyecto.
Para hacer esto correctamente, se deben realizar acuerdos de confidencialidad, honorarios legales, investigación y considerables inversiones de tiempo y dinero incluso antes de comenzar la codificación. El propietario del negocio, a excepción de los honorarios de sus propios abogados, deberá incurrir en estos costos. Cualquier propietario de negocio que no esté dispuesto a proporcionar un plan detallado por escrito legal probablemente sea un desastre a punto de ocurrir.
Lo más importante es ¿a quién pertenece el código? ¿Tiene el programador derecho a utilizar la misma codificación para otros proyectos? Muchos reclamarán la propiedad de todo el código que escriban si el propietario de la empresa no supo de antemano cómo detallarlo claramente en el contrato. Sería un conflicto de intereses para el programador declarar cualquier cosa que no sea:
Busque un abogado calificado en esta área para redactar un contrato y aconsejarle cómo proceder, antes de comenzar. Es posible que el abogado no esté familiarizado con el proceso de desarrollo, por lo que no hay sustituto para la experiencia en el área de gestión del desarrollo. Las primeras veces, puede esperar clientes insatisfechos hasta que sepan cuáles son realmente sus responsabilidades.
