×Закрыть

Материалы по теме «проект»

RSS

Оценка трудоемкости проектов разработки. Часть 2 Оценка трудоемкости проектов разработки. Часть 2

Oleksandr Katrusha 5274

Качественная оценка — необходимое, но недостаточное условие успеха. Следование лучшим практикам управления проектом и изменениями на всех его стадиях абсолютно необходимы. При этом хорошо выполненная и структурированная оценка может сильно помочь в последующих проектных активностях. Александр Катруша, Senior Engineering Manager, дает рекомендации по оценке трудоемкости проектов. 71

Оценка трудоемкости проектов разработки. Часть 1 Оценка трудоемкости проектов разработки. Часть 1

Oleksandr Katrusha 7782

В первой части статьи Александра Катруши, Senior Engineering Manager, рассмотриваем основные сложности в оценке проектов, цели процесса оценки, требования к оценщику (разработчику), структуру и единицы измерения оценки. 21

Как избежать неправильного оценивания проектов Как избежать неправильного оценивания проектов

Natali Renska 13599

Тема оценки проектов актуальна для многих проджект-менеджеров, которые сталкиваются с вопросами оценки задач, спринтов, релизов или разработки всего продукта. Наталья Ренская, Program Manager в Luxoft Ukraine, советует, как избежать головной боли (или хотя бы уменьшить ее) по поводу неправильных эстимейтов. 78

Роль Product Manager на разных этапах развития проекта Роль Product Manager на разных этапах развития проекта

Andrei Karol 9192

Все проекты уникальны. Нельзя четко сказать, на каком количестве клиентов, размере команды и величине прибыли для Product Manager заканчивается одна стадия роста и начинается другая. О роли продакта на разных этапах развития стартапа/продукта/проекта рассказывает Андрей Кароль, Product Manager в EduNav. 14

Быстрая и точная оценка проекта Быстрая и точная оценка проекта

Andrew Batutin 22433

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех). Я попробую изложить подход, который вы можете использовать, если обнаружите себя в подобной ситуации. 42

Вредные советы по постановке задач и описанию требований Вредные советы по постановке задач и описанию требований

Kostiantyn Perevoznyk 26075

В статье описаны 10 практичных и проверенных способов, как поставить задачу таким образом, чтобы жизнь разработчиков не казалось манной небесной, поставки срывались, бюджеты превышались, а качество трещало по швам. 39

Технический долг: профилактика и погашение Технический долг: профилактика и погашение

Oliinyk Denys 11689

Откровенно плохая архитектура, не-модульность компонентов, «костыли» — на выходе получатся продукт, который сложно поддерживать. Давайте разберемся, как же менеджеру проекта правильно работать с техническим долгом, чтобы не страдало качество проекта. 67

О роли PM и менеджменте больших масштабируемых проектов О роли PM и менеджменте больших масштабируемых проектов

Kirill Sidorov 15022

ПМ — это специалист, способный объединить вокруг себя проектную команду и обеспечить реализацию проекта, удовлетворяющего требованиям Заказчика. Часто требования весьма завышены, сроки крайне сжаты, а бюджеты таковы, что без «магии» проект просто не реализуем. 52

Как оценить сроки проекта с нуля: метод «критического пути» Как оценить сроки проекта с нуля: метод «критического пути»

Ivan Kutanin 18742

Вашей команде поручили реализовать проект — мобильное приложение. Приложение не сложное, но заказчик просит оценку по времени реализации. С чего начать? Данный опус поможет понять за что «хвататься» при оценке проекта с нуля. 94

Где мы теряем время: причины срыва сроков «по вине заказчика» Где мы теряем время: причины срыва сроков «по вине заказчика»

Елена Голубенко 12122

В жизни каждого менеджера проекта наступает момент, когда заказчик спрашивает, на что же было потрачено время и почему проект запаздывает. В статье речь пойдет о случаях, когда задержка сроков поставки происходит, с точки зрения менеджера проекта, по вине заказчика. 43

13 вредных советов для проектного менеджера 13 вредных советов для проектного менеджера

Александр Карпилович 16060

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

Best practice по планированию работ. Опыт проектного менеджера Best practice по планированию работ. Опыт проектного менеджера

Igor Dumbur 21958

Предлагаю рассмотреть два case-study, которые я взял из собственного опыта. Поговорим о декомпозиции и планировании работ, а также о выдерживании сроков по релизам, промежуточным билдам и прочим ключевым датам. 73

7 признаков того, что вы не готовы стать менеджером проекта 7 признаков того, что вы не готовы стать менеджером проекта

Светлана Кошеленко 28777

Любой человек способен научиться рисовать диаграммы Ганта, но эффективные менеджеры проектов полагаются на здравый смысл, который приходит с опытом. Или не приходит... Ваши потуги вряд ли будут полезны, если вы изначально не обладаете теми качествами, которые будут необходимы каждый день, чтобы направлять проект к успеху. 65

Как быстро и больно убить проект Как быстро и больно убить проект

Dmitriy Voshkarin 24721

Список из 10-ти шагов, как быстро и больно убить проект. Не принимайте во внимание риски, забудьте слова Scrum, XP, Kanban и ни в коем случае не стоит поощрять желание к саморазвитию. 114

Комментарии

. Договора в електронній формі. ЕЦП круто лише в межах України і то не дуже й то популярно. Як укладати договора віддалено з іноземцями? Чи мають скани з підписом однієї сторони якусь юридичну силу?
Отдельный респект за анимашную визуализацию сортировок...
«так ведь других нет!?» (к) При том, что в з.п. от местных не особо отличается. я так понимаю вы вообще не в курсе и правда «почему тогда» ))
наличие целой толпы успешных университетов и вполне себе толпы средних но хороших как бы б этот тезис никак не подтверждает на практике )) Они, возможно и хорошие.
На мій подив, цю статтю з очевидними основами досить тепло зустріли. Я думав буде гірше. Але так, погодитись на публікацію на Доу — все одно, що підписати контракт з дияволом. Ти знаєш, на що йдеш. Потім не скигли.
Мій принцип використання інтернету, сформований за багато років, полягає у наступному: завантажую сайт із закладинок, збережених раніше, і проглядаю список публікацій. Якщо тема, з якихось причин, мене зацікавила, я відкриваю її у новій вкладці.
Я Вас шукав. Чесно, ще не читаючи статті, очікував побачити купу гнівних коментарів на тему: «кеп», «баян», «це і так всі знають» тощо. А знайшов перший такий десь внизу, та й то у вкладенні. Невже я переоцінив вміст жовчі у наших краях?
Принципова різниця між Вашим дописом і формальними, часто канцелярськими, джерелами — це жива мова і приклади з практики.
До речі, слушна думка. Весь матеріал пройшов, наче художній твір, а не технічну статтю. Набагато простіше, ніж у Кормена та інших джерелах, що мені траплялися.
Мне кажется Перекрестись.
Я вам скажу в чем разница с США — ты не найдёшь в сша чувака с университетским дипломом в компьютер сайнс и не знающего описанных в статье базовых основ. А на украинских галерах хватает всяких магистров ничего про это толком не знающих.
Спасибо за статью, не слышал до этого про, trusted types интересно было узнать.
Если речь конкретно о доу, то все очевидно — здесь настолько токсичное коммьюнити, что необходимо иметь завидный уровень толстокожести, чтобы писать здесь посты.
От себя скажу, что микрофронтенд — отличная штука, если знать как её варить и кушать затем. Тут все дело в правильно построенной архитектуре. На данном проекте полёт нормальный.
Градус по нарастающей для тех, кого на пи-побольство нужно развести и потом подставить.