The purpose of this blog post is to find a methodological way to find technical solutions for business requirements and come to a conclusion as a team excluding human factors.
Based on my past experience, I have identified, the key human factor for any successful team is having the right INTENTION. Also there are other human factors as well.
But in reality, It’s a rare situation to have a perfect team in a project/product which works for the same goal. And that’s why in any organization having a methodological way of working is a must then the impact of human factors can be mitigated.
Having a method is like having a recipe, we can get the same results over and over again by following it. Also continuously refining it can lead to getting new foods that we never tried out before.
Therefore the first thing is we need to have a method which needs to continuously evolve and improve.
The next important thing that we need to keep in mind is that business evolves rapidly and to support that, technical solutions also need to evolve at the same speed, which leads to innovation while managing risk.
According to my understanding there are two proven techniques that we can follow. Which are
Fail Fast
Fail Safe
By applying fail fast, we can validate a solution efficiently without being stuck or stagnate.
Also failing safely will reduce the negative impact to the current business. To achieve fail safe we should be able to do an impact analysis and assess the situation before taking any decision.
Thirdly, once we come to a decision or solution, we should be able to continuously evaluate the outcomes and find further improvements if necessary.
Lastly we should identify technical principles,guidelines and best practices which align with organizational standards. For instance, there can be different departments , teams, projects or products in the same organization. They might need to follow the same tech stack or different tech stack. As a principal, we find solutions for the problem and architecture and tech stack for that solution. Hence to make sure from problem to tech stack selection propagates to the right direction not vice versa.
Also there is a famous mistake that people often make, which is to try to find a universal solution rather than case by case.
Identifying the right principals will help to find right decisions for solutions.
Let’s try to find a methodology by keeping in mind those four key factors.
Recipe to find a technical solution for a business requirement:
Start with a document and user story. Document everything related to this topic.
Both business and technical teams should have their respective documents and user stories.
Firstly we need to have a clear problem statement in the documents.
Then the business team should evaluate the business impact of having and not having a solution to this problem.
Technical teams should discuss with relevant stakeholders and take all the inputs.
Technical teams can come up with one or few possible solutions and designs to evaluate.
How to evaluate technical design.
Discuss all the concerns. Use technical diagrams as much as possible.
Validate or invalidate those concerns technically. We can find the facts and evidence for those. Finally we can do a POC to get more tangible results.
Practically we won't be able to assess all the concerns at the same time with one POC.
Most of the time we may not be able to find a perfect solution hence we should focus on the result context.
Benefits 2. Drawbacks 3. Issues
e. Do a feasible study. Again POC gives more confidence for the team. Additionally we can take the team's technical competency as a factor. Please note that in here don’t take the worst or best case as a base line.
f. Take previous lessons learnt as inputs for the solution. This can be production issues and solutions provided.
Use open channels and forums for any discussions which help to keep everyone on the same page and less surprises.
Come to a conclusion based on facts and evidence.
Please note, never come to a conclusion purely based on imaginations and assumptions.
Take help and guidance with well experienced colleagues.
Use an iterative approach to implement the solution and later further improve.
Initially apply the solution for one place/problem and continuously evaluate it before going to the next step.
No comments:
Post a Comment