Комментарии 35
Интересно, и хочется продолжения.
P.S. Ох и эмблемка статьи у вас, брр :) Масоны отаке1!
P.S. Ох и эмблемка статьи у вас, брр :) Масоны отаке1!
Спасибо!
Будет продолжение ;]
Будет продолжение ;]
это не моасоны, это иллюминаты :)
ru.wikipedia.org/wiki/%D0%98%D0%BB%D0%BB%D1%8E%D0%BC%D0%B8%D0%BD%D0%B0%D1%82%D1%8B
ru.wikipedia.org/wiki/%D0%98%D0%BB%D0%BB%D1%8E%D0%BC%D0%B8%D0%BD%D0%B0%D1%82%D1%8B
Давайте прочтем тут: http://ru.wikipedia.org/wiki/Масоны
«В символике всемирного масонства это изображение обозначает властительную вершину — треугольное око т. н. «Великого Архитектора Вселенной» — так они называют Бога-Творца. «Лучезарная дельта» у масонов является знаком просвещенности или принципа сознания, напоминающим масону о всепроникновении Творца, Высшего Бытия. Это главный масонский символ первого градуса, степени ученика. Стилистически, глаз часто заменяет вписанная в треугольник окружность.»
А иллюминаты — ну что они — совсем не страшные по сравнению с масонами :)
«В символике всемирного масонства это изображение обозначает властительную вершину — треугольное око т. н. «Великого Архитектора Вселенной» — так они называют Бога-Творца. «Лучезарная дельта» у масонов является знаком просвещенности или принципа сознания, напоминающим масону о всепроникновении Творца, Высшего Бытия. Это главный масонский символ первого градуса, степени ученика. Стилистически, глаз часто заменяет вписанная в треугольник окружность.»
А иллюминаты — ну что они — совсем не страшные по сравнению с масонами :)
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.»
Ну после этого точно куплю вашу книжку =D
А по существу — очень нравятся ваши мысли. Пишите ещё :)
С удовольствием бы послушал про реализацию собственных идей, с самостоятельным инвестированием. То есть, как составить реальный план, находясь в эйфории собственной идеи.
Ну после этого точно куплю вашу книжку =D
А по существу — очень нравятся ваши мысли. Пишите ещё :)
С удовольствием бы послушал про реализацию собственных идей, с самостоятельным инвестированием. То есть, как составить реальный план, находясь в эйфории собственной идеи.
Очень полезно понимать все 3 требования на каждом этапе работ, т.е. что значит качественно и вовремя применительно к проектированию и как это влияет на недорого. Также надо иметь ввиду, что понятия вовремя и недорого немного меняют смысл на не fixed price проектах, например, в Agile, где вовремя может быть применено только к итерации, а не всему проекту в целом из-за постоянного изменения требований к продукту.
Вы забыли основное ограничение — содержание проекта))
Традиционно считается что успешный проект, который находится в рамках следующих ограничений («тройное ограничение» — правда ограничений самих больше :):
— содержание
— сроки
— стоимость
— качество
— удовлетворенность заказчика
Часть из требований вы могли опустить на начальном этапе и признать их гибкими. Например с самого начала вы договаривайтесь с заказчиком — «Слушай, ты сам не знаешь чего ты хочешь. Давай будем работать по Agile. И критерий успешности проекта — выполнение каждой итерации в срок, в рамках стоимости, с получением необходимого содержания, с должным качеством».
По поводу тезиса
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.» — это может быть правдой только при одном условии. Что вы не сформулировали критерии успешности проекта вместе с заказчиком и спонсором. А это нужно делать на начальной стадии проекта.
Традиционно считается что успешный проект, который находится в рамках следующих ограничений («тройное ограничение» — правда ограничений самих больше :):
— содержание
— сроки
— стоимость
— качество
— удовлетворенность заказчика
Часть из требований вы могли опустить на начальном этапе и признать их гибкими. Например с самого начала вы договаривайтесь с заказчиком — «Слушай, ты сам не знаешь чего ты хочешь. Давай будем работать по Agile. И критерий успешности проекта — выполнение каждой итерации в срок, в рамках стоимости, с получением необходимого содержания, с должным качеством».
По поводу тезиса
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.» — это может быть правдой только при одном условии. Что вы не сформулировали критерии успешности проекта вместе с заказчиком и спонсором. А это нужно делать на начальной стадии проекта.
Верно подмечено. У каждого участника проекта своё представление о успешности проекта, как и критерии оценки. (Помните у Роберта Шекли «Па-де-труа шеф-повара, официанта и клиента»? Вот, оно самое.)
А у хозяев бизнеса вообще своё представление о том, что должна делать компания и успешность проектов ему как правило вторична.
А у хозяев бизнеса вообще своё представление о том, что должна делать компания и успешность проектов ему как правило вторична.
Всё просто: с начала проекта ДОГОВОРИТЕСЬ что вы считаете успешным.
VasilioRuzanni — пример почему удовлетворенность не является единственным критерием. Например менеджер в web-студии. Делает проект (сайт) для клиента. У проекта огромное вылезание за содержание проекта, сроки и бюджет при контракте fixed-price. Т.е. например он делает всё что просит заказчик, игнорируя контракт.
Итог — заказчик доволен. Студия получила расходы существенно выше стоимости сайта.
VasilioRuzanni — пример почему удовлетворенность не является единственным критерием. Например менеджер в web-студии. Делает проект (сайт) для клиента. У проекта огромное вылезание за содержание проекта, сроки и бюджет при контракте fixed-price. Т.е. например он делает всё что просит заказчик, игнорируя контракт.
Итог — заказчик доволен. Студия получила расходы существенно выше стоимости сайта.
Ну так, удовлетворенности то нужно достичь не просто так, а в тех самых остальных 4-х рамках проекта. Само собой, заказчик будет на 7-м небе от счастья, если вы сделаете ему все бесплатно. Но этого вы не можете себе позволить.
Я априори исхожу из правила, что это должно быть выгодно для бизнеса (иначе нет смысла в самом бизнесе). И тут уже каждый сам определяет, сколько для него «стоит» отношение заказчика, когда приходится идти на компромиссы. Изредка встречается и ситуация, когда проект «выгодно» сделать, несмотря на то, что он в конкретный момент невыгоден для бизнеса — например, когда вы с большой долей уверенности получите куда больший проект.
Это все рассматривая с позиции бизнеса.
Удовлетворенность же является важнейшим критерием с позиции заказчика (то есть, заказчик должен быть доволен, хотя это и не является поводом для жертвы всеми остальными параметрами проекта).
Я априори исхожу из правила, что это должно быть выгодно для бизнеса (иначе нет смысла в самом бизнесе). И тут уже каждый сам определяет, сколько для него «стоит» отношение заказчика, когда приходится идти на компромиссы. Изредка встречается и ситуация, когда проект «выгодно» сделать, несмотря на то, что он в конкретный момент невыгоден для бизнеса — например, когда вы с большой долей уверенности получите куда больший проект.
Это все рассматривая с позиции бизнеса.
Удовлетворенность же является важнейшим критерием с позиции заказчика (то есть, заказчик должен быть доволен, хотя это и не является поводом для жертвы всеми остальными параметрами проекта).
Думаю, что удовлетворенность заказчика — это из другого измерения, нежели 4 остальные (основные) величины. Это цель самого проекта, независимо от этих 4-х параметров. Эти 4 параметра являются рамками проекта, в то время как удовлетворенность заказчика не является (а является целью и, в том числе, управляется отдельно — дисциплина Expectations Management).
По этому поводу можно дискутировать.
В моей практике содержание проекта всегда известно до его начала. Результат — весьма конкретен и целостен, его и ожидает Заказчик, «почти готово» — не считается выполненным результатом. За такое не платят. Примеры из личного опыта: ERP roll-out, реорганизация, строительство. В таких проектах неопределенность в отношении содержания недопустима. Есть цель, срок и бюджет.
В разработке ПО, действительно, содержание должно быть критерием успеха.
Удовлетворенность заказчика — слишком субъективная мера оценки. У нее нет меры. Есть договорные обязательства, их нужно выполнить. Есть лояльность клиента.
Я ни разу не встречал способа измерить удовлетворенность от единичного проекта. Буду рад доказательству обратного.
В моей практике содержание проекта всегда известно до его начала. Результат — весьма конкретен и целостен, его и ожидает Заказчик, «почти готово» — не считается выполненным результатом. За такое не платят. Примеры из личного опыта: ERP roll-out, реорганизация, строительство. В таких проектах неопределенность в отношении содержания недопустима. Есть цель, срок и бюджет.
В разработке ПО, действительно, содержание должно быть критерием успеха.
Удовлетворенность заказчика — слишком субъективная мера оценки. У нее нет меры. Есть договорные обязательства, их нужно выполнить. Есть лояльность клиента.
Я ни разу не встречал способа измерить удовлетворенность от единичного проекта. Буду рад доказательству обратного.
Удовлетворенность заказчика — да, очень субъективная, поэтому хорошо иметь хоть какой-то набор, пусть и субъективных критериев. Но при всей «необъективности» от удовлетворенности в большой мере зависит успешность проекта в частности, и взаимоотношения с клиентом в целом.
Удовлетворенность можно не мерять в точных единицах. Зачастую достаточно простого «доволен/не очень/недоволен», чтобы сделать соответствующие выводы.
Удовлетворенность можно не мерять в точных единицах. Зачастую достаточно простого «доволен/не очень/недоволен», чтобы сделать соответствующие выводы.
Я когда-то считался хорошим специалистом по SAP CRM, продавал это решение в качестве пре-сейла. Рассказывал про лояльность, удовлетворенность и прочие радости удержания клиента в рамках его жизненного цикла.
Точных методов расчета показателя удовлетворенности не встречал еще. ;]
Грубо говоря, удовлетворенный клиент может стать лояльным. Купил несколько раз — удовлерен, купил много раз или просто много — повод задуматься о переводе в ключевые клиенты.
Точных методов расчета показателя удовлетворенности не встречал еще. ;]
Грубо говоря, удовлетворенный клиент может стать лояльным. Купил несколько раз — удовлерен, купил много раз или просто много — повод задуматься о переводе в ключевые клиенты.
Ну так я и не спорю, что методов расчета точных нет — я говорю лишь о том, что это не повод не управлять этим параметром, несмотря на субъективность.
Точно мы знать не можем — но можем предполагать примерно — и этим надо пользоваться — это очень важно. Нужно меньше усилий, когда клиент понимает, что хочет и может это объяснить и больше усилий, когда он сам слабо понимает, что ему нужно. Но, думаю, это вы и сами уже знаете :)
Точно мы знать не можем — но можем предполагать примерно — и этим надо пользоваться — это очень важно. Нужно меньше усилий, когда клиент понимает, что хочет и может это объяснить и больше усилий, когда он сам слабо понимает, что ему нужно. Но, думаю, это вы и сами уже знаете :)
Нужно. Важно. Обязательно.
Но все это относится к деятельности отдела продаж или еще кого-то, кто клиента ведет.
Дисциплина управления проектами предполагает исключать из проекта всю работу, которая не помогает выполнить результат. Для этого определяют зависимости между задачами, сетевые диаграммы рисуют.
Если методология выполнения предполагает проведение представительских мероприятий, то можно считать управление удовлетворенностью частью проекта. И отчитываться по статусу ежемесячной задачи «Поход в баню» перед руководством ;]
Но все это относится к деятельности отдела продаж или еще кого-то, кто клиента ведет.
Дисциплина управления проектами предполагает исключать из проекта всю работу, которая не помогает выполнить результат. Для этого определяют зависимости между задачами, сетевые диаграммы рисуют.
Если методология выполнения предполагает проведение представительских мероприятий, то можно считать управление удовлетворенностью частью проекта. И отчитываться по статусу ежемесячной задачи «Поход в баню» перед руководством ;]
Я так думаю, что задача отдела продаж — продать. Аккаунт-менеджеры и сэйлы занимаются именно этим. Во время проекта, и в контексте этого проекта клиента ведут проект-менеджеры и управление ожиданиями и удовлетворенностью — их задача (могут быть выделены отдельные роли и люди под это — но это часть проектной команды, ведь они отвечают за успех проекта).
Да, к слову, поход в баню в реальности бывает играет куда более решающую роль в проекте, чем правильно принятое архитектурное решение (это если смотреть на примере ИТ-проекта).
Да, к слову, поход в баню в реальности бывает играет куда более решающую роль в проекте, чем правильно принятое архитектурное решение (это если смотреть на примере ИТ-проекта).
«Теперь — черед рассуждений о том, что же нужно сделать, чтоы проект считался успешным.» — бувка потерялась
Верно подмечено. У каждого участника проекта своё представление о успешности проекта, как и критерии оценки. (Помните у Роберта Шекли «Па-де-труа шеф-повара, официанта и клиента»? Вот, оно самое.)
А у хозяев бизнеса вообще своё представление о том, что должна делать компания и успешность проектов ему как правило вторична.
А у хозяев бизнеса вообще своё представление о том, что должна делать компания и успешность проектов ему как правило вторична.
Успешный проект (imho) — это тот, который полностью удовлетворил заказчика (без прямой зависимости от качества, сроков, и перерасходованного бюджета). Клиент может быть вполне доволен по разным причинам, получив в итоге продукт позже и дороже, того же качества на который рассчитывал. Такой проект вполне можно считать успехом.
Ровно также как и проект, который уложили в бюджет, сроки и задали приемлемый уровень качества может не быть успешным — например, заказчик ожидал что-то еще более «эдакое крутое» (часто даже сам не знает, что именно — поэтому важно управление ожиданиями).
Ровно также как и проект, который уложили в бюджет, сроки и задали приемлемый уровень качества может не быть успешным — например, заказчик ожидал что-то еще более «эдакое крутое» (часто даже сам не знает, что именно — поэтому важно управление ожиданиями).
Статья написана красивыми словами, но по сути — может привести к большим ошибкам и полном краху.
Автор, прости меня, пишешь действительно замечательно, но дабы люди все-таки становились успешными управленцами, стоит пояснить некоторые моменты.
Критерии успешности, которые поставлены во главу угла статьи — недостижимы в принципе.
Что такое качественно? Для заказчика это означает одно, а для разработчика — совсем другое. И именно на эти грабли чаще всего наступают те, кто поднимает проект.
Чтобы говорить об успешности проекта, не плохо бы для начала понять ЧТО такое проект? Википедия нам это объясняет: "Проект — это уникальная деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата."
О! Уже понятнее. Итак, проект имеет своей целью ОПРЕДЕЛЕННЫЙ РЕЗУЛЬТАТ! Качество тут вообще и рядом не лежит. Ибо — результат либо есть, либо его нет. Результат не может быть качественным, или некачественным.
Понятие результата же вытекает из постановки ЦЕЛЕЙ. Если цель достигнута — результат есть. Если нет — результата нет.
Результируя, дабы уже не утомлять всех:
Успешный проект — это проект, который достиг поставленную заранее ЦЕЛЬ, в намеченные заранее СРОКИ, с потраченным материальным активном, который заложен в план проекта заранее.
Автор, прости меня, пишешь действительно замечательно, но дабы люди все-таки становились успешными управленцами, стоит пояснить некоторые моменты.
Критерии успешности, которые поставлены во главу угла статьи — недостижимы в принципе.
Что такое качественно? Для заказчика это означает одно, а для разработчика — совсем другое. И именно на эти грабли чаще всего наступают те, кто поднимает проект.
Чтобы говорить об успешности проекта, не плохо бы для начала понять ЧТО такое проект? Википедия нам это объясняет: "Проект — это уникальная деятельность, имеющая начало и конец во времени, направленная на достижение определённого результата."
О! Уже понятнее. Итак, проект имеет своей целью ОПРЕДЕЛЕННЫЙ РЕЗУЛЬТАТ! Качество тут вообще и рядом не лежит. Ибо — результат либо есть, либо его нет. Результат не может быть качественным, или некачественным.
Понятие результата же вытекает из постановки ЦЕЛЕЙ. Если цель достигнута — результат есть. Если нет — результата нет.
Результируя, дабы уже не утомлять всех:
Успешный проект — это проект, который достиг поставленную заранее ЦЕЛЬ, в намеченные заранее СРОКИ, с потраченным материальным активном, который заложен в план проекта заранее.
Не совсем понял, что может привести к краху. :]
Сейчас чуть-чуть порассуждаю о качестве.
Если говорить о качестве, то Цель можно выполнить:
— отлично и даже чуть-чуть лучше, чем ожидалось;
— хорошо;
— удовлетворительно;
— хреновенько, но работает;
— неудовлетворительно. Что-то вроде «теоритически это лошадь, а практически — на ногах не стоит».
Критерии оценки качества следует оговоривать сразу же после постановки цели.
Думаю, стоит написать о ограничениях проекта подробнее. Напишу.
А о том, что такое проект я как-то писал в своем блоге: www.neposeda.tv/content/koroiva-na-ldu-vypusk-vtoroi
Сейчас чуть-чуть порассуждаю о качестве.
Если говорить о качестве, то Цель можно выполнить:
— отлично и даже чуть-чуть лучше, чем ожидалось;
— хорошо;
— удовлетворительно;
— хреновенько, но работает;
— неудовлетворительно. Что-то вроде «теоритически это лошадь, а практически — на ногах не стоит».
Критерии оценки качества следует оговоривать сразу же после постановки цели.
Думаю, стоит написать о ограничениях проекта подробнее. Напишу.
А о том, что такое проект я как-то писал в своем блоге: www.neposeda.tv/content/koroiva-na-ldu-vypusk-vtoroi
Вот, с этим практически на 100% согласен. Разве что определение термина «проект» мне исторически ближе из PMBOK, я же его переводил когда-то :).
Да, проект должен банально оставаться в рамках project scope, чтобы добраться до scope продукта, а «удовлетворенность», «качество» — это лишь эмоции, если не выражены в конкретных требованиях. И даже лучше делать — не нужно. Нужно точно. Потому что заинтересованные лица проекта, стейкхолдеры, то бишь, не всегда явно озвучивают свои интересы. У меня был случай, когда разрабатываемая технология очистки получилась круче, чем требовалось. Хорошо ли это? Большой вопрос. Потому что выяснилось (слава богу, не слишком поздно), что один из соинвесторов технологически был завязан именно на наличие конкретного состава, не более чистого, а конкретного.
Да, проект должен банально оставаться в рамках project scope, чтобы добраться до scope продукта, а «удовлетворенность», «качество» — это лишь эмоции, если не выражены в конкретных требованиях. И даже лучше делать — не нужно. Нужно точно. Потому что заинтересованные лица проекта, стейкхолдеры, то бишь, не всегда явно озвучивают свои интересы. У меня был случай, когда разрабатываемая технология очистки получилась круче, чем требовалось. Хорошо ли это? Большой вопрос. Потому что выяснилось (слава богу, не слишком поздно), что один из соинвесторов технологически был завязан именно на наличие конкретного состава, не более чистого, а конкретного.
Качество — такое же понятие, как «норма», «средняя температура по больнице» и т.п.
О качестве можно рассуждать только сравнивая что-то с чем-то. К тому-же разные люди, будут это делать по разному.
Пример: Для богатого человека качественное вино — это вино за 1000 долларов бутылка, 12 летней выдержки, из определенных сортов винограда, и определенных мест произростаний.
Для очень бедного — качественное вино, это любое вино дороже 500 рублей.
Каждый их них сравнивает по среднему арифметическому того, что он может себе позволить и о чем может делать суждения. Сказать о продукте качественный он или нет, они смогут только сравнивая с похожими товарами, которые их устраивают или не устраивают.
Если мы говорим о разработке программных продуктов, то очень часто это уникальные разработки, сравнивать которые с чем-либо невозможно. Следовательно говорить о том, качественные они или нет — не представляется возможным. Можно говорить только о том, достигнута ли цель, которая поставлена перед началом разработки — или нет.
Опять же — разговоры о качестве часто рождаются тогда, когда не понятна цель. Такие разговоры всегда сопровождаются сравнениями:
— а вот у моего конкурента лучше/хуже
— а вот другие разработчики мне предлагали круче/не круче
— а вот я видел, что это было реализовано «качественнее»
Заказчики (и разработчики), которые заводят подобные речи, чаще всего не знают четко, какую цель должен удовлетворить создаваемый продукт. Поэтому остается рассуждать о качестве.
Если цель поставлена четко и удовлетворяется, к примеру: «Увеличить товарооборот компании в 3 раза от существующего через 6 месяцев», «Упростить документооборот, тем самым уменьшив время отклика клиенту до 1 часа» и т.д. — тогда о качестве вообще не возникает разговоров. Тут уже возникнут другие разговоры: Почему цель не достигнута, и как ее достигнуть.
А о крахе я говорил по той причине, что критерии «качества» — настолько необъятные, что если рассуждать подобными понятиями — можно создать не то и не для тех (см. пример с вином).
О качестве можно рассуждать только сравнивая что-то с чем-то. К тому-же разные люди, будут это делать по разному.
Пример: Для богатого человека качественное вино — это вино за 1000 долларов бутылка, 12 летней выдержки, из определенных сортов винограда, и определенных мест произростаний.
Для очень бедного — качественное вино, это любое вино дороже 500 рублей.
Каждый их них сравнивает по среднему арифметическому того, что он может себе позволить и о чем может делать суждения. Сказать о продукте качественный он или нет, они смогут только сравнивая с похожими товарами, которые их устраивают или не устраивают.
Если мы говорим о разработке программных продуктов, то очень часто это уникальные разработки, сравнивать которые с чем-либо невозможно. Следовательно говорить о том, качественные они или нет — не представляется возможным. Можно говорить только о том, достигнута ли цель, которая поставлена перед началом разработки — или нет.
Опять же — разговоры о качестве часто рождаются тогда, когда не понятна цель. Такие разговоры всегда сопровождаются сравнениями:
— а вот у моего конкурента лучше/хуже
— а вот другие разработчики мне предлагали круче/не круче
— а вот я видел, что это было реализовано «качественнее»
Заказчики (и разработчики), которые заводят подобные речи, чаще всего не знают четко, какую цель должен удовлетворить создаваемый продукт. Поэтому остается рассуждать о качестве.
Если цель поставлена четко и удовлетворяется, к примеру: «Увеличить товарооборот компании в 3 раза от существующего через 6 месяцев», «Упростить документооборот, тем самым уменьшив время отклика клиенту до 1 часа» и т.д. — тогда о качестве вообще не возникает разговоров. Тут уже возникнут другие разговоры: Почему цель не достигнута, и как ее достигнуть.
А о крахе я говорил по той причине, что критерии «качества» — настолько необъятные, что если рассуждать подобными понятиями — можно создать не то и не для тех (см. пример с вином).
Ладно, уговорили написать о качестве.
Качество — это способность результата проекта удовлетворять заранее определенным критериям.
Например: цель — изготовить нестандартные болтик и гайку, предположим М10. Критерий качества: гайка накручивается на винт, пару изделий можно использовать в хозяйстве. Весь проект будет состоять из следующах операций:
1. Разработать чертеж;
2. Утвердить чертеж;
3. Выточить детали;
4. Приемочный тест: винт вкручивается в гайку.
Может быть куча дополнительных требований к качеству, как-то:
— долговечность;
— устойчивость к коррозии;
— гладкость поверхности и что-угодно еще.
Качественные характеристики требуют разработки однозначных критериев оценки.
Вам очень сложно будет убедить меня в том, что качеством невозможно управлять — в компании, сотрудником которой я являюсь, внедрена система управления качеством. Более того, я принимал участие в недавнем проекте аудита. Качество — есть. И это здорово ;]
Качество — это способность результата проекта удовлетворять заранее определенным критериям.
Например: цель — изготовить нестандартные болтик и гайку, предположим М10. Критерий качества: гайка накручивается на винт, пару изделий можно использовать в хозяйстве. Весь проект будет состоять из следующах операций:
1. Разработать чертеж;
2. Утвердить чертеж;
3. Выточить детали;
4. Приемочный тест: винт вкручивается в гайку.
Может быть куча дополнительных требований к качеству, как-то:
— долговечность;
— устойчивость к коррозии;
— гладкость поверхности и что-угодно еще.
Качественные характеристики требуют разработки однозначных критериев оценки.
Вам очень сложно будет убедить меня в том, что качеством невозможно управлять — в компании, сотрудником которой я являюсь, внедрена система управления качеством. Более того, я принимал участие в недавнем проекте аудита. Качество — есть. И это здорово ;]
Во! Уже теплее :)
Но тем не менее, по тому-же болту М10 цель какая то странная: Разработать нестандартные болтик и гайку. Спрашивается с какой целью? Для какой цели должен служить этот продукт? Не просто же так их делают нестандартными, для чего то? Для чего?
Тут можно только додумывать:
— Для того, чтобы дистанцироваться по внешнему виду от конкурентных товаров
— Для того, чтобы использовать болт при экстремально высоких температурах
— Для того, чтобы использовать изделие в нестандартных изделиях, где невозможно использовать стандартные М10
… но так и не угадать, что же хотел заказчик начать проводить операции…
То, что вы называете критериями оценки, я называю — задачами проекта :)
Потому что изначально ставятся ЗАДАЧИ. Продукт делается с целью достигнуть поставленные задачи. А когда продукт создан — проводятся тесты, с целью ОЦЕНИТЬ, насколько продукт соответствует тем целям, для которых его создавали.
Иными словами, критерии создаются ДО НАЧАЛА разработки. Для того, чтобы было по чему оценивать.
Но лучше, все-таки называть эти вещи задачами. Потому как большинство разработчиков часто соверашают одну и туже ошибку: Они используют критерии качества, ориентируясь на то, что ктото уже создал. «Дизайн возьмем от фейсбука, движок от хабра, пару модулей от Моего круга — будет крутой проект» :)
Задачами тут как-то не пахнет. Одни лишь критерии качества.
Но тем не менее, по тому-же болту М10 цель какая то странная: Разработать нестандартные болтик и гайку. Спрашивается с какой целью? Для какой цели должен служить этот продукт? Не просто же так их делают нестандартными, для чего то? Для чего?
Тут можно только додумывать:
— Для того, чтобы дистанцироваться по внешнему виду от конкурентных товаров
— Для того, чтобы использовать болт при экстремально высоких температурах
— Для того, чтобы использовать изделие в нестандартных изделиях, где невозможно использовать стандартные М10
… но так и не угадать, что же хотел заказчик начать проводить операции…
То, что вы называете критериями оценки, я называю — задачами проекта :)
Потому что изначально ставятся ЗАДАЧИ. Продукт делается с целью достигнуть поставленные задачи. А когда продукт создан — проводятся тесты, с целью ОЦЕНИТЬ, насколько продукт соответствует тем целям, для которых его создавали.
Иными словами, критерии создаются ДО НАЧАЛА разработки. Для того, чтобы было по чему оценивать.
Но лучше, все-таки называть эти вещи задачами. Потому как большинство разработчиков часто соверашают одну и туже ошибку: Они используют критерии качества, ориентируясь на то, что ктото уже создал. «Дизайн возьмем от фейсбука, движок от хабра, пару модулей от Моего круга — будет крутой проект» :)
Задачами тут как-то не пахнет. Одни лишь критерии качества.
«Именно в честь их пирамид, треугольных в профиль, ограничения проекта по срокам, качеству и бюждету назвали “Золотым треугольником”.»
А «любовный треугольник» в литературе тоже от Египетских пирамид пошёл?
Такой вопрос: А откуда вообще появилось желание дать определение понятию «успешный проект»?
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.»
А если спонсора нет? Если проект личный? А если он всё оправдал, кроме такого параметра, как отдача. Т.е. денег то и не принёс. Ну он качественный, вовремя сделан и в бюджет вписался, но оказался никому не нужен? Я имею в виду потребителя. Честно говоря можно ещё много всяких «если» можно придумать, но вывод я могу сделать такой: определение успешного проекта другое.
А «любовный треугольник» в литературе тоже от Египетских пирамид пошёл?
Такой вопрос: А откуда вообще появилось желание дать определение понятию «успешный проект»?
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.»
А если спонсора нет? Если проект личный? А если он всё оправдал, кроме такого параметра, как отдача. Т.е. денег то и не принёс. Ну он качественный, вовремя сделан и в бюджет вписался, но оказался никому не нужен? Я имею в виду потребителя. Честно говоря можно ещё много всяких «если» можно придумать, но вывод я могу сделать такой: определение успешного проекта другое.
Любовный треугольник назвали в честь барона Мюнхгаузена, очень популярного у дам, и его треуголки, которой он регулярно клялся ;]
По сути. Нужно различать успех проекта и успех продукта. Это — разные вещи.
Спонсор — это лицо, заинтересованное в проекте и обеспечивающее проект ресурсами.
Часть моей работы — обучение руководителей проектов. В том числе и «с нуля». Эти заметки — поиск истины в каком-то смысле. Пишу ответы на интересные вопросы о проектах. Вопрос «Какой проект успешен?» пришел мне от Даши. ;]
Хотите попробовать задать интересный вопрос?
По сути. Нужно различать успех проекта и успех продукта. Это — разные вещи.
Спонсор — это лицо, заинтересованное в проекте и обеспечивающее проект ресурсами.
Часть моей работы — обучение руководителей проектов. В том числе и «с нуля». Эти заметки — поиск истины в каком-то смысле. Пишу ответы на интересные вопросы о проектах. Вопрос «Какой проект успешен?» пришел мне от Даши. ;]
Хотите попробовать задать интересный вопрос?
Такой вопрос: Что важнее для руководителя, умение руководить или понимание того, чем занимается его «команда»?
Писал об этом недавно. В карманной газете для руководителей проектов. ;]
Спасибо за ответ. Я тоже был такого мнения, но хотелось авторитетного подтверждения.
Всегда пожалуйста ;]
Вот еще одна моя заметка, рассуждения на тему, кто такой руководитель проектов. Кто они, руководители проектов? Какими компетенциями должны обладать? Откуда они такие берутся: ими рождаются или становятся?
Вот еще одна моя заметка, рассуждения на тему, кто такой руководитель проектов. Кто они, руководители проектов? Какими компетенциями должны обладать? Откуда они такие берутся: ими рождаются или становятся?
«Успешным считается проект, повысивший зрелость компании в области управления проектами и оправдавший ожидания спонсоров к качеству, срокам и бюждету.»(с)
Соглашусь с Вами в том, что успешным считается проект оправдавший ожидания спонсоров к качеству, срокам, стоимости (или все же бюджет?). А повысил ли проект зреслость компании — это уже мотивация компании работать над проектом. Скажем так, это Ваша внутрення цель. У заказчика/инвестора могут быть свои цели и это, как правило, деньги. А вот участник проекта, прораб Петров, считает, что главная цель это зарплату вовремя домой приносить и о каких-то высших материях думать ему совсем не хочется.
ИМХО, все остальные (кроме качества, сроков, стоимости) критерии успешности проекта — это мотивация всех участников проекта.
Соглашусь с Вами в том, что успешным считается проект оправдавший ожидания спонсоров к качеству, срокам, стоимости (или все же бюджет?). А повысил ли проект зреслость компании — это уже мотивация компании работать над проектом. Скажем так, это Ваша внутрення цель. У заказчика/инвестора могут быть свои цели и это, как правило, деньги. А вот участник проекта, прораб Петров, считает, что главная цель это зарплату вовремя домой приносить и о каких-то высших материях думать ему совсем не хочется.
ИМХО, все остальные (кроме качества, сроков, стоимости) критерии успешности проекта — это мотивация всех участников проекта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какой проект успешен?