Преамбула
В одном, среднем по размеру российском Банке, есть интернет банк для физиков и юриков, сайты и мобильные приложения. А также есть подразделение, которое все это хозяйство сопровождает и развивает. Сюда и приходит молодой Руководитель, проработавший в этой организации уже более 3 лет, от лица которого и будет данное повествование.
Предыстория
Банк современный, процессы построены согласно ITIL, на первый взгляд все выглядит «по учебнику». Как видно из названия статьи, мы затронем только один кусочек из интересующего нас процесса «Внесения изменений».
Проблема
Все в этом процессе было отлично за исключением одного момента, а именно – согласования Аналитиком сроков разработки с Заказчиком – владельцем продукта «Интернет банк юридических лиц, каналы web+mobile», далее будем называть его просто Заказчиком. Заказчик всегда понимал и принимал работы, которые проходили у него на глазах или с его участием, а именно:
- Уточнение и формализация его требований. Он непосредственно видел, как из его 2-х строчек текста рождается клиентская история, прототип, и наконец, постановка для разработчика.
- Все виды тестирования. Он видел огромные списки тестов.
- Документирование. Он мог посмотреть на количество страниц текста и картинок(схем).
- А вот в части разработки заказчик всегда чувствовал подвох, ему казалось, что злобный(а на самом деле добрейшей души человек) бородатый тимлид, давший свою оценку, только и видит, как вписать туда процентов 50 лишних часов, не утруждаясь уложиться в SL и получить мотивацию по KPI. Эту проблему и пришлось решать молодому Руководителю.
Решение
Шаг 1. Как в абсолютных значениях рассчитать длительность разработки
Идей было много, одна из них: делать оценку на основании ранее выполненных задач, лучше, чем ничего, но:
- трудоемко делать каждый раз ретроспективный анализ
- далеко не для всех задач можно подобрать аналоги.
Что, если не брать задачи целиком, а каждую разделить на конечные составляющие работ для нашей системы(системой, на протяжении всей статьи, будем называть Интернет банк юридических лиц, каналы web+mobile)?
В нашем случае получилось так:
- Изменение верстки страницы
- Создание новой документарной страницы
- Доработка формы, вывод нового поля формы из БД
- Типовой контроль
- Сложный контроль (сложный нетривиальный алгоритм)
- Расширение схемы БД
- Скрипт СМС рассылки
- Скрипт для рассылки по ЭП
и т.д. в начале позиций было порядка 20, а в результате чуть больше 80
Для оценки трудоемкости каждого блока была придумана единица – стандартная единица трудозатрат(СЕТ, s). СЕТ — это абстрактная мера измерения трудоемкости, она не имеет под собой физического смысла, можно назвать как угодно. Путем ретроспективного анализа(за последние 3 месяца), мы(я, аналитик по системе и тимлид) разбили все задачи на конечные составляющие и пропорционально оценили трудоемкость каждой из них(si), результат в таблице(табл.1).
Теперь каждую задачу мы могли оценить в СЕТах, например:
- Задача: реализовать форму обратной связи на главной странице системы, которая появляется у клиентов, не давших обратной связи. На форме отображены:
- шкала оценки в форме звездочек, кликом по которым можно дать оценку от 1 до 5,
- поле ввода в свободной форме длиной 500 символов,
- кнопка отправить, по нажатию на которую осуществляется запись данных в соответствующую таблицу БД, закрытие формы без перезагрузки страницы.
- Детерминация на простейшие действия, согласно табл.1.:
- Создание таблицы в существующей БД, написание логики отображения формы – 0,2 СЕТ
- Верстка формы, 2 поля + проверка на заполненность – 1 СЕТ
- Написание асинхронного запроса к серверной части, написание серверной функции записи в БД, — 1 СЕТ
- Расчет трудоемкости в СЕТах: 1+1+0,2=2,2 СЕТ
После этого, был введен термин производительность(p), который определяет производительность каждой категории разработчика(Табл.2)
Теперь стало возможным оценить длительность разработки каждой задачи по формуле:
продолжим на нашем примере
4. Определение длительности работ, для сотрудника категории Senior:
2,2(СЕТ)/1,5(СЕТ/день)=1,6 дней
Длительность 1,6 дней
Принимаем допущения: имея full-stack разработчиков, на решение каждой отдельной задачи привлекается только один из них.
Методика оценки так понравилась Заказчику, что он предложил оценивать остальные этапы работ:
- уточнение требований
- планирование реализации
- тестирование и документирование
в пропорциональном отношении от времени разработки, так были введены следующие коэффициенты (Табл. 3):
Теперь была возможность оценить длительность каждого этапа:
всю длительность внесения изменений в систему, по формуле:
например:
4. Определение длительности работ, для сотрудника (аналитик и разработчик) категории Senior:
0,2*2,2/1,5+0,3*2,2/1,5+2,2/1,5+0,2*2,2/1,5=0,3+0,44+1,6+0,3=2,64 дня
Длительность 2,64 дня
В результате получилась достаточно понятная методика, общим собранием (Заказчик, я, аналитик по системе и тимлид) решили ее опробовать, о первых результатах будет в продолжении…
