Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
После прочтения названия топика сразу родился ответ — «Планировать проекты в 2-3 длиннее» ))
В большинстве случаем заказчики такими сроками будут неудовлетворенны. Но самое главное будете ли вы удовлетворены таким длинными сроками? Не наскучит ли вам проект через полгода работы? Выпустите ли вы его качественно после потери мотивации?
Ну с другой стороны, переоценка скорости разработки — одна из самых частых ошибок. Както мне рассказывали, что какя-то из версий Майкрософт-ворд разрабатывалась 3 года вместо 1.5 только из-за того, что план был построен на 1 год.
Проект не может сделаться быстрее чем он должен делаться, 9 женщин не родят ребенка за месяц.
Проблема в другом — сейчас и так все умножают цифры, полученные от девелопера, на 2 или 3. Но это все-равно не помогает.
Я считаю вообще утопичным строить длинные планы. Вся история девелопмента говорит о том, что сроки чаще срываются. Не говорит ли это о том, что многие вещи вообще нереально грамотно спланировать по времени?
Вот тут очень хороший топик-притча habrahabr.ru/blogs/pm/137519/
Так что, я бы ваш вопрос перефразировал в 2 других:
1. Как сделать так, чтобы проект разрабатывался максимально эффективно
2. Как делать реалистичную оценку
«Ай-ай-ай! Проект делается в 2 раза дольше запланированного» — это и есть та самая эпичная ощибка менеджера. Проекту как-бы наплевать на то что вы о нем думаете ))
Проект не может сделаться быстрее чем он должен делаться, 9 женщин не родят ребенка за месяц.
Проблема в другом — сейчас и так все умножают цифры, полученные от девелопера, на 2 или 3. Но это все-равно не помогает.
Я считаю вообще утопичным строить длинные планы. Вся история девелопмента говорит о том, что сроки чаще срываются. Не говорит ли это о том, что многие вещи вообще нереально грамотно спланировать по времени?
Вот тут очень хороший топик-притча habrahabr.ru/blogs/pm/137519/
Так что, я бы ваш вопрос перефразировал в 2 других:
1. Как сделать так, чтобы проект разрабатывался максимально эффективно
2. Как делать реалистичную оценку
«Ай-ай-ай! Проект делается в 2 раза дольше запланированного» — это и есть та самая эпичная ощибка менеджера. Проекту как-бы наплевать на то что вы о нем думаете ))
Пока будут попадаться заказчики, которые не понимая реально что им нужно, не понимая отдельных аспектов в разработке программного продукта, требуют самых коротких сроков — придется делать оценки, которые будут далеки от реалистичных.
Но и в этой ситуации грамотный РМ может хорошо помочь, если он поймет, а главное объяснит, что же реально нужно заказчику на самом деле и правильно расставит приоритеты по разработке. Уже можно говорить о примерных сроках, но все равно в большинстве случаев они будут больше запланированных.
Но и в этой ситуации грамотный РМ может хорошо помочь, если он поймет, а главное объяснит, что же реально нужно заказчику на самом деле и правильно расставит приоритеты по разработке. Уже можно говорить о примерных сроках, но все равно в большинстве случаев они будут больше запланированных.
Т.е. вы утверждаете, что оценку проекта нужно делать исходя из пожеланий заказчика? ))
Даже если программист квалифицированный, задача поставлена ясно и понятно и не меняется — грамотно оценить ее можно только если она, скажем так, стандартна и тривиальна. Т.е. не содержит особого элемента новизны или исследований.
Оценка проектов, включающих исследования — самое неблагодарное занятие. Это вам любой менеджер скажет.
Но современный мир таков, что одинаковые и рутинные проекты уже никто не делает. Если задача уже решена — значит ее решение можно купить.
Вывод — большинство проектов плохо предсказуемы и все.
Если программист говорит «день» — это значит, что «может и два». Но плюс-минус день это не страшно да? Но если он говорит неделя/месяц/квартал/год — это тоже может значить «а может и 2».
Вывод — планировать больше чем на месяц почти бесполезно. Люди, описавшие agile, не зря там месяц в основном используют.
Даже если программист квалифицированный, задача поставлена ясно и понятно и не меняется — грамотно оценить ее можно только если она, скажем так, стандартна и тривиальна. Т.е. не содержит особого элемента новизны или исследований.
Оценка проектов, включающих исследования — самое неблагодарное занятие. Это вам любой менеджер скажет.
Но современный мир таков, что одинаковые и рутинные проекты уже никто не делает. Если задача уже решена — значит ее решение можно купить.
Вывод — большинство проектов плохо предсказуемы и все.
Если программист говорит «день» — это значит, что «может и два». Но плюс-минус день это не страшно да? Но если он говорит неделя/месяц/квартал/год — это тоже может значить «а может и 2».
Вывод — планировать больше чем на месяц почти бесполезно. Люди, описавшие agile, не зря там месяц в основном используют.
Я утверждаю, что к оценке проекта нужно подходить дифференцированно, основываясь:
на собственном опыте и прошлых проектах.
Нет, вы только что сказали:
Пока будут попадаться заказчики, которые не понимая реально что им нужно, не понимая отдельных аспектов в разработке программного продукта, требуют самых коротких сроков — придется делать оценки, которые будут далеки от реалистичных.
Т.е. наоборот — наплевать, что опыт, оценки и чутье подсказывает, если заказчик требует «быстро», надо пообещать ему «быстро»
Пока будут попадаться заказчики, которые не понимая реально что им нужно, не понимая отдельных аспектов в разработке программного продукта, требуют самых коротких сроков — придется делать оценки, которые будут далеки от реалистичных.
Т.е. наоборот — наплевать, что опыт, оценки и чутье подсказывает, если заказчик требует «быстро», надо пообещать ему «быстро»
И где противоречие? :) Нет не наплевать — опыт бывает разный. Если есть опыт, когда заказчик хочет короткий срок — оценивайте коротко, но точно знайте про себя что этот срок будет «просран» (по мне так лучше отказывать от таких проектов).
Мы говорим о грамотной оценке сложности проектов или о том как грамотно лизать задницу заказчику? ))
Сложность проекта — величина математическая, для нее не существует понятия заказчика. Только постановка задачи, ресурсы и риски.
Срок, который вы пишете в договоре, это не оценка проекта, это условия договора.
Давайте не путать тему топика ))
Сложность проекта — величина математическая, для нее не существует понятия заказчика. Только постановка задачи, ресурсы и риски.
Срок, который вы пишете в договоре, это не оценка проекта, это условия договора.
Давайте не путать тему топика ))
Чуть ниже Вы пишете, что «лучше отказываться от таких проектов».
Так что, имхо, надо всегда делать максимально реальные оценки. И если заказчика они не устроят — то проекта не будет. И никто никому не будет грызть мозг. Это стопудово лучше, чем ввязываться в проект заведомо провальный.
Так что, имхо, надо всегда делать максимально реальные оценки. И если заказчика они не устроят — то проекта не будет. И никто никому не будет грызть мозг. Это стопудово лучше, чем ввязываться в проект заведомо провальный.
Хороший троллинг, но плохой совет: вы будете проигрывать на рынке по срокам и стоимости.
Всегда ваш, кэп :)
Всегда ваш, кэп :)
Ну не надо понимать все так буквально, Кэп )) Выше я объяснил свою мысль более подробно.
Но… оценив слишком оптимистично мы будет проигрывать в репутации, т.к. сроки все равно будут сорваны. Тут главное еще правильно выбрать для себя проект, а не кидаться на все за что хорошо платят.
Хотя у нас в России репутация играет меньшую роль, чем связи и откаты.
Самое плохое, что оценив слишком оптимистично, мы тем самым удлиняем проект.
Ибо начинаются нервотрепки, трах мозга, пренебрежение качеством, разработка ненужного функционала и т.д.
Ибо начинаются нервотрепки, трах мозга, пренебрежение качеством, разработка ненужного функционала и т.д.
У меня после прочтения вспомнился другой совет — слушайте заказчика о том, что нужно сделать, а сами пытайтесь понять, чего он хочет достичь. Ведь заказчику не нужно выпилить из дерева ложку, ему хочется скушать плова.
Смысл совета в том, чтобы называя цену учитывать не стоимость выполнения конкретных задач, которых может быть недостаточно, а стоимость достижения цели. Если же цели размыты и точную цену назвать не реально (как вариант — проект слишком уникальный и никто такого еще не делал) — называем конкретный план достижения цели, иногда даже вовсе без цены.
(собственно, это краткий и вольный пересказ нескольких принципов agile)
Смысл совета в том, чтобы называя цену учитывать не стоимость выполнения конкретных задач, которых может быть недостаточно, а стоимость достижения цели. Если же цели размыты и точную цену назвать не реально (как вариант — проект слишком уникальный и никто такого еще не делал) — называем конкретный план достижения цели, иногда даже вовсе без цены.
(собственно, это краткий и вольный пересказ нескольких принципов agile)
Просто программисты — очень душевные люди. По вечерам они садятся в кресло, наливают себе чаю или кофе и смотрят, как горят сроки сдачи проектов. (с) чей-то там.
Чтоб не горели сроки, надо работать, работать и работать.
Этого не всегда достаточно. Более того, в том что проекты «просрачиваются» нет вины конкретных исполнителей, они как раз работают, работают и работают :)
эх, если бы все было так просто… к сожалению за исключением случаев в которых явно виноваты неквалифицированные исполнители, срыв сроков часто является причиной неадекватного менеджмента и политических игрищ высшего руководства. А вкалывать, вкалывать и вкалывать хоть и работает на начальном этапе, но в общем — плохой совет. Программист с убитым зрением, больной спиной, раздражительный из-за недосыпа и неурядиц в личной жизни никому ненужен.
основной причиной несоблюдения сроков является, на мой вгляд, «синдром студента», поэтому программист никогда не должен знать сроков, он просто должен работать.
Это называется менеджмент над шампиньонами — meta-delo.blogspot.com/2008/09/management-nad-shampinonami.html. Проблема в том, что команда будет не мотивирована на успех и не будет атмосферы доверия.
Чтобы преодолеть синдром студента, достаточно использовать итеративные процессы.
Чтобы преодолеть синдром студента, достаточно использовать итеративные процессы.
ссылка не работает, а почитать хочу, поправьте плз
Точечку в конца убрать надо :) meta-delo.blogspot.com/2008/09/management-nad-shampinonami.html
Кто-нибудь уже додумался до того, что программирование — это не строительные работы, а НИОКР, и в принципе не могут планироваться?
Конечно.
Мало того, agile построена вокруг подобного сюжета.
Говорят, даже автор waterfall до этого додумался, но его не дослушали и оборвали на полуслове :)
Мало того, agile построена вокруг подобного сюжета.
Говорят, даже автор waterfall до этого додумался, но его не дослушали и оборвали на полуслове :)
Имхо, это скорее обычная инженерная деятельность, чем НИОКР. Особенно это касается разработки бизнес-приложений и веб-сайтов.
«функционал, который не будет использоваться — удалить из продукта»
интересно, а как это функционал попал в продукт? наверное не было проведено анализа потребностей бизнеса клиента? или он был проведен один раз в самом начале проекта, а за время пока проект был в разработке эти потребности поменялись (это попытка докопаться до корня проблемы которую вы озвучили, а не просто решать последствия..)
интересно, а как это функционал попал в продукт? наверное не было проведено анализа потребностей бизнеса клиента? или он был проведен один раз в самом начале проекта, а за время пока проект был в разработке эти потребности поменялись (это попытка докопаться до корня проблемы которую вы озвучили, а не просто решать последствия..)
Господи, ну какая глупость в первом же слайдкасте.
«Давайте использовать только итеративный подход». Для Каких-то проектов больше подойдет итеративная модель, но для каких-то — скорее поэтапная.
Представьте, что проект внешний и ожидается только первая и последняя версия продукта. На кой ляд здесь эджайл?
«Давайте использовать только итеративный подход». Для Каких-то проектов больше подойдет итеративная модель, но для каких-то — скорее поэтапная.
Представьте, что проект внешний и ожидается только первая и последняя версия продукта. На кой ляд здесь эджайл?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делать, чтобы проекты не занимали в 2-3 раза дольше, чем планируется? Часть 1