Я не работал во всех этих компаниях — это информация, полученная из открытых источников. Какое имеет отношение к вопросу работал я в них или нет? Если уж на то пошло, я работал в таких проектах, и да, были проекты которые заканчивались и успехом и провалом. Пересмотр текущих целей — не есть отсутствие целей, заметьте. И прекратите носиться как с писаной торбой со своим PMBOK.
Да это не более чем catch-phrases, главное — содержание. Эта статья достаточно банальна, но просто каждый пункт мне напоминает одну или несколько ситуаций из моей жизни, потому и решил перевести. Может быть прочтя еще раз одно и то же, кто-то не допустит тех же глупых ошибок.
Ну а что я вам должен ответить, если вы уперлись и не готовы воспринимать какие-либо альтернативные точки зрения? Гибкие методологии успешно используются многими компаниями по всему миру, включая google, phillips, nortel, yahoo, siemens medical solutions, paypal… я могу продолжать вечно. И все эти люди не согласны с вашим «значит что проекта вообще нет», с успешными результатами их труда вы сталкиваетесь каждый день. Смысл спорить? Вы действительно слишком категоричны.
Если пересмотр текущих целей проекта осуществляется на регулярной основе (как раз таки «гибкие» методологии), оценка ущерба и согласование изменений бюджетов и сроков не требуются. Вы же рассматриваете только вариант фиксированных требований, сроков и бюджетов.
Ну тогда это может случиться всего один раз, так? Если не спросили и не осознали — то нет проблемы, если не спросили и осознали — еще лучше, не вводить нового человека в проект.
Как вы думаете, как долго после «сделали вопреки» люди могут работать в команде? Под «не спросили» вы, случайно, не имеете ли ввиду «менеджер не в курсе чем занимается команда»?
Вообще, это перевод. Но все эти пункты напоминают мне мои и чужие ошибки, да. По той части 4го пункта на которой вы заострили внимание я могу и согласиться — да, должны, без какой-либо фиксации требований работать нельзя. Но жизнь — штука сложная, требования плывут. По разным причинам — по неопытности тех кто эти требования составляет, по причине того что под действием внешних факторов меняются потребности заказчика и т.п. Дыма без огня не бывает. Agile методологии — ответ на изменяющиеся требования.
Как попали люди с недостаточной квалификацией в команду? «Стремление рисковать» само по себе вреда ходу проекта не наносит, кто эти рискованные решения подтверждает? Кто дал играться с новыми технологиями в ущерб проекту? И последний вопрос — менеджер в такой команде это, выходит, тот кто подходит со спины три раза в день и спрашивает «Когда будет готово?» Так его легко можно заменить мартышкой с диктофоном.
отдельно статистики, конечно, нет — но за 2009 было несколько интервью, в которых представители Google говорили о том что они всё-таки надеются выйти по Youtube на окупаемость, аналитики credit suisse писали о том, что по их оценкам, благодаря Youtube, прибыль Google за 2009 почти что на полмиллиарда меньше.
youtube, когда был отдельной конторой был убыточен. убыточен и сейчас, как отдельный проект, а не часть Google Inc. Google из этого списка можно выкинуть — в 99ом гугл получил первые серьезные деньги от инвесторов, в 2000 уже продавался adwords. До сих пор приносит большую часть денег, что и позволяет содержать убыточные проекты.
Мне кажется, что срок в пару недель не особо критичен. Примерно столько нам понадобилось чтобы в 2006 самим от начала и до конца зарегистрировать компанию, открыть счета и получить все необходимые документы.
Я пытался аппелировать к элементарной логике — нет оценок/невозможно оценить — нет плана — нет бюджета. А так не бывает, хотя бы потому, что уже готового программного обеспечения вокруг навалом и я сильно сомневаюсь что какая-то статистически-различимая его доля написана по схеме «как будет готово — так будет готово, а пока отлистывайте деньги». По вашему выходит, что заказная разработка ПО может осуществляться только по почасовке? Так это тоже не так.
Я могу написать проще — в сфере в которой работаю я могу оценить проект с погрешностью 10-15%. Проект в смежной области я могу оценить более грубо, но и то, скорее всего, смогу накидать смету и сроки которые позволят потом не заводить разговоры с заказчиком в духе «мы вылетели из бюджета».
И я, заметьте, не использовал весьма спорных аргументов в духе «подавляющее количество софта пишется так-то», ну, право, ну откуда у вас такие сведения?
Оправданий для невозможности оценить хотя-бы грубо (пусть 30%-40% ошибки) при наличии вменяемого технического задания нет. Если это невозможно сделать — никакого бизнеса вообще не будет. И не надо под отсутствие этого навыка подводить научную базу, используя весьма сомнительную аргументацию.
Согласен, что строятся абстрактные модели, прототипы, проводятся различные испытания, но это всё поддаётся оценке и всё это является неотъемлемой частью любого проекта. То что более-менее похоже на то что раньше уже создавалось оценивается более точно, то что меньше — менее точно. Не нужно из этого делать какой-то особой магии.
Если бы в этом была некая магия, реализация многих высокотехнологичных коммерческих проектов была бы невозможна, только потому что в принципе-то всё понятно, но программное обеспечение — хрен знает когда. Люди работают, как закончат — так можем двигаться дальше. Такой подход делает невозможным любое планирование. Ну представьте себе NASA которые сидят и не запускают ракету, потому что программисты программируют и нет никаких оценок.
Слава богу это не так.
И все ваши выкладки по поводу разделения и неразделения проектирования они происходят от того же заблуждения, что программирование содержит в себе некий элемент исследовательской работы.
Я не люблю аналогии со строительством, но здесь они уместны. Здание начинается с эскиза, потом выбор материалов, чертежи, рассчеты, а потом уже кладут кирпич. Если используются новые материалы — они предварительно тестируются, если новые технологии — проверяются. После этого строят. В этом случае ваша фраза про проектировщика звучит примерно так «Бывают инженеры которые понарисуют таких чертежей, что потом бригадир с рабочими сами додумывают или строят по-своему», «эффективнее если рабочий сам сочиняет что строить». Это не правда. Да, действительно, можно собраться с друзьями и за выходные построить баньку на даче без особого плана, но небоскребы так не строятся. И не спорьте.
При этом, что банька, что небоскреб, с определенной погрешностью легко оцениваются человеком который руководил/участвовал в проекте постройки баньки или небоскреба.
А элемент «исследовательской» работы это ни что иное как то время, которое вы тратите на преобретение необходимого опыта для выполнения данной работы. Если вы уже обладаете необходимой квалификацией вы не промахнетесь в 10 раз с оценками.
Я могу написать проще — в сфере в которой работаю я могу оценить проект с погрешностью 10-15%. Проект в смежной области я могу оценить более грубо, но и то, скорее всего, смогу накидать смету и сроки которые позволят потом не заводить разговоры с заказчиком в духе «мы вылетели из бюджета».
И я, заметьте, не использовал весьма спорных аргументов в духе «подавляющее количество софта пишется так-то», ну, право, ну откуда у вас такие сведения?
Оправданий для невозможности оценить хотя-бы грубо (пусть 30%-40% ошибки) при наличии вменяемого технического задания нет. Если это невозможно сделать — никакого бизнеса вообще не будет. И не надо под отсутствие этого навыка подводить научную базу, используя весьма сомнительную аргументацию.
Если бы в этом была некая магия, реализация многих высокотехнологичных коммерческих проектов была бы невозможна, только потому что в принципе-то всё понятно, но программное обеспечение — хрен знает когда. Люди работают, как закончат — так можем двигаться дальше. Такой подход делает невозможным любое планирование. Ну представьте себе NASA которые сидят и не запускают ракету, потому что программисты программируют и нет никаких оценок.
Слава богу это не так.
И все ваши выкладки по поводу разделения и неразделения проектирования они происходят от того же заблуждения, что программирование содержит в себе некий элемент исследовательской работы.
Я не люблю аналогии со строительством, но здесь они уместны. Здание начинается с эскиза, потом выбор материалов, чертежи, рассчеты, а потом уже кладут кирпич. Если используются новые материалы — они предварительно тестируются, если новые технологии — проверяются. После этого строят. В этом случае ваша фраза про проектировщика звучит примерно так «Бывают инженеры которые понарисуют таких чертежей, что потом бригадир с рабочими сами додумывают или строят по-своему», «эффективнее если рабочий сам сочиняет что строить». Это не правда. Да, действительно, можно собраться с друзьями и за выходные построить баньку на даче без особого плана, но небоскребы так не строятся. И не спорьте.
При этом, что банька, что небоскреб, с определенной погрешностью легко оцениваются человеком который руководил/участвовал в проекте постройки баньки или небоскреба.
А элемент «исследовательской» работы это ни что иное как то время, которое вы тратите на преобретение необходимого опыта для выполнения данной работы. Если вы уже обладаете необходимой квалификацией вы не промахнетесь в 10 раз с оценками.