Маленькие вещи могут иметь большое значение
Много лет назад я работал над проектом с фиксированной ценой в качестве инженера по обеспечению качества. В проекте с фиксированной ценой, теоретически, цена и объем фиксированы. На самом деле цена фиксирована, а объем остается гибким. Как подрядчик, вы не можете постоянно говорить «нет» всему и делать клиента довольным. Если можете, позвоните мне. Я хочу учиться на твоих путях.
Ключ к успеху в проектах с фиксированной ценой в качестве подрядчика - это быть достаточно гибкими, чтобы клиент был доволен, но при этом вы оставляете достаточно маржи для себя, чтобы заработать немного денег. Таким образом, это беспроигрышный вариант, и клиент может нанять вас для дополнительной работы. Это сложная и сложная игра, особенно потому, что все оценки делаются заранее и часто ошибочны.
Оценки, сделанные до начала проекта, затруднены только из-за того, что они знают заранее. И это может быть значительным недостатком, поскольку кажущиеся тривиальными детали могут испортить ваши первоначальные оценки. Если вы скептически относитесь к такой возможности, позвольте мне рассказать вам историю проекта, который вышел из-под контроля из-за разногласий, отмеченных как тривиальные, но не маловажных.
Мы работали над проектом, в котором нам нужно было интегрироваться с определенной версией продукта. Один из рисков, который мы определили перед запуском проекта, заключался в том, что в среде принятия и производственной среде использовались несколько разные версии. В среде принятия была запущена английская версия программного продукта, а в производственной среде использовалась голландская версия, которая была немного старше.
Мы попытались убедить клиента, что мы должны обновить их, чтобы они работали с той же версией. В наших глазах язык не имел значения. Но, к сожалению, это было невозможно из-за затрат на лицензирование и усилий, связанных с обновлением. Поскольку разница в номерах версий была не такой большой, мы оставили ее в покое и добавили дополнительные отступы ко всем нашим оценкам, чтобы устранить неопределенность.
Проект с фиксированной ценой потерял цифровому агентству в 5 раз больше денег, чем предполагалось. И самым большим сюрпризом было то, что это произошло не из-за разницы в версиях. Это произошло потому, что они использовали другой язык. Поэтому, даже если мы обновили производственную среду до той же версии, что и среда принятия, она не решила бы наши проблемы.
API для указанного программного продукта был разным для каждого языка, он зависел от языка. В голландской версии был другой API, и вам приходилось делать вызовы API на голландском языке. Поэтому, если вы будете использовать вызовы английского API в голландской среде, они не будут работать и приведут к ошибкам. Это означало, что ничего из того, что мы построили, не будет работать, когда мы запустим его в производство.
Нам нужно было создать что-то, что работало бы как в принимающей, так и в производственной среде, даже несмотря на то, что эти две среды были фундаментально разными. Другой вариант заключался в том, чтобы перенести одну из двух сред на другую языковую версию, что также было дорогостоящим мероприятием.
Короче говоря: разные языковые версии одного и того же программного обеспечения не должны иметь значения, верно? Что ж, иногда это так, и это стоит компании огромных денег. Непредвиденная сложность имеет значение, и вы никогда не знаете, как она поднимет свою уродливую голову так, как вы меньше всего ожидаете.
Как мы могли предотвратить эту проблему? Выпуская что-то маленькое в производство раньше. Тогда мы бы сразу обнаружили проблему. Результат по объему работы был бы таким же, но, по крайней мере, мы бы обнаружили это раньше.
Я уверен, что у вас есть свои истории о, казалось бы, тривиальных деталях, сорвавших ценный проект. Напишите, пожалуйста, ответ, я бы хотел о них услышать!
Вы хотите писать для Serious Scrum или серьезно обсуждать Scrum?
