We’re working on continuously improving our process of project management and development. The below outlines the high level overview of the processes we use to develop and build web applications and custom business software.

The Core Fundamentals:

  1. Find out exactly what the [user, client, or person who is benefiting the most from this system] needs and wants.
  2. Get the data you need to make that happen. Analyze at least ten types of forms. Refuse to accept any data without validating it first, always assume there is undiscovered data.
  3. Build the simplest and quickest version of that. Always focus on getting the simplest version to a solution in production as soon as possible.
  4. Test with user, fix mistakes, create better functionality. Ensure that no human error is found again (through automated tests and scripts).
  5. Do not allow arbitrary deadlines hurt long term productivity (focus on the tasks that will take a few extra days and save a few months). Set deadlines for each project on either weekly, every two weeks, or monthly deadlines. In emergencies, set daily deadlines. Agree upon this before the project begins.
  6. Ensure all changes are pushed to a staging environment, rigorously tested, and then pushed live after that.
  7. Ensure all people involved in the project have the tools and resources they need to see the project vision. The lowest developer or the highest project manager should be able to rollback changes if needed, or push new changes live easily.
  8. All project details are carefully, but not wastefully, documented.
  9. Nothing matters in the project other than working software, easy functionality, and results.

Programmers and developers are not the best at managing clients. Since we’re very literal people, we love systems that have precisely defined behaviors.

This makes working with non-technical people harder for us than it needs to be because we tend to take every request literally, rather than spending the time trying to figure out what a client actually wants.

The goals of our process system:

  1. To minimize bottlenecks, and spend as much time on the Code, Test, Deploy cycle as possible
  2. To create a system where even the entry level developers have the resources to make decisions and determine what the client actually wants, providing customers better systems and faster implementation cycles
  3. To measure all projects on weekly cycles to ensure that we are not losing focus on the big picture, but ensuring small tasks are taken care of efficiently

High-Level Planning Notes:

  1. To plan the project, we need access to all the data or a live test case. Not a promise of the data, not a vague understanding, but the exact items that we will be putting into production.
    1. This needs to be detailed enough to create an exact scope.
    2. We should have at least several different use cases/data examples to account for one-offs
    3. We always want to question the validity of the data and ensure we’re probing to iron out any outliers and cases that will break the system
  2. All development systems and task reporting needs to empower the developer, not add unnecessary work to the developer
    1. This means we need to streamline the process of a developer seeking higher level help, clarification, etc., without a lot of unnecessary reporting and systems
    2. Our motto: outsource anything we cannot do directly, automate anything we can automate, and eliminate anything that’s not crucial to the project
  3. All project tasks are updated in real-time in the task tracking (currently, Asana)
  4. Active documentation needs to be included in all parts of the process; all documentation needs to be up-to-date with no exceptions.
    1. Two “testing” documents are prepared and utilized for each client
      1. A document to use to guide testing
      2. A seperate document to use to track testing changes

Plan Asana Tasks for Web Development

As a rule of thumb, all tasks and documentation need to have necessary details. Usually an image/screenshot of the task, and text to explain the issue.

We organize each  project into with the main boards of:

  • Wishlist (a place where we can store dreams/wanted tasks that aren’t in production)
  • Bugs (bugs that are on the live site and would require pertinent attention)
  • In Progress (tasks that are currently being worked on)
  • Ready for Staging (ready to be pushed to staging)
  • Failed on Staging (bugs that did not pass testing on staging)
  • Ready to Push live (Items that are ready to push live)
  • Completed (any tasks that have been been completed)

Note: a single client of ours can have more than one active project.

Software Testing Methods

  1. Acceptance Testing – This is ensuring that the application fits the client’s needs, and we work with the client to create these tests. This is testing the key performance indicators of the application.
  2. Unit/Component/Deployment Tests – These are standard software development/unit tests.
  3. Live User Testing – using active customers (NOT the client) to provide feedback and find issues and other “breaks” that would have never been thought of or planned.
  4. Application and Performance Testing – This includes learning the capacity of the application by testing the load times, application security, and so on.

Finally, we determine how we can automate as many of those tests as possible, to save time.