Автор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.
По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.
Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?
Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о:
Первый фактор — новому приложению необходимо догнать текущее. Допустим, речь идет о замене используемой программной системы (а это практически всегда так, ибо зачем менять что-то, чем никто не пользуется). На поддержание ее работы затрачиваются существенные усилия: пользователи делают запросы, всплывают баги, появляются виды продаж, для которых приходится внедрять новые функции. В большинстве случаев команда не может бросить развитие текущей системы, чтобы взяться за создание другой.
Когда вы решаете разработать приложение заново, затраты на этот проект вы оцениваете только на основании накопленных знаний о текущей системе. При этом невозможно заранее учесть те фичи, которые добавятся в текущую версию системы одновременно с разработкой нового продукта, поскольку на момент оценки надобность в этих функциях еще не возникла.
Тем не менее, можно сделать догадку, сравнив продуктивность старой и новой команд. К примеру, если новая команда разработчиков выдает фичи в два раза быстрее, то прогнозируемые сроки сокращения разрыва между проектами необходимо умножить на два. Если они работают в пять раз быстрее, множитель составит 1,25. В таблице ниже указано время, которое потребуется новой команде, чтобы догнать старую при различной скорости работы.
Следующий фактор, продлевающий сроки переработки проекта, — неочевидные изменения, скрытые внутри существующего приложения. Как правило, переработке подвергаются достаточно старые системы. За годы работы в них внедрено множество функций, исправлена куча багов. И зачастую проекты переживают не одну группу разработчиков. По мере того, как люди уходят из команды, внесенные ими фичи забываются или неверно интерпретируются. Но пока фичи работают, они востребованы как минимум у некоторых клиентов.
Если не учесть этот фактор и выпустить релиз, то он получится хуже нормы (согласно графику, приведенному выше). Хоть в нем и будет реализовано все запланированное, возможности нового проекта все равно будут отставать от старого приложения. И наверняка придется ввести недостающие фичи.
Этот дополнительный объем работ упускают из виду при предварительной оценке. Его довольно сложно определить, но, по крайней мере, вы можете сделать соответствующие предположения, опираясь на то, какой объем выявила новая команда в ходе изучения текущего продукта. Лучше всего измерить этот показатель в виде процента от известного прогнозируемого объема работ и добавить в итоговую формулу. Обозначим этот фактор Fнп.
Последнее препятствие, с которым сталкиваются продукты, догнавшие предшественников по фичам, — это боязнь пользователей переходить на другую систему. Если в новинке нет принципиальных улучшений, какой смысл конечному пользователю перебираться на нее? Это особенно актуально, когда текущее ПО тесно интегрировано с бизнес-процессами другой организации. Какой бы громоздкой ни была старая система, люди уже привыкли к ней, научились обходить неудобства и выработали соответствующую «мышечную память». Предложить им просто выбросить весь этот опыт на помойку и начать сначала? Это не убедит пользователей оценить новинку.
Поэтому даже если команда учтет все известные и неизвестные фичи, им придется придумывать и добавлять новые функции до тех пор, пока продукт не станет достаточно убедительно выглядеть в глазах существующих пользователей.
Количественно оценить влияние этого фактора тоже довольно сложно. Но можно включить в формулу предположение в виде процента от известного прогнозируемого объема работ. Обозначим этот фактор Fу.
Сумма трех факторов — сокращения разницы Fср, непредвиденных поправок Fнп и улучшений проекта Fу — во много раз увеличивает предварительную оценку времени и стоимость разработки. Итоговый срок, выраженный по отношению к изначальной оценке, можно вычислить по формуле
Итоговые временные затраты = Tо + (Fср * Tо) + (Fнп * Tо) + (Fу * Tо)
Рассмотрим пример. Допустим, вы собрали команду, чтобы оценить затраты на переработку своего главного продукта. Они предположили, что четыре разработчика справятся за один год. Этот предположение записываем как То = 1.
Теперь предположим, что разработчики штампуют фичи в три раза быстрее, чем команда старого продукта. Pн = 3. Значит, фактор сокращения разницы составит 3 / (3 — 1) = 1,5.
Таким образом, к проекту уже добавилось 50% или шесть месяцев, просто из расчета времени, которое потребуется новой команде, чтобы догнать старую.
А что насчет непредвиденных поправок? Как можно выразить все то неизвестное, что прячется в старом приложении, в процентах от общего объема фич? Для этого можно учесть, сколько лет приложение развивалось и дополнялось, и сколько раз сменилась команда. Попробуем угадать: Fнп = 25%.
Теперь прикинем, что потребуется, чтобы существующие клиенты приняли продукт. Какие запросы на новые фишки накопились у вас в бэклоге? Какие из них достаточно ценны, чтобы убедить существующих клиентов перейти на новинку? Помните, что попытки навязать переход клиенту иногда заканчиваются тем, что ему проще уйти к конкуренту. Для примера спрогнозируем Fу 30%, и этого будет достаточно для внедрения.
Итого = 1 + 0,5 + 0,25 + 0,3 = 2,05 года.
Даже с учетом довольно скромных допущений первоначальный прогноз увеличился более чем вдвое. Fср, показатель сокращения разницы — самый изменчивый фактор. А если новая команда будет справляться только в два раза быстрее? Тогда первоначальная оценка этого фактора увеличится вдвое, а итоговый результат вырастет до 2,55!
Прежде чем анализировать преимущества нового приложения и расходы на его переделку, имеет смысл рассчитать и реальные затраты на такой проект. Полагаю, в большинстве случаев вы придете к выводу, что подобный подход к переработке не окупится почти никогда.
А есть ли способ лучше? Я предложу альтернативу в своем следующем посте.
По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.
Модель оценки объема работ
Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?
Читайте также
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»
Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о:
- необходимости наверстать разницу между уровнями текущего и нового приложений,
- объеме непредусмотренных изменений,
- улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.
Сокращение разницы
Первый фактор — новому приложению необходимо догнать текущее. Допустим, речь идет о замене используемой программной системы (а это практически всегда так, ибо зачем менять что-то, чем никто не пользуется). На поддержание ее работы затрачиваются существенные усилия: пользователи делают запросы, всплывают баги, появляются виды продаж, для которых приходится внедрять новые функции. В большинстве случаев команда не может бросить развитие текущей системы, чтобы взяться за создание другой.
Когда вы решаете разработать приложение заново, затраты на этот проект вы оцениваете только на основании накопленных знаний о текущей системе. При этом невозможно заранее учесть те фичи, которые добавятся в текущую версию системы одновременно с разработкой нового продукта, поскольку на момент оценки надобность в этих функциях еще не возникла.
Тем не менее, можно сделать догадку, сравнив продуктивность старой и новой команд. К примеру, если новая команда разработчиков выдает фичи в два раза быстрее, то прогнозируемые сроки сокращения разрыва между проектами необходимо умножить на два. Если они работают в пять раз быстрее, множитель составит 1,25. В таблице ниже указано время, которое потребуется новой команде, чтобы догнать старую при различной скорости работы.
Непредусмотренные поправки
Следующий фактор, продлевающий сроки переработки проекта, — неочевидные изменения, скрытые внутри существующего приложения. Как правило, переработке подвергаются достаточно старые системы. За годы работы в них внедрено множество функций, исправлена куча багов. И зачастую проекты переживают не одну группу разработчиков. По мере того, как люди уходят из команды, внесенные ими фичи забываются или неверно интерпретируются. Но пока фичи работают, они востребованы как минимум у некоторых клиентов.
Если не учесть этот фактор и выпустить релиз, то он получится хуже нормы (согласно графику, приведенному выше). Хоть в нем и будет реализовано все запланированное, возможности нового проекта все равно будут отставать от старого приложения. И наверняка придется ввести недостающие фичи.
Этот дополнительный объем работ упускают из виду при предварительной оценке. Его довольно сложно определить, но, по крайней мере, вы можете сделать соответствующие предположения, опираясь на то, какой объем выявила новая команда в ходе изучения текущего продукта. Лучше всего измерить этот показатель в виде процента от известного прогнозируемого объема работ и добавить в итоговую формулу. Обозначим этот фактор Fнп.
Улучшения, необходимые для внедрения
Последнее препятствие, с которым сталкиваются продукты, догнавшие предшественников по фичам, — это боязнь пользователей переходить на другую систему. Если в новинке нет принципиальных улучшений, какой смысл конечному пользователю перебираться на нее? Это особенно актуально, когда текущее ПО тесно интегрировано с бизнес-процессами другой организации. Какой бы громоздкой ни была старая система, люди уже привыкли к ней, научились обходить неудобства и выработали соответствующую «мышечную память». Предложить им просто выбросить весь этот опыт на помойку и начать сначала? Это не убедит пользователей оценить новинку.
Поэтому даже если команда учтет все известные и неизвестные фичи, им придется придумывать и добавлять новые функции до тех пор, пока продукт не станет достаточно убедительно выглядеть в глазах существующих пользователей.
Количественно оценить влияние этого фактора тоже довольно сложно. Но можно включить в формулу предположение в виде процента от известного прогнозируемого объема работ. Обозначим этот фактор Fу.
Подытожим
Сумма трех факторов — сокращения разницы Fср, непредвиденных поправок Fнп и улучшений проекта Fу — во много раз увеличивает предварительную оценку времени и стоимость разработки. Итоговый срок, выраженный по отношению к изначальной оценке, можно вычислить по формуле
Итоговые временные затраты = Tо + (Fср * Tо) + (Fнп * Tо) + (Fу * Tо)
Рассмотрим пример. Допустим, вы собрали команду, чтобы оценить затраты на переработку своего главного продукта. Они предположили, что четыре разработчика справятся за один год. Этот предположение записываем как То = 1.
Теперь предположим, что разработчики штампуют фичи в три раза быстрее, чем команда старого продукта. Pн = 3. Значит, фактор сокращения разницы составит 3 / (3 — 1) = 1,5.
Таким образом, к проекту уже добавилось 50% или шесть месяцев, просто из расчета времени, которое потребуется новой команде, чтобы догнать старую.
А что насчет непредвиденных поправок? Как можно выразить все то неизвестное, что прячется в старом приложении, в процентах от общего объема фич? Для этого можно учесть, сколько лет приложение развивалось и дополнялось, и сколько раз сменилась команда. Попробуем угадать: Fнп = 25%.
Теперь прикинем, что потребуется, чтобы существующие клиенты приняли продукт. Какие запросы на новые фишки накопились у вас в бэклоге? Какие из них достаточно ценны, чтобы убедить существующих клиентов перейти на новинку? Помните, что попытки навязать переход клиенту иногда заканчиваются тем, что ему проще уйти к конкуренту. Для примера спрогнозируем Fу 30%, и этого будет достаточно для внедрения.
Итого = 1 + 0,5 + 0,25 + 0,3 = 2,05 года.
Даже с учетом довольно скромных допущений первоначальный прогноз увеличился более чем вдвое. Fср, показатель сокращения разницы — самый изменчивый фактор. А если новая команда будет справляться только в два раза быстрее? Тогда первоначальная оценка этого фактора увеличится вдвое, а итоговый результат вырастет до 2,55!
Прежде чем анализировать преимущества нового приложения и расходы на его переделку, имеет смысл рассчитать и реальные затраты на такой проект. Полагаю, в большинстве случаев вы придете к выводу, что подобный подход к переработке не окупится почти никогда.
А есть ли способ лучше? Я предложу альтернативу в своем следующем посте.
roscomtheend
Это не только доработка, это и создание конкурирующего продукта. Часто слышим «ужасный продукт, никто не хочет делать конкурента и озолотиться, раньше делали, а теперь… (обленились, капитализм(почему он?), мировой заговор)». В том-то и дело что раньше, когда система с 3 функциями начинала заменять систему с 5ю, оставшиея две допиливались быстро, да и профит от лучшей реализации тех трёх был заметен, а сейчас нельзя выкатить 3, поскольку у конкурента их уже 55, нужно хотя бы 53 (а лучше 63), потому как у оригинала аудитория, море документации, учебные пособия, наработанный саппорт и много чего ещё. Конечно, мессенджер с нескучными обоями может отхватить кусок рынка за счёт новизны (и быстро отвалиться, ибо не имеет УТП), но заменить «серьёзные системы» сейчас — задача не для мелких контор и бюджетов. И бюджеты важны, поскольку 55 функций будут делаться на порядок+ дольше, чем 5.