| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: OOP - a question about database access
"Tak To" <takto_at_alum.mit.edu.-> wrote
TT.0> It seems to me that these managers have confused features with TT.0> tasks. Using the analogy of a building: these managers think TT.0> they can schedule construction by rooms, thereby ignoring TT.0> tasks such as pouring the foundation, laying down the pipes TT.0> and ducts and pulling the wires.
Bob Badour wrote:
BB.1> A foundation is a feature. Pipes are features. Ducts are features. BB.1> Wires are features. Some features are "must have" features and BB.1> some are not. Humanity got by without foundations, pipes, ducts BB.1> or wires for many millenia. Granted, dwellings without BB.1> foundations have quality, stability and durability issues, but BB.1> they are still used on every continent.
TT.2> I am not sure if you think my analogy is inapt, or you think there TT.2> is no distinction between tasks and features.
BB.3> There is a distinction between tasks and features. However, BB.3> I find both the analogy and the conclusion inapt. Managers do BB.3> not need to divide features into tasks; the tech staff working BB.3> for the managers need to have this skill.
This is _your_ point of view of what a manager should do, and this is exactly where we differ. I assume we are talking about a technical manager here and in my view (no doubt different from yours) a technical manager should manage technology -- i.e., the development of software. There are of course non-technology related tasks a manager does, such as what you have listed: negotiate timelines and budgets, hire resources, motivate and discipline employees, manage contacts. However, in my experience (which no doubt differs from yours), non-technical management tasks alone usually do not justify the expenses of a manager position -- at least at the typical manager-staff ratio that I have seen. In other words, I think many of the mid-level bean counters that I have seen who do not contribute technically are essentially superfluous.
BB.3> You assumed that features are rooms and then the only "tasks" BB.3> you mentioned amounted to "add a feature". Pulling wire is BB.3> the equivalent of adding the wiring feature.
No, this was my analogy so I got to choose what constitutes features. Here _only_rooms_ are features and "wiring" is _not_ a feature. This reflects the common situation in which a customer wants to organize things in his perspective. You missed this point entirely.
And if your manager tries to talk the customer into accepting "wiring" as a feature, then your manager is doing exactly what I say he should do, namely translating features into tasks.
You can say my analogy as inept, but to critize it merely because it is different from your analogy (as you seem to be doing here) is rather pointless.
BB.3> Stripping a wire or fastening a conduit or connecting a BB.3> box is a task.
It is a task, but not necessarily at the right granular level to be assigned to a team member.
TT.2> So let me try again. Contracting a plumber to do the water TT.2> pipes as well as the wiring conduits is a task, not a TT.2> feature. BB.3> The task is: Hire someone, a plumber, to add a feature, BB.3> plumbing, which is a management task, and every managerBB.3> has the requisite skill. The plumber has the requisite BB.3> skill to break the plumbing feature into necessary tasks.
But plumbing is _not_ a feature in my analogy and my usage of the word "feature", which has been explained:
TT.2> A manager talks features with the customer, tasks with TT.2> his team.
Note that your team member may be a manager himself, in which case the task that you have assigned to him becomes a feature from his perspective. In other words, the plumber that you have contracted might actually be a plumbing contractor who assigns finer tasks to his team members.
BB.3> I disagree that it is necessary for a manager to talk BB.3> tasks with his or her team provided the tech staff have BB.3> the requisite skill to translate tasks completed into an BB.3> accurate fraction of the feature.
You completely miss my point that a customer may not want to organize things in the way you want them organized.
TT.2> There is no fixed relation between features and tasks: TT.2> a feature may requires several tasks, or a task can TT.2> implement several features.
BB.3> I find the latter assertion questionable. What sort of BB.3> task implements several features?
I don't understand your question.
TT.0> Translating featuers to tasks is often non-trivial. Most TT.0> managers lack the necessary skillset and that is often why TT.0> they become managers instead of architects or independent TT.0> consultants.
BB.1> Every manager has the necessary skillset [...]
TT.2> I am not sure why you assume that all managers are competent.
BB.3> I assume only the competence to ask a question. Is that BB.3> too much?
Yes (I think you are assuming too much) based on my experience.
TT.2> Perhaps we have a fundamental disagreement. I think it is TT.2> the manager's job to map features to tasks and to assign tasks TT.2> to team members. BB.3> I would never work for you, nor would I want to work for any BB.3> manager who second guesses my decisions. The only task aBB.3> manager really needs to map to a feature is: implement the BB.3> feature.
I am not sure I would hire you. You don't seem to be willing to entertain the possibility of a difference of terminology (in "feature" and "task") but instead rather quickly conclude that I would be encroaching on your territory.
Tak
--
----------------------------------------------------------------------
Tak To takto_at_alum.mit.eduxx
--------------------------------------------------------------------^^
[taode takto ~{LU5B~}] NB: trim the xx to get my real email addr
Received on Sat Nov 08 2003 - 02:23:34 CST
 |
 |