Еще 10-15 лет назад типовой программный продукт тщательно планировался и описывался в огромном техническом задании (ТЗ). А затем долго и кропотливо разрабатывался и тестировался чуть ли не годами.
Бывали ситуации, когда к моменту завершения продукт устаревал морально.
Я хорошо помню, что на запросы по разработке отвечал потенциальным клиентам: «Пришлите подробное ТЗ, мы оценим сроки и стоимость». Часть заказчиков не присылала ничего, мы и не печалились, предлагали разработать ТЗ либо отказывались работать без задания.
Но со временем экономические процессы начали развиваться быстрее. Гораздо быстрее, чем бизнес мог выделить времени на разработку ПО по такой схеме. И мы быстро перекочевали на динамическую разработку. Про аджайл еще мало кто слышал и употреблял.
Проблем на первом этапе стало на порядок больше. Очень возросла роль менеджмента. Если раньше дал программисту ТЗ и проверяешь по нему, то теперь стало необходимо управлять программистов в свете неопределенности задач от клиента и отсутствия четкой конечной цели.
Много кода приходилось переписывать на каждой новой итерации: сегодня одна хотелка от клиента, завтра другая.
Совершенная неопределенность в стоимости проекта и его сроках. А вот качество продукта стало лучше, код чаще был перед глазами, ошибки находились лучше, исправлялись быстрее.
Сегодня мы сталкиваемся с задачами, когда заказчик только примерно знает, что он хочет. И наша цель — как можно быстрее воплотить эти желания.
По-прежнему осталась проблема сроков и стоимости. Но мы решили ее для заказчика простым образом:
Разработка продукта состоит из трех факторов: бюджет, срок, возможности продукта. К сожалению, все факторы зафиксировать нельзя. Это фундаментальная особенность разработки программ. Как минимум один из факторов должен быть плавающим. Какой?По нашей статистике подавляющее количество заказчиков жестко фиксируют бюджет. Чуть свободнее относятся к срокам. А вот возможностями «жертвуют» легко — как-то сразу понимают, что если не в первой версии программы будет личный кабинет, так во второй или третьей.
Если клиент утверждает, что сроки не важны, то мы скептически относимся к серьезности такого заказчика. К счастью таких у нас было всего два. И оба через месяц вдруг стали злиться на медленную скорость разработки.
И ни одного клиента не было, кто зафиксировал срок и возможности программы, но оставил плавающим бюджет.
Проведя анализ первого полугодия, я начинаю делать еще больший упор на скорость. Скорость решает всё. Если есть скорость, ошибку можно исправить. Если скорости нет — даже тщательно разработанный код останется с ошибкой. А время уходит, возрастает недополученная прибыль заказчика. А этого надо всячески избегать.
Комментарии
Отправить комментарий