Fix POSDCORB for a good software application design
POSDCORB stands for Planning Organising, Staffing, Directing, Coordinating, Reporting and Budgeting. These are considered as the following while a typical MVP is designed or delivered.
There are severe pain points for causing bad designs:
Pre-Sale Leaks
1- Consideration of the Pre-Sales estimations and architecture design is finalised or prepared for these segments where the team doesn’t have in-depth context application or customer needs or they are usually last-time creators or reviewers.
Reason: Organisation doesn’t have to believe in that it will win this project so feed it n let it see. Or it may depend on client/partner relations or any one of these having fewer interests.
Discovery phase leaks
2- In case 1st point comes like the client accepted your quotes or allows you to proceed and implement the proposed solution then the discovery phase started but the team is not yet boarded or resources are under pressure to fit what is committed at 1st point.
Agile Leaks (Driven agile by waterfall experts)
3- Sprint-0 started not to have enough resources in place but managers have to start and show their commitment to being done defined SLA or before.
Design Leaks (UI/UX resources started either one of them not hired or vice versa)
4- UI resource hired but UX is not yet ready or multiple revisions of UX design as half-cooked design were confirmed at level 1.
4.1 Architect still unknown of integration applications, API security, performance testing, test automation, and cloud services, or a few other necessary points these are very important. These usually cause frequent data model changes, data composition techniques, think about failover strategies etc.
Now, Development leaks
5- Less knowledge of test automation, cloud infrastructure or considering backend or frontend developers and running behind to test local E2E setup of the application or putting less interest to do this setup due to the complexity of configuration. (Remember things are always complex until you either practice or are unaware or not interested)
- Limited developers, limited visibilities of the scope of the application, and lack of owning the feature or module by a team.
- Lacks of collaborative work culture, blame culture, delivery pressure or developers doing what they don’t like it.
- Sometimes developers feel that there is no scope for new learnings but they don’t apply the learnings that they have learned across their experience they just follow the same what they have done in previous projects.
- Tech-Debts, Tech-Debts, Tech-Debts etc Tech-Debts.
- Poor code reviews and approve it being considered as tech-debts.
DevOps Leaks
6- Development environments are not ready because of the 0cost involved or bad cloud service selections or new to the cloud infrastructure and services.
6.1 Manual configurations of DevOps pipeline and many other configurations hence spending time to create or replicate other environments
6.2 Due to lack of budget and limited resource creation, repetitive security certificate installation and also manual way and many more.
Operations Leak
7. Relying on testers or quality analysts to test features which could have been done by programmers by following the Test Pyramid sincerely and thoroughly in each layer of the application.
7.1 Product Owner or business analyst tests the feature at the very last stage and the developer usually does not follow pre-development of acceptance criteria. There are plenty of chances where PO/BA may have missed some details or over-covered the details about features or attachments of old UX/UI design on the user stories.
7.2 Poor sprint plannings, backlog refinements, either no retrospect or retrospect without any further actions columns or if the column is there but no one follows up on previous retrospect meeting’s actions in ongoing retrospect meeting.
Many Thanks
Follow me on Linkedin | GitHub | YouTube | StackOverflow
