http://www.perlmonks.org?node_id=266330


in reply to Re: Re: XSL/XML/Perl as a development process
in thread <strike>XSL/XML/Perl as a development process</strike>

Thought I should round up my answer more even-handedly.

In practice, I feel managers and programmers (or any "technical" personnel) are as much a victim as vilain, since most of them were never taught how to work with each other.

The CS curriculum normally focuses on programming, nothing much on how to work with people. (Like, a programmer might always complain a req spec wasn't "perfect," instead of helping a non-techie how to write a spec.)

A biz program teaches quite a bit of concepts and theories, but not every biz student came out with good implemenation knowledge (theoretical or pragmatic). I usually found them lack of any concept of "stable system" and why you can't meaningful fix and improve a system that's not "stable." Instead, management by crisis or mgt by (annoying) cheerleading is a common style, which often amounts to destablizing a system.

It would be better if mgrs and programmers have overlapping knowledge that helps bridge their communication gap. In an ideal world, we could have the following:

Stylized view of the distribution of knowledge and skill sets
 

knowledge\skill sets

  strategic
thinking
biz
sense
req elicit
(aka mind-
reading?)
req
analysis
 design programming  QA
(conceptual
and/or
technical)
biz/acc't mgr
 
  
 
  
 
  
 
  
 
  
 
  
 
  
proj mgr
 
  
 
  
 
  
 
  
 
  
 
  
 
  
sys analyst1.
 
  
 
  
 
  
 
  
 
  
 
  
 
  
lead programmer1.
 
  
 
  
 
  
 
  
 
  
 
  
 
  
programmer
 
  
 
  
 
  
 
  
 
  
 
  
 
  
what to
do/know:
if a project/client
strategically or
technologically
compatible &
complementing
the current sys
or products...
how a project
contributes to
the bottomline,
or to the
current system
or products...
ask questions
that lead to
actionable
requirements...
if each step
has adequate
input-output
params,
generalize/
minimize
the flowchart...
generalize,
minimize...
(assume
you know
best here)
explain to
mgr why
the one who
programmed
shouldn't be
the one
who tests...
sample
artifacts:
a sensible
executive
talks sensibly...
biz case,
justifies proj ...
flowchart
(readable by
clients
) w/
indications of
input-output
params at
each step...
flowchart
(meaningful to
programmers
),
conceptual
class
diagram...
class
diagram,
activity
diagram,
mock
screens...
(assume
you know
best here)
test scripts
(manual or
automated)

1.sys analyst -- system-wide architectural issues
  lead programmer -- individual applications


If people don't come in readily with what it takes, we just have to train them in house (if feasible).

See that, on one hand, the major reasons of the software projects' failure (as a business) are "managerial," rather than "technical;" on the other hand, managerial decision process is a collective effort, not just by titled managers.