Comments 108
В точку. Сам себя постоянно на этом ловвлю и сам себя ставлю в хреновое положение. И сколько лет — никак не научусь учитывать все оверхеды ))
Программист должен уметь оценивать сроки выполнения задачи, но он не должен делать это вместо менеджера. Если он (программист) это делает, значит менеджер работает плохо.
Менеджер вообще может не очень понимать, какой таск сколько занимает времени. С точки зрения менеджера как раз «добавить какую нибудь финтифлюшку» может быть вообще плевой задачей. Но реально он не знает. Поэтому он в этом примере спрашивает у программиста и делает поправку на ветер
Обратная сторона дела, что из-за отношения менеджера к какой-то задаче, типа «ну вот щас быстренько сделай это плиз» психологически сложнее реально оценить объем работ
Обратная сторона дела, что из-за отношения менеджера к какой-то задаче, типа «ну вот щас быстренько сделай это плиз» психологически сложнее реально оценить объем работ
Но согласитесь «добавить какую нибудь финтифлюшку» — очень хорошая характеристика менеджеру )
Менеджеры не способны к обучению, о котором упоминает автор статьи?
Выдать задание, проконтролировать, отметить время выполнения, учитывать время выполнения при расстановке сроков для следующий заданий.
Слишком сложно для менеджера? Пусть лучше этим программист занимается.
Выдать задание, проконтролировать, отметить время выполнения, учитывать время выполнения при расстановке сроков для следующий заданий.
Слишком сложно для менеджера? Пусть лучше этим программист занимается.
это возможно если задачи одинаковые, но ни к сожалению разные :)
Еще раз — менеджер просто не может оценить объем работ, необходимых для реализации фичи.
Он понятия не имеет, какой рефакторинг нужно или не нужно будет произвести в конкретном проекте, чтобы что-то добавить.
То есть менеджер может научиться исправлять погрешности оценок конкретного программиста, но ему точно не стоит брать цифры просто наобум исходя из прошлого опыта.
Пример ошибочного управления — «в прошлом проекте мы разверстали за день, значит и в этом разверстаем за день — на верстку даю время в один день». А потом получаются видимо что верстаки козлы, не справились, так что ли? Или в прошлый раз видимо поленились, если в этот раз быстрее? А ему кто-то обещал кроме него самого, что верстка будет сделана в те сроки, что он хочет?
Он понятия не имеет, какой рефакторинг нужно или не нужно будет произвести в конкретном проекте, чтобы что-то добавить.
То есть менеджер может научиться исправлять погрешности оценок конкретного программиста, но ему точно не стоит брать цифры просто наобум исходя из прошлого опыта.
Пример ошибочного управления — «в прошлом проекте мы разверстали за день, значит и в этом разверстаем за день — на верстку даю время в один день». А потом получаются видимо что верстаки козлы, не справились, так что ли? Или в прошлый раз видимо поленились, если в этот раз быстрее? А ему кто-то обещал кроме него самого, что верстка будет сделана в те сроки, что он хочет?
Зачем тогда нужен этот менеджер?
В планировании работ он бесполезен.
В планировании работ он бесполезен.
К сожалению, бОльшая часть наших менеджеров таковыми не являются. В лучшем случае они — переводчики.
Для того, чтобы согласовывать и управлять проектом, в котором кучи разных исполнителей и чтобы их оптимально загрузить.
Чтобы балансировать между требованиями клиента, рентабельностью проекта и возможностями команды
Чтобы технари могли работать, а не морочиться организационными проблемами.
Чтобы балансировать между требованиями клиента, рентабельностью проекта и возможностями команды
Чтобы технари могли работать, а не морочиться организационными проблемами.
Если бы все менеджеры читали книги, вроде «Как пасти котов» Рейнвотера или другие по управлению проектами и психологии и хоть что-то из них брали на вооружение, руководствуясь при этом логикой и здравым смыслом…
Вот поэтому я всегда говорил и буду говорить: менеджеры должны выходить из среды профессиональных программистов, а не набераться с кафедры Экономики и Управления местного института.
Менеджер должен учитывать особенности каждого разработчика команды, в том числе касающиеся оценки, и приводить их к общим показателям (суммирующим, средним и т.д.).
Это не отменяет того, чтобы самому для себя развиваться и в качестве грамотного оценщика. Более того, если хочешь из программиста стать архитектором, тебе это необходимо как воздух.
Это не отменяет того, чтобы самому для себя развиваться и в качестве грамотного оценщика. Более того, если хочешь из программиста стать архитектором, тебе это необходимо как воздух.
Абсолютно согласен! Менеджер может советоваться с разработчиком, но не перекладывать на него ответственность за срыв сроков, из-за неправильной оценки.
UFO just landed and posted this here
Верно, но ведь оценка рисков это как раз задача менеджера, правда?
упаси Боже вас использовать экспертов для оценки сроков. Ни когда больше этого ни кому не пишите. Эта ошибка ещё хуже, чем отсутствие опыта при собственной оценке. Потому что отвечать вам (или вашему программисту), а оценивает Василий Иванович, признанный эксперт. Ниже приведу наброски из литературы по оценке трудозатрат программных продуктов ( Software Estimation: Demystifying the Black Art).
Для малых проектов (до 5 человек) малых проектов лучше, чтобы исполнители оценивали трудоёмкость.
Для больших проектов (25+ человек, 6+ месяцев) учитывается состояние проекта. На ранних стадиях лучше использовать нисходящие оценки (алгоритмы и статистика в помощь). На средних стадия лучше комбинировать нисходящие и восходящие оценки. На поздних — восходящие оценки.
Для средних проектов (5-25 человек, 3-12 месяцев) подходят любые методики.
Оценки нужно избегать, если имеется возможность подсчитать точно. Если нет точного ответа, то стоит использовать вспомогательные данные. Считать нужно следующее — инженерные требования, запросы на изменения, веб-страницы, отчёты, диалоговые окна, экраны, таблицы БД и т.д.
Нужно искать осмысленный показатель для оценки (например, количество строк кода — LOT ) на ранней стадии.
Для оценки чаще всего используются строки кода (LOC). Это плохой способ, но остальные ещё хуже. Альтернатива LOC — функциональные пункты. Если стоимость фиксированная, то наибольшее влияние на оценку оказывает размер проекта (количество маркетинговых и инженерных требований, функциональные пункты). Функциональные пункты доступны на завершающих стадия и не подходят в качестве “осмысленного показателя”
На основе собранных данных производится грубый оценочный подсчёт (средний объем работ на дефект, с.о.р на страницу)
Повысить точность можно с помощью оценок в группах, т.к. ошибка индивидуальной оценки — 55%, ошибка после обсуждения в группе — 30%. Delphi метод в помощь (точность на 40% выше).
Самый точный способ — оценочные программы, типа бесплатной Construx Estimate.
Также можно использовать опыт собственных и только аналогичных проектов или различные подходы (Delphi, PERT)
Если уж ни чего нет — то средние показатели по отрасли. Но ни когда не используйте экспертов.
Для малых проектов (до 5 человек) малых проектов лучше, чтобы исполнители оценивали трудоёмкость.
Для больших проектов (25+ человек, 6+ месяцев) учитывается состояние проекта. На ранних стадиях лучше использовать нисходящие оценки (алгоритмы и статистика в помощь). На средних стадия лучше комбинировать нисходящие и восходящие оценки. На поздних — восходящие оценки.
Для средних проектов (5-25 человек, 3-12 месяцев) подходят любые методики.
Оценки нужно избегать, если имеется возможность подсчитать точно. Если нет точного ответа, то стоит использовать вспомогательные данные. Считать нужно следующее — инженерные требования, запросы на изменения, веб-страницы, отчёты, диалоговые окна, экраны, таблицы БД и т.д.
Нужно искать осмысленный показатель для оценки (например, количество строк кода — LOT ) на ранней стадии.
Для оценки чаще всего используются строки кода (LOC). Это плохой способ, но остальные ещё хуже. Альтернатива LOC — функциональные пункты. Если стоимость фиксированная, то наибольшее влияние на оценку оказывает размер проекта (количество маркетинговых и инженерных требований, функциональные пункты). Функциональные пункты доступны на завершающих стадия и не подходят в качестве “осмысленного показателя”
На основе собранных данных производится грубый оценочный подсчёт (средний объем работ на дефект, с.о.р на страницу)
Повысить точность можно с помощью оценок в группах, т.к. ошибка индивидуальной оценки — 55%, ошибка после обсуждения в группе — 30%. Delphi метод в помощь (точность на 40% выше).
Самый точный способ — оценочные программы, типа бесплатной Construx Estimate.
Также можно использовать опыт собственных и только аналогичных проектов или различные подходы (Delphi, PERT)
Если уж ни чего нет — то средние показатели по отрасли. Но ни когда не используйте экспертов.
Все стараются экономить косты на разработку не понимая, что программист-то ужмется, а вот результат, который будет на выходе, будет очень низкого качества. И тот обычно тендер выигрывает, кто заложил времени меньше на разработку, соотв. и дешевле остальных выкатил цену. (я не рассматриваю здесь другие варианты рассмотрения победителя тендера :)
В погоне за баблом — качества никогда не будет…
Очень обидно, что все это понимают, а никто не делает…
В погоне за баблом — качества никогда не будет…
Очень обидно, что все это понимают, а никто не делает…
Заметил, что программисты дают оценку довольно точно… но для идиальных условий. То есть, да, я действительно сделаю эту работу за час, но если буду в хорошем настроении, меня не будут отвлекать, мне не будет хотеться есть, и ещё куча если.
Попросите Ваших программистов оценивать задачу в идиальных часах и получите довольно точную метрику. А уже соотношение идиальный час/реальный будет разное в зависимости от человека и условий. Впрочем, это довольно постоянное значение и вычисляется статистикой.
Ах да, чуть не забыл — бесполезно спрашивать оценку в разгар работы — это ведь случайное число :)
Попросите Ваших программистов оценивать задачу в идиальных часах и получите довольно точную метрику. А уже соотношение идиальный час/реальный будет разное в зависимости от человека и условий. Впрочем, это довольно постоянное значение и вычисляется статистикой.
Ах да, чуть не забыл — бесполезно спрашивать оценку в разгар работы — это ведь случайное число :)
у нас так и работает =))
Слово «идеальный» однокоренное с «идеал», а не с «идиот».
Да, спасибо :)
* когда уже сделают плагин для исправления прямо в тексте, как в тетрадках — с перечёркиванием и написанием сверху? :)
* когда уже сделают плагин для исправления прямо в тексте, как в тетрадках — с перечёркиванием и написанием сверху? :)
На stackovefflow мне нравится как сделано.
Можно ссылку с примером?
На stackoverflow.com можно любой топик брать. Там как сам пост с вопросом так и ответы можно редактировать, причём и свои и чужие. Возможности редактирования растут с репутацией. Свои ответы и комментарии можно редактировать: с низкой репутацией — в течение определённого времени, с высокой — всегда, хоть удалить.
Абсолютно согласен. Но главное на мой взгляд чтобы код, который будет писать программист, не затрагивал код, который написан «нехорошо» или который по всей логике вещей должен был давным давно написан, но к сожалению отсутствует.
В «Software Estimation: Demystifying the Black Art» («Сколько стоит программный проект») считается что экспертные оценки содержат наибольшую погрешность и предлагается опираться на статистку по проектам своей организации, объём проекта и пр. параметры и техники. Если оценку прямо или косвенно можно посчитать (вычислить), лучше именно так и сделать.
«Важно понимать, что опыт программирования и оценческий опыт — это разные вещи» — верно, опыт оценки нарабатывается достаточно долго.
«Каждый программист делает оценку отчасти правильной, но практически всегда забывает о накладных расходах (отладка, тесты т.п.). » — эх, ладно, перевод все таки, из песни слова не выкинеш и т.п.
«Как опытный менеджер проектов, я часто сталкивался с заявленными программистами сроками выполнения задачи, умножал их на Пи и брал следующий по счету порядок. Так 1 день превращался в 3.14 недель. » — наверное у опытного менеджера были неограниченые бюджеты. Превратить 1 день в почти месяц это надо уметь конечно. Точность в табличке конечно получше, но все равно «на глазок». Табличку можно в мусорку выбросить. Если программисту надо несколько лет, чтобы наработать хороший уровень оценки, то какой смысл в простенькой таблице, особенно если ей будут пользоватся менеждеры не вышедшие из программистов. Вред один.
«Каждый программист делает оценку отчасти правильной, но практически всегда забывает о накладных расходах (отладка, тесты т.п.). » — эх, ладно, перевод все таки, из песни слова не выкинеш и т.п.
«Как опытный менеджер проектов, я часто сталкивался с заявленными программистами сроками выполнения задачи, умножал их на Пи и брал следующий по счету порядок. Так 1 день превращался в 3.14 недель. » — наверное у опытного менеджера были неограниченые бюджеты. Превратить 1 день в почти месяц это надо уметь конечно. Точность в табличке конечно получше, но все равно «на глазок». Табличку можно в мусорку выбросить. Если программисту надо несколько лет, чтобы наработать хороший уровень оценки, то какой смысл в простенькой таблице, особенно если ей будут пользоватся менеждеры не вышедшие из программистов. Вред один.
«Так 1 день превращался в 3.14 недель» — Много вы проектов довели до конца?
Походу тут опечатка, имелось ввиду 1 неделя -> 3,14 недель или 1 день -> 3,14 дня. Правило умножать оценку на пи известно давно.
Не опечатка — в тексте явно написано «взять следующий порядок». Правило «прибавить 1 к числу и взять следующую единицу измерения» я слышал давно, и оно работает хорошо… для идеальных условий :) (1 день превращается в 2 недели, а 2 месяца — в 3 года. Основное время уходит на то, чтобы найти в рабочем расписании окошко, позволяющее заниматься именно этой задачей и не отвлекаться).
Автор ошибся, а мне за это карму слили, прикольно :) И как я теперь с этим жить буду? ;) Вы хоть представляете какого это — быть отхабренным?
Для начала, предлагаю сделать опрос, для прочитавших этот пост, сколько менеджеров и сколько программистов =)
Отправил тилиду, повесил распечатку на стену над монитором — может хоть иногда буду за нее взглядом зацепляться…
Ой зря. Имхо, доверять в таких вопросах человеку который умножал на пи и волшебным образом менял дни на недели, и утверждал, что при этом всего-лишь была плохая точность, не стоит. И почему на пи интересно, как разработка ПО связана с площадью круга? Почему не на «e» или на случайное число от 1 до 10, или какая-нибудь другая волшебная, не связанная с реальностью формула, ((фаза луны * номер месяца / номер знака зодиака разработчика дававшего оценку) + число выпавшее на кубике) * оценку данную разработчиком. В хрустальный шар еще можно вглядыватся, чтобы найти коэффициент.
Ну зачем так серьезно? Тимлид у меня очень даже адекватный, доля юмора в формуле так же есть, а напоминание себе, что кроме ощущаемого времени на код есть еще гора и вагонетка времени, которое проходит, но не ощущается — всегда полезно.
Ну разве что юмора ради. Адекватный опытный тимлид, думаю прекрасно понимает что оценка штука сложная, учесть все факторы невозможно, но можно приблизительно прикинуть сколько не учел, какой запас нужно взять. Риски программирования опытный разработчик оценит лучше менеджера (если менеджер сам не опытный разработчик конечно). Поэтому умножение на пи и перевод в недели, ну чисто поржать, а табличка приравнивается к юмористическому плакату, для поднятия настроения. Если так, то я за вас спокоен :)
Кроме того что оценка штука сложная, она еще выматывает конкретно, если нужна высокая точность. И вот представте себе ситуацию, разработчики сидели 3 часа чтобы оценить задачи на месяц, вынесли себе мозг полностью, пытаясь понять что затронут новые фичи, какой риск нужно добавить, где снизить, где увеличить. Приносят результат менеджеру, а он бах, и умножает это на пи (пусть даже в днях, без перевода в недели). Ну и зачем они спрашивается потели? Следующая оценка разработчиков будет уже на глазок, риски заложенные ими вырастут (а чего мучится, менеджер же не заморачивается с точностью). Опять бах, на пи. или по табличке 2 дня в 5. Через месяц эффекстивность команды снизилась в несколько раз, стоиомость проектов увеличилась в разы как и время разработки. Конкурентоспособность компании ниже плинтуса. Зато никаких дедлайнов нет, запас же сотни процентов.
Я не говорю что риски закладвать не нужно, нужно, но спросить на какую магическую цифру стоит умножать стоит у разработчиков. Буквально. Есть у менеждера есть возможность домавить лишний запас, он говорит об этом разработчикам, и вместе решают, стоит или нет, в зависимости от ситуации.
Ну и все это имеет смысл, конечно, только если разработчики уже обладают достаточным опытом оценки. Хотя ситуация когда в команде нет ни одного человека, у которого есть этот опыт, крайне редкая, как минимум тимлид. Вот у него и стоит уточнять, если оценку дает разработчик с малым опытом оценки.
Кроме того что оценка штука сложная, она еще выматывает конкретно, если нужна высокая точность. И вот представте себе ситуацию, разработчики сидели 3 часа чтобы оценить задачи на месяц, вынесли себе мозг полностью, пытаясь понять что затронут новые фичи, какой риск нужно добавить, где снизить, где увеличить. Приносят результат менеджеру, а он бах, и умножает это на пи (пусть даже в днях, без перевода в недели). Ну и зачем они спрашивается потели? Следующая оценка разработчиков будет уже на глазок, риски заложенные ими вырастут (а чего мучится, менеджер же не заморачивается с точностью). Опять бах, на пи. или по табличке 2 дня в 5. Через месяц эффекстивность команды снизилась в несколько раз, стоиомость проектов увеличилась в разы как и время разработки. Конкурентоспособность компании ниже плинтуса. Зато никаких дедлайнов нет, запас же сотни процентов.
Я не говорю что риски закладвать не нужно, нужно, но спросить на какую магическую цифру стоит умножать стоит у разработчиков. Буквально. Есть у менеждера есть возможность домавить лишний запас, он говорит об этом разработчикам, и вместе решают, стоит или нет, в зависимости от ситуации.
Ну и все это имеет смысл, конечно, только если разработчики уже обладают достаточным опытом оценки. Хотя ситуация когда в команде нет ни одного человека, у которого есть этот опыт, крайне редкая, как минимум тимлид. Вот у него и стоит уточнять, если оценку дает разработчик с малым опытом оценки.
Как показывает мой опыт, обычно в конце проекта не хватает одной недели/дня/месяца (в зависимости от размера проекта).
Я где-то видел идею про то, чтобы поставить дедлайн там, где сказали разработчики, а самому втихую пробить заказчику дедлайн на день/неделю/месяц позже. Но как-то раз я случайно обмолвился правдой с разработчиками, отчего те тихо на меня обиделись. Обошлось без драк, всё-таки ребята очень хорошие были, но авторитет немного подпортил таким недоверием к команде и обману, пусть даже и во благо.
Вопрос остаётся открытым — как добавить эти самые недостающие 5%?
Я где-то видел идею про то, чтобы поставить дедлайн там, где сказали разработчики, а самому втихую пробить заказчику дедлайн на день/неделю/месяц позже. Но как-то раз я случайно обмолвился правдой с разработчиками, отчего те тихо на меня обиделись. Обошлось без драк, всё-таки ребята очень хорошие были, но авторитет немного подпортил таким недоверием к команде и обману, пусть даже и во благо.
Вопрос остаётся открытым — как добавить эти самые недостающие 5%?
Вы про мотивационную сторону, т.е. если у вас есть запас и о нем знаю разработчики то они и его съедят (запас расслабляет), а если проставить его втихую, то даже если сорвут сроки то сработает запас? Или о чем?
Рабочего проверенного решения не знаю, но как вариант: обьяснить разработчикам ситуацию, что сорванные сроки очень плохо сказываеются на…, и вместо 1 дедлайна создать 2: первый — дедлайн проекта для команды (компании) и второй — дедлайн заказчика. Разработчики будут знать что запас есть, но он именно запас, на крайние случаи, и срывать дедлайн команды постоянно не есть хорошо. Но при этом не будут надрыватся чтобы успеть к дедлайну (ну возможна же такая ситуция и не по вине разработчиков), а потом узнавать что у них еще был запас в неделю а они до ночи работали чтобы пол дня выкроить. Не будет и обиды что им не доверяют, и втихаря перестраховываются.
Обсуждаем, можно кто пробовал такое. У меня опыта такого нет, максимум что есть: я озвучивал менеджеру 2 оценки иногда, для менеджера и для заказчика, в ситуациях когда срыв сроков очень не желателен. Та что для менеджера была нормальная, та что для заказчика — уже чтобы наверняка успеть, с ничтожной вероятностью срыва сроков. Но это было для небольших задач (несколько дней) и все же немного не то, инициатива от меня как разработчика шла.
Рабочего проверенного решения не знаю, но как вариант: обьяснить разработчикам ситуацию, что сорванные сроки очень плохо сказываеются на…, и вместо 1 дедлайна создать 2: первый — дедлайн проекта для команды (компании) и второй — дедлайн заказчика. Разработчики будут знать что запас есть, но он именно запас, на крайние случаи, и срывать дедлайн команды постоянно не есть хорошо. Но при этом не будут надрыватся чтобы успеть к дедлайну (ну возможна же такая ситуция и не по вине разработчиков), а потом узнавать что у них еще был запас в неделю а они до ночи работали чтобы пол дня выкроить. Не будет и обиды что им не доверяют, и втихаря перестраховываются.
Обсуждаем, можно кто пробовал такое. У меня опыта такого нет, максимум что есть: я озвучивал менеджеру 2 оценки иногда, для менеджера и для заказчика, в ситуациях когда срыв сроков очень не желателен. Та что для менеджера была нормальная, та что для заказчика — уже чтобы наверняка успеть, с ничтожной вероятностью срыва сроков. Но это было для небольших задач (несколько дней) и все же немного не то, инициатива от меня как разработчика шла.
Не так давно я оценивал проект, на который другая организация уже дала оценку в $30,000. Наша оценка, достаточно детализированная, получилась минимум в два раза больше. Естественно, мы проиграли, так как сбрасывать цену и работать за бесплатно не собирались.
Я практически на 100% уверен, что конкуренты затянут проект по строкам (и заказчик в этом уверен, как ни странно), и попадут по деньгам, и будут доделывать за бесплатно.
Но заказчику это выгодней, так как он из них выжмет все что сможет.
А на качество ему плевать… тоже как ни странно…
Я практически на 100% уверен, что конкуренты затянут проект по строкам (и заказчик в этом уверен, как ни странно), и попадут по деньгам, и будут доделывать за бесплатно.
Но заказчику это выгодней, так как он из них выжмет все что сможет.
А на качество ему плевать… тоже как ни странно…
может тот заказчик сам является посредником?
Нет, как раз таки заказчик не посредник, а производитель здоровых таких механизированных шкафов, то есть речь про!!! встроенный!!! софт.
Мда… видимо у него свои методы воздействия. Не уложился в срок — плати издержки, работай за еду бесплатно и всё такое.
Возможно вам повезло, что не связались с ним, не факт что вы уложились бы в сроки, тогда бы прочувствовали все его методы на себе.
Возможно вам повезло, что не связались с ним, не факт что вы уложились бы в сроки, тогда бы прочувствовали все его методы на себе.
Вместо зачеркнутого «за еду» прочел сначала «в аду»
Что в данном контексте схоже :)
Сам порой веду со стороны заказчиков таких горе-разработчиков. Наобещают золотые горы, ценник, раскладку по времени дадут. Говоришь им — ребят, вы не уложитесь, тут половины работ нет, подумайте — в ответ только битие в грудь, что они опытные перцы.
Потом у них жизнь и правда ад, кушать хочется. Но и конкуренты их схожие условия выставляют, так что «не брать заведомых идиотов» не скажешь. Ну а мы, как заказчика, не обязаны знать их техпроцесс — «пацан сказал — пацан должен сделать», иначе-то как?
Что в данном контексте схоже :)
Сам порой веду со стороны заказчиков таких горе-разработчиков. Наобещают золотые горы, ценник, раскладку по времени дадут. Говоришь им — ребят, вы не уложитесь, тут половины работ нет, подумайте — в ответ только битие в грудь, что они опытные перцы.
Потом у них жизнь и правда ад, кушать хочется. Но и конкуренты их схожие условия выставляют, так что «не брать заведомых идиотов» не скажешь. Ну а мы, как заказчика, не обязаны знать их техпроцесс — «пацан сказал — пацан должен сделать», иначе-то как?
Так может эти парни решили таким образом урвать контракт. Потом схитрят в ТЗ, все расплывчатые места трактуют по свойму, баги пойдут как поддержка после продакшена(платная разумеется). По срокам может и затянут, но зато заказчик уже будет на крючке и никуда не дропнется.
>Я практически на 100% уверен, что конкуренты затянут проект по строкам (и заказчик в этом уверен, как ни странно), и попадут по деньгам, и будут доделывать за бесплатно.
Может получится такой расклад, что исполнитель будет обосновывать срыв сроков изменением требований (а они почти всегда есть). И у закачика будет выбор: либо судиться с ними и отдать проект друим, либо доплатить полную стоимость (даже дороже, чем предлагали вы) и быстро доделать проект.
Далеко не каждый будет судиться.
Может получится такой расклад, что исполнитель будет обосновывать срыв сроков изменением требований (а они почти всегда есть). И у закачика будет выбор: либо судиться с ними и отдать проект друим, либо доплатить полную стоимость (даже дороже, чем предлагали вы) и быстро доделать проект.
Далеко не каждый будет судиться.
Встраиваемый софт мало кто может толково писать, может дело тут в компетенциях конкурента?..
Когда меня начальник спрашивает за сколько я сделаю… в редмайн всегда накидывает в 2 раза больше времени.
Как правило я справляюсь быстрее (всегда говорю время с небольшим запасом), но бывают и исключения что где-то что-то не учел…
Как правило я справляюсь быстрее (всегда говорю время с небольшим запасом), но бывают и исключения что где-то что-то не учел…
Извечная проблема, иногда над кнопкой можно дольше просидеть, чем над каким-либо другим более важным модулем.
У меня схема планирования такая, каждой задачи присваиваю сложность от 1 до 7 звезд. И в зависимости времени и усталости выполняю или тяжелые или легкие.
Вообще, сейчас думаю над тем чтобы сделать такую систему. Внести элемент игры в работу. После выполнения подзадач, и выполнения основной например, выход на новый уровень. Своего рода онлайн игра-работа для разработчиков и дизайнеров. Ведь в принцие в жизни как и в игре, чем больше сделал тем больше опыта набрался.
Самое главное что отслеживая и видя результат своей работы, вырабатывается один гормон в мозге, эндорфин, который дает мотивацию на решение других задач.
Можно даже ввести понятие Энергия, если слишком много задач выполнил, система заблокирует интерфейс и даст отдохнуть.
Может и решит озвученную проблему в топике :)
У меня схема планирования такая, каждой задачи присваиваю сложность от 1 до 7 звезд. И в зависимости времени и усталости выполняю или тяжелые или легкие.
Вообще, сейчас думаю над тем чтобы сделать такую систему. Внести элемент игры в работу. После выполнения подзадач, и выполнения основной например, выход на новый уровень. Своего рода онлайн игра-работа для разработчиков и дизайнеров. Ведь в принцие в жизни как и в игре, чем больше сделал тем больше опыта набрался.
Самое главное что отслеживая и видя результат своей работы, вырабатывается один гормон в мозге, эндорфин, который дает мотивацию на решение других задач.
Можно даже ввести понятие Энергия, если слишком много задач выполнил, система заблокирует интерфейс и даст отдохнуть.
Может и решит озвученную проблему в топике :)
Директор про менеджеров и заказчики про подрядчиков могут написать точно такую же статью. Так что программисты могут особо не обижаться…
Сказав несколько раз «Да тут на час работы» и сделав её только за 3 часа вывел себе правило — в ответ на вопрос «Через сколько будет готово?», пришедшее, по первым оценкам, на ум время умножаю на 2. Главное что бы дедлайны позволяли. Пока выручает =)
В общем вывод очевиден – закладывай время с запасом. Сделал раньше – герой. Начались проблемы – есть запас на их решение.
Вывод очевиден. Совсем не очевиден размер этого запаса.
Обычно это плюс 30-50% времени. Этот момент описан многими методами расчета времени, например PERT.
По ссылке там только рассуждения про среднее значение времени и дисперсию. Про их отношение ничего не говорится.
30-50 — довольно ощутимая разница, обычно это разница между успеем или сорвем сроки и это разница получит компания проект (если аутсорс) или нет. Ну и проблемы возникают обычно в нестандартной ситуации, когда 50% мало или когда и 30% много.
Но в принципе верно, 30 — 50% обычный такой диапазон рисков.
А методика, очередной праздник. 1958 год, совершенно другая область и условия, совершенно другие задачи. А давайте ее возьмем и будем использовать для современного IT для оценки рисков! Ведь серьезная контора по ним работала, много красивой математики, и самое главное, не нужно с спецификой работать, забил формулу и старые данные и программка ответ дала. Только программка не знала что решение задачи нужно будет доработать или изменить архитектуру, отрефакторить код, или решение неизвестно и возможно удастся решить его текущими инструментами, а возожно нет, и без как минимум пары часов на разобратся не решить, или другая крайность, решение уже продумано, модульно независимо и риск там 10% в лучшем случае.
Но в принципе верно, 30 — 50% обычный такой диапазон рисков.
А методика, очередной праздник. 1958 год, совершенно другая область и условия, совершенно другие задачи. А давайте ее возьмем и будем использовать для современного IT для оценки рисков! Ведь серьезная контора по ним работала, много красивой математики, и самое главное, не нужно с спецификой работать, забил формулу и старые данные и программка ответ дала. Только программка не знала что решение задачи нужно будет доработать или изменить архитектуру, отрефакторить код, или решение неизвестно и возможно удастся решить его текущими инструментами, а возожно нет, и без как минимум пары часов на разобратся не решить, или другая крайность, решение уже продумано, модульно независимо и риск там 10% в лучшем случае.
Честно говоря, 30-50% для меня звучит, как фантастика. Оно может работать только если вы уже точно знаете, как решать эту задачу, у вас уже есть продуманная архитектура программы, про которую известно (непонятно откуда), что ее для этой задачи достаточно, и все алгоритмы, которые потребуются, давно разработаны и написаны. А если чего-то из этого нет, задача в проекте возникла впервые, и существующая архитектура на нее совсем не была рассчитана? Как тогда считать?
Ознакомиться с лучшими практиками конкурентов в данной области, сформулировать требования, при необходимости – обновить команду и – в путь.
Не думаю, что конкуренты будут очень уж рады открыть свои разработки (даже если они у них есть). А если и удастся ознакомиться, то окажется, что там все совсем с другими исходными данными, допусками и требованиями к железу, чем то, к чему стремимся мы… Конечно, время будет потеряно не совсем зря, но почти.
Ну мне как разработчику в большинстве случаев удавалось дать точность 30 (если постаратся) и 50 (грубая оценка). Это если считать с момента, когда я набрал достаточно опыта в оценке. До этого конечно были косяки в оценке, и много, благо более опытные товарищи выручали.
А если совсем уж непонятно, что и как использовать, как решать задачу, ответил вам же чуть ниже
Эх, все бы с радостью ставили риски в сотни процентов всегда, но вот бизнес с этим не согласен. Хотя вот судя по статье и комментариям, кому-то удается ставить риски в тысячи процентов (я про пи и временной интервал следующего порядка) и при этом не разорится. Где это эльдорадо находится, мне интересно.
А если совсем уж непонятно, что и как использовать, как решать задачу, ответил вам же чуть ниже
Эх, все бы с радостью ставили риски в сотни процентов всегда, но вот бизнес с этим не согласен. Хотя вот судя по статье и комментариям, кому-то удается ставить риски в тысячи процентов (я про пи и временной интервал следующего порядка) и при этом не разорится. Где это эльдорадо находится, мне интересно.
А как предлагается оценивать время на задачу, у которой еще неизвестен алгоритм решения? На нее может потребоваться и два дня (если повезет, и догадаешься, с какой стороны подойти) и два года…
В таких случаях (по моему опыту) задача разбивается на этапы, аналитика, разработка этого алгоритма (не обязательно до конца) и сам кодинг. Можно и меньше элеметнов. Суть в том что можно создать задачу целью которой будет устранить эту неопределенность, свести до разумных пределов. И эта задача должна быть относительно небольшой по времени, чтобы если после нее станет ясно что исходная задача слишком большая и от нее стоит отказатся, было не так жалко. Ну и разбежки в 2 дня — 2 года я не встречал, а вот в 2 дня — 2 месяца видел.
Ну или второй вариант, делаем первую упрощенную версию, а потом отдельными задачами ее развиваем. Все от ситуации зависит.
Ну или второй вариант, делаем первую упрощенную версию, а потом отдельными задачами ее развиваем. Все от ситуации зависит.
Была у меня такая задача. Есть два множества точек в пространстве (известных не слишком точно), найти совмещение, при котором побольше пар точек совместятся друг с другом поточнее. Несколько раз за нее брался, за 2-3 дня сделать ничего не мог, откладывал. Так она и болталась на подкорке. Потом как-то решил попробовать очередной подход, 4 часа — и все написано. Работает при 50% перекрытии почти стабильно; как можно улучшить, уже знаю. Но года 2 на размышления ушло, если не больше. Фактически — на «аналитику».
ну вы же не потратили 2 человеко-года (а значит и сумму денег за них) на эту аналитику. Да если задача совсем не срочная и не так уж и нужна счас и в принципе, и ее оценка тоже, то можно ее отложить до случая, может ее удастся сделать между делом, и оценить по факту, ну или решение будет найдено и можно будет прикинуть оценку. Были и такие случаи.
Я больше говорил о задачах типа «скажите сколько это займет времени и как можно скорее, нам нужно это знать чтобы решить вообще она нужна или обойдемся, а если нужна то спланировать куда ее нужно воткнуть, чтобы график других задач не поломать, ну или к конкурентам уйти если вы слишком дороги :)», в большинстве случаев оценка делается именно поэтому. И на это уже можно выделить пару дней времени и денег.
Я больше говорил о задачах типа «скажите сколько это займет времени и как можно скорее, нам нужно это знать чтобы решить вообще она нужна или обойдемся, а если нужна то спланировать куда ее нужно воткнуть, чтобы график других задач не поломать, ну или к конкурентам уйти если вы слишком дороги :)», в большинстве случаев оценка делается именно поэтому. И на это уже можно выделить пару дней времени и денег.
Не ново, изучайте законы Мерфи.
Правило Вестгеймера.
=====================
Чтобы определить, сколько времени потребует работа,
возьмите время, которое по-вашему на нее необходимо, ум-
ножьте на 2 и замените единицы измерения на единицы более
высокого порядка. Так, мы выделяем два дня на одночасовую
работу.
Правило Вестгеймера.
=====================
Чтобы определить, сколько времени потребует работа,
возьмите время, которое по-вашему на нее необходимо, ум-
ножьте на 2 и замените единицы измерения на единицы более
высокого порядка. Так, мы выделяем два дня на одночасовую
работу.
В дне 8(6) часов, в неделе (рабочей) 5 дней, в месяце 4 недели, в году 12 месяцев. Какие порядки, где логика?
И если разработчик решил что работа займет месяц, вы всерьез поставите срок оценки 2 года?
Класно, т.е. ваши разработчики час (ну 2-3 c рисками) работают а потом полтора дня отдыхают? А деньги откуда, или зарплаты им так же рассчитываются?
для сроков в 5 минут замечаний нет, но тут проще другое правило: оценка (предварительная) не может быть меньше часа (в редких случаях 0.5 часа). Оценка по факту, ну это уже другой разговор.
И если разработчик решил что работа займет месяц, вы всерьез поставите срок оценки 2 года?
Класно, т.е. ваши разработчики час (ну 2-3 c рисками) работают а потом полтора дня отдыхают? А деньги откуда, или зарплаты им так же рассчитываются?
для сроков в 5 минут замечаний нет, но тут проще другое правило: оценка (предварительная) не может быть меньше часа (в редких случаях 0.5 часа). Оценка по факту, ну это уже другой разговор.
Мой друг, вы правда РП? Почему так остро реагируете? Учитесь читать между строк и мир будет вам улыбаться.
Вся беда при оценки в том, что разработчики неисправимые оптимисты.
И не все в мире чернобелое, бывают задачи на два часа, которые делаются два часа… Подумайте об этом. И дружите с разработчиками, вы работаете благодаря им.
P.S.
А вы уверены, что они вас не обманывают?
Вся беда при оценки в том, что разработчики неисправимые оптимисты.
И не все в мире чернобелое, бывают задачи на два часа, которые делаются два часа… Подумайте об этом. И дружите с разработчиками, вы работаете благодаря им.
P.S.
А вы уверены, что они вас не обманывают?
UFO just landed and posted this here
для таких случаев придумали правило «Пи». Если вам кажется, что работу выполните за 2 часа, то можете смело умножить это время на число Пи — это и будет реальное время выполнения работы.
UFO just landed and posted this here
Еще статья на эту тему trurl123.blogspot.com/2012/09/blog-post.html
Scrum вам в помощь
А расскажите-ка поподробнее — желательно, о личном опыте применения. Дайте ссылку на литературу, которую стоит почитать по этой теме.
Для начала можно почитать вики. У команды есть фиксированный спринт (итерация), например у нас это две недели. Есть бэклог, в которых лежат юзер стори (грубо говоря новые фичи или изменения существующих, далее ЮС). Каждой ЮС до начала нового спринта проставлено определенное количество стори поинтов (предварительный показатель объема или сложности выполнения данной ЮС), таким образом аналитик всегда знает, какой объем новых фич мы выполним за будущие 2 недели (по окончании каждого спринта — релиз). Есть такое понятие как фокус-фактор, по сути это показатель эффективности работы команды, варьируется он в пределах 0.3-0.6, например у нас он 0.4. количество идеальных часов на спринт рассчитывается как реальное время (количество программистов*количество дней*количество часов минус заранее известные отгулы, отпуска и пр.) умноженное на фокус-фактор. Каждому таску (ЮС может состоять из более чем одного таска) выставляется оценка (от программистов) в идеальных часах (я сделаю это за столько, аналог первого столбца Оценка в данном посте), таким образом на спринт набирается то количество ЮС, сумма времени тасков которых не превышает идеальное количество часов спринта. В итоге фоку-фактор заранее учитывает все непредвиденные обстоятельства в архитектуре, баги, какие-либо еще косяки, время на попить чай, таким образом к дедлайну (концу спринта) есть стабильная версия с заранее запланированными новыми фичами, исправленными багами и доработками, которые были осуществлены в процессе спринта (все это фокус-фактор). Бывает и такое, что по каким-либо причинам в конце спринта нет стабильной версии и версия не релизится, спринт заваливается, но такое бывает редко, у нас такое случалось 2 раза за полгода. Все описанное выше далеко не краткое изложение скрама, а всего лишь описание возможного решения или предвидения проблемы, описанной в посте
Спасибо за объяснение. Однако, всё же прошу посоветовать какую-нибудь хорошую книгу или статью по Scrum, т.к. информация в Википедии довольно скудна, некоторые термины не расшифрованы, а некоторые другие, как я подозреваю, просто некорректно переведены (работа надмозга). В результате складывается довольно размытое представление об этой методике разработки.
<оффтоп>
Спеллчекер Firefox подчеркнул слово «Википедии», в качестве исправления предложив слово «Педики». Вот оно что, а я думал, там только детское порно :D
</оффтоп>
<оффтоп>
Спеллчекер Firefox подчеркнул слово «Википедии», в качестве исправления предложив слово «Педики». Вот оно что, а я думал, там только детское порно :D
</оффтоп>
Знаете я сколько ни пытался, умножать на два, на три, на порядок — все равно все срывалось. Пока не понял одну простую вещь — реально задача решаться начинает только под конец означенного срока, каким бы он ни был. До этого команда может раскачиваться, рефакториться (времени то дофига еще) рюшечки всякие впиливать по просьбам тестеров и юзабильщиков, отодвигая корневой функционал, как наиболее сложный, напоследок. И в результате, за неделю до дедлайна выясняется что вместо решения мы имеем кое-как работающую демку и еще больше планов на рефакторинг.
У меня наоборот бывают пролеты — оценил доработку в 2 дня, сделал за 15 минут. Но, как правило, это потому что забыл уже как оно там устроено. А оказывается, что устроено все удачно. Ну классика — оценил в 2 недели, на деле вышло 4 месяца, конечно тоже бывает, ну за первых две недели задачка успевает подрасти просто :-).
Я в программировании уже более 15 лет, но так и не нашел метода, дающего гарантированные оценки.
Единственная, обнаруженная мною закономерность такая:
Нельзя давать оценку за время меньшее 1/6 времени на всю оцениваемую задачу!
Т.е. если я размышлял меньше 10 минут — давать оценку более чем на час очень рискованно, тем более рискованно, как писали выше, поразмышляв всего три часа давать оценку на 30 дней и т.д.
Таким образом для того, чтобы оценить задачу например в 6 дней, думать над ней мне надо не менее 1 дня — иначе моя оценка будет очень приблизительной.
Единственная, обнаруженная мною закономерность такая:
Нельзя давать оценку за время меньшее 1/6 времени на всю оцениваемую задачу!
Т.е. если я размышлял меньше 10 минут — давать оценку более чем на час очень рискованно, тем более рискованно, как писали выше, поразмышляв всего три часа давать оценку на 30 дней и т.д.
Таким образом для того, чтобы оценить задачу например в 6 дней, думать над ней мне надо не менее 1 дня — иначе моя оценка будет очень приблизительной.
Интересный метод, надо попробовать.
Это не метод, это скорее ограничение, предотвращающее поспешные оценки. Меня всегда «умиляет», когда разработчик подумав 15 минут, говорит что ему потребуется неделя на реализацию. Ну вот как он мог за эти 15 мин прикинуть чем он будет заниматься всю неделю ?!
Это также приблизительный ориентир, т.е. если например на сбор информации и решение задачи «на бумаге» мне понадобилось пару часов, то и реализовать я все это в коде смогу никак не быстрее чем за 12 часов.
Это также приблизительный ориентир, т.е. если например на сбор информации и решение задачи «на бумаге» мне понадобилось пару часов, то и реализовать я все это в коде смогу никак не быстрее чем за 12 часов.
Это на «фичу» или задачу в целом?
А у меня другое наблюдение: Если задача в первой оценке тянет больше чем на день, надо расписать её в подзадачах длительностью не более человеко-дня. Иначе качество оценки стремится к нулю.
Именно этим и я занимаюсь целый день, когда планирую работу на несколько дней.
Любопытно.
— Сколько времени будет писаться пояснительная записка?
— Я должен подумать не меньше двух с половиной часов чтобы ответить на этот вопрос!
— Сколько времени будет писаться пояснительная записка?
— Я должен подумать не меньше двух с половиной часов чтобы ответить на этот вопрос!
Покажу руководителю студии. Ему точно пригодится.
Как руководитель производства веб индустрии согласен на все 100%
Как руководитель производства веб индустрии согласен на все 100%
Добавил статью в закладки, буду давать ссылку заказчику перед началом работ.
Проблема в том, что не только в программировании неправильно планируют сроки.
А причина тому — слишком оптимистичный взгляд на собственную деятельность. Больше причин нет.
Статья выше — частный случай этой закономерности.
А причина тому — слишком оптимистичный взгляд на собственную деятельность. Больше причин нет.
Статья выше — частный случай этой закономерности.
Sign up to leave a comment.
Реальная оценка или почему наступают дедлайны?