Should I file my checklists as documentation?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
10
down vote
favorite
I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.
I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.
We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.
Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?
documentation
add a comment |Â
up vote
10
down vote
favorite
I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.
I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.
We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.
Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?
documentation
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33
add a comment |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.
I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.
We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.
Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?
documentation
I keep lots of little checklists of to-do stuff. I used to keep them on a legal pad and I threw away the pages when they were done. Now I use an iPad app, so my history is always stored,but I don't save it in any form of official documentation.
I'm a programmer so most of my work is documented via version control, but there's lots of little fixes to non-version controlled software, database changes and check-ups I do as I fill a sort of support role as well.
We've been trying to document what we do in my department more so the idea came to me, but my changes aren't the ones that have been causing problems.
Should I keep my task list as a sort of official documentation? How would I make sure it's actually useful for someone other than me?
documentation
asked Apr 13 '12 at 16:04
Rarity
4,37643457
4,37643457
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33
add a comment |Â
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33
add a comment |Â
7 Answers
7
active
oldest
votes
up vote
8
down vote
It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.
If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.
Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.
Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
add a comment |Â
up vote
6
down vote
I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.
It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
 |Â
show 1 more comment
up vote
3
down vote
I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.
A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.
add a comment |Â
up vote
2
down vote
Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.
The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.
You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
add a comment |Â
up vote
1
down vote
You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.
From Wikipedia
The retention period of a document is an aspect of records management.
It represents the period of time a document should be kept or
"retained" both electronically and in paper format. At the termination
of the retention period, the document is usually destroyed. The term
is generally used by accountants and tax professionals whose
occupation involves dealing with legal documents that only need to
remain in existence for a certain amount of time. The retention period
varies for different types of records. For example, business
incorporation documents have a permanent retention period (meaning
that they should be retained and never be destroyed), but receipts for
tax-deductible purchases by an individual taxpayer usually have a
three-year retention period (and can often be safely discarded after
that point.) The length of the retention period vary by industry and
are based on the likelihood that the document will be needed at some
point in the future for ligitation reasons. Records that will serve no
further purpose (as determined by the length of their retention
period) are destroyed for space issues, usually by paper shredders.
add a comment |Â
up vote
1
down vote
To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.
My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.
The key is keeping it public and easy to update (and access, even via your iPad).
add a comment |Â
up vote
0
down vote
Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.
If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.
Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.
Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
add a comment |Â
up vote
8
down vote
It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.
If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.
Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.
Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
add a comment |Â
up vote
8
down vote
up vote
8
down vote
It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.
If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.
Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.
Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.
It sounds like your department is trying to keep better track of who is doing what and what is being done, so towards that end I would say yes, you should keep them. That said, it sounds like in the format they are in, they will not be useful to many other people, as they may be random collections of big and little tasks with little associated information or tags.
If there is a concerted effort in your department to track and document more, it does sound like a good time to begin using software for this. One of the huge benefits of using a service like Fogbugz, Teambox, Trello, Pivotal Tracker, etc, is that everything you do becomes searchable to both yourself and any current or future team members. Want to see the first time someone dealt with a particular issue, or if it comes up often? Search for it, and see what comes up.
Personally, I implemented Teambox in my workplace, and I encourage my coworkers to use it for collaborative tasks. But I also use it myself for things that only I need to keep track of, knowing that whoever is in my role in the future (even if it's me!) may appreciate this history of how certain things were handled before.
Many of these systems are fairly quick and easy to use and integrate a commenting stream do that updates and discussions around a task are stored with that task. Also, if there are repeatable task lists, many of these systems let you store them as a template.
answered Apr 14 '12 at 4:00


Tech Lover in NYC
771617
771617
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
add a comment |Â
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
Use a Ticketing System (Also called Issue Tracking: Such as Trello, Jira... etc).
– Sandra K
May 29 at 14:24
add a comment |Â
up vote
6
down vote
I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.
It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
 |Â
show 1 more comment
up vote
6
down vote
I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.
It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
 |Â
show 1 more comment
up vote
6
down vote
up vote
6
down vote
I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.
It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)
I had kind of the same situation at my previous employer. I ended up just starting to write up in our wiki each time I had a new non-trivial support issue I had to deal with. It was somewhat enlightening, as there was a significant amount of information that I had just internalized. Even the tiny issues really assume that you have at least some level of institutional knowledge.
It's a pain to do when you start, but afterwards, it's kinda nice as you can take a vacation and maybe get one phone call instead of 3-4 a day. :)
answered Apr 13 '12 at 16:59
Brandon
31125
31125
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
 |Â
show 1 more comment
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
That sounds like a lot more than a simple checklist.
– FrustratedWithFormsDesigner
Apr 13 '12 at 17:24
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
I wish we had a Wiki, I sorta liked the idea of a wiki in a ticketing system. All we have are horribly sorted word documents
– Rarity
Apr 13 '12 at 18:55
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@FrustratedWithFormsDesigner Yeah - my day-to-day stuff might be a checklist for me, but it's not going to be for someone else. They'll likely need the half page of background info to grok what's going on.
– Brandon
Apr 13 '12 at 21:25
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
@Rarity Set one up. Install IIS on the dev server, grab Windows Platform Installer and install ScrewTurn and just run with it. I prefer to ask for forgiveness than permission. :)
– Brandon
Apr 13 '12 at 21:26
1
1
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
@Rarity I'm a Windows .NET guy myself, so I defaulted to using the WPI, but I understand where you're coming from. Throw MediaWiki at an Apache box and go to town. :)
– Brandon
Apr 13 '12 at 22:00
 |Â
show 1 more comment
up vote
3
down vote
I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.
A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.
add a comment |Â
up vote
3
down vote
I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.
A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.
add a comment |Â
up vote
3
down vote
up vote
3
down vote
I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.
A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.
I would say you should document everything you do. If the only documentation is the checklist then yes, it should be saved somehow.
A note on terminology though, I'm not talking about "documentation" in the sense of someone else referring to it later, I'm talking about a record of your activities, suitable for mentioning at your performance review. Keeping a list of what you've done will help you put together a statement of accomplishments, and if you've missed important goals it will give you an idea of what other tasks came up that made the goals/deadlines slip.
answered Apr 13 '12 at 18:09
voretaq7
5,21812529
5,21812529
add a comment |Â
add a comment |Â
up vote
2
down vote
Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.
The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.
You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
add a comment |Â
up vote
2
down vote
Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.
The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.
You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.
The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.
You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.
Maybe. I think the place they would be most useful would be training staff to take on new tasks that they are unfamiliar with. For example, trouble shooting a specific class of problems might involve walking through some steps and using a checklist to eliminate certain situations. A checklist might also be good for tasks such as complicated code deployments or server changes. I've seen simple checklists in the documentation for developer setup guides for setting up the environment for more complex projects.
The downside of a checklist is when the person following it is unknowingly on an instance of the task that deviates a bit from what the checklist assumes. Hopefully though, that won't happen until after the person is skilled enough to not need the checklist and make their own decisions.
You also want to avoid having people become entirely dependent on the checklist, so maybe don't make it too detailed - maybe write it more as a high-level guidline, unless the specific task will not change and the deep detail is necessary.
answered Apr 13 '12 at 16:21
FrustratedWithFormsDesigner
10.7k43957
10.7k43957
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
add a comment |Â
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
Unfortunately my checklists are more only for me, it'd take some substantial rewriting for them to be useful to others. especially as anything more than "what I did lately"
– Rarity
Apr 13 '12 at 16:24
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
@Rarity: Are they at least repeatable, such that you could use them again in the future to avoid having to figure out everything all over again?
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:26
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
Not as of yet, they're usually not split into sub-tasks. If something's actually complicated I put it out in an actual document, like how to install our server.
– Rarity
Apr 13 '12 at 16:28
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
@Rarity: Only useful to you, for non-repeatable tasks... Based on how you decribe them, I think you might get more use by filing your grocery shopping lists as documentation. At least those are sometimes repeatable. ;)
– FrustratedWithFormsDesigner
Apr 13 '12 at 16:31
add a comment |Â
up vote
1
down vote
You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.
From Wikipedia
The retention period of a document is an aspect of records management.
It represents the period of time a document should be kept or
"retained" both electronically and in paper format. At the termination
of the retention period, the document is usually destroyed. The term
is generally used by accountants and tax professionals whose
occupation involves dealing with legal documents that only need to
remain in existence for a certain amount of time. The retention period
varies for different types of records. For example, business
incorporation documents have a permanent retention period (meaning
that they should be retained and never be destroyed), but receipts for
tax-deductible purchases by an individual taxpayer usually have a
three-year retention period (and can often be safely discarded after
that point.) The length of the retention period vary by industry and
are based on the likelihood that the document will be needed at some
point in the future for ligitation reasons. Records that will serve no
further purpose (as determined by the length of their retention
period) are destroyed for space issues, usually by paper shredders.
add a comment |Â
up vote
1
down vote
You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.
From Wikipedia
The retention period of a document is an aspect of records management.
It represents the period of time a document should be kept or
"retained" both electronically and in paper format. At the termination
of the retention period, the document is usually destroyed. The term
is generally used by accountants and tax professionals whose
occupation involves dealing with legal documents that only need to
remain in existence for a certain amount of time. The retention period
varies for different types of records. For example, business
incorporation documents have a permanent retention period (meaning
that they should be retained and never be destroyed), but receipts for
tax-deductible purchases by an individual taxpayer usually have a
three-year retention period (and can often be safely discarded after
that point.) The length of the retention period vary by industry and
are based on the likelihood that the document will be needed at some
point in the future for ligitation reasons. Records that will serve no
further purpose (as determined by the length of their retention
period) are destroyed for space issues, usually by paper shredders.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.
From Wikipedia
The retention period of a document is an aspect of records management.
It represents the period of time a document should be kept or
"retained" both electronically and in paper format. At the termination
of the retention period, the document is usually destroyed. The term
is generally used by accountants and tax professionals whose
occupation involves dealing with legal documents that only need to
remain in existence for a certain amount of time. The retention period
varies for different types of records. For example, business
incorporation documents have a permanent retention period (meaning
that they should be retained and never be destroyed), but receipts for
tax-deductible purchases by an individual taxpayer usually have a
three-year retention period (and can often be safely discarded after
that point.) The length of the retention period vary by industry and
are based on the likelihood that the document will be needed at some
point in the future for ligitation reasons. Records that will serve no
further purpose (as determined by the length of their retention
period) are destroyed for space issues, usually by paper shredders.
You should check your companies document retention policy. Some companies may require you retain them, some require that you do not. The reason is after a certain amount of time they can be considered discover-able documents for legal proceedings. These vary by company. I have worked at companies that considered any document over 5 years a record that required retention. Even if it was a menu used for take out that had a not scribbled on it.
From Wikipedia
The retention period of a document is an aspect of records management.
It represents the period of time a document should be kept or
"retained" both electronically and in paper format. At the termination
of the retention period, the document is usually destroyed. The term
is generally used by accountants and tax professionals whose
occupation involves dealing with legal documents that only need to
remain in existence for a certain amount of time. The retention period
varies for different types of records. For example, business
incorporation documents have a permanent retention period (meaning
that they should be retained and never be destroyed), but receipts for
tax-deductible purchases by an individual taxpayer usually have a
three-year retention period (and can often be safely discarded after
that point.) The length of the retention period vary by industry and
are based on the likelihood that the document will be needed at some
point in the future for ligitation reasons. Records that will serve no
further purpose (as determined by the length of their retention
period) are destroyed for space issues, usually by paper shredders.
answered Apr 13 '12 at 18:50


IDrinkandIKnowThings
43.9k1398188
43.9k1398188
add a comment |Â
add a comment |Â
up vote
1
down vote
To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.
My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.
The key is keeping it public and easy to update (and access, even via your iPad).
add a comment |Â
up vote
1
down vote
To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.
My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.
The key is keeping it public and easy to update (and access, even via your iPad).
add a comment |Â
up vote
1
down vote
up vote
1
down vote
To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.
My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.
The key is keeping it public and easy to update (and access, even via your iPad).
To answer your last question first, you will only know if other people are interested after you document it somewhere others can see it.
My suggestion: document it on a wiki where everyone can see it. You can either put it on a page as an "official" procedure for your position or on a personal page. But then at least other people can see it when you are away and take over your tasks. And people in similiar positions across the company can peer review it and exchange ideas.
The key is keeping it public and easy to update (and access, even via your iPad).
edited Apr 14 '12 at 12:02
answered Apr 14 '12 at 11:48


Wikis
1,50311525
1,50311525
add a comment |Â
add a comment |Â
up vote
0
down vote
Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
add a comment |Â
up vote
0
down vote
Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.
Do you have a case tracking system like Bugzilla or FogBugz? I work on a programming team and we use our FogBugz instances for general tasks in addition to bugs/feature requests and it works pretty well.
answered Apr 13 '12 at 18:38
JohnFx
3,8302233
3,8302233
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
add a comment |Â
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
IT's a small system and practically a one man team for any given fix, so we don't use a bug tracker, just commit messages. Hasn't been a big enough problem to get anyone else to use a bug tracker.
– Rarity
Apr 13 '12 at 18:48
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
Actually you may be in luck then. FogBugz (and probably others) will let you use the hosted version of their tool free if you have less than 2 users (fogcreek.com/fogbugz/StudentAndStartup.html)
– JohnFx
Apr 13 '12 at 18:50
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f527%2fshould-i-file-my-checklists-as-documentation%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Why would database changes not be in source control? And why not check in scripts you use to do checkups?
– HLGEM
Apr 13 '12 at 18:55
@HLGEM I'm working on getting that started, but this isn't just about database stuff
– Rarity
Apr 13 '12 at 21:33