Комментарии 9
Похоже, что в теме разработки вы поплыли. То вы сами выделяете стадии жизненного цикла продукта в отдельные продукты, то говорите, что это единый контур. И как бы компании не чекали таймшиты - их польза соотносится с формальностью подхода в организации.
Если проще, то время разработчики обычно заполняют от балды, а реально могут заниматься несколькими заданиями. Так как разработчик делает то, что от него требуют в данный момент. За день работы на новой фичей он может решить пару багов, помочь тестировщикам и ответить на вопросы саппорта. Отрапортует всё как "продуктовая фича". Ничем не отличается от подхода хорошего начальника - не его забота денежки считать. Поэтому могу вам сразу сказать, что ваш прибыльный продукт - это третья категория (старые продукты) и убыточная - первая (новая разработка).
А чтобы было по-другому, нужно менять процессы. Допустим оценивать успешность не попаданием в срок и тем, что клиент не ушел, а через затраты на разработку и интеграцию. Но и тут вас ждёт засада, так как продукт с большим сроком разработки не может быть прибыльным с самого начала. Если понимать, что привлеченные инвестиции != прибыль. В мире высоких технологий (тут же и медицины и химия), высокие прибыли основаны на том, что процесс разработки и тестирования долгий и дорогой. Agile как раз и подчёркивает принцип eventual consistency.
Я рассматриваю разработку как производственный процесс. Единый контур - это все подразделения, которые связаны с выручкой. Разработка любого вида продукта (в данном случае 3 видов) это тоже самое концептуально как производство натурального товара 1, товара 2 и товара 3. Маркетинг и продажи (исследования, кастдевы, обратная связь и тд) при взаимодействии с производством создают товары, нужные рынку (делают фичу 1 и не делают фичу 2, дорабатывают баг 2, баг 3 и 4 и тд.). Поэтому я не вижу противоречий между "единым контуром" и разными с точки и рдения процессами производства.
Что касается убытков. То тут немного иначе, прибыльным является группа 2. Группа 1 и 3 - убыточна. Масштаб убытков по 3 группе не понятен, тк никто не ведет статистику. На вскидку процесс длится больше 5 лет и из-за особенностей "технологии" (разработки ПО) будет требовать все больше ресурсов на поддержание жизнеспособности.
Процессы нужно менять, тут с вами совершенно согласна. Как и чеканье и использование таймшитов. Сейчас из-за устройства процессов, пользоваться ими неудобно и это сводится к чеканную ради чеканная или заполнению на коленке, что бессмысленно.
Ну давайте тогда абстрагируемся и перейдём к кирпичам. У вас маленький кирпичный заводик. Вы делаете кирпичи (разработка продукта), его нужно развезти заказчикам (адаптация и развёртка), ну и конечно, обеспечить качество гарантией (поддержка). Вы клепаете кирпичи и знаете расход материала, энергии и труда. Клиент/3-е лицо/вы занимается доставкой и складированием. В случае брака вы отвечаете за расхождения со стандартом (лом, предельная нагрузка, время и условия эксплуатации и т.д.). И вы говорите, что у вас:
убыточное производство
большой процент брака
вы в плюсе на перевозках
Вам самой не странно, что компания в прибыли только в том сегменте, который вообще не связан на прямую с вами (с продуктом). Есть целая ниша логистики (интеграторов), может ну их эти кирпичи то?
В любом бизнесе все стадии - это один продукт. И цена формируется из всех трех (или девяти). Если продав кирпич вы не заложили в его цену шанс на иск при обрушении дома, износ производства, форс мажоры доставки и тд, то о каком подсчёте прибыли и планировании идёт речь? Похоже, что всё на авось и пальцем в небо. Просто раньше как-то концы сходились, но Рандом велик...
Именно, никто не закладывает в стоимость износ производства и т.д.
Я бы иначе описала процесс производства кирпичей. У завода есть технология супер кирпичей, которые решают проблему заказчика (насекомые не проползают или влажность идеальная и тд). Компания может изготовить любой дом из кирпичей или кирпичи любого размера (это адаптация и внедрение текущего решения). Параллельно придумывает кирпичи с новыми свойствами или дополнительный к кирпичам продукт - черепицу, например. (и пытается их продать кому-то еще, выйти на новую нишу).
Из-за особенностей технологии, приходится регулярно приезжать и проводить дом.работы со сданным в эксплуатацию домом. Обрабатывать составом специальным кирпичи, подламывать дыры и тд. Иначе дом рухнет. Или обработали новым составом и по кирпичам плесень пошла, нужно снимать плесень и обрабатывать другим составом.
При оценке проекта (адаптация и внедрение), никто не считает работы по дальнейшему обслуживанию этих кирпичей, а костов там много.
Я думаю, что масштаб проблем накопился из-за возросшего числа проектов и клиентов, которых нужно поддерживать (3 тип продукта), при этом проблеме не уделяется внимание, требуется увеличить продажи, следовательно нагрузка на разработку и внедрение/адаптацию возрастет. Больше задач будет копиться в узком горлышке.
Так, к сведению. Все (почти), описанное в данной статье, относится к функциям продакт-менеджера. Но он в статье даже не упоминается.
Потому что это головняк продакта - сколько времени разрабов инвестировать в ту или иную фичу и считать, сколько денег она принесет, и не лучше ли инвестировать в другую фичу. У Саши в компании его, видимо, нет, точнее, он есть всегда, но его роль в компании выполняет кто-то, кто даже не догадывается о том, что несет эту высокую честь. И вряд ли это сюзерен.
Функция продукта есть, этот человек отвечает за разработку новых фичей и за развитие ПО в целом. Ввиду нехватки ресурсов, функционал и возможности практически равны 0. Кроме того, решение о том, что и как развивать принимается исключительно исходя из опыта и видения продукта, сео и тд. Я в след главе расскажу о том, как происходит продажа и принимается решение о создании новой фичи.
Основной упор в компании делается на адаптацию готового продукта (кастом для каждого нового заказчика, те подгонка готового решения под запрос). Поэтому большая часть ресурсов в тч разработки идет на это и на залатывание дыр в старых проектах. На новое нет ресурса. Поэтому и без того длинный срок еще сильнее удлиняется и повышается риск создания неактуального продукта.
Функция продукта есть, этот человек отвечает за разработку новых фичей и за развитие ПО в целом. Ввиду нехватки ресурсов, функционал и возможности практически равны 0. Кроме того, решение о том, что и как развивать принимается исключительно исходя из опыта и видения продукта, сео и тд.
Вроде бы все слова знакомые, но смысл ускользает :) Похоже, пару предложений Вы выкинули в последний момент.
Основной упор в компании делается на адаптацию готового продукта (кастом для каждого нового заказчика, те подгонка готового решения под запрос). Поэтому большая часть ресурсов в тч разработки идет на это и на залатывание дыр в старых проектах. На новое нет ресурса. Поэтому и без того длинный срок еще сильнее удлиняется и повышается риск создания неактуального продукта.
Такая ситуация примерно у 90% компаний в мире, занимающихся разработкой и работающих на свободном рынке. Ничего особенного. Думаю, и сюзерен говорит то же самое.
Я к тому, что дают продакту разрабов и аналитиков на разработку новых фичей)
Ну или дают, но потом забирают, потому что у заказчика горит, заказчик платит сейчас, а новые фичи - когда еще окупятся. Или выдают огромные ресурсы на создание фичи 1, которую никому больше нельзя в будущем перепродать.
На мой взгляд, это разсинхронная работа происходит тоже из-за того, что разработка нового продукта, продажи, внедрение, разработка в целом не состоят в едином контуре и не взаимодействуют между собой.Каждый тянет в интересную ему сторону.
ЕСли 90% так живут - "это печально" ))
Давайте попробуем разложить по полочкам.
Ну или дают, но потом забирают, потому что у заказчика горит, заказчик платит сейчас, а новые фичи - когда еще окупятся
То есть имеются запросы на поддержку, которые автоматом (для данного заказчика) переводят с третьей линии поддержки (студент на телефоне техсаппорта) на первую (разрабы), минуя все согласования и договоренности, правильно?
Но тогда разработки у вас, получается, нет, если назвать вещи своими именами? Потому что переключение разработчика с одной задачи на другую в технически сложном продукте - задача медленная, и если таких много - почти все время уходит на переключение.
Или выдают огромные ресурсы на создание фичи 1, которую никому больше нельзя в будущем перепродать.
Простите, Вы сейчас точно о продакте говорите? Потому что человек, с которым проделывают такие вещи, называется РМом, либо линейным руководителем, но уж точно не продактом. Продакту не могут просто спустить сверху фичи с ресурсами, поскольку это происходит на продуктовом комитете, где хотелки сейлов оцениваются в терминах времени и денег - и соотносятся с предполагаемой прибылью от включения фичи в продукт. Продакт имеет на продуктовом комитете решающий голос.
Если же речь идет о размерах убытков при отсутствии данных фич - это, скорее, уже не разработка, а саппорт.
На мой взгляд, это разсинхронная работа происходит тоже из-за того, что разработка нового продукта, продажи, внедрение, разработка в целом не состоят в едином контуре и не взаимодействуют между собой.Каждый тянет в интересную ему сторону
Еще раз повторю - так всегда и везде. Это нормально и даже хорошо, что ваши люди замотивированы выполнить именно свою часть работы, не беспокоясь о судьбе вселенной в целом. Ненормально не заставлять переводить их хотелки в условных попугаев, которые можно численно оценить, проверить и затем сравнить. Пока нет оценок, нет и смысла создавать такой контур, поскольку он нерегулируем - "Нельзя управлять тем, что невозможно измерить" (С) Хьюлетт из HP или Деминг, не помню уже.
Даже при упрощении, что разработка все-таки есть, и работает идеально, реализуя все фичи за один день, как определять, какую фичу надо реализовать завтра, а какую - через месяц? По степени близости к руководству и громкости голоса? Так это и так происходит, как я понял, зачем тут контур?
Отношения с IT. Часть десятая. Себестоимость и анализ фактических данных