Может ли человек, не знающий ни одного языка программирования, быть прожект-менеджером?
Для начала - нужно ли быть программистом, чтобы стать проджект-менеджером? Нет, не нужно. Это абсолютно разные области. Проджект не должен ничего кодить, ему нужно развивать совсем другие скиллы. Например:
Понимание UX/UI чтобы правильно готовить продуктовые фичи и уметь думать от пользователя
Маркетинговые навыки, чтобы понимать как оценивать изменения, за какими метриками следить, проводить A/A, A/B тестирование и тд
Развивать софт скиллы в виде эмпатии, умение принимать решения, умение брать на себя ответственность и т.д. - вроде типа все это умеют, а вот нихрена. Рядовой специалист может скрыться за "это не моя зона ответственности", хороший PM не может.
Развивать знания предметной области, понимание бизнеса и как он работает. Без этого менеджер просто будет заниматься крысиными бегами, симулировать деятельность и не приносить результат компании.
Все это совершенно не обязательно, чтобы писать хороший код.
Тут еще можно подискутировать относительно того, что вроде это все больше Product'у нужно, а не Project'у, но на самом деле нет. Это все важно для обоих.
Возвращаясь к теме программирования - но понимание этой темы, сделает вас более эффективным менеджером. Как человек, который пришел в менеджмент из программирования, я сразу понял одно правило - не лезь с советами по коду, даже если знаешь, как сделать лучше. Во-первых, это не твоя зона ответственности. Во-вторых, ты все равно не в контексте кода и проекта. Наконец, твоя команда будет воспринимать это как вторжение в личное пространство. Но есть и обратная ситуация.
Как-то я занимался аудитом IT проектов. Это ты когда приходишь, подписываешь NDA, изучаешь проект, а потом даешь советы и рекомендации, что можно улучшить. Так вот одна история была про то, как через месяц должен был запуститься проект с рекламой по всем федеральным каналам и т.д. Но чет последние месяцы они вообще не видели прогресса, хотя программисты говорили что все успеют. Пригласили меня. За несколько часов я понял, что два года ребята просто ничего не делали, придумывали проблемы и типа их чинили. Вся кодовая база была ужасна и весь функционал, что был один я мог написать за месяц. Более того, все было настолько плохо, что я пришел к директору и объявил, что его проект, рассчитанный на милионную аудиторию не выдержит нагрузки в 50 одновременных соединений. Тот решил, что я зазнавшийся парень просто, позвал админов провести тест. Отвалилось на 46.) После этого паника, увольнения, уговоры меня переписать все за месяц за любые деньги и т.д.
К чему эта история? Это пример того, что бывает, когда менеджмент нифига не шарит в программировании. И отчасти почему все так плохо в непрофильных IT компаниях аля ООО Мир Шпингалетов, где решают нанять программистов а менеджером поставить заместителя директора по общим вопросам, нифига в этом не разбирающимся. Менеджмент просто начинают водить за нос.
Например, вам могут сказать, что-то в духе - блин, тут короче проблема такая, что тип таблицы MyISAM, чтобы стало нормально, надо тип таблицы поменять, это долго, примерно неделя. Хотя я могу за дня 4 справиться, но это с переработками. Если вы не шарите в чем речь вы покиваете головой, а потом программисту еще и премию выпишите за героическое успевание в 4 дня. А если шарите - уволите его нафиг, потому что описанное выше делается за 2 минуты, да и вообще мб ересь какая-то, зависит от того какую проблему решать. Просто нужно понимать о чем речь и тогда становится понятно, что вас пытаются нагреть.
Прям в моей практике был пример, когда парень пытался меня прощупать. И когда я попросил предложения по решению проблемы с долгими запросами, заявил, что срочно нужен докер и тогда 90%, что все будет огонь (спойлер, это две несвязанные вещи вообще, примерно как "что нужно, чтобы приготовить яичницу" - "давайте заправим автомобиль"). Разок поставил его на место, больше таких гениальных предложений не было.
Мораль истории - не нужно становиться кодером, но иметь представление о том как это работают, что такое ООП и чем отличается от функционального программирования, какие бывают СУБД, что по верхам имеет какие преимущества и т.д. - все это нужно знать. Не на глубоком, а на поверхностном, но нужно. Не говоря о том, что без этого вы даже тикеты корректно не декомпозируете. Иначе вы никогда не получите результат. Плюс взаимоуважение, вот что важно. Если вы не шарите в предметной области, его гораздо сложнее добиться от специалистов своей области (хотя, если вы хороший менеджер, то возможно, но нужен опыт).
Но многое зависит от ваших целей. Не раз встречал менеджеров, которые скорее вредили своей команде, отыгрывая свои комплексы или потешая ЧСВ (типа я тут босс). Или которые были просто бесполезны от слова совсем, не желающие брать на себя ответственность и что-то решать. Фактически их можно было заменить на комнатное растение и в принципе в команде бы ничего не поменялось. В общем, есть те, кто попал случайно, по удаче, по знакомству и просто отсиживает штаны, считается менеджером и ему пофиг на результативность команды. Поэтому вариант сидеть на попе ровно, никак не развиваться и кормить бизнес завтраками тоже всегда есть, но мне хочется верить, что в мире будет больше нормальных управленцев. Поэтому лучше учитесь и развивайтесь.
Для начала - нужно ли быть программистом, чтобы стать проджект-менеджером? Нет, не нужно. Это абсолютно разные области. Проджект не должен ничего кодить, ему нужно развивать совсем другие скиллы. Например:
Все это совершенно не обязательно, чтобы писать хороший код.
Тут еще можно подискутировать относительно того, что вроде это все больше Product'у нужно, а не Project'у, но на самом деле нет. Это все важно для обоих.
Возвращаясь к теме программирования - но понимание этой темы, сделает вас более эффективным менеджером. Как человек, который пришел в менеджмент из программирования, я сразу понял одно правило - не лезь с советами по коду, даже если знаешь, как сделать лучше. Во-первых, это не твоя зона ответственности. Во-вторых, ты все равно не в контексте кода и проекта. Наконец, твоя команда будет воспринимать это как вторжение в личное пространство. Но есть и обратная ситуация.
Как-то я занимался аудитом IT проектов. Это ты когда приходишь, подписываешь NDA, изучаешь проект, а потом даешь советы и рекомендации, что можно улучшить. Так вот одна история была про то, как через месяц должен был запуститься проект с рекламой по всем федеральным каналам и т.д. Но чет последние месяцы они вообще не видели прогресса, хотя программисты говорили что все успеют. Пригласили меня. За несколько часов я понял, что два года ребята просто ничего не делали, придумывали проблемы и типа их чинили. Вся кодовая база была ужасна и весь функционал, что был один я мог написать за месяц. Более того, все было настолько плохо, что я пришел к директору и объявил, что его проект, рассчитанный на милионную аудиторию не выдержит нагрузки в 50 одновременных соединений. Тот решил, что я зазнавшийся парень просто, позвал админов провести тест. Отвалилось на 46.) После этого паника, увольнения, уговоры меня переписать все за месяц за любые деньги и т.д.
К чему эта история? Это пример того, что бывает, когда менеджмент нифига не шарит в программировании. И отчасти почему все так плохо в непрофильных IT компаниях аля ООО Мир Шпингалетов, где решают нанять программистов а менеджером поставить заместителя директора по общим вопросам, нифига в этом не разбирающимся. Менеджмент просто начинают водить за нос.
Например, вам могут сказать, что-то в духе - блин, тут короче проблема такая, что тип таблицы MyISAM, чтобы стало нормально, надо тип таблицы поменять, это долго, примерно неделя. Хотя я могу за дня 4 справиться, но это с переработками. Если вы не шарите в чем речь вы покиваете головой, а потом программисту еще и премию выпишите за героическое успевание в 4 дня. А если шарите - уволите его нафиг, потому что описанное выше делается за 2 минуты, да и вообще мб ересь какая-то, зависит от того какую проблему решать. Просто нужно понимать о чем речь и тогда становится понятно, что вас пытаются нагреть.
Прям в моей практике был пример, когда парень пытался меня прощупать. И когда я попросил предложения по решению проблемы с долгими запросами, заявил, что срочно нужен докер и тогда 90%, что все будет огонь (спойлер, это две несвязанные вещи вообще, примерно как "что нужно, чтобы приготовить яичницу" - "давайте заправим автомобиль"). Разок поставил его на место, больше таких гениальных предложений не было.
Мораль истории - не нужно становиться кодером, но иметь представление о том как это работают, что такое ООП и чем отличается от функционального программирования, какие бывают СУБД, что по верхам имеет какие преимущества и т.д. - все это нужно знать. Не на глубоком, а на поверхностном, но нужно. Не говоря о том, что без этого вы даже тикеты корректно не декомпозируете. Иначе вы никогда не получите результат. Плюс взаимоуважение, вот что важно. Если вы не шарите в предметной области, его гораздо сложнее добиться от специалистов своей области (хотя, если вы хороший менеджер, то возможно, но нужен опыт).
Но многое зависит от ваших целей. Не раз встречал менеджеров, которые скорее вредили своей команде, отыгрывая свои комплексы или потешая ЧСВ (типа я тут босс). Или которые были просто бесполезны от слова совсем, не желающие брать на себя ответственность и что-то решать. Фактически их можно было заменить на комнатное растение и в принципе в команде бы ничего не поменялось. В общем, есть те, кто попал случайно, по удаче, по знакомству и просто отсиживает штаны, считается менеджером и ему пофиг на результативность команды. Поэтому вариант сидеть на попе ровно, никак не развиваться и кормить бизнес завтраками тоже всегда есть, но мне хочется верить, что в мире будет больше нормальных управленцев. Поэтому лучше учитесь и развивайтесь.