Хорошая статья. Для начинающих РП это может показаться всё каким-то излишним усложнением, но, действительно, проваливающиеся проекты часто сопровождают страх неудачи, недоговорки в команде и отсутствие открытости.
Не обязательно прям делать документ и заставлять подписывать его кровью, достаточно рассказывать и нести ценности команде, создавать атмосферу, где будет приятно продуктивно работать. Главный принцип: нормально делай — нормально будет.
Хочу дополнить ещё то, что хорошим аналитиком вы не станете, если вам тяжело отказывать людям.
Важно быть честным и сохранять нейтралитет в подходе к анализу данных. К вам прямо или косвенно могут обращаться, чтобы вы слегка поправили выборку данных, по-другому на них посмотрели для того чтобы инициатор получил выгоду (его фичу не выпилили, например). Нужно уметь жёстко говорить, что вы за выяснение истины, а не за подлог.
Если не уметь говорить "нет", то вы станете плохим аналитиком, примерно как градусник, который отражает не реальную температуру, а ту, которая "очень просит партия".
Начинающим важно понимать: да, бывают трудности. Независимо от вашей роли — программист, аналитик или менеджер проектов — вам придется учиться многому вне основной работы, общаться с людьми из новых для вас сфер и понимать, что от вас нужно, чтобы совместная работа шла комфортно.
С опытом придет возможность быстрее решать базовые задачи и меньше учиться. Однако сложность перейдет в задачи, которые еще никто не решал из вашей команды. Со временем сможете выбирать компании по вашим приоритетам — игнорировать второстепенные минусы и фокусироваться на том, что действительно важно, например, на возможности удаленной работы.
Мне искренне жаль. Я рад, что у меня была возможность скачивать и читать те книги, которые просто не купить и не найти в других местах. Это нередко помогало мне в сложных моментах жизни, отвлекая от суровой действительности через хорошую литературу.
Я никогда не задумывался до новостей о болезни Stiver'a о том, что кто-то содержит этот проект в одного, борется с блокировками и множеством проблем. Но я очень горд за него, что у него все получалось до сих пор, он делал то, что делал хорошо и только болезнь прервала его путь.
То, что так много людей комментирует говорит о том, что он делал громадное дело. Спасибо, Stiver! <3
Я еще пользуюсь весами с импедансами в зале, которые имеют ручки, позволяющие измерять состав всего тела, а не только нижней части как на обычных весах. Если совместить их данные с данными с браслетов, датами и программами тренировок, то по идее можно еще получить выводы о том как много мышц растет / жира сгорает за среднюю тренировку, что работает эффективнее из программ.
Но это прям трудоемко, но может быть очень интересным :)
А есть же еще вариант, чтобы сделать какой-то pet project, понятно, что это некоммерческий опыт, но можно сделать какое-то приложение/плагин. Насколько часто этим заморачиваются джуны-программисты или толку от этого в резюме мало?
Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Понял, что возможно ответил не совсем корректно на вопросы. Отвечу отдельно.
Как я и изложил в статье, я считаю что текущие подходы и не изменяются, потому что они с лихвой закрывают текущие потребности, они не идеальны, но позволяют достигнуть результата в текущих условиях.
Главный вопрос: а что нужно добавить в классический проектный или гибкие проектные подходы, чтобы увеличить их эффективность?
Вот тут у меня и нет простого ответа, потому что у нас есть те проблемы (неопределенность и сами люди) и как сделать так, чтобы универсально для всех повысить количество успешно закрытых проектов на 1% я не знаю. Но мне было бы очень интересно пообщаться с коллегами на эту тему, поэтому и написал эту статью, узнать их мнение.
По PMBoK – да, всё верно, я и отразил, что это справочник.
Насчет "новых подходов". Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Как я и писал в статье, у меня нет готового полноценного ответа. Если бы мне предложили написать фантастический роман о проектном управлении, в котором была бы такая система, то я думал больше в сторону противодействия разрастания содержания проекта.
Например, система внутри крупной компании с ИИ, которая обучена на тысячи их проектах с указанием хронологии проекта, принятых решениях и итоговой стоимости, сроках и конечном эффекте – показателях. А также загруженные данные о всех участниках проекта, причем как исполнителей, так и заказчиков и заинтересованных лиц с расчетом синтетической оценки правильности принятых решений.
При каждом изменении содержании проекта по инициативе исполнителей, заказчиков или заинтересованных лиц, то это изменение проходило бы через систему ИИ и выдавало бы вердикт-рекомендацию по внесению данного изменения. Уровня "этот маневр будет стоить нам 51 год с вероятностью в 80%" или что-то вроде того :)
Если изменение имеет высокие риски для проекта и скорее приведет к проблемам, то данное изменение подтверждается только руководителем инициатора изменения и руководителем проекта совместно. Если решение принято, то система визирует изменение, вносит его в проект и формирует риск-план с указанием конкретным исполнителям/заказчикам что нужно сделать, чтобы это изменение прошло с наибольшей эффективностью (например, что заказчик должен уточнить требования за какой-то срок).
В общем, как видно, романист из меня не очень, но пока какой-то такой взгляд на грядущее будущее.
Согласен, сам думал примерно в том же ключе. Scrum сейчас это "стандарт" и если даже говоришь, что делаешь проекты не по Agile, а просто по классическому итеративно-инкрементальному подходу, то на тебя смотрят как на еретика, который оскорбил Бога Гибкости и втайне поклоняется идолу Водопада :) Но Скрам притом что он так широко распространен не стал серебряной пулей, которая решает все проблемы даже близко (такие надежды ходили в 2016-2017 годах, когда он появлялся в России), более того, он легко может при неправильном применении создать новые проблемы на ровном месте.
Насчет лидера-слуги улыбнуло, интересно было бы на широкой выборке узнать как и чего у РП / Скрам Мастеров происходит в реальности и как у них внутри их структур всё происходит.
Да, всё абсолютно так. Это важно понимать и прямо на собеседовании выяснять какая степень влияния на процессы и ресурсы будет, потому что везде ситуация уникальна.
Всё верно, я хотел подсветить то, что бывают и крайние случаи. Не знаю как сейчас у новичков проджектов, но когда я начинал работать в заказной разработке такое происходило довольно часто (из-за того, что ты еще по сути был тестировщиком, это было в дремучие десятые годы).
Хорошая статья. Для начинающих РП это может показаться всё каким-то излишним усложнением, но, действительно, проваливающиеся проекты часто сопровождают страх неудачи, недоговорки в команде и отсутствие открытости.
Не обязательно прям делать документ и заставлять подписывать его кровью, достаточно рассказывать и нести ценности команде, создавать атмосферу, где будет приятно продуктивно работать. Главный принцип: нормально делай — нормально будет.
Хочу дополнить ещё то, что хорошим аналитиком вы не станете, если вам тяжело отказывать людям.
Важно быть честным и сохранять нейтралитет в подходе к анализу данных. К вам прямо или косвенно могут обращаться, чтобы вы слегка поправили выборку данных, по-другому на них посмотрели для того чтобы инициатор получил выгоду (его фичу не выпилили, например). Нужно уметь жёстко говорить, что вы за выяснение истины, а не за подлог.
Если не уметь говорить "нет", то вы станете плохим аналитиком, примерно как градусник, который отражает не реальную температуру, а ту, которая "очень просит партия".
Начинающим важно понимать: да, бывают трудности. Независимо от вашей роли — программист, аналитик или менеджер проектов — вам придется учиться многому вне основной работы, общаться с людьми из новых для вас сфер и понимать, что от вас нужно, чтобы совместная работа шла комфортно.
С опытом придет возможность быстрее решать базовые задачи и меньше учиться. Однако сложность перейдет в задачи, которые еще никто не решал из вашей команды. Со временем сможете выбирать компании по вашим приоритетам — игнорировать второстепенные минусы и фокусироваться на том, что действительно важно, например, на возможности удаленной работы.
Мне искренне жаль. Я рад, что у меня была возможность скачивать и читать те книги, которые просто не купить и не найти в других местах. Это нередко помогало мне в сложных моментах жизни, отвлекая от суровой действительности через хорошую литературу.
Я никогда не задумывался до новостей о болезни Stiver'a о том, что кто-то содержит этот проект в одного, борется с блокировками и множеством проблем. Но я очень горд за него, что у него все получалось до сих пор, он делал то, что делал хорошо и только болезнь прервала его путь.
То, что так много людей комментирует говорит о том, что он делал громадное дело. Спасибо, Stiver! <3
Неплохая идея, сам об этом не думал.
Я еще пользуюсь весами с импедансами в зале, которые имеют ручки, позволяющие измерять состав всего тела, а не только нижней части как на обычных весах. Если совместить их данные с данными с браслетов, датами и программами тренировок, то по идее можно еще получить выводы о том как много мышц растет / жира сгорает за среднюю тренировку, что работает эффективнее из программ.
Но это прям трудоемко, но может быть очень интересным :)
Спасибо за подробный и полезный комментарий!
Действительно, надо было лучше разобраться: и в хронологии, и в определениях, чтобы всё было чётко. В следующий раз подготовлюсь лучше.
Искреннее уважение к вам за то, что так подробно разобрали статью!
А есть же еще вариант, чтобы сделать какой-то pet project, понятно, что это некоммерческий опыт, но можно сделать какое-то приложение/плагин. Насколько часто этим заморачиваются джуны-программисты или толку от этого в резюме мало?
PS ссылка на группу нерабочая
Понял, что возможно ответил не совсем корректно на вопросы. Отвечу отдельно.
Как я и изложил в статье, я считаю что текущие подходы и не изменяются, потому что они с лихвой закрывают текущие потребности, они не идеальны, но позволяют достигнуть результата в текущих условиях.
Главный вопрос: а что нужно добавить в классический проектный или гибкие проектные подходы, чтобы увеличить их эффективность?
Вот тут у меня и нет простого ответа, потому что у нас есть те проблемы (неопределенность и сами люди) и как сделать так, чтобы универсально для всех повысить количество успешно закрытых проектов на 1% я не знаю. Но мне было бы очень интересно пообщаться с коллегами на эту тему, поэтому и написал эту статью, узнать их мнение.
Спасибо за отклик!
По PMBoK – да, всё верно, я и отразил, что это справочник.
Как я и писал в статье, у меня нет готового полноценного ответа. Если бы мне предложили написать фантастический роман о проектном управлении, в котором была бы такая система, то я думал больше в сторону противодействия разрастания содержания проекта.
Например, система внутри крупной компании с ИИ, которая обучена на тысячи их проектах с указанием хронологии проекта, принятых решениях и итоговой стоимости, сроках и конечном эффекте – показателях. А также загруженные данные о всех участниках проекта, причем как исполнителей, так и заказчиков и заинтересованных лиц с расчетом синтетической оценки правильности принятых решений.
При каждом изменении содержании проекта по инициативе исполнителей, заказчиков или заинтересованных лиц, то это изменение проходило бы через систему ИИ и выдавало бы вердикт-рекомендацию по внесению данного изменения. Уровня "этот маневр будет стоить нам 51 год с вероятностью в 80%" или что-то вроде того :)
Если изменение имеет высокие риски для проекта и скорее приведет к проблемам, то данное изменение подтверждается только руководителем инициатора изменения и руководителем проекта совместно. Если решение принято, то система визирует изменение, вносит его в проект и формирует риск-план с указанием конкретным исполнителям/заказчикам что нужно сделать, чтобы это изменение прошло с наибольшей эффективностью (например, что заказчик должен уточнить требования за какой-то срок).
В общем, как видно, романист из меня не очень, но пока какой-то такой взгляд на грядущее будущее.
Согласен, сам думал примерно в том же ключе. Scrum сейчас это "стандарт" и если даже говоришь, что делаешь проекты не по Agile, а просто по классическому итеративно-инкрементальному подходу, то на тебя смотрят как на еретика, который оскорбил Бога Гибкости и втайне поклоняется идолу Водопада :) Но Скрам притом что он так широко распространен не стал серебряной пулей, которая решает все проблемы даже близко (такие надежды ходили в 2016-2017 годах, когда он появлялся в России), более того, он легко может при неправильном применении создать новые проблемы на ровном месте.
Насчет лидера-слуги улыбнуло, интересно было бы на широкой выборке узнать как и чего у РП / Скрам Мастеров происходит в реальности и как у них внутри их структур всё происходит.
Да, всё абсолютно так. Это важно понимать и прямо на собеседовании выяснять какая степень влияния на процессы и ресурсы будет, потому что везде ситуация уникальна.
Всё верно, я хотел подсветить то, что бывают и крайние случаи. Не знаю как сейчас у новичков проджектов, но когда я начинал работать в заказной разработке такое происходило довольно часто (из-за того, что ты еще по сути был тестировщиком, это было в дремучие десятые годы).