7 ms·

The best project managers I've had have identified and removed obstacles for me (including things like - attending mandatory meetings, so the devs don't have to

• cube00 10y ago
  Agree with not going overboard with stats and Jira. However being good with these tools to help measure velocity and improve the quality of estimates reduces the pressure on the team when clients plant the seeds of doubt that you've over estimated.
  • marktangotango 10y ago
    I agree it's possible to go overboard, but I find that a lot of developers don't appreciate how useful it is to have documentation of what the team is doing and visibility (ie numbers) into how time is being spent. A lot of developers hate tracking task in jira or any task tracker, but whenever deadlines start being missed due to roadblocks thrown up by other teams, or ineffective project management, having that all documented can really help resolve toxic situations.
    • atmosx 10y ago
      <rant> I don't know, Jira feels like a conspiracy theory in action: Atlassian somehow tricked management into adopting JIRA. Then the management had to pay insane prices for external plugins in order to allow programmers to do trivial things like displaying in a visually appealing way hours spent over a week. It's really an awesome business model. Worked great for Microsoft. </rant>
    • ci5er 10y ago
      Then one of the requirements on the project manager would be to communicate what his own constraints and objectives are to the team, right? One could imagine a PM saying to the team: "I go to meetings so you don't have to. But one of the tools I use to keep the finance people happy enough to keep this project fully staffed is those stupid metrics. Help me help you by filling them in."
• bitwize 10y ago
  If it can't be measured, it can't be managed. Remember that your manager is accountable to someone else higher up the chain. They don't know how dev works, but they want to see quantifiable progress. Statistics, spreadsheets, and tools like Jira are how that progress gets communicated. Like it or not, this is an essential part of the business.
  • Aqueous 10y ago
    Yes, it is important. However, some project managers obsess over it. Instead of focusing on delivering something the client wants and finds valuable they obsess over estimates, minimizing change orders, and time spent, to the point where it becomes the single determining factor in what we do and don't do. It's important to be on time. I've found that it's more important to solve the client's problem. And if you solve the client's problem well enough, the client will give you flexibility on the time.
  • quantumhobbit 10y ago
    The best measure of how a project is going is using the software it is producing. Instead of using questionable data from Jira and the like, just try to use the software. Ask for a demo, or run the code yourself, or look through unit and acceptance tests.
    • bitwize 10y ago
      Direct supervisors can do that and get a detailed feel for how it's going. But that's too touchy feely, too many variables. C-level execs want to know "are we on track to ship version 3.0 by the end of the quarter?" and they need a yes/no answer, justified by numbers and graphs. They don't know about unit tests, and can't be bothered to walk through the software itself.
• bobbytherobot 10y ago
  Speaking of the tools (spreadsheets, Jira, standups, etc), the tools are there to help you execute your process, they are not your process. Too often I see people try to fix their process - or simply the lack of a process - by throwing random tools or catch phrases at it.
• Jtsummers 10y ago
  Attending some of those meetings, as a developer, isn't all bad, though. It can be useful for: 1) Providing direct input, rather than summarized versions (even good project managers lose track of details and misstate things). 2) Learning what your project manager and others do. This can reveal corporate bullshit, but also enlighten you as to the amount of work that other middle-manager is actually involved with (and you may be surprised by their technical competence, or disappointed). 3) If you want to move out of a managed role in your company as a developer, and into a role that affords more authority and direction of projects (your own vision, if you will), this is a good opportunity to learn and to get face-time with people that you'll be interfacing with later, or that'll give you a promotion. 4) You don't find out secondhand what the corporate decisions are, you were there to witness them. 5) You learn what to say and what not to say to management. Never, ever, say that X is almost done when X is a prototype or subsystem. You speak about the completeness of the whole system, and then break down to the subcomponents. You learn the art of understating progress so that you don't seem to be behind (because you aren't, hopefully) but also to avoid the appearance of being further ahead (because it's just a prototype, or it's only one subsystem, or whatever). I learned a lot at one of my jobs by being invited, as a lowly new-hire tester, to a few meetings with management. In particular, the smallness of scope of my portion of the project to the project as a whole, while still being on the critical path. Particularly, those meetings sat at the intersection of electrical, chemical, software, and mechanical engineering. That's where I learned what systems engineering was really about. A lot bad about that company, but outside their mismanagement of software, their understanding of systems management was actually pretty solid. That mismanagement was changing, but a lot of us software types didn't realize or understand our role in the whole process either (overvalued ourselves).