When you have a team working on a payment processor, or an app focused on wealth management, it's true that the development team may or may not have experience in these areas, and it's not easy to establish everything from the beginning based solely on experience.
However, I agree with Allen that we can discover from the start and establish some guidelines or principles according to the area.
I can think of something to start with like:
------
Key Development Guidelines
1. Security-First
- Encrypt all sensitive data at rest and in transit.
- Support various payment actors (IRS, Mastercard, VISA, AMEX).
- Handle batch, near-real-time, and real-time processing reliably.
3. Data Management
- Ensure all entities (Merchant, Card, Transaction, etc.) are trackable.
- Build a data model for efficient reporting and compliance with regulations.
4. Scalability & Performance
- Design for high transaction volumes with scalable architecture.
- Combine monolithic core with microservices for flexibility.
5. Agile & Continuous Delivery
- Adopt Agile practices, with CI/CD pipelines for fast, secure releases.
6. Collaboration
- Ensure strong cross-functional teamwork with shared documentation and clear communication.
7. Compliance & Monitoring
- Enable audit-ready logging, meet regulatory standards, and set up robust monitoring from day one.
------
I've never done it, but I'd like to do something like this. It's a mini team Manifesto for that specific product. It can change, reflects some assumptions, allows us to start talking about important issues from the beginning.
I know requirement is the no-no word ;) But, I think this sometimes ignores certain company or geographic cultural aspects. I sometimes work with teams that, if things would not be formalized, almost nothing productive would happen. It even goes so far that it almost feels like a complete reset from one day to the next, making it seem as though yesterday's discussions never happened. Do you have any angle on this on how not using requirements would be better?
When you have a team working on a payment processor, or an app focused on wealth management, it's true that the development team may or may not have experience in these areas, and it's not easy to establish everything from the beginning based solely on experience.
However, I agree with Allen that we can discover from the start and establish some guidelines or principles according to the area.
I can think of something to start with like:
------
Key Development Guidelines
1. Security-First
- Encrypt all sensitive data at rest and in transit.
- Implement PCI DSS compliance, strong authentication, and regular security audits.
2. Payment Ecosystem
- Support various payment actors (IRS, Mastercard, VISA, AMEX).
- Handle batch, near-real-time, and real-time processing reliably.
3. Data Management
- Ensure all entities (Merchant, Card, Transaction, etc.) are trackable.
- Build a data model for efficient reporting and compliance with regulations.
4. Scalability & Performance
- Design for high transaction volumes with scalable architecture.
- Combine monolithic core with microservices for flexibility.
5. Agile & Continuous Delivery
- Adopt Agile practices, with CI/CD pipelines for fast, secure releases.
6. Collaboration
- Ensure strong cross-functional teamwork with shared documentation and clear communication.
7. Compliance & Monitoring
- Enable audit-ready logging, meet regulatory standards, and set up robust monitoring from day one.
------
I've never done it, but I'd like to do something like this. It's a mini team Manifesto for that specific product. It can change, reflects some assumptions, allows us to start talking about important issues from the beginning.
I know requirement is the no-no word ;) But, I think this sometimes ignores certain company or geographic cultural aspects. I sometimes work with teams that, if things would not be formalized, almost nothing productive would happen. It even goes so far that it almost feels like a complete reset from one day to the next, making it seem as though yesterday's discussions never happened. Do you have any angle on this on how not using requirements would be better?