Ця стаття — про те, як зробити процес передачі/отримання проєкту легким і навіть приємним. Стаття буде корисна молодим командам, які ще не пройшли всі перешкоди на своєму шляху, або лідерам команд, які тільки опановують цю роль. 5
Мы все знаем, что релизят код, а проект заканчивают. Но будем говорить о том, как делать не надо. А за 8 лет в проектном менеджменте у Павла Устинова, как и у каждого РМ’а, накопилось множество историй из серии «как лучше не делать». Его опыт поможет коллегам подготовиться к возможным неприятностям и не совершать тех же ошибок. 3
Часто навіть технічним спеціалістам потрібна допомога в структуруванні проєкту та розкладанні усього по поличках. Можливо, багато з вас брали участь в оцінюванні проєкту і навіть мають певні tips&trics. Але завжди знайдуться нюанси, які можна випадково пропустити. У статті розглянемо проєкт під мікроскопом, зокрема його оцінювання. 8
Максим Вишнивецкий, руководитель службы качества в Luxoft, имеет опыт изменения SDLC и подхода к работе с качеством в проекте на ScrumBut. О проблемах, собственных ошибках, решениях и результатах — в статье. 7
Павел Устинов, имея пятнадцатилетний опыт работы в ІТ, делится своими наблюдениями, как можно избежать факапов и не совершать базовых управленческих ошибок на проектах. Советы и кейсы из статьи помогут junior PM заранее «подстелить соломку», чтобы не набить все шишки на первом же проекте. Опытные РМ’ы тоже найдут для себя что-то полезное: всегда интересно узнать, как справляются с трудностями коллеги. 19
Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Проваливать проект — это не плохо, плохо выходить из проекта, не взяв на себя ответственность. Артем Ганжа, СЕО iSKY.solutions, рассказывает о факторах, которые повышают вероятность фейла и что делать, когда что-то пошло не так. 7
Проблема невідповідності естимейтів фактично витраченому часу знайома чи не кожному менеджеру. Як наслідок — виснаження, демотивація та інші неприємності, з якими доводиться немало працювати. Хоч би ким ви були — розробниками, тестувальниками, менеджерами, зацікавленими в темі оцінки часу, — запрошуємо до прочитання. 30
Проєктів без ризиків не буває, бувають лише неідентифіковані ризики. І з ризиками треба працювати, тільки якою мірою і за допомогою яких інструментів — залежить від ролі на проєкті, рівня занурення в проєкт, а також від стейкголдерів, з якими доводиться мати справу. Андрій Мудрий, що працює в ІТ-галузі майже 15 років, 10 з яких — у царині менеджменту, розповідає про керування ризиками. 5
Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. При этом хорошо выполненная и структурированная оценка может сильно помочь в последующих проектных активностях. Александр Катруша, Senior Engineering Manager, дает рекомендации по оценке трудоемкости проектов. 72
В первой части статьи Александра Катруши, Senior Engineering Manager, рассмотриваем основные сложности в оценке проектов, цели процесса оценки, требования к оценщику (разработчику), структуру и единицы измерения оценки. 21
Тема оценки проектов актуальна для многих проджект-менеджеров, которые сталкиваются с вопросами оценки задач, спринтов, релизов или разработки всего продукта. Наталья Ренская, Program Manager в Luxoft Ukraine, советует, как избежать головной боли (или хотя бы уменьшить ее) по поводу неправильных эстимейтов. 78
Все проекты уникальны. Нельзя четко сказать, на каком количестве клиентов, размере команды и величине прибыли для Product Manager заканчивается одна стадия роста и начинается другая. О роли продакта на разных этапах развития стартапа/продукта/проекта рассказывает Андрей Кароль, Product Manager в EduNav. 14
Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех). Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации. 43
В статье описаны 10 практичных и проверенных способов, как поставить задачу таким образом, чтобы жизнь разработчиков не казалось манной небесной, поставки срывались, бюджеты превышались, а качество трещало по швам. 39
Откровенно плохая архитектура, не-модульность компонентов, «костыли» — на выходе получатся продукт, который сложно поддерживать. Давайте разберемся, как же менеджеру проекта правильно работать с техническим долгом, чтобы не страдало качество проекта. 67
Большинство людей считают, что Канбан — методология разработки. Но так ли это на самом деле? Я бы хотел помочь разобраться с этим вопросом. 46
ПМ — это специалист, способный объединить вокруг себя проектную команду и обеспечить реализацию проекта, удовлетворяющего требованиям Заказчика. Часто требования весьма завышены, сроки крайне сжаты, а бюджеты таковы, что без «магии» проект просто не реализуем. 52
Вашей команде поручили реализовать проект — мобильное приложение. Приложение не сложное, но заказчик просит оценку по времени реализации. С чего начать? Данный опус поможет понять за что «хвататься» при оценке проекта с нуля. 94
В жизни каждого менеджера проекта наступает момент, когда заказчик спрашивает, на что же было потрачено время и почему проект запаздывает. В статье речь пойдет о случаях, когда задержка сроков поставки происходит, с точки зрения менеджера проекта, по вине заказчика. 43
За время своей работы я собрал перечень основных ошибок, которые часто совершают project менеджеры. Не оговаривайте всех деталей с клиентом (по ходу выясните), реагируйте эмоционально на любые спорные ситуации по проекту (вы же живой человек) и ни в коем случае не следите за ходом выполнения работ (надо доверять своим программистам). 43
Комментарии