Каков коэффициент возврата инвестиций при привлечении аналитика?

Тема всплыла на форуме UML2.ru. Я за форумом на этом сайте не слежу, тем более в нем не участвую (не потому, что он плохой, а потому, что времени нету), но по этой теме попытаюсь высказаться, поскольку близка она, эта тема.
 

Я б русский бы выучил только за то...

Когда человек говорит, что хочет оценить коэффициент возврата инвестиций, то я могу предположить, что он просто хочет узнать, будет ли привлечение аналитика экономически оправданным. Но задаться таким вопросом человека мотивируют (на мой взгляд) две вещи: непонимание пользы от привлечения аналитика и желание численно (а потому наглядно) выразить эффект от участия аналитика в проекте.

Зачем нужен аналитик на проекте, кто такой аналитик - это вопросы, объем обсуждения вокруг которых сопоставим разве что с темой про жизнь на Марсе. Ответов на эти вопросы ровно столько, сколько народу ими задавалось, поэтому выскажу свое личное мнение.
Итого, если мы говорим об аналитике, как специалисте, знающем предметную область, способного проанализировать проблему и синтезировать ее решение на уровне постановки задачи под разработку, то использование аналитика на проекте будет полезно в том случае, если:

- в проектной команде нет экспертизы по предметной области;
- перед проектной командой стоит не сугубо техническая (разберите пожалуйста вот этот файл, а потом положите сюда), а бизнес-задача (нам нужно автоматически получить вот такой отчет, данные для него мы берем там, потом вот так их надо перелопатить, забить сюда и нажать ту кнопку).

Если эти два условия не выполняются, то аналитик на проекте не нужен и команда успешно справится без него.

Получается, что вопрос привлечения аналитика на проект решается очень просто на основе буквально пары критериев, характерных как для заказной, так и коробочной разработки.
 

Экономическая сторона вопроса

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

ROI = (Sw - Sl) / (Sh + Sc + Spr + Si)

где:
- Sw - выручка от работ, выполненных аналитиком;
- Sl - финансовые потери, связанные с некачественной аналитикой (деньги, потраченные на компенсацию низкого качества аналитики и не взятые с Заказчика);
- Sh - стоимость хантинга (поиск, вложения в замануху, аллокация HR-затрат на всякие мероприятия и т.п.);
- Spp - инвестиции в развитие специалиста (предпродакшен обучение, тренинги, и все такое прочее);
- Sc - награда специалисту за работу - зарплата + бонусы;
- Spr - инвестиции в работу специалиста в проекте (проектные тренинги, входная стажировка, командировки и подобные вещи);
- Si - затраты на обеспечения специалисту инфраструктуры (рабочее место, коммунальные и прочие всякие расходы, аллокация аренды помещения, телефон-интернет и прочие корпоративные расходы).

При заказной разработке экономический эффект от работы аналитика определяется той выручкой, которую компания получает с Заказчика за проделанную работу и теми финансовыми потерями, которые компания несет от некачественной работы аналитика. Эти цифры относительно просто узнать и более того - каждый руководитель проекта эти цифры скорее всего знает или подозревает хотя бы их порядок. Если руководитель проекта не знает эту цифру, значит он неудачник и за этот проект надо бояться.

Затратная часть (знаменатель) тоже довольно очевидна и на уровне компании ее всегда можно определить и более того - она почти наверняка считается.
 

Морально-этическая сторона вопроса

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

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

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

Единой идеи, как это сделать, у меня пока нет, но разрозненные мысли таковы:
1. Можно попытаться вывести такой показатель, как глубина проработки задачи аналитиком, который показывал бы на сколько детально аналитик должен прорабатывать задачу для того, чтобы ее можно было отдать в девелопмент. Интуитивно я понимаю, как это можно сделать, но словами пока не расскажу. Этот показатель может быть как априорный, так и апостериорный.
2. Качество проработки аналитики как соотношение затрат на поиск, обработку информации, синтез решения к затратам на изменения требований по причине низкого качества аналитики. В этом пункте пока понятно, как это сделать без учета затрат на переработку кода. Но это по идее сугубо апостериорный показатель.
3. Затраты на переработку кода вследствие некачественной аналитики (изменения требований по вине некачественной аналитики). Это скорее тоже апостериорный показатель.

Получается, что сейчас единственный путь, который мне видится - это путь по варианту 1.
Это как-бы начало, поэтому не судите строго. Лучше помогите идеей ;)

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы аналитика – а чем он занимается и чего можно померить?

Оценка эффективности работы руководителя проектов