Форум Сообщества Аналитиков
Дисциплины => Управление Проектом => Тема начата: Careeristka от 21 Сентября 2011, 17:35:34
-
Уважаемые коллеги, кто как справляется с проблемой просрочки задач?
Например, если один из членов команды постоянно не укладывается в заявленный срок.
Не больничный, не отпуска, отговорки вроде "закопался в решении", "думал сделать так, чтобы при доработке не надо было все переделывать", работаю над очень крутым решением, поэтому долго".
Заранее спасибо
-
Справляемся по-разному, в зависимости от ситуации:
Пытаемся разобраться в диалоге, что именно происходило и что стало причиной ошибки в оценке
Планируем совместно
Нарезаем задачи на более мелкие (не больше 4 часов каждая)
Вместе выполняем очередную задачу
Ставим наставника
Берём поправочный коэффициент 1,5-Pi на все его оценки
Отправляем человека отдохнуть
Делаем отчёты об исполнении задач публичными
Вводим ежедневный скрам
Наказываем снижением премии
Жалуемся его линейному руководителю
Увольняем
-
Согласен с Денисом.
Важная часть планирование.
Информация доводиться до руководителя проекта.
Сотруднику объясняется, что решение должно уладываться в рамки цена-качество-время.
Обычно после диалога в основном понимают :)
-
Здравствуйте, Careeristka!
Не больничный, не отпуска, отговорки вроде "закопался в решении", "думал сделать так, чтобы при доработке не надо было все переделывать", работаю над очень крутым решением, поэтому долго".
А как у Вас происходит контроль сроков? В какой момент времени менеджер проекта узнаёт, что разработчик не успевает справиться с задачей?
У нас это происходит так:
1. Перед началом production'а фичи разработчик прорабатывает технический дизайн фичи, который оформляется документально.
2. Разработанный дизайн ревьюится ведущим программистом, который вносит свои замечания, а разработчик - на основе этих замечаний - вносит изменения. После чего дизайн считается принятым.
3. Параллельно разработчик разбивает фичу на подзадачи, каждая из которых не может быть меньше 4-х и больше 24-х часов.
4. Эти задачи и их оценка также ревьюятся ведущим программистом, после чего вносятся изменения в задачи и их оценку, и далее - принимаются.
5. Затем задачи вносятся в систему контроля задач, и разработчик приступает к их выполнению.
6. Приступая к работе над задачей, разработчик ставит её в статус In Progress.
7. В конце каждого дня он обязан проапдейтить эстимейт по задаче. В ситуации, когда всё нормально, часы уменьшаются с запланированной скоростью.
8. Если задача пробуксовывает, то это сразу же становится видно менеджеру проекта, т.к. он собирает статистику каждый вечер после того, как все разработчики проапдейтят информацию по текущим задачам.
9. Далее менеджер пытается выяснить, в чём заключается причина пробуксовки. Если она носит организационный характер, то менеджер обязан помочь в её решении. Если причина - неучтённый технический риск, то он заносится в регистр рисков, и далее мониторится. Кроме того, происходит переоценка сроков. Если причина носит какой-то технический характер (например, разработчик не сталкивался с подобного рода задачами, и не знает, как её решить), то подключается ведущий программист, который помогает разработчику.
-
Опишите подробно один какой-нибудь случай из вашей практики. Слишком мало информации.
-
Согласен с Денисом.
Важная часть планирование.
Информация доводиться до руководителя проекта.
Сотруднику объясняется, что решение должно уладываться в рамки цена-качество-время.
Обычно после диалога в основном понимают :)
Вообще то, нет. Не должно. Эта штука вариативна. А попытка компенсации разброса, вызванного общими причинами всегда ведет к негативным последствиям.
Действия в случае особых и общих причин должны кардинально различаться.
"ГОСТ Р 50779 контрольные карты Шухарта" предлагает 8 критериев для того, чтобы отличить одну ситуацию от другой. Но лучше Генри Нива почитать. "Организация как система"
Обычно после диалога в основном понимают :)
Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.
PS. Вероятно, то, что я написал, выглядит несколько странно. Эти штуки контринтуитивны. Но с этим я ничего не могу сделать.
-
Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.
Точно. Регулярно такое вижу. Диалог как правило ни к чему не обязывает, обе стороны чувствуют что решили проблему, проблема откладывается как решенная, хотя ничего не изменилось вообще.
У нас в компании, срыв сроков происходит обычно по двум причинам:
1. Разработчик думает что знает как сделать за указанное при оценке время.
2. Разработчик не думает при оценке ни о чем кроме решения задачи.
Т.к. разработчиков у нас не очень много (менее 20 человек), по этому для каждого сотрудника есть поправочный коэффициент.
Т.е. оценка каждого умножается на него. Обычно он где-то в диапазоне 1,2 - 1,5.
-
Т.к. разработчиков у нас не очень много (менее 20 человек), по этому для каждого сотрудника есть поправочный коэффициент.
Т.е. оценка каждого умножается на него. Обычно он где-то в диапазоне 1,2 - 1,5.
Это тоже неправильно. Поправочный коэффициент должен быть таким, чтобы срыв сроков был в 50% случаев. После чего нужно на основании статистики рассчитать верхний и нижний пределы. И если вам нужен "почти гарантированный результат", то верхний предел и будет такой оценкой. Только разработчику ее показывать не надо, дабы не срабатывало когнитивное искажение "студенческий синдром".
И еще момент. Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть. Оно вам точно надо?
-
И если вам нужен "почти гарантированный результат", то верхний предел и будет такой оценкой.
Фактически у нас это он и есть.
Только разработчику ее показывать не надо, дабы не срабатывало когнитивное искажение "студенческий синдром".
Ни в коем случае!:)
Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть.
Никогда об этом не слышал, можно поподробнее?
Оно вам точно надо?
У нас проекты фикс прайс. Сначала нам из коммерческого департамента спускают проект, мы его оцениваем, затем уже продажники, руководствуясь какими-то внутренними инструкциями продают эти часы клиенту.
Оно нам может и не надо, но по другому в данном случае не знаю как.
-
Если программист дает оценку трудоемкости, то это снижает его производительность примерно на треть.
Никогда об этом не слышал, можно поподробнее?
Статистика: http://www.ozon.ru/context/detail/id/2338486/
Теоретическое обоснование: http://www.ozon.ru/context/detail/id/21211837/
У нас проекты фикс прайс. Сначала нам из коммерческого департамента спускают проект, мы его оцениваем, затем уже продажники, руководствуясь какими-то внутренними инструкциями продают эти часы клиенту.
Оно нам может и не надо, но по другому в данном случае не знаю как.
Примерно как везде.
По другому можно, но этому учиться надо. Долго.
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.
-
Примерно как везде.
По другому можно, но этому учиться надо. Долго.
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.
Спасибо за ссылки.
Может что-нить порекомендуете почитать про продажу пользы?
-
Спасибо за ссылки.
Может что-нить порекомендуете почитать про продажу пользы?
IMHO, наиболее ярко продажа пользы описана в книге "Цель-3". Только чего то я ее в продаже не вижу.
Еще можно вот эти две:
"Цель-2" http://www.ozon.ru/context/detail/id/6258664/
"Я так и знал!" http://www.ozon.ru/context/detail/id/5572374/
А первая цель это о том, как сделать чтобы было чего продавать. Т.е. об операционном менеджменте.
PS. На всякий случай примете к сведению предупреждение. И отнеситесь к нему серьезно. Изучение этих книг может изменить вас. Изменить необратимо. И это может быть очень больно.
-------------------------------------------------------------
"...но не совершай ошибку, Драко. Настоящая наука не похожа на магию. Ты не можешь заняться ею и остаться прежним, как это происходит, когда ты узнаёшь слова к новому заклинанию. За силу нужно платить. Платить цену столь высокую, что большинство людей отказываются это делать."
-
Вообще то, нет. Не должно. Эта штука вариативна. А попытка компенсации разброса, вызванного общими причинами всегда ведет к негативным последствиям.
Рассмотрим пример.
Есть 2 недели на реализацию требования Заказчика. Оценили - решили что делать 2 дня. Через день понимаем, что делать как минимум 5 дней.
Одно из решений: упростить реализацию, сделать за 4 дня , протестировать. И с осознанным риском отдать Заказчику.
Не-а. После диалога проблема маскируется. А ситуация ухудшается. Только теперь этого не видно.
Т.е. что не разговариваем тогда ? Цель разговора, довести текущее положение, о том что что к указанному сроку надо.
И на этом конечно не заканчиваем, а определяем маяки контроля.
В итоге если это будет систематически или разработчик успеет адаптироваться или придется попрощаться с ним
-
Продавать часы сильно не выгодно. Продавать лучше пользу клиента. И именно этому учиться долго.
Не могли бы вы пояснить эту идею?
У меня опыт участия в продажах не сильно большой, но в целом он укладывается в следующие рамки:
Сейл: Заказчик, тебе для полного счастья нужна вот такая хрень! Она для тебя сделает ... а еще ...
Заказчик: Ух ты! Хочу! Сколько мне это будет стоить?
Сейл: Надо посчитать, завтра пришлю оценку.
...
Сейл: Команда, мы вроде продали Заказчику ту хрень, которую бросили делать в прошлом году. Срочно нужна оценка, чего нам будет стоить сдуть пыль и довести до ума.
Команда: (после продолжительных подсчетов) X усредненных человеко-часов!
Сейл: Так... Х*1,5*стоимость часа + накладные + маржа + премии + премии мне + поддержание лояльности заказчика = Y.
...
Сейл: Заказчик, счастье обойдется тебе в Y*1,15!
Заказчик: Ну них.. себе счастье! Вы обалдели?
Сейл: Вот смета, убедись.
Заказчик: Да, по вертикали и горизонтали суммы сходятся... Ну, пошли договор заключать.
Т.е. заказчику продается счастье, а суммы подтверждаются часами.
-
Не могли бы вы пояснить эту идею?
У меня опыт участия в продажах не сильно большой, но в целом он укладывается в следующие рамки:
Сейл: Заказчик, тебе для полного счастья нужна вот такая хрень! Она для тебя сделает ... а еще ...
Заказчик: Ух ты! Хочу! Сколько мне это будет стоить?
Сейл: Надо посчитать, завтра пришлю оценку.
...
Сейл: Команда, мы вроде продали Заказчику ту хрень, которую бросили делать в прошлом году. Срочно нужна оценка, чего нам будет стоить сдуть пыль и довести до ума.
Команда: (после продолжительных подсчетов) X усредненных человеко-часов!
Сейл: Так... Х*1,5*стоимость часа + накладные + маржа + премии + премии мне + поддержание лояльности заказчика = Y.
...
Сейл: Заказчик, счастье обойдется тебе в Y*1,15!
Заказчик: Ну них.. себе счастье! Вы обалдели?
Сейл: Вот смета, убедись.
Заказчик: Да, по вертикали и горизонтали суммы сходятся... Ну, пошли договор заключать.
Т.е. заказчику продается счастье, а суммы подтверждаются часами.
Леонид, вы абсолютно правы. Так обычно и бывает. Но бывает и по другому. Редко. Я например так не умею.
Завод металлоизделий.
- Консультант. У вас сейчас в месяц $100kk продажи, $110kk расход и $800kk связанного капитала. Могу сделать $150kk продажи, $110kk расход и $200kk связанного капитала. Гоже?
- Заказчик. Да. Сколько?
- Консультант. $5k в месяц в течении 6 месяцев. Потом начнется вышеописанное счастье и тогда будете в течении 12 месяцев отдавать четверть от улучшения продаж и выгоды от уменьшения связанного капитала.
----------------------
Итого доход консультантов:
$30 000 - фиксированная сумма
(150 000 000 - 100 000 000)* 1/4 * 12 = $150 миллионов от увеличения продаж
(800 000 000 - 200 000 000)* 3% * 1/4 * 12 = $54 от уменьшения связанного капитала
Затраты: 2 человека, около года - примерно $100 тысяч
--------------------------------------------------
Польза заказчика: Из убыточной фирмы получается фирма, приносящая очень прилично денег
---------------------------------------------------
Но российский заказчик готов даже разориться, лишь бы не платить так много. Ну че, пусть разоряется. Чеж тут сделаешь то.
"Меняться необязательно. Выживание дело добровольное."
-
Леонид, вы абсолютно правы. Так обычно и бывает. Но бывает и по другому. Редко. Я например так не умею.
Понятно. Думаю, для получения таких возможностей потребуется не только усердие, но и некоторые предпосылки в среде, окружающей бизнес. Которые ныне не видно.
Так что я пока за продажу часиков.
-
Понятно. Думаю, для получения таких возможностей потребуется не только усердие, но и некоторые предпосылки в среде, окружающей бизнес. Которые ныне не видно.
Так что я пока за продажу часиков.
Да, согласен. Если не ошибаюсь, для изменения необходимо преодолеть когнитивное искажение "Неприятие потери" http://webpsiholog.blogspot.ru/2013/03/blog-post.html
при котором тебя настолько угнетает факт, что кто-то заработал рубль, что ты готов пойти на потерю своего червонца, лишь бы этот человек не заработал.
-
IMHO, наиболее ярко продажа пользы описана в книге "Цель-3". Только чего то я ее в продаже не вижу.
Еще можно вот эти две:
"Цель-2" http://www.ozon.ru/context/detail/id/6258664/
"Я так и знал!" http://www.ozon.ru/context/detail/id/5572374/
А первая цель это о том, как сделать чтобы было чего продавать. Т.е. об операционном менеджменте.
Спасибо за подсказку!
Первую цель я как раз читал (для общего развития), а до второй и третьей руки не дошли пока. Теперь точно дойдут:)
Первая цель мне очень понравилось, но мне пока не хватает коммерческого и управленческого опыта чтобы применить знания полученные оттуда к производству ПО.
-
Да, согласен. Если не ошибаюсь, для изменения необходимо преодолеть когнитивное искажение "Неприятие потери" http://webpsiholog.blogspot.ru/2013/03/blog-post.html
при котором тебя настолько угнетает факт, что кто-то заработал рубль, что ты готов пойти на потерю своего червонца, лишь бы этот человек не заработал.
Возможно этот фактор сыграет у какого-то мелкого хозяйчика свечного заводика. В системах посолиднее - вряд ли.
Там другое актуально. Балансы интересов различных игроков рынка, политическая ангажированность, негласные и гласные договоренности и сговоры, симбиоз с другими структурами...
Операционными совершенствованиями (которые вполне можно назвать внутренними) много не накопаешь.
Для серьезных цифр копать надо глубже. "Консультантов", которые способны менять маркетинговый профиль крупной организации, балансы интересов (в т.ч. сложившиеся в результате рейдерства и активного отстрела владельцев хозяйствующих субъектов чуть ранее), вести работу на уровне глав администраций регионов должны знать по именам. И скорее всего, их "в свободной продаже" не будет.
И сколько ни изучай управленческий учет, джиты и прочие бэст практайсы, таким не станешь. Нужно или правильно родиться, или правильно жениться, или удачно поработать в юности с правильными людьми в комсомольских ячейках. Ну и проявить недюжинные личные качества, разумеется.
Мнение, естественно, личное и совсем необязательно правильное. Возможно даже, что излишне пессимистичное. Но пока оснований для другого не имею.
Ну а если вернуться на уровень свечных заводиков, то почему бы и нет? Основная сложность в том, что сколько сам ни совершенствуйся, "когнитивные искажения" все равно в голове у Заказчика. Который своей головой и так доволен, и всякой фигней по совету консультантов заниматься не намерен. Ну, разве что если консультант - авторитетный в кругах общения Заказчика астролог или диетолог.
-
Основная сложность в том, что сколько сам ни совершенствуйся, "когнитивные искажения" все равно в голове у Заказчика. Который своей головой и так доволен, и всякой фигней по совету консультантов заниматься не намерен.
Именно.