Преамбула У одного среднего российского банка есть интернет-банк для физиков и юристов, сайты и мобильные приложения.
Еще есть подразделение, которое обслуживает и развивает все это предприятие.
Тут-то и приходит молодой Лидер, проработавший в этой организации более 3-х лет, от имени которого и будет рассказана эта история.
Фон
Банк современный, процессы построены по ITIL, на первый взгляд все выглядит «по книжке».
Как следует из названия статьи, мы коснемся только одной части процесса «Внесения изменений», которая нас интересует.
Проблема
Все в этом процессе было отлично, кроме одного момента, а именно согласования Аналитиком сроков разработки с Заказчиком - владельцем продукта «Интернет-банк для юридических лиц, веб+мобильные каналы», в дальнейшем мы будем просто звонить он Заказчик.Заказчик всегда понимал и принимал работу, которая происходила на его глазах или при его участии, а именно:
- Уточнение и формализация его требований.
Он непосредственно видел, как из его 2-х строчек текста рождалась клиентская история, прототип и, наконец, продакшн для разработчика.
- Все виды тестирования.
Он видел огромные списки тестов.
- Документация.
Он мог посмотреть количество страниц текста и картинок (схем).
- Но с точки зрения разработки заказчик всегда чувствовал, что есть подвох; ему казалось, что злой (а на самом деле добросердечный человек) бородатый тимлид, давший свою оценку, видит только, как уложиться в 50 процентов сверхурочных часов, не удосуживаясь уложиться в SL и получить мотивацию по KPI .
Именно эту проблему пришлось решить молодому Вождю.
Решение
Шаг 1. Как рассчитать продолжительность разработки в абсолютных значениях Идей было много, одна из них: сделать оценку по ранее выполненным заданиям, лучше, чем ничего, но:- каждый раз проводить ретроспективный анализ трудоемко
- Невозможно подобрать аналоги для всех задач.
- Изменение макета страницы
- Создание новой страницы документа
- Доработка формы, вывод нового поля формы из базы данных
- Тип управления
- Комплексное управление (сложный нетривиальный алгоритм)
- Расширение схемы базы данных
- Скрипт рассылки СМС
- Скрипт для рассылки по ЭP
CET — абстрактная мера интенсивности труда; оно не имеет физического смысла; его можно называть как угодно.
Путем ретроспективного анализа (за последние 3 месяца) мы (я, системный аналитик и тимлид) разделили все задачи на конечные составляющие и пропорционально оценили трудоемкость каждой из них (си), результат представлен в таблице ( Таблица 1).
Теперь мы могли оценивать каждую задачу в SET, например:
Задача: реализовать форму обратной связи на главной странице системы, которая появляется для клиентов, не оставивших отзыв.
В форме отображается: шкала оценок в виде звездочек, нажав на которую можно поставить оценку от 1 до 5, поле ввода свободной формы длиной 500 символов, кнопка отправки, при нажатии на которую данные записываются в соответствующую базу данных table, закрытие формы без перезагрузки страницы.
Определение для простейших действий по таблице 1: Создание таблицы в существующей базе данных, написание логики отображения формы – 0,2 SET Макет формы, 2 поля + проверка на полноту – 1 SET Написание асинхронного запроса к серверной части, написание серверной функции для записи в базу данных – 1 SET Расчет трудозатрат ввод в наборах: 1 +1+0,2=2,2 НАБОР После этого был введен термин производительность (р), определяющий производительность каждой категории разработчиков (табл.
2).
Теперь оценить время разработки каждой задачи можно по формуле: 
давайте продолжим наш пример 4. Определение продолжительности работы для работника Старшего разряда:
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 дня
Результатом стала довольно четкая методология; общее собрание (Заказчик, я, системный аналитик и тимлид) решили опробовать, первые результаты обсудим позже.
Теги: #Управление развитием #Управление персоналом #управление временем
-
Ад Своими Руками
19 Oct, 24 -
Дайджест Joomla За Июнь-Июль 2019 Года
19 Oct, 24 -
Bumptop 3D Теперь Поддерживает Мультитач
19 Oct, 24
