petros_aramovich
@petros_aramovich
IT Project Manager

Смириться или искать?

Работаю PM-ом полтора года.
За все время были и есть проекты, которые разрабатывали до меня.
Реализованы они через n-ое место, куча багов и прочего.
Понимаю, что это обычное дело и это не новость в digital.
Перечитал кучу статей по этой теме, изучал причины и советы.
Вопрос к ПМ-ам:
- Смириться с таким положением дел и принять как данность? Если так, то как вы к этому пришли? Получилось ли смириться и меньше париться о таких вещах?
- Или же все таки есть проекты, которые менее проблемные и можно заниматься развитием/поддержкой с меньшей нервотрепкой?

Само ведение проектов и есть нервотрепка, это суть ПМ-ского дела.
Но когда видишь проекты, от которых хочешь выколоть глаза, встаешь в ступор...
От того мне нужно понимание, как с этим поступить или как относиться к этому на пути Пм-а.
Спасибо!
  • Вопрос задан
  • 127 просмотров
Пригласить эксперта
Ответы на вопрос 3
Sanes
@Sanes
Но когда видишь проекты, от которых хочешь выколоть глаза, встаешь в ступор...

Работа такая. Донеси до руководителя по каждому проекту расходы. И какие варианты решения ты предлагаешь. Руководитель решит, что с этим делать.
Ответ написан
MetaAbstract
@MetaAbstract
Архитектор информационных систем и баз данных. Ful
Можно взять в союзники архитектора/аналитика и тимлида и привести проекты в порядок. С таким результатом можно смело смотреть в будущее.
Ответ написан
Комментировать
Vovakorn
@Vovakorn
Менеджер с десятилетним стажем в ИТ
Есть проекты, где не хочется выколоть глаза, но там скучно и неинтересно.
Есть проекты, где хочется, но на них интересно работать.

Попробуйте понять почему вас это расстраивает? Вам не нравится, что кому-то всё равно? Станьте тем, кому нет. Вам не нравится работать с некомпетентные людьми? Нарабатывайте резюме и меняйте работу. Смиряться нельзя, но ваше "несмирение" не должно быть просто позой. Вы должны не только предлагать улучшения, но и продавать их заказчику (он может быть как внутренний, так и внешний). Зачем ему это надо, ак это изменит его бизнес? Этот баг существует 3 года и никак не влияет на бизнес-показатели. Зачем его убирать?

Возможно причины проблем на проектах в компромиссах, баги и недоработки могли произойти не потому что кто-то плохой или криворукий, а из-за сроков/бюджетов/задач. (Хотя возможно, конечно, кто-то и криворукий).

Процитирую здесь Фёдора Борщёва, хоть этот текст для программистов, мне кажется, что это частично ответ на вопрос:

Вопрос: Я написал код на основе того, что уже был в проекте, но на ревью мне сказали, что этот код был плохой и надо улучшать. Как сразу понимать, хороший код ты пишешь или нет?

Ответ: У меня нет универсального совета, как отличать хороший код от плохого — в каждой команде и каждом проекте требования уникальны. Они обусловлены инженерной культурой, умением ребят договариваться с бизнесом и нанимать правильных людей, спецификой бизнес-домена и кучей всего ещё.

Могу дать другой совет — старайтесь улучшать всё. Если вы старше мидла — подходы к кодированию на проекте для вас уже не могут быть константой. Даже на самом чистом проекте с самой высокой инженерной культурой, весь код, который вы видите — это результат компромисса со временем. Если бы код писали безкомпромиссно, скорее всего компания, в которой вы работаете, уже не существовала бы.

Независимо от условий, в которых ваши предшественники заключали свои компромиссы — сейчас условия совершенно другие, и вы заключаете совершенно новый компромисс. Так что, не забывая про здравый смысл, начинайте с того, чтобы сделать себе удобно
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы