Пользователь
0,0
рейтинг
2 июля 2012 в 11:44

Управление → От инженера до руководителя. Часть 1: Чувство справедливости

Работая продолжительное время инженером-программистом, я собирал помимо опыта и знаний ещё недовольство и замечания к рабочему процессу и начальству в частности. Каждый раз, когда я сталкивался с проблемой, я думал над тем, как мог бы я её решить и что я могу сделать в этой ситуации. Что-то удавалось сделать, а что-то разбивалось об процесс и руководящий аппарат. И каждый раз проблема и её решения откладывались мной, с осознанием того, что если бы у меня были нужные рычаги, уж тогда-то я смог бы изменить и сделать так, как правильно. Я даже сформировал ментальную систему, которую, впрочем, поленился формализовать на бумаге. Царящая вокруг меня несправедливость была для меня хоть и сокрытым, но комком в горле, превращающимся в камень на душе. Я ожидал шанса и возможности всё накопленное реализовать и поправить, и однажды возможность подвернулась.

Будьте осторожны в своих желаниях — они сбываются!



Так и случилось, что мне предложили нежданно-негаданно руководящую должность, оценившую мои таланты и навыки и позволяющую реализовать свои амбиции. Беседа с менеджером закончилась в лучших традициях “Ты теперь начальник — управляй”. И теперь мне предстояло воплощать в себе лучезарный и кристально-чистый светоч справедливости и делать людей счастливыми, нести слово и байт людям. Однако, почти сразу же оказалось, что это несколько сложнее, чем мне казалось ранее, что угол зрения на проблемы снизу и сверху несколько различается, и родной код оказался приветливее громадины проблем и забот. Поэтому сейчас я решил наконец-то оформить свои догмы на бумаге от лица исполнителя и с призмы начальника. Вряд ли я скажу что-то новое, кроме того, что уже до меня написано в хороших книгах, за исключением примеров из практики и шуток с прибаутками, поэтому либо пролистывайте сразу, либо добро пожаловать под кат.

Во-первых, начну с того, чтобы что-то делать и чего-то добиться надо знать, хотеть и делать. Недостаточно кивнуть на удачу или принцип Питера: “В иерархической системе любой работник поднимается до уровня своей некомпетентности”. Хотя и такое случается чаще, чем хотелось бы природной программистской справедливости. Надо знать больше, чем того требует принцип, чем даёт обладание бумажкой диплома, чем видимое с вашей точки зрения участие в рабочем процессе. Будучи рядовым сотрудником я интересовался, как делают ЭТО системные архитекторы и менеджеры проектов, как всё связано и как работает, и зачем, чёрт подери, я пишу код. Нет, я конечно абстрактно понимал, что мой софт запишут в память контроллера, а за контроллер заказчик отдаст деньги. Но помимо моего кода было ещё было много всего остального, зачастую, как мне казалось, ненужного (а иногда так оно и было), и мне жизненно важно было понять суть и цель той миссии, справедливости, что я несу сам во имя Луны.



У программистов, разработчиков обострённое чувство справедливости. Если его нет, то этот специалист — плохой. Не имейте с ним дело и не надейтесь на него. Хорошие программисты не идут на компромиссы до той поры, пока не посчитают решение справедливым. Поэтому одна из наиважнейших мотиваций — это святая цель, управление целью. Хорошим примером могут служить примеры Apple с его пацифизмом или Google с его свободой для сотрудников. Хорошими примером является так же выступление против “зла” в лице других компаний. Имея цель, как в рабочем процессе, так и на уровне компании легче определить возможности и ресурсы, которые исполнитель будет использовать для своих действий, он будет в конечном итоге понимать, зачем и для чего он работает, и что его отловленный баг не будет больше летать в воздухе, где-то усевшись в контроллере управления самолётом, с сотней ничего об этом не подозревающих людей, потому что его компания, допустим, высшей целью поставила жизни людей. Разработчик, имея свои идеалы и мерила справедливости никогда не пойдёт в компанию, которая убивает морских котиков или распиливает бюджет на латание ям, если это будет противоречить его идеалам. Для него будет критичен стиль кода (нет, только не индийский код!), количество печенья (не допустите, чтобы кому-то не досталось!), вид из окна (у начальника на реку, а у программистов на кирпичную стену) и шум в офисе (менеджеры всегда болтают вместо работы). С точки зрения других участников процесса разработчик может быть и не всегда прав, но у него есть свои святые цели, догмы, нарушение которых куда страшнее, чем, например, оплата труда.

Это очень важный момент, оплата труда разработчика должна быть такой, чтобы он не думал о своих заботах и не искал урывками как бы заработать деньги. И его успехи не нуждаются в подтверждениях в виде премий. Он работает на цель, за свою справедливость, но не за поощрение. Вскормив разработчика с руки вы рискуете просто разрушить отличного специалиста, который мог бы гореть на своём месте куда дольше, озаряя своими идеями весь рабочий процесс. Однако если разработчик ставит во главе угла деньги, и регулярно ходит просить у босса премий — это признак проблемы. С человеком или процессом. Была допущена ошибка, от которой нет обратного хода, но, с точки зрения процесса и управления есть возможность на других сотрудниках избежать подобной проблемы в будущем.

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

Возможно, с точки зрения читателя, вы можете сказать, что сам виноват, что же я сам этого не сделал? Что же я пахал на “того парня”? Если многие могут читать башорг на рабочем месте и сохранять видимость работы, то мне, листающему мануалы и пишущему код Qt (допустим) за место ассемблера это сделать было тяжело, опять-таки в силу обострённого чувства справедливости — обманывать начальство? Да и заниматься чем-то другим на работе не приветствуется нигде, а уж тем более иметь side-проекты. Это ещё одна из ошибок руководства — не обучать сотрудников. Вторым важным качеством разработчика является обучаемость. Мы, люди связанные с IT, находимся в перманентном состоянии изучения и совершенствования. Нам мало оттачивать навыки, и интересно написать hello world на brainfuck’e, тетрис на Haskel и много чего такого, что от нас не просят. Нам интересно изучать новое. И когда я спрашивал руководство “А бывают ли у вас тренинги, семинары?” — мне отвечали отрицательно. Они не всегда могут быть связаны с работой, что могло бы приносить риски и потери ресурсов со стороны работодателя, но положительным было бы расширение моей сферы знаний и влияния, обмен опытом с другими программистами, знание новинок в моей сфере. И нечего удивляться, что частой забавой для нас было написание нечитаемого кода, либо красивого, либо сверхбыстрого и низкоуровнего, где происходила битва за каждый не байт, а бит и за каждый такт. Что, в конечном итоге, хотя и не противоречило внутренним стандартам, но вызывало недовольство руководства: код становился человеко-зависимым. Нужда в нас восполняла несправедливость.

Это в Google сотрудник имеет право 20% своего времени заниматься своими проектами, при возможности их внедрить в будущем, т.е. проявить инициативу. На практике это почти всегда не так. Более того, рутина обычно преобладает перед интересными задачами, и отсутствие сайд-проектов губительно так же для атмосферы и мотивации разработчиков. Тем не менее, убить мотивацию разработчика очень сложно, и его идеи и движения рано или поздно доходят до руководства. Не все из них полезны, конечно, но ни одна из них, как правило, не бывает вредна (если, конечно, специалист не обрушил целый build последним commit’ом с сумасбродной и неодобренной фичей). Тем не менее, жестоким ударом по нему будет выкидывание результатов в мусор. Например такое, какое уж никаким образом не должно касаться всей архитектуры и последующих итераций\тестирования. Как пример, могу привести чисто эстетическое вылизывание кода, табуляций, опечаток в комментариях (помимо новой написанной функции), или дополнение unit-test’ов до MC\DC. Совершенно очевидно, что функционально такие изменения не изменят ничего, просто приведут к тому, что в обновление вместо одного участка кода попадут другие, и в целом изменения будут больше ожидаемых. Проблема: результат инициативы будет выброшен в мусор. При том, что это не является нарушением или косяком в рабочем процессе. Или обратная сторона — нововведение (фича, рабочий процесс, тулза) будет принята не под автором идеи, а под именем другого сотрудника или промежуточного начальника. С одной стороны, это может быть расценено как вопиющее воровство, а с другой как сигнал к недоверию к сотруднику, что куда хуже повлияет на его собственную оценку.

Помимо всего прочего, важным является так же протекция и сплочённость команды разработчиков. Протекция значит следующий факт, что всё сыплющееся на разработчика сверху — бухгалтерская отчётность, митинги, спринты SCRUM (если процесс не налажен), инвентаризация, техническая оснащенность, возможность участвовать в жизни компании, должно фильтроваться буфером в лице руководителей и менеджмента. У разработчиков особая парадигма жизни, особая экосистема, в которую запускать что-то непонятное очень рисковано. Их, держащих в голове огромную модель, взаимосвязи проекта и кода нельзя отвлекать по “пустякам”, иначе всё начинает рушиться, как карточный домик, а надежда возобновить рабочий процесс становится шалтаем-болтаем, которого, в последствие, надо будет собирать всем персоналом всей компании. Но наряду с этим важно отметить, что участие в жизни компании — это не просто способ увидеть светлую цель, но и почувствовать свою важность. Самой часто распространённой проблемой является посыл “вы денег не зарабатываете”. Люди IT тратят деньги, при этом ничего не производя. А отдел продаж зарабатывает. Продаёт. Поддержка работает с клиентами. Это высказывание — маячок огромной системной проблемы, когда даже в распределённом концерне роль IT-персонала является “убыточной”, хотя, как правило, автоматизация и проекты одной команды разработчиков могут приносить тысячи и миллионы единиц товара на продажу. Особенно плохо дело обстоит с отделами инфраструктуры IT, особенно если они работают хорошо (а не постоянно перетягивают кабели) и с тестированием (код написан!). Такое отношение хотя и порождает защитную реакцию “тупые продажные женщины”, но самое главное, ведёт зачастую к пренебрежению винтиком-разработчиком, на котором держится весь концерн (и конечная прибыль в итоге): в бытовом плане — в стульях второго сорта, в возможности сэкономить (они не жалуются, кому? с людьми же не работают), обрезать бюджет на печенье или мобильную связь, оставив в чёрном лесу на съедение волкам, если несчастному программисту посчастливилось ехать в командировку на объект через тёмные леса.

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

Сплочённость команды — очень важная вещь, и её как-то облечить в форму управления очень сложно. Сплочённость — это способность команды идти в одной упряжке и взаимодополнять друг друга, иметь общие интересы, не выделяя “худших и лучших”. Я уже сказал выше, что цели и задания не должны пересекаться, не должна появляться конкуренция и соперничество между людьми. Рейтинги, поощрения, морковки и печеньки, особенно печеньки для избранных — это тёмная сторона зла. И не меньшее зло — сам коллектив. Разработчик приходит к себе на работу с желанием быть понятым и принятым. И важными являются точки соприкосновения. Зачастую точки соприкосновения образуют подгруппы, группы по интересам. В любом обществе это нормально, но неприемлемо в рабочем процессе. Что же я хуже, в самом деле, что я не вхожу в эту группу любителей покерфейсов? Проблема, когда стержень группы просто расходится со стержнем человека. Например каждодневное обсуждение новостных порталов или нелюбимого вида спорта будет вызывать недовольство. Просто потому что человек не читает желтые новости и не смотрит увлекательное пинание ядер левым мизинцем. Далее объединение в такие сообщества попросту вызовет междоусобные сборы и протекцию, продвижение одних над другими. В обычном обществе — это проблемы общения, но в техническом обществе, в среде IT, как плохо владеющими коммуникационными навыками, такая проблема может носить терминальный характер. Более того, это повод задуматься, если один из сотрудников изучает мануалы, читает тематические ресурсы, и подходя к коллегам с желанием поделиться “я тут такой фреймворк нашёл” слышит в ответ “что ерунда, нам это не интересно”. Это повод задуматься разработчику — а туда ли он вообще пришёл? И повод задуматься руководству о сотрудниках: а тем ли они заняты и нужные ли это люди? Умение решать проблемы и задачи без интереса в профессиональном плане — признак гниения процесса и команды. Поэтому заинтересованность — третье важное качество разработчика.

Все эти проблемы выливаются в чувство несправедливости и неправильности. Процесса, людей, всего, что окружает человека. И именно с этими факторами мне, как руководителю предстояло бороться и не повторять прежних ошибок.

Для этого можно составить итоговый список по всему, что я перечислил выше:

  1. быть рассудительным и видеть точку зрения разработчика;
  2. быть открытым для обратной связи;
  3. иметь авторитет человека, знающего тематику;
  4. развивать людей без боязни, что они уйдут;
  5. доверять и делегировать управление;
  6. не давать обещаний, которые нельзя выполнить;
  7. управлять командой и подбором людей;
  8. выработать цель и ценности;
  9. иметь открытый и ясный процесс;
  10. защищать интересы команды в первую очередь.


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

Об остальных проблемах, опыте и деталях мы поговорим в следующий раз.
Верещагин Илья @wwakabobik
карма
138,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (52)

  • +15
    Эта статья просто обязана стать «топиком добра»
  • +10
    This thread need more Magic!
  • +18
    Продолжайте эту тему. Ваши «мысли вслух» достаточно интересно читать.
  • +7
    Сам, проходил такой путь :), было желание создать рай в отдельно взятой компании — получилось, только если это большая компания и для нее IT это новомодная (инновационная) игрушка (направление), где цитата «ничего посчитать нельзя, соответственно все потраченные деньги — это расходы на перспективу и их считать не надо. Условно решили, что это не будет больше 1-2% от маржинальной прибыли компании»

    А если Вы с такими взглядами начнете строить свой бизнес (на что я сам напоролся) — то вы узнаете, что в бизнесе действуют другие законы и вот тут нужно уже балансировать на стороне командного духа и бизнес-эффективности, при этом нужно стараться не вылететь с рынка :)

    Это уже другая история.
    • +5
      Да, мой взгляд и опыт актуален для большой компании.

      Но в целом, лейтмотив — это человеческие отношения, а не использование человекосил как ресурса, чем любят грешить менеджеры со стороны. Стараюсь мыслить позитивно, и надеяться на оптимизм даже в рамках жестокого бизнеса. И, безусловно, если покопаться и изучить все новые проблемы, то снова будет сдвиг взглядов и отношения.

      Не поймите меня не правильно, я согласен с вами, что не всё легко и гладко и бизнес-эффективность тут выходит на первый план. Но, всё-таки, это больше пособие о «хорошем» со стороны как исполнителей, так и руководителей, ведь 2\3 своей жизни мы проводим на работе, и она должна быть не только источником материального дохода, но и источником радости. По крайней мере, надо к этому стремиться начиная с самого низкого уровня и кончая стратегией компании. Так жизнь должна стать лучше — в зависимости от нашего вклада, как бы это избито и наивно не звучало.
      • +4
        Я только — за, все должно быть положительным :)
        Если на работу бежишь и не важно кто ты менеджер или разработчик, значит климат системы сделан правильно и ты показываешь производительность на 150%.

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

        А так же есть интересная статья "Управление без управления"
  • +5
    Очень интересно и занимательно. Особенно потому что я простой разработчик, но к рабочему процессу тоже присматриваюсь.
  • +7
    > Никогда, ни при каких обстоятельствах не давайте повод разработчикам делать чужую работу даже по их инициативе

    Ё-маё!!! А я-то думаю — чего это все мои предложения "… а давайте я это проверю...", "… а давайте я это пересчитаю...", "… а давайте я сделаю вот это, все равно сервер не занят..." натыкаются на бетонную стену непонимания :)
    • +3
      Не всегда начальник — дурак, как оказывается. И можно покопать дальше, чтобы найти другие, неочевидные и непопулярные методы, которые в итоге должны оказаться хитрыми решениями. Всё-таки опыт — результат проб и ошибок.
      • +4
        Я вас услышал.
        И буду думать эту мысль.
        Прямо сейчас я не могу с ней согласиться — ведь я все время считал, что только выполнением своей работы могу чего-то большего добиться. Под «своей» же работой всегда подспудно понимал не только мои таски, но и то, что находится в непосредственной близости.
        Не видел (до сегодняшнего дня) ничего предосудительного в том, что программист некоей программы (то бишь я) будет следить за тем, как делается сайт этой программы, как распространяется эта программа, как работает саппорт с юзерами этой программы, как художник видит работу этой программы и как менеджеры решают вопросы о будущем этой программы.
        Может быть я неправильно понял вашу мысль? В идеальной ситуации действительно програмист не должен вмешиваться в работу верстальщика, а девочка из саппорта может ответить на любой вопрос любого пользователя.
        • +2
          Так «следить» за процессом, спрашивать, высказывать своё мнение — это одно; а выполнять работу других, пусть даже ваших коллег-программистов — разные вещи.

          Грубо говоря, у вас в задачах реализовать классы multiplication, а у ваших коллег — division и root. Так вот делать все скопом математические функции, даже если ваш коллега замешкался с кубическим корнем не следует без должной мотивации с вашей стороны; как и вёрстку сайта за девочку-дизайнера, если вы не собираетесь с ней вместе прийти за ручку и доложить о том, что вы помогли этой девочке и с последующем видите себя вправе выражать своё экспертное мнение, по сути — беря ответственность на себя.

          Как я писал ниже в комментариях, что если у вас есть цель и реакция на вашу активность — без проблем. Главное будьте готовы принять ответное действие, в случае, если результат вас не устроит, чтобы вы впоследствие не опустили рук из-за своей недооценённости или перегруженности.
  • +12
    Ах молодость… Пони, графики, мечты о справедливости :) Жажда денег и комфорта к сожалению превалирует над всеми этими целями и сплоченностями.
    • +3
      Что ж, естественно, почти что львиная доля мотивации — это финансы и комфорт, социальные пакеты и защищённость. Но всё-таки всем, наверное, хочется помимо дома иметь и любимую работу, коллектив. В конце концов, главное чтобы жажда комфорта и денег в итоге не оказалась ложной, а жизнь не была прожита лишь в погоне за ними.
      • +3
        Жизнь несколько прозаичнее. Жажда комфорта и денег не может оказаться ложной, поскольку это вынужденная мера, а не прихоть. Кушать всем хочется, а еще и семью кормить. Отсюда и меркантильный взгляд на жизнь. Это очень грустный, но и решающий фактор. Предложите сотруднику повышение, с улучшенными условиями труда, большей ЗП, перспективой роста и «сплоченность» эта резвеится как пыль на ветру. Будут конечно фразы «я очень рад что работал с вами» и «я никогда не забуду», но внутри он уже будет грезить новым местом. Если это не клинический случай, конечно.
        • +4
          Безусловно. Однако имея почти одинаковые условия, но имея на одной чаше весов, допустим, разницу в 10% зарплаты и интересный проект с коллективом с другой — шанс выбрать второе при худших материальных условиях для инженера выше. И именно эта разница — кредит доверя и рычаг руководителя, которыми вне материальных ценностей можно управлять и мотивировать сотрудника.
          Вопрос в балансе и пороге.
        • +3
          У материальной стороны, как правило, есть некоторый порог насыщения, после достижения которого ее привлекательность начинает стремительно уползать из ТОП-а приоритетов.
          • +1
            При этом каждый стремится его достичь, правда?
            • +1
              Правда, но только для тех «каждых», кто его еще не достиг.
  • +5
    Иллюстрация заставляет задуматься об инженере-руководителе как о сферическом коне в вакууме. А так очень интересно почитать следующие части.
    • +9
      Вы хотели сказать, сферическом пони в вакууме? ;)
    • +3
      Спасибо. Интересное, кстати сравнение.
      Наверное поломка шаблонов исполнителя будет переводом всей сферичности руководителя к тяговой лошади, на которую могут положиться его подчинённые.
  • +4
    «Это в Google сотрудник имеет право 20% своего времени заниматься своими проектами»

    Ведь это давно отменили, разве нет?

    По теме немного не понял о инициативе разработчика. Понял, что не нужно допускать разработчику выполнять чужую работу, но самому разработчику это ведь будет плюсом? Или лучше воздержаться от этого, скажем, если разработчик искренне преследует цель компании? Спрашиваю со стороны разработчика.
    • +3
      Ответом на ваш вопрос будет: всё зависит от мотивов и целей разработчика.

      Смотрите, получение опыта — это очень хорошо, безусловно. Особенно когда это возможность взяться за новую работу или область. Однако регулярно выполняя «за того парня» такое поведение просто снизит вашу мотивацию. Вначале мотивация «я сделал больше всех\я решил сложную проблему, которую не смог сделать N, я молодец», а затем отношение «а какого я делаю это за других, мне больше всех надо? Мне платят за это?». Можно таким образом попытаться замелькать перед начальником, и если у него есть возможности и если он не дурак, то это должен оценить. А если нет? Сколько вы так планируете проработать? Сколько мириться, что вашу инициативу и ваши старания не оценивают? А сможете ли вы конвертировать ваши усилия на текущей работе в знания, которые вы в последствии сможете использовать?

      Так чтобы сказать, хорошо это или плохо — надо поставить цель. И установить определённый дедлайн, что мы к нему хотим получить от своих стараний. И по достижению не продолжать в том же духе, а действовать. Идти к начальнику\менять работу\организовать своё дело\саботировать работу\постить поняшек.
      • +3
        Спасибо за развернутый ответ. Все понял, цели поставлены, сроки установлены)
    • +3
      «Ведь это давно отменили, разве нет?»

      Нет.
  • +5
    Дорогие мои инженеры, разработчики и девелоперы!
    Не ходите в манагеры, там вам будет плохо!
  • +5
    Рискую быть «обминусованным» но с темой «уникальности людей IT» вы переборщили. Рассмотреть ситуацию с разных сторон всегда интересно, к сожалению так и не увидел разных взглядов на одни и те же проблемы. К сожалению когда то давно у меня ситуация сложилась наоборот, и теперь я смотрю на работу по ту сторону от начальства, забавно так видеть обратную сторону. )
    • +3
      простите за тавтологию, писал отвлекаясь
    • +3
      Что считать уникальностью: те же две руки, две ноги, голова одна. То, что «звёзды» IT не похожи на среднестатистических обитателей офисов — факт. Как фактом будет, например, непохожесть качественных работников научной сферы. Думаю, тут дело в количественном отношении. Люди, имеющие способности к IT не столь привязаны к обычным удовольствиям жизни и набору условий, как те же менеджеры по продажам, для них решающими факторами будет с большей долей вероятности девайс, над которым они работают, а не близость от дома. По крайней мере, до поры до времени.

      >к сожалению так и не увидел разных взглядов на одни и те же проблемы
      Вы про руководителя и рядового разработчика? Я не ставил такой цели, я лишь указал знакомые ошибки и методы управления и корректировку их основываясь на опыте рядового разработчика. Моя позиция здесь — что допущения и упущение во взглядах и тех и других — плохо, её надо избегать.
  • +8
    Мировоззрение разработчика очень точно описано, руководилам читать обязательно
  • +3
    Не структурированно и сумбурно. Но кажется очень и очень правильным.

    Образцом раскрытия этой темы считаю «Peopleware». Этот пост — отличное дополнение.
  • +5
    Когда компания растет и пересекает некую границу, то происходит «отдаление» отдела IT, отдела разработки непосредственно и менеджеров, продажников, а основное — от руководства (продажникам и программистам могло и изначально друг на друга наплевать было, а вот руководство всегда должно понимать и видеть истину). И разработчики, которые, зачастую, находятся в конце производственного процесса или не являются по ощущениям важным звеном (именно по ощущениям) начинают ущемляться, а всем все больше и больше начинает казаться, что IT отдел ничем не занимается.

    Это как хороший админ, который сидит на месте и ничего не делает, а плохой, работает в поте лица (знаю реально примеры, когда у крупных интернет провайдерах проводного интернета увольняли хороших админов, потому что они «ничего не делали», а те, которые постоянно в мыле бегали продолжали работать).
  • +2
    Юхуу! Топик добра! Всем плюсов! :)
    • +3
      И мне?
      • +1
        смотри, точно
  • +2
    > Более того, это повод задуматься, если один из сотрудников изучает мануалы, читает тематические ресурсы, и подходя к коллегам с желанием поделиться “я тут такой фреймворк нашёл” слышит в ответ “что ерунда, нам это не интересно”.
    Про меня.
    Желаю всем интересных разработок и конструктивных идей. И чтобы начальство было прогрессивным и понимало вас.
  • +1
    топик бобра.
  • +1
    Эээх. Ваши бы слова… да нашему руководству в голову…
    Благо прямой начальник в отделе понимающий грамотный мужик… Сам работал как мы, все четко делает.
  • +2
    По данному вопросу были разработаны теории.
    Выглядит вкратце это так:


    source: Мотивация персонала в IT
    • +1
      Пирамида Маслоу. Однако тезис, и не только мой, что она даёт не исчерпывающее объяснение, и для IT-сферы бывает спутанной, и удовлетворение потребности более высокого уровня могут превалировать над низменными. Пусть и в очень ограниченных масштабах.
      • 0
        Пирамида Маслоу во всю пиарится везде — хотя сам Маслоу таки признал её ошибочной. Странно правда?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.