Эта статья — не совсем по делу, как любят на Хабре. Она демонстрирует ситуацию, когда программист попробовал посмотреть на общество сквозь призму концепций проектирования систем. А еще эта статья даст простейшее представление о некоторых паттернах тем людям, которые не хотят их изучать, но не прочь узнать, о чем они.
Итак
Довелось мне как-то занимать одну из руководящих должностей в одной не совсем серьезной (совсем не серьезной) организации (не IT). В моем отделе было 9 человек, 5 из них занимались схожей деятельностью, занятие же остальных сложнее назвать похожими — но вместе получался жизнеспособный процесс. Еще у меня были сведения, что грядет объединение моего отдела с другим, и это было все, что я знал об совмещении.
Сразу скажу, что статья шуточная, но, как говорится, в любой шутке есть доля шутки.
Попутно я буду во время написания этой статьи вспоминать, как называются различные ситуации, и записывать их в виде паттернов (вернее, моего скромного их знания). Чтоб было веселее, ведь все любят декомпозицию :)
Начало
Когда я пришел, взаимодействия сущностей как такового не было: при возникновении любых проблем предполагалось обращение ко мне, причем двухстороннее: я, в свою очередь, тоже должен был пинать людей, если они не справлялись (front controller).
Поскольку организация, как я сказал, была несерьезная, я решил, что можно заниматься творчеством того же типа, что и в написанных мною системах — а именно, добиваться того, что бы все работало надежно, без негатива и автоматически (навести там IoC). А главное, хотелось добиться масштабируемости, что бы в отдел могло прийти много новых людей — и структуру менять не пришлось бы (т.к организация на удивление быстро росла).
Первые шаги
Мотивация сотрудников была прямо пропорциональна занимаемой должности; соответственно меньше всего её было у тех специалистов, которых было большинство (те самые 5 человек).
И это было проблемой, потому что вся организация работала по этому принципу и на почти голом энтузиазме. То есть выгода сотрудникам, безусловно, была, но это были не деньги. И любой из участников терял при выходе слишком мало, а найти новых было не так просто. И эти 5 человек об этом догадывались, поэтому случаев невыполнения своих обязанностей было много (25%).
Конечно, первым делом я решил умножить количество сотрудников одного вида занятий, и с трудом нашел еще 2 человек. Дальше, я провел анкетирование с целью выяснить, в какие дни недели каких людей предпочтительнее привлекать к деятельности; и, наконец, поставил себе заместителя. Это был человек, который не очень хорошо выполнял свою работу, но был неплохим организатором и имел авторитет в коллективе. Этим я хотел убить двух зайцев: во-первых, увеличить его мотивацию, подняв его в должности; во-вторых — добавить слой абстракции в структуру, для того что бы он был единственным человеком из этого блока, кто взаимодействовал с людьми (mediator) — потому что я, например, не знал многих специфик их работы и хотел быть понятым без технических подробностей (fasade). Плюс ко всему, я не знал что случится с моим отделом в результате объединения; но хотя бы один целостный блок (в который можно добавлять любое количество сотрудников (open-closed)) у меня был. Он выполнял одну функцию (single responsibility), поэтому я был спокоен за то, что его не реорганизуют и он сохранит свою целостность.
Дальше — больше
А чего же с оставшимися четырьмя? Там ситуация кардинально отличалась: у каждого была своя специфика(1)(что-то, отдаленно напоминающее interface segregation, который я не использовал); хотя они состояли в моем отделе, были вещи, про которые я ничего не знал; а знал руководитель рангом выше. Следовательно я был не единственным их руководителем(2)(multiple inheritance). Они все были девушками(3), я не очень хорошо представлял, как с ними работать и сохранять их мотивацию. Правильнее было, наверное, вообще туда не лезть(ибо они давали меньше сбоев, чем первый блок), но схожие проблемы вынудили меня попытаться применить ту же тактику, что и с первым блоком: я приготовил список позиций, по которым нужны были дополнительные люди и хотел назначить главного по блоку.
Таким образом отдел был бы полностью масштабируемым.
С этими предложениями я пришел на центральное совещание организации.
Финал
К сожалению, мои предложения не были реализованы из-за различий во взглядах. Что ж, им виднее)
Тем не менее, пребывание в этой организации дало мне веселый опыт, который я не рискнул бы повторить в настоящей компании. И это круто)
А как бы вы поступили в данной ситуации?
Комментарии (5)
xDimaRus
03.10.2019 10:03Звучит как выстраивание овер иерархии в маленьком отдельчике и желание закрыться от внешних и внутренних коммуникаций заместителями
SeApps Автор
03.10.2019 10:48Вы правы, на тот момент это было избыточно. Но я понимал, что завтра в отдел могут прийти еще 20 человек — и структуру пришлось бы менять на ходу. Тем более, что сама организация напоминала какой-нибудь стартап — никогда не знаешь, что тебя ждет. Поэтому я перестраховался)
ZaEzzz
Какое-то письмо исповедь менеджера среднего звена. Пытаться вносить изменения не разобравшись как это работает...