diff options
| -rw-r--r-- | drafts/adding-value.php | 53 |
1 files changed, 53 insertions, 0 deletions
diff --git a/drafts/adding-value.php b/drafts/adding-value.php new file mode 100644 index 0000000..bc496cf --- /dev/null +++ b/drafts/adding-value.php @@ -0,0 +1,53 @@ +Outline + +- write software to do one thing and do it well + + - prefer general-purpose, reusable solutions to complex one-offs + - see: the UNIX philosophy + - probably also prefer that the software does a small thing + +- invest time into researching, learning, and knowledge-sharing +- spend time on simpler projects with short time to added value vs complex ones + with long time to added value + + - as the team's experience and expertise grows with a larger toolset, those + complex problems become simpler + +- using existing work to leverage new projects adds value + - existing impls reused with new automation reduces manual labor in new fields +- look for "wins" that use what we already know + - extend existing functionality exposed to users into self-service portals to + push ticket time back onto business units +- additional expose leads to new expertise and better results + +- engineering expertise + programming ability + use-case insight = added value + in the form of sustainable, extensible, and reusable software + +# Successful and Effective Enterprise Automation (for non-programmers, or managers of programmers) + +I am a software engineer at a three-letter company. I work primarily as a +developer working on "enterprise automation". My clients are architects, +operators, and systems administrators who are frequently performing repetitive, +time-consuming, or laborious manual tasks. My job is to take those tasks, define +a standardized process for them (if none exist), and write software to carry out +those tasks with little to no human interaction. To do this, the software my +team and I build needs to work quickly, correctly, and efficiently. Some of the +projects I have been a part of have been more successful than others. Here are +some of the lessons learned working on these projects these past three years. + +## Use-Case Insight + +Early on we received requests for projects or features that solved one problem +for one or a few people. We would take their request, build a solution to carry +out the task as quickly as possible, and then hand it off to the user. Maybe it +got used occasionally, maybe it didn't. Projects like these probably weren't +worth the time in research and development that it took to build them. Pet +projects or "would be nice to have" projects are dangerous that way, because the +benefit (or _value_) that they provide doesn't justify the cost to create them. +One of the first larger projects our team worked on was more successful because +we were able to gather a collection of use-cases and build something +general-purpose to solve many problems instead of just one. + +Our company has call centers. Those call centers record their calls for business +reasons. Let's say the software we use to manage those call recordings is called +Calamity. |