Выработка у разработчиков

Выработка у разработчиков

Как спрогнозировать сроки исполнения задач? Как определить реальную потребность в ИТ-разработчиках? Они же не пирожки пекут, которые можно пересчитать в конце рабочего дня. В любой работе, имеющей творческую составляющую (программисты и системные архитекторы занимаются именно такой работой), нагрузку определить не так‑то просто.

Применяют ухищрения: аудит или декомпозицию написанного кода на блоки с расценкой каждого блока. Несколько лет назад для ИТ-разработчиков существовали даже методички с расценками: написанный в коде программы вложенный цикл — 2 рубля, выборка из базы данных — 1,5 рубля. Но представьте себе текст программы, в котором 150 – 200 тысяч строк. Сколько там вложенных циклов? Сколько выборок?

А главное — программа должна обеспечить получение результата с максимально эффективным использованием ресурсов и вычислительных мощностей. Если платить за количество циклов или символов, грамотные программисты в соответствии с такой мотивацией легко соорудят работающую программу с вложением в нее пары-тройки томов «Войны и мира».

Ну нельзя оценивать картины Ван Гога по количеству мазков или используемых оттенков желтого цвета. Не все подвластно калькулятору, иногда приходится прибегать и к экспертной оценке.

Существуют специальные программы и консалтинговые компании, которые предоставляют услуги по анализу кода программы на соответствие определенному стандарту или уровню безопасности. Но не будешь же каждую заявку пропускать через эту сложную и дорогую процедуру.

Поэтому мы создали в Корпорации свою экспертизу — «комитет по доработкам». В него входят ИТ-менеджеры, архитекторы и эксперты, которые, исходя из знания архитектуры информационной системы Корпорации, структуры процессов, взаимосвязей данных, определяют правильность и / или качество поступившей в службу разработки и «расцененной» программистом задачи.

Чтобы «комитет по доработкам» сам не расслаблялся, мы на ретроспективной основе проводим аудит его решений с привлечением внешних экспертов. Таким образом, выстроена система, способная достаточно объективно оценивать точность расценки заявок.

Зачем все это нужно? Реализация любой заявки требует определенных трудозатрат (на рисунке показан десяток видов работ, которые требуют затрат времени). Важно изначально оценить заявку в человеко-часах.

Учтем еще, что разработчик не может использовать все 168 рабочих часов в месяц (8 часов × 21 день) именно на разработку. У него немало других необходимых активностей, поэтому на разработку кода он может выделить порядка 60 % своего времени (то есть не более 100 часов в месяц). Ниже приведена диаграмма распределения рабочего времени грамотного программиста, имеющего опыт работы в Корпорации.

Почему мы сделали выше оговорку про «грамотного и имеющего опыт работы в Корпорации программиста»? Да потому, что вновь принятые разработчики, даже опытные, на новом рабочем месте показывают не более 60 – 70 часов производительной разработки в месяц. И только после погружения в процессы Корпорации, через 6 – 12 месяцев, выходят на 100‑часовой показатель выработки.

Вспоминается старый анекдот. Даму, пришедшую устраиваться на работу машинисткой, спрашивают: «Вы в резюме указали, что можете печатать со скоростью до тысячи знаков в минуту. Это правда?» «Могу и до тысячи, — отвечает дама, — только такая фигня при этом получается».

Впрочем, анекдот анекдотом, а исключения встречаются:

• есть люди, способные выдавать результат, причем качественный, и 168, и 180 часов в месяц;

• есть «программисты-Калашниковы», которые могут эффективно реализовывать до пятидесяти трех-четырехчасовых задач безотказно, не отрывая пальцев от клавиатуры.

Исключения радуют, но технология на них не строится, потому как люди это очень редкие, а у нас производство массовое и максимально технологизированное.