Мало хороших ПМ

Вопрос: что почитать для расширение кругозора? Читал только «Как пасти котов».

Можно вот это почитать: https://ru.wikipedia.org/wiki/Свод_знаний_по_управлению_проектами

Но вообще сейчас это немодно. Сейчас лучше почитать что-нибудь по Agile.

Кругом одни модные люди, обвешанные Slack, Skype, Telegram, Viber, каждую минуту читающие, пишущие, переадресующие сообщения коллегам, но забывающие о проекте, который надо было сдать месяц назад.

Я сторонник чего-то попроще, «водопада», например.

Ещё вопрос: пусть если 7 программистов разного уровня, возможна ли из них команда без явного технического лидера - только с один проект-менеджером?

7 - уже достаточно много, чтобы разделить обязанности. Лучше найти среди них одного, кто занимался бы координацией по технической части - определял архитектуру. А менеджерскую рутину оставить ПМу. Можно ПМу оставить ещё какую-нибудь техническую роль (вроде разработчика), но не основную. Но это — исключительно ИМХО.

Но это — исключительно ИМХО.

Пожалуй, все мои знакомые, кого я спрашивал, солидарны с этим :)

Я сторонник чего-то попроще, «водопада», например.

Ну водопад - это классика. Это вышеуказанный PMBoK. Но Agile появился не от хорошей жизни. Чтобы водопад работал, нужно в самом начале очень хорошо знать что должно получиться - иметь четкую спецификацию требований. А так почти никогда не бывает. В частности потому, что заказчик никогда не знает что ему нужно, даже если он считает иначе.

часто ли вы встречали квалифицированных руководителей проектами?

нет

Опыт программирования - важная часть подготовки?

да

Кто чаще всего идёт в руководство?

те кто решил остаться подольше

Я сторонник чего-то попроще, «водопада», например

который особенно прекрасно работает когда центральный координатор проекта умудрился запихать блокируемую задачу перед задачей-блокером по срокам

лучше хоть кого-нибудь из команды спросить, чем, витая в мечтах, брать число с потолка и потом делить его на три :)

вот есть допустим группа погромистов, которая реально делает за неделю задачку.

однако, в реальности эти сроки нужно на 4-5 умножать. это без учета тестирования и вылавливания и починки свежих багов.

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

кроме всякой маргинальщины и мелких проектов, написанный и готовый код, это редко выше 20% работы, которая должна быть будет выполнена в итоге.

а если в опенсорце, то код - это чуть ли не 5-10% от всей работы.

Мало хороших ПМ

«Хороших» в любой профессии мало, к сожалению.

Но все издержки можно подсчитать. Нужно.

Во многих командах менеджер раз за разом делает вид, что издержек не существует и о них думать не надо. Может, сглазить боится, чёрт его знает...

Имел ввид - менеджеры, пардон.

а) оценивать сроки, б) планировать временные затраты, в) разбивать задачи на части

Ты отстал от жизни, в гибчине, оценками и декомпозицией занимаются гребцы. Надсмотрщики рисуют графики и улучшают процессы...

Мало хороших ПМ

Премьер-министров?

что почитать для расширение кругозора

Deadline. Роман об управлении проектами.

А как он планирует время?

Собирает с команды импакт ассессмент и планирует.

Я хз, кто идёт в ПМы, но одного толкового встречал-это наш. Проект медицинский, попадает под американские стандарты здравоохренения, документации больше чем кода, пёрднуть нельзя без занесения в 10 реестров и он все эти стандарты-реестры держит в голове, помнит наизусть, знает что где и как, какие решения противоречат стандартам, кому когда и что надо записывать в реестры, непринуждённо нагибает програмистов по архитектурной части, выбивает из заказчиков доп. финансирование, расширяет сроки, короч многорукий Шива, как он есть.

Deadline. Роман об управлении проектами.

Там есть что-нибудь про мотивацию?

Я думал, тред про пакетные менеджеры будет.

да никак ты неподсчитаешь. ибо все эти взаимные влияния станут ясны только после того, как появится хоть какая-то реализация.

ибо обычно по прикидкам, всё хорошо. а начинаешь делать - то кругом проявляется печалька.

а из того, что делают менеджеры -периодически смотрят на всё это и пытаются решить, что же в итоге можно заделиверить без особых рисков.

смысл их обсуждать, если они ничто без нормального и удобного менеджера ПО?

да никак ты неподсчитаешь. ибо все эти взаимные влияния станут ясны только после того, как появится хоть какая-то реализация.

Дык, считать надо или срок можно с потолка брать?

Про всё помаленьку. Имхо это маст рид книга для любого товарища решившего кем-то руководить (сам таким не являюсь).

Она небольшая и стоит недорого, лично я за вечер прочитал :)

Того же автора: Балдеющие от адреналина и зомбированные шаблонами: Паттерны поведения проектных команд.

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

Дык, считать надо или срок можно с потолка брать?

Через какое-то время в проекте появляются коэффициенты. Типа тимлид говорит, что напейсать протокол обмена сообщениями выйдет в две недели. Ты такой: ага, умножаем на его коэффициент 1.75 и получаем реалистичный срок. Плюс небольшой люфт на мелкие проблемы.

а в чем он не прав? сформулируй поточнее, без ТЗ - результат ХЗ! :)

емнип, с этой задачки начинается «сколько стоит программный проект» Макконнелла =)

надо отличать «оценку» (которую скорей всего дал тимлид) и «задачу» (которую сказал начальник, это совсем разные сущности). ПМ пишет и то, и другое, плюс прикладывает к этому work breakdown structure (воможно, несколько - с учетом разных сценариев, которые обычно сочиняются вместе с тимлидом). И дальше, например, для каждого блока пишется пессимистичная, средняя, и оптимистичная оценка. Для блоков выделяются специалисты, которые будут их делать (не только тимлид), на основе которых и сочиняются оценки. Дальше это натягивается на производственный процесс организации (если аджайл то там отдельный ад с целями спринтов), и получается набор из нескольких планов (например, 10 штук). Дальше ПМ идет к директору, и показывает эти планы вместе с данными о возможности и вероятности попасть в целевое время. Дальше уже ответственность директора.

т.к. в процессе подготовки таких презентаций тратится бесконечная бездна времени на коммуникацию, аналитику, написание документов и бумагомарание, то проектного менеджера (даже в аджайл стеке!) лучше всё-таки иметь, имхо. Иначе в него превратится лид (тимлид, скрам-мастер, канбан-сенсей, итп), а они обычно этого сильно не хотят

Ну а составить план-график и следить за его выполнением - это даже не основное.
Мне попадались люди, которые даже не пытаются этого делать.

Если у тебя требования, выдвигаемые заказчиком, меняются каждые два дня, зачем его делать?

По пиэмбуку, если поменялись критичные для сроков проекта требования (которые обычно указываются в проджект чартере), это должно вести к перезапуску проекта. Если перезапускать каждые два дня - получится аджайл xD

Я уже год живу в такой структуре: есть огромный багтрекер с хотелками и багами, и мы просто делаем из него любые интересные тикеты, кому какой больше нравится. Есть приоритетные баги, например критические ошибки «сервер не запускается» и все ошибки безопасности. Брат жив.

Куда лучше делать не «проект», а «процесс по улучшению продукта», и тогда не будет никаких дебильных ограничений с необходимостью создания армейской структуры

Ну а составить план-график и следить за его выполнением - это даже не основное.

Мне попадались люди, которые даже не пытаются этого делать.

Если у тебя требования, выдвигаемые заказчиком, меняются каждые два дня, зачем его делать?

Если бы было так, то да. А если известно за 2, 3, 4 месяца что фичу нужно будет делать, то здесь уже есть место для манёвра.

Кстати, чем плоха армейская структура?

Тем что я не хочу работать в такой структуре.

Работать с равными тебе «товарищами» в коммунистическом смысле слова, которые все вместе делают одно общее доброе дело, в однораноговой структуре - это тру. Кто-то может выделяться, и делать сложнее или больше, и получает за это больше бабла, но это не должно приводить к возникновению иерархии и отношений подчинения.

Люди пришли на работу, потому что они любят свое дело и хотят достигнуть определенных целей - которые являются не только рабочими, но и их личными (именно по этому признаку их и наняли), а не потому что их бьют по башке майоры с дубинками.

То есть в капиталистическом обещстве, это скорей всего структура вида: хозяин бизнеса (чувак который гребет бабло, живет в домике в швейцарских альпах, никто его не видел уже 10 лет), несколько наемных директоров (для координации суперглобальных проблем и торговлей лицом), и одноранговые отделы специалистов с двигающимися столами (сгруппированные по глобально-функциональному признаку: программисты, пиарщики, итп).

у другой - закриптовалось усе

Это ты про вирус-шифровальщик? =)

угу

Ладно если на такое бухгалтера ловятся. Но программисты =)

яж не сказал что запустили программисты 8) у программистов обычно и прав на все нету, а вот у менеджмента 8)