Смешно. Науки о точных эстимэйтах нет. Есть более-менее формальные методики вроде PERT, но я не знаю ни одной минской компании, где бы такое использовалось.
О систематическом несовпадении можно говорить, когда есть систематически точные оценки. Для временных промежутков вроде день-полтора-два (о таких вроде бы здесь идет речь) такие оценки возможны, если задачи типовые. Выполнялись не раз, риски изучены и действительно есть основание строго спросить за вылет за пределы
( ... )
Это работает в любых масштабах и на любой функциональности.
Я даже не очень понимаю, при чем тут масштабируемость. Что не всем надо, это понятно. Но чем дальше, тем больше это будет внедряться повсеместно, потому как только у нас тут еще витают остатки мифа о том, что программирование это такая особая сфера.. а весь мир за исключением пары процентов почти чистой науки давно уже все оценивает весьма точно.
> Это работает в любых масштабах и на любой функциональности.
Пиздец, простите мой французский. Пацаны то и не знают, наверно проспали революцию. Опишите пожалуйста вкратце методику оценки трудоемкости проекта по созданию системы для автоматизации какого-нибудь кросс-функционального бизнес-процесса. Предполагается интеграция с двумя легаси системами и участие субподрядчика для реализации части функциональности.
> Но чем дальше, тем больше это будет внедряться повсеместно, потому как только у нас тут еще витают остатки мифа о том, что программирование это такая особая сфера.. а весь мир за исключением пары процентов почти чистой науки давно уже все оценивает весьма точно.
Что - это? Что будет внедряться? Какой мир, что оценивает и главное - как?
А, ну да. Вы проспали. Проспали внедрение Agile-методик. Оценить трудоемкость создание системы с точностью до часа вы не сможете. Но оценить загрузку программиста на неделю -- элементарно.
Внедряться будут точные методики оценок. Просто по той причине, что 2% всего IT это наука и изобретение чего-то нового. А 98% это рутина и конвейер. Где все уже придумано до нас. И попасть в те самые два процента -- это очень круто. Но тогда бы и мыслей не возникало о том, как убить большую часть рабочего дня на посторонние дела.
Попроси собеседника представиться (должность назвать). А также указать, откуда он берёт суждения о планировании, проектировании и контроле сроков. Дело в том, что ты судишь со стороны разработчика и того-кто-читал-про-agile-методике. А я тебе рассказывал о моём реальном опыте работы на позиции project manager'а. И, насколько я знаю, insolite вполне так себе эксперт в обсуждаемом вами обоими вопросе. Что касается меня, я всего лишь ёрничал над тем, что кое-кто из начальства акцентирует своё внимание только на времени прихода на работу и ухода домой. Почти не обращая внимания, что 5/8 рабочих часов люди занимаются самосовершенствованием.
Ну я сужу со стороны разработчика, но изнутри с работающей системы. Причем речь не о домашних страницах кота бублика а о высоконагруженных медиа-проектах для одного из мировых лидеров. И более того, тот же scrum это не прихоть белорусской стороны, а реально работающая методология со стороны заказчика.
Просто потому что время огромных проектов, которые планируются на годы вперед и согласно этому плану потом и реализуются, давно ушли. Сейчас в любой крупный проект изначально закладывается, что к моменту его выхода в свет существующие технологии и решения будут устаревшими и в ходе проекта неизбежны изменения.
Но при этом на каждом отдельном этапе мы контролируем процесс с достаточной степенью погрешности.
Я тебе раскрою страшную тайну. Есть "базовая" оценка. Т.е. время за которое среднестатистический (!) работник выполнит ту или иную задачу. Допустим, менеджер (эксперт) грамотный и оценка реальная. Потому что если она изначально нереальная, то это прямой путь к серьёзному разговору. Дальше вводится поправочный коэффициент - это и есть страшная тайна. Если проект "горит", то к-т равен 1. Её и доводят до работника. Но это уже повод для серьёзного разговора с менеджером, потому что в секретных талмудах менеджеров чётко сказано, что загрузка работника не должна превышать 80%. Если проект нормальный, а программист уровня "джуниор", то к-т доходит до 8. И уже эту цифру менеджер закладывает в свои отчёты, но до испонителя доносит сроки с к-том раза в 2 меньше. Т.е. если на задачу надо потратить 2 часа, то менеджер закладывает 16, а исполнителю говорит, что надо сделать за 8. Если исполнитель сделает за 12, то все будут довольны. А разговор будет серьёзным только если исполнитель превысит 16 часов. Вывод: не надо наглеть, а работа должна быть
Reply
Что сложного присуммировать время к каждой задаче? То, что реально заняло 3 часа будет отрапортовано как 8.
Reply
Reply
Reply
Reply
Reply
И все работает. :)
Reply
Наверняка, или copy-paste, или тривиальщина.
Reply
Reply
Это не масштабируется ни разу. Я понимаю, не всем надо.
Reply
Я даже не очень понимаю, при чем тут масштабируемость. Что не всем надо, это понятно.
Но чем дальше, тем больше это будет внедряться повсеместно, потому как только у нас тут еще витают остатки мифа о том, что программирование это такая особая сфера.. а весь мир за исключением пары процентов почти чистой науки давно уже все оценивает весьма точно.
Reply
Пиздец, простите мой французский. Пацаны то и не знают, наверно проспали революцию. Опишите пожалуйста вкратце методику оценки трудоемкости проекта по созданию системы для автоматизации какого-нибудь кросс-функционального бизнес-процесса. Предполагается интеграция с двумя легаси системами и участие субподрядчика для реализации части функциональности.
> Но чем дальше, тем больше это будет внедряться повсеместно, потому как только у нас тут еще витают остатки мифа о том, что программирование это такая особая сфера.. а весь мир за исключением пары процентов почти чистой науки давно уже все оценивает весьма точно.
Что - это? Что будет внедряться? Какой мир, что оценивает и главное - как?
Reply
Оценить трудоемкость создание системы с точностью до часа вы не сможете. Но оценить загрузку программиста на неделю -- элементарно.
Внедряться будут точные методики оценок. Просто по той причине, что 2% всего IT это наука и изобретение чего-то нового. А 98% это рутина и конвейер. Где все уже придумано до нас. И попасть в те самые два процента -- это очень круто. Но тогда бы и мыслей не возникало о том, как убить большую часть рабочего дня на посторонние дела.
Reply
Дело в том, что ты судишь со стороны разработчика и того-кто-читал-про-agile-методике. А я тебе рассказывал о моём реальном опыте работы на позиции project manager'а. И, насколько я знаю, insolite вполне так себе эксперт в обсуждаемом вами обоими вопросе.
Что касается меня, я всего лишь ёрничал над тем, что кое-кто из начальства акцентирует своё внимание только на времени прихода на работу и ухода домой. Почти не обращая внимания, что 5/8 рабочих часов люди занимаются самосовершенствованием.
Reply
И более того, тот же scrum это не прихоть белорусской стороны, а реально работающая методология со стороны заказчика.
Просто потому что время огромных проектов, которые планируются на годы вперед и согласно этому плану потом и реализуются, давно ушли. Сейчас в любой крупный проект изначально закладывается, что к моменту его выхода в свет существующие технологии и решения будут устаревшими и в ходе проекта неизбежны изменения.
Но при этом на каждом отдельном этапе мы контролируем процесс с достаточной степенью погрешности.
Reply
Допустим, менеджер (эксперт) грамотный и оценка реальная. Потому что если она изначально нереальная, то это прямой путь к серьёзному разговору.
Дальше вводится поправочный коэффициент - это и есть страшная тайна. Если проект "горит", то к-т равен 1. Её и доводят до работника. Но это уже повод для серьёзного разговора с менеджером, потому что в секретных талмудах менеджеров чётко сказано, что загрузка работника не должна превышать 80%.
Если проект нормальный, а программист уровня "джуниор", то к-т доходит до 8. И уже эту цифру менеджер закладывает в свои отчёты, но до испонителя доносит сроки с к-том раза в 2 меньше. Т.е. если на задачу надо потратить 2 часа, то менеджер закладывает 16, а исполнителю говорит, что надо сделать за 8. Если исполнитель сделает за 12, то все будут довольны.
А разговор будет серьёзным только если исполнитель превысит 16 часов.
Вывод: не надо наглеть, а работа должна быть
Reply
Leave a comment