Comments 19
Мой личный топ тем для погружения в особенности разработки веб-проектов выглядит так:
TCP/IP
Клиент-серверная архитектура
Фронтенд/бэкенд
API
Цикл разработки ПО
GIT
Зачем идти в ПМ - если еще не овладел этой базой?
Зачем мучать и себя и команду - если не хочешь это осваивать?
Зачем ПМу знать TCP/IP? Его не все разрабы-то знают, он где-то ооочень глубоко под всеми этими абстракциями. В лучшем случае какие-то знания нужны, чтобы определить, нужен для такого-то функционала websockets или нет.
По поводу API - а в чём тут вообще загвоздка для ПМа? Это больше к архитектору, какие сущности выставлять, какие патчить, какие в реалтайме заливать, время жизни и всё такое. Для ПМа API это всего лишь способ достать данные без загрузки веб-морды, всё.
Остальное да, хотя бы иметь представление надо. Разработчику нужны все пункты, да.
Слушайте, ну тут же не знание на уровне 9999лвл подразумевается. Тут речь идет о том, чтобы банально понимать, о чем с тобой говорит разработчик. И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам.
Блин, ладно, отвечу подробнее.
Темы даны для формирования общего представления о работе веб-приложений и Интернета в целом. Углубленное изучение менеджером не предполагается, по крайней мере на самом начальном этапе. С моей точки зрения данные темы помогут заложить фундамент и дадут базис глоссария для менеджера, начинающего свой путь в веб-разработке.
Таким образом, будут заложены основы понимания:
а) как работает передача данных в сети в целом;
б) как работает передача данных и как распределяется нагрузка между сервером и клиентом;
в) чем вообще отличается фронтенд от бэкенда, и какие задачи кому из разработчиков отдавать соответственно;
г) как происходит связка между фронтом и бэком, как работает API;
д) какие этапы проходит ПО и команда во время его разработки;
е) как происходит процесс доставки кода с локальной ветки разработчика на продакшн-среду, как устроен GIT и какие возможности он может дать менеджеру.
Основной профит для ПМ при изучении указанных тем:
- появляется общее представление, какие задачи ставить на фронта, какие на бэка, какие на контента и т.д.;
- появляется некоторый theoretical minimum, технический вокабуляр, с которым понимать и клиентов, и разработчиков становится попроще;
- ПМ становится на путь познания особенностей архитектуры и разработки ПО :)
Буду также рада послушать, какие темы посоветовали бы новичкам вы, или все читающие этот тред
Ну в идеальном мире, конечно, не надо. Но в жизни часто бывает так, что приходят совсем зеленые джуны, которые готовы обучаться.
Насчет "не хочешь это осваивать" — эта статья написана для тех, кто как раз-таки хочет освоить техничку. Мне кажется, те, кто не хотят либо очень быстро уходят из IT, либо остаются на уровне лендингов и простых контентных сайтов.
Очень мало знаю примеров, когда крутой ПМ ну вот совсем не шарит в техничке, но при этом проекты у него релизятся в срок и как надо. Это исключение, подтверждающее правило.
ПМ без технички выезжают за счет сильных софтов, лояльной и мотивированной команды) Достойная статья, было бы неплохо если бы Вы развили ее дальше, как раз на предмет степени погружения в техничку, в идеале на примере какого нибудь проекта из личного опыта
У меня был такой пример) В статье решила не рассказывать о нем, но если коротко, то как-то раз пришлось самой залезть в код, так как разработчик был выжат после нескольких бессонных суток. И в тот момент, сквозь слезы, я поняла, что это не так страшно, как кажется. И что код логичный и его можно читать и хотя бы верхнеуровнево понимать, за что он отвечает. Но тут мне еще повезло, у нас везде в проектах ООП, что влияет на качество кода.
Не говорю, что я теперь, знаете ли, сам своего рода разработчик, но после этого случая стало легче иметь дело с разработчиками.
Может, напишу отдельную статью об этом проекте)
Вообще неплохо вышло :) я правда сисадмин (devops на минималках), а не программер/разработчик, но уже общался с менеджерами достаточно, чтобы подтвердить сказанное вашими разработчиками.
PS: глоссарий штука хорошая, но его надо не "апдейтить", а все-таки дополнять.
Да, понимаю, что он неполный) Собирала термины со слов наших джунчиков. Спросила, какие термины у них вызывают "сбои")) Будем дорабатывать
Спасибо! На самом деле менеджеры тоже очень хотят разбираться хотя бы базово в техничке. Нам тоже не нравится разговаривать с разрабами на разных языках) Ну и хочется быть классным менеджером для своей команды
Глоссарий кстати классная штука. Правда, там должно быть больше терминов.
Мне к сожалению трудно понять, что может чувствовать человек в роли ПМа без технического бэкграудна по понятным причинам, но некоторые моменты из статьи непонятны
Во-первых - ПМ должен знать SDLC. Да, он у вас на 5м месте, возможно просто потому что список неотсортирован, но это must have. Не поверхностно, а именно хорошо в деталях. Поэтому его присутствие в одном списке с TCP/IP оставляет надежду, что это просто случайно и автор успеет все исправить :) Поэтому я думаю он должен стоять отдельно от этого. Ну и чего там делает GIT при наличии SDLC тоже не очень ясно? Тулите тогда уже, ну не знаю, весь DevOps. Чего только на Git смотреть?
Во-вторых - я тут посмотрел в комментарии, иногда автор лезет в код (господи, зачем), ставить задачи фронту и беку (а нет аналитика/архитектора/лидов?). Важно не пытаться чего-то понять технически, а сначала сосредоточиться на том, что делаете вы. А эти попытки - ну такое, может вам нравится :) Но как по мне - это что-то вроде стоять рядом с автомастером под машиной, если ты двигатель от коробки не отличаешь. Хотя - может ему просто приятно, если это красивая девушка :)
Список терминов - ну такое. Учить тупо и бесполезно, разве что как список того, о чем надо прочитать.
Нет в списке базовых ИТ-процессов вроде релиз менеджмент, управление изменениями и т.д. Да, это больше ИТ-пасочки, но знания этого "дерьма" сильно облегчает общение внутри большого ентерпрайза, иначе вам вообще сложно понимать, о чем все эти вроде одинаковые ИТ-шники говорят. Есть даже одна аббревиатура, но я ее приводить не буду, найдете :)
Клиент-серверная архитектура
Я обычно QA задаю простой вопрос на тему F12 в браузере. Если знает и даже более того, умеет читать всякое там написаное - значит базово ОК. С ПМом условно тоже самое. Все это вами написанное сводится к простому - если вы проходите этот вопрос, значит да - вы уже где-то на уровне джуна/мидла мануального QA по этому вопросу. Нет - я вас расстрою, вы ничего из этого списка не знаете :) Даже если выучите и про клиент-сервер, и просто TCP/IP и еще много чего.
И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам
Я из комментария взял. Ну ... такое. Обычно игра в "испорченный телефон" - это не лучшее, чем стоит заниматься. У вас есть прекрасные опции:
Взять разраба с собой и если с той стороны есть тех. спец - пусть они пообщаются. Естественно если разраб умеет в общение и понимает, почему он вообще на встрече
Узнать у разраба, как это влияет на ваши ПМские метрики (сроки, бюджет, риски, скоуп,...) И потом совместно запилить слайд (или как вы хотите это преподнести) для заказчика. Потому что вам же ж надо донести в ПМских терминах суть проблемы, так как чисто технические проблемы по идее заказчика волновать не должны (либо вы его не понимаете)
В очень редких случаях, когда это реально тех. проблема - см. пункт первый, так как яесли с той сторы будет спец, то вы будете выглядеть смешно и жалко. А зачем это вам?
В первую очередь, спасибо за такой обширный и интересный комментарий :)
Ну и чего там делает GIT при наличии SDLC тоже не очень ясно? Тулите тогда уже, ну не знаю, весь DevOps. Чего только на Git смотреть?
Здесь, пожалуй, стоит отметить, что опиралась я на процессы внутри компании, в которой работаю последние 5+ лет.
Отсюда вытекает 2 момента:
1) во каких-то компаниях процессы выстроены иным способом, в связи с чем описанное в статье может вызывать недоумение на тему «нафига это вообще нужно ПМу» или «как вообще такой чувак стал ПМом без таких-то знаний» и т.д.;
2) есть компании со схожими с нашими процессами, в связи с чем описанное в статье может помочь определенной категории населения таких компаний :)
Про какие именно процессы я говорю:
а) аккаунт-менеджер и проджект-менеджер — это одно лицо, разделения нет, менеджер общается как с клиентом, так и с командой;
б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
в) случается такое, что ПМ, не занимавшийся разработкой, вдруг оказывается на проектах по разработке (в виду форс-мажорных обстоятельств в агентстве, собственных интересов, других причин);
г) на встречи с клиентом брать кого-либо из команды разработки нельзя, т.е. ПМ должен быть способен ответить на все технические вопросы, отработать все возражения и скользские моменты сам в 90% случаев.
Также, к счастью, у нас в компании позитивно относятся к различного рода переходам и, тем более, росту сотрудника, поэтому встречаются абсолютно разные примеры трансферов: из фронта в ПМ, из ПМ в сис.админа, из ПМ в бэка, из офис-менеджера в ПМ и т.д.
Ничего плохого в том, что ПМ что-то узнает у товарищей, учится и наблюдает за классными примерами работы, впитывает знания — мы не видим. Более того, это не встречает сопротивления или негатива и у разработчиков.
Нет в списке базовых ИТ-процессов вроде релиз менеджмент, управление изменениями и т.д.
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Я обычно QA задаю простой вопрос на тему F12 в браузере. Если знает и даже более того, умеет читать всякое там написаное - значит базово ОК. С ПМом условно тоже самое. Все это вами написанное сводится к простому - если вы проходите этот вопрос, значит да - вы уже где-то на уровне джуна/мидла мануального QA по этому вопросу. Нет - я вас расстрою, вы ничего из этого списка не знаете :) Даже если выучите и про клиент-сервер, и просто TCP/IP и еще много чего.
Моя статья для менеджеров, которые хотят получить эти знания. И не знают, с чего начать. Постепенно все, кто жаждут знаний и развития, дойдут до того, что описываете вы, а потом и уйдут дальше :)
б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
Тогда вся статья просто не имеет смысла, так как вы закрываете две роли и соответственно вопрос наличия тех компетенций очевидно транформируется в необходимость иметь компетенции, достаточные для роли как для ПМа, так и для аналитика
А для аналитика, особенно по веб приложениям, вам реально нужны не глоссарий, а базовые знания :)
То, что вы описали - совершенно недостаточно :)
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Это "техничка" для любого, кто занимает руководящую должность в ИТ :)
Наслаждайтесь: ITIL - Wikipedia . Конечно, условно сертифицированным теоретиком быть не обязательно, но не знать базы ... разве что работать на небольших проектах, и то ... там все тоже, просто может быть, что несколько позиций закрываются одним человеком.
аккаунт-менеджер и проджект-менеджер
Аккаунт менеджер - это про другое. Он отвечает за клиента в целом (с которым может быть 5 проектов) и его ответственность: удовлетворенность клиента и чтобы он не ушел в закат. Возможны вы еще и аккаунт ведете, в дополнение к роли аналитика, кто знает. Но обычно это другой человек. В небольших конторах это может быть комерс, так как держать "команду" аккаунтов тупо нет денег.
Иногда это сейл, который ведет своего клиента и "гоняет" других сейлов от него. Но делать из ПМа еще и аккаунта - это интересно :)
при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/
шо за п....ц у вас там творится??
на встречи с клиентом брать кого-либо из команды разработки нельзя
что за ПИ....Ц у вас там творится!?????
Для начала бы определиться что имеется под менеджер проекта, т.к то кем он должен быть по мнению PMI и то что мы в 90% случаях видим в IT - это о разном. В IT это в большей степени координаторы проектов, они занимаются командой и процессами и проксированием запросов от бизнеса к инженерам. Отвественности за бизнес результаты проекта - нет, отвественности за бюджетирование нет, список можно продолжить...
Так вот менеджер в позиции что должен менеджер солидарен с PMI. Они представляют навыки менеджера в виде треугольника, в нем есть интересная грань - business accumen (далее цитата с сайта PMI):
Business Acumen: Professionals with business acumen understand the macro and micro influences in their organization and industry and have the function‑specific or domain‑specific knowledge to make good decisions. Professionals at all levels need to be able to cultivate effective decision‑making and understand how their projects align with the big picture of broader organizational strategy and global trends.
Менеджер должен сам определить набор навыков которые гарантируют ему возможность принятия правильных решение. Если ему нужно знать как работает kafka streams (непоняно зачем) - он узнает, если нужно углубится в модель OSI и все ее уровне - сделает, но это должно решать вопросы.
Коммуникация и ее успешность не должна быть завязана на параметрах: обладает или нет человек техническими знаниями. Иначе это уже похоже на попытки вступления его в чужеродное племя, где для того что бы стать одним из его членов нужно заколоть носорога в полночь шылом быть инженером.
А если она у вас не может быть построена иным способом - у вас проблемы..
Я в начале статьи описала, о каких именно ПМах речь:
Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.
Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.
Так я не продвигаю мысль, что ПМу нужно забить на все остальное и сидеть разбираться в коде. Моя мысль о том, что базис надо набирать, если хочешь продвигаться в карьере и нормально проекты закрывать. Ну и быть своей команде помощником.
Чушь несусветная. Девушка, не вводите людей в заблуждение. Здесь описаны роли аккаунта, аналитика и ещё кого-то. Причем тут ПМ? То что в компании построены процессы через одно место это вопрос к ее менеджменту, а не к скилам ПМ))
Нужен ли менеджеру проектов технический бэкграунд и как его нарабатывать? Исповедь ПМа и опрос разработчиков