Job Tracker - Project Retrospective

Project Retrospective

1. Project Summary

Goal: To develop and deploy a functional Minimum Viable Product (MVP) of a job tracking application, while adhering to professional project management processes.

Outcome: Success. The team successfully deployed a live, working application that meets all the "In-Scope" criteria defined in the Project Charter. All backend and frontend features, including CRUD functionality and drag-and-drop, were implemented.

2. What Went Well

• Structured Planning: The project began with a detailed Project Charter, which served as our guide to make informed decisions. This document was iterated upon to clarify scope, define a realistic timeline, and manage stakeholder expectations effectively.
• Thorough Backlog Management: All work was broken down into granular tasks and managed on a GitHub Kanban board. Each task had a clear user story and acceptance criteria, which eliminated ambiguity.
• Effective Problem Solving: The team successfully navigated several critical bugs, including Firebase authentication errors and UI race conditions. Each issue was documented, debugged, and resolved systematically.
• Adaptability: The project plan was successfully adapted to accommodate scope changes (adding a delete button) and new insights (the need for production security rules), with new tasks being formally added to the backlog.
• Successful Delivery: The team delivered a fully functional and deployed MVP as planned.

3. Challenges & Opportunities for Improvement

• Initial Environment Setup: The project was initially blocked by several Firebase configuration issues. This highlighted the importance of a "Task Zero" for thoroughly validating all third-party service settings before beginning feature development.
• Architectural Trade-offs: To meet the aggressive timeline, a decision was made to build the application within a single index.html file. While this accelerated initial development, it is not a scalable or maintainable architecture. In a real-world scenario, the code should be refactored into separate modules (e.g., api.js, ui.js).
• Manual Testing: All testing was performed manually by running the application in the browser. This is not sustainable. A future iteration should include an automated testing framework to ensure code quality and prevent regressions.
• Security as an Afterthought: The need for strict Firestore Security Rules was identified after initial development began. While the issue was caught and resolved (JT-13), security planning should be an integral part of the initial design phase, not a reactive fix.
• Accessibility Not Prioritized: The MVP was built with a focus on core functionality and did not include specific accessibility (a11y) features. Building it highlighted the importance of inclusive design. If we begin developement of V2, a top priority would be to include accessibility features, ensuring the tracker is usable for everyone, regardless of ability.

4. Key Learnings

1. Process is as Important as Product: By following a structured process (Charter -> Backlog -> Sprints -> Retrospective), we were able to manage complexity, adapt to change, and deliver a successful product. The Charter and Backlog served as an excellent knowledge base that kept the development experience smooth.
2. Optimistic UI Updates: The initial UI felt slow because it waited for database confirmation. Refactoring to an "optimistic update" model, where the UI updates instantly and handles the database operation in the background, drastically improved the user experience.
3. The Value of a "Doorman": The Missing or insufficient permissions error served as an important lesson in backend security. A public-facing API key is useless to an attacker if robust, server-side security rules are in place.

5. Action Items & Next Steps

• Complete Final Documentation: Create the portfolio case study/blog post that tells the story of this project, linking to the live app and the key artifacts in the GitHub repository.
• Archive Project Artifacts: Ensure the GitHub repository is clean, well-documented, and all issues on the Kanban board are closed.
• Formally Conclude MVP Phase: The MVP has met all its objectives as defined in the Project Charter. A strategic decision has been made to not proceed with Phase 2 (Future Roadmap) at this time, and to consider the project complete.