Это про то, что всем интересно, но про что стесняются спрашивать.
Есть два основных формата ведения проектов:
Fixed Cost (FC) - есть бюджет, сроки, критерий выполненности. Твори что хочешь, получишь результат - получишь деньги. Ошибся с оценками - сам дурак, будешь работать себе в убыток. Изменения требований/критериев (change request, CR)
(
Read more... )
Comments 26
(The comment has been removed)
Reply
Ну знакомая же ситуация, когда все понимают что какая часть проекта это кусок говна, который получился даже случайно, но его нельзя трогать? Да даже за рефакторинг в таком проекте по головке не похвалят. Обычно весь проект идет в режиме самообмана, вслух все говорят что "мы профессионалы", оно так и есть наверное, но на практике "ну здесь чуть сэкономим", "да и так пойдет, а че". Двоемыслие.
Reply
Опять же при FC понятие качества сугубо утилитарно. У рефакторинга тоже должен быть заказчик, хотя бы и внутренний. Если нет четко осознанной бизнес-цели действия, то оно превращается в бессмысленный ритуал. Рефакторить весь код из любви к красивому коду - один из примеров такого ритуала. Многие выполняют, не задумываясь. Потому что в умных книжках так написано.
Reply
Да, про рефакторинг я обще выразился, не обязательно он конкретно.
Reply
А вообще у энтерпрайз софта другие критерии качества, чем у консюмерского. Критерий простой: решена бизнес задача или нет, превышает ли стоимость вложений и TCO бизнес-вэлью, и не превышает ли совокупная величина рисков допустимый уровень.
Reply
Reply
Reply
Reply
Сколько раз для оценки FC-проектов использовал методику TM-проектов с завышенной ставкой. Как оказалось - не зря, почти все FC проекты требовали большого числа смежных работ, а иначе "денег не заплачу". Поэтому важно просто хорошо делать свое дело, а какая методика оценки - FC, TM, гибрид и потолочно-пальцевые оценки - дело десятое.
Опять же, если хорошо делаешь свое дело, а заказчик не согласен с предложенной моделью оценки и навязывает свою - это хороший повод не прыгать вокруг наглого клиента как вокруг драгоценного артефакта. А это очень хорошо, ибо, как ни крути, бизнес - это желание и рыбку съесть, и жопу не ободрать.
Reply
Reply
Reply
лучшая из ситуаций (имхо) - когда проект FP, но обоснование P даётся в терминах TM (при этом оцененых очень детально и основательно, здесь очень важно включить всё, чтобы потом не только не было мучительно больно, но и та самая (сверх)прибыль образовалась, к которой все стремятся)
ничуть, однако, не хуже та ситуация с монотонным процессом, когда люди из команды продают своё время, например, для поддержки чего-то достаточно стабильного, где активностей в среднем на полдня в неделю, но платят каждому за 40 часов, а оставшиеся 36 часов можно использовать для своей же выгоды.
мне доводилось бывать в обоих ситуациях, и сожалеть можно лишь о том, что первое далеко не всегда удаётся на фазе обоснования (часто знаешь, чем ограничен потолок по проекту, и приходится идти на компромисс с самим собой, чтобы не остаться без заказа), а второе - конь, крайне редко выходящий из вакуума и не всем материализующийся в виде нормальной, а не сферической формы.
Reply
Обоснование для кого? При FP обоснования для заказчика такое: "Это столько стоит". Трудозатраты и свою почасовую ставку афишировать вообще не обязательно.
> когда люди из команды продают своё время <...> где активностей в среднем на полдня в неделю, но платят каждому за 40 часов
Это как раз FP, при TM им бы заплатили только за полдня.
Reply
Обычно заказчики просят обоснование цены. Можно и не обосновывать, но в тех случаях, с которыми сталкивался я, диалог сразу становился резко неконструктивным.
> Это как раз FP
Неа, речь именно о "длинном TM", когда договор заключается, к примеру, на год и на определённое кол-во людей в наличии (т.е. в офисе на подхвате, отчёт и выставление счетов ведётся по времени прихода-ухода).
Reply
Reply
Leave a comment