Skip to content

Instantly share code, notes, and snippets.

@Najaf
Last active January 11, 2018 16:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Najaf/3f5903e5946f29a6e3124b1e554b9140 to your computer and use it in GitHub Desktop.
Save Najaf/3f5903e5946f29a6e3124b1e554b9140 to your computer and use it in GitHub Desktop.

Happy Bear Software - Consultant Role Definition

Preamble

This document outlines and details the role of consultant developer at Happy Bear Software.

This document has the following goals:

  • Provide a clear definition of what’s expected of existing consultant developers.
  • Show to potential hires what their job will entail if they decide to work with us.
  • Act as context for assessing and improving task-relevant maturity.

While this document will attempt to be exhaustive, it will never fully capture all possible activities that you can expect to perform as part of the services you provide to clients.

In it's current state however, it represents the "ideal" consultant developer from the businesses point of view: if you're able and willing to do all of these things when required then I can safely leave you to it without worry.

Note: while most of this article is focused on regular development work, much of it carries over into maintenance and support retainers on Upkeep.

Your goal

Your primary goal as consultant developer is to provide our clients with custom web development services that they are happy to pay for and would recommend to their associates.

You'll achieve this goal via three activities performed an on ongoing basis:

The rest of this article will dive into each of those activities and enumerate the specific tasks you'll be expected to perform within them.

1. Planning and requirements gathering

Your purpose here is to get a strong understanding of the client's requirements, help them define them more precisely and build a surplus of implementable work items that will bring the client closer to their goal once implemented (a "backlog"). This helps clients get the best value for money from our services and ensures that we stay productive on the project.

  • Gathering information - Doing research and meeting with the client to determine requirements.
  • Defining requirements - Capturing requirements in a format that can be used for implementation.
  • Preparing tasks for implementation - Breaking tasks down into smaller pieces and collecting any required information/materials.

Activities - Gathering information:

  • Evaluating any existing requirements documents (specifications, wireframes etc) in order to determine requirements.
  • Learning about the clients business, customers, competitors and the industry they operate within in order to get a better understanding of their problem domain.
  • Discussing the clients initial ideas about solutions that will meet their requirements.
  • Asking clients for clarification about anything they've said that you don't fully understand.
  • When a client explains a non-trivial domain-specific concept or desired outcome, repeating it back to them in order to confirm assumptions and surface any misunderstandings.
  • Identifying and raising to the client edge cases in their problem/solution and determining whether and how to handle those edge cases.
  • Suggesting options and alternative solutions to meet a clients goals more quickly or better define requirements.
  • Documenting any known future use cases that the client might have planned for later in the project.
  • Asking clients to define user personas in order to better understand how they intend their system to work.
  • Walking through related user cases with a client and questioning them on desired behaviour in order to better understand their internal model of the system they have in mind.

Activities - Defining requirements:

  • Capturing requirements in the form of tasks on a task tracker e.g. Trello.
  • Documenting enough information about each task so that another developer (or you in a few weeks time) could easily get all required context from the noted information required to implement.
  • Selective use of "Agile" user story descriptions of the format "As a [X], so that I can [Y], I want a [Z]".
  • Specifying acceptance criteria that define the desired functionality.
  • Identifying tasks that deliver very little functionality but "bootstrap" underlying data/model work.
  • Creating simple wireframes to demonstrate an intended outcome (when no wireframe/design has been provided).
  • Capturing bug reports by defining expected behaviour, observed behaviour, steps to reproduce and optionally the specific acceptance criteria that was violated.
  • Defining what a particular task does not include in order to be clear to the reader what issues have been considered.
  • Discussing acceptance criteria on task with the client to develop a shared understanding of exactly what will be delivered when the task is "complete".

Activities - Preparing tasks for implementation:

  • Decomposing tasks by selecting groups of related acceptance criteria and breaking them out into their own tasks.
  • Collecting all required supporting materials (fonts, designs, images, data, documentation, URLs, credentials etc) and making them easily available from the task.
  • Refraining from starting tasks that have unresolved dependencies that can't be resolved by the developer (e.g. design input etc)
  • Breaking a "blocked" part of a task out into its own task so that the rest of the task can be started.
  • Adding extra acceptance criteria to the task to refine or restrict the desired functionality so that desired result is more easily understood by both you and the client.
  • Marking clearly (perhaps in a trello list) which tasks are "Ready to start" and can be scheduled to begin implementation.

2. Implementing requirements

This is where you will be taking the defined requirements and turning them into working software that a client can interact with.

Implementation breaks down into three sub-sets of activity:

  • Planning the implementation - Assessing requirements and coming up with an architecture or implementation that meets them, keeping concerns about future development in mind.
  • Developing the implementation - Using your technical skills to actually build the software such that it meets the agreed requirements.
  • Delivering working software - Deploying the implementation to somewhere clients can see it, walking them through how to demo it and capturing any feedback they send you.

Activities - planning the implementation:

  • Evaluating the appropriateness of ruby gems, Javascript libraries and other open source software to put to use in implementations.
  • Considering the likelihood of meeting known future requirements.
  • Considering desired performance, in particular in light of the expected magnitude of data and the ways in which it will be queried.
  • Considering the required maintenance cost.
  • Considering how easily the planned implementation will be extended.
  • Consider what existing reusable components on the project can be used.
  • Consider what parts of the implementation would be useful as reusable components.

Activities - developing the implementation:

  • Using Ruby to write computer programs.
  • Using the object-oriented constructs in Ruby to manage the complexity of the code you write.
  • Using automated testing to help prevent introducing regression bugs in any features you build.
  • Using the libraries in Rails to build web applications that provide CRUD functionality.
  • Using Devise to provide authentication features for Rails applications.
  • Working with a background job processor like Sidekiq.
  • Building RESTful web-based API’s.
  • Applying database normalisation and entity-relationship modelling to create and iterate on a suitable relational database schema.
  • Optimising database indexes and queries that your application makes for performance.
  • Using HTML and CSS to build responsive web sites and applications, potentially from a static design.
  • Building maintainable single-page web applications in JavaScript, possibly using a framework.
  • Using git for version control, including writing useful commit messages, resolving conflicts, working with branches, remotes, merges, cherry-picks, fetches and any other features required for day-to-day integration.
  • Working with Heroku, including setting up new applications, deploying, provisioning resources, debugging, setting up environment variables, and working with pipelines.
  • Working with the Unix command line, including coreutils and any other commands required for day-to-day development work on Ruby/Rails applications.
  • Soliciting and giving constructive feedback on changesets, possibly via GitHub pull requests.

Activities - delivering the implementation:

  • Deploying any completed features to a client-facing environment.
  • Perform manual acceptance testing of the client-facing environment before inviting feedback.
  • Sending clients step-by-step instructions to demo deployed features.
  • Deploying and manually testing the features at any other environments required by the client.
  • Continuing requirements gathering and planning when a client responds with feedback.

3. Communicating about the project

Communication has a number of purposes on a client project. They include keeping the client up to date about work status, giving them a clear idea of the software delivered for the money they paid and re-assuring them that you are in fact spending the time they're paying for focused on the project at hand.

Client communication could loosely break down into three subsets of activity:

  • Reporting - Giving the client a firehose of knowledge about activity on the project, which they can dip into/out of at will.
  • Informing - Summarising the ongoing state of the project or a particular issue for the client. If Reporting is the firehose, informing is sending targeted knowledge to the people that need to know.
  • Consulting - Discussing the state of the project, including any issues and opportunities with the goal of helping to solve the clients problems.

Activities - Reporting:

  • Sending the client daily "stand-up" style status updates: what you worked on yesterday, what you're going to work on today, and details of any obstacles you've come up against.
  • Setting up and maintaining a task tracker (e.g. trello) so that it shows useful information to a client observing progress on the project.
  • Keeping a task tracker (e.g. Trello) up to date with the current status of development on any given feature.
  • Where possible, setting up automatic notifications for the client on any project activity, e.g. activity on trello, GitHub or deployment.

Activities - Informing:

  • Writing a weekly summary of the forward progress made on a project for clients.
  • Where possible, letting clients know well in advance of any paid leave or national holiday you intend to take.
  • Sending clients clear instructions on how to demo any newly deployed functionality.
  • Letting clients know as soon as possible when an implementation doesn't go according to plan (i.e. you identify problems while implementing that mean the feature will take longer to complete than expected).

Activities - Consulting:

  • Soliciting feedback from clients on how they feel about the services provided.
  • Addressing issues or concerns that clients have about their project.
  • Asking clients for information on anything that will effect the success of the project (business domain changes, demos, traffic, or anything else that conceivably effect the project).
  • Flagging any issues that you don't have the authority to deal with on your own to someone who does (probably Ali).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment