Хочу вкатиться в ПМство, расскажи мне про "типичные косяки" своего ПМа Проектный менеджер, для ребят с завода
Хочу, все таки, стать хорошим специалистом, а значит стоит анализировать ошибки других.
Если есть знатоки, которые спиздили всевозможные курсы для ПМов, тоже буду рад ссылкам.
И да, есть понимание фронт-энда у вэб-макак, основ дисигна. Так что хочу быть ПМом у вэб-макак, так что не будет особой проблемы с "меня захотят наебать со сроками"
А, ну и да. Есть образование айтишника, так что я не свитчер.
Можете не вспоминать про идиотов, которые два дня назад крутили курицам головы в колхозе, а теперь полезли в айти. Я 5.5 лет этому уже отдал (магистр)
любой ПМ, прогнувшийся под кабанчика - уёбок. Хуле тут обсуждать?
Почему ты так думаешь? Есть же ПМы, которые помогают делать работу приятнее и проще. Выстраивают правильные отношения и действуют по методу "критического пути", не заставляя тебя делать все "по таким срокам, ибо я так хочу".
Схоронил. Спасибо. А есть что-то по теме треда?
>Почему ты так думаешь?
Потому что я ПМ
>Есть же ПМы, которые помогают делать работу приятнее и проще. Выстраивают правильные отношения и действуют по методу "критического пути", не заставляя тебя делать все "по таким срокам, ибо я так хочу".
Ага и чо?
В моем понимании пм - это такой пистолет недокабанчик. Обкашливает чужие вопросики.
> Потому что я ПМ
О, было бы интересно послушать. Где учился? Какие советы можешь дать джуну? Может какие-то курсы слитые знаешь где спиздить?
> Ага и чо?
Так большой процент айтишников ненавидят ПМов за ненужные (по их мнению) действия и поведение "царя". Вот мне и интересно, какие еще есть причины нелюбви и что ты сам заметил, будучи ПМом.
Ну, не совсем. Это человек контролирующий весь процесс разработки.
И далее пропасть. Ибо в маленькой конторе ПМ еще и бизнес-аналитик, офис менеджер и т.д.
>которые два дня назад крутили курицам головы в колхозе, а теперь полезли в айти. Я 5.5 лет этому уже отдал
5.5 лет головы курицам крутил, кретин ёбаный?
Все верно. Учил всякое "понемногу". В итоге хочу пойти к вэб-макакам, чтобы потом еще познать мобильный рынок. (ибо они сейчас все более тесно работают)
Кушай кал, школьник.
Да мне уже 24, чини свой прибор.
>> Потому что я ПМ
>О, было бы интересно послушать. Где учился?
На факультете ПМ-ов в МГУ, лол
> Какие советы можешь дать джуну?
Больше слушай и учиться выявлять неадекватов. (Двач в помощь)
> Может какие-то курсы слитые знаешь где спиздить?
Книжки, начиная от "профессора фортрана" и далее куда кривая вывезет. Если ты не можешь сам искать книжки то забудь, ИТ не для тебя.
>
>> Ага и чо?
>Так большой процент айтишников ненавидят ПМов за ненужные (по их мнению) действия и поведение "царя".
Средний современный ИТшник это гной тупорогий. Сказки про велики и могучих росийских программистов остались где-то в 90-2000 годах
>Вот мне и интересно, какие еще есть причины нелюбви и что ты сам заметил, будучи ПМом.
Когда мы заморозили проект моя команда нашему кабанчику сказала что они не будут без меня продолжать работать.
(Приятно, но проекту пизда по причинам кабанчика)
Самое главное это иметь подвешенный язык, любить и уметь общаться с людьми, разруливать конфликты и решать проблемы, всё остальное вторично.
Мимо_год_работал_ПМ
>Да мне уже 24
Ещё
мимо 41 лвл
>Да мне уже 24, чини свой прибор.
С мозгом школьника.
> На факультете ПМ-ов в МГУ, лол
> Больше слушай и учиться выявлять неадекватов. (Двач в помощь)
Тебе приходилось кого-то "подводить к выходу" через начальство? Часто?
> Книжки, начиная от "профессора фортрана" и далее куда кривая вывезет.
Мне обычно советовали авторов/сам находил. ДеМарко, например. Стоит тратить на это время? А может сразу читать ПМбук?
А, кстати. Что можешь посоветовать почитать о риск менеджменте? Это считаю своим "слабым местом".
Дед, как оно? Ельцина живьем видел?
Разбирайся в проекте и внятно объясняй. Записывай всё, что можно. Записывай каждый звонок - если приложение не позволяет (обычно это Скайп, он позволяет) - так хотя бы на диктофон. Клиенты имеют особенность наглеть. Не забивай на бизнес-логику приложения, особенно если в команде часто меняются разработчики. Если не часто - тоже не забивай.
Понимание проекта и чёткость ТЗ избавит тебя от кучи проблем с заказчиком, шефом и разработчиками.
мимо-фронтендер
> Проектный менеджер, для ребят с завода
Бля, а я думал, это опять какая-то хуйня про настолки.
Сралена в жопу ебал еще
Работаю в средне-крупного масштаба агентстве full-cycle разработки софта. Никогда не встречал на каком-нибудь проекте конфликтов ПМа (а их много разных) и команды, которые бы длились дольше пары минут.
Спасибо, это полезно, хоть и очевидно. Но, как я понимаю, это не редкая проебка от ПМа.
А сколько у тебя было ПМов за твою карьеру? Все так грешили?
Да, это пехота из вархамера, друг. Ты все верно понял.
>>235405821
Настоящий дед. Уважаемо. Проходи, тебе полагаются вся кожа с жаренной курочки и вот те хрящики около костей. Томатный сок будешь, деда?
Обычно ПМы, в твоей конторе, это один типаж людей? Или "разнотравье"? И почему нет конфликтов? Они все четко "дают и показывают" или просто хорошо поставили себя?
Если тред "схлопнется" до момента моего возвращения, то хочу уже сейчас сказать спасибо анонам, которые откликнулись на просьбу о помощи.
>>235405941
>>235404678
>>235404733
>>235405677
>>235402393
Отвечу по порядку:
- Типаж людей абсолютно разный, и это полезно когда нужен определённый подход к определённому заказчику и доменной области.
Есть ПМ с критическим подходом ко всему - для сомнительных заказчиков, которые потенциально могут начать творить хуйню. Есть максимально открытая ПМ-тян для амбициозных стартаперов. И так далее.
- Да, всё довольно чётко даётся и показывается, ни в коем случае не жалеется время на предпроектную работу. Пока ПМ на нескольких митингах с командой не решит, что всё нормально и можно двигаться дальше - лучше перебздеть. Но это всё ещё Agile, да.
- Насчёт "хорошо поставили", к должности ПМа обычно у нас идут, поднимаясь\перемещаясь с другой должности (схожей или просто пониже). Так что новый ПМ это человек, который знаком командам уже пару лет. Подозреваю, что это и есть половина успеха.
Хочу дропнуть.
Отговорите.
>Спасибо, это полезно, хоть и очевидно. Но, как я понимаю, это не редкая проебка от ПМа.
Да. Проблема даже не так в самом ПМе, а в коммуникации и порядке на проекте. Поддерживать готовый проект сложнее, чем делать с нуля. Это особенно непросто, если предыдущий ПМ или команда в целом не следили за порядком. Пример: два года назад сделали какую-то фичу и десять правок по этой фиче. Сейчас нужно обновить какую-то мелочь, и есть огромная вероятность, что текущий разработчик что-то сломает и даже не заметит. Не заметит ни тестироващик, если такой имеется, ни ПМ, потому что бизнес-логика проекта им не знакома. В то же время, тикеты в Трелло / Джире хорошо если заводили на саму фичу, а правки обсудили где-то в условном Слаке (который в бесплатной версии через сколько-то там месяцев сообщения стирает).
Можно возразить, мол, ведь есть же код - в коде же видно, что как работает? - на что я ответчу, что это так только в теории, на практике же код будет в лучшем случае "так себе", понять, что за что отвечает и с чем связано порой можно только экспериментальным путём.
>>235406326
>А сколько у тебя было ПМов за твою карьеру? Все так грешили?
Примерно человек 5-7, если не считать работу с клиентами напрямую.
В общем-то, этим грешило большинство. Если проект "типичный", типа интернет-магазина, это не страшно, подавляющая часть вещей должна работать так же, как и на других магазинах и интуитивно понятна всем. Если проект хоть сколько-нибудь нестандартный, без внимательного подхода к делу начинаются качели.
Справедливости ради, практически все ПМы были норм, как правило, проблемы были связаны либо с бестолковым заказчиком, либо с перегруженностью, потому что у ПМа под крылом обычно не один проект.
Алсо, ещё из рекомендаций: очень круто, когда разработчики пишут тесты. Это умеют не все, и код нужно писать хороший, но тесты спасут от массы неприятных ситуаций. Плохая сторона тестов в том, что они едва ли удвоят время на разработку. Объяснить клиенту, что это выгодно на перспективу, как правило, непросто.
In the nutshell: добивайся внятных требований от заказчика, всё записывай, разбирайся в бизнес-логике, консультируйся с командой.
На словах выглядит просто, на практике будут качели. Но, как говорится, дело мастера боится.
>Хочу вкатиться в ПМство, расскажи мне про "типичные косяки" своего ПМа
ПМ норм ствол. Главное его чистить не забывать. Вкатывайся оп.
Даже не скучная, а мразотная. То есть подходит не для нормального творческого человека, а для этакого васянчика, который пишет вкалтактике про пешеходов сбивших с Толку Дом. Типа приказчик при барине, что ли. Петухан, которого все тихо ненавидят, но считаются, потому что так заведено. Умственный калека, который нихуя сам не умеет и вся выгода от которого в том, что он оформляет в общее стадо людей, которые недолюбливают друг-друга и которым в целом похуй на работу, которую они делают. Сержант, который орёт на роту новобранцев.
В общем, если два кодера спорят и не могут договориться, ты не должен говорить 'разберитесь сами'. Выступить арбитром в споре - твоя обязанность. Решение конфликтов тоже на тебе.
Если ты этого не понимаешь, иди нахуй из профессии.
Дальше. Ты формулируешь задачи в нужности которых уверен. Если бизнес просит отложить овме и поправить какую-то хуйню, ты должен объяснить им, почему надо подождать. Не можешь? Иди нахуй из профессии.
Потом. Организация процессов тоже твоя задача. Не перекладывай джиру на кодеров. Не веди задач в ебучем экселе, если есть джира. Научись ей пользоваться, блять!
Программисты только программируют и ревьювят друг друга. Вчитайся.
Не тягай кодеров на собрания с бизнесом.
Не ожидай, что они будут заводить сами задачи.
Кодеры только кодят, блять!
Повтори ещё раз.
Если к тебе приходят с моральной проблемой, вы слушай и постарайся помочь. Если кому-то неуютно в коллективе, то это твоя проблема. Снижение продуктивности, баги, напряжение в коллективе.
Но если все написанное для тебя ебать какое откровение и ты эмоциональный инвалид, то лучше вали из профессии.
>Если к тебе приходят с моральной проблемой, вы слушай и постарайся помочь. Если кому-то неуютно в коллективе, то это твоя проблема.
Это скорее к HR.
>>235413123
Удваиваю этого господина.
мимо->>235412077 и >>235405677 фронтендщик
Атмосфера в команде, это-таки ответственность тимлида и менеджера. Hr далеко, на моей памяти они не занимаются ничем кроме найма.
Поэтому, если все в команде напряжены, все раздражены, все собачатся, то виноват командир.
Не стану спорить, повезло работать в командах без раздора. Может и за ПМ это.
На всех галерах где я был, ПМы были из опытных разработчиков. Если честно, мне не кажется что на роль ПМ возьмут ньюграда из института без опыта работы и инженером, и менеджером.
Если не нравится - дропай. В чем проблема?
>>235407136
Спасибо, понял тебя.
>>235412077
Понял тебя, спасибо.
>>235413123
> Кодеры только кодят, блять!
Архитектура же еще. Или ты ее тоже в "кодят" вписал? Тогда да, согласен.
А все то что ты написал, разве, обычные ПМы не делают?
Эксель ведется "для себя" обычно же, нет?
>>235413712
Это интересная часть работы ПМа для меня.
Абу благословил этот пост.
> На всех галерах где я был, ПМы были из опытных разработчиков.
В маленькие галерки на 1.5 инвалида готовы брать и новичков, только оторваных от сиськи курсов и универов.
Кстати, если еще тут, то расскажи, почему бросил?
Я ещё здесь, слежу за тредом.
Спрашивай, если есть вопросы, как от ПМа к разработчику.
Всё тот же фронтендер
Да я рот ебал эту хуйню, работаешь 24/7 фактически, охуевшая ответственность и мозгоебля, я там на 20кг за год похудел. Но я в топ галере работал, будешь стандартные сайтики пилить такого геморроя не будет, наверное у меня там сервисы были, мобилки, ерп.
Часто ли видел систему RACI в деле?
Метод критического пути с тобой обсуждали, чтобы показать тебе сроки и возможные овертаймы для твоей части работы?
Как часто работал по вотерфолу?
Участвовал ли в составлении таблицы/документа рисков на проекте?
> Да я рот ебал эту хуйню, работаешь 24/7 фактически
А разве при правильной "настройке всего" не уменьшается нагрузка? Много видел фразу про "если кажется, что ПМ не нужен на проекте, то значит ПМ все автоматизировал идеально", думаешь это наеб для гоев?
> будешь стандартные сайтики пилить
Да я бы хотел сайтики, из сайтиков в мобильные+сайтики перекатиться, а затем уже посмотреть, что будет дальше.
>Средний современный ИТшник это гной тупорогий
Бля как же я проиграл. Тебе, дебилу, пишут что пмы будучт прокладкой между булками ведут себя как божки, а ты берешь и называешь всех говном. ПМ года, не иначе
К своему стыду признаюсь, что тупо НИЧЕГО из того, что ты говоришь, не видел и не слышал :-D
Вершина моих познаний о проджект менеджменте - это что скрам и канбан.
Могу предположить, что некоторые вещи (типа метод критичекого пути) у меня в работе были, но я не знал, что это они есть и что они так называются.
Могу предположить, господин, на пост которого ты отвечал выше, попал на не очень удобный проект. Потому что и правда бывают клиенты, которым нужно СРОЧНО исправить буковку в субботу в 23:59.
Алсо, клиенты из постсовка в среднем противнее и тупее клиентов из швятого. Видимо, сказывается отрицательная селекция кабанчиков в лихие 90-е и отсутствие культуры, которая передалась текущему поколению кабанчиков.
Но бывают исключения - есть и говноклиенты со швятого, есть и норм ребята у нас.
>А разве при правильной "настройке всего" не уменьшается нагрузка?
Да чушь всё это, форсмажоры постоянно на релизах, особенно если с дебилами работаешь, пикрил например меня грустным каждый раз делает. Ну представь себе ситуацию, на тебе лежит, чисто гипотетически, сеть доставки жрачки, пилятся доработки, всё отлично работает на тестовых серваках, но после попадания кода из мастер ветки в продакшн всё нахуй падает и не начинает почему-то работать после восстановления из бекапа...
• Кто выполняет задачу (R - responsible)
• Кто отвечает за результат (A - accountable)
• С кем консультироваться (С - consulted)
• Кого информировать о статусе (I - informed)
Обычно это все негласно, мол "все все понимают", но некоторые, по началу, сразу просто цепляют такую табличку, чтобы "люди запутавшиеся" могли разобраться "а к кому идти, чтобы мне помогли по проекту".
Вотерфолл - это методология разработки. Которая применяется тогда, когда ВСЕ по проекту известно ОТ И ДО и правок в запросах не будет, а окончание работы одного сотрудника = начало работы следующего и "туда-сюда" они не будут гонять проект.
Условно: Дизайнер нарисовал ВСЕ СРАЗУ ---> Фронт сверстал ВСЕ СРАЗУ -----> Бек сделал все свои дела ----> Тестер проверил ----> Проект завершен.
без "спринтов" аджайла.
> (типа метод критичекого пути) у меня в работе были, но я не знал, что это они есть и что они так называются.
Второй скрин - метод критического пути. Если не разберешься, задавай вопросы.
Пынямаю, как говорится.
>>235419294
Так... А гит и битбаккет же есть для такой хуйни. Берешь, смотришь какой пидорас все испортил и по шапке ему, ПО ШАПКЕ!
Да по шапке, по шапке, но перед этим тебе позвонит кабанчик и будет верещать как в жопу выебаный, рассказывать охуенные истории о том сколько он в секунду миллионов теряет и сколько раз твою мамку можно за эти деньги выебать. А пока вы всё пофиксите уже час ночи будет.
>Так... А гит и битбаккет же есть для такой хуйни. Берешь, смотришь какой пидорас все испортил и по шапке ему, ПО ШАПКЕ!
Есть то он есть, но рукожопство никто не отменяет.
И, допустим, ты дал пидорасу по шапке. Потом ещё. И ещё. Допустим, вы уволили пидораса, и наняли другого. Или даже норм типа наняли.
Всё равно проект значительно замедляется. Как бы не был талантлив новый чувак, ему нужно вкатиться в проект. А если до него был пидорас, значит и код этот пидорас писал соответствующий. Это ещё минус к скорости нового чувака.
>Обычно это все негласно, мол "все все понимают",
Очевидно, сложилось у меня именно так.
>>235419304
>Вотерфолл - это методология разработки.
Во, теперь вспомнил. Учил на курсах, и с тех пор не встречался. В теории выглядит круто, на практике надо учитывать тысячи нюансов ещё на этапе планирования, да ещё чтобы клиент не лез со своим "надо вот тут такую кнопочку сделать, чтобы вот так... в смысле 20 часов? Это же кнопочка!".
Из платинового во фронте правки из серии "Я думаю, что заказчику не понравится это и это". И сначала правки от пма, потом заказчик охуевает какое вышло г-но и еще правки от заказчика. В итоге заказчики всегда уходили недовольными и контора закрылась лол. Пм - пизда. Растягивание рабочего процесса на 500%. напрямую с заказчиком почти всегда было все быстро и адекватно. Так что я в итоге на фриланс ушел, нахуя платить прокладке.
Ну тут варианта два, которые стоит заранее обговорить с владельцем твоей галеры:
1. Ты в договоре указываешь, что все работы ведутся только с 10 до 18
2. Ты договариваешься с начальником, чтобы разрабы были готовы исправлять собственные ошибки и в час ночи.
Иначе, к сожалению, никак.
Ну и да, если из-за такого работника возникают ошибки систематически, то стоит после очередной ретроспективы поставить вопрос о замене его. Либо "намекнуть" HR, чтобы подыскивала на его должность человека. (С согласия владельца галеры, очевидно)
>>235419561
> Всё равно проект значительно замедляется. Как бы не был талантлив новый чувак, ему нужно вкатиться в проект.
Ну да, но ты как ПМ можешь уменьшить время этого вката, если ебал прошлого пидораса и требовал от него документацию и нормальных результатов (результатов код ревью, очевидно)
> Очевидно, сложилось у меня именно так.
А тебе было бы удобнее видеть такую таблицу?
Если да, то "на каждом новом проекте" или первые месяцы, после того, как ты пришел в компанию?
> Во, теперь вспомнил. Учил на курсах, и с тех пор не встречался.
А с критическим путем? Там же, как ты видишь, показаны нюансы с "запасным временем" для "не критического пути".
> Из платинового во фронте правки из серии "Я думаю, что заказчику не понравится это и это". И сначала правки от пма, потом заказчик охуевает какое вышло г-но и еще правки от заказчика. В итоге заказчики всегда уходили недовольными и контора закрылась лол. Пм - пизда. Растягивание рабочего процесса на 500%. напрямую с заказчиком почти всегда было все быстро и адекватно.
Ну ты описал просто плохого ПМа, который не смог составить ТЗ грамотно.
> Так что я в итоге на фриланс ушел, нахуя платить прокладке.
Не все готовы ебаться объясняя каждой части проекта "чего они хотят", "на когда надо" и "проверять каждые три дня, че и как там".
Лол это всё так не работает
>Ты в договоре указываешь, что все работы ведутся только с 10 до 18
Просто идешь нахуй на этой стадии, нас ПМов жопой жри, не хочешь ты работать другой захочет.
>Ты договариваешься с начальником
Он кивает гривой, но чувак продолжает работать, в коллективе, ВНЕЗАПНО, все узнают что ты серишь коллегам и даешь повод для их увольнения, тебя начинают считать за дерьмо, а отношения с коллективом, для ПМ, критически важны.
> Просто идешь нахуй на этой стадии, нас ПМов жопой жри, не хочешь ты работать другой захочет.
На самом деле не много, а качественных еще меньше. Но это не важно. Я тебе говорил про работу ВСЕЙ фирмы, а не только ПМа. ПМ- кусок команды.
> Он кивает гривой, но чувак продолжает работать, в коллективе, ВНЕЗАПНО, все узнают что ты серишь коллегам и даешь повод для их увольнения, тебя начинают считать за дерьмо, а отношения с коллективом, для ПМ, критически важны.
И чтобы этого избежать есть ретроспективы и навык ПМа "держаться на плаву" даже если это волна говна.
>А тебе было бы удобнее видеть такую таблицу?
Не уверен. Никогда над подобным не задумывался. По факту, я все эти вещи узнаю в первые пару дней работы в компании / на отдельно взятом проекте.
>>235419750
>1. Ты в договоре указываешь, что все работы ведутся только с 10 до 18
Здесь есть свои подводные камни. Поскольку ты вкатываешься, скорее всего, со старта ты попадешь в галерку помельче и, как бы это сказать, покабанистее - со всеми вытекающими. Например, работать без договора. Или "да, договор, но очень надо".
>>235419750
>Ну да, но ты как ПМ можешь уменьшить время этого вката, если ебал прошлого пидораса и требовал от него документацию и нормальных результатов (результатов код ревью, очевидно)
Опять же, о нюансах.
Может быть, что на проекте код ревью не было.
Может быть так, что говнокода столько и он затрагивает такие ключевые вещи, что переписывать нет ни времени, ни средств.
>>235419750
>
>Ну и да, если из-за такого работника возникают ошибки систематически, то стоит после очередной ретроспективы поставить вопрос о замене его. Либо "намекнуть" HR, чтобы подыскивала на его должность человека. (С согласия владельца галеры, очевидно)
Из подводных: у него может быть зп в две пачки Роллтона / Мивины; владелец галеры хочет взять себе побольше, и хватает только на всяких долбодятлов; кабанчик настолько ужимает бюджет, что выгодно держать на проекте такого долбодятла.
Это я не спорить лезу, если что - просто прикидываю, какие трудности ты можешь встретить.
Короче, это всё о противостоянии нормального человеческого порядка кабанизму в его худших проявлениях - с "авось", "и так норм", "главное, чтобы работало", "потом переделаем", "главное денег срубить".
>А с критическим путем? Там же, как ты видишь, показаны нюансы с "запасным временем" для "не критического пути".
По видимому, обсуждалось, но не:
- Эй, аноннейм, давай обсудим эту задачу по методу критического пути
...а:
- Сколько примерно это займет? А багфикс? А если вот это? А если то? Ну давай ещё час накинем.
Пикрелейтед еще каждые блять пару минут. Сука я все нервы себе угробил. Никогда не шли голосовухи, будь няшей
>голосовые
Ну это вообще дно днищенское.
> Не уверен. Никогда над подобным не задумывался. По факту, я все эти вещи узнаю в первые пару дней работы в компании / на отдельно взятом проекте.
А часто сталкивался с проблемой, что ты "идешь спросить помощи" не у того человека или заебываешь вопросами одного, например синьора, а мог бы и мидла, и дисигнера спросить и т.д.? И видел таких вокруг себя?
> Например, работать без договора. Или "да, договор, но очень надо".
И тут вариант только с выбиванием плюшек для коллектива у начальника сработает. Скорее всего, нематериальных. Мол, лишний отгул оплачиваемый и т.д.
> Может быть, что на проекте код ревью не было.
Если это проект твоей конторы, как описывал его анон выше, то за такое и по ебальничку нужно дать тимлиду, пму и техлиду. Ибо такое зло нужно искоренять нахуй.
> Из подводных: у него может быть зп в две пачки Роллтона / Мивины; владелец галеры хочет взять себе побольше, и хватает только на всяких долбодятлов;
Если он такой один, то это скорее всего джун. Джун таких делов не наворотит, ибо его курируют. Мидла такого "за копейки" искать не стоит, ибо можно поднять "с нового проекта" крепкого джуна на мидла, а мидла выкинуть на мороз (при условии, что синьор сможет "иногда поглядывать" за работой мидло-джуна).
> Если не нравится - дропай. В чем проблема?
Ты норм ПМ будешь, видно что говно человек.
Нет, метод критического пути немного про иное. Смотри:
Есть процесс А, процесс Б и процесс С.
Процесс С может начаться ТОЛЬКО ТОГДА, когда закончится этап А и Б.
Процесс А длится 5 дней.
Процесс Б длится 3 дня.
Процесс С начнется ТОЛЬКО ЧЕРЕЗ 5 ДНЕЙ.
Это значит, что у процесса Б есть два запасных дня. Понял о чем я?
>На самом деле не много, а качественных еще меньше.
А ты что, уже стал топовым ПМ? лол
> 4 секунды
Сука, ну и уебок. Там же явно меньше 20 символов.
Поколение дегроидов во всей красе хуйли
Мне кажется это деградация всех пмов. Сначала они стараются, все уточняют по 10 раз, документы хуементы. Потом похуй я иду посрать и сидя с толчка запишу тебе голосовуху.
Наблюдал такое явление много раз, заказчики постоянные тоже этим грешат. Сначала нормальное структурированное тз с кучей подразделов, потом небольшое тз в общих чертах, потом короткое сообщение в телеге, потом давайте созвонимся, а потом это.
>А часто сталкивался с проблемой, что ты "идешь спросить помощи" не у того человека или заебываешь вопросами одного, например синьора, а мог бы и мидла, и дисигнера спросить и т.д.? И видел таких вокруг себя?
Было и такое, как правило, на новом проекте. Обычно решается быстро и без нервов. Если человек не шарит - скажет, у кого спросить. Если занят - ответит позже. Если занят, но срочно - скажет, у кого другого спросить, или сам найдеш.
Если речь о том, например, что ты бекендера просишь сделать то, что должен делать фронт, или фронта то, что должен дизайнер - ну, ничего не вижу в этом плохого, клиент и ПМ не обязаны понимать технических (подчёркиваю) деталей. Если спросил не того человека - ничего страшного. Если разраб не долбоёб, спокойно ответит, что с этим вопросом не к нему, да и всё.
Нет, я просто "мониторю рынок кадров". Крупные конторы по пол года уже не могут найти себе ПМа с 3+ года опыта. Мелких, безусловно, как говна, но и те не очень качественные. Нужно и это говно просеивать, надеясь, что там есть "что-то ценное".
Это в любом деле так, мне кажется, в том числе и за пределами ИТ.
> Было и такое, как правило, на новом проекте. Обычно решается быстро и без нервов. Если человек не шарит - скажет, у кого спросить. Если занят - ответит позже. Если занят, но срочно - скажет, у кого другого спросить, или сам найдеш.
Но есть же разные люди, разные команды. Джуны, особенно джуны, иногда стесняются спрашивать и т.д.
Понял.
Нет, с подобным не встречался.
Алсо, да - ещё один подводный камень профессии, это эстимейт. Будь готов к вечным провтыкам по срокам, недооценке и переоценке задач.
Каюсь, сам этим грешу постоянно.
Ну просто с такой схемой куда проще "помогать сотрудникам" не перегорать от постоянной нагрузки. Там ему "выцепишь выходной", там дашь день поебловать на работе смотря ютуб и т.д.
Справедливое замечание.
Это индивидуальная тема - от человека зависит.
У меня язык подвешен, например. Хотя я вообще стеснительный, но если речь о работе, в коммуникации я крут.
Думаю, если ты видишь, что джун не тащит, а спросить стесняется - прояви инициативу, позови более опытного разработчика.
С таким тоже не встречался.
На моей текущей работе, если у разработчика нет задач, его бросают на другой проект. Если другого проекта нет - разработчик идет учить английский / смотреть курсы по технологиям, которые не знает или знает плохо.
Этот пост удваиваю.
Казалось бы, в ИТ вкатилась куча народу, ЗП упадут, а вакансий не будет - но нет, бестолкового народу тьма, а человек с руками и головой до сих пор дичайше востребован.
Думаю, ПМ в этом плане сложнее, так как для ПМ гораздо большую роль играет умение себя показать и коммуницировать - в этом плане, обыкновенные, простите мой французский, пиздоболы смогут обходить действительно толковых, но более скромных менеджеров.
> Если другого проекта нет - разработчик идет учить английский / смотреть курсы по технологиям, которые не знает или знает плохо.
Все понимают, что он с вероятностью большой пойдет ебловать смотря в экран, нет?
> Думаю, ПМ в этом плане сложнее, так как для ПМ гораздо большую роль играет умение себя показать и коммуницировать - в этом плане, обыкновенные, простите мой французский, пиздоболы смогут обходить действительно толковых, но более скромных менеджеров.
Вылетят же, через полгода и 2-3 проебаных проекта из-за неумения вести документацию и проверять "какая температура средняя по палате" каждый день.
>В общем, если два кодера спорят и не могут договориться, ты не должен говорить 'разберитесь сами'. Выступить арбитром в споре - твоя обязанность. Решение конфликтов тоже на тебе.
бугага, представил как пм будет арбитром кодеров. разборку устраивает кто понятия имеет
нет, спят все уже. а что тут было?
Звучит так, словно зачастую проблема в самом коде, а не в отношении двух людей.
Если в коллективе нормальная атмосфера, то кто-то и так легко пойдет на уступки/признает свою неправоту. А вот выберут они switch или if/else - это уже и правда не забота ПМа. Но разве будут они устраивать буйный скандал из-за такой мелочи?
Да вдруг еще есть какие-то советы, я бы почитал.
ну вообще цитата выше звучит как букварь тимлидов, что не надо игнорировать конфликты, они от этого никуда не деваются, их надо обнаруживать и решать. и в общем случае это не про программирование, а про какой-то межличностный движ. что касается технических решений, то для их принятия обычно есть специальный человек, ибо если его нет, то будет цирк и колхоз, ответственность которого либо что-то решать, либо забивать в ситуации когда все равно. и ПМ может, и бывает, ни одним из этих людей.
Ну да, тут я с тобой согласен. Конфликты двух личностей решает ПМ, двух техработников - техлид/синьор.
Так он же не такой сложный. Есть куда более "яркие примеры".
Тип чисто ознакомиться с работой и глянуть курсы?
Или надо уметь программировать и тд?
> Обьясните. В пм-сы вкатывабтся с улицы?
Нет, нужен или опыт работы в айти на НЕ_ПМской_ДОЛЖНОСТИ (если контора средняя/большая) + курсы ПМа.
В маленькой можно начать и с просто курсов, а профильное образование будет тебе плюсом.
> Или надо уметь программировать и тд?
Плюс, но не обязательно. Знание базиса - обязательно.
надо уметь задавать три вопроса
- когда сделаешь
- кого ждешь
- почему не сделал
дальше ходишь по кругу по всем выбранным людям и упоминаемым в п.2. личностям, задаешь эти вопросы, записываешь ответы, всё. причем в ответе "почему не сделал" можно вообще всю хуйню пропускать, слова незнакомые, это все не важно. важно кто всё продолбал, кто кому не сказал, кто до кого не дошел. это надо запонимать, доходить и говорить. а, еще желательно план-факт из первого пукнта запоминать, чтобы понимать на сколько человек ошибается и в какую сторону.
Как же ты горишь с ПМов. Это не ты, часом, тот анон, что ушел на фриланс из-за "нежелания платить прокладке"?
почему горю, очень полезные люди, иначе этим всем пришлось бы мне заниматься
Ну, тогда ты частично прав, но ты уберег малыша от информации о том, что там еще будет гора документации, которую придется контролировать, общение с заказчиком, продукт овнером, поиском "почему Вася-фронт перегорел" и деталями, вроде "ежедневный митинг на тему текущего проекта".
>
>
Хороший МП должен иметь опыт кодинга на бекенде хотя бы 2 месяца, на фронте, немного тестировать и рисовать дизайн, то есть ты должен быть в шкуре каждого члена команды хотя бы по месяцу - скачай себе IDE попробуй попрограммировать
Если у тебя не будет такого опыта то ты сразу идешь на хуй и не быть тебе никогда хорошим ПМ
перегорел - наймем нового. какие тут проблемы?
Дисигнил, фиксил огрехи дисигна пары человек.
Пытался во фронт, блеванул и сказал себе, что лучше пусть мне внутренности вынут ножовкой.
А вот бэк не трогал. Думаешь это так важно?
>>235424994
Плохой ПМ.
>>235424996
Если причина систематическая, то "перегорит и новая деталь, а может и всю систему замкнет нахуй". Понимаешь, к чему я?
> "типичные косяки" своего ПМа
Беда всех менеджеров, с которыми ме довелось работать, в том, что эти люди, призванные находить общий язык с заказчиком, чётко выяснить его цели и задачи и поставить грамотное ТЗ исполнителю, на деле не умели ни того ни другого, и представляли из себя — все как один! — паразитов, прослойку-вредителя, исполняющего лишь роль испорченного телефона. По факту эти люди не умели и не умеют ни в коммуникацию ни в технические знания даже на базовом уровне, ни в организацию процессов.
Это люди, которые думают, что менеджер — это такой человек, который уполномочен стоять над исполнителем и ковырять ему мозги: «Ну когда, когда, быстрее, о! Правки!»
Ну, видимо тебе и правда попадались идиоты.
Неужели они даже не пытались понять, что тебе нужно как сотруднику?
За 5 лет был один (один, сука), человек, который реально понимал что значит работа ПМа. Настроил тасклисты, шарил в техпроцессе, вместо колупания мозгов с полным непониманием того, что и за какие сроки в принципе возможно сделать, подгонял всякий полезный в реализации стафф, умел ставить ТЗ и в целом был очень приятным. Вероятно, именно поэтому вылетел пулей через пару месяцев, потому что никакая адекватность и профессионализм не победят вековые устои глупости и лизоблюдство коллег и самодурство начальства.
И это, без смехуёчков, крупная корпорация, лидер в своей отрасли, вот это все.
Правда, направление, где я работаю, непрофильное, так что всем поебать, но проблема системная на самом деле.
Даже Татьяныч с такой хуйней сталкивался, что уж говорить: https://tema.livejournal.com/2794320.html
Татьяныч неоднозначная личность. Мамин выпиздышь, который свое бабло получил на господрядах и эпатажности, ибо продает вниманиеблядство. Вне "рисунков" я бы слушать такого человека не стал.
>Дед, как оно? Ельцина живьем видел?
Да, и топил за него в 96 будучи сосницким, и щас подписан на "ельцин был скином"
>> На факультете ПМ-ов в МГУ, лол
>> Больше слушай и учиться выявлять неадекватов. (Двач в помощь)
>Тебе приходилось кого-то "подводить к выходу" через начальство? Часто?
Никогда, легко увольняю. И ещё ИТшники часто сами видят что "не тянут" и сваливают чтобы обосрамса не случилось и ЧСВ не было задето.
>> Книжки, начиная от "профессора фортрана" и далее куда кривая вывезет.
>Мне обычно советовали авторов/сам находил. ДеМарко, например. Стоит тратить на это время? >А может сразу читать ПМбук?
>А, кстати. Что можешь посоветовать почитать о риск менеджменте? Это считаю своим "слабым местом".
Честно, не помню уже что читал на эту тему. Быть ПМом не великая премудрость.
Орлова помню читал, "записки автоматизатора". И ещё всяких чичваркиных-тиньковых почему-то помню, лол
>>Средний современный ИТшник это гной тупорогий
>Бля как же я проиграл. Тебе, дебилу, пишут что пмы будучт прокладкой между булками ведут себя как божки, а ты берешь и называешь всех говном. ПМ года, не иначе
Я не называю всех говном, ты в шары долбишься. Я называю СРЕДНЕГО русского ИТшника говном.
Вот буквально только что подкаст "хабр про" случайно послушал (не говноед, просто не люблю фоновую музыку)
и вот там как раз два таких абсолютно бессмысленных чела рассказывают какие они ИТшники и как их судьба привела в это вот всё. Чувство мерзкое после осталось, хотя для тех кто не в теме оно должно было быть чем-то типа агитки, мол нехватка у нас кадров, ряяя!
если кому интересно ссылка - https://podcastaddict.com/episode/116525652
> Орлова помню читал, "записки автоматизатора".
Полезная книга?