Комментарии 60
Мне повезло, я еще ни разу я не жаловался на наличие менеджера. Менеджер избавляет от кучи головняков, которые бы свалились на меня. Я искренне благодарен, что он у нас есть. Коротко о статье:
Когда менеджер – это плохо? Когда менеджер — плохой менеджер.
Когда менеджер – это хорошо? Когда менеджер — хороший менеджер.
Когда менеджер – это плохо? Когда менеджер — плохой менеджер.
Когда менеджер – это хорошо? Когда менеджер — хороший менеджер.
Если бы менеджеры были не нужны то их бы и не было. см. Конкуренция.
Нужны ли программисты в IT?
Программисты бывают плохие и хорошие! Мало кто об этом знает. Плохие программисты в IT не нужны, а хорошие нужны.
Минусы от использования программистов в IT
— Высокая зарплата.
— Могут завалить серьёзный проект на сотни денег.
— Постоянно толпятся возле кофемашины.
— Могут сутками ничего не делать.
Плюсы от использования программистов в IT
— Делают проекты на сотни денег.
— Соблюдают противопожарную технику безопасности.
Брать или не брать программистов в IT решать вам, но во всём мире берут и наверное это правильно. Выводы сделайте сами. Если сможете.
Программисты бывают плохие и хорошие! Мало кто об этом знает. Плохие программисты в IT не нужны, а хорошие нужны.
Минусы от использования программистов в IT
— Высокая зарплата.
— Могут завалить серьёзный проект на сотни денег.
— Постоянно толпятся возле кофемашины.
— Могут сутками ничего не делать.
Плюсы от использования программистов в IT
— Делают проекты на сотни денег.
— Соблюдают противопожарную технику безопасности.
Брать или не брать программистов в IT решать вам, но во всём мире берут и наверное это правильно. Выводы сделайте сами. Если сможете.
НЛО прилетело и опубликовало эту надпись здесь
из 8-и перечисленных пунктов, самый важный, на мой взгляд — пункт 2. очень часто менеджер не может найти золотую середину и начинает либо дергать разработчика слишком часто, не давая сосредоточиться и вгоняя его в стрессовое состояние, либо дает слишком много свободы, и удивляется, когда проходят все мыслимые сроки (хотя тут, конечно, завитсит от разработчика и его мотивации).
пункт 1 немного спорный, мне кажется достаточно пункта 8, т.к. менеджер вряд ли должен (именно «должен», а не «может») разбираться во всех технических тонкостях, хотя это так же было бы неплохо.
пункт 1 немного спорный, мне кажется достаточно пункта 8, т.к. менеджер вряд ли должен (именно «должен», а не «может») разбираться во всех технических тонкостях, хотя это так же было бы неплохо.
>> либо дает слишком много свободы
Как говорит один мой знакомый: «Чтобы разработчики работали, нужно стоять над ними или брать в заложники их детей».
Как говорит один мой знакомый: «Чтобы разработчики работали, нужно стоять над ними или брать в заложники их детей».
разработчика нужно мотивировать, а не запугивать.
Не представляю, как можно работать, когда кто-нибудь стоит над душой.
У вашего знакомого никто не брал в заложники детей? Как он, эффективно сам то работает под таким давлением?
У вашего знакомого никто не брал в заложники детей? Как он, эффективно сам то работает под таким давлением?
Если кто-то возьмет в заложники кого-то из моих родных, то половина строк в получившейся программе будут закладками.
думаю, вы так будете делать до первого аудита :)
Думаете, сынок директора что-нибудь найдет?)
Не, я развивал гипотетическую ситуацию с закладками в коде, написанным под давлением и шантажом захваченной семьи. Те, кто бы так сделал, исходили бы из предпосылки — а) выгоды от дела (ПО) весьма высоки, б) оперирующая команда достаточно сильная и не стеснена ни в каких ресурсах., в) — психологический портрет исполнителя скорее всего был бы составлен до дела, в том числе и реакция на подобный прессинг. А значит — надо проверять (на самом деле, проверять и дважды — обязательно) — и потому ваш код проверял бы второй разработчик (на которого бы давили другим способом) и, как минимум, еще один человек, проверяющий обоих, в ряде случаев мотивирован позитивно (например, большой премией).
В таком случае от идеи давить на меня заложниками отказались бы еще в процессе составления психологического портрета.
Я не могу представить себе человека, который заранее знает, что в коде будут закладки, но предполагает решить эту проблему в дальнейшем с помощью аудита…
Я не могу представить себе человека, который заранее знает, что в коде будут закладки, но предполагает решить эту проблему в дальнейшем с помощью аудита…
Все решения в этих областях (грубо говоря — военные, космос и связанные с безопасностью во всех вариантах) принимаются исходя из ситуации, что исходное решение и/или поведение содержит ошибки.
Ошибка != закладка
Чем профессиональнее программист, тем реже в его коде будут ошибки, но и тем проще ему спрятать закладку, коли потребуется.
Чем профессиональнее программист, тем реже в его коде будут ошибки, но и тем проще ему спрятать закладку, коли потребуется.
ну ошибка тут в самом общем случае: если программа делает еще что-то кроме того что должна и /или имеет возможность влияния на результат, кроме предусмотренного.
Потому и надо проверять :) и перепроверять перекрестным методом, исключая личностные и другие факторы.
Потому и надо проверять :) и перепроверять перекрестным методом, исключая личностные и другие факторы.
А простая перекрестная проверка с целью поиска ошибок и не страшна. Ну найдут парочку, ну и что? Их же еще много осталось. Да и меня обвинить в них нельзя — я же старался. Вон, в коде соседа тоже три ошибки нашел.
Не уверен — нет такого, обвинить нельзя. Будет просто условие, для пример — за каждую найденную закладку -1 орган у рандомного родственника :)
Как они отличат закладку от ошибки? А ошибки делают все, за них наказывать нельзя — в момент вообще без программистов останутся.
Для равного по квалификации разработчика отличить достаточно просто. Так как это совсем разные вещи. к тому же, еще раз — основной поинт — перекладывания на разработчика бремени ответственности за любые неожиданности.
Ну как, кааак это высказывание можно воспринять всерьёз?! Непонятно.
Очень часто менеджеры, дабы оправдать отсутствие каких-либо результатов своей работы, заставляют своих подчиненных рисовать ежедневные отчеты, фиксировать каждый шаг, например, потраченное время на посещение курилки
Вот тут недавно была статья от менеджера — habrahabr.ru/post/218435/
Очень хорошо подходит под ваше описание.
Все же мне кажется менеджера нужно нанимать не со стороны, а выделять человека со временем из уже сколотившейся команды и исходя из определенных критериев (хотя бы даже гугловских).
P.S. очень тяжело найти достойного менеджера с хорошим пониманием IT.
P.S. очень тяжело найти достойного менеджера с хорошим пониманием IT.
Вовсе не гарантировано, что IT-шник будет хорошим менеджером.
Согласен. Как правило такой менеджер будет сильнее погружен в процесс. Его будут связывать не только формальные обязательства. Сплоченность и нацеленность коллектива на результат одно из важнейших составляющих успеха.
У всякой медали есть обратная сторона. В данном случае, этот менеджер будет скорее всего прикрывать некомпетентных сотрудников, если такие окажутся в команде.
Главное ведь результат.
А что, неэффективный член команды никак не влияет на результат?
На мой взгляд, если менеджер полностью справляется со своими обязанностями, то в принципе он может выделять больше времени на ликбез молодого специалиста (не путать с безнадежно глупым) — но это строго его дело. Тем более что большинство фирм не могут себе позволить нанимать только лучших спецов, а значит нужно заниматься обучением и молодых работников.
Если нанимают менеджеров — значит нужны.
Книга «Deadline» — очень неоднозначная. Не устаю всем рекомендовать отзыв Стаса Фомина (belonesox) на эту книгу:
http://lib.custis.ru/Deadline_(Демарко)
http://lib.custis.ru/Deadline_(Демарко)
Сдаётся мне, автор рецензии не уловил основной сути «романа», который хоть и роман, но главным образом об «управлении проектами», то есть это скорее учебная литература, а не художественная, в которой ГГ должен быть суперкрутым, а мир, даже фэнтезийный, подчиняться привычным законам. Сюжет в ней слишком второстепенен и служит лишь элементарной оболочкой для донесения основных тезисов грамотного управления.
Хотя лично мне больше нравится книга «Человеческий фактор: успешные проекты и команды» Демарко и Листера. Там более подробно, хотя и в менее развлекательной форме.
Хотя лично мне больше нравится книга «Человеческий фактор: успешные проекты и команды» Демарко и Листера. Там более подробно, хотя и в менее развлекательной форме.
Проблема «Дедлайна» в том, что «обрамление» не нужно.
Герой записываем умные мысли, не принимает решений, проблемы решаются сами собой.
Т.е., он собственно как таковым управлением не занимается. Ничего не решает. Ну и зачем он тогда нужен? Для чего введён? Что бы был?
Поддержу автора рецензии, почему все считают её «настольной книги» — не понимаю. Упомянутый вами «человеческий фактор» на эту роль подходит гораздо больше — и читается интереснее, и все полезные мысли рассмотрены на примерах и жизненных ситуациях, а не в сферическом вакууме идеальной для героя ситуации.
Герой записываем умные мысли, не принимает решений, проблемы решаются сами собой.
Т.е., он собственно как таковым управлением не занимается. Ничего не решает. Ну и зачем он тогда нужен? Для чего введён? Что бы был?
Поддержу автора рецензии, почему все считают её «настольной книги» — не понимаю. Упомянутый вами «человеческий фактор» на эту роль подходит гораздо больше — и читается интереснее, и все полезные мысли рассмотрены на примерах и жизненных ситуациях, а не в сферическом вакууме идеальной для героя ситуации.
Ни раз сталкивался с тем, что в коллектив приходили менеджеры не только далекие от темы, но и лишенные опыта управления, не умеющие вести диалог. В итоге потихоньку коллектив устранялся, вырастала текучка кадров. Для молодых проектов это большая проблема, ибо вникнуть в процесс, который на этапе становления с ходу получается далеко не у всех. Причиной появления таких «менеджеров» в большинстве случаев было банальное «кумовство». Сталкивался я с этим трижды, причем, как работая в небольшой конторе, так и в одной из крупнейших российских интернет-компаний. Следствием являлось, если и не падение показателей (во многих случаях система была крупной и сбить ее с курса одним ошибочным назначением было тяжело), то стагнация или падение показателей относительно конкурентов.
НЛО прилетело и опубликовало эту надпись здесь
Если нет клиентов, а программисты опытны, мотивированы внутренне самим проектом и дисциплинированны — менеджеры будут либо помехой, либо нахлебниками. Valve, Blizzard и т.п. подтверждают это.
Если есть клиенты, а значит есть неадекватные и жадные клиенты, и плюс работает половина джуниоров, менеджеры необходимы для двух целей:
— быть прослойкой с заказчиком, не забивать программисту голову лишними проблемами;
— держать дисциплину среди джуниоров, среди которых много «звезд, кодивших на асме и сишке», заставлять их слушаться старших товарищей, банально просить сеньоров присмотреть за детишками, т.к. сами девелоперы от такой работы отгораживаются.
Ну и в больших корпорациях 90% работы — рутина рутинная, скучная до невообразимых масштабов. Тогда надо хоть как-то мотивировать программистов на работу левой рукой в перерывах на ютуб; в лучшем случае появляется Гугл, в худшем — mail.ru group.
Если есть клиенты, а значит есть неадекватные и жадные клиенты, и плюс работает половина джуниоров, менеджеры необходимы для двух целей:
— быть прослойкой с заказчиком, не забивать программисту голову лишними проблемами;
— держать дисциплину среди джуниоров, среди которых много «звезд, кодивших на асме и сишке», заставлять их слушаться старших товарищей, банально просить сеньоров присмотреть за детишками, т.к. сами девелоперы от такой работы отгораживаются.
Ну и в больших корпорациях 90% работы — рутина рутинная, скучная до невообразимых масштабов. Тогда надо хоть как-то мотивировать программистов на работу левой рукой в перерывах на ютуб; в лучшем случае появляется Гугл, в худшем — mail.ru group.
Ну уж Valve-то как раз пример крупнейшего затягивания сроков, так что лучше бы там были менеджеры…
Ага, тогда бы и игры выходили наподобие Electronic Arts (FIFA 2001, 2002, 2003,…, 2034)
Ну, кстати, серия FIFA — это как раз тот пример, когда выход игр по расписанию оправдан.
Объясните не-любителю FIFA почему? Что кроме набора и состава команд можно менять каждый год?
все верно. сейчас в новом проекте тим лид/менеджер — все 4 пункта в точку.
Рискую конечно, понимаю что большая часть аудитории — именно разработчики.
Эти 8 пунктов верны, но это к сожалению не всё. Все что в этих пунктах — не так уж сложно повторить. И все это работает пока не случится какая-нибудь серьезная проблема, требующая решительных действий. И здесь менеджер должен уметь делать ряд неприятных вещей:
1. Увольнять сотрудников, если это необходимо.
2. Вводить в команде непопулярные но необходимые меры. Но так, чтобы все не разбежались.
3. Эффективно отдуваться перед командой за негативные решения вышестоящего руководства.
4. Наказывать за реальные косяки.
По себе могу сказать, что не все эти пункты смог освоить, когда превратился из менеджера в программиста. А первые 8 — да без проблем :)
Эти 8 пунктов верны, но это к сожалению не всё. Все что в этих пунктах — не так уж сложно повторить. И все это работает пока не случится какая-нибудь серьезная проблема, требующая решительных действий. И здесь менеджер должен уметь делать ряд неприятных вещей:
1. Увольнять сотрудников, если это необходимо.
2. Вводить в команде непопулярные но необходимые меры. Но так, чтобы все не разбежались.
3. Эффективно отдуваться перед командой за негативные решения вышестоящего руководства.
4. Наказывать за реальные косяки.
По себе могу сказать, что не все эти пункты смог освоить, когда превратился из менеджера в программиста. А первые 8 — да без проблем :)
Мне наверное не везет, я еще не разу не видел хорошего (понимающего что да как) проект менеджера, вечно далекие от IT. Вернее когда он более менее набирался опыта, не выдерживал рабочего хауса и увольнялся. Как и сейчас происходит замечательная компания, интересный проект, но тупые проект менеджеры(парень — отсутствие тех.знаний но хорошо говорит и девушка бывший прогер как собака все понимает но сказать нечего не может )
был проведен небольшой опрос на тему: читали ли они книгу “Deadline: роман об управлении проектами”Вполне возможно что и повезло той компании! Это все совсем не об управлении проектами. А о коллективах людей, работающих головой. Причем спорные утверждения. Заказчик проекта (не продукта) — бизнес, поэтому ему требуются не человеко-месяцы, а деньги.
Именно превращение работы в деньги — задача менеджеров. Причем наикратчайшим путем. Это сложная работа. И она делается не по романам, а по совсем другим, специфическим знаниям.
Просто у разработчиков часто бывает одно свойство — если они в чем-то разбираются, они бывает думаю что разбираются и в остальном (как детей воспитывать, как управлять другими — об этом можно сказать все люди думают что знают как делать). Кстати я сам разработчик нынче (хотя пм со стажем), в горизонтальной команде, но задачу менеджера вижу в такой организации труда (рабочего места, процесса), чтобы это приводило к достойному вознаграждению. Я люблю получать повышение зп и бонусы, а они в ИТ результат командной работы в большей степени, чем индивидуальной.
Так что посыла статьи «менеджер должен это, и это не должен» я не понимаю. Это какой-то взгляд снизу — «нам должны». Попробуйте стать менеджером — и окажетесь всем должны. И сверху, и снизу, и слева, и справа. Какой там ДеМарко…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нужны ли менеджеры в IT?