[Управление разработкой, Управление персоналом] Как оцифровать разработчика или коротко о том, как сделать работу разработчиков более прозрачной для Компании
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Преамбула
В одном, среднем по размеру российском Банке, есть интернет банк для физиков и юриков, сайты и мобильные приложения. А также есть подразделение, которое все это хозяйство сопровождает и развивает. Сюда и приходит молодой Руководитель, проработавший в этой организации уже более 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 дня
В результате получилась достаточно понятная методика, общим собранием (Заказчик, я, аналитик по системе и тимлид) решили ее опробовать, о первых результатах будет в продолжении…
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-компании, Карьера в IT-индустрии, Управление персоналом, Учебный процесс в IT] Токсичность в команде, компании и индустрии. Конспект митапа из серии “Инженер заходит в бар”
- [Карьера в IT-индустрии, Управление персоналом, Читальный зал] Переставляя кровати
- [Управление продуктом, Управление разработкой] 22 сентября, Онлайн-митап Product Engineering Meetup #2: Культура разработки
- [Карьера в IT-индустрии, Управление персоналом, Управление проектами, Управление e-commerce] Пошаговый план для директора по качеству клиентского обслуживания, чтобы его не уволили в этом году (перевод)
- [Конференции, Тестирование IT-систем, Управление разработкой] 30 сентября приглашаем на круглый стол QA&SDET онлайн
- [Программирование, Управление разработкой, Управление персоналом, Карьера в IT-индустрии] Как начать подгорать, но не выгореть в проекте, где «было срочно нужно»
- [WordPress, PHP, Управление разработкой, Монетизация IT-систем] Проблемы монетизации продуктов на WordPress
- [Управление разработкой, Разработка для интернета вещей, Производство и разработка электроники, Дизайн, Электроника для начинающих] Кухня промдизайна #1: почти идеальная разработка корпуса модуля IRRIOT
- [Карьера в IT-индустрии, Развитие стартапа, Управление продуктом, Управление разработкой] Составление требований к разработке фичей: Курс Создание программного продукта и управление его развитием
- [Карьера в IT-индустрии, Управление персоналом, Читальный зал] Почему 97% программистов 1С мало платят и так будет всегда
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_upravlenie_vremenem (управление временем), #_upravlenie_razrabotkoj (управление разработкой), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:33
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Преамбула В одном, среднем по размеру российском Банке, есть интернет банк для физиков и юриков, сайты и мобильные приложения. А также есть подразделение, которое все это хозяйство сопровождает и развивает. Сюда и приходит молодой Руководитель, проработавший в этой организации уже более 3 лет, от лица которого и будет данное повествование. Предыстория Банк современный, процессы построены согласно ITIL, на первый взгляд все выглядит «по учебнику». Как видно из названия статьи, мы затронем только один кусочек из интересующего нас процесса «Внесения изменений». Проблема Все в этом процессе было отлично за исключением одного момента, а именно – согласования Аналитиком сроков разработки с Заказчиком – владельцем продукта «Интернет банк юридических лиц, каналы web+mobile», далее будем называть его просто Заказчиком. Заказчик всегда понимал и принимал работы, которые проходили у него на глазах или с его участием, а именно:
Решение Шаг 1. Как в абсолютных значениях рассчитать длительность разработки Идей было много, одна из них: делать оценку на основании ранее выполненных задач, лучше, чем ничего, но:
Что, если не брать задачи целиком, а каждую разделить на конечные составляющие работ для нашей системы(системой, на протяжении всей статьи, будем называть Интернет банк юридических лиц, каналы web+mobile)? В нашем случае получилось так:
и т.д. в начале позиций было порядка 20, а в результате чуть больше 80 Для оценки трудоемкости каждого блока была придумана единица – стандартная единица трудозатрат(СЕТ, s). СЕТ — это абстрактная мера измерения трудоемкости, она не имеет под собой физического смысла, можно назвать как угодно. Путем ретроспективного анализа(за последние 3 месяца), мы(я, аналитик по системе и тимлид) разбили все задачи на конечные составляющие и пропорционально оценили трудоемкость каждой из них(si), результат в таблице(табл.1).  Теперь каждую задачу мы могли оценить в СЕТах, например:
После этого, был введен термин производительность(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 дня В результате получилась достаточно понятная методика, общим собранием (Заказчик, я, аналитик по системе и тимлид) решили ее опробовать, о первых результатах будет в продолжении… =========== Источник: habr.com =========== Похожие новости:
Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 21:33
Часовой пояс: UTC + 5