

Ask HN: How to bring order to a chaotic web dev process? - tst2010

Hi All,<p>I'd be grateful for any advice you might have on the following.<p>Our company is currently searching for Project Management software. Our office setup is a web design team based off site in central Europe, and a management &#38; marketing team based in the UK. Currently all changes to our web sites are requested by the management &#38; marketing team via a web request system. These requests are then passed on to the relevant developer by the web team leader. However as there is no project management in place the staff members that request the changes have no way to keep track of them and the developers have no way to update staff on their requests other than email. The company also has 7/8 new online products launching every quarter so the project management software that we eventually use will need to keep track of these as well.<p>The biggest issue that we are facing at the moment is tracking projects. We have enough skilled developers but no software to keep the rest of the company updated on the various web projects. This combined with the unlimited number of emails &#38; docs that go back and forth (&#38; get lost) between project stakeholders and developers make tracking project progress almost impossible.<p>Any PM software recommendations would be great and also any advice on how to bring order to a chaotic web development system would be very welcome.<p>Thanks,
T
======
mgkimsal
Almost _any_ web-based tracking tool would help bring order to your chaos. It
doesn't particularly matter which one, as long as everyone uses it. There need
to be penalties for not using it. Alternatively, one person can be designated
as the 'point person' for keeping it up to date, summarizing the emails and
updating statuses as appropriate. If one person has that job, it might make
the transition for everyone else easier.

I'm currently using redmine for projects. It gets the job done right now. You
may have specific in-house skills or needs which may point you to another
tool.

There might be some resistance to it - as in "we don't have _time_ to use
another tool!". But how much time has been lost when documents go missing,
people have different understandings of the project status, and (verbalized)
deadlines are missed or ignored? Likely far more time than it will take to
adopt a single issue tracking tool.

------
kls
No tool will do it!!!!! No for a bit of less sensationalism, you need a good
process, if you have that you can do it on paper tools just help you
streamline your process. When creating a process the #1 rule is don't add
steps to a workers routine for example forcing a developer to branch and merge
their changes just to get their 1 line of code into the system.

Here is what we did, we looked at ever-ones job and tried to figure out a way
that we could not add steps to their job, that broke their work-flow. We then
identified tasks that while technical really only needed someone to administer
the process.

A good example of this is taking everyone's defect tickets and merging them
into a version branch. While branching and merging is a technical process the
person that is most knowledgeable about what needs to go in and what needs to
be deferred to the next release is the release manager. Good ones generally
have better process administration background than technical chops.

So given that they are the best person to oversee this process we wrote
scripts and built a simple UI that allowed them to do trivial merges. If there
was a conflict the system created a conflict branch and then generated a
ticket in the tickets system and assigned it to a developer.

All of this worked in the work-flow that the developers are used to in their
day to day tasks. If you got a merge resolution ticket. That was your task, it
was not a by-product of trying to get your change in, so the developer saw it
as their objective to resolve the ticket not just something to try to plow
through to get you change in.

As well, when a developer checked in a change it would go into a continuous
integration build once deployed onto a server the system would generate assign
tickets to QA testers automatically when approved it would auto merge into the
release branch, generate tickets if there where any non-trivial merges and
then generate a manifest for the release manager.

The point is, streamline your process, identify areas that you can automate to
not create new disjointed work-flows for your workers and get a manager to
mange the process. Then and only then can you truly identify tools that can be
plugged in to help streamline that process.

And remember above all else, creating task that are not intuitive to the work
flow of a worker will create and environment where people put in the least
amount of effort to get it through the hoops to get back to doing what they do
best. It also means training every new recruit on a disjointed work-flow that
does not come naturally and enduring the associated errors that accompany it.

EDIT: Forgot to mention once you have a process defined the metrics for
reporting become self generating from that process. For example our release
manifest is consumed by our PM tools to update velocity, effort towards goal,
milestones and general project tracking.

How we start a project is that we define requirements in a system. Those
requirements get broken down into work tickets and they they get assigned to
developers or administrators. As the tickets get worked they feed back into
the project management system to update the overall progress.

