Привет, Хабр. Меня зовут Марина Заботина, я аккаунт-директор в диджитал-агентстве Далее. Сегодня хочу поднять животрепещущую тему — зачем и как прокачивать технический бэкграунд проджект-менеджеру. В статье рассмотрю:
насколько техническая грамотность нужна для управления проектами, связанными с разработкой.
с какими сложностями приходится сталкиваться, когда тех бэка нет.
лайфхаки, чтобы стать бро для команды вместо того, чтобы получать косые взгляды в спину.
приведу примеры из собственного опыта и конкретный план действий.
Пара ремарок:
Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.
Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.
Почему сложно без технической подкованности и на что влияет ее отсутствие
Я не раз наблюдала, как менеджеров, работавших до этого только с дизайном и контентом, перекидывали на разработку. И как быстро волосы их седели, глаза наполнялись слезами, а рот — новопасситом. Потому что без элементарных базовых знаний было не выжить.
Это случилось и со мной в начале менеджерского пути. Когда я впервые пришла на проект с разработкой, мне выпал хардовый уровень. Я вела проект, который лидирует технический директор. Сразу бинго: мегамозг, светило науки, Ferrari 250 GTO в мире IT, способен выучить любой язык программирования за несколько дней (и это не шутка). Примерно так я себя ощущала в тот момент:
Но в коммуникации человек этот был сложным: говорил только техническим языком и выжимками из логов. Так что я очень быстро перестала задавать вопросы по любой непонятной мне теме. То есть, по любой.
Казалось бы — что с того, что техдир не хочет с тобой общаться? Вы же не в друзья друг другу набиваетесь, а работаете. Но дело как раз в том, что нехватка взаимопонимания с техлидом, разработчиком или командой в целом влияет на проект.
Качественно передать информацию клиенту не удается. Объяснить можешь только контуры проекта и то, что тебе сказали, причем, с минимальным уровнем понимания. Если у клиента возникают вопросы — ответить на них часто не можешь. Нужно бежать к техлиду, а он, как мы помним, на вопросы отвечать не хочет. А если ответит, то понимания это не прибавит.
Клиент может почувствовать, что менеджер не очень подкован — страдает доверие. Команда видит, что ПМ в теме не разбирается — может ли он чем-то управлять? Такая ситуация продуктивности не прибавляет.
Подытожу. На что влияет отсутствие базовых технических знаний:
не всегда понятно, к кому из команды идти с той или иной задачей: это для синиора или джуна/ а это вообще на фронт или на бэк?
лишнее время проджекта, команды и клиента. Приходится адресовать даже базовые вопросы команде, вместо того, чтобы решать их самостоятельно.
качество погружения в проект и качество коммуникации с командой и клиентом ниже.
нет возможности фильтровать задачи и пожелания клиента по технической части, если они неосуществимы.
самостоятельно оценить объем задачи сложно.
неуверенность, страх, боль и слезы — в постоянном стрессе быть продуктивным и развиваться сложно.
Что говорят в интернетах
Чтобы удостовериться, что мое мнение — это не только мнение, а реальность, пришлось даже зайти в интернет. Еще в 2020 году на Хабре провели опрос, где выясняли, какого уровня должен быть технический бэкграунд у менеджера. 63% опрошенных ответили, что нужна общая техническая грамотность. В комментариях под тем опросом разгорелся занятный холивар. Почитайте на досуге.
Данных опроса мне было недостаточно — требовались детали. Поэтому я провела опрос среди коллег (нас больше 320 человек). Добавила к нему опрос в нашем ТГ-канале и запушили еще один на Хабре и vc.ru.
У менеджеров мы узнавали, как они оценивают свой уровень технической грамотности, какие сложности видят в общении с разработчиками, как борются с трудностями. У разработчиков спрашивали, как влияет наличие или отсутствие этого самого бэкграунда на работу и готовы ли они помогать неокрепшим менеджерам превращаться в суровых технарей.
Чувствуют ли проджекты нехватку технических знаний: результаты опроса
Опрос ПМов показал, что 100% тех, кто боится задавать вопросы разработчикам, оценили уровень своей технической подкованности как нулевой. Смелее себя чувствуют те, у кого есть базовая или продвинутая техническая грамотность.
А вот некоторые ответы менеджеров на вопрос о том, какие трудности у них возникают из-за недостатка технического бэкграунда:
Мнение разработчиков про технический бэкграунд менеджеров: результаты опроса
Окей, вроде мои выводы подтвердились. Отсутствие технического бэкграунда влияет и на коммуникацию с командой, и на качество общения с клиентом.
А что по этому поводу думают сами разработчики? Мы спросили, чувствуют ли они разницу в работе с технически подкованным и нулевым менеджером. Подавляющее большинство (81,8%) ответило утвердительно.
Приведу ответы разработчиков на вопрос: «Можете рассказать, в чем вы видите разницу в общении с технически подкованным ПМ, если она есть?» В двух словах: разница в понимании.
Важен не столько технический бэкграунд, сколько понимание того, как всё работает. Если человек понимает, то он еще на самой ранней стадии даёт фидбек клиенту о нереалистичности, а не приходит с идеей, на которую получает ответ от технаря «это работает не так», отвлекая того по пустякам».
Технически подкованного менеджера очень сложно обмануть в оценке задач (объективно, а не то чтобы я пытался).
Не нужно объяснять банальные вещи.
В переводе задач с клиентского на разрабский; в фильтрации задач. Технически подкованный менеджер сам уточнит все необходимые моменты перед тем, как давать задачу разработчику.
Те же разработчики ответили, что дает наличие технической базы менеджеру.
Выводы из опросов
Техническая подкованность важна. Без нее сложнее общаться и с клиентом, и с разработчиками. Приходится тратить больше времени на погружение в детали проекта. А если есть базовые знания — продуктивность растет, ресурсами легче управлять, обратную связь по задачам может дать сам менеджер, не отвлекая разработчиков.
Дополнительно к опросам я провела мини-исследование по 50 вакансиям проджект-менеджеров в заказной разработке. В 39 из них технический бэкграунд нужен, в 4 требовалось еще и умение кодить, 7 компаний готовы взять на работу человека без базовых технических знаний и всему его научить.
То есть, становиться супер-профи не нужно. Но если у вас классные софты, и вы при этом способны вести осмысленный диалог с разработчиками — то будете у работодателя в топе. И, как ни крути, набирать базу придется. Даже агентства, готовые взять ПМ без базовых знаний, планируют ньюкамера обучать, следуя заветам товарища Ильича.
Как нарабатывать технический бэкграунд
Теперь, когда мои гипотезы подтвердились и мы пришли к тому, что техническая грамотность помогает делу и нервной системе менеджера, поговорим о том, как её нарабатывать и что этому может помешать.
Побороть страх
Как вы помните, боятся подходить к разработчикам с вопросами те, у кого нулевой технический бэкграунд. Почему так? Дело в том, что менеджера в начале его пути преследуют простые человеческие страхи. Страх показаться глупым, задавать вопросы, ответы на которые для других очевидны, и из-за этого столкнуться с негативом. Некоторые даже опасаются, что их уволят за профнепригодность. Да и синдром самозванца никто не отменял.
Что с этим делать? Во-первых, обращусь к результатам опроса. 100% опрошенных нами разработчиков готовы помогать менеджерам, если те приходят с вопросами.
А есть ли случаи, когда разработчики не хотят помогать менеджеру разбираться? Конечно, есть. Если менеджер не хочет погружаться и реально разбираться в теме, задает одни и те же вопросы, не запоминая ответы, не хочет учиться самостоятельно — помогать ему будут с меньшим желанием или не будут вовсе.
Итого — если вы правда хотите наработать технические знания, разработчики всегда готовы вам помочь.
Самостоятельно искать нужную информацию
Сначала изучите вопрос самостоятельно. Ищите базовые материалы по теме, читайте Хабр, идите на форумы. Основная задача — понять предметную область, по которой не хватает информации. Отлично помогает YouTube: запросы из разряда «разбор темы для чайников» действительно работают. Где-то в мире живет индус, который уже разобрал вашу тему и выложил 20-ти минутный ролик с понятным разбором. И это не шутка.
Если у вас хороший уровень английского, изучайте зарубежные источники. В англоязычном интернете вы с большей вероятностью найдете объяснение необходимых вам нюансов, да и материалов по теме там, скорее всего, будет больше.
Выбирать правильное время для общения с разработчиками
Если к техлиду проекта идти страшно, найдите более лояльного товарища среди разрабов и обращайтесь к нему. Лайфхак — если у разработчика не хватает на вас времени, поймайте его во время обеда, перерыва на кофе или в курилке.
У разработчиков есть две фазы работы. Активная — когда они непосредственно работают над задачей, в это время переключаться на что-то другое для них нежелательно. И фаза осмысления — пошел выпить кофе, вроде за кодом не сидишь, но задачу обдумываешь. Эта вторая фаза — возможность для ПМов что-то выяснить, задать вопросы, обсудить задачу и способы ее решения. Вам полезно, а разработчику приятно видеть заинтересованность в его работе.
Учиться защищать мнение разработчиков перед клиентами
Стратегия, которая повысит уровень погруженности в технические детали и сделает вас настоящим бро в глазах разработчиков.
Для этого вам нужно хорошо разбираться в теме и задавать правильные вопросы. Правильные — значит те, которые связаны не с технологией в целом, а с ее применением на вашем проекте.
Когда клиент хочет фичу Х, а разработчик говорит, что это невозможно или возможно, но с нюансами, выясняйте, почему так и как это объяснить клиенту. Но не с тем, чтобы заставить разработчика изменить мнение, а чтобы собрать аргументы для его защиты перед клиентом.
Для этого вам нужно разобраться в теме максимально. Поэтому задавайте им самое большое количество уточняющих вопросов, которые только возможно. Аргумент тут простой: «Если я это пойму, я смогу твое мнение защитить».
Преграды на пути
Схема получения драгоценных технических знаний не такая тривиальная, как кажется. Менеджеры, которые только начинают путь, сталкиваются с тремя ограничениями.
Ограниченность по времени
Мы работаем в условиях цейтнотов, сроков, многозадачности. Поток информации большой, нужно успевать его обрабатывать. Возможность выделить конкретное время на изучение технической части выдается крайне редко.
Сложный язык
Большая часть информации о технологиях, которую вы встретите в интернете, написана техническим языком и для технарей. Когда языка не понимаешь, приходится гуглить не только про саму технологию, но и термины, которые используют для ее объяснения. Так, забив в поиске «Что такое DNS», через сутки можно обнаружить себя с трясущимися от кофе руками, в поту изучающим топологию сети.
Устаревание знаний
Пункт актуален не только для менеджеров, но и для всех в IT. Часто, когда заходишь читать про какую-то технологию, оказывается, что речь в статье про версию-прапрапрабабушку современной технологии. И кстати — она не поддерживается с 2011 года. Если вы на старте работы с проектом что-то изучили по конкретным темам, не факт, что через год, столкнувшись с похожим стэком, сможете разобраться в деталях. Возможно, технологии убегут далеко вперед.
Хорошая новость в том, что этих ограничений бояться не следует — достаточно о них знать. Так вы не станете вешать на себя дополнительную нагрузку и не будете расстраиваться, когда чего-то не успеваете или не понимаете. Как писала выше: общайтесь с командой. Конечно, ролики на Youtube, статьи и Хабр помогут разобраться с базой, но только разработчик на вашем проекте сможет объяснить, что конкретно пошло не так или почему применить ту или иную технологию невозможно.
Советы и рекомендации
Если вы только встали на этот сложный путь, рекомендую следующее:
Стараться погружаться в особенности проектов, использовать софт-скилы, чтобы наладить контакт с командой.
Задавать вопросы разработчикам.
Набирать теоретикал минимум на Хабре и Ютубе.
Мой личный топ тем для погружения в особенности разработки веб-проектов выглядит так:
TCP/IP
Клиент-серверная архитектура
Фронтенд/бэкенд
API
Цикл разработки ПО
GIT
В зависимости от специфики проектов, у каждого будет свой топ. Мой список не универсальный.
Если базовые знания уже есть, продолжайте развиваться:
Не прекращайте задавать вопросы
Учитесь защищать мнение разработчиков перед клиентом
Попробуйте читать код. Звучит страшно, но хотя бы базово это надо уметь делать, чтобы лучше понимать разработчиков.
Разбирайтесь в нюансах.
В финале делюсь глоссарием основных понятий, который собрала вместе с командой. Глоссарий написан менеджерами для менеджеров. Так что очень надеюсь, что благодаря ему слез и нервов будет меньше, а уверенных ПМов — больше. А если кто-то захочет дополнить мой словарь другими полезными терминами — пишите в личку.
Комментарии (19)
vesper-bot
16.05.2024 10:36Вообще неплохо вышло :) я правда сисадмин (devops на минималках), а не программер/разработчик, но уже общался с менеджерами достаточно, чтобы подтвердить сказанное вашими разработчиками.
PS: глоссарий штука хорошая, но его надо не "апдейтить", а все-таки дополнять.
Marinzana Автор
16.05.2024 10:36Да, понимаю, что он неполный) Собирала термины со слов наших джунчиков. Спросила, какие термины у них вызывают "сбои")) Будем дорабатывать
Marinzana Автор
16.05.2024 10:36Спасибо! На самом деле менеджеры тоже очень хотят разбираться хотя бы базово в техничке. Нам тоже не нравится разговаривать с разрабами на разных языках) Ну и хочется быть классным менеджером для своей команды
YuliaZubova
16.05.2024 10:36Глоссарий кстати классная штука. Правда, там должно быть больше терминов.
Marinzana Автор
16.05.2024 10:36Да, понимаю) Это, скажем так, первая итерация. Взяли самые "больные" термины для ПМов)
Batalmv
16.05.2024 10:36+1Мне к сожалению трудно понять, что может чувствовать человек в роли ПМа без технического бэкграудна по понятным причинам, но некоторые моменты из статьи непонятны
Во-первых - ПМ должен знать SDLC. Да, он у вас на 5м месте, возможно просто потому что список неотсортирован, но это must have. Не поверхностно, а именно хорошо в деталях. Поэтому его присутствие в одном списке с TCP/IP оставляет надежду, что это просто случайно и автор успеет все исправить :) Поэтому я думаю он должен стоять отдельно от этого. Ну и чего там делает GIT при наличии SDLC тоже не очень ясно? Тулите тогда уже, ну не знаю, весь DevOps. Чего только на Git смотреть?
Во-вторых - я тут посмотрел в комментарии, иногда автор лезет в код (господи, зачем), ставить задачи фронту и беку (а нет аналитика/архитектора/лидов?). Важно не пытаться чего-то понять технически, а сначала сосредоточиться на том, что делаете вы. А эти попытки - ну такое, может вам нравится :) Но как по мне - это что-то вроде стоять рядом с автомастером под машиной, если ты двигатель от коробки не отличаешь. Хотя - может ему просто приятно, если это красивая девушка :)
Список терминов - ну такое. Учить тупо и бесполезно, разве что как список того, о чем надо прочитать.
Нет в списке базовых ИТ-процессов вроде релиз менеджмент, управление изменениями и т.д. Да, это больше ИТ-пасочки, но знания этого "дерьма" сильно облегчает общение внутри большого ентерпрайза, иначе вам вообще сложно понимать, о чем все эти вроде одинаковые ИТ-шники говорят. Есть даже одна аббревиатура, но я ее приводить не буду, найдете :)
Клиент-серверная архитектура
Я обычно QA задаю простой вопрос на тему F12 в браузере. Если знает и даже более того, умеет читать всякое там написаное - значит базово ОК. С ПМом условно тоже самое. Все это вами написанное сводится к простому - если вы проходите этот вопрос, значит да - вы уже где-то на уровне джуна/мидла мануального QA по этому вопросу. Нет - я вас расстрою, вы ничего из этого списка не знаете :) Даже если выучите и про клиент-сервер, и просто TCP/IP и еще много чего.
И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам
Я из комментария взял. Ну ... такое. Обычно игра в "испорченный телефон" - это не лучшее, чем стоит заниматься. У вас есть прекрасные опции:
Взять разраба с собой и если с той стороны есть тех. спец - пусть они пообщаются. Естественно если разраб умеет в общение и понимает, почему он вообще на встрече
Узнать у разраба, как это влияет на ваши ПМские метрики (сроки, бюджет, риски, скоуп,...) И потом совместно запилить слайд (или как вы хотите это преподнести) для заказчика. Потому что вам же ж надо донести в ПМских терминах суть проблемы, так как чисто технические проблемы по идее заказчика волновать не должны (либо вы его не понимаете)
В очень редких случаях, когда это реально тех. проблема - см. пункт первый, так как яесли с той сторы будет спец, то вы будете выглядеть смешно и жалко. А зачем это вам?
Marinzana Автор
16.05.2024 10:36В первую очередь, спасибо за такой обширный и интересный комментарий :)
Ну и чего там делает GIT при наличии SDLC тоже не очень ясно? Тулите тогда уже, ну не знаю, весь DevOps. Чего только на Git смотреть?
Здесь, пожалуй, стоит отметить, что опиралась я на процессы внутри компании, в которой работаю последние 5+ лет.
Отсюда вытекает 2 момента:
1) во каких-то компаниях процессы выстроены иным способом, в связи с чем описанное в статье может вызывать недоумение на тему «нафига это вообще нужно ПМу» или «как вообще такой чувак стал ПМом без таких-то знаний» и т.д.;
2) есть компании со схожими с нашими процессами, в связи с чем описанное в статье может помочь определенной категории населения таких компаний :)
Про какие именно процессы я говорю:
а) аккаунт-менеджер и проджект-менеджер — это одно лицо, разделения нет, менеджер общается как с клиентом, так и с командой;
б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
в) случается такое, что ПМ, не занимавшийся разработкой, вдруг оказывается на проектах по разработке (в виду форс-мажорных обстоятельств в агентстве, собственных интересов, других причин);
г) на встречи с клиентом брать кого-либо из команды разработки нельзя, т.е. ПМ должен быть способен ответить на все технические вопросы, отработать все возражения и скользские моменты сам в 90% случаев.
Также, к счастью, у нас в компании позитивно относятся к различного рода переходам и, тем более, росту сотрудника, поэтому встречаются абсолютно разные примеры трансферов: из фронта в ПМ, из ПМ в сис.админа, из ПМ в бэка, из офис-менеджера в ПМ и т.д.
Ничего плохого в том, что ПМ что-то узнает у товарищей, учится и наблюдает за классными примерами работы, впитывает знания — мы не видим. Более того, это не встречает сопротивления или негатива и у разработчиков.
Нет в списке базовых ИТ-процессов вроде релиз менеджмент, управление изменениями и т.д.
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Я обычно QA задаю простой вопрос на тему F12 в браузере. Если знает и даже более того, умеет читать всякое там написаное - значит базово ОК. С ПМом условно тоже самое. Все это вами написанное сводится к простому - если вы проходите этот вопрос, значит да - вы уже где-то на уровне джуна/мидла мануального QA по этому вопросу. Нет - я вас расстрою, вы ничего из этого списка не знаете :) Даже если выучите и про клиент-сервер, и просто TCP/IP и еще много чего.
Моя статья для менеджеров, которые хотят получить эти знания. И не знают, с чего начать. Постепенно все, кто жаждут знаний и развития, дойдут до того, что описываете вы, а потом и уйдут дальше :)
Batalmv
16.05.2024 10:36+1б) при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/кто-либо еще, таким образом ПМ должен уметь «переводить с клиентского на технический» и наоборот, уметь декомпозировать задачу, понимать технические особенности и к кому с чем вообще подаваться;
Тогда вся статья просто не имеет смысла, так как вы закрываете две роли и соответственно вопрос наличия тех компетенций очевидно транформируется в необходимость иметь компетенции, достаточные для роли как для ПМа, так и для аналитика
А для аналитика, особенно по веб приложениям, вам реально нужны не глоссарий, а базовые знания :)
То, что вы описали - совершенно недостаточно :)
Могу дополнить этот комментарий: не хватает риск-менеджмента и других важных для ПМ хардов. Но! Речь в данной статье идет исключительно о знаниях по техничке.
Это "техничка" для любого, кто занимает руководящую должность в ИТ :)
Наслаждайтесь: ITIL - Wikipedia . Конечно, условно сертифицированным теоретиком быть не обязательно, но не знать базы ... разве что работать на небольших проектах, и то ... там все тоже, просто может быть, что несколько позиций закрываются одним человеком.
аккаунт-менеджер и проджект-менеджер
Аккаунт менеджер - это про другое. Он отвечает за клиента в целом (с которым может быть 5 проектов) и его ответственность: удовлетворенность клиента и чтобы он не ушел в закат. Возможны вы еще и аккаунт ведете, в дополнение к роли аналитика, кто знает. Но обычно это другой человек. В небольших конторах это может быть комерс, так как держать "команду" аккаунтов тупо нет денег.
Иногда это сейл, который ведет своего клиента и "гоняет" других сейлов от него. Но делать из ПМа еще и аккаунта - это интересно :)
Ivan22
16.05.2024 10:36+3при постановке задач команде практически или вовсе не используется аналитик/архитектор/лид/
шо за п....ц у вас там творится??
на встречи с клиентом брать кого-либо из команды разработки нельзя
что за ПИ....Ц у вас там творится!?????
reinmaker1990
16.05.2024 10:36+1Для начала бы определиться что имеется под менеджер проекта, т.к то кем он должен быть по мнению 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 и все ее уровне - сделает, но это должно решать вопросы.
Коммуникация и ее успешность не должна быть завязана на параметрах: обладает или нет человек техническими знаниями. Иначе это уже похоже на попытки вступления его в чужеродное племя, где для того что бы стать одним из его членов нужнозаколоть носорога в полночь шыломбыть инженером.
А если она у вас не может быть построена иным способом - у вас проблемы..Marinzana Автор
16.05.2024 10:36Я в начале статьи описала, о каких именно ПМах речь:
Эту тему рассматриваю в контексте ведения проектов в заказной разработке: не только дизайн, контент, но и проекты интернет-магазинов, веб-приложений.
Роль проджекта на проекте заключается не только в управлении командой, но и в непосредственном общении с клиентом. Для клиента менеджер — основное контактное лицо. Это значит, ему нужно защищать решения команды, обосновывать выбор тех или иных технологий. А для этого — советоваться с разработчиками, и на каком-то уровне, но разбираться в теме.
Так я не продвигаю мысль, что ПМу нужно забить на все остальное и сидеть разбираться в коде. Моя мысль о том, что базис надо набирать, если хочешь продвигаться в карьере и нормально проекты закрывать. Ну и быть своей команде помощником.
Thisnicknameisbusy
16.05.2024 10:36Чушь несусветная. Девушка, не вводите людей в заблуждение. Здесь описаны роли аккаунта, аналитика и ещё кого-то. Причем тут ПМ? То что в компании построены процессы через одно место это вопрос к ее менеджменту, а не к скилам ПМ))
1uxor
Зачем идти в ПМ - если еще не овладел этой базой?
Зачем мучать и себя и команду - если не хочешь это осваивать?
vesper-bot
Зачем ПМу знать TCP/IP? Его не все разрабы-то знают, он где-то ооочень глубоко под всеми этими абстракциями. В лучшем случае какие-то знания нужны, чтобы определить, нужен для такого-то функционала websockets или нет.
По поводу API - а в чём тут вообще загвоздка для ПМа? Это больше к архитектору, какие сущности выставлять, какие патчить, какие в реалтайме заливать, время жизни и всё такое. Для ПМа API это всего лишь способ достать данные без загрузки веб-морды, всё.
Остальное да, хотя бы иметь представление надо. Разработчику нужны все пункты, да.
Marinzana Автор
Слушайте, ну тут же не знание на уровне 9999лвл подразумевается. Тут речь идет о том, чтобы банально понимать, о чем с тобой говорит разработчик. И потом уметь донести это до клиента, особенно если какие-то серьезные технические ограничения есть по его хотелкам.
Marinzana Автор
Блин, ладно, отвечу подробнее.
Темы даны для формирования общего представления о работе веб-приложений и Интернета в целом. Углубленное изучение менеджером не предполагается, по крайней мере на самом начальном этапе. С моей точки зрения данные темы помогут заложить фундамент и дадут базис глоссария для менеджера, начинающего свой путь в веб-разработке.
Таким образом, будут заложены основы понимания:
а) как работает передача данных в сети в целом;
б) как работает передача данных и как распределяется нагрузка между сервером и клиентом;
в) чем вообще отличается фронтенд от бэкенда, и какие задачи кому из разработчиков отдавать соответственно;
г) как происходит связка между фронтом и бэком, как работает API;
д) какие этапы проходит ПО и команда во время его разработки;
е) как происходит процесс доставки кода с локальной ветки разработчика на продакшн-среду, как устроен GIT и какие возможности он может дать менеджеру.
Основной профит для ПМ при изучении указанных тем:
- появляется общее представление, какие задачи ставить на фронта, какие на бэка, какие на контента и т.д.;
- появляется некоторый theoretical minimum, технический вокабуляр, с которым понимать и клиентов, и разработчиков становится попроще;
- ПМ становится на путь познания особенностей архитектуры и разработки ПО :)
Буду также рада послушать, какие темы посоветовали бы новичкам вы, или все читающие этот тред
Marinzana Автор
Ну в идеальном мире, конечно, не надо. Но в жизни часто бывает так, что приходят совсем зеленые джуны, которые готовы обучаться.
Насчет "не хочешь это осваивать" — эта статья написана для тех, кто как раз-таки хочет освоить техничку. Мне кажется, те, кто не хотят либо очень быстро уходят из IT, либо остаются на уровне лендингов и простых контентных сайтов.
Очень мало знаю примеров, когда крутой ПМ ну вот совсем не шарит в техничке, но при этом проекты у него релизятся в срок и как надо. Это исключение, подтверждающее правило.
BuHHTuK
ПМ без технички выезжают за счет сильных софтов, лояльной и мотивированной команды) Достойная статья, было бы неплохо если бы Вы развили ее дальше, как раз на предмет степени погружения в техничку, в идеале на примере какого нибудь проекта из личного опыта
Marinzana Автор
У меня был такой пример) В статье решила не рассказывать о нем, но если коротко, то как-то раз пришлось самой залезть в код, так как разработчик был выжат после нескольких бессонных суток. И в тот момент, сквозь слезы, я поняла, что это не так страшно, как кажется. И что код логичный и его можно читать и хотя бы верхнеуровнево понимать, за что он отвечает. Но тут мне еще повезло, у нас везде в проектах ООП, что влияет на качество кода.
Не говорю, что я теперь, знаете ли, сам своего рода разработчик, но после этого случая стало легче иметь дело с разработчиками.
Может, напишу отдельную статью об этом проекте)