Все больше и больше теорий советуют embrace constrants, not trying to lift them -- не только Голдратт, у которого главное слово subordinate ("прогнисть под ограничение"), но и 37signals с их философией Get Real -- http://gettingreal.37signals.com/ch03_Embrace_Constraints.php
Очень интересно то, что разные новые тренды организации возникают именно в софтверной индустрии (двумя путями: либо как приемы организации труда самих программистов, либо как приемы организации труда, подсказанные программистами -- так, Голдратт был именно что разработчиком организационного софтвера, когда начал популяризировать свой подход к проблемам организации производства).
Еще интересно, что всякие организационные/административные инновации аккуратно обходят стороной "большие проекты", или вопрос о том, как должна быть устроена "бригада бригад". Можете себе представить Манхэттенский проект (который все чаще и чаще вспоминают комментаторы моего журнала), использующий принципы книжки Getting Real? Масштабируемость (scalability) -- вот хороший тест на различные оргинновации. Мой любимый пример при этом -- компьютер. Какой тип организации нужно иметь, чтобы на выходе ее получился современный компьютер? И не говорите мне "рынок", это будет не вся правда, даже если вы согласитесь учитывать и административные рынки. Недаром авторы Getting Real честно пишут, что область применения их бизнес-философии -- веб-разработки, которые делаются маленькими командами (их самих семеро, начальное число членов команды для версии 1.0 любого веб-проекта они рекомендуют в три человека). Для меня это очень важный пункт: если уж мы и говорим, что организация/администрирование -- это про способы разделения труда, то сразу ставится вопрос о том, среди скольких людей этот труд эффективно делить тем или иным методом, вопрос о мощности метода.
Тем не менее, в книжке четко прослеживается существенный тренд 21 века: преодоление "системного подхода" с его бесконечными списками того, что "абсолютно необходимо учесть" -- лекарства, которое стало главной болезнью конца века 20. В 21 веке все больше и больше говорится о том, что:
а) пойми, что тебе нужно, чтобы быть страстным по этому поводу (пререквизит потока)
б) обеспечь присутствие опыта (собственного, или опытных людей в команде), а затем используй силу интуиции -- исключительно для нахождения ограничений
в) фокусируйся на ограничениях, по одному за один раз: и не для того, чтобы их снять, а для того, чтобы прогнуть все остальное под них.
Выбор того, на что стоит обратить сознательное внимание, и что нужно сейчас делать изо всего, что можно было бы сделать -- единственная интеллектуальная задача, остальное все сводится к "просто труду" (это говорится в GTD Аллена. Вообще, слово getting становится само по себе признаком бестселлера: Getting Things Done Дэвида Аллена, Executives Боссиди и Чарана имеет подзаголовок The Art of Getting Things Done, теперь вот 37 сигналов с их Getting Real).
И все-таки, разные бизнес-философии существенно отличаются по тому, что они предлагают, главным образом в следующих моментах:
-- мультитаскинг сотрудников: убрать или организовать
-- предварительный дизайн: обязателен или вреден (дизайн сам по себе обязателен, но весь вопрос -- делается ли он как отдельный первый этап, или вперемешку с разработкой)
-- процессы (предварительный дизайн -- но уже организационный): помогают или мешают
Дискуссия по книжкам серии "Getting" часто выходит на поток (Flow им.Чиксентмихайи), например http://headrush.typepad.com/creating_passionate_users/2007/01/what_comes_afte.html (и, кстати, обратите внимание, что заявленный в постинге post-agile никак не прописан. Автор честно пишет, что про Поток есть куча литературы, а вот про post-agile как метод разработки он really have no idea. Просто этот метод разработки должен обеспечивать поток, точка. Ну, и XP обеспечивает поток, да и водопадная модель тоже может обеспечивать. А post-agilism указывается в комментах к этому посту его соавтором как слово, специально изобретенное, чтобы люди не застряли надолго в этапе agile, без малейшего представления о том, что бы это могло быть).
Про поток я бы вставил свои две организационные копейки: потоков должно быть три: организационный поток, производственный поток, клиентский поток. Вы должны пробовать:
-- обеспечить проживание потока (в той части, в какой они соприкасаются с вашими продуктами и сервисами) людям клиента путем
-- проживания потока вашими производственниками, что обеспечивается
-- проживанием потока организаторами производства.
Конечно, я при этом разделяю организацию производства (обеспечение того, что люди используют ту или иную бизнес-философию и делят труд между собой в соответствии с этой философией при помощи совместимой с этой философией учетной/коммуникационной системы) и собственно производство. Явное различение этого важно. Далее можно поставить задачу в соответствии с предметом организации/администрирования: как нужно (по)делить работу между людьми, чтобы у каждого участвующего в процессе этой дележки был поток?
Но постановка тройного потока в число явно учитываемых ограничений (не целей!) организации/администрирования -- это интересно. Над этим нужно специально будет подумать.
Этот постинг -- побочный продукт моей подготовки к семинару "Организация деятельности в 21 веке" 19-20 мая (http://www.techinvestlab.ru/semorgact). Думаю, что завтра-послезавтра выложу очередной апдейт программы.