Теперь обратим взгляд на инженеров (умотипа №1, скажем, программистов) со стороны менеджмента (умотипа №0).
- Программисты работают слишком медленно;
- Программисты работают эффективно лишь над одной задачей;
- Программисты могут выполнять каждый только свою фиксированную часть работы;
- Программисты плохо заменяют друг друга;
- Программисты плохо поддаются организации и т.д...
На самом деле эти задачи, в отличие от инструкций, отлично формализуются. Например для описания управления 3-мя программистами эффективным менеджером отлично подойдет старенький язык
GPSS (взято из примера 4).
Код:
SIMULATE
EXP FUNCTION RN1,C12
0,0/.2,.22/.4,.51/.5,.6/.6,.92/.7,1.2/.8,1.61/.9,2.3/.95,3/.99,4.6/.999,6.9/1,1000
GENERATE 30,10
SEIZE PROGRAMMER1
ADVANCE 20,FN$EXP
RELEASE PROGRAMMER1
SPLIT 1,MET1
SEIZE PROGRAMMER2
ADVANCE 10,FN$EXP
RELEASE PROGRAMMER2
TRANSFER ,MET2
MET1 SEIZE PROGRAMMER3
ADVANCE 8,FN$EXP
RELEASE PROGRAMMER3
MET2 ASSEMBLE 2
TERMINATE 1
START 1000
END.
Язык этот предназначен для имитационного моделирования. Смысл очень прост: генерится последовательность т.н. транзактов с определенными параметрами, которые последовательно/параллельно проходят все блоки (операторы) программы.
В нашем случае Спорадический умотип (менеджер) генерит заказы на разработку ПО по экспоненциальному закону в случайные моменты времени в диапазоне [20,40]. ПО разрабатывает сначала PROGRAMMER1, затем параллельно работают PROGRAMMER2 и PROGRAMMER3, каждый над своей частью заказа.
Ответственность за технику лежит на программистах, менеджер обеспечивает заказы и координацию (планы, сроки).
Необходимо отметить, что подобная схема управления используется во многих корпорациях, т.к.:
1. легко формализуема;
2. отлично масштабируется;
3. распределяет ответственность;
4. позволяет эффективно управлять людскими ресурсами (ответ на вопрос "Зачем?" Валерия Шипкова).
5. устойчива, т.к. отлично работает при исполнителях среднего уровня.