Не могу не процитировать

[metaclass]

Ссылка

Как раз то, что для меня создает основные проблемы при работе последние два года:

Дело в том, что смена деятельности на управление разработкой приводит к внутреннему конфликту -- человек становится ответственным за работу команды с четким осознанием, что он может теперь только советовать, но не решать конкретные технические задачи. Это конфликтует с внутренней установкой на созидание. Немногие осознают сразу, что это на самом деле то же созидание, как и раньше, только инструменты другие, уже не собственные руки и голова, а голова и чужие руки.

Очень сложно сделать так, чтобы эти чужие руки считали, что в их голову не влазят со своими взглядами, а дополняют ими имеющееся видение. Успешный руководитель-технарь становится по сути дела педагогом-водителем, к которому идут за советом и ждут помощи в устранении "того, что мешает творить". Технический опыт при этом имеет огромное значение, так как позволяет коллективу по-прежнему считаться с голосом руководителя как эксперта-коллеги, а не просто на основе подчинения.

И вот с этим у большинства технарей проблемы. Моя текущая теория (подвержденная многолетней практикой, но все же теория) состоит в том, что по-хорошему, у нас никогда не учили и не учат в технических областях работать в команде. Не учат коллективной работе как отдельному явлению, типовым проблемам и возможным решениям. Это глобальная проблема -- не только на постсоветской территории. А если учесть, что успешная разработка сегодня -- это совместный труд множества людей, к тому же географически не всегда находящихся рядом, станет понятно, что такое обучение должно быть частью базового технического образования.

Все это присутствует в хороших педагогических вузах. До определенной степени присутствует на журналистских факультетах с хорошей журналистской школой. Но практически полностью исключено из технического образования.

Я готов закопаться по уши в хаскеле, теории категорий и прочем матане, делать энтерпрайз проекты своими силами по ночам, чтобы избавится от перспективы "согласовывать и управлять несколькими командами разработчиков и заказчиков".

Хотя, если бы была реальная возможность и время набрать разработчиков, обучить их, а потом ими управлять - я бы все таки предпочел этот путь. Просто сейчас получается, что нужно одновременно и продукты делать и разработчиков обучать, это очень тяжело.

Comments

[w00dy.livejournal.com]

+1

Мне такой подход тоже больше нравится, причём от хорошо работает в малых коммандах. Вроде все являются разрабочиками, но тем не менее есть человек за которым всегда остаётся последнее слово и который может решать споры и всё такое.

[mend0za.livejournal.com]

да, пирамидальная структура оправдывает себя полностью только в действительно крупных проектах, все части которого существенно зависят друг от друга.

в случае небольших кусков работы, плоская структура с неформализированной коммуникацией, отлично работает (если конечно исполнители не ложат мужской половой хуй на свою часть ответственности).