Пять причин быть управленцем

    Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.

    Прежде всего хочу заметить, что доктор биологических наук Сергей Савельев в книге «Изменчивость и гениальность» говорит, что мозг каждого человека под что-то создан. Кто-то имеет мозг программиста, кто-то управленца, кто-то обе сферы может осилить. Но обычно талант вынуждает человека делать то, что ему нравится. А к чему он не создан, его радовать не будет, и в это все дело.

    Таким образом, к примеру, есть мозг художника, и он не будет математиком. А математик часто не может писать гениальные стихи, и так далее. Бывают гении, типа Леонардо да Винчи, но это исключение.

    Весь вопрос в том, чтобы освоить азы профессии, и если она нравится — ей и нужно заниматься. Если нет — пробовать себя в чем-то другом.

    Поэтому универсальных советов нет, каждому нужно искать свое дело.

    Это было предисловие, а теперь про плюшки работы управленцем.

    Итак, что в управлении проектами круто.

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

    upd: прекрасная цитата Winter_mute, описывающая мое ощущение.
    Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.

    Это значит, если мы хотим создать автоматизацию договорного отдела, или технической поддержки для обслуживания 10,000 клиентов, то нужна работа команды. В одиночку сделать такое трудно. А делать масштабные проекты мне нравится больше, чем сделать один отчет или одну страничку самому, или даже большой модуль для highload, но пилить его полгода.

    2. Неустареваемость
    Написанная в 80х годах книжка Дедлайн Демарко, а также книга Брукса 70х актуальна и спустя 30-40 лет. Все те же проблемы, и те же решения. При этом едва ли книги по тем технологиям (где-то видел, к примеру, про программинг под Вакс или особенности MS DOS) могут быть актуальны спустя такой срок. То есть вы прокачиваете свои скиллы и они не устаревают. Как там писали классики, дома новы, а предрассудки стары.

    Конечно, тут можно поспорить — освоив с++ в 90х, можно и спустя 20 лет кушать вкусно и с икрой. Но я за последние 7 лет сменил три языка прикладного программирования, три языка web-программинга и кучу мелких технологий. И у каждой свои нюансы, и мелочи, каждая для своих задач. Каждый раз сначала учить, и от этого устал. Хотя общие принципы часто работают везде (SPOT, KISS и тд), вся суть дела часто решается мелочами. А за ними нужно следить.

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

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

    Я занимаюсь автоматизацией внутри компании. У нас проекты — как стартапы, в разных сферах. Автоматизация договоров, продаж, веб-проекты по апартаментам, аггрегатор всех скидок компании, биллинг, автоматизация отдела кадров, сайт по привлечению программистов, и так далее. Такого у меня не было, когда был программистом. Каждый раз новая предметная сфера, новый язык, новые пользователи, новые клиенты, новые сложности.

    Плюс улучшение — раздел нужно сделать посещаемым, разработать метрики оценки эффективности, придумать, как эти метрики достичь… Миллион разных решений, каждый раз новое, и это challenge, который вызывает чувство драйва, кайф от работы.

    4. Бесконечность развития проекта
    Любой проект можно развивать бесконечно. Генерить идеи, делать их, доставлять пользователям, выкатывать новый функционал. Это творчество в чистом виде.

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

    5. Риски и ответственность
    Да, требуется неслабая психика. Много рисков, нельзя списать на дизайнера, что он криво сделал макет, или на железо, что слабый сервер. За все отвечаешь, причем часто люди от тебя независимо заболевают, и так далее. А ты следишь за этим.
    И эта ответственность высоко оплачивается, гораздо выше рядового разработчика.

    Раньше я просто отвечал за проект, и немного за серверную часть. А теперь и обучение сотрудников, и набор, и ранжирование по профессионализму. И как кому перспективы дать, какие интересные задачи. Как посчитать бонусы, как повысить зарплату. Как учесть возможные болезни и отпуски, чтобы и результат был, и сотрудникам было удобно. И так далее.

    То, что описано в исходном посте — бесконечные совещания, или так любые митинги и ретроспективы и тд в Agile методах, есть ИМХО в 90% случаев трата времени разработчиков. Поэтому менеджмент в этом и состоит, по сути дела — в создании для талантливых сотрудников условий для работы. Люди должны четко знать, что делать, и иметь под руками, все что нужно — план работ, перспективы роста, сложные задачи. А расчисткой пути в неизвестное будущее, доведение до конца и миллионом дел занимается проджект, управленец.

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

    Хороших программистов мало, а управленцев — еще меньше.

    Я управляю проектами два года, и только начинающий project manager, по сути дела. В отделе 15 человек, несколько проектных групп. Менеджер среднего звена — управляю теми, кто управляет программистами. При этом напрямую также веду программистов и ряд проектов. До этого три года был ведущим web-программистом, до этого стартапы, своя студия, фриланс и тд.

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

    Всем успехов и с праздниками!
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 250
    • +33
      Понеслась…
      • +114
        В итоге остается 8 причин не быть управленцем
        • НЛО прилетело и опубликовало эту надпись здесь
          • +3
            напишите пост на оставшиеся 8?
          • +27
            Лично меня очень сильно удручает, что в наше время все стараются становится управленцами, а не делать что-либо хорошо, причём это в любой области. И обычно это приводит к подобнычм историям. Потому управленцы конечно нужны, но они должны появлятся там где действительно нужно, а не стремиться становиться управленцем ради повышения зарплаты или там каких-то причин (в этом тезисе я могу заблуждаться, но я вижу это именно так).

            P.S. крайне неверно что у управленцев зарплата больше специалистов, учитывая что их знания не устаревают и не требуют постоянного самосовершенствования оплата их умений должна упираться в какой-то разумный потолок, хехе
            • +2
              1. стараться стать управленцем не нужно, это очень сложно и нужно иметь способности
              как и программистом, потому что типа АЙТИ модно (С)

              согласен, что управленцы должны быть не везде. но я четко обозначил миссию в посте — управленец должен создавать условия для сотрудников, чтобы им ничто не мешало работать результативно. а ЗП, административ, планирование, бонусы, мотивация, управление коммуникациями, управление рисками и кучу других вещей нужно делать, и это менеджер проектов. программист не должен думать об этих «мелочах», но без этих «мелочей» очень трудно. каждый, кто был фрилансером, знает, что такое общение с заказчиками, бухгалтерия и тд -и это должен кто-то делать :)

              2. риски и ответственность, а также уровень профессионализма рулят. и, конечно, экономический эффект от работы.
              если вы — крутой архитектор 100 000 серверов Гугла и управляете как технический лидер подчиненными, ваша ЗП будет не меньше рядового управленца, а в разы больше.

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

              рулят профессионалы. 200 000 строк кода без единой ошибки в Тойоте — я думаю, программеры и архитекторы там тоже намазывают хлеб с икрой, не меньше чем менеджеры проекта.
              • 0
                Проблема не в том, чтобы найти причины стать управленцем, а в том, что реально компетентных управленцев весьма мало и лезет в управленцы очень много шлака. Ибо для того, чтобы стать клевым управленцем большинству требуется прочитать одну клевую книжку от Брукса или Демарко, а чтобы стать всего лишь неплохим программистом нужно перелопатить кучу всего сделать.
                И еще: рулят профессионалы ой как не везде. И где это видано, чтобы начальнег получал зп меньше подчиненного?
                • 0
                  > 200 000 строк кода без единой ошибки

                  Где об этом можно почитать?
              • +8
                Один раз увидев как начальника отдела увозят с инфарктом, спровоцированным сорванным дедлайном, как-то уже не стремишься и к дедлайнам более ответственно относишься.
                • 0
                  Мезапам, бокс, «бойцовские клубы», секс, экстримальные виды спорта, путешествия — есть куча способов снимать напряжение, но да, мезапам — дешевле)
                  Бухать и курить — уже выходит из моды
                • +1
                  Как это ни удивительно, но в некоторых сегментах IT наблюдается именно такая штука. Но при этом таких специалистов стараются держать вне штата — именно как раз по причине кошмарной дороговизны. Например, это консультанты по SAP или iScala
                  • +5
                    не стремиться становиться управленцем ради повышения зарплаты или там каких-то причин
                    Стремиться надо к тому, чего хочется, и мотивация тут не имеет никакого значения. Иначе всю жизнь будешь себя упрекать в якобы упущенных альтернативах.

                    Есть реальная история — знакомый (инженер-метролог) решил что хочет быть радиоведущим. Решил и пошел учиться. Заплатил денег, год учился, покрутился в этой тусовке и понял что не его. А если бы не попробовал — в старости обязательно считал бы что не реализовал свою мечту и всё могло бы быть иначе.

                    • +1
                      по поводу бабла:
                      1. менеджер получает много не потому, что много знает, а потому, что несет большую ответственность и риски
                      2. вы сильно недооцениваете, какое количество навыков и опыта нужно иметь грамотному менеджеру для успешной работы

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

                      p.s. вот несколько мыслей по этому поводу cup-of-brand.ru/170211779
                      • +3
                        Вот объясните мне, как человек с другого берега — какого рода ответственность несёт менеджер? Чем он отвечает, как искупает исправляет свои ошибки?
                        исправил опечатки
                        • +1
                          в случае факапа проекта обычно с коробочкой в сторону выхода идет менеджер а не программист
                          • +3
                            Риск быть уволенным, как кажется, нельзя считать таким уже и негативным риском. Проекты не часто меняются. Раз в году может и пойти поискать другую работу.

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

                              успешный менеджер делает условия для работы, а люди работают сами.
                              и кажется, что он нихрена не делает.

                              НО!

                              как только менеджера нет, то
                              — то кто-то заболел, и остальные без работы неделю, так как зависели от него, и зависимости разруливал менеджер (верстки нет для сайта). как люди умеют договариваться сами, надеюсь, объяснять не надо. редко когда успешно — гении правда могут, не спорю
                              — то оба сотрудника ушли в офис и компания в авралах, все упало, сотрудников чинить нет. не учли риски
                              — программеры ударились в рефакторинг и задержались проект на полгода. он не взлетает — premature optimization. инвесторы в шоке. и программеры потом в шоке, когда проект никому не нужен (см. пост тут про идеальное приложение Архангельского недавно был — 300 штук рублей вложил, и нет успеха. а если бы делал частые релизы — можно было бы вырулить)
                              — и вообще, набрать лучших из лучших. сначала возьми тимлида, которому доверяешь. потом с его помощью набери толковых программеров. короля играет свита
                              — и еще миллион вещей

                              • +2
                                Скорее соглашусь, чем не соглашусь. Со многими но. Грустно всё это — когда программистам нужен кнут для мотивации (и Кнут против premature optimization).

                                По опыту скажу — лучшие проекты (в срок и сверхнадежные) были, когда не было никаких менеджеров. Людей, правда, тоже мало: 1-3. Почему? Потому что хотя бы когда появляется менеджер, он может убить вопросом: «почему ты покрываешь тестами? Нам за это деньги не платят». Или «кто сказал, что покрытие тестами должно быть 100 процентов?».

                                Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).

                                Мотивация у людей сильно растет в случае их личного ощущения причастности и участия в разработке. Всякие аджайлы этому помогают. Чтобы человек не отлынивал, можно, чтобы он сам участвовал в дележе задач. Задачи писать на доске, на стене, возле выхода. Всем видно, кто что делает. Взаимное ревью кода позволяет другим видеть, чем человек занимался, помогает распространять знания о системе (не должно быть — один заболел, от него зависящие бездельничают). ТДД (опять сказал это слово!) позволяет выполнять задачи равномерно, ощущая «на вес» каждый кусок кода — поэтому задачи становятся интересными. Появляется ощущение выполненной работы в любом части проекта.

                                Несколько хороших опытных программистов — и всё будет в порядке. Единственное, что это бывает в стране единорогов.

                                Если программисты ударяются в предварительную оптимизацию — факап — неопытные программисты. Если программисты рефакторят полгода — факап — неправильные программисты. Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.
                                • 0
                                  >Недавно показательная вещь случилась. Говорю: полдня надо еще, чтобы полностью покрыть тестами. Человек, который уж очень хочет забрать код, говорит: «не надо, мы тебе и так доверяем». В итоге нашли баг, который был как раз в том месте, не покрытом тестами. Но они потратили 2 дня на его поиски. (не ТДД, каюсь, но то был проект — взять готовый код, оптимизировать и рефакторить).

                                  если проджект адекватный и есть ведущий программист в группе, то проджект с ведущим это решат
                                  проджект сумеет рассчитать экономический эффект от тестов (очевиден — 0.5 дня против двух * ставки людей за это время + потери необслуженных клиентов) для обоснования времени заказчикам.
                                  а ведущий(=тимлид) будет уверен, что качество ценят, и уверит команду как «свой»

                                  коммуникации рулят.

                                  >Потому что рефакторинг — часть процесса, он должен быть незаметным и проводиться всё время. А если тормознули на полгода, значит говнокодили до этого долго и дошли до точки.

                                  золотые слова!
                                  • 0
                                    Задача менеджера, в том числе, организовать аджайл процесс (а для начала решить будет аджайл, водопад или ещё что). А главное, менеджер знает цели проекта, грубо говоря, выбирает каким пунктом из «быстро, дешево, качественно» можно пренебречь на данном этапе. Да, он может принимать технические решения (типа будет движок на MySQL или CouchDB) ничего не понимая в них, но он принимает решения, выводящие команду из тупиковых ситуаций, когда половина команды за один вариант, а половина за другой, и вместо работы начинают холиварить.

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

                                    помогает распространять знания о системе (не должно быть — один заболел, от него зависящие бездельничают)


                                    Современные системы зачастую используют кучу языков и технологий, в которых одновременно быть экспертом реально только гению. Совместное владение кодом это некий недостижимый идеал. Вернее знать существующий код ещё можно, но быть готовым на лету подхватить разработку в области в которой ты не спеицализируешься без резкого падения скорости и(или) качества сложно, да ещё если эта область тебе не нравится. Живой пример: верстальщик-фронтендер заболел, тебя с серверсайда бросают что-то там допиливать, в принципе ты знаешь, где что у него есть, его код понимаешь, но, например, не знаешь о многообразии плагинов jQuiery и там где он просто взял бы плагин, чутка его подточив, ты начинаешь изобретать велосипед. Изобретаешь-изобретаешь, формально работа идт, потом он выходит, ужасается, стирает нафиг всё что ты написал, и за полчаса прикручивает плагин.
                                    • 0
                                      А я не говорил или не подразумевал, что не будет программиста, за которым последнее слово. Да, такой человек нужен. Но это один из программистов, который кодит наравне. Он не замыкает на себя информационные каналы, не распределяет задачи, не общается единолично с заказчиком так, как будто бы не холопское это дело другим с ним общаться.
                                      Такой человек нужен для того, чтобы его «не было заметно», а только в критической ситуации дать последнее слово. Но и это вообще-то плохо, чаще всего есть более надежные способы, чем доверять чьему-то мнению. Например, при выборе какой-то технологии, какого-то фреймворка или библиотеки, сначала собираются требования-пожелания от коллектива, потом делаются небольшие исследования, возможно замеры, выносятся на обсуждение плюсы и минусы.

                                      Другое дело — менеджер, который считает, что нужно уметь только менеджить (это из статьи про 13 недостатков). Человек, далекий от разработки и особенно не бывший никогда разработчиком, не может физически принимать адекватные решения по поводу технических вещей. Поэтому когда он принимает, то просто полагается на тех, кому он доверяет — но и таких людей изначально выбрать не может, потому что опять же — нет у него критериев для оценки — кто хороший специалист, а кто нет. Бывали такие ситуации из жизни:
                                      — Вы же специалисты, скажите, что вы думаете об этой проблеме?
                                      Рассказывают. Потом такой менеджер говорит:
                                      — Я думаю, что эту проблему надо решать так:…
                                      (т.е. польза от него нулевая. Даже отрицательная. Потому что программисты бы быстрее договорились между собой, не опускаясь в объяснение того, что знает любой программист, и не опускаясь в детали пересказывания заново работы системы).

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

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

                                      Не совсем. Команды нормальные где-то около 4-6 человек (на мой взгляд, исследований таких не читал). Больше людей в одну команду нецелесообразно — и владение кодом тяжелее становится и совещания шумные и кпд низкое. Нижней границы правда нет, может и 1 программист, если справляется с проектом. Команда из 6 опытных программистов может очень многое. Тут смотря что называть серьезным проектом. Не каждая команда пишет эксель или ворд (хотя, думаю, при достаточном времени и 6 человек напишут в реальные сроки). Не каждая команда пишет операционную систему. Для большинства проектов больше людей не нужно. Даже и этих много. Это мое мнение.
                                      Но если всё же случаются проекты, где людей нужно больше, то делятся на такие команды. Каждая команда может успешно делать свой модуль, работать в том же аджайле независимо, иногда договариваясь про API и иногда проводя общие совещания (с другими командами) и есть общий отдел тестирования. Владеть кодом будут люди внутри команды и кодом команды. Этого достаточно, чтобы не быть кому-то незаменимым. Не только ревью кода помогает знать о системе. Можно и успешно меняться местами. Брать разные задачи так, чтобы каждый поучаствовал в каком-то куске.

                                      А с чужим кодом да, будет потеря производительности. Но далеко не катастрофическая, если что-то случится — день два — и человек уже разобрался и может кодить
                                      • 0
                                        Если за ним последнее слово, то он будет распределять задачи так или иначе — задачи, за которые никто не хочет браться, или задачи за которые хотят браться все, или задачи за который один человек хочет взяться, но он работает уже над не менее важной задачей и передавать её не рационально. Заказчики сами зачастую предпочитают общаться с одним человеком, особенно если только один человек из команды может говорить с ними на языке бизнеса этого заказчика.

                                        Замеры, плюсы-минусы, обсуждения и т. п. — это всё хорошо, но должен быть кто-то кто скажет «мы посовещались и я решил».

                                        Не совсем. Команды нормальные где-то около 4-6 человек


                                        Угу, дизайнер, верстальщик, фронтендер, серверсайдер, админ. Да, все они владеют кодом (и не только), да, все они могут какой-то простой баг типа опечатки по-быстрому поправить. Но целесообразно ли админа сажать за оптимизацию вёрстки или дизайнера за кэширование на уровне приложения?

                                        • 0
                                          А с чего вдруг будут такие задачи, за которые никто браться не хочет? Владение кодом то общее. А поэтому с необходимостью кодом меняются. И код пишут по очереди в разных местах. А то еще возьмется за неинтересную задачу кто-то, а потом ревьювить будет тоже всем неинтересно.

                                          Я в таких идеальных коллективах не работал, чтобы и кодом менялись и все были опытные сразу. Хотя в той или иной степени всегда где-то в гибких разработках участвовал. Но люди делятся опытом, рассказывают, что при таком подходе вдруг у всех включается интерес и ответственность. И кого-то подгонять или заставлять делать то, что «неинтересно» не надо. Это нужно проекту? Да. Так почему же это неинтересно? Рутина? Так где-же наши умения ее сокращать? Это тоже интересно.

                                          Задачи любые интересны, если используется какой-то «системных подход» к их решению, ТДД (опять это слово!).
                                          «дизайнер, верстальщик, фронтендер, серверсайдер, админ» — это не из расы программистов. Я про них не говорил. Понятно, что кодом владеют только программисты. По крайней мере править код могут только и только они. А вот, в среде именно программистов — никаких секретов.
                                          • 0
                                            Ошибся в копипасте. фронтендер, серверсайдер — программисты. Лично я против такого деления. И сервер-сайд и фронтэнд — пусть пишут одни и те же люди
                                            • 0
                                              Верстальщик тоже пишет код (html/css) который прямо присутствует в коде проекта, более того фронтендер и серверсайдер непосредственно с этим кодом взаимодействуют. Они втроем правят одни и те же файлы. Они совместно владеют кодом и, как правило, понимают весь код в этих файлах и могут по мелочам поправить код вне зоны своей специализации.

                                              А с чего вдруг будут такие задачи, за которые никто браться не хочет?


                                              Ладно, пускай два программиста с примерно одинаковым бэкграундом, но одному нравится писать модели, реализовывать бизнес-логику, другому нравится визуализировать данные на клиенте, а вот писать контроллеры и прочую логику приложения (аутентификацию и авторизацию, валидацию и санацию, хранение и кэширование и т. п.), не нравится никому. Но без этого никак, все это понимают, но никто делать не хочет.
                                • 0
                                  Если менеджер нифига не понимает в предметной области, значит компания зажала денег на качественного менеджера. В Гугле, например, практически нереально стать продакт менеджером без первоначального диплома в computer science. Не в экономике, а именно в ИТ, потому что откуда иначе ты будешь знать как создавать софтверные продукты?
                                  То же самое в любой другой области, без соответствующего опыта или знаний не возьмут.

                                  А риск быть уволенным и не получить хороших рекомендаций — это большой риск. Потому что на интервью тебя спросят, чем ты раньше занимался и какие были последние проекты. И на каком-нибудь узком рынке найти знакомых знакомых и проверить, не зафакапил ли проекты данный человек — проще простого. Это программиста посадил, он тебе написал код, и дальше особо ходить не надо. А людей на управленческие позиции часто ищут по рекомендациям и проверяют как могут.
                                  • 0
                                    Это программиста посадил, он тебе написал код, и дальше особо ходить не надо


                                    Этого программиста сначала надо найти, которого можно посадит, и он напишет в срок код, который потом не придётся 100 раз переписать. И найти его сложнее чем менеджера, да и без менеджера конечный продукт может иметь место, а без программиста нет, так что мне кажется, что вы очень преувеличиваете роль менеджера в разработке ПО.

                                    А про риски быть уволенным — все сотрудники компании имеют риск быть уволенными без рекоммендаций и у всех достаточно несложно проверить.
                                    • +1
                                      Я речь вела про интервью :) Дал задание, и сразу видно, может человек писать код или нет. Не нужно искать людей через третьи руки, которые с ним работали, чтобы выяснить, правда ли он кодил хорошо.
                                      Да, хорошего специалиста непросто найти, но это можно сказать про специалиста в любой области, их везде мало.

                                      Я не преувеличиваю роль менеджера в разработке ПО, просто надо сравнивать большие проекты, где есть насущная потребность в менеджменте, а не маленькие группы разработчиков, где вполне работает самоорганизация. Проекты, где много хороших программистов, но в результате делается не тот продукт что заказывали, не в те сроки или с трехразовым перерасходом бюджета я видела. Почему-то никто за этот продукт платить не хотел в результате, хотя каждый отдельно взятый программист — душка и зайка (разве что звереет от регулярного общения с клиентом напрямую)).
                                • 0
                                  Спасибо, а как менеджеры исправляют допущенные ошибки?
                                  • 0
                                    Да, я правильно вас понял, что в случае проблем менеджер увольняется, а программисты остаются решать эти проблемы?
                                    • 0
                                      конечно, именно программист решает проеб с логистикой, с ошибкой в договоре, по которому прогнули компанию на деньги, с неправильной маркетинговой стратегией и т.д, кто же еще :)
                                      • 0
                                        Но мы говорим о менеджерах разработки ПО, а не о доставках и продажах
                                        • 0
                                          менеджер по разработке ПО — это кто? Проектный или продуктовый? Вы скорее всего имеете ввиду просто тимлида. Я изначально говорю (и сам являюсь) про продуктового менеджера, который обычно занимается менеджментом всего жизненного цикла продукта.
                                  • +1
                                    я уже приводил выше.

                                    1. если выбрал не ту стратегию — маркетинговую, продажи и ценообразование, не тот интерфейс утвердил, не те user stories И тд — то программист сделал и сдал по ТЗ и свободен.
                                    а бюджет проекта ушел в минуса. и менеджер не получил денег

                                    2. кто-то заболел, кто-то не сдал работу в срок.
                                    опять же, менеджер не получил бонус (часто существенная часть дохода). а человек свою зарплату получил и не парится

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

                                    4. вы овертаймите, потому что очень много параллельных задач плюс неучтенные риски (=тоже ваш косяк)
                                    сотрудники же работают 10-19.

                                    и так далее
                              • +3
                                «Управленческая наделя» на Хабре?

                                Устраиваюсь поудобнее :)
                                • 0
                                  я уже раз 5 порывался ответы написать на такие посты.

                                  сегодня созрел
                                  • +1
                                    и потом, вон, Ашманов. он и бизнесмен, и менеджер проектов, и сам программит круто, как понимаю. читал, что он сам тюнил систему, которая по ТВ шла в прямом эфире, суперхайлоад, будучи менеджером проектов.
                                    • +1
                                      спасибо, очень интересно почитать отзыв действующего управленца довольного своей работой
                                      • 0
                                        пожалуйста.

                                        я учусь только, у меня очень хорошие учителя, настоящие профессионалы. топ-менеджеры, основатель своего дела, крутые управленцы большими коллективами, архитекторы.
                                        в общем-то только благодаря им на 80% развиваюсь :) сам 20% труда вкладываю.
                                  • +6
                                    Ещё раз перечитал расписание: утка про cs2 на этой неделе была, важный технический ресурс закрывался, холивар есть :)
                                    • +1
                                      На мой взгляд, статья, на которую вы отвечаете, была заметно лучше тем, что была ближе к жизни. В ней автор говорил не только об общих вопросах, как здесь, но и ежедневной рутине, которая как раз формирует отношение к профессии.

                                      А есть ли в ежедневной практике вещи, которые вам не нравились, как программисту, и которых нет в менеджерстве?
                                      • +3
                                        я бы мог добавить, но объем вырастет в 2-3 раза.
                                        поленился, буду честен.

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

                                        а бизнес требовал результатов, и разочаровываешься — вроде работает, но неидеально, а улучшить особо некогда. нужно делать новый продукт :)

                                        в управлении я могу варьировать свою нагрузку более плавно, больше свободы. неделю отдыхаем, рефакторим, я тестирую проекты, пишу программы развития отдела. потом впахиваем, делаем релиз, внедряем. потом снова отдых.

                                        2. поднадоело. я как программист чуть выше среднего, брал упорством и трудом.
                                        спустя 10 лет (я программлю с 13, как многие тут) уже не прет от новых языков или задач. был и софт, и базы, и шифраторы я писал, были и дипломы разные за программки прикладные, и за веб-сайты благодарности.

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

                                        условно, я пишу на интуиции. много читал и изучал, и решение задачи выглядит так. долго думаешь, и так и сяк, а потом раз — и готово решение. и оно предсказуемо 100%, заработает, только пиши код 2-3 недели.

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

                                        допускаю, через 10 лет опять буду прогать. не знаю :)
                                        • +4
                                          Так в реальной жизни (читай в бизнесе) нет особо сложных задач. Ну т.е. они с другой стороны не тривиальные, но это скорее от индивидуальности каждой отрасли и компании.

                                          Управлять такими темпами тоже станет скучно. Одни и те же косяки сотрудников, одни и те же совещания. И вроде обсуждаете по теме, а ощущение, что где-то это уже было.

                                          ИМХО никогда не будет скучно только в науке. Тут может попасться задачка, что на всю жизнь хватит и внукам еще останется.
                                          • 0
                                            Мне пока в новинку.
                                            И потом, я занимаюсь автоматизацией внутри компании.
                                            Это, считайте, стартапы в разных сферах. Очень сложно и достаточно интересно.

                                            Недавно делали отдел обучения новичков. Сейчас делаем обучение существующих сотрудников.

                                            Очень круто — можно взять любой проект, отдел, бизнес-процесс и улучшить. Новая сфера, новые знания, новые люди, новые клиенты!
                                          • +2
                                            И кстати, лично я программирую 17 лет (с 8). И как-то не надоело. Даже в каком-то смысле открылось второе дыхание.
                                            • 0
                                              Я, конечно, программлю какие-то куски.

                                              Но их мало. Для себя делаю софт как хобби (редко), есть желание отдать опен-сорс сообществу софт в будущем. Так как линуксоид, и очень много мне дал труд программистов мира.
                                          • 0
                                            Расписал подробнее пункты.
                                        • +6
                                          Ваш оппонент более убедителен. его пост пропитан опытом, а это просто вырезка и вступления к какой нибудь брошюрке курсов для манагеров. Стоило бы получше подготовится, а не бросаться писать опровержение.
                                          • +3
                                            это не опровержение.

                                            кому-то нужно быть программистом, кому-то дизайнером.

                                            зачем художнику рубанок? зачем рабочему акварель?

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

                                          • +20
                                            Вот, сразу видно разницу между настоящим интровертом (много деталей, много связей, в т.ч. между пунктами, все взаимосвязано и довольно подробно) и экстравертом (возмутился другой точке зрения, кратко накидал список атрибутов — не связей — и типо все).

                                            П.с. имхо, если программист перестаёт видеть сложность в своих задачах и абсолютно уверен в том, что напланированная задача будет успешно решена, по-сути, ещё до написания кода — он, скорее всего, засиделся на простых задачах. В общем п.3 несколько притянут за уши.
                                            • +1
                                              я обычно пишу большие посты по управлению (см. блог), с деталями и примерами.

                                              часов 4-5 занимает.

                                              тут задача была сделать прототип поста. может, он не понравится Хабралюдям. и тогда 4-5 часов пойдут под хвост.

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

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

                                                  но в работе эмоционален и экспрессивен. и пою на сцене тоже (это хобби)
                                                  www.youtube.com/watch?v=vGtJgMY0hrg

                                                  так что то ли интроверт, то ли экстраверт, фиг его поймет. «я был посредственный поэт, зато отличный гражданин» (С) в роли Сталина «Гражданин поэт»
                                                  • +1
                                                    У меня примерно так же с контактами вне работы.

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

                                                    К тому же это в равной степени касается как манагера, так и специалиста.

                                                    P.S. Вы потрясающе поете. Огромный респект!
                                                    • 0
                                                      спасибо, стараемся)

                                                      еще учиться. хочется и тут стать профессионалом.
                                                    • 0
                                                      См. Коммент к ветке чуть ниже. Судя по построению речи вы более экстраверт. Неудержимого желания общаться со всеми и постоянно это не будет означать.
                                                      • 0
                                                        ок спс.

                                                        сложно сказать. я бы отметил, что это два режима мышления.

                                                        когда я проектирую систему, сначала я «нормализую» ее. выделяю ключевые сущности, элементы, объекты. что в проекте, что в архитектуре системы (ООП).

                                                        дальше — связи между ними и их состояниями. диаграмма последовательностей в UML, user stories если это в проекте.

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

                                                        это оно?

                                                        • +1
                                                          Как любая абстракция «про людей», в совсем чистом виде ничего не встречается ;) А так да, похоже не правду. Характерной особенностью так же может быть возможность без напряжения помнить обо всем и всех понемногу, не вдаваясь в подробности — но о многом.
                                                          У меня при построении систем наоборот, собственно определить сущности/состояния — самая муторная часть. Зато взаимосвязи строятся разве что не сами, нормализация РБД для меня вообще шоком была «а разве можно делать сначала как-то не так?!»
                                                          • 0
                                                            П.с. вообще это про себя нужно знать для одно важной штуки — как правильно ставить задачи. Экстраверты стремятся к цели, к ещё конкретному достижению, интроверты стремятся просто идти в правильном направлении. Примерно по этой причине хороший менеджер сумеет назвать правильный срок даже если его программисты этот срок назовут довольно расплывчато, а сами программисты такие навыки часто приобретают только с достаточным опытом.
                                                      • +1
                                                        А «глубоко» — это как?
                                                        По Юнгу экстраверт — это человек, который видит состояния и объекты, а интроверт — связи между объектами и состояниями. Скорее ложно понимание интровертов как нелюдимых молчунов, а экстравертов как компанейских людей. Это просто следствия изначального восприятия, статистически удобная форма личности.
                                                        • 0
                                                          А разве по Юнгу не должно быть три измерения — Intravert/Extravert, Intuitive/Sensitive, Thinking/Feeling?
                                                          А потом еще появилась типология Майерса-Бриггс, которая добавила Judging/Perceptive…
                                                          • 0
                                                            Должно быть. Впрочем на тему соционики целиком здесь не вижу смысла заморачиваться — она сама в себе противоречива (тимы по разному воспринимают и, следовательно, оценивают). А вот про экстравертов/интровертов слышали все, да и по значимости это самое фундаментальное «измерение».
                                                    • +2
                                                      Бокс по переписке
                                                      • +7
                                                        В 90-х активно интересовался менеджментом, вплоть до добровольных двух курсов ВО после ухода из техвуза, куда родители «запихали». Но когда понял, что менеджмент это прежде всего работа с людьми, а не экономика, финансы, логистика, трейдинг и прочие формальные (или кажущиеся таковыми :) системы, то решил держаться от него подальше, пока психологию человека не разложат на формулы. Прочитав оба поста обрадовался — всё правильно сделал :)
                                                        • +10
                                                          Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.

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

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

                                                          Хороший руководитель обязан мыслить стратегически и масштабно. Если же единственное, чем занимается менеджер — это подготовкой отчетов и бессмысленной муштрой своих подчиненных — то это не менеджер, это кошмарное недоразумение, которое зря получает свою зарплату.
                                                          • +2
                                                            Мне кажется, что наиболее адекватная мотивация в том, чтобы быть менеджером — это желание сделать нечто такое, что один человек сделать не может в принципе.

                                                            Отличная формулировка, поклон за точность!
                                                            • 0
                                                              Почему-то кажется, что таких менеджеров либо вообще нету, либо их меньше 1% и мне с ними не посчастливилось встретиться.

                                                              Как минимум в нашей стране любая управляющая должность считается заведомо лучше любой другой профессии. Скажем слесарь всегда почему-то хуже бригадира (я немного утрирую, думаю понятно). Поэтому многие хорошие программисты становятся менеджерами (потому что жена пилит, потому что денег больше и т д), а не потому, что <ваша цитата>.
                                                              А потому конечно они будут плакать, что работа сложная, никакой отдачи, то плохо это плохо.

                                                              Ну вот если бы программист мог так же перейти скажем работать терапевтом в поликлинику. Я думаю опять же многие заплакали бы на тему (вот старухи ходят, одно и то же каждый день и т д). А ведь у врачей на самом деле точно такие же крутые задачи есть. И точно такая же текучка, которую кто-то должен делать.

                                                              Люди, меняйте отношение к работе. Работа не для денег, она для души.
                                                              • 0
                                                                Ну мне поднадоело немного программить. При этом я учусь управлять и меня это прет. Одно из — то, что вы написали. Пусть как управленца меня оценивают другие, тут еще вагон и маленькая тележка работы предстоит.

                                                                Я горд своими программистами. Они профессионалы, многие любят работу. И пусть работают, они оживляют проект, собственно, делают много работы, творят, думают. Я же сам программист, понимаю, как это трудно. Зачем им рваться управлять?
                                                                И никакой управленец не работает без команды, рулят профессионалы — исполнители.

                                                                Даешь каждому свое дело по душе!
                                                                • +2
                                                                  Все меняется когда приходит Идея. И ты понимаешь что в одиночку ее не осуществить.

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

                                                                  Я когда впервые занял позицию менеджера, в одном из проектов, и когда через 3 недели мы выдали ощутимый результат… (сам так же занимался программированием частично, но и команду удалось собрать практически идеальную)… Это не описать словами… кайф. Это не просто мотивирует, это фантастично =)
                                                              • 0
                                                                А куда в этой формуле давать «среднее звено»? Такие люди могут любить своё дело, но возможности реализовать собственно свои задумки у них может не быть — есть планы, есть задания вышестоящих. И без них ведь тоже никуда.
                                                                • +1
                                                                  А где вы там нашли «свои задумки», там абстрактное «нечто». Есть задание вышестоящих, которое один человек выполнить не может — типичный вызов медеджеру, сможет ли он организовать процесс так, чтобы задание было выполнено или не сможет, а в идеале выполнено досрочно, меньшими ресурсам, но не в ущерб качеству. Если вы такое задание воспринимаете как вызов, то сочувствую :) — вы менеджер в душе.
                                                                  • 0
                                                                    Мда, видимо плохо соображалось ночью)
                                                                    Воспринимаю так почти все, но чур меня — это просто качество человека, хотя бы старающегося быть ответственным))
                                                                    • +1
                                                                      Не в ответственности дело. Лично для меня вызов написать какой-то сложный модуль, отрефакторить код десятилетней давности, продумать архитектуру или схему БД и т. п.: получится в срок — я крут, не получится — ну облажался, с кем не бывает на сложных задачах. А вот делегировать задачи и ответственность — это для меня просто наказание. Если получится — это сделал не я, а подчиненные, если не получится — облажался я: никакой положительной мотивации в решении таких задач не вижу. Единственный вариант с положительной мотивацией — делать самому работу рассчитанную на, скажем, троих, работая по 16-18 часов в сутки без выходных, но надолго меня в таком режиме не хватает — месяц-другой и если не успел проект закончить, то всё, дедлайн сорван, а если успел то опуск нужен хотя бы дней 10…
                                                                      • +1
                                                                        Насчет сложностей с делегированием, переработками и мотивацией — это все знакомо. ИМХО это все дело привычки и наличия какого-то способа передать ответственность без необходимости убеждать/уговаривать/упрашивать.

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

                                                                        Как только эта привычка к восприятию делегирования сломана — остается все тот же процесс по набиванию скилла — выяснение всяких плюшек и приемов, понимание взаимосвязей и проблемных мест — все наше родное. Детерминированности, конечно, меньше, но, думаю, любой программист встречал баги запредельной для текущего уровня понимания сложности на ровном месте. Принципиальной разницы между этими ситуациями просто не вижу.
                                                                        • 0
                                                                          Никто не спорит, что распараллеливание хорошо. Я тоже делегирую задачи, но директору с формулировкой типа «вот ТЗ на вёрстку, я это буду делать N дней, хороший верстальщик сделает быстрее и тебе дешевле обойдётся» :)
                                                                          • 0
                                                                            Только поиск хорошего верстальщика займет 2^N дней… И не факт что найденный на самом деле окажется хорошим :)
                                                                            • 0
                                                                              Это не моя, как говорится, зона ответственности. Руководству предоставлена информация — пускай оно решает что и как. Решат, что коней нв переправе не меняю и придётся мне верстать с негативным отношением к процессу, да со влиянием того, что я свой уровень врстки оцениваю ниже среднего — мне сложно представить, чтобы кто-то сверстал хуже меня — например я так толком не разобрался в семантике многих новых тегов HTML/
                                                                          • 0
                                                                            «так что любая параллельность хороша, даже если она где-то по началу не супер-эффективна»
                                                                            Очень опасное утверждение.
                                                                            Любое рапараллеливание в проектном менджменте — это дополнительные риски.
                                                                            Далеко не все задачи и далеко не все ресурсы параллелятся.
                                                                          • +2
                                                                            Если получится — это сделал не я, а подчиненные, если не получится — облажался я: никакой положительной мотивации в решении таких задач не вижу.

                                                                            Какая знакомая ситуация. Мне тоже очень сложно получить правильную мотивацию при правильно делегировании задач, поэтому приходится насиловать себя и забирать часть работы (обычно самой сложной, либо принципиальной) себе, чтобы потом иметь хоть какие-то положительные эмоции от выполненной задачи.
                                                                            И как исправить данную ситуацию неизвестно, думаю, только сменой рода деятельности.
                                                                            • 0
                                                                              В теории я решение знаю — нужно воспринимать достижение команды как своё: набрал хорошую команду, правильно распределил задачи, правильно организовал процесс, вовремя раздавал кнуты и пряники и т. п. Ведь негативные моменты так получается на себя брать: набрал плохую команду, неправильно раздал задачи, не контролировал и не мотивировал и т. д. — всё моя вина. Но, блин, только в теории, положительный результат в роли менеджера я эмоционально считаю как «на этот раз повезло, удачно звезды встали, карта легла». Как изменить своё отношение я не знаю, поэтому самоустраняюсь от менеджерских функций, выступая в роли технического эксперта и где-то в роли бизнес-аналитика для менеджера, выдавая, например, ТЗ для верстальщика менеджеру и проверяя его выполнение, но не вмешиваюсь в вопросы контроля и мотивации.
                                                                  • +1
                                                                    Хорошо что есть управленцы, и хорошо что не все хотят ими быть. Пусть те кто могут управлять, собирают талантов и притворяют достойные идеи в жизнь.
                                                                    • 0
                                                                      Меня терзают смутные сомнения, что эта неделя будет посвящена "[до-хрена] причин быть/не-быть/может-быть лидом"

                                                                      image
                                                                      • +3
                                                                        Помойму, авторы обоих постов различают термины «менеджер» и «тимлид».
                                                                        • +1
                                                                          согласен.

                                                                          играющий тренер, ведущий программист — это одно.

                                                                          а менеджер проекта — другое.

                                                                          классический управленец на месте — третье.

                                                                          в управлении тоже много специальностей. антикризисный менеджер, оперативный руководитель, топменеджер со стратегическим видением, прораб на стройке и тд — over 9000 их
                                                                          • +2
                                                                            Все они когда-то были стажерами. Точка.
                                                                    • +8
                                                                      Одни управленцы в стране… Заводы стоят!!! Деталь тупо выточить некому, потому, что управленцы не знают как (а как можно управлять не понимая ссуть?), а остальные — юристы, программисты и гитаристы. Все. Это полный крах, дальше уже некуда.
                                                                      • +3
                                                                        После завода пишите?
                                                                        • 0
                                                                          Да, хоть бы и после грузчика. Или Вас это чем-то задевает?
                                                                          • 0
                                                                            Конечно, трудяга еще успевает пофлудить в каментах. Я бы хотел пожать вам руку, как человеку, который совмещает достойную работу простого парня и успевает писать эмуляторы приставок по ночам.
                                                                            • +5
                                                                              А я не говорю, что сейчас работаю грузчиком. Но трудяга, да, это Вы это в точку. По ночам я сплю здоровым крепким сном, чего и Вам желаю конечно; и не пишу никакие эмуляторы приставок. Но думаю Вы не вправе не согласится, что кадры разные нужны, кадры разные важны. И что сейчас «управленцев», а по сути — офисных крыс плюющих в потолок и изредка, с пинка еще вышестоящих «управленцев» чего то делающих, поголовно больше, чем низкоквалифицированных подчиненных. Разве нет?
                                                                              • +2
                                                                                Вот же ж можете писать нормально, а не троллить тупой и изъезженной темой про «заводы стоят».

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

                                                                                > И что сейчас «управленцев», а по сути — офисных крыс плюющих в потолок и изредка, с пинка еще вышестоящих «управленцев» чего то делающих, поголовно больше, чем низкоквалифицированных подчиненных
                                                                                Да.

                                                                                > поголовно больше, чем низкоквалифицированных подчиненных. Разве нет?
                                                                                Я не обладаю авторитетной статистикой, но не кажется ли, что их должно быть больше, т.к. эта работа доступнее.

                                                                                > По ночам я сплю здоровым крепким сном, чего и Вам желаю конечно
                                                                                Спасибо. И вам не хворать.

                                                                                Но знаете, чего я не могу понять: если так много неэффективного в плане производительности слоя «управленцев», которые должны раздавать задания (сделай то и то, а почему? так надо), то как наш мир функционирует.
                                                                                • 0
                                                                                  Но знаете, чего я не могу понять: если так много неэффективного в плане производительности слоя «управленцев», которые должны раздавать задания (сделай то и то, а почему? так надо), то как наш мир функционирует.

                                                                                  В отношении заводов оборонки за счет минимум тройной себестоимости.
                                                                        • 0
                                                                          Ну я вышел из программиста, немного в теме, как бы :)

                                                                          А заводы — модернизация должна быть в стратегических планах государства. Это вы к другим управленцам, которые эту стратегию пишут, обращайтесь :)
                                                                          • +3
                                                                            Фиговые управленцы раз не могут найти и(или) подготовить того, кто деталь выточит. Или на фиг та деталь никому не нужна, но управленцы и тут фиговые, раз думают о том, как е выточить.

                                                                            P.S. Пишу как несостоявшийся менеджер машиностроительной промышленности. Одна из причин — понял, что придётся искать тех, кто может детали выточить.
                                                                            • 0
                                                                              Дизайнеры и блоггеры еще
                                                                            • +5
                                                                              Ещё один нюанс — качество специалиста проще проверить, чем качество управленца. Программиста можно попросить показать код, решить пару тестовых заданий — и его уровень будет ясен. А вот для управленцев таких тестов, к сожалению, нет.

                                                                              Соответственно, есть масса «так-себе-управленцев», которые при этом претендуют на те же позиции, что и действительно профессиональные менеджеры, и отфильтровать их не так-то просто.

                                                                              Я обычно руководствуюсь двумя критериями: «сколько человек было под началом» и «что делало руководимое подразделение». Потому что начальник отдела из 5 и из 30 человек — это две большие разницы. Но при этом отдел из 5 человек может быть, скажем, «отделом автоматизации» в маленьком банке и решать все его разнообразные потребности, а отдел из 30 — это может быть просто банда сисадминов, но в банке большом.

                                                                              Но и это не всегда помогает. Кроме того, часто управленцев переманивают с должностей заместителя: дескать, карьерный рост, повышение — но заместитель может быть действительно правой рукой шефа, а может — чисто номинальной должностью, зато красиво раздувать щёки и рассказывать на собеседованиях о своей важности :)
                                                                              • 0
                                                                                согласен.

                                                                                а еще их учить дольше и труднее, и тупо дороже получается.
                                                                                • 0
                                                                                  Если это соискатель на РП, например, предложите ему спланировать какой-нибудь выдуманный проект. За 5-7 минут в общих чертах концептуально.

                                                                                  Если это соискатель на тимлида, например, предложите ему за 5-7 минут накидать план организации процесса разработки на пустом месте.
                                                                                  • +2
                                                                                    Подписываюсь. Практические задачи на интервью радикально меняют картину и помогают отсеять тех, кто лишь «умеет продавать себя».
                                                                                • 0
                                                                                  Не мог бы ты привести пример «масштабируемости» из твоей практики? Какая у тебя была самая большая команда и на каком проекте?
                                                                                  • 0
                                                                                    Да в общем, не очень большой у меня опыт, не как у автора того поста.

                                                                                    Примеры
                                                                                    1. Автоматизация техподдержки. Суммарно 10 человек. Это в плане людей.
                                                                                    Условно, единый центр приема заявок со многих проектов (с десяток крупных ) + учет звонков (у нас разные группы клиентов, везде тысячами и десятками тысяч исчисляется письмо), плюс куча бизнес-процессов внутри компании (менеджеры, пишущие вопросы клиентам в техподдержку, для поддержки мониторинг, как их проблемы третьего уровня решают разработчики, и тд). Много всего.

                                                                                    2. В плане сложности — из недавнего. Перенос сложного проекта CRM с MySQL на PG и внедрение, плюс перенос части функционала из ранней версии CRM в текущую (карточка клиента). Это делала одна моя группа, там PM + программист. Трудное внедрение, так как 50 сейлзов, система должна работать постоянно. Плюс трудно технически, много кода перелопатили, а сроки (месяц) ограничены.

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

                                                                                    В целом возможность параллелить работу и давать людям возможность делать самостоятельно — это привлекает, это масштабируемо.
                                                                                    • 0
                                                                                      Эх, максимализм.
                                                                                      В 21 год я то же был PM'ом группы из 7 человек (1 тестер, 2 BA, 1 суппорт, 3 разработчика), автоматизировал розницу одного банка из топ-20 на тот момент.

                                                                                      Просто вот это «Как управленец, я могу строить управленческие структуры, рабочие группы, и суммарный результат во много раз больше, чем если бы я сам кодил» ну никак не коррелирует с опытом руководства 10 сотрудниками, уж поверьте.
                                                                                      • 0
                                                                                        Мне 25 :) Макс. опыт 30 человек руководства. Это чуть больше, чем управление проектами в рамках одной группы, поверьте.

                                                                                        Просто вы спросили в одной группе — да, всего лишь 10, не 100 и 1000, как у топикстартера.

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

                                                                                        Где тут максимализм? В формулировке разве что.
                                                                                  • 0
                                                                                    Я управляю проектами два года, и только начинающий project manager, по сути дела. В отделе 15 человек, несколько проектных групп. Менеджер среднего звена — управляю теми, кто управляет программистами. При этом напрямую также веду программистов и ряд проектов. До этого три года был ведущим web-программистом, до этого стартапы, своя студия, фриланс и тд.
                                                                                    А почему сменили «свою студию» на корпоративного менеджера проектов? Ведь в своей студии управлять должно быть интереснее и, возможно, выгоднее?
                                                                                    • 0
                                                                                      в то время я был очень молодой и неопытный. и работал оперативным управленцем, а также занимался продажами и тд.
                                                                                      только зарождался Веблансер, был 2007 год )

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

                                                                                      короче, много геммороя и мало интересного. деньги мало решают, их не было много.

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

                                                                                      вообщем классический PM — это как раз мини-бизнес в рамках компании. есть бюджет. проект, ресурсы, риски. дали пистолет и крутись, как в анекдоте :) только инфраструктура вся — от продаж до бухучета и тд — готовая, а ты не создаешь ее с нуля, как в своем деле на 100%.
                                                                                      • 0
                                                                                        то есть короткий ответ
                                                                                        1. там было неинтересно
                                                                                        2. не было выбора проектов, трудно было с ресурсами (кто сам искал проггеров или даже дизайнеров на фрилансе в веб-студиях, знает)
                                                                                        3. денег было не так много
                                                                                        4. я просто не тянул это профессионально.
                                                                                      • +1
                                                                                        «У нас проекты — как стартапы, в разных сферах.»
                                                                                        «Любой проект можно развивать бесконечно.»

                                                                                        «A project is a temporary endeavor undertaken to create a unique product, service, or result» © PMBOK Guide 4th Ed
                                                                                        • 0
                                                                                          Есть такое дело.
                                                                                          Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.

                                                                                          Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.

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

                                                                                          НО!

                                                                                          1. Основные задачи раздел решает, то есть стадия самодостаточности есть
                                                                                          2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
                                                                                          3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас а от чего нет — это тоже работа проблеете и очень мало кто умеет это делать. Я только учусь, еще не умею
                                                                                          • +1
                                                                                            Это была просто придирка.

                                                                                            Судя по описанию, вы безусловно занимаетесь управлением и являетесь членом Project Management Team. Но вот Project Manager ли вы?..

                                                                                            Очень часто возникает путаница. Технический руководитель — это не руководитель проекта. Как и TechLead, как и TeamLead.

                                                                                            Зачастую, определения и круг обязанностей в разных компаниях настолько отличаются, что невольно задаёшь себе вопрос: «А я-то тогда кто?»
                                                                                            Во многих государтвенных (или бывших) организациях это вообще невозможно понять. И должности называются настолько длинно и сложно, что сотрудники первый год сами подглядывают названия в подписях к своим же сообщениям в Outlook.

                                                                                            Благо, с сентября вступили в силу ГОСТ Р 54869-2011, ГОСТ Р 54870-2011, ГОСТ Р 54871-2011. Надеюсь, теперь всё устаканится.
                                                                                            По иронии судьбы, курировал разработку стандартов Евгений Петросян. Нет, слава Богу, не тот…
                                                                                            • 0
                                                                                              Должность у меня вообще руководитель отдела. И много, связанного с этим, тоже решаю. Административная нагрузка в минус, зато контроль над ресурсами и людьми в плюс. Много плюшек за и против.

                                                                                              Но специальность и основной вид деятельности, конечно, PM. По мере роста моего профессионализма он все ближе в плане полномочий и возможностей к классическому варианту.
                                                                                              • 0
                                                                                                А как вы для себя определяете менеджера проектов? Кто это?
                                                                                                • 0
                                                                                                  В таких случаях я обращаюсь к стандартам.
                                                                                                  Например, PMI PMBOK.
                                                                                                  Если же структура компании и её корпоративные культура и нормы совсем уж уникальные и ни на что не похожие, тогда надо руководствоваться именно этими нормами.
                                                                                                  Но, мне кажется, лучше велосипедов не выдумывать и использовать то, что есть. Хотя бы для того, чтобы разговаривать на одном языке с остальными.
                                                                                                  • 0
                                                                                                    Да, язык важен, и общение с коллегами. Важны стандарты и чужой опыт.

                                                                                                    Но у меня задачи пока проще. Сначала добиваться результата в заданной системе ограничений. Недавно добавилась задача определять, что есть результат, и самому строить системы, в которых команды результативно работают.
                                                                                                    • 0
                                                                                                      Важнее всего голова и здравый смысл, как показывают многочисленные наблюдения.
                                                                                                      Благо, в ИТ с этим, как бы многим не казалось, значительно лучше, нежели в других сферах.
                                                                                                    • 0
                                                                                                      Та же пмбок при изучении показала, что пока для нас это как из пушки по воробьям. Или мы не умеем его готовить :)
                                                                                                      • 0
                                                                                                        Это заблуждение.
                                                                                                        Вы, вероятно, просто поверхностно ознакомились с руководством.
                                                                                                        Так что скорее просто не умеете его готовить.
                                                                                                        Сходите на курсы, мастер-классы, посмотрите, как это работает не только в больших, но и в самых маленьких компаниях и проектах.
                                                                                                        • 0
                                                                                                          Из проб других методик и подходов, более простых и айтишных, типа скрама, появилось впечатление, что это тупо товар и продавцы серебряной пули

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

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

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

                                                                                                          Вот этому что-то пока никто не учит.
                                                                                                          • 0
                                                                                                            Простите за жесткость. Где-нибудь в Газпроме, где у знакомого моего проджект менеджеры это крутые бумажко писатели, нужны конечно стандарты, ГОСТы, законы.

                                                                                                            У меня же айти, автоматизация бизнеса, задачи именно такие, четкие.
                                                                                                            • 0
                                                                                                              Вот на Газпром и прочие государственные и прогосударственные компании я бы точно не равнялся. Плохой пример.
                                                                                                            • 0
                                                                                                              Про пмбок от опытных товарищей слышал, что для бюджета от миллиона долларов это рулез и ничего лучше не надо.

                                                                                                              У нас в 5-30 раз меньше бюджеты на проекты, и плюс сложные условия, что нам ближе всего методология XP.
                                                                                                              • 0
                                                                                                                XP — это методология разработки.
                                                                                                                Но не управления проектами.

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

                                                                                                                «Ничего лучше не надо» — это неправильный подход. Improvement должен быть всегда.
                                                                                                                • 0
                                                                                                                  Да, согласен, просто очень много уделяю разработке. Не стоило смешивать

                                                                                                                  Ок прогляжу еще раз, раз опытные люди советуют. Попробую взять пару вещей при необходимости
                                                                                                              • 0
                                                                                                                Поэтому я и написал выше, что самое главное — это светлая голова и здравый смысл.
                                                                                                                Всяческие стандарты и методологии — это не панацея, не догма и уж точно не серебрянная пуля.
                                                                                                                Собственно, в некоторых стандартах это чёрным по белому пишут.
                                                                                                                • 0
                                                                                                                  Работать без методологии можно, просто опираясь на здравый смысл (а в управлении на 99% именно он, а не специфические знания). Проблема заключается в том, что каждый уверен в том, что именно у него со здравым смыслом все в порядке. И если удалось несколько лет в индустрии продержаться, то и «опыт» появляется. И вот такой чувак, со «своим видением» и «опытом» дров способен наломать немало. Поэтому общепринятый стандарт, методология, позволяет убедиться, что с человеком хотя бы можно говорить на одном языке. Что ему не нужно объяснять, кто такие стейкхолдеры и почему важно утверждать с ними требования к проекту. Зачем нам расписывать risks mitigation plan заранее и почему нельзя закрыть проект просто после того как он сдан заказчику.
                                                                                                                  Да, можно иметь РМР-сертификат, вызубрить PMBOK на память и быть плохим менеджером проектов. Точно так же можно вызубрить правила дорожного движения, и быть плохим водителем. Но без знания правил лучше все же на дорогу не выезжать в принципе.
                                                                                                        • 0
                                                                                                          А какой у вас опыт управления проектами?
                                                                                                          • 0
                                                                                                            У меня тоже «всё сложно».
                                                                                                            Занимался управлением проектами я более 4 лет.
                                                                                                            Но твёрдо PM я 2 года.
                                                                                                            • +2
                                                                                                              Светлая голова и зравый смысл — главное. Разуммется, но имхо рекомендации разработаны чтоб 1. Импрувмент должен быть всегда. 2 для тех у кого голова не такая светлая и смысл не такой здравый (разрабатываются фреймворки именно теми у кого со светлостью и здравым смыслом все ок, чтобы управлять ресурсами).

                                                                                                              Вот только для рф характерен тотальный непрофессионализм. вообще начну с того что бОльшая часть людей не знает что такое методология, а бОльшая часть трудящихся менеджеров в нашей стране в соотвествующей сфере особенно крупных компаний очень далеко стоят от методологий в управлении проектов.
                                                                                                              Классический пример — менеджер отвечающий за интернет проект со стороны клиента (раработка интернет магазина линейки проудктов) с трудом отвечает что такое браузер. и поэтому токого рода хай левел в управлении проектами в нашей стране просто модель. Несмотря на то что пмбоке в общем рассматривается ситуация с отрицательной полезностью стейкхолдера итп. сложно представляю как можно объяснить управление рисками субъекту, который сам является самым большим риском проекта (что нужно сделать чтобы запуститься к дедлайну — выпей йаду и не мешай).
                                                                                                              Или вот еще — задачу по разработке дизайна ставит один человек, а результат работы принимает другой, не соблюдая последовательность в разработке.
                                                                                                              Разумеется понятно как это разруливать, но ведь хочется работать грамотно и эффективно, по плану проекта.
                                                                                                              Много всего хочется написать да как то грустно.
                                                                                                              • 0
                                                                                                                Не могу не согласиться со всем вышенаписанным.
                                                                                                                Увы, многие в проблемах РФ обвиняют неэффективных менеджеров и тотальную коррупцию. Всё это так, если бы в дополнение не было ещё и тотального непрофессионализма.
                                                                                                      • 0
                                                                                                        Есть такое дело.
                                                                                                        Я пока только учусь, пмбок проглядывал и пока ясно одно, мы пока не так круты, чтобы юзать эту мощь.

                                                                                                        Я перефразирую. Речь о состояниях. Мы выделяем разные фазы развития проекта. Среди этих фаз есть самодостаточность раздела. Это когда вроде работает и показатели в норме, но можно улучшить.

                                                                                                        Давайте за пример Хабр. Раздел профиль пользователя. Я захожу в мои посты, и сразу понимаю, что не хватает фильтра. По блогу, поиск по ключевому слову. Возможно год и месяц статьи, искать их было бы муторно без гуглопоиска по хабру. И еще миллион улучшений вы мне назовете сами, так как вы и я в шкуре пользователя проекта. А работа проджекта сродни работе актера — вы должны перевоплотиться в своего клиента, в своего пользователя, работать с живыми клиентами, иначе не поймете, как нужно сделать продукт качественным и удобным, решающим именно те задачи, которые нужны вашим клиентам.

                                                                                                        НО!

                                                                                                        1. Основные задачи раздел решает, то есть стадия самодостаточности есть
                                                                                                        2. Новый функционал типа фильтров может быть экономически не оправдан и не совпадать со стратегией развития
                                                                                                        3. Всегда, делая одно, мы не делаем другое. Вот понять, что в каком порядке делать, от чего отказаться сейчас, а от чего нет — это тоже работа проджекта и очень мало кто умеет это делать. Я только учусь, еще не умею
                                                                                                        • 0
                                                                                                          Прошу прощения за дубль
                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                          • +4
                                                                                                            Недавно подслушал любопытную женскую теорию. Суть — чем больше женщина тратит тем больше мужик будет зарабатывать. Много думал.

                                                                                                          • 0
                                                                                                            Желаю жить как Миша Галустян — иметь душ триста крепостных крестьян…
                                                                                                            • +3
                                                                                                              >Я прочитал пост «13 причин не быть управленцем» и хочу написать ответ.
                                                                                                              Тот пост: «Не становитесь управленцем! Это сложно, а потому плохо!»
                                                                                                              Этот пост: «Станьте управленцем! Это сложно, а потому интересно!»

                                                                                                              Может всё-таки проблемы не в должности, а в психотипе?
                                                                                                              • 0
                                                                                                                Вы внимательно читали?
                                                                                                                Написано: Поэтому универсальных советов нет, каждому нужно искать свое дело.
                                                                                                                • +2
                                                                                                                  Дело не в сложности, дело в том какая это сложность. Управленческая сложность неуправляемая, непредсказуемая, несистематизируемая, неформализуемая. Нельзя поставить эксперимент и посмотреть, что будет, а потом откатиться как будто его и не было — начинать придётся не с нуля, а из минусов вылазить как чисто финансовых, так и репутационных, психологических и т. п. опять же неквалифицируемых, неформализуемых и т. д. Всё время приходится «работать на продакшене», а не на «уютном дев-сервере».
                                                                                                                • +7
                                                                                                                  А давайте все станем управленцами? И будем друг другом управлять! Вот круто будет! :)
                                                                                                                  • 0
                                                                                                                    Вот в таких статьях всегда раздражает то, что автор как будто бы забвает, что управленцы не нужны. Без управленцев программисты запросто создают отличные продукты, а вот управленцы без программитсов — ничего не создают, кроме отчётов.
                                                                                                                    • +1
                                                                                                                      И много можно найти успешных проектов, построенных без управленцев (продукты, которые можно выпустить силами 1-3 человек в расчет брать не будем)?
                                                                                                                      • 0
                                                                                                                        Steam?
                                                                                                                        • 0
                                                                                                                          Пруф?
                                                                                                                          • 0
                                                                                                                            раз: 35 млн пользователей и его делает Valve ru.wikipedia.org/wiki/Steam
                                                                                                                            два: в Valve нет менеджеров habrahabr.ru/post/142645/
                                                                                                                            Значит Стим — крупный продукт, сделаный без менеджеров
                                                                                                                            • 0
                                                                                                                              В статье упоминается некое «руководство». Также ничего не сказано что в проектах нет руководителей. Да, структура компании непостоянная, но нигде не сказано, что нет управляющих ролей.
                                                                                                                              • +1
                                                                                                                                Мне почему-то кажется, что если копнуть глубже, то окажется, что всё «отсутствие руководства» заключается только в свободном перемещении сотрудников между проектами
                                                                                                                        • 0
                                                                                                                          я согласен.

                                                                                                                          какой % таких программистов, и какой тех, кто делает сам 99% и бросает?
                                                                                                                          • +1
                                                                                                                            Только в случае если один из программистов берёт на себя роль управленца: «мы посовещались и я решил». Даже если брать опенсорс проект на гитхабе, то обычно кто-то один (или небольшая группа) решает какие пулл реквесты принимать, а какие — нет. В крайнем случае вырабатывает механизм коллективного принятия решений («пулл реквесты принимаем по результатам голосования за неделю») и разруливает спорные моменты.
                                                                                                                          • +3
                                                                                                                            Вот типичный управленец — он мотивирует. Пред. статья должна быть в топе на demorivators.bla

                                                                                                                            Спасибо тебе добрый фей!
                                                                                                                            • +5
                                                                                                                              Перечитал.
                                                                                                                              Пункт 1. А как насчёт системы на 35 миллионов пользователей, построенной и отлично работающей без менеджера?

                                                                                                                              Пункт 2 вообще пушка — «я не хочу учиться, хочу один раз и чтоб потом бабло грести». Просто ода лени.

                                                                                                                              Пункты 3, 4 и 5 — про интенсивность, бесконечность и ответственность в той же степени подходят и программистам. С той разницей, что менеджеры об этом говорят, а программисты делают. Собственно программисты и создают эту самую «бесконечность развития», и несут ответственность за себя и за менеджера. Ведь если программист ошибается — переделывает он. А когда ошибается менеджер — переделывает снова программист.
                                                                                                                              • 0
                                                                                                                                1. я только за
                                                                                                                                когда была своя студия, поначалу был и жрец, и жнец, и на дуде игрец. и продавец сам себе, и бухгалтер, и PM, и верстальщик, и техподдержка.

                                                                                                                                если программист тянет другие роли, в том числе делает управленческую работу — пожалуйста.

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

                                                                                                                                2. ода лени, и ода разумности.
                                                                                                                                вот в Dolphin Olympics наибольшие очки набираются, только если каждый следующий прыжок основан на предыдущем. упал — все, мало очков будет.

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

                                                                                                                                3. согласен со всем, кроме ответственности
                                                                                                                                если менеджер проекта (продукта) придумал неверный раздел, неверный маркетинг и так далее, то беда ему, а не программеру. программер сделал — и молодец, все четко, получил ЗП. а вот продукт не взлетел с новой фишкой, бюджет в минусах и у PMа бонус потерян. так что тут зависит от ситуации :)