En tant que programmeur, comment puis-je accélérer mon adoption et ma compréhension des règles métier?

Je suis développeur depuis un moment. Je suis loin d'être le meilleur. (Alors que je m'assois seul dans cette pièce, je me demande si je ne suis même pas le meilleur ici.) Cependant, j'ai fini par comprendre mes outils et j'ai confiance en ma capacité de raisonner et d'apprendre.

Lorsque je commence un nouveau travail, je crois toujours que je peux apprendre la base de code si c'est une langue que je connais. Si ce n'est pas un langage ou un framework que je connais, je crois que je peux saisir suffisamment les concepts pour l'apprendre (et juste lire la documentation). Cela fait partie de nos compétences en tant que programmeurs et je suis fier de pouvoir respecter cette norme.

Pour tout cela, cependant - l'une de mes principales faiblesses est d'apprendre et d'intérioriser les règles commerciales pour le client pour lequel je travaille rapidement - que je sois un employé rémunéré ou un entrepreneur. Je suis d'accord avec les bases de code, mais les règles et processus métier pour une entreprise spécifique semblent toujours prendre un certain temps pour bien comprendre. (Par exemple, cela peut être un tripup lors de la réécriture d'applications d'entreprise.)

En tant que développeur, quelle est la meilleure façon d'assimiler rapidement et efficacement les règles et processus métier? Est-ce possible sans être un expert en la matière ou simplement avoir des années d'expérience avec le client, l'entreprise ou l'entreprise?

Pour moi, c'est en lisant et en comprenant les bases de code.

Je dis cela pour deux raisons principales:

1. Les gens craignent. Oh, pas délibérément (habituellement), mais dans les affaires, j'ai constaté que les gens ont souvent une compréhension subtilement différente des règles commerciales. Et chacun a son propre modèle mental qui, à son tour, perd en fidélité lorsqu'il essaie de vous le communiquer. Mais le code ne ment pas. Les gens peuvent penser ce qu'ils veulent sur la façon dont les choses sont censées fonctionner, mais le code est juste.

2. Construisez d'abord une fondation. Donc, si chacun a son propre modèle mental de ce que sont ces termes et processus spécifiques à l'entreprise, comment construisez-vous le vôtre? Pour moi, et j'attends de nombreux programmeurs, je construis mes modèles mentaux au mieux à partir du code. Le code a des modèles. Le code a des abstractions. J'ai beaucoup d'expérience en prenant du code et en construisant un modèle mental à partir de celui-ci. Une fois que j'ai au moins une forme vague de ce que les choses existent et comment ils se rapportent, alors je peux parler aux gens d'affaires. Ensuite, je peux poser les bonnes questions et mieux adapter leurs réponses au puzzle.

Ne soyez pas trop dur avec vous-même. Parfois, je me demande pourquoi ils prennent même la peine de les appeler des "règles" commerciales, mais je suppose que les appeler "des façons dont nous faisons généralement les choses à moins qu'il y ait d'autres choses qui s'appliquent alors nous les faisons différemment" les insulterait probablement. Les affaires sont en désordre. Ils jonglent avec les besoins des clients, des agences juridiques, de la comptabilité, de la réglementation, des fournisseurs, des employés, des gestionnaires et des autorités locales. Ils n'ont pas toujours de raison.

Je pense que la meilleure façon est de s'assurer que vous passez du temps avec autant de gens d'affaires que possible. Cela peut être difficile pour certaines personnes occupant des postes techniques.

1. Budget votre temps et respectez le leur, mais obtenez autant que vous le pouvez.
2. Vous devrez poser des questions. Ils ne pensent pas comme les programmeurs et décomposent tout et ont une compréhension complète de la façon dont les informations sont liées les unes aux autres.
3. Ne simulez pas comme vous le comprenez. Si vous en saviez autant que les autres gens d'affaires, ils vous feraient faire les deux emplois. Voir # 2.
4. Ne vous attendez pas à de la documentation. Offrez beaucoup d'éloges si vous en obtenez.
5. Retenez les critiques. Les processus et procédures peuvent avoir des redondances et d'autres efficacités potentielles auberge, mais il peut y avoir une raison à cela. Apprenez pourquoi, mais ne soyez pas choqué quand ils disent: "Nous l'avons toujours fait de cette façon."
6. Soyez courtois, gentil et partagez vos collations. Vous traitez avec des gens. Dis bonjour. Demandez comment ils vont. Demandez pourquoi ils sont entrés dans l'industrie, depuis combien de temps ils travaillent pour l'entreprise.

Vous n'êtes pas un vide appelé le programmeur, vous êtes une personne. Faites-leur savoir que vous êtes là pour faciliter leur travail. Malheureusement, vous pouvez être le héros ou la chèvre. C'est la nature de notre entreprise.

Je recommanderais de lire un livre intitulé The 5 Elements of Effective Thinking d'Edward Burger et Michael P. Starbird. C'est lié à la compréhension de nouveaux concepts en général, mais je pense que cela s'applique à cette situation.

Voici quelques points intéressants du livre:

Maîtrisez les bases

Si vous ne connaissez pas les bases, vous construirez votre compréhension sur une base fragile. Vous devez donc poser ces questions stupides que personne d'autre ne pose.

Laissez les erreurs vous guider

Parfois, il est utile de poser des questions manifestement erronées afin de découvrir votre manque de compréhension. (Ex: vous voulez dire que les administrateurs ont accès à tous les documents? Oh. Pourquoi?)

Enseigner ou expliquer aux autres

Lorsque vous essayez de l'enseigner à quelqu'un d'autre, vous commencez à découvrir où vous avez du mal à comprendre.

J'espère que ça t'as aidé!

En tant que développeur, j'ai réalisé que je traduis directement l'entreprise en code, structures de données, classes possibles, etc ... Je passe de quelque chose d'abstrait et souvent, non défini à quelque chose de spécifique, quelque chose de "forme". Je commence à coder immédiatement et, le manque d'information , me conduit à de fréquents refactors. Chaque refactor me fait penser qu'il y a trop de lacunes dans ma compréhension de l'entreprise .

Comment ai-je commencé à résoudre ce problème?

Je m'oblige à lire tous les documents réalisés lors de l'analyse fonctionnelle et des phases précédentes. J'essaie de le faire en tant que client ou utilisateur final . J'ai besoin de comprendre ce que le client recherche avec de telles applications et exigences. Mais je dois rester loin du développeur que je suis.

Notre travail nous fournit une grande compétence que les clients n'ont pas. Nous pensons dans des structures conditionnelles d'une manière que les autres ne pensent pas. Je commence donc à faire face à des exigences. Recherche de contradictions ou d'incohérences . Un petit peu de cerveau qui tourne autour de ce que j'ai compris. Formuler des scénarios hypothétiques.

Cela m'a conduit à des questions et des doutes. Je tape tout le monde et finalement je fixe un rendez-vous avec qui peut résoudre mes doutes.

En résumé, je change de point de vue. J'essaie de regarder le problème sous un autre angle. Mais j'ai mis les compétences de certains développeurs sur le processus. Ce qui se termine par un bon tas de questions et de doutes à résoudre. Une fois résolu, ma compréhension de l'entreprise est plus profonde.

Étude> Doutes> Questions> Réponses> Compréhension (répétez le cycle encore et encore)