Comments 29
В статье всё правильно написано, но я думаю, что кто-то вроде руководителя нужен в самом начале для организации бизнеса. И самые успешные руководители — это программисты и люди с системным мышлением — есть много тому примеров. Потому как самые эффективные модели в бизнесе — это когда для определенных идей и целей создается и реализуется система, и потом бизнесом уже управлять не нужно, а лишь оптимизировать и адаптировать систему под новые задачи и цели. Либо если новые задачи и цели кардинально отличаются то нужно создавать или внедрять другую системную модель бизнеса.
Если разложить традиционное «главенство» по полкам ролей и компетенций, то от него ничего не останется. Так зачем нужен такой руководитель?
Это красиво звучит до тех пор, пока всё хорошо. А в случае форс-мажора кто будет решать, что делать? Все финишёры-мотиваторы отработали, как могли (ну или им так кажется), но что-то всё равно пошло не так: сроки срываются, ТЗ не выполняется… «Большой босс с большой зарплатой» в такой ситуации чётко понимает, что исполнителям-то ничего не будет (ну премии лишат), а вот он рискует очень сильно. И начинает разруливать ситуацию: вызвать кого-то сверхурочно? выдать люлей? привлечь аутсорс? надавить личными связями и подвинуть сроки?
В общем, веду к тому, что руководство включает в себя ответственность. А по вашей схеме получается, как у Райкина с костюмом: «Кто шил костюм?!»
UPD: Это, кстати, тоже может быть не руководитель, а кризис-менеджер. Ну, как МЧС.
Есть на свете и нормальные программисты, которые сами решают, что делать с системой, зная стоящие перед ней цели. Если цели ставятся кривые, то они не стесняются, и корректируют их, и всем удается договориться.
А знаете, бывает такая ситуация, когда программист делает что-то для изделия. А изделие — это сложная аппаратно-программная игрушка. И вот если на этапе разработки аппаратной части «специалисты» (инженера-программиста-электроника, к слову, забыли позвать на обсуждение концепций и схемотехники — он впервые «познакомится» с изделием немного позже — в виде сюрприза) сделали её так, что мысль, как к ней писать программную часть с заявленным функционалом теряется в туманной дали (ввиду большой переусложнённости на данной аппаратной части или вообще практической невозможности достичь требуемого функционала на ней), то вот хоть лопни, а убедить переделать (даже если знаете, как) не получится. Почему? Потому что:
1) Уже были потрачены деньги. Хорошие такие деньги. Переделка влетит в копеечку.
2) Уже были потрачены деньги на доработки. Которые по мелочи. Главного они не меняют — см. пункт 1.
3) Начальство не понимает ни в конструировании, ни в электронике, ни в ПО. Но уверено, что его видение правильное, а остальные просто не умеют работать. Кстати, «специалистов» нашло само начальство без вашего участия. Поэтому объяснить, почему программа с полной функциональностью вырождается в неуправляемого монстра не получится. Начальство хочет знать, мы можем отработать прямую ветку без сбоев? Можем? Ну и отлично. Работа системы резервирования (а именно там и кроется источник серьёзных проблем) и тому подобное не столь важна в глазах начальства. А переделка см. пункт 1.
4) Главный начальник любитель чайка-менеджмента. Он предпочитает собирать медальки «за службу и верность», а не организовывать работы. Ответственность же всегда будет спихнута ниже («Они, сволочи, меня подвели!»). И ему за это не будет ничего. А нам будет. :)
:)
Когда этот начальник от нас уволился мы больше двух недель выбрасывали это «добро».
Спасибо за статью.
Егор Бугаенко продвигает идеи
- разработки без руководителей и
- оплату программистов по факту выполнения задач,
т. е. нечто очень похожее на то, что предлагаете Вы в этой и других статьях.
Вы знакомы с его творчеством (например, методологией разработки и проектом автоматизации разработки ПО)? С Вашей точки зрения, может это работать?
При этом не важно — какова форма собственности предприятия или организации, о каком виде деятельности идет речь — от интеллектуальной или административной и до физического труда включительно, и даже какие век и общественный строй на дворе.
Впервые что-то подобное, помнится, я обсуждал со своими старшими друзьями где-то в начале своей трудовой деятельности в самом начале 70-х годов прошлого века. Уверяю вас, что с тех пор в обсуждаемых вопросах принципиально не изменилось ничего.
Хотя, как сами понимаете, детали и «декорации» поменялось радикально.
Скорее всего, выход из данного тупика лежит в области переоценки роли и, главное, прогрессивного характера коллективной работы как таковой. И вероятнее всего, наиболее понятна необходимость такой переоценки станет в первую очередь именно в сфере IT и в программировании, в частности. Действительно, трудно найти более отличную от работы на хлопковой плантации или на конвейере Генри Форда сферу деятельности — а ведь господствующие и сегодня стереотипы о благотворной и прогрессивной роли коллективного труда сформировались именно еще в те времена…
:(
Вы надеетесь, что так и у людей?
Описанные Вами модели являются производными от военной. При усложнении внешних условий, описанные Вами модели устремятся к ней.
Если модель управления слегка отлична от военной, значит собственник организации имеет доход превышающий получение необходимого. Если модель управления мимикрировала от военной к странной — собственник «вздыхает по изысканному» и т.д. Как только у собственника припекает, модель управления избавляется от безумных.
«Не мы такие, жизнь такая»
Хороший (объективный, а не для рекламы книг Лалу) анализ компания с горизонтальным лидерством в статье от 12.12.2018 в «Российской газете». Там, кстати, и про «чисто бирюзовые» российские компании неплохо написано.))
P.S. Когда исполнитель, никогда не имевший своего дела со штатом исполнителей больше 3-5 человек пишет о том, что «руководители — зло и атавизм» — это настолько занятное и весёлое чтение. Спасибо за хорошее настроение)))))
И немного юмора в тему:
…
Про БАМ, раз Вы сами упомянули.)
Я там отработал 10 лет, в основном в БАМтоннельстрое. Как выглядел тоннель на БАМе — естественно, гора, а в ней дыра, рядом — посёлок Тоннельного отряда (организация численностью до 1,5 тыс. человек), с магазином, клубом, школой, стадионом, милицией, баней и т.п. С промзоной — электростациями, мех.цехом, участками Управления механизации, Автобазы, Управления комплектации (отдельные предприятия с базами в других поселках и городах), базами ЖКО и УРС. На ряде самых крупных тоннелей были еще подразделения подрядных организаций — спецшахтуправлений, мехколлон и т.п. Самый маленький поселок — Гоуджекит в лучшие времена доходил до 4-5 тысяч с чадами и домочадцами, самый большой — Северомуйск, до 25 тысяч жителей.
Где-то в 78-м году поступило решение закупить для строительства Северомуйского тоннеля автономный горно-проходческий комплекс американской фирмы Роббинс. Для знакомства с работой которого в Штаты послали группу тоннельщиков, среди которых были мои друзья и родственники. Там их, в том числе, свозили и на реальную рабочую площадку — 3-х киллометровый тоннель на севере Мексики, где аналогичный комлекс эксплуатировался.
Тоннель в Мексике выглядел так — гора, в ней дыра, в дыре горно-проходческий комплекс и рядом с порталом несколько личных трейлеров окрестных фермеров, нанятых и обученных на время строительства тоннеля для работы операторами комплекса в колличестве 16 человек, работавшие посменно вахтовым методом.
Еще пара десятков приезжали на своих и взятых в аренду самосвалах из дома и отвозили породу в отвалы. Всё…
Это я не в критику написанного Вами, а всего-лишь в подтверждение того, что стереотипы в организации труда объективно существуют, и об этом не стоит забывать.)))
При всем уважении к автору, мне кажется, что вам еще есть куда расширять кругозор, хотя бы путем получения опыта работы в разных компаниях(от стартапов до корпорацией) и на разных позициях.
Это ведь уже было на инфостарте. На хабре разрешили перепосты из других мест?
Кровососы. Классификация программиста