“I’ve been saving for months to get the Corsair Dominator 64GB CL30 kit,” one beleagured PC builder wrote on Reddit. “It was about $280 when I looked,” said u/RaidriarT, “Fast forward today on PCPartPicker, they want $547 for the same kit? A nearly 100% increase in a couple months?”

  • HubertManne@piefed.social
    link
    fedilink
    English
    arrow-up
    1
    ·
    21 hours ago

    Honestly the biggest problem I see is not getting requirements but being pushed for deadlines. I have been in monitoring solutioning lately and we constantly can’t get answers from teams on what they need and end up having to just analyzed the data as non specialists and do a best guess because we can’t just not have the solution happen.

    • Aceticon@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      7 hours ago

      Well, seniority helps on the deadlines front: you can spot managers trying to force too short deadlines on you a mile away and throw it back at them (“I’m am the specialist, so I’m the one who knows best how long it will take”) and if they just try and impose deadlines you can bluntly state “that isn’t possible” and if they somehow have the authority to push them you make sure everybody (especially other managers, ideally the managers above them) knows that you’ve informed them upfront that such deadlines were impossible so when it inevitably fails, said manager can’t shove the blame your way.

      As for obtaining things from other teams, that’s a two part thing:

      • First make it painfully obvious in your estimates that a dependency on something from an outside teams exists. When inquired about progress, constantly point out that it will only happen “if that team provides us what we need to progress”. Keep reminding people that those deliverables are a conditional for yours - “they’re late our project is late”.
      • Second, start pushing them for delivering to you what you need well before you need it. It’s there, in your planning, so you know you need it and have some idea of when. The bigger the project the earlier you start pestering them. Persist on asking them for it, escalate to upper management if no movement is visible on their side. Make sure the groundwork is set so that if they’re late they get the blame on project deadlines being missed. It depends on the country culture but generally most people aren’t really impeccable professionals at time and priority management (and yeah, that includes managers) and tend to prioritize addressing “what’s burning harder” in their pile, hence why you need to start pestering them early, do it often and with more urgency the closer it gets to the point you need it (to make sure it’s perceive as an urgent need and rises to the top of their priority pile) and make sure the groundwork is set for them to be blame if your own deadline is missed because they were late and, more importantly, that THEY know they will get the blame (this generally at mid/upper manager level), so that from their point of view it’s “burning” (i.e. they’ll suffer if that doesn’t get picked up on time)

      Of course, all this requires competent management since they’re the ones supposed to do it and if your managers are trying to impose deadlines on you or using slimy trickery to get people to commit to shorter deadlines, they’re NOT competent managers - that kind of shit invariably yields death marches and bug-riddled results that in the mid and long term end up wasting far more time that it was shave by those shorter deadlines.

      Kinda sad that one has to play such games. Welcome to Mankind.

      • HubertManne@piefed.social
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 hours ago

        yeah although in the situation Im talking the issue isn’t the deadlines vs the technology we are configuring but in not getting the requirements from the various specialists for what they want out of it. I have encountered things like it all the time. Each team has their own priorities and they won’t really put in the effort until they are actually using the product regularly and then decide what they want out of it because its not giving them exactly what they want. Honestly can’t say it upsets me to much as ultimately it keeps me employed longer.

        • Aceticon@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 hour ago

          Most people don’t actually know what they need until the see it, and the only ones who might are those who already have a process in place (hence know it in detail) and just want it or parts of it automated.

          People often do think they know what they want, but it’s a very general and fuzzy view, with little in the way of details and which seldom considers what should happen outside the most thread path of their process (i.e. things like error situations such as “what if somebody enters the wrong data in this form” or after the fact responsibility tracing in the form of usage logs and reports).

          It is actually a bit of an art to tease the details of the requirement from the stakeholders in a consistent and thorough way and also spot and get requirements for those “outside the main process path” elements and, frankly, in my career I’ve met very few people - even amongst business analysts - who are actually good at it.

          That said, what maybe the main advantage of Agile when done properly (with proper use cases and the actual end users trying the implementation of those requirements out) is exactly that it’s an interactive process to refine the requirements by cycling back and forth between requirements gathering, feature development and result evaluation to fill in missing details and tease out further requirements. IMHO, this is actually were Agile shines the most when compared to Waterfall, but as I said you need to do the requirements gathering and results evaluation parts of Agile (so the parts involving interacting with actual users bot upfront in making use cases and at the end of the cycle in evaluating the fitness for what they need of what was implemented) to get those gains, and most “Agile” teams out there seem to only do the fashionable parts of Agile like the “standup meeting” which aren’t what makes it most valuable as a process.

          • HubertManne@piefed.social
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 hour ago

            Oh I agree here. I find I often really need to get to the “what exactly do you expect to do with it” as they will want something thinking it will help them with X but its not really what they want.