24 января 2025
«Укрощение строптивой» или комфортная цифровизация. Часть 2: почему может быть долго и дорого, и что делать, если нужно быстрее и дешевле?
Продолжаем разбирать значимость технического задания (ТЗ) для цифровой трансформации, а также сложности и нюансы взаимодействия заказчика и исполнителя при разработке программного обеспечения (ПО).
Рассмотрим Топ-4 ситуации при взаимодействии заказчика с исполнителем по вопросам “укрощения строптивой” цифровизации.
Ситуация 1. «Долго и дорого» — почему так происходит?
— Почему вы так долго делаете и дорого берете!!!
— Так бывает…
— Так бывает…
На самом деле здесь ситуация для размышления. Если посмотреть глазами исполнителя, то дорого и долго может быть из-за того, что у него не хватает компетенции. Любое П О можно написать на любом языке, только в одном случае это будет реализовано за две недели, а в другом — за два месяца. За всем этим находятся специалисты: аналитики, разработчики, тестировщики и др. Им потребуется время на изучение конкретных технологий или отраслевой специфики заказчика. У команды есть рабочее время, и, на задачу потребуется, например не 5, а 10 часов. Это подразумевает оплату труда. Следовательно, стоимость услуг для заказчика будет ее включать, покрывая затраты на создание ИТ-решений и напрямую влиять на конечную цену и сроки разработки ПО.
Исполнители могут быть разные
Первое, что делает заказчик до встречи с исполнителем, — мониторит рынок на наличие необходимого софта, который будет перекрывать его потребности. Готовый продукт и лицензия будут стоить дешевле. Любое создание ПО с нуля — это достаточно долго: постановка требований, согласование и т. п. Заказчики чаще всего не готовы долго ждать, даже при наличии бюджета. Проще приобрести готовый продукт или платформу, а потом кастомизировать под себя. Но в таком случае они должны перекрывать хотя бы 50% своих задач. Иначе это снова превратится в кастомизацию, которая будет стоить дороже, чем само подключение.
У исполнителя не хватает опыта в конкретной сфере
Это сложнее в разы. Получается, даже при владении конкретными технологиями необходимо инвестировать время в изучение процессов, работу структуры системы целиком, чтобы дальше декомпозировать все до конкретики. Если исполнитель всегда работал с банками, то для заказчика из этой сферы он будет исполнителем номер один, для заказчика из сферы автомобилестроения он будет весьма сомнительным: потребуется погрузиться в историю и изучение всех процессов. По сути, заказчик в этом случае берет на себя роль наставника, и это займет колоссальное количество времени.
Получается, что если заказчик выбирает исполнителя на основании деловой репутации и опыта, готов платить больше, но для него важнее качество и он доверяет аналитикам, то уже на старте комбинация «долго-дорого» будет оправданной. Просто следует на берегу взвесить все «за» и «против».
Пример оценки проекта по импортозамещению ПО
Например, один из проектов, который мы недавно рассматривали и оценивали. Есть задача в рамках автоматизации и импортозамещения создать объемный блок программного обеспечения, который обвязывает достаточное количество новых процессов, связанных с качеством. Для создания этого блока, чтобы полноценно понять все процессы, потребовалось бы 1,5−2 месяца чистой аналитики. И если запараллелить все работы, плюс 3−4 месяца чистой разработки.
Другая компания пришла, предложила меньше денег, так как у них есть движок готовый и на него не нужно тратить время, то, которое мы себе заложили. А время на кастомизацию и интеграцию с другими системами, они как раз заложили 1 месяц. Соответственно, они более конкурентны и быстро делают на своем движке со своими интерфейсами.
Мы же предлагали сделать это относительно долго. Если мы рассуждаем такими категориями, как скорость, и возьмем за «быстро» 1 месяц, то 5 месяцев — это уже долго. Мы собирались сделать, как в тех интерфейсах и программах, которые увидел заказчик, то есть восстановить их заново, но убрать затраты на обучение, которые будут после того, как они воспользуются услугами по созданию ИТ-решения другой компании. Потому что мы бы сделали им идентичный продукт, только их собственный. Не нужно было бы переучивать персонал и тратить на это время, силы, средства. Но все по-разному оценивают, что важнее в данном случае: либо время, либо деньги.
Всегда ориентируемся на конечную цель
Нет правильного и неправильного. Мы скорее говорим про понимание возможных вариантов развития событий, наличие конкретных ресурсов и что должно получиться в результате. Дальше уже по итогам анализа совокупности этих факторов будет понятно, как дальше действовать. При этом важный момент у комбинации «долго + дорого» — это качество, если оно в приоритете.
Если рассматриваем готовый продукт
Это не 100% гарантия, что дальше его можно развивать. Продукт может представлять собой коробку с жестко очерченными гранями, которую невозможно развивать под свой развивающийся бизнес. А когда разработка выполняется долго и качественно, то, как правило, закладывается возможность для масштабирования системы. Подразумеваются дополнения ИТ-решения новыми сервисами, модулями, блоками, функциями, которые будут уже ложиться поверх этой программы. Их стоимость будет намного ниже в сравнении с покупкой коробки, которая отвечает требованиям в моменте, но не будет отвечать им через длительное время. В итоге это приведет к решению, что рядом необходимо будет ставить что-то новое. Это влечет за собой потерю времени и сил, но вероятность того, что это будет стопроцентный фактор через какое-то время, тоже существует.
Вариантов здесь много, и некоторые заказчики «забивают какой-то костыль», чтобы это работало и дальше. Можно разрабатывать что-то свое и развивать внутри, оставляя за собой конкурентное преимущество, и все наработки останутся в компании. Можно масштабировать, изменять, конфигурировать свой бизнес уже на существующем поле, немного дорабатывая и изменяя ПО. В части коробочных сервисов это сделать невозможно: если они самостоятельно не развиваются — это путь к тупиковому развитию.
Ситуация 2. У нас есть дотендерная сумма — что мы получим за наши деньги?
— У нас есть дотендерная сумма — что мы получим за наши деньги?
— Сочувствие…
— Сочувствие…
Тут можно так продолжить этот диалог.
— Можете дать скидку?
— Могу.
— А сколько можете дать? Х рублей ?
— Да.
— А Y рублей можете дать?
— Конечно, можно. Вы у нас ничего не спрашивали, мы вам ничего не отвечали. У вас ничего нет, у меня ничего нет…
— Могу.
— А сколько можете дать? Х рублей ?
— Да.
— А Y рублей можете дать?
— Конечно, можно. Вы у нас ничего не спрашивали, мы вам ничего не отвечали. У вас ничего нет, у меня ничего нет…
Здесь дотендерная сумма — это некорректное целеполагание. Если мы говорим о том, что нужно что-то сделать, к этому необходимо готовиться. Процесс цифровизации достаточно сложный и небыстрый. Особенно зависит от масштаба компании. Дотендерная сумма может быть. Что за эти деньги может получить заказчик? «Посмотреть», выполнить небольшой объем работы, поставить цели и задачи. Все зависит от размера дотендерной суммы. Как правило, она небольшая. Нередки случаи, когда это становится инструментом манипуляции исполнителем (если мы говорим о недобросовестном заказчике).
Объем задачи имеет значение
Если он укладывается в дотендерную сумму, то провести аналитику, скорее всего, за эти деньги получится и прояснить ситуацию, чтобы понимать глубину проблем. Тут еще может быть осознанное получение заказчиком на коммерческой основе стороннего и независимого взгляда. И это тогда уже не про сочувствие, а про расширение возможностей.
Ситуация 3. Все и сразу
— Нам нужно только помочь с автоматизацией выгрузки отчетности… всей… международной… с аналитикой… и визуализацией… в 3D… … Вы куда? Я еще не договорил.
Аппетит растет во время еды. Самая простая задача может превратиться в «огромного динозавра». Это распространенная практика, когда нужно было просто выгрузить данные, а потом пришло понимание, что есть возможность сделать больше: покрасить зеленым, перенести из одной части в другую, и это будет все собираться с помощью магии в великолепный документ, который можно использовать. Среди заказчиков существует мнение, что это делается по щелчку пальца. Тем не менее необходимо правильно ставить задачу.
Возвращаемся к вопросу составления правильного ТЗ (ссылку на первую часть этого текста) и его согласования: всех необходимых функций, задач, требований к ПО и т. д. Дальше это может быть любой каприз за деньги заказчика. Возможно, он переформулирует цель, расширит и углубит, а может, с помощью компетентных исполнителей, наоборот, ее сузит до того момента, чтобы решать свои задачи и сделать свою жизнь проще.
Важность цифровой грамотности внутри команды заказчика
Заказчику не обязательно максимально точно разбираться в нюансах IT-производства, а важно на 150% знать все свои процессы и уметь изложить их на бумаге, либо рассказать в интервью IT-специалистам и аналитикам компании-поставщика. А они, в свою очередь, уже положат ответы на вопросы в ТЗ и автоматизируют процессы. Стоит отталкиваться именно от этого.
В основе «укрощения строптивой» цифровизации/автоматизации лежит качественное ТЗ!
Этот документ является главным, не только для того, чтобы правильно поставить задачи и декомпозировать на уровне разработки. Он имеет юридическую силу как приложение к основному договору, на основании которого ведутся и принимаются работы на уровне заказчика. И это является ограничителем аппетитов.
ТЗ подразумевает установку требований и ограничений по количеству правок, операций и т. д. Когда уходим за рамки установленного и утвержденного ТЗ, наш «аппетит» приводит к тому, что проект из маленького «крокодильчика» превращается в большого «динозавра», который съест все ваши ресурсы прежде, чем вы достигните результата. Такого быть не должно.
Ситуация 4. Стоимость и сроки для ‘ничего'
— Нам нужно сделать что-то. Сколько это будет в деньгах и как долго?
— Нужно уточнить ТЗ.
— Вы сначала скажите: сколько и когда!
— Нужно уточнить ТЗ.
— Вы сначала скажите: сколько и когда!
Это в корне некорректная постановка задачи, но она присутствует на рынке. Тут речь о цифровой грамотности. Главное, чтобы было понимание процессов, когда исполнитель берет тайм-аут для оценки на основе требований. Они составляются либо заказчиком, либо представляют собой отдельный вид услуги — аналитику. После этого можно озвучить стоимость. В противном случае будет игра в «угадайку».
Разные уровни и формы взаимодействия исполнителей с заказчиком
Например, можно озвучить стоимость одного часа разработки. Каждая задача оценивается в человеко-часах. Соответственно, договариваемся о количестве часов. Если идем по стандартному пути, когда исполнитель составляет ТЗ, оценивает его в часах, уточняет ставку специалистов и работает. Стоимость контракта получается путем умножения количества часов на стоимость часа.
Может быть другой момент, когда исполнитель конечной цели не видит. У него есть мелкие задачи, которые регулярно сыплются из предыдущего вопроса. Но это история о множестве противоречий и непрозрачности цели. Сложно понять, попадешь в ожидания заказчика или нет. Когда отсутствует достаточное количество данных для того, чтобы сделать хотя бы приблизительную оценку, то можно просто «ткнуть пальцем в небо».
Не исключено, что подобные ситуации — это «проверка на вшивость». Такие запросы могут иметь разные цели или группы целей: пощупать рынок и понять пути реализации, вилку цен, психологическую составляющую (каким образом исполнители реагируют на запросы) и т. п.
Итоги: «„Строптивую приручить“ — не магия, а точная наука» ;)
ТЗ — это венец, главный документ, конституция, фундамент дома и первый шаг младенца компании в цифровизации своего бизнеса.
Даже если поначалу цифровизация кажется непослушной, её «укрощение» — вопрос грамотной подготовки. Когда Т З составлено вдумчиво, приоритеты расставлены чётко, а команда говорит на одном языке, вместо конфликтов и резких скачков получается плавный переход к новым возможностям. И в итоге цифровизация перестаёт быть «страшным зверем», превращаясь в надёжного союзника, который ведёт бизнес к росту и эффективности.
Если заказчики сталкиваются с вопросами цифровизации, чаще всего перед ними стоит выбор: разработать уникальное решение с нуля или использовать готовую платформу, которая уже содержит базовые инструменты для управления и оптимизации процессов.
Когда к нам приходят заказчики с четким запросом или в поисках готового решения, мы предлагаем обратить внимание на «Платформу обработки телеметрической информации и поддержки принятия решений». Этот технологический продукт разработан именно для таких случаев и позволяет реализовать различные пользовательские сценарии в управляемые сроки.
Платформа позволяет ускорить получение результата и эффективно автоматизировать процессы, основываясь на четком ТЗ и уникальных требованиях бизнеса. В отличие от решений, созданных «с нуля», платформа уже имеет готовое ядро (интеграционную платформу), к которой можно добавить и индивидуально настроить модули под ваш бизнес, включая функции мониторинга, управления инцидентами, прогнозирования и автоматического выполнения задач.
Почему Logrocon?
- Скорость внедрения. За счет готовых инструментов мы помогаем быстрее запустить цифровизацию.
- Гибкость. Платформа адаптируется под уникальные бизнес-процессы, сохраняя возможность масштабирования в будущем.
- Экономия. Использование готового движка / продуктового ядра позволяет снизить расходы на разработку и тестирование.
Компания Logrocon обладает 12-летним опытом в области разработки, тестирования и интеграции ПО и ИТ-консалтинга. Мы предлагаем комплексные решения, адаптированные к специфике вашего бизнеса и поможем достичь поставленных целей.
Грамотное составление ТЗ и использование проверенных инструментов — первый шаг к успешной цифровой трансформации. Если ищете профессиональную поддержку в вопросах цифровой трансформации, наши эксперты готовы помочь вам на этом пути.
Свяжитесь с нами, и мы обсудим дальнейшие шаги.
Вам также может быть интересно