Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.

  

- У нас нет пока понимания о том, сколько нам стоит каждый проект и разработка новых фичей. Часть проектов, по словам директора по денюжкам в разрезе 2 лет – убыточные, - бесстрастно объясняет СЕО.

- Это как?

- Мы инвестируем деньги в разработку стратегических продуктов и проекты. В этом смысле, мы – уникальная компания.

- Это я уже поняла, а что по себестоимости?

- С этим вопросом иди к директору по денежкам. - говорит сюзерен и машет рукой на дверь.

Аудиенция закончена.

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

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

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

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

 При этом, кажется, что интеллектуальные продукты можно условно разделить как минимум на 3 категории. 

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

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

- А что у нас по проектам?

- О, у нас есть регламент ведения проекта, есть шаблон для проведения обследования перед проектом и в стоимость мы закладываем различные риски. Это помогает более полно оценить масштаб задачи.

- А вы потом сверяете с таймшитами фактические трудозатраты?

- Мы планируем на них скоро перейти. Может быть к концу года.

 Вовлечение в операционку или отсутствие стратегического мышления не позволяет сложить в голове модель о том, как учет затрат на проект может влиять на весь бизнес в целом. Это не про задротство и учет часов ради учета часов. Контроль за временем в проекте позволяет не только анализировать постфактум рентабельность проекта (сравнить его с плановой), но и в будущем провести классификацию проектов в зависимости от сложности, проводить ABC и XYZ анализ и работать с продуктовой матрицей, более гибко управлять продажами.

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

- А в эту сумму заложен мой бонус за продажу и что это за маржа и наценка? – улыбаясь, спрашивают ребята из коммерческого отдела.

Наклоняюсь к расчетам, изучаю цифры и говорю:

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

- Эй, а почему они так считают?

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

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

- Я не хочу вообще ничего продавать! – упрямо твердит очень хороший начальник.

- Но ведь именно ты считаешь стоимость проекта.

- Я ничего не считаю. Я считаю часы. Все. Дальше продают продажники.

- Тем более, в твоих расчетах заложены показатели «наценка», «маржа» и единая часовая ставка, завышенная от реальных раз в 5... 

- Это не ко мне, а к директору по денюжкам и директору по операциям.

Любая оптимизация бизнес-процессов начинается с изучения того, как все происходит. Важно, понять, как это работает сейчас, как происходит взаимодействие, найти узкие горлышки, которые существуют внутри компании. Любое изменение требует согласия всех участников ну или как минимум отсутствие сопротивления с их стороны. Именно для этого проводятся встречи по сбору проблем, болей и видения того, как проблема может быть решена. Консалтерам или бизнес-аналитикам не нужно придумывать велосипед с колесом, нужно просто начать слушать и слышать то, что говорят те, кто максимально глубоко погружен в процессы и понимает их специфику. Для появления первой итерации изменений требуется в среднем 2-3 месяца в зависимости от численности компании и уровня ее консервативности. Другое дело, когда команда не желает изменений и отгораживается от проблем, которые на первый взгляд ее не касаются. 

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

- У нас нет проблем. Мы прекрасно считаем стоимость проектов по эталону. - раздраженно говорит мне очень хороший начальник.

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

- Потому что лично мне – это не нужно. Я внедряю и адаптирую проекты. Успешно. За много лет моей работы, ни один заказчик не расторг с нами контракт. Поэтому, Сашуля, займись делом. Иди учи продажников продавать.

В переговорах есть ситуация, когда гарантированно не удастся договориться. Это происходит, когда один из переговорщиков не желает договариваться. Какие бы профиты вы не предлагали, какие бы доводы не приводили – это не сработает, если на другом берегу с вами договориться не хотят.

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

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

Понимая фактическую себестоимость, можно было бы понять, какова доля в выручке каждого направления (проекты, новые продукты, доработка старых) и насколько каждое из направлений рентабельно. Эти данные позволили бы понять какое направление "сжирает прибыль", если действительно суммарно все проекты убыточны. При желании, можно было бы с помощью настроенной аналитики (от табличек в экселе до дашбордов BI или Таблё) проваливаться в каждый проект, сравнивать его с аналогичным и корректировать подход не только к оценке каждого нового контракта, но и возможно находить взаимосвязи в проектах в зависимости от отрасли или каких-то иных данных.

- Привет! Расскажи, пожалуйста, как вы считаете себестоимость? Мне сказали, что ты рассчитал единую ставку для более простого подсчета КП. 

- Это часовая ставка, при которой мы, условно говоря получаем 0 при реализации проекта. 

- Хм, хорошо. Но ты же понимаешь, что единая ставка смазывает картину и не дает понимания рентабельности по проектам? Ведь они отличаются по сложности и по уровню грейдов людей, задействованных в проекте.

- Им нужно вести таймшиты, иначе все эти расчеты - пустота. Я ничего не могу сделать чтобы изменить ситуацию. У нас все проекты убыточные, если считать их правильно. – Говорит директор по денюжкам и устало разводит руками. 

Решения, принятые жопой интуитивно и случайным образом завершившиеся успехом закрепляют паттерн принятия решения без привязки к цифрам и анализу, что глобально повышает риск убытка или как минимум ведет к снижению рентабельности бизнеса. Пока у вас нет реальных данных: трудочасов, часовых ставок и затрат, связанных с внедрением проектов, вы не понимаете экономику проекта. А общий убыток или 0 можете списать на: «Мы много инвестируем в разработку новых проектов».

Только после анализа и расчетов можно строить гипотезы и делать выводы: стоимость перепродажи часа сотрудников команды слишком высокая и не конкурентная значит нужно смотреть в структуру проекта, общие затраты офиса слишком высоки, тогда нужно разбираться с тем, как их оптимизировать, разработка новых проектов занимает много времени и не приносит прибыли, следовательно следует пересмотреть подход к оценке емкости новых продуктов и больше внимания уделить процессу разработки.

- Может быть, напихивая в расчет наценку, маржу и коэффициенты рисков мы предлагаем завышенную стоимость проекта, пытаясь переложить неэффективность менеджмента на заказчика? – спрашиваю у сюзерена.

- Ой нет. Сашуля, ты вообще знаешь сколько стоит такой проект в США? Наши цены в сравнении с международными – копейки.

Ну да, это же корректно сравнивать экономики двух стран, у которых только ВВП (ППС) отличаются между собой в 2,3 раза (69 375 $ на человека против 30 341$).

Фото: Екатерина Штукина/ТАСС.

Комментарии (9)


  1. XaBoK
    08.05.2022 16:40

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

    Если проще, то время разработчики обычно заполняют от балды, а реально могут заниматься несколькими заданиями. Так как разработчик делает то, что от него требуют в данный момент. За день работы на новой фичей он может решить пару багов, помочь тестировщикам и ответить на вопросы саппорта. Отрапортует всё как "продуктовая фича". Ничем не отличается от подхода хорошего начальника - не его забота денежки считать. Поэтому могу вам сразу сказать, что ваш прибыльный продукт - это третья категория (старые продукты) и убыточная - первая (новая разработка).

    А чтобы было по-другому, нужно менять процессы. Допустим оценивать успешность не попаданием в срок и тем, что клиент не ушел, а через затраты на разработку и интеграцию. Но и тут вас ждёт засада, так как продукт с большим сроком разработки не может быть прибыльным с самого начала. Если понимать, что привлеченные инвестиции != прибыль. В мире высоких технологий (тут же и медицины и химия), высокие прибыли основаны на том, что процесс разработки и тестирования долгий и дорогой. Agile как раз и подчёркивает принцип eventual consistency.


    1. sasha_firsova Автор
      09.05.2022 10:45

      Я рассматриваю разработку как производственный процесс. Единый контур - это все подразделения, которые связаны с выручкой. Разработка любого вида продукта (в данном случае 3 видов) это тоже самое концептуально как производство натурального товара 1, товара 2 и товара 3. Маркетинг и продажи (исследования, кастдевы, обратная связь и тд) при взаимодействии с производством создают товары, нужные рынку (делают фичу 1 и не делают фичу 2, дорабатывают баг 2, баг 3 и 4 и тд.). Поэтому я не вижу противоречий между "единым контуром" и разными с точки и рдения процессами производства.

      Что касается убытков. То тут немного иначе, прибыльным является группа 2. Группа 1 и 3 - убыточна. Масштаб убытков по 3 группе не понятен, тк никто не ведет статистику. На вскидку процесс длится больше 5 лет и из-за особенностей "технологии" (разработки ПО) будет требовать все больше ресурсов на поддержание жизнеспособности.

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


      1. XaBoK
        09.05.2022 15:55

        Ну давайте тогда абстрагируемся и перейдём к кирпичам. У вас маленький кирпичный заводик. Вы делаете кирпичи (разработка продукта), его нужно развезти заказчикам (адаптация и развёртка), ну и конечно, обеспечить качество гарантией (поддержка). Вы клепаете кирпичи и знаете расход материала, энергии и труда. Клиент/3-е лицо/вы занимается доставкой и складированием. В случае брака вы отвечаете за расхождения со стандартом (лом, предельная нагрузка, время и условия эксплуатации и т.д.). И вы говорите, что у вас:

        1. убыточное производство

        2. большой процент брака

        3. вы в плюсе на перевозках

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

        В любом бизнесе все стадии - это один продукт. И цена формируется из всех трех (или девяти). Если продав кирпич вы не заложили в его цену шанс на иск при обрушении дома, износ производства, форс мажоры доставки и тд, то о каком подсчёте прибыли и планировании идёт речь? Похоже, что всё на авось и пальцем в небо. Просто раньше как-то концы сходились, но Рандом велик...


        1. sasha_firsova Автор
          09.05.2022 19:07

          Именно, никто не закладывает в стоимость износ производства и т.д.

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

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

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

          Я думаю, что масштаб проблем накопился из-за возросшего числа проектов и клиентов, которых нужно поддерживать (3 тип продукта), при этом проблеме не уделяется внимание, требуется увеличить продажи, следовательно нагрузка на разработку и внедрение/адаптацию возрастет. Больше задач будет копиться в узком горлышке.


  1. DarkTiger
    08.05.2022 22:32

    Так, к сведению. Все (почти), описанное в данной статье, относится к функциям продакт-менеджера. Но он в статье даже не упоминается.
    Потому что это головняк продакта - сколько времени разрабов инвестировать в ту или иную фичу и считать, сколько денег она принесет, и не лучше ли инвестировать в другую фичу. У Саши в компании его, видимо, нет, точнее, он есть всегда, но его роль в компании выполняет кто-то, кто даже не догадывается о том, что несет эту высокую честь. И вряд ли это сюзерен.


    1. sasha_firsova Автор
      09.05.2022 10:52

      Функция продукта есть, этот человек отвечает за разработку новых фичей и за развитие ПО в целом. Ввиду нехватки ресурсов, функционал и возможности практически равны 0. Кроме того, решение о том, что и как развивать принимается исключительно исходя из опыта и видения продукта, сео и тд. Я в след главе расскажу о том, как происходит продажа и принимается решение о создании новой фичи.

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


      1. DarkTiger
        09.05.2022 18:52

        Функция продукта есть, этот человек отвечает за разработку новых фичей и за развитие ПО в целом. Ввиду нехватки ресурсов, функционал и возможности практически равны 0. Кроме того, решение о том, что и как развивать принимается исключительно исходя из опыта и видения продукта, сео и тд.

        Вроде бы все слова знакомые, но смысл ускользает :) Похоже, пару предложений Вы выкинули в последний момент.

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

        Такая ситуация примерно у 90% компаний в мире, занимающихся разработкой и работающих на свободном рынке. Ничего особенного. Думаю, и сюзерен говорит то же самое.


        1. sasha_firsova Автор
          09.05.2022 19:11
          +1

          Я к тому, что дают продакту разрабов и аналитиков на разработку новых фичей)

          Ну или дают, но потом забирают, потому что у заказчика горит, заказчик платит сейчас, а новые фичи - когда еще окупятся. Или выдают огромные ресурсы на создание фичи 1, которую никому больше нельзя в будущем перепродать.

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

          ЕСли 90% так живут - "это печально" ))


  1. DarkTiger
    09.05.2022 21:39

    Давайте попробуем разложить по полочкам.

    Ну или дают, но потом забирают, потому что у заказчика горит, заказчик платит сейчас, а новые фичи - когда еще окупятся

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

    Или выдают огромные ресурсы на создание фичи 1, которую никому больше нельзя в будущем перепродать.

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

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

    Еще раз повторю - так всегда и везде. Это нормально и даже хорошо, что ваши люди замотивированы выполнить именно свою часть работы, не беспокоясь о судьбе вселенной в целом. Ненормально не заставлять переводить их хотелки в условных попугаев, которые можно численно оценить, проверить и затем сравнить. Пока нет оценок, нет и смысла создавать такой контур, поскольку он нерегулируем - "Нельзя управлять тем, что невозможно измерить" (С) Хьюлетт из HP или Деминг, не помню уже.
    Даже при упрощении, что разработка все-таки есть, и работает идеально, реализуя все фичи за один день, как определять, какую фичу надо реализовать завтра, а какую - через месяц? По степени близости к руководству и громкости голоса? Так это и так происходит, как я понял, зачем тут контур?