• sudo42@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 day ago

    Both of you are right.

    You meed to document processes. The minute you put them to paper they will be out of date. No one will read them. It has always been so.

    • funkless_eck@sh.itjust.works
      link
      fedilink
      arrow-up
      8
      ·
      1 day ago

      But it does allow you to go, “Ah here’s where the process went wrong, step 6 in the SOP. Why don’t you use it as a guide for the next one?” It then isn’t me vs them, it’s me helping them understand the documented process collaboratively.

    • MadBigote@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      23 hours ago

      I just started at a new company that really invests time in documenting their processes, but the are poorly made by people that don’t understand the process itself and, in some cases, the process itself is poorly planned and has to be changed over and over again, to the point where the DTP looks nothing like what’s actually done…

      I was instructed to review the documentation you twin myself, but advised the process did not actually describe the process itself…

    • 4grams@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 day ago

      That’s precisely what I’m after, and what I’m proposing. I don’t care about the outputs, I care about the process that gets them to us.

      Also why they need to be living documents, but if we have to reinvent the wheel every time we need a new one, it slows things down. I should mention, I’m on the IT side.

      • sudo42@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 day ago

        There are Process people and there are Get It Done people. Both are necessary. In their extremes, both are bad. When they work together they can do great things.