Всем привет! Я — Егор, менеджер проектов в Secreate. Мой стаж в менеджменте — уже 7 лет, поэтому знаний в этой области накопилось на целый лонгрид. Сегодня на реальных кейсах поделюсь, как решать проблемы в проектах по разработке, что должен знать PM и как этому учиться. В конце статьи — ссылка на чек-лист с ключевыми качествами плохого и хорошего…
интересно предложение "В итоге я сел дописывать симулятор сам".
наверное были проекты, где не знали язык программирования на котором был сделан проект. как справлялись со сложностями, когда невозможно самому быстро дописать функционал?
было бы интересно почитать, если есть такой кейс.
руководил проектом, где сам выступал и в роли бэкэндера, фронтенд (приложение под андроид) был на аутсорсе. поменял фрондентендера во время разработки. до того как нашел нового разраба, сам хотел выучить kotlin.
проект завершили нормально, но испытал такой стресс, что сейчас нет большого желания брать проекты, где я не разбираюсь в ЯП проекта.
и боюсь, если уходить в менеджеры, буду тянуть команду в сторону языка программирования, который сам знаю - не знаю хорошо это или не очень.
Я вот например против того, чтобы менеджер глубоко понимал суть работы программистов как раз из-за таких кейсов. В конце концов история с "самому быстрее, чем тупым объяснять" - самая губительная для руководителя и организатора. Конечно, всегда проще самому, если умеешь. Но на этом далеко не уехать)
Хотя конечно иногда все читерят.
Можно не знать ЯП, да и то, что так получилось - лишь удачное стечение обстоятельств.
Тут главное как можно раньше обнаружить проблему, а дальше уже можно решать дополнительными ресурсами, коммуникациями с командой, с клиентом - всегда есть выход. Иногда команда может промолчать о проблеме, которую, вероятно, ПМ сможет решить.
Однако, волей-неволей, работая над проектами с одним стеком, ПМ все равно может стать заложником одного стека - понимая ограничения и функциональность той же ноды, при этом боясь прикоснуться к проектам на PHP и тд. Тут надо пробовать, брать разносторонние проекты и быть в контакте с командой. Конечно, если проекты на конкретном стеке ПМ не вел - нужно уделить должное внимание этому на пресейле: советоваться с техлидами, разработчиками на данном ЯП или фреймворке. Далее уже квалифицированная команда будет в помощь - важно всегда быть с ней на контакте и постепенно разбираться в вопросе. В конце концов - логика везде +- одинаковая:)