Ask HN: Any project management app you feel at home with? I know there are tons and tons of PM apps. I wanna know if any of those drive your daily project management activities as (Engineering) Manager. |
Ask HN: Any project management app you feel at home with? I know there are tons and tons of PM apps. I wanna know if any of those drive your daily project management activities as (Engineering) Manager. |
It’s an open source software development platform can do pretty much ANYTHING you want and if you know PHP, you can add everything you need at low cost! It has task management, code repository, code review, team collaboration syatem, knowledge sharing and ...
If someone was starting from no system today I’d recommend Asana. Jira gives you way too much rope to make a custom workflow to enforce business rules, but as long as you have a light touch and use it mostly stock it’s fine. I have trouble organizing medium to large projects with many small sub-tasks in Trello. When I’ve used a more engineering-focused tool like GitHub Issues or Phabricator, I have too much trouble getting non-technical stakeholders to follow along there. I despised PivotalTracker trying to put me in a process straightjacket, and found BugZilla unusably ugly.
I also find it incredibly annoying that when you add a card to a column, it adds it to the top of the column, rather than the bottom.
However, aside from those two annoyances, it does seems to offer a lot of useful functionality.
Asana has the added benefit of allowing the user to interweave non-project-specific tasks to achieve something of a GTD workflow. It really helps me to get every actionable item out of my head space and assign some kind of priority / responsibility / due date to it.
Asana Premium is a must for the flexibility with custom fields (https://asana.com/guide/help/premium/custom-fields)
The tool is expensive, constantly deteriorating in visual appeal, workflow, and support, and over complicates very simple tasks. The Agile Clergymen who work at my office boast it's integration abilities, it's high customization, and 3 charts it produces that inevitably say "You're not Agile enough" as being all one would ever need for a project management system.
In my opinion there are three main options right now.
If you're hosting an internal Software Development-only ticketing system that only the PM and the developers will interact with, and you are using GitLab, and you have the ability to host a robust GitLab server internally, I would recommend GitLab Issues [0]. It's free and open source and very integrated with the entire workflow even including time-tracking, gantt charts, etc. It's all bundled into what they're calling a Portfolio Manager [1] that has a bunch of other features you may want to explore as a PM.
If you want to use JIRA because the Agile mob is present within your organization it is a fine option so long as you either don't mind spending a very long time figuring out how the unnatural interface works and setting up a bunch of essentially needed "customization" then you can look into that. It even produces 3 pretty nice charts!
If you specifically need to take in issues and triage bug reports and feature requests then you may want to look into Redmine [2] or BugZilla [3]. Both are extremely dated but have been tried and successfully used by many large teams.
[0] - https://about.gitlab.com/features/issueboard/
[1] - https://gitlab.com/gitlab-org/gitlab-ee/issues/3254
[2] - https://www.redmine.org/
Clubhouse is Trello where each card can is synced with a git branch. As you add and push, the cards move automatically.
This helps me as a developer, because the business is always up to date with the latest progress and all I need to do is follow the company's git workflow.
To see the cards move when you raise or merge a PR is magical.
There are other features like collecting tickets together into an epic, sub projects and integrations with logging and deployment tools. If you are the manager and you implement this in your org, you dev team will love you.
As a PM, my main focus is just to get people to update what they're doing and trying to assign, distribute, negotiate, and see tasks and dependencies that need to be done.
Asana - Amazingly good in the first few versions. But it started getting slow as they added more features. Back then I would use it even for trivial things like bug tracking, because the keys and controls were so intuitive.
Google Docs/Sheets - It does the job. It's got history and versioning. Low learning curve. It's very powerful at searching (you can link to a document and it will search the linked document as well). Sheets is mildly programmable.
It's missing some tricks like tagging people and tracking who is assigned to what, attaching files, and has a limited comment system. You can't really subtask, map dependencies, or do burndown charts with it.
Jira - Hated it. Its core purpose seems to be covering asses. It makes a PM look extremely productive. It makes late night and remote workers look productive. It logs what people are doing and logs issues and dependencies. Extremely useful for people who have agile contracts for another company. But actually managing people seems to be the lowest priority of the tool.
Pivotal Tracker - Lots of potential. If you're using full Agile, this is probably the best. It's probably too heavy if you have a team of two, but even then it works. I think the Epics handling is a little messy, but it's much better than the others.
Trello - good for assigning tasks to a group. Too light for managing a pipeline from design to dev to testing to approval. At some point, it acts like email, where people get too many messages and ignore a lot of them.
I'm considering experimenting more with Google Sheets and maybe even group Evernotes. The others are a bit too clumsy.
- shared but read-only, the manager writes
- at the top of page1 are your top3 quarterly goals
- each persons name starts a short outline list of their 2 -3 active task-goals
- since your team is 3 - 8ish ppl everyone fits on one page
- all other ideas, wants, tasks, goals, questions, etc go onto page 2, "the wishlist"
- meet twice a week, mon/thur
- monday you go around the "room" (its always a vid conf) and each person declares their 2 - 3 items
- thursday you go around the room and go over what got done and/or learned
- every quarter you start a new doc with a clean/only-a-few-carryovers wishlistI was happiest when my team could just get by with GitHub issues. It was super simple and really easy to work with.
Eventually we used JIRA and Confluence, and it worked fine. Just make sure you keep workflows as simple as possible. I think there exists the temptation to add lots of constraints and requirements when creating and resolving issues, but that just raises the bar for getting actual things done. If reporting something takes more time than actually fixing the bug then your system is broken.
I wrote a book on extreme minimalist information management[1]. Notepad and git (along with the appropriate text tools, which might just be some shell programming) work just fine, as long as you know how to tag and organize stuff.
Even without the stuff I wrote about, what do you really need to know? 1) What work is there? 2) How much of it is done? 3) Who's doing what? 4) How are things going?
There's not a lot to it -- which is probably why you see fourteen million PM apps out in the wild.
I'd like to see PM apps make the transition that source control apps did to git. That is, moving from everybody-makes-an-app-they-sell-you to something bland, easy, free, highly configurable and interoperable -- and runs anywhere. There's no reason we can't have that.
For anyone interested. I also have a free white paper specifically about PM information management. Ping me.
- Meeting starts every Monday night, 5PM/end of business day - Meeting ends when it ends. Usually 1-2 hours, but at times till midnight - Only executives, one per department: so CEO, COO, CFO, SW Development, Marketing/Sales... no more than 5 max 7 people - A google spreadheet - Projects are ranked by importance: 1,2,3 and 4. 1 High, 2 medium, 3. low. 4 just placeholder for ideas - Projects must have a completion date of 3 months or less. If longer they get broken down into <3 months chunks - Weekly deliverables. All deliverables are due on Monday - Each row is 1 project, then there are columns for Dependencies, Resources (people, money, things, outside contractors) - If one of the deliverables is going to be late, or there's a chance it might be late, the executive has to notify the executive committee by email no later than end of business day on Thursday with a succinct explanation of what's going on and revised project deliverable etc.... The CEO is in charge of eventually clarify with the Executive or take any action. If no such email arrives, the deliverable is assumed to be on-time, on-target, and on-budget by the following Monday. - Only the Executive is accountable. No blaming others.
The above was the original, these days I like to ADD to the above BASECAMP project management for any and all communications between anyone involved. Everything's public, from commitments to comments, if it's not in there, it didn't happen.
Do you need an application, at all?
I would suggest you to devise a WORKFLOW that you like, and you build or choose a (probably small) app that fits your needs.
Personally, I rarely found PM problems (reporting, calculating effort spent vs remaining, record task completion) that require a lot more than a spreadsheet, but again, I don't know what you're trying to achieve.
The great thing about having our own tool (which we also license to our customers but it's far from our main focus) is the possibility to adapt exactly to how our company works. It is integrated into everything (integration and offline are our strengths) and when something doesn't fit, it usually takes a few days until a solution is found (or it is already implemented for a customer). It even has a lunch module which adds calendar entries in our outlook when we say we are attending a company lunch, and that is integrated into navision which takes care of the accounting side.
We also evaluated using JIRA at one point in the history. IMHO, if JIRA fits, go and use it, when not, you can bend it but that causes some headaches.
Your company's website is simply atrocious. It takes many seconds to load on my 100 MBit/s connection, the CPU fan immediately spins up, scrolling lags, opening the navigation / burger menu takes several seconds, further navigation again takes several seconds before anything but a spinner shows up.
Suppose I'm a prospective customer. If I saw your website, you're going to have a hard time to sell me your (presumably) web-based software, since I must conclude that it must be as slow and bloated (or worse, since it should have more functionality than delivering a static page) than your company website.
Thanks for the feedback, I'll pass it forward.
Every business works differently, so all PM apps in their default config will match 80% of what you need, for 80% of businesses.
If a manager implements an app without customising it to the business, users will be frustrated, directionless and end up hating the app - see user comments in this thread!
Bespoking it to the business allows users to do their jobs with minimal interaction AND WITHOUT MICROMANAGEMENT.
Finally, without management buy-in (that's you!), without you actually using the inputs and outputs of it, it will fail - lead by example.
Hope this helps :)
Give it some love.
Phacility
Phabricator
Other setups I've worked with are Trello-style (but not actual Trello) kanban boards, be it a physical board or a board implemented in something else. In some projects it worked very well with GitLab and GitHub integrated project tools. As limited as they are, they are a great minimal way to workflow your stuff. Anything more complex than that is often in the wrong place and should most likely be managed at a different (non-engineering) level. Perhaps that is why JIRA works for us as well on most projects; we tend to not mix engineering and non-engineering stuff as they often have different needs where even small differences make for a bad combination in the same tool.
I honestly like it very much. It is way easier to use than Jira, nice modern UI/UX, integrates with git etc. It has enough features to help with larger projects, and you can shut off features you don't need. There's even more to say, but I don't want to spam the thread.
I feel the product deserves credit. You can try it out.
One backlog. It forces everyone to truly think about priorities and by its design, avoids the “everything is important, mark it a P5!” issue.
That's also the fault of my process-obsessed co-workers who, in my opinion, often prize how we do work over actually doing work. Our workflows are hilariously over engineered. Even so, pivotal is great. I'd choose it again in a heartbeat.
I know Jira and Confluence get a lot of hate but the companies I’ve worked for always seem to favor it and I’ve gotten very comfortable in there now. If I were at a company with <20 people then I’d go with Trello. >20 then Jira
While it doesn't have all the bells and whistles or even the integrations as Jira or Asana, I've found it more useful.
When you have a bad project manager, good software will not save you. This is my personal story of how things can go wrong:
-----------------------------------
At 2 PM we had a meeting scheduled to go over all of the tasks in PivotalTracker. John had promised Milburn that we would execute our work according to a project-management philosophy that the tech industry called agile. Agile software development, among many other aspects, focuses on the delivery of small, incremental improvements to software. It encourages self-organizing teams, evolving and continuous progress, and rapid response to challenges faced. The Celolot team would work two-week sprints, checking in at the end of each period to see where everyone was at.
Unfortunately, vague definitions of “done” haunted our progress. John read through a long list of tasks that had been assigned to Sital.
“Find all possible variations of ‘Close Date,’” John read from the screen. “Is this done?”
“Yeah,” muttered Sital. “Sure.”
His assurance meant nothing to me. Sital would never lie, indeed I was often surprised by his childlike honesty, but he lacked an appreciation for the many ways that software could break.
“How many variations have been tested?” I asked.
“Two,” replied Sital.
“That’s not enough,” I said.
“That’s enough,” countered John. “‘Close Date’ and ‘Contract.’ That’s all we need.”
“What about ‘Close’?” I asked.
“Oh, yeah,” John thought aloud. “What about ‘Close’?”
“I’ll see,” Sital responded somewhat robotically.
John marked it as done.
“Wait,” I objected. “That is not done.”
John turned back to Sital. “Do you think you can finish today?”
“Absolutely,” Sital assured us.
“Then I’ll mark it as done,” said John, returning to his screen.
“But it’s not done till it’s done,” I argued.
John pondered this for a brief moment. “It’ll be done today,” he shrugged. He marked it as done.
In my view, John’s casual use of the word “done” to refer to items that were nowhere near done meant that this whole effort to track tasks was a useless ceremony. But John felt good about it. He could tell Milburn that we were following a two-week sprint, just like an authentic agile team.
It was true we had the accoutrements of an agile team. We used PivotalTracker. We broke down goals into fine-grained tasks. We reviewed the task list once a week, and we added more tasks every two weeks. But the whole thing was mockery of what the Agile Process was supposed to accomplish. If you have programmers who cannot finish assignments, then there is no point in pretending to be making progress.
----------------------
related to here:
https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...
Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work. If you've got your head stuck in an online system for any length of time during the day, you're not doing it right.
Tools, whether PM tools or not, are supposed to disappear so you can focus on value. If you're talking about them, spending time in them, going to useless meetings with pointless reports generated from them, etc? They stop being tools. At that point they become obstacles. Carpenters don't go to meetings with graphs of how many hammers they own. Brick masons don't spend half a day comparing the status of all of their trowels. Project Management has jack squat to do with configuring and using PM tools. Unless you're specifically training on skills, tools should disappear. That's the entire point. I wish more people knew that.
ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing. To them, the feature list of any tool is reassurance that they can continue not knowing what they're doing and somehow things will still work out fine. The tool will handle it.
> ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing.
This to me proves you're not in the bubble of people who I talk about when I say "Agile Clergy".
I remember my first coaching gig. I was looking to dive into a team, get into the code, make things happen! Instead, I spent the first day in what could best be called religious discussions. It was quite odd.
But in their defense, they had no context. Agile was an abstract and nebulous thing. Instead they all had heroes/demigods that they looked to for advice from on-high. The focus was on "being correct"; tool features, usage, and adoption; having a good time with the teams. All sorts of crap instead of just making stuff people want.
I see the same thing in management, with or without the Agile part added in. Once you get removed from value delivery, even if it's only just a little bit, you end up adrift at sea. So many of the management schools are just as religious as the Agile folks. They just have different demigods :)