Менеджмент. Краткое руководство для начинающих менеджеров и опытных подчиненных

    Современный менеджмент включает в себя целый ряд дисциплин, которые объединяют в себе самые различные функции, от менеджмента рисков до управления ресурсами и маркетинга. Сегодня же мы взглянем на менеджмент проекта в рамках IT-компании в общем, опишем главные функции менеджера (каждая из которых включает тысячи подфункций и еще больше всевозможных задач) и опровергнем несколько устойчивых и вредных мифов. Эта статья для начинающих PMов, а также для тех, кто вырос в менеджера из программиста.

    Контрольный вопрос: чем менеджер отличается от подчиненного? На самом деле, основное отличие – это ответственность за результат. Менеджер отвечает за результат всей команды. На этом фоне ни решение задач, ни зарплата не является основной отличительной чертой между подчиненным и менеджером.

    Теперь поговорим о функциях менеджера. Всего их пять:

    Основная задача менеджера – планирование процесса в целом. Давайте возьмем самое простое: к примеру, начинается какой-то стартап и задача менеджера – спланировать, что должно происходить и в какие сроки. «Когда мне нужно снять офис? Когда мне следует нанять команду? Когда необходимо выполнить ту или иную задачу?» Детальный план определяет полноту и легкость реализации, увязывает организационные вопросы с задачами, которые ставит проект. Насколько правильно вы проранжируете задачи, настолько эффективно вы сможете контролировать течение проекта.

    Следующая функция менеджера – это:

    Грубо говоря, сюда всходит все, кроме людей. Нам нужно позаботиться о рабочих местах, материалах, технике. Любой грамотный менеджер обязан создать все условия для выполнения задачи, в первую очередь позаботиться об элементарном бытовом удобстве рабочего места своих подчиненных. Далее следуют формализация процессов и политик внутри компании, удобство коммуникации с клиентами, которые временами могут вынести мозг самому стойкому программисту, качественно формализованные задачи и разумные сроки их выполнения. Пример показательной организации — знаменитые офисы Google, где все, включая распорядок рабочего дня, призвано сделать человека в офисе более счастливым, чем у себя дома.

    Как показывает практика, качественная организация быта прямо влияет на производительность и настроение в компании, сколько бы человек в ней не насчитывалось, и поэтому не стоит игнорировать потребности коллег. Зачастую выгоднее купить хороший кофе и арендовать комфортный офис, чем искать новых квалифицированных сотрудников и обучать их специфике работы.
    Далее идет:

    — А если у меня есть выбор между одним очень хорошим кандидатом и тремя не очень, но которые вместе выполнят ту же работу, которую обычно выполняет один хороший, но за меньшую сумму. Как я должен поступить в данной ситуации?
    — Все зависит от ваших задач. Если проект длительный, и я беру только одного человека, то в случае его болезни вы сами понимаете, что происходит: его задачи банально некому выполнять. То есть, все зависит от ваших проектов и конкретных задач.
    Из лекции Ивана Печерского (Astound, Web Development Manager)


    Контрольный вопрос: насколько объективным должен быть менеджер при подборе людей в команду?

    На первый взгляд, может показаться, что менеджер должен быть максимально объективным, эдаким перстом справедливости. Ни в коем случае. Забудьте, что такое объективность. Всегда пользуйтесь субъективными критериями при выборе специалистов. Задавайте себе вопрос: «Смогу ли я работать с этим человеком?» или «Насколько долго я смогу с ним работать?». Если вы уже на начальном этапе видите, что вы с человеком, как говорится, на разных волнах, он, вероятно, не нужен вам и вашей команде. Если вы чувствуете, что готовы с ним работать год, два, десять – это отличный выбор.

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

    Если вы пришли в уже существующую команду, в первую очередь узнайте о своих новых коллегах побольше. И не только из технических интервью — поговорите с ними о том, чем они живут, что им нравится, составьте о них взвешенное субъективное мнение. Если вдруг среди ваших подчиненных будут те, с кем у вас явно какие-то «непонятки», формализуйте ваши отношения с самого начала. Договоритесь “на берегу”, пообщавшись искренне и открыто. Скажите человеку, чего вы от него требуете, и чего он может требовать от вас.

    Итак, мы собрали команду, что дальше?

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

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

    Долгосрочное направление — это когда мы наставляем на путь истинный мальчишку-джуниора, планируя через несколько лет увидеть его синиором или, к примеру, архитектором. Здесь мы не можем просто сказать «эй, делай все, чтоб стать архитектором к семнадцатому числу!» Это так не работает. Нужно следить за его прогрессом, давать ему правильные задачи, которые будут его развивать в нужном направлении, предоставляя ему возможности для реализации себя в роли эксперта.

    Последняя функция менеджера – это:

    На этой функции «валятся» все начинающие менеджеры. Мы привыкли, что контроль – это постоянный поводок, тяжелый взгляд Большого брата, поминутные отчеты и другие малоприятные вещи.

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

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

    Краткие комментарии к популярным тезисам о менеджерах и менеджменте:
    1. Менеджер должен заниматься всей работой сам.
    Менеджер может и должен делегировать часть своих задач подчиненным. На самом деле это то, что должен уметь каждый уважающий себя менеджер. Умение построить доверительные отношения в команде, вычислить того, кто хочет расти по менеджерскому пути, и отдать ему часть своей работы — крутой лайфхак для менеджера. Так вы освобождаете часть своего времени, позволяете членам своей команды учиться и расти быстрее, и повышаете собственные шансы карьерного роста — ведь любом случае вас не переведут выше прежде, чем вы подготовите себе замену. Профит.
    2. Менеджер не должен никому доверять.
    Неправильно. Доверие — результат ваших коммуникационных усилий. Организуйте доверительное общение с членами команды и наслаждайтесь благами делегирования задач и уверенностью в том, что все выложатся по максимуму. Не смог — вакансии на «свободная касса!» есть всегда.
    3. Менеджер всегда должен быть объективным.
    Ни менеджер, ни сварщик, ни СЕО не способен быть абсолютно объективным, так как сам является субъектом и подчинен непростым, но объяснимым химическим процессам в собственном организме. Не пытайтесь быть лучше своей природы, человек не бывает объективен на 100 процентов, увы. Постарайтесь выжать максимум из собственной субъективности — подберите идеальную команду, найдите уникальную схему работы со своими персоналом — так есть шанс получить лучший результат, чем если мерить всех по условно «объективной» линейке.
    4. Менеджер всегда защищает свою команду.
    Нет, нет и еще раз нет. Если ваша команда сделала что-то не так, вы должны дать ей это понять, иначе она будет постоянно прикрываться вами. Тут, конечно, как и в любой ситуации, лучшим советчиком будет здравый смысл. Во многих случаях действительно стоит прикрыть команду (если она того стоит, что опять же, зависит от менеджера). Но иногда случается, что правила и сроки оговорены, все в курсе дела, и вот какой-то дятел прощелкал все на свете, и проект валится. Менеджер может создать условия для работы, но увы, он не всегда способен превратить дятла в гения продуктивной разработки. Соответственно, если команда (или отдельные ее части) накосячили — им нужно дать об этом знать и назначить некий «штраф».
    5. Менеджер никогда не должен отступать.
    Менеджер должен объективно оценивать свои силы и силы своей команды, так как отвечать в любом случае ему лично.
    6. Менеджер – самый лучший учитель.
    Менеджеры – плохие учителя. Они требуют результата, и у них обычно нет времени учить. Поэтому не стоит пытаться совместить в себе функции и певца, и жнеца — достаточно будет, если вы сможете хорошо выполнять свои прямые обязанности.

    Полезная литература.
    Управление людьми:
    «Человеческий фактор: успешные проекты и команды» Тимоти Листер, Том ДеМарко
    «22 закона управления людьми» Георгий Огарев

    Управление проектами:
    «Вальсируя с медведями» Тимоти Листер, Том ДеМарко
    «Deadline. Роман об управлении проектами» Том Демарко
    AstoundCommerce
    Компания
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 28

      +2
      «Вырос в менеджера из программиста...» Как-то неполиткорректно получилось. Не понятно еще, кто в кого вырасти должен.
        +9
        «Вырос в менеджера из программиста...»

        Этот подход вообще зачастую является контр-продуктивны. При таком назначении программиста менеджером компания получает два минуса — теряется хороший программист и добавляется плохой менеджер.
          +1
          сам подход — не обязательно. вполне возможно, что программист со временем стал лучше понимать, как создаётся ПО не только с точки зрения технологий. Ему становится интересно улучшать и там, но на позиции программиста это делать не получится. Но вот формулировка «вырос» действительно не очень. Хорошая формулировка «перешел в менеджеры из программистов»
            0
            Вот вы только что добавили в историю нового персонажа, о котором и речи не шло :) Какие-то назначатели тут вообще не нужны, но даже если он и присутствует, который назначил человека на некую позицию вне интересов, склонностей и умений самого человека, можем просто договориться о том, что он или недостаточно компетентен или недобросовестен. Но в посте по большей части о добровольном менеджменте.
              +1
              Несколько вопросов:
              — «Назначатель» — это или управляющий, или директор. или старший менеджер. Кто-то должен же управлять компанией. Я не очень понимаю, как без этого вообще компания может работать? Объясните, пожалуйста.

              — Что такое добровольный менеджмент?
                0
                Я имею ввиду, что назначение не пришло или не приходит извне (от главный менеджеров и т.д.) без всяких к тому предпосылок. Обычно, человек сам берет на себя часть обязанностей менеджера (иногда своего), выполняет какие-то организационные задачи и стремится перейти в должность, собственно, менеджера. Он высказывает свои желания, компания нуждается в менеджере, таким образом его и назначают. Ну или создатели стартапов еще.
                  0
                  Мы, наверное, работает в параллельных вселенных. Ответственный назначается, а не выбирается, так как желающих «поуправлять» обычно много, а способных — практически нет.

                  > Обычно, человек сам берет на себя часть обязанностей менеджера (иногда своего), выполняет какие-то организационные задачи и стремится перейти в должность, собственно, менеджера.

                  Обычно человек добровольно остается допоздна, не для того, чтобы закончить код к дедлайну, а для того, чтобы написать отчет, о котором его никто не просил, или составить план для отдела программистов, о котором его никто не просил? Такой «обычный» человек мне не встречался за 20+ лет работы в IT.

                  > Он высказывает свои желания, компания нуждается в менеджере, таким образом его и назначают.

                  Это, мягко говоря, странно. В реальной жизни, если компания нуждается в менеджере, она его находит извне, не спрашивая у сотрудников, хотят ли они стать менеджерами.
                    0
                    Обычно, в реальной жизни все происходит по-разному, ну а статья — один из многих взглядов на тему. Кроме того, думаю, не только самим менеджерам может быть полезна такая информация. Подчиненным тоже быть проще, когда немного понимаешь, какие процессы там в голове могут происходить у руководства.
                      0
                      Вы видимо работаете в какой-то странной конторе, т.к. в крупных типа mail.ru, yandex, все именно как человек выше написал.
                +1
                Если программист решил переродиться в менеджера и у него не будет такой возможности, то он просто уйдёт из компании, ведь у человека сместились интересы.
                  +5
                  > «Вырос в менеджера из программиста...»
                  > Этот подход вообще зачастую является контр-продуктивны.
                  Пожалуйста, приведите про себя десять примеров того, как программист стал менеджером. Пусть даже в IT. Несложно, правда?
                  А теперь десять примеров того, как менеджер стал программистом. Несложно?

                  > компания получает два минуса — теряется хороший программист и добавляется плохой менеджер
                  Значит, компания дуинг ит вронг.
                  В нормальных компаниях обычно получается сразу три плюса:
                  — не теряется хороший программист,
                  — его лучшие черты перенимаются его подчинёнными,
                  — добавляется неплохой менеджер с глубоким пониманием технической части и бизнес-логики.
                    –3
                    > Пожалуйста, приведите про себя десять примеров того, как программист стал менеджером. Пусть даже в IT. Несложно, правда?

                    Можно и двадцать. Толку то? Хороший программер исключительно редко становится хорошим менеджером.

                    > А теперь десять примеров того, как менеджер стал программистом. Несложно?

                    Зачем? Это две разные профессии.

                    > Значит, компания дуинг ит вронг. В нормальных компаниях обычно получается сразу три плюса:

                    Мы с Вами в параллельных вселенных живем.
                      +1
                      Директор компании, в которой я работаю, несколько лет назад пришел в эту компанию на должность программиста и он отличный менеджер. Больше половины PM, с которыми я работал в прошлом программисты и я не вижу в этом ничего плохого.

                      Где-то упоминалось что когда разработчик становится мидлом — у него два пути — либо расти в сениора, либо в менеджера, потому что на этом этапе он уже разбирается как в технологиях, так и в процессах ведения проекта.
                        0
                        Дело в том, что кроме упомянутых выше больших, успешных и (главное!) частных молодых компаний, которых не так много, существует огромное количество немолодых, полу или целиком государственных фирм (или частных, но ставших такими из государственных, или просто заплывших жиром бюрократизма), где всё, увы, не так хорошо.
                    +2
                    а почему вы решили, что программист был хороший?.. В менеджера может вырасти посредственный программист, которому стало не интересно программировать. Но он обладает достаточной компетенцией и кругозором, чтобы понимать как это вообще должно быть.
                    0
                    Ну это зависит от того, с какой стороны мы ставим этот вопрос. Бывает, что человек сначала работает программистом, а потом, в силу каких-то своих внутренних причин хочет стать менеджером. И не все успевают разобраться в новой деятельности, ко времени, когда нужно в нее окунуться. Опять же, есть талантливые программисты, создатели стартапов, которые умеют делать крутейший продукт, но им сложно справляться с командой из даже 10 человек.
                    +3
                    Я извиняюсь, но я так и не понял, о каком менеджменте идет речь? Если об Управлении Проектами (PM), то при чем тут подбор команды и контроль? Проекты зачастую кросс-функциональны и вовлекают в себя участников из различных команд и на разном уровне иерархий.

                    Откуда эти «популярные» тезисы? Из книжек, на которые Вы ссылаетесь? В моей работе ни у одного из моих сотрудников, коллег или подчиненных не возникал в голове такой «популярный тезис».

                    Извините, но какая-то каша с картинками получилась.
                      +2
                      Менеджер должен хорошо руководить и не должен плохо руководить =)
                        0
                        Козьма Прутков отдыхает! :)
                      0
                      Но иногда случается, что правила и сроки оговорены, все в курсе дела, и вот какой-то дятел прощелкал все на свете, и проект валится.

                      совершенно не согласен с этим примером особенно в контексте пункта «Менеджер всегда защищает свою команду» и том, что написано выше про контроль (с этим согласен на 100%). Если 1 «дятел» в команде что-то «прощелкал» и менеджер узнал об этом, когда проект уже завалился — плохой менеджер. Узнал раньше и ничего не сделал — плохой менеджер. Допустил, что персональная ошибка 1 человека в «комманде» привела к краху проекта — плохой менеджер. Но это опять же ИМХО, при чем не ПМа, но человека знающего о процессе разработки ПО не по слухам.
                        +2
                        По статье сразу видно что бывает когда мэнеджеры вырастают из программистов.
                        Когда же они вырастают из инженеров, то подход выражается куда как более системно. Собственно Арни Файоль уже лет 100 как сформулировал основные принципы:
                        Предвидение
                        Организация
                        Распорядительство
                        Координация
                        Контроль
                        На этом базисе построен весь западные мэнеджмент вообще.
                        Зачем изобретать велосипед, когда он уже есть?
                          0
                          Не нашел в статье про ситуации когда количество менеджеров над разработчиками зашкаливает, и некоторые из них полные бездари.
                            0
                            Так бывает. Вообще, благодатная тема, я бы еще поинтервьюировала наших менеджеров и написала пост, если интересно.
                            0
                            Комментарий по поводу: «Менеджер всегда защищает свою команду».
                            Так вот, это золотое правило. Если менеджер не защищает свою команду перед вышестоящим руководством, то он не менеджер. Есть проект или операционная деятельность за которые несет ответственность менеджер. И только он несет всю полноту ответственности. Кто-то нарушает правила и срывает сроки? А что в это время делал менеджер? Ничего? Значит он виноват. А придти к руководству и сказать: «Я все правильно делал, а вот Вася сроки сорвал и он поэтому редиска», это за гранью здравого смысла.
                            Еще раз. Менеджер всегда защищает свою команду! Но это не значит, что нельзя ругать своих подчиненных. Можно (желательно один на один). Это не значит, что нельзя своих подчиненных наказывать. Можно (и вот здесь как раз нужен упоминаемый вами здравый смысл). Это не значит что нельзя увольнять подчиненных. Можно (помня, что у вас есть сроки и вам придется выделять ресурсы на поиск нового сотрудника и введение его в проект/операционную деятельность). Но перед вышестоящим руководством всегда несет ответственность только менеджер.
                              0
                              Но перед вышестоящим руководством всегда несет ответственность только менеджер.

                              Как-то это интересно, и звучит почти как про футбол. Когда при неудачах команды меняют тренера (проще ведь 1-го поменять, чем 20, так же?).

                              Давайте определимся за что несет ответственность менеджер. За провал проекта в целом — да. За конкретные баги — нет. За срыв сроков проекта — да, за срыв сроков по задаче/задачам исполнителя — нет. И так далее.
                              Отсюда вывод — менеджер должен держать в курсе всего происходящего на проекте своё вышестоящее руководство, особенно если вопрос рисковый и вне рамок его полномочий (а такое очень, очень часто бывает).

                              Была у меня история. Один паренек постоянно срывал сроки. И заменить его было некем. Что оставалось мне как менеджеру? Правильно, сужать скоуп, менять задачи, цели… передоговариваться. Это искусство. Но это всё равно провал. В конце концов я ушел — понял, что проект изначально провальный в текущих обстоятельствах. Не потому что не захотел нести ответственность, а потому что win-win не выходило. Мораль: менеджер несет ответственность за план и разницу план-факт, за все остальное несут ответственность те, кто непосредственно что-то делает.
                                0
                                Давайте определимся за что несет ответственность менеджер. За провал проекта в целом — да. За конкретные баги — нет. За срыв сроков проекта — да, за срыв сроков по задаче/задачам исполнителя — нет. И так далее.

                                Бинго. Вы сами все рассказали. Моего руководителя не должен интересовать срыв сроков задачи или появление багов. Я эти проблемы должен решать сам со своими подчиненными. За срыв сроков проекта, которые произошли по причине срывов сроков задач, несу ответственность я. Давайте покажу на примере вашей истории.
                                Итак, у нас есть ключевой разработчик (раз заменить его не кем). Мы планируем некий проект и у нас есть два варианта развития событий:
                                1. На старте проекта, в рамках процесса по планированию рисков мы закладываемся на риск: «ключевой разработчик не сможет выполнить весь запланированный на него скоуп задач». Риск достаточно серьезный по последствиям и с достаточно высокой вероятностью, т.к. разработчик может забить, заболеть, уйти в другую организацию. Т.е. с риском надо работать. Планируем мероприятия по снижению вероятности наступления риска и/или снижению его последствий (например, обучаем других сотрудников навыкам нужным для решения таких задач). Также планируем мероприятия позволяющие в случае реализации риска снизить последствия (например, через вышестоящее руководство договариваемся с другим отделом о предоставлении сотрудников для решения этих задач). Ок. Проект начался. Проводим мероприятия по предотвращению риска, при наступлении нежелательного явления — мероприятия по снижению последствий. Информируем руководство о возможных сдвигах графика или о необходимости доп. ресурсов в рамках первоначальной договоренности.
                                2. На старте проекта околачиваем груши. В процессе работы над проектом «контролируем» факт срыва сроков ключевым разработчиком и ничего не делаем. При срыве сроков идем к руководителю и радостно сообщаем: Ваня Петров — редиска, он сорвал все сроки, ну а я ухожу.
                                Как вы не знаю, а я за первый вариант развития событий. А вы?

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

                            Самое читаемое