1. 5

Hello fellow crustaceans,

I’ve just started a new job as a continuation of my security career and part of my new responsibilities is to manage the development of a small internal CRUD application that is due for a major update. I’m new to the world of project management, especially for software projects so I’m looking to see if anyone might recommend specific books, articles or techniques to help. One of my biggest concerns is how to accurately capture all of the requirements from the end users to avoid a trial-and-error approach where we are guessing about how features should be implemented.



  2. 4

    In my opinion, the big change that agile brought to the table was the formalization of trial-and-error. It assumes that we will not get it right the first time, so instead of adding more documentation we simply build it, test it, and make it fail fast. And finally (and most importantly) we learn from it and start over.

    As a developer with no experience in project management, my suggestion would be to listen, dig deep into the reasons why they think they need what they are asking for, and once you have an idea build a prototype and test it quickly to find where you got it wrong.

    In other words, optimize for failure :)

    1. 3

      Let me ask you a tiny, but compelling, question….

      If the way your users do business doesn’t change when they get the new system…..

      Why are you bothering?

      Or why do you think it’s a Good Idea “avoid a trial-and-error approach where we are guessing about how features”?

      It’s almost as if you don’t want to deliver something that will change your users lives in interesting and unforeseen and unforeseeable ways…

      1. 1

        To some degree your “requirements” choices are limited by your software architecture. You mention it is a “CRUD” application. This likely means that your domain logic and constraints are in a Service Layer featuring procedural code wrapped in transactions. If so, then Use Cases or Stories are likely your best bet, despite their ineffectiveness largely due to them inevitably requiring further and further decomposition. They are particularly well suited to this “transactional script” approach, even though it so often results in a “big ball of mud” - as complexity and size increase.

        On the other hand, if you represent your domain logic and constraints in some different way …

        1. 1

          If you are in position to do that, it’s a good idea to start with reviewing the process the application is supposed to facilitate, not the application itself.

          Technical debt is not limited to code, it also accumulates in human workflows. Sometimes a process that was always suboptimal gets automated as is. Sometimes it accumulates cruft over time. There are a few common “process smells”. A report that is made but not used by anyone. Two people doing the same steps. One person doing one thing with the same data repeatedly. A person having to look in more than one place for the same common task.

          Something like IDEF0, or an informal equivalent, is easy to get started with for users, so that you can sit with them and map the current process. Many end users often don’t know what the whole process is. That leads to unclear or outright wrong requirements—one of the main sources of “trial and error”. If you know exactly what needs done, then the remaining trial and error is in how to do it best. When the process is visualized, anti-patterns can be clearly visible. Some things are hard to visualize, but it’s worth a try.

          I’m not exactly opposed to user stories, but ideally story tellers should understand how it fits in the big picture. Who knows if they want a better way to do a task that needs not be done?