Lessons over Chinese BBQ
Met with a long-time friend and mentor last night for delicious Chinese BBQ and lessons. Part of the conversation moved to idea/app development, and clarifying the stages and clear scopes.
Scope: Validating an idea, or a concept i.e. "something that's never been done before"
Ends when the idea/concept is validated or disqualified
Mitigates risk/cost at the expense of time (estimating this is naturally hard because it's a new thing)
Is thrown away entirely (aside from lessons learned) at the end.
Should be coded as such! (i.e. hard code connection strings, because things like setting up config files is waste for this stage)
MVP
Scope: Laying the framework for your production thing.
Minimum feature set because the goal here is 'establish the product, build the foundation'.
Once the groundwork is laid, architecture set up, additional features can be added.
Should be coded as 'this will end up being production, so do it right'.
Production thing
Scope: Addition of features, expansion of the product on top of the original framework.
Long term maintainability.
Lessons
If the team/leadership is not in agreement on scope and expected outcomes, you will have problems.
If anyone wants to change scope, explain to them the risk/cost, and get senior LT to sign off on the scope change (accepting responsibility).
If LT is signing off on this kind of thing (when they really shouldn't), then it's a good sign things are not healthy.
If the POC stage is skipped, you are essentially gambling.
==> Business is all about cost, risk, and responsibility.
If I make this exception, what is the risk, who is responsible? If you want this, will you sign off on it knowing the risk?
e.g. If someone decides they want to keep Proof of Concept code and turn it into production - do they understand the risk? Bad code from yesterday can cause even highly skilled professionals to move many times slower than necessary. It's faster to start from scratch and build it right! (if you don't have the time to do it right, when are you going to find the time to do it again?)
Will this project enable to grow (or directly grow) the bottom line? If not, why are we doing it?
e.g.
Incorrect seller: I am selling you technology that does XYZ and is amazing!
Correct seller: I am selling you this service that takes risk and responsibility off your plate!
Buyer: I am buying peace of mind and less hassles.
As in, are you focused on what the customer really wants?
In an environment where IT is considered a cost centre, ROI is huge. If your project doesn't demonstrate clear ROI, it's a waste of time doing it. (i.e. "productivity" improvements are hard to quantify, but direct cost savings is hard to argue with) This is a distasteful place to be - IT should be a valuable partner in helping drive the business forward, not considered a janitorial service.
What is the roadmap out of that place? Get out of a firefighting stance first! How will you build trust and gain the ability to take risks again? What metrics are important?
Are you really the right person for this job? We can't do everything by ourselves. Do you understand your skillset and place? (if you don't understand yourself, how can you correctly judge others?)
Stages of product development
Proof of conceptScope: Validating an idea, or a concept i.e. "something that's never been done before"
Ends when the idea/concept is validated or disqualified
Mitigates risk/cost at the expense of time (estimating this is naturally hard because it's a new thing)
Is thrown away entirely (aside from lessons learned) at the end.
Should be coded as such! (i.e. hard code connection strings, because things like setting up config files is waste for this stage)
MVP
Scope: Laying the framework for your production thing.
Minimum feature set because the goal here is 'establish the product, build the foundation'.
Once the groundwork is laid, architecture set up, additional features can be added.
Should be coded as 'this will end up being production, so do it right'.
Production thing
Scope: Addition of features, expansion of the product on top of the original framework.
Long term maintainability.
Lessons
If the team/leadership is not in agreement on scope and expected outcomes, you will have problems.
If anyone wants to change scope, explain to them the risk/cost, and get senior LT to sign off on the scope change (accepting responsibility).
If LT is signing off on this kind of thing (when they really shouldn't), then it's a good sign things are not healthy.
If the POC stage is skipped, you are essentially gambling.
Office politics
Another topic was office politics and 'the right person for the job'.==> Business is all about cost, risk, and responsibility.
If I make this exception, what is the risk, who is responsible? If you want this, will you sign off on it knowing the risk?
e.g. If someone decides they want to keep Proof of Concept code and turn it into production - do they understand the risk? Bad code from yesterday can cause even highly skilled professionals to move many times slower than necessary. It's faster to start from scratch and build it right! (if you don't have the time to do it right, when are you going to find the time to do it again?)
Will this project enable to grow (or directly grow) the bottom line? If not, why are we doing it?
Startups
Have you defined your idea? What are you actually selling? (cost, risk, responsibility!)e.g.
Incorrect seller: I am selling you technology that does XYZ and is amazing!
Correct seller: I am selling you this service that takes risk and responsibility off your plate!
Buyer: I am buying peace of mind and less hassles.
As in, are you focused on what the customer really wants?
ROI
Can you prove the ROI? Projects that give convenience or productivity improvements don't tend to equal financial success (even if they are delightful).In an environment where IT is considered a cost centre, ROI is huge. If your project doesn't demonstrate clear ROI, it's a waste of time doing it. (i.e. "productivity" improvements are hard to quantify, but direct cost savings is hard to argue with) This is a distasteful place to be - IT should be a valuable partner in helping drive the business forward, not considered a janitorial service.
What is the roadmap out of that place? Get out of a firefighting stance first! How will you build trust and gain the ability to take risks again? What metrics are important?
Are you really the right person for this job? We can't do everything by ourselves. Do you understand your skillset and place? (if you don't understand yourself, how can you correctly judge others?)
Comments
Post a Comment