Introducir mis ideas en el software de mi empresa: ¿escribir especificaciones o hacerlo yo mismo?

Soy biólogo y matemático de formación, mi trabajo es encontrar soluciones algorítmicas y conceptuales (a veces UX) para problemas en un entorno de laboratorio (típicamente cosas de optimización, a veces análisis de datos) para ayudar a que nuestro proyecto sea exitoso. He estado en la empresa durante aproximadamente 2 años, me gusta mi trabajo porque puedo hacer muchas cosas diferentes.

El conjunto de problemas:

a) Dado que soy el que tiene más experiencia en el negocio de los clientes, esto no es lo único que hago, también hago mucho trabajo de gestión de proyectos (ingeniería de requisitos, redacción de otras especificaciones, comunicación con el cliente, ... ) ==> Rara vez puedo dedicar más de un par de horas a una cosa.

b) Sé R, Matlab y muy poco C (2 carreras universitarias). Mi empresa trabaja con C#. Por lo tanto, no puedo probar fácilmente el código ni escribirlo yo mismo; tiene que pasar por un desarrollador. ==> Esto provoca malentendidos que cuestan tiempo.

c) No es una opción ir solo a la gestión de proyectos ni ser 100% desarrollador porque mis otras habilidades y conocimientos son muy útiles en otros lugares. Además, actualmente soy el único matemático "real" en la empresa.

Situación actual: Resuelvo el problema y escribo un prototipo en R. Alguien más hace la implementación en C#.

  • Bueno: puedo encontrar una solución comprobable rápidamente.

  • Malo: a los desarrolladores no les gusta documentar o trabajar con especificaciones demasiado detalladas y tienen dificultades para juzgar si funciona como se esperaba, no puedo entender el código, el código se escribe de una manera que dificulta la adaptación a nuevos problemas. ==> mucho tiempo perdido e infeliz yo y dev.

¿Cómo puedo mejorar la situación para todos? Mis ideas:

  • encontrar una manera de convencer a los desarrolladores de que tener un código bien documentado y probar el acceso para mí no es porque quiera controlar cada pequeño paso, sino que es una forma de trabajar juntos.

  • aprender C# para poder escribir partes específicas del software yo mismo (supongo que lleva mucho tiempo)

  • aprender C# lo suficientemente bien para poder entender el código y detectar malentendidos temprano (puede que no sea eficiente)

  • aprenda algo como Python que está más cerca de lo que sé (más rápido), conéctelo al resto del software e impleméntelo junto con las partes de C#. Si es crítico para el rendimiento (muy raro), entregue esas partes al desarrollador real.

  • oren para que pronto estemos vendiendo soluciones en la nube y sigan haciendo todo en R

  • [tu idea aquí]

Mi pregunta para ti: ¿qué crees que es mejor para paliar la situación? Tengo muchas ganas de quedarme en la empresa y quiero que tengamos éxito. Puedo contar con algo de apoyo del jefe.

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .

Respuestas (2)

Le sugiero que trabaje con el administrador de desarrolladores para alinear sus necesidades con las habilidades que los desarrolladores tienen actualmente.

Lo más probable es que los desarrolladores no quieran pasar de C# a R, Python o BDD y, francamente, no es necesario. Los desarrolladores que están familiarizados y son competentes con una pila en particular normalmente no querrán cambiar a otra.

Creo que sus necesidades pueden ser satisfechas por la gente que tiene, pero tendrá que establecer una relación con los desarrolladores y su administrador para lograrlo.

En resumen, no creo que esto sea realmente un problema técnico, sino más bien una falta de trabajo en equipo o comunicación.

voto negativo no tienes idea de lo que los desarrolladores quieren hacer en absoluto. las relaciones necesitan una estructura: las cosas deben funcionar en un proceso, no se puede simplemente decir "tener una relación", tiene que haber una estructura de comunicación.
@bharal: es difícil estructurar la comunicación cuando no tienes nada o muy poco. Preferiría que alguien se me acercara inicialmente con una oferta para una conversación abierta.

Este es un momento perfecto, honestamente, simplemente perfecto, para usar BDD.

Sabes lo que quieres que haga el código. Puede escribir código: use Cucumber. Ahora mismo este es el enlace

Échele un vistazo: efectivamente, le permite definir los pasos para una prueba exitosa, y luego el desarrollador va y escribe el código que se conecta a esta definición.

Entonces puede estar seguro de que cualquier cosa que los desarrolladores hayan ideado funciona. También es exactamente lo que Cucumber pretende hacer (solo que nunca lo hace, porque la gente de negocios no escribe código ni usa cosas con una interfaz de usuario fea, ¿y quién puede culparlos?)

No sé si existe un puerto de pepino para "R", sería bueno que pudieras tener el archivo de especificaciones de pepino y luego hacer que ambas bases de código se prueben en su contra, pero estoy seguro de que podrías hacer que tus muchachos simplemente "llamen " su código R de C# y utilícelo como entrada para el código de Cucumber.

seguro que parece interesante, sin duda sugeriré que como una opción... a los desarrolladores les podría gustar :)
Lo que me gusta de Cucumber es que incluso si el equipo no usa un enfoque BDD, las especificaciones que crea son de gran ayuda para desarrollar un sistema que el cliente necesita y que realmente funciona de la manera que el cliente espera. La desventaja es que los clientes son malos para pensar en casos extremos y excepciones... Por lo tanto, el código cuc también puede hacer perder el tiempo. Estoy de acuerdo en que esto es algo sobre lo que el OP debería hablar con el equipo de desarrollo y tal vez intentar trabajar juntos para encontrar una solución.
sí, pero pensar en casos extremos es parte de mi trabajo. Supongo que tendremos que sentarnos juntos y hablar sobre "qué puedo hacer para apoyar su desarrollo de manera más efectiva". Todavía soy relativamente nuevo y tal vez (como sugirió uno de los comentarios anteriores) mis especificaciones son demasiado "matemáticas", pero nadie quiere hablar ...
@BootstrapBill: probablemente podría ser bueno en BDD y esas especificaciones deberían ayudar al equipo de desarrollo a crear las herramientas que está solicitando.