>>235406326 >Спасибо, это полезно, хоть и очевидно. Но, как я понимаю, это не редкая проебка от ПМа. Да. Проблема даже не так в самом ПМе, а в коммуникации и порядке на проекте. Поддерживать готовый проект сложнее, чем делать с нуля. Это особенно непросто, если предыдущий ПМ или команда в целом не следили за порядком. Пример: два года назад сделали какую-то фичу и десять правок по этой фиче. Сейчас нужно обновить какую-то мелочь, и есть огромная вероятность, что текущий разработчик что-то сломает и даже не заметит. Не заметит ни тестироващик, если такой имеется, ни ПМ, потому что бизнес-логика проекта им не знакома. В то же время, тикеты в Трелло / Джире хорошо если заводили на саму фичу, а правки обсудили где-то в условном Слаке (который в бесплатной версии через сколько-то там месяцев сообщения стирает).
Можно возразить, мол, ведь есть же код - в коде же видно, что как работает? - на что я ответчу, что это так только в теории, на практике же код будет в лучшем случае "так себе", понять, что за что отвечает и с чем связано порой можно только экспериментальным путём.
>>235406326 >А сколько у тебя было ПМов за твою карьеру? Все так грешили? Примерно человек 5-7, если не считать работу с клиентами напрямую.
В общем-то, этим грешило большинство. Если проект "типичный", типа интернет-магазина, это не страшно, подавляющая часть вещей должна работать так же, как и на других магазинах и интуитивно понятна всем. Если проект хоть сколько-нибудь нестандартный, без внимательного подхода к делу начинаются качели.
Справедливости ради, практически все ПМы были норм, как правило, проблемы были связаны либо с бестолковым заказчиком, либо с перегруженностью, потому что у ПМа под крылом обычно не один проект.
Алсо, ещё из рекомендаций: очень круто, когда разработчики пишут тесты. Это умеют не все, и код нужно писать хороший, но тесты спасут от массы неприятных ситуаций. Плохая сторона тестов в том, что они едва ли удвоят время на разработку. Объяснить клиенту, что это выгодно на перспективу, как правило, непросто.
In the nutshell: добивайся внятных требований от заказчика, всё записывай, разбирайся в бизнес-логике, консультируйся с командой.
На словах выглядит просто, на практике будут качели. Но, как говорится, дело мастера боится.