Нещодавно на форумі DOU викликав жваве обговорення топік про те, як довго слід працювати на одному проєкті. У численних коментарях під ним думки аудиторії розділилися: одні стверджували, що для саморозвитку доцільно змінювати проєкти раз на рік-два, інші ж переконані, що багаторічна робота на одному проєкті критично важлива для професійного зростання. Тож ми запитали у фахівців із різним досвідом, як часто треба змінювати проєкти.
Health-чек проєкту може бути актуальним для багатьох: від топменеджерів і власників бізнесу до будь-кого в компанії. Він допоможе краще оцінити якість сервісу на проєкті, виявити те, що можна поліпшити, та запобігти можливим ризикам. Як його проводити — у статті Юлії Сичкової, Head of Delivery у Fulcrum Rocks.
Есть ряд стандартных типов контрактов, и каждый из них может иметь различные варианты. Какие вопросы стоит задать, чтобы выбрать подходящий? Наталья Ренская, организационный консультант-коуч, создала детальную инструкцию с примерами.
Ця стаття — про те, як зробити процес передачі/отримання проєкту легким і навіть приємним. Стаття буде корисна молодим командам, які ще не пройшли всі перешкоди на своєму шляху, або лідерам команд, які тільки опановують цю роль.
Мы все знаем, что релизят код, а проект заканчивают. Но будем говорить о том, как делать не надо. А за 8 лет в проектном менеджменте у Павла Устинова, как и у каждого РМ’а, накопилось множество историй из серии «как лучше не делать». Его опыт поможет коллегам подготовиться к возможным неприятностям и не совершать тех же ошибок.
Часто навіть технічним спеціалістам потрібна допомога в структуруванні проєкту та розкладанні усього по поличках. Можливо, багато з вас брали участь в оцінюванні проєкту і навіть мають певні tips&trics. Але завжди знайдуться нюанси, які можна випадково пропустити. У статті розглянемо проєкт під мікроскопом, зокрема його оцінювання.
Максим Вишнивецкий, руководитель службы качества в Luxoft, имеет опыт изменения SDLC и подхода к работе с качеством в проекте на ScrumBut. О проблемах, собственных ошибках, решениях и результатах — в статье.
Павел Устинов, имея пятнадцатилетний опыт работы в ІТ, делится своими наблюдениями, как можно избежать факапов и не совершать базовых управленческих ошибок на проектах. Советы и кейсы из статьи помогут junior PM заранее «подстелить соломку», чтобы не набить все шишки на первом же проекте. Опытные РМ’ы тоже найдут для себя что-то полезное: всегда интересно узнать, как справляются с трудностями коллеги.
Фейлят все — и большие компании с опытом, и маленькие «зеленые» фирмы. Не фейлить невозможно. Проваливать проект — это не плохо, плохо выходить из проекта, не взяв на себя ответственность. Артем Ганжа, СЕО iSKY.solutions, рассказывает о факторах, которые повышают вероятность фейла и что делать, когда что-то пошло не так.
Проблема невідповідності естимейтів фактично витраченому часу знайома чи не кожному менеджеру. Як наслідок — виснаження, демотивація та інші неприємності, з якими доводиться немало працювати. Хоч би ким ви були — розробниками, тестувальниками, менеджерами, зацікавленими в темі оцінки часу, — запрошуємо до прочитання.
Проєктів без ризиків не буває, бувають лише неідентифіковані ризики. І з ризиками треба працювати, тільки якою мірою і за допомогою яких інструментів — залежить від ролі на проєкті, рівня занурення в проєкт, а також від стейкголдерів, з якими доводиться мати справу. Андрій Мудрий, що працює в ІТ-галузі майже 15 років, 10 з яких — у царині менеджменту, розповідає про керування ризиками.
Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. При этом хорошо выполненная и структурированная оценка может сильно помочь в последующих проектных активностях. Александр Катруша, Senior Engineering Manager, дает рекомендации по оценке трудоемкости проектов.
В первой части статьи Александра Катруши, Senior Engineering Manager, рассмотриваем основные сложности в оценке проектов, цели процесса оценки, требования к оценщику (разработчику), структуру и единицы измерения оценки.
Тема оценки проектов актуальна для многих проджект-менеджеров, которые сталкиваются с вопросами оценки задач, спринтов, релизов или разработки всего продукта. Наталья Ренская, Program Manager в Luxoft Ukraine, советует, как избежать головной боли (или хотя бы уменьшить ее) по поводу неправильных эстимейтов.
Все проекты уникальны. Нельзя четко сказать, на каком количестве клиентов, размере команды и величине прибыли для Product Manager заканчивается одна стадия роста и начинается другая. О роли продакта на разных этапах развития стартапа/продукта/проекта рассказывает Андрей Кароль, Product Manager в EduNav.
Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех). Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации.
В статье описаны 10 практичных и проверенных способов, как поставить задачу таким образом, чтобы жизнь разработчиков не казалось манной небесной, поставки срывались, бюджеты превышались, а качество трещало по швам.
Откровенно плохая архитектура, не-модульность компонентов, «костыли» — на выходе получатся продукт, который сложно поддерживать. Давайте разберемся, как же менеджеру проекта правильно работать с техническим долгом, чтобы не страдало качество проекта.
Большинство людей считают, что Канбан — методология разработки. Но так ли это на самом деле? Я бы хотел помочь разобраться с этим вопросом.
ПМ — это специалист, способный объединить вокруг себя проектную команду и обеспечить реализацию проекта, удовлетворяющего требованиям Заказчика. Часто требования весьма завышены, сроки крайне сжаты, а бюджеты таковы, что без «магии» проект просто не реализуем.
Комментарии