🤔 Зачем продакту писать код
Есть две категории продакт-менеджеров: те, которые всю жизнь думают только про менеджмент и смыслы, и те, кто умеет писать код. Давайте разберёмся, зачем вторая категория вообще думает о такой вещи, как разработка своими руками - и что им это даёт.
1. Понимание майндсета разработчиков. Это - очень ценный навык для продактов и проджектов. Он даёт лучшее понимание масштаба технических рисков, сложности задач и выполнимости той или иной идеи. У менеджера исчезает иллюзия, что фраза от разраба "Я думал об этой задаче" на регулярном созвоне - это про лень. Ведь написание кода занимает всего 10-15% от всего времени задачи, основное - это поиск решений. Критики этого подхода говорят, что понимание разрабротки снижает продуктовые амбиции, но это не так. Общий майндсет рационализирует амбиции и помогает договариваться о сходимых и понятных результатах для бизнеса; 2. Головорукость. Это про возможность самому что-то быстро собрать и проверить, не дожидаясь ценного ресурса. К примеру, вы хотите быстренько визуализировать какую-то метрику. Можно дожидаться разработчиков, системных аналитиков и доступности их времени. А можно попросить доступ к БД, структуру - и написать самому SQL запрос для вывода нужных данных. Такой подход позволяет собирать MVP на коленке - прикрутить Эксельку вместо базы данных через SheetDB, IFTTT вместо крона - и смотреть, как работает то или иное решение; 3. Критический подход к архитектуре. Менеджер начинает понимать, какими бывают внутренние устройства систем - и может пообщаться со своим архитектором на одном языке. Чаще всего в крупных продуктах есть техдолг и неоптимальные решения, потому что "так сложилось". Сильный менеджер померяет влияние таких проблем на скорость разработки и качества продукта. При высоком уровне технической боли можно сменить стратегический modus operandi и выделить команде время на устранение известных проблем;
❓Но ведь начать писать коммерческий код вроде бы сложно и требует кучи времени. Что же делать? ✅ Это проще, чем кажется: 1. Для начала можно прочитать об алгоритмах для понимания мышления разработчика. Я советую "Грокаем алгоритмы" Адитьи Бхаргавы, а самым хардкорным - 1 том "Искусства программирования" Кнута; 2. Далее, если вас увлекло - пройти пару марафонов по написанию простых программ/ботов и почитать что-то по интересному вам языку (можно выбрать тот же, на котором был марафон - или самый популярный в компании); 3. Далее - базовый курс языка. Есть удобные оффлайн-форматы типа JavaRush (если хорошо с самоорганизацией) или онлайн-курсы, если вам нужно быть в темпе; При этом 1 и 2 этап займут 20% усилий и сработают по правилу Паретто (80% результата). Они дадут вам огромный буст перед коллегами, которые не готовы ступить на одну землю с разработкой.
📝 А какие ещё плюсы понимания менеджером разработки знаете вы? Пишите в комментариях 👇
P.S. Не забывайте оставлять ❤️😃
Делитесь этим постом с коллегами-продактами, чтобы узнать о других важных софт-скиллах продакта
· 09.10.2024
Полностью согласен и поддерживаю такую идею. Сам начинал как программист, а сейчас продакт. Добавлю к плюсам - это возможность быстрой оценки трудозатрат на реализацию той или иной фичи без привлечения специалистов на ранних этапах Discovery. Данный набор скиллов очень актуален при работе с частью продуктового беклога, в котором содержатся только гипотезы/цифры или сырые прототипы, без конкретики. И чем глубже понимание технических особенностей инфраструктуры проекта или продукта - тем более уверенно можно давать "менеджерский" HLA. В любом случае, команда, которая будет реализовывать проект проведет свою оценку, но чтобы они их оценили - задача должна из беклога уйти в работу. А это может занять какое то время. Дополню: финальные трудозатраты все же остаются за командой, но продакт может своей оценкой корректировать ожидания стейкхолдеров и вносить тактические изменения в свои планы, или планы смежных команд. Если фича с интеграциями - понимание как работает backend будет большим плюсом. Понимая frontend - чтение макетов или прототипов в figma меняется кардинально. Уже можно своими силами декомпозировать объем работ и уже потом прикинуть бизнес-ценность каждой поставки, скорректировать роадмап, или например убрать сложный для реализации, и сомнительный по ценности элемент (или не отказываться, а отправить в исследование чтобы оценить его ценность).
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён