1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
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.
|
