tgoop.com/reinforced_sc/76
Last Update:
Ещё раз о софт-скиллах
Как вы знаете, я получаю менеджерское образование в Питере. Это серьёзное учебное заведение, без лишнего буллшита дающее хорошие знания кратко и по делу. Рекламировать бренд я тут не буду. Возможно, сделаю это позже.
Так вот. Вы будете смеяться, но именно там мне объяснили откуда взялось требование софт-скиллов в IT. Всё оказалось проще пареной репы. Дело тут в матричной структуре управления. Вот, почитайте про неё подробнее. Именно такая структура наводится в большинстве средних IT-компаний, потому что это единственное что хоть как-то работает. Если в EPAM это всё чётко разведено грамотными консультантами, то там где труба по-ниже а дым по-жиже, слабые матричные структуры создаются естественным путём от сохи руководителями, MBA-ев не кончавшими. Играют, короче, как умеют.
В чём суть матричной структуры? В том, что компания разрезается по горизонтали и по вертикали. Оргструктура получается похожа на таблицу, но это слишком скучное слово, поэтому "матрица".
По вертикали у нас — функциональные направления. Иногда их называют "гильдия". Фронтенд, бекенд, DBA, DevOps, мобильные разработчики. От джунов до сениоров. В грамотно построенной матрице есть руководители функциональных направлений. Условно — самый-главный-фроентендер, самый-главный-девопс ну и так далее. Терминология может разниться, но мы назовём людей наверху "архитектами".
По логике вещей попадает на эту должность гуру направления и его роль сводится к тому, чтобы возиться с людьми, распространять свой опыт (менторство, ревью пулл-реквестов), участвовать на правах консультанта в построении продуктов, уберегая молодых бойцов от граблей и проектировать решения, на что многие кладут писюн.
По горизонтали же компания делится на проекты. У каждого проекта есть свой проектный менеджер (который сейчас в дань моде вытесняется продакт-менеджером). Этот чувак может ни бельмеса не смыслить в разработке. Его задача сводится, грубо говоря, к getting things done. По всем пробежать, всех напрячь, коммуникации скоммуницировать, вопросики порешать, фуру на владик отправить.
И тут теория нас научает: при таком раскладе неизбежны конфликты двойного подчинения.
Шо цэ? Ну смотрите: проекту нужны люди. Их выдёргивают из функциональных подразделений. PM идёт на поклон к архитекту и говорит "дай фронтендера!". И тут случается первый конфликт двойного подчинения. Ответ архитекта по умолчанию — "не дам". Или "бери джунов". Почему? Ну потому что KPI по людям у архитекта такие. Джунам надо опыта добрать, а хороших людей хочется припасти для более важных проектов. А для хорошего архитекта всегда будут более важные проекты чем какая-то дичь, которую тащит PM.
Второй конфликт случается когда разрабы начинают работать над проектом. PM давит со сроками и велит забить на качество, а архитект учил другому. Субъективно разрабу это ощущается как шизофрения руководства. "Што вы? Кто вы? Идите подеритесь уже!" — вполне справедливо думает разраб. На выходе из проекта ситуация тоже турбулентная. Вроде как у человека был PM, он вроде остался в чате, периодически что-то написывает и просит помочь по мелочи, но архитект помогать не велит. А велит, скажем, техдолг разгребать во внутреннем проекте. Снова здорово: "договоритесь уже между собой, ушлёпки!".
Работать это может только при поголовной адекватности всех участвующих. Но написать "не быть мудилой" в вакансии нельзя, поэтому пишут "требуются софт-скиллз".
Проблемы очевидны, но на практике всё как всегда через жопу: низкого качества руководство слабо понимает как тут сработают софт-скиллз, HR с дипломом пед. вуза села Верхняя Пышма тоже не шарит что происходит, а поэтому все дружно не понимают каких людей искать. И то, что в первую очередь хорошие софт-скиллз должны быть у PM-а и архитекта — этого так же никто не разумеет.
Такие дела
BY Novikov on Soapbox
Share with your friend now:
tgoop.com/reinforced_sc/76