Я в начале статьи описала, о каких именно ПМах речь:
Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.
Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.
Так я не продвигаю мысль, что ПМу нужно забить на все остальное и сидеть разбираться в коде. Моя мысль о том, что базис надо набирать, если хочешь продвигаться в карьере и нормально проекты закрывать. Ну и быть своей команде помощником.
В первую очередь, спасибо за такой обширный и интересный комментарий :)
Ну и чего там делает GIT при наличии SDLC тоже не очень ясно? Тулите тогда уже, ну не знаю, весь DevOps. Чего только на Git смотреть?
Здесь, пожалуй, стоит отметить, что опиралась я на процессы внутри компании, в которой работаю последние 5+ лет.
Отсюда вытекает 2 момента:
1) во каких-то компаниях процессы выстроены иным способом, в связи с чем описанное в статье может вызывать недоумение на тему «нафига это вообще нужно ПМу» или «как вообще такой чувак стал ПМом без таких-то знаний» и т.д.;
2) есть компании со схожими с нашими процессами, в связи с чем описанное в статье может помочь определенной категории населения таких компаний :)
Про какие именно процессы я говорю:
а) аккаунт-менеджер и проджект-менеджер — это одно лицо, разделения нет, менеджер общается как с клиентом, так и с командой;
б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
в) случается такое, что ПМ, не занимавшийся разработкой, вдруг оказывается на проектах по разработке (в виду форс-мажорных обстоятельств в агентстве, собственных интересов, других причин);
г) на встречи с клиентом брать кого-либо из команды разработки нельзя, т.е. ПМ должен быть способен ответить на все технические вопросы, отработать все возражения и скользские моменты сам в 90% случаев.
Также, к счастью, у нас в компании позитивно относятся к различного рода переходам и, тем более, росту сотрудника, поэтому встречаются абсолютно разные примеры трансферов: из фронта в ПМ, из ПМ в сис.админа, из ПМ в бэка, из офис-менеджера в ПМ и т.д.
Ничего плохого в том, что ПМ что-то узнает у товарищей, учится и наблюдает за классными примерами работы, впитывает знания — мы не видим. Более того, это не встречает сопротивления или негатива и у разработчиков.
Нет в списке базовых ИТ-процессов вроде релиз менеджмент, управление изменениями и т.д.
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Я обычно QA задаю простой вопрос на тему F12 в браузере. Если знает и даже более того, умеет читать всякое там написаное - значит базово ОК. С ПМом условно тоже самое. Все это вами написанное сводится к простому - если вы проходите этот вопрос, значит да - вы уже где-то на уровне джуна/мидла мануального QA по этому вопросу. Нет - я вас расстрою, вы ничего из этого списка не знаете :) Даже если выучите и про клиент-сервер, и просто TCP/IP и еще много чего.
Моя статья для менеджеров, которые хотят получить эти знания. И не знают, с чего начать. Постепенно все, кто жаждут знаний и развития, дойдут до того, что описываете вы, а потом и уйдут дальше :)
Темы даны для формирования общего представления о работе веб-приложений и Интернета в целом. Углубленное изучение менеджером не предполагается, по крайней мере на самом начальном этапе. С моей точки зрения данные темы помогут заложить фундамент и дадут базис глоссария для менеджера, начинающего свой путь в веб-разработке.
Таким образом, будут заложены основы понимания:
а) как работает передача данных в сети в целом;
б) как работает передача данных и как распределяется нагрузка между сервером и клиентом;
в) чем вообще отличается фронтенд от бэкенда, и какие задачи кому из разработчиков отдавать соответственно;
г) как происходит связка между фронтом и бэком, как работает API;
д) какие этапы проходит ПО и команда во время его разработки;
е) как происходит процесс доставки кода с локальной ветки разработчика на продакшн-среду, как устроен GIT и какие возможности он может дать менеджеру.
Основной профит для ПМ при изучении указанных тем:
- появляется общее представление, какие задачи ставить на фронта, какие на бэка, какие на контента и т.д.;
- появляется некоторый theoretical minimum, технический вокабуляр, с которым понимать и клиентов, и разработчиков становится попроще;
- ПМ становится на путь познания особенностей архитектуры и разработки ПО :)
Буду также рада послушать, какие темы посоветовали бы новичкам вы, или все читающие этот тред
У меня был такой пример) В статье решила не рассказывать о нем, но если коротко, то как-то раз пришлось самой залезть в код, так как разработчик был выжат после нескольких бессонных суток. И в тот момент, сквозь слезы, я поняла, что это не так страшно, как кажется. И что код логичный и его можно читать и хотя бы верхнеуровнево понимать, за что он отвечает. Но тут мне еще повезло, у нас везде в проектах ООП, что влияет на качество кода.
Не говорю, что я теперь, знаете ли, сам своего рода разработчик, но после этого случая стало легче иметь дело с разработчиками.
Слушайте, ну тут же не знание на уровне 9999лвл подразумевается. Тут речь идет о том, чтобы банально понимать, о чем с тобой говорит разработчик. И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам.
Ну в идеальном мире, конечно, не надо. Но в жизни часто бывает так, что приходят совсем зеленые джуны, которые готовы обучаться.
Насчет "не хочешь это осваивать" — эта статья написана для тех, кто как раз-таки хочет освоить техничку. Мне кажется, те, кто не хотят либо очень быстро уходят из IT, либо остаются на уровне лендингов и простых контентных сайтов.
Очень мало знаю примеров, когда крутой ПМ ну вот совсем не шарит в техничке, но при этом проекты у него релизятся в срок и как надо. Это исключение, подтверждающее правило.
Спасибо! На самом деле менеджеры тоже очень хотят разбираться хотя бы базово в техничке. Нам тоже не нравится разговаривать с разрабами на разных языках) Ну и хочется быть классным менеджером для своей команды
Поналетели коршуны, как обычно) автор, спасибо за лайфхацки!
Я в начале статьи описала, о каких именно ПМах речь:
Так я не продвигаю мысль, что ПМу нужно забить на все остальное и сидеть разбираться в коде. Моя мысль о том, что базис надо набирать, если хочешь продвигаться в карьере и нормально проекты закрывать. Ну и быть своей команде помощником.
В первую очередь, спасибо за такой обширный и интересный комментарий :)
Здесь, пожалуй, стоит отметить, что опиралась я на процессы внутри компании, в которой работаю последние 5+ лет.
Отсюда вытекает 2 момента:
1) во каких-то компаниях процессы выстроены иным способом, в связи с чем описанное в статье может вызывать недоумение на тему «нафига это вообще нужно ПМу» или «как вообще такой чувак стал ПМом без таких-то знаний» и т.д.;
2) есть компании со схожими с нашими процессами, в связи с чем описанное в статье может помочь определенной категории населения таких компаний :)
Про какие именно процессы я говорю:
а) аккаунт-менеджер и проджект-менеджер — это одно лицо, разделения нет, менеджер общается как с клиентом, так и с командой;
б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
в) случается такое, что ПМ, не занимавшийся разработкой, вдруг оказывается на проектах по разработке (в виду форс-мажорных обстоятельств в агентстве, собственных интересов, других причин);
г) на встречи с клиентом брать кого-либо из команды разработки нельзя, т.е. ПМ должен быть способен ответить на все технические вопросы, отработать все возражения и скользские моменты сам в 90% случаев.
Также, к счастью, у нас в компании позитивно относятся к различного рода переходам и, тем более, росту сотрудника, поэтому встречаются абсолютно разные примеры трансферов: из фронта в ПМ, из ПМ в сис.админа, из ПМ в бэка, из офис-менеджера в ПМ и т.д.
Ничего плохого в том, что ПМ что-то узнает у товарищей, учится и наблюдает за классными примерами работы, впитывает знания — мы не видим. Более того, это не встречает сопротивления или негатива и у разработчиков.
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Моя статья для менеджеров, которые хотят получить эти знания. И не знают, с чего начать. Постепенно все, кто жаждут знаний и развития, дойдут до того, что описываете вы, а потом и уйдут дальше :)
Блин, ладно, отвечу подробнее.
Темы даны для формирования общего представления о работе веб-приложений и Интернета в целом. Углубленное изучение менеджером не предполагается, по крайней мере на самом начальном этапе. С моей точки зрения данные темы помогут заложить фундамент и дадут базис глоссария для менеджера, начинающего свой путь в веб-разработке.
Таким образом, будут заложены основы понимания:
а) как работает передача данных в сети в целом;
б) как работает передача данных и как распределяется нагрузка между сервером и клиентом;
в) чем вообще отличается фронтенд от бэкенда, и какие задачи кому из разработчиков отдавать соответственно;
г) как происходит связка между фронтом и бэком, как работает API;
д) какие этапы проходит ПО и команда во время его разработки;
е) как происходит процесс доставки кода с локальной ветки разработчика на продакшн-среду, как устроен GIT и какие возможности он может дать менеджеру.
Основной профит для ПМ при изучении указанных тем:
- появляется общее представление, какие задачи ставить на фронта, какие на бэка, какие на контента и т.д.;
- появляется некоторый theoretical minimum, технический вокабуляр, с которым понимать и клиентов, и разработчиков становится попроще;
- ПМ становится на путь познания особенностей архитектуры и разработки ПО :)
Буду также рада послушать, какие темы посоветовали бы новичкам вы, или все читающие этот тред
Да, понимаю) Это, скажем так, первая итерация. Взяли самые "больные" термины для ПМов)
У меня был такой пример) В статье решила не рассказывать о нем, но если коротко, то как-то раз пришлось самой залезть в код, так как разработчик был выжат после нескольких бессонных суток. И в тот момент, сквозь слезы, я поняла, что это не так страшно, как кажется. И что код логичный и его можно читать и хотя бы верхнеуровнево понимать, за что он отвечает. Но тут мне еще повезло, у нас везде в проектах ООП, что влияет на качество кода.
Не говорю, что я теперь, знаете ли, сам своего рода разработчик, но после этого случая стало легче иметь дело с разработчиками.
Может, напишу отдельную статью об этом проекте)
Слушайте, ну тут же не знание на уровне 9999лвл подразумевается. Тут речь идет о том, чтобы банально понимать, о чем с тобой говорит разработчик. И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам.
Ну в идеальном мире, конечно, не надо. Но в жизни часто бывает так, что приходят совсем зеленые джуны, которые готовы обучаться.
Насчет "не хочешь это осваивать" — эта статья написана для тех, кто как раз-таки хочет освоить техничку. Мне кажется, те, кто не хотят либо очень быстро уходят из IT, либо остаются на уровне лендингов и простых контентных сайтов.
Очень мало знаю примеров, когда крутой ПМ ну вот совсем не шарит в техничке, но при этом проекты у него релизятся в срок и как надо. Это исключение, подтверждающее правило.
Спасибо! На самом деле менеджеры тоже очень хотят разбираться хотя бы базово в техничке. Нам тоже не нравится разговаривать с разрабами на разных языках) Ну и хочется быть классным менеджером для своей команды
Да, понимаю, что он неполный) Собирала термины со слов наших джунчиков. Спросила, какие термины у них вызывают "сбои")) Будем дорабатывать