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

  

- Сашуля, вот тебе первое задание. Иди и проверь нашего самого главного по продуктам.

- А что нужно проверить?

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

 

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

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

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

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

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

 

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

- Ты, конечно, со своей задачей вообще не вовремя. Это теперь мне нужно будет поднять все свои записи, свериться, пересчитать. Это не быстро.

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

- Есть, но мы ими не пользуемся.

- В смысле *****???? Хм, сколько тебе понадобится времени на эту задачу?

- Неделя, максимум полторы. Но постараюсь в неделю уложиться.

 

Неделя!? Неделя, чтобы посчитать данные, которые должны уже где-то быть (даже чтобы уснуть, нужно сосчитать меньше овец, чем неделя). 

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

- А есть ли кто-то, кроме самого главного по продуктам, кто мог бы посчитать или найти данные по трудочасам разработки в разрезе новых фичей и модулей?

- Нет, никого нет. – Отвечает грустно директор по людям. 

- А босс самого главного по продукту (развивающий директор по продукту)? – в надежде спрашиваю я.

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

- Ну т.е. я буду сидеть и ждать 7 дней (это один, два, три, четыре, неделя!) пока он посчитает всех попугаев все часы?

- Ага. – Все также невозмутимо отвечает директор по людям.

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

 

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

 

- Скажи, как так получается, что тебе нужна неделя на актуализацию данных?

- Слушай, это же не так все просто. Вот ты, например, знаешь, что никто не знает сколько времени было потрачено на разработку основного нашего ПО?

- Почему? 

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

- А почему? 

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

- Т.е. никто не знает точно сколько на самом деле времени было потрачено на разработку того или иного продукта, фичи, доработки и кто был привлечен конкретно к работам?

- Неа. 

  

Разговор интересен еще и тем, что он означает (хотя прямо об этом не говорится), что данные, которые будут предоставлены – не будут корректными. Они лишь приблизительно покажут то, сколько и чье время было потрачено на создание IT-продукта.

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

Решение о старте разработки происходит опираясь исключительно на мнение авторитета:

- Да эта фича точно взлетит!

- Нам на его разработку нужно 20 часов. Точняк уложимся и продадим потом всем нашим заказчикам!

 

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

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

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

 

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

Это позволит избежать ситуаций, когда разработка какой-то, казалось бы, небольшой (с точки зрения функционала для заказчика) фичи обходится IT-компании в приличную сумму, для окупаемости которой требуется N продаж. И хорошо, если N – не стремится к бесконечности и представляет собой достижимый объем продаж в обозримый период времени (желательно, краткосрочный).

А так, даже анализ на коленке среди it-продуктов (модулей и фичей) представляет жалкое зрелище, потому что:

1.     Тут фактическая себестоимость многократно превысила плановую.

2.     Тут оказалось, что пока мы делали продукт – он стал никому не нужен.

3.     Вот эта фича стоит настолько до дорого, что ее никто не покупает.

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

5.     Вот этот продукт нам нужно продать миллион раз, чтобы окупить его. Пока продали три раза. Но ничего, осталось 999 997 раз и заживем.

 

Среди неявных проблем, которые всплыли как лепестки роз после дождя, оказалась и проблема того, что команды по адаптации и продуктовая команда конкурирует между собой, а следовательно не заинтересованы в отдельном успехе друг друга. Т.е. продавая новые востребованные продукты (удивительно, но такие тоже оказались в списке у главного по продуктам) текущим заказчикам, для апсейла и плановых платных доработок не остается денюжек. Как и тех, кому можно продавать по завышенной цене новые уникальные it-продукты. Неудивительно, что потом приходится резать цену и предлагать за 500 то, что вчера стоило миллион.

 

- Ой, да мы уже давно окупили себестоимость и разработку!

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

- Да кто об этом узнает?! 

 

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

Прошло много месяцев обсуждения существующих проблем, пока…

 

- Сашуля, у меня радостная новость! Мы закупили новые тайм шиты. Очень удобные и классные! Пойдем покажу!

- О, отлично.

- Но есть и плохая новость.

- Какая?

- Денюжки мы потратили. Шиты мы закупили еще три месяца назад, но ими никто не пользуется. 


ПС Обложка - кадр из фильма “Где моя тачка, чувак”, реж. Д. Лейнер.

 

 


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


  1. Hungryee
    23.07.2022 12:39
    +4

    В целом то мысли и правильные. Понравилась фраза про горлышко, которого «могло бы и не быть».

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

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


    1. sasha_firsova Автор
      23.07.2022 12:41
      -5

      Конечно, неудобно. Но вместо того, чтобы решить эту проблему - происходит имитация использования трекеров (+покупка, "внедрение", уговоры к использованию и тд)


      1. TonnyRed
        24.07.2022 03:35

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

        Кровати, чаще всего, переставлять бесполезно. Нужно организовывать ротацию "персонала".


    1. w0lf
      24.07.2022 09:16
      -4

      Нормально продуманный тайм-трекинг не отвлекает и не занимает много времени. Что я пониаю под "нормальный": Разработчик не должен заводить себе таски, это задача pm. Разработчик не должен думать о статусах и т.п. Он видит первый по приоритету таск, нажимает "старт" и начинает работать. При переключении - "стоп" и "старт" нового. Это занимает 20-30 секунд. Мы внедрили подобную систему более 10 лет назад, первое время для контроля матчили с табелем рабочего времени, потом, когда убедились в достаточной точности учета, перестали.


  1. Politura
    23.07.2022 18:14

    Но как рассчитать точно это время?

    Для этого не надо спрашивать всякие гугли, а только немного подумать.

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

    Вроде есть компании, где люди прыгают от проекта к проекту даже в течении дня, там такой подход не сработает, но и там не надо никого напрягать никакими таймшитами и прочим бредом. Сейчас для управления разработкой все используют Jira, или аналоги, а там у каждого тикета есть свои сторипойнты. И пусть человек за неделю закрыл всего два тикета, один на 2 сторипойнта, второй на однин, первый из одного продукта, второй из другого. Берем его рабочие часы за неделю и две трети относим к одному продукту, а треть к другому. Ну и отпускные его тоже в пропорции распределить по его недавним проектам.

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


    1. AlexeyK77
      23.07.2022 19:43
      +8

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


  1. mentin
    24.07.2022 04:18
    +7

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

    Только хорошо подумайте, нужно ли оно вам? ;)


  1. Nichls
    25.07.2022 10:10

    Здравый мысли есть в статье - тот, кто платит разрабам не хочет, чтобы ИТ представляло собой черный ящик, на вход которого подали 100500 денег и на выходе (как правило) получили то, что нужно.
    Стоило это то, что нужно, затраченных средств? Да Бог его знает!

    Возможно тот, кто платил разрабам думал "Нет "дорогого" или "дешево" - есть "Могу позволить эти расходы" и "Не могу", так как считаю, что оно того стоит и ПО/фичи нужны.

    ИМХО статья написана тем, кто хочет обосновать свое место в компании и свою зарплату.

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

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

    Как-то так.