Производство заведомо некачественного ПО

Производство заведомо некачественного ПО

Сегодня хотелось бы поговорить о производстве некачественного программного обеспечения, как одном из основных демотивирующих факторов в работе.

О чём вообще речь? Речь идёт о ситуации, когда заказчик напрямую просит оставить баги в программе так как это его дело (связанное с финансированием их исправления) а наше дело делать всё строго по плану работ (в который исправление мелких несущественных багов сознательно исключено).

У меня лично такой подход вызывает чувство отвращения к собсвенной работе по такому проекту, и работать далее заставить можно толко "из под палки". Почему ?

Часто вообще бывает наоборот - бьёшься бьёшься чтобы добить все баги в программе, а они всё лезут и лезут…. Конечно, кто то скажет что проблема в процессе разработки и … будет прав. При правильном подходе, баги фиксяться до того как возникают - на этапе написания юнит тестов. Если же тестов нет а идёт только интеграция, то багов может оказаться много и интуитивно, каждый разработчик старается избегать таких ситуаций. Правильно сказано - если баги находит отдел QA, значит тестирование происходит слишком поздно.

Я считаю, что всё что делается нашей командой, должно делаться на максимальном качественном уровне. Нам невыгодно (ни финансово, ни имиджево) писать глюкавые программы, даже в том случае, если заказчик считает (и часто ошибается), что это выгодно ему. Куда мы денем такой проект ? Заработать на таком проекте получиться только на стартовой стадии - далее проект медленно умрёт от накопившихся в проекте багов. Мало того, работа над таким проектом, со временем начнёт приносить всё меньше и меньше удовольствия всем сторонам, учавствующим в процессе - пользователям проекта, заказчику, и нам, так как продуктивное время будет испорчено наличием проблем на всех уровнях реализации.

Шансов "выйти в люди" у проекта с низким качеством реализации почти ноль. Я так замечаю (и не только я) что популярными и интересными для пользователя становяться только те реализации, которые содержат минимальное количество багов, при максимально востребованном функционале. Конечно найти золотую середину довольно сложно так как в одном случае 100 багов на квадратный сантимтр программы будет недостаточно чтобы отвадить пользователей от пользования единственным и неповторимым онлайн ресурсом - а в другом случае наличие одного несущественного бага (например при оплате данных по кредитке) может отвадить всех и навсегда.

Именно потому что мы знаем насколько важно поддерживать качество разработки на уровне постоянно, мы просто тупо отказываемся работать с заказчиками, которые в процессе работы настаивают на том, что фиксить баги и заниматься рефакторингом кода "не является приоритетом для данного проекта".

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

Почему же так происходит? Почему даже старые заказчики иногда "портяться" и начинают настаивать на том, что качество значения не имеет, главное скорость и количество фич? Мне кажется дело в недальновидности таких решений. Часто кажется что таким образом можно съекономить средства на разработку - ведь за меньшие деньги получается больше фич, и быстрее. Это ли не факторы успеха? Как оказывается, по нашему опыту - разработка ПО с багами зараннее обречено на провал. Потому что через непродолжительное время, количество багов нарастает в геометрической прогрессии, и в такой же прогрессии падает скорость разработки и вырастают расходы. Мне это ясно и понятно, но вот часто объяснить это заказчику, даже с моим опытом ведения политических переговоров часто сложно.

Очень интересная аналогия по этому поводу приведена в книге "The Pragmatic Programmer: From Journeyman to Master". Там приведен опыт полиции одного из городов в NY. Опыт следующий - если в нежилом здании все окна целы, то оно стоит и никаких проблем. Если же кто то разобьёт окно, и при этом никто не прийдёт и не заменит - то от времени, то максимум через пару лет здание кроме как на снос больше ни на что годиться не будет? Вначале появляется граффити, потом бомжи, потом что то ещё происходит, а потом уже вернуть былое состояние становится невозможно. Очень похожая ситуация с ПО. Если зараннее не следить за качеством - проект умрёт, по той или иной причине с точки зрения заказчика. При этом, этот же заказчик будет считать виноватыми нас, а мы его.

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

 

Comments

Comments powered by Disqus