Pull to refresh

Comments 8

Так, я не понял. Работников всех учитываем по рублю в день, а бетон как?
А стажеров от сеньёров тоже не отличаем, всех по рублю?
Тогда эти рубли с рублями складывать нельзя, и не понятен профит от рублей как единицы измерения.
В общем, почему не использовать — раскрыто полно. А чем даёт профит по сравнению с попугаями или отклонением по времени от достижения контрольных точек — не видно.
Данный вариант не для финансовой отчетности, а для понимания сколько сделано и как мы движемся. в частности SPI и CPI. Отстаем мы по времени и деньгам или нет. Задаем базу, и от нее считаем. Главное использовать одни правила. Можно работников по рублю, руководителей по 2, а бетон с коэффициентом. Можно все с коэффициентом. Вам другой пример — полет до Луны можно измерять километрами, а можно прослушанными песнями. И ответ «прослушали 100 песен из 500», лучше чем «мы находимся в пути».
Отклонения по времени от контрольных точек дает только отклонение по времени. А по содержанию? Хорошо если много мелких контрольных точек, а если всего 2, и что делать в промежутке?
ИМХО в ИТ у задачи есть 2 состояния — сделали или не сделали. Так что если контрольных точек 2, то или проект на неделю — одна в среду, другая в пятницу, или вы сильно влипли.
Сколько бы вы на задачу времени не ахнули — если она не сделана, то сейчас может вылезти что-то, что заставит её переделывать целиком.
А если это не так — то значит вы можете выделить промежуточные контрольные точки, по ним и нужно мерить.

Теперь про бетон: если вы скрыли все за абстрактным «1 рублем стажера», а потом применили коэффициент к бетону (который все знают, сколько стоит), то грош цена вашим пряткам — всегда можно восстановить чистые рубли.

А какая защита от классического "Какой результат? Бюджет-то освоен. Программисты программировали, тестировщики тестировали, дизайнеры рисовали, менеджеры управляли. Ну и что что релизить нельзя — люди же работали, надо оплатить."?

UFO just landed and posted this here
Измерение и есть защита. Программисты программировали 100 рублей из 400…

Ну вот проект какой-нибудь, интернет-магазин пускай. Оценен в 400 рублей программирования. По графикам всё хорошо — программисты сидят, работают, 400 рублей заработали и получили, даже много кода, проходящего не бессмысленные тесты есть.


Но в результате оператор не может ни одного товара добавить, а может ли покупатель его купить — неизвестно вообще. Вернее на тестах может, когда руками в базу сид записали, но вот в бою неизвестно.

Хорошо объясняет идею. Но EVM, на лично мой взгляд, хорош для вещей типа копания 100км канав (рытье котлована и кладка кирпича на стройке, перевод хелпа, рисование форм в бухгалтерии и картинок в играх). В общем, во всех тех случаях, когда риски не влияют на проект кардинальным образом.
В девелоперских сферах это далеко не так. Например, печатная плата делается 2-3 недели, и вполне может попасть на китайские праздники. Разработчики софта могут попасть на недокументируемую фичу библиотеки, называемую багом, и провозиться с ней пару недель. Залить ресурсами, как на стройке, такую проблему нельзя, поскольку установить контакты с местными производителями плат неизбежно займет время, а библиотеку эту знает один человек в компании, и, если он в отпуске, то проблема решится не ранее, через две недели. Даже на стройке может попасться принципиальный чиновник, которые не берет взяток, а потребует, чтобы все было сделано по инструкции, от и до, что многим исполнителям будет внове.
В общем, там, где большие риски, метод EVM не катит. Более того, ужасно, когда в роли руководителя проекта с высокими рисками оказывается успешный человек со стороны, той же стройки или продажник, который привык всю жизнь работать по EVM-KPI, и требует того же от подчиненных. Самый яркий пример — расследование причин катастроф Боинга после MCAS, тут статья пробегала про их менеджмент.
Sign up to leave a comment.

Articles