Этот вопрос можно считать субъективным (я получил предупреждение) и быть закрытым, но я рискну его, так как мне нужен хороший совет / опыт по этому вопросу.
На странице «О компании» Fog Creek Software , компании, которую основал Джоэл Спольски и которая является генеральным директором, я прочитал следующее :
В 2000 году у основателей Fog Creek, Джоэла Спольски и Майкла Прайора, были проблемы с поиском места для работы, где у программистов были достойные условия труда, и у них была возможность делать отличную работу, без неуклюжих, нетехнических менеджеров. способ. Каждая высокотехнологичная компания утверждала, что хочет иметь хороших программистов, но они не будут вкладывать свои деньги туда, где они говорят.
Все началось с физической среды (десятки ящиков застряли в шумной темной комнате, где продавцы, кричащие по телефону, лишают разработчиков возможности сосредоточиться). Но это намного глубже, чем это. Менеджеры, испуганные переменами, рассматривали любую новую идею как причудливый вирус, который нужно поместить в карантин. Младшие руководители комплекса Наполеона настаивали на том, чтобы дела шли именно так, как вам нужно, или вы уволены. Корпоративная мебель Полиция корчилась в агонии, когда кто-то приклеивал постер к фильму в своей кабинке. Дезорганизация была настолько распространена, что даже если бы идеи были хорошими, было бы невозможно сделать из них продукт. Неопытные менеджеры практиковали наездное управление, отдавая строгие приказы о том, как делать что-то, не оставаясь без присмотра, чтобы увидеть фарсовые результаты своих подвигов.
И что хуже всего, ответственные за MBA-типы считали, что кодирование - это вспомогательная функция, в основном причудливая форма набора текста.
Тупые правда о большинстве современных крупных софтверных компаний! К сожалению, не каждый разработчик так gutsy(или lucky, я могу сказать?), Как Джоэл Спольски! Итак, мой вопрос:
Как лучше всего работать с такими менеджерами, держать их в страхе и при этом выполнять отличную работу?
источник
Ответы:
В то время как разработчики воспринимаются как неосведомленные о проблемах бизнеса, менее технические менеджеры будут смотреть свысока на разработчиков. Разработчики должны изучить бизнес-кейсы и начать вести или предложить улучшения в бизнес-терминах. Как только разработчики и менеджеры говорят на одном языке, все становится проще.
Это так же, как об изменении отношения. Да, всегда будет гм упрямые люди в управлении. Однако создание отношения «мы и они» усиливает это с обеих сторон.
источник
Вариант 1: Станьте менеджером самостоятельно и покажите всем, как все делать правильно. Вы, вероятно, обнаружите, что это не так просто, как думают многие программисты.
Вариант 2: Оставьте и найдите лучшее место для работы. Я считаю, что есть много больших и малых компаний, которые хотя бы знают об этой проблеме и пытаются ее решить. С разной степенью успеха.
источник
Ваша задача - доставить отличную работу. Управление - это вспомогательная функция, ее цель - дать вам возможность выполнять отличную работу - выступать в качестве буфера между вами и клиентами, заинтересованными сторонами, политикой, продажами и т. Д., Устранять препятствия, абстрагироваться от повседневной чуши, которая мешает вам достичь лучших результатов.
Подумайте о диспетчере памяти . Это не босс, который командует вами и вашими программами, скорее, он освобождает вас от рассмотрения всего, что происходит на компьютере, позволяя вам сосредоточиться на том, что важно для вашей программы. Это то, о чем пишет Джоэл, вот как в идеале должны работать менеджеры .
Не все менеджеры идеальны, но вы тоже. Ничего. Если что-то не сумасшедшее, просто смиритесь с этим и сделайте все возможное, игнорируйте то, что вас раздражает, и сконцентрируйтесь на своей работе. Если вы выполняете отличную работу, менеджеры со временем будут уважать вас и больше доверять вам, и вы сможете больше работать по-своему, как только вы продемонстрируете, что можете выполнять отличную работу.
Можно работать в идеальной организации на 70%. Если ваша ситуация действительно плохая, смените работодателя. Но не сдавайся слишком рано; процесс завоевания доверия - убеждения ваших менеджеров и организации ваших способностей - может занять годы.
источник
Удачи с этим. Я основал свою собственную компанию, и это действительно все, что я могу предложить.
Надеемся, что в таких ситуациях инженеры объединяются, и если есть реальная проблема, либо технический менеджер проекта, технический менеджер по продукту, архитектор или ваш собственный менеджер по разработке могут понять сферу вашей работы и не пускать нетехнических людей в вашу группу. путь.
Но это не всегда работает таким образом. Однажды я работал в огромной технологической компании, где менеджер был, предположительно, техническим, и когда разработчики жаловались на непрерывные встречи с 4 разными менеджерами проектов изо дня в день, его ответ был - ОК, так что вы хотите БОЛЬШЕ встреч с руководителями проектов.
Я чувствую, что за последние 10 лет технические «таланты», как и настоящие таланты, были невероятно отодвинуты со стороны бизнеса софтверных организаций, и это проблема для нас в карьере.
Управление высокооплачиваемыми разработчиками с низкооплачиваемыми деловыми людьми похоже на отправку вашей младшей сестры в школу укрощения львов, просто не работает.
Но одно решение, которое я определенно буду принимать, это ложь. Я видел, как действительно хорошие разработчики пытаются отвлечь менеджеров, наполняя их историями, которые технически не имеют оснований, чтобы заставить их уйти. Не делайте этого, если вы делаете, вы продали свою душу, и это хуже, чем иметь дрянную работу.
источник