3 ms·
Ask HN: How to bring order to a chaotic web dev process?
Hi All,
I'd be grateful for any advice you might have on the following.
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 & marketing team based in the UK. Currently all changes to our web sites are requested by the management & 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.
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 & docs that go back and forth (& get lost) between project stakeholders and developers make tracking project progress almost impossible.
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.
Thanks,
T
- mgkimsal 16y agoAlmost 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 16y agoNo 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.