emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: "Sébastien Gendre" <seb@k-7.ch>
Cc: emacs-orgmode@gnu.org
Subject: Re: How do you manage complex project with Org-mode
Date: Thu, 03 Mar 2022 08:55:21 +1100	[thread overview]
Message-ID: <87zgm8ov7y.fsf@gmail.com> (raw)
In-Reply-To: <87czj4t6yc.fsf@k-7.ch>

Sébastien Gendre <seb@k-7.ch> writes:

> Hello Tim,
> Thanks for your response and advice.
> I want to keep Org-mode as simple as possible. As you suggest.
> In the past, I ended up several times with a too complex Org-mode
> workflow and stop using it because of that. That because, today, I want
> to keep it simple. Usually, I apply a GTD workflow (or what I think it
> is, I'm not an expert).
> As you say, I need to learn skills for project management. But the
> project management methods we learned at school where to rigid. And, at
> work, the method is more "do the job, stop thinking, be professional".
> But it's, or was, the kind of job where you are asked to "not write test
> to save time". I generally have bad experiences at work.

Sadly, the software industry is full of some very poor middle managers
who don't really understand the complexities of the software
life-cycle. Too often, they focus on immediate deadlines and overlook
long-term maintenance. How you deal with such situations is down to
experience, confidence and where your own personal values lie. There has
been more than one job I've left because the way management was running
the project was poor and almost certainly going to lead to eventual
failure. There has been more than one job interview where I've stated
that if they are looking for someone to write code by the pound, I'm not
there man. I will ask leading questions in the interview to evaluate
what 'style' of development/management they use - for example, if they
measure productivity by the number of lines of code you right in a day,
I will thank them for their time and quietly walk away.

> To manage school big work, I think of managing them as projects.
> I want to apply a simple "Project" workflow:
> * Each project is a headline with the status "PROJECT"
> * Each project have the deadline defined by the school work deadline
> * Each project have a complete description with every info needed to work
> * Each project have one or many tasks (as sub headlines with a status)
> * Each task have a importance, time and effort estimation
> * Each task have its own deadline, distributed along the remaining time
> * When I set a task deadline, I look at its estimations and also other projects tasks
> * To create a new project, I use Org-capture with a template
> Every time I create a new project, it start with one task: "Planning the
> project". With a deadline at 2 days max. The description of this task is
> a checkbox list of thing to do when planning the project.
> And finally, 2 times per week, I got a repetitive task: "Review the
> projects progress". With this, I should be able to adjust spending time
> and effort.

All seems like a reasonable starting point. The key is to regularly
review and refine your workflow. I would avoid the tendency to
think you have to put everything into your workflow. For example, I
would not have a task which says to review my tasks twice a week. Do you
really need a task to remind you to do this twice a week? Do you really
need to track that you have done this? I would classify such tasks as
'noise' tasks. They really don't perform any real purpose.  It is
similar to brain dead project policies which state things like "every
function must have a unit test". Many functions don't need a unit test
and forcing people to write pointless unit tests does more damage than
not having them. A unit test needs to be a positive addition and
deciding when it is or is not is part of what being a professional
developer is all about. Likewise with project management. You don't want
tasks for every simple thing you do. You want to record and track the
important tasks. No tool is a replacement for using your brain - these
are just tools and it is down to us to use them in an intelligent and
efficient manner.

Use org mode to make your life easier. If it isn't making it easier,
then you are doing something wrong and need to review and

  reply	other threads:[~2022-03-02 22:17 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01  1:43 Sébastien Gendre
2022-03-01  4:03 ` Matt
2022-03-02 19:44   ` Sébastien Gendre
2022-03-01  6:43 ` Dr. Arne Babenhauserheide
2022-03-02 20:00   ` Sébastien Gendre
2022-03-01  7:12 ` Tim Cross
2022-03-02 20:33   ` Sébastien Gendre
2022-03-02 21:55     ` Tim Cross [this message]
2022-03-20  5:16       ` Ihor Radchenko
2022-03-20 21:24         ` Tim Cross
2022-03-21  9:25           ` Ihor Radchenko
2022-03-20  5:06     ` Ihor Radchenko
2022-03-01 19:26 ` Antonio Carlos Padoan Junior
2022-03-02 20:53   ` Sébastien Gendre
2022-03-01 21:06 ` Milan Zamazal
2022-03-02 20:58   ` Sébastien Gendre
2022-03-02 16:29 ` Quiliro Ordóñez
2022-03-02 21:05   ` Sébastien Gendre
2022-03-01  4:38 Eric Abrahamsen
2022-03-02 21:26 ` Sébastien Gendre
2022-03-02 23:35   ` Eric Abrahamsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zgm8ov7y.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=seb@k-7.ch \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).