Сколько стоит разработка: 5 мифов о затратах на IT-продукт

«IT-разработка – это слишком дорого», «Невозможно оценить эффективность IT-системы» – это лишь некоторые утверждения, которые говорят о недоверии бизнеса к технологиям. Однако изменения на рынке подтолкнули компании к усилению цифровизации. Мы более 20 лет разрабатываем ПО и сейчас получаем много запросов как на адаптацию готовых IT-систем, так и на разработку собственных уникальных продуктов. Исследуем пять популярных мифов о финансовой стороне IT-разработки и поделимся наблюдениями со всеми, кто планирует создание IT-продукта.

Миф 1. IT-разработка – это всегда сложно, дорого и долго

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

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

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

Другими словами, можно запустить систему, используя 20-30% от общего бюджета. Продажи начнут «отбивать» часть потраченных средств и финансировать следующие этапы разработки. Например, в нашем портфолио есть медицинский проект для сети клиник Великобритании, который мы развиваем более 10 лет. При этом его первый релиз вышел через 8 месяцев после старта. Также был опыт запуска MVP продукта для дистанционного банковского обслуживания крупного сетевого банка за 100 дней. К слову, этот продукт мы продолжаем дорабатывать и дополнять новыми современными фичами.

Миф 2. Можно сэкономить, передав задачи разработки No-Сode-системам

No-Code – это способ реализации IT-продуктов при помощи специальных платформ, без написания кода вручную. Его можно использовать для создания сайта компании, корпоративного портала, интернет-магазина, игрового приложения и других IT-решений. Таким путем родилось немало сервисов и приложений, в основном, зарубежных – Tavalo, Reachr, Look App, Comet и другие.

Чтобы передать задачи разработки No-Code-платформам, нужно серьезное основание. Например, доказанная гипотеза о том, какие бизнес-выгоды принесет такой шаг. На наш взгляд, вместо того, чтобы сокращать ресурсы, стоит задуматься, на что их выделить. Исследуйте возможности No-Code-платформ для решения конкретных бизнес-задач. При этом важно понять, что и насколько изменится в бизнесе, а главное – когда это произойдет.

Проведите эксперимент – сделайте прототип или MVP нового продукта на No-Code-платформе. Потом покажите результат своим клиентам или инвесторам, протестируйте вместе с ними, получите обратную связь. Если все устраивает, можно думать, как это развивать.

Вывод: No-Code-платформы удивляют возможностями и манят простотой освоения. Их действительно стоит изучать, но только вместе с имеющимися инструментами – использовать как возможность диверсифицироваться, усилить команду, расширить кругозор и компетенции разработчиков. Не стоит рубить сплеча и кардинально менять систему работы, если есть слаженная IT-команда.

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

Миф 3. Можно «собрать» IT-систему из доступных продуктов

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

Безусловно, правильно подобранное сочетание может помочь на старте проекта, но опасно полагать, что такие решения всегда будут «двигаться в одном направлении» с вашей компанией и одинаково быстро справляться с потребностями бизнеса, подстраиваясь под текущие реалии.

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

  • Имеют разные возможности кастомизации и интеграции. Некоторые конструкторы, готовые решения, No-Code-платформы никогда не смогут полноценно взаимодействовать между собой. Например, сайт компании интегрирован с платежной системой X, а вендор учетной системы и не планирует такую интеграцию.
  • Отличаются по качеству технической и клиентской поддержки, графику обновлений и т.п. В частности, для конечного клиента, как правило, не имеет значения, что у поддержки сайтов, созданных на разных платформах, разный SLA, и что сервер был недоступен в момент, когда он оплатил заказ. В следующий раз покупатель просто уйдет и не вернется.

Вывод: как показывает наша практика, чем сложнее планируемый продукт и чем «взрослее» существующий, тем очевиднее нужна индивидуальная разработка или модернизация с архитектурным решением, которое будет:

  • Отвечать текущим и будущим техническим и бизнес-требованиям.
  • Обеспечивать производительность, безопасность и управляемость.
  • Адаптироваться к новым требованиям.

Миф 4. Не нужно переплачивать, соберите команду из джунов

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

Собрать команду только из джунов – все равно, что открыть стоматологическую клинику и нанять туда на работу студентов из меда. Для проекта нужны специалисты, которые разработают продукт и выведут его на рынок, чтобы он начал приносить прибыль бизнесу.

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

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

  • Требования заказчика: насколько качественно они проработаны, детализированы и сформулированы в окончательной редакции – не планирует ли заказчик их менять.
  • Сложности проекта, его размер и объем задач, помимо кодинга: аналитика, дизайн, различные виды тестирования, CI/CD...
  • Технологический стек.
  • Наличие у специалистов опыта реализации подобных проектов.

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

Миф 5. Нет смысла тратиться на аналитику проекта

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

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

Какие задачи помогает решать Discovery-фаза

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

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

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

3. Стартап-изобретатель – человек из цифровой сферы, который увидел возможность уберизации сложившейся бизнес-модели. В этом случае подрядчик вместе с заказчиком погружается в предметную область, в некоторых случаях – с привлечением научной экспертизы. Далее проводит Customer Development, составляет перечень нужных пользователю функциональностей, определяет приоритеты и описывает наиболее удобные сценарии для пользователей. В итоге, быстро выпускает минимальный жизнеспособный продукт (MVP) для проверки возможности уберизации бизнес-модели в боевых условиях.

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

Вывод: если у бизнеса есть только идея, но нет техзадания, четких требований или понимания, с чего начать, предварительная подготовка поможет избежать ненужных трат. А главное – создать продукт, который будет востребован аудиторией, а значит, бизнес сможет на нем зарабатывать.

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

Читайте также:

Расскажите коллегам:
Комментарии
Инженер, Омск

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

Собрать команду только из джунов – все равно, что открыть стоматологическую клинику и нанять туда на работу студентов из меда. Для проекта нужны специалисты, которые разработают продукт и выведут его на рынок, чтобы он начал приносить прибыль бизнесу.

Ещё больший миф - слова Анны в цитате выше. Этим она наглядно показала насколько понимает разницу между специалистами. 

Итак, начнём: 

Здесь сразу возникает вопрос: кто будет их обучать? 

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

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

В процессе разработки важно грамотное сочетание теории и практики, желательно на реальных задачах.

На этом месте я бы спросил Анну: В чем разница между обычной практической работой в колледже или работой, выполненной человеком дома, в процессе самообразования и "реальной задачей" в коммерческой организации? 

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

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

Запомните раз и навсегда: Если вы человека наняли на работу, то дайте ему эту работу, и не мешайте ему её выполнять! 

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

Ваша работа - поддерживать связь с заказчиком, а не облизывать ему пятки! Заказчик тоже не дурак, чтобы менять подрядчика из-за лишних 2-3 дней ожидания. Если же всё таки дурак, то как говорится, "тут главное не мешать". 

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

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

И в третьих, давайте рассмотрим цитату "проверять за начинающими код". Сразу вопрос: Какой в этом содержательный смысл? 

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

Гениальный способ деверсии! 

А может стоит просто не мешать расспределить работу ведущему программисту или тому, кого они попросили назначить Team Lead-ом? Например, просто дать заниматься начинающим программистом тем же интересным проектом наравне с более опытными. 

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

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

Давайте ещё посмотрим:

  • А что если человек переходной категории? Уже не начинающий, но ещё и не настолько опытный, насколько хочется. 
  • А что если мы судим неправильно по "количеству времени в компании", а стоит судить по количеству и качеству проектов, над которыми работал конкретный специалист?
  • А что если, человек может хорошо адаптироваться к прикладным знаниям в тех вещах, с которыми он имеет дело впервые, ввиду того, что программирует он не в первый раз?! 
  • А что если, между синьором и архитектором нет ни то что больше, а вообще никакой разницы?! 
  • И наконец, где проходят границы водораздела между специалистами каждого ранга? Вы изобретали армию?! 
Инженер, Омск

Теперь о менеджменте с заказчиками, но сначала сразу закроем предыдущую тему:

Вывод: для достижения успеха любого проекта можно попробовать вывести идеальную формулу соотношения джунов, мидлов и сеньоров.

Уважаемая Анна Шведова, довожу до вашего сведенья, что уже как 40 лет существует формула 1:2:3, которую по-русски правильно было бы называть "иеархическая пирамида". 

Далее открывает тему цитата:

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

  • Требования заказчика: насколько качественно они проработаны, детализированы и сформулированы в окончательной редакции – не планирует ли заказчик их менять.
  • Сложности проекта, его размер и объем задач, помимо кодинга: аналитика, дизайн, различные виды тестирования, CI/CD...
  • Технологический стек.
  • Наличие у специалистов опыта реализации подобных проектов.
  • Запомните правило "Заказчик всегда пересматривает свои первые требования". Оптимально их разделить ровно на две главы:

    1. Эргономика и пользовательский интерфейс. Тут речь о том, для кого вы разрабатываете этот продукт. 

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

    Мой совет: Дайте человеку высказать письменно прямо все его пожелания. Пусть он их ещё пересмотрит это несколько раз, но свою первоначальную идею не потеряет ни заказчик, ни вы. 
  •  
  • Так как заказчик регулярно пересматривает свои требования, то лучше позаботится о том, чтобы в контракте были чётко оговорены сроки демонстраций версий проекта в разработке. Эмпирически уже давно определенно, что самым оптимальным сроком будет каждые 2-3 недели, вплоть до полной сдачи проекта. 
  • И тут же менеджеру необходимо предусмотреть порядок пересмотра условий сдачи проекта в релиз по договоренности между заказчиком и ведущим разработчиком, но при этом не забывать, что слово заказчика выше слова разработчика. 
  • И если заказчик в процессе потребует ещё закомментировать исходный код, написать документацию и справочную систему для пользователя разрабатываемой системы, то в интересах менеджера исполнить это пожелание. В противном случае, подрядчик сильно рискует потерять свою репутацию ещё до сдачи проекта в релиз.
  •  
  • "Сложности проекта" невозможно определить на стадии технического задания. Если есть какие-то краевые условия (например, по максимальной нагрузке на сервер), то это указывается как техническое пожелание со стороны заказчика. 
  • Размер и объем задач - абсолютно ту же корзину. Их определяет ведущий программист, применяя свои технические знания, а не заказчик в ТЗ. 
  • "Различные виды тестирования": Договариваются о порядке и процессе тестирования, если речь только о контрактной разработке ПО. Для "продуктовой" разработки - это задача целиком QA-тестировщиков. 

    В случае контрактной разработки несколько сложнее:
    - Функциональность и выловить ошибки задача именно тестировщиков, и обычно джунам перепадает замечательная возможность "сломать программу полностью".
    - Эргономику и интерфейс уже коллективная работа, тут скорее всего проще договорится с заказчиком, чтобы тот приводил на демонстрацию несколько пользователей и те в свободной форме оставляли все свои комментарии в письменном виде. Даже если это высококультурные выражения на великом и могучем. 
    - Если, конечно, у того нет дизайнера, который сделал макет пользовательского интерфейса по его прихоти. 
  • CI/CD: расшифровка "Continuous Integration/Continuous Delivery". Вы сами понимаете, что в предыдущих пунктах уже решен этот вопрос? У меня почему-то стойкое ощущение, что Анна сама не до конца понимает значение всего что она написала. 
  • "Технологический стек". Очередной кретинизм, придуманный эффективными менеджерами.

    Окей, допустим, ваши разработчики и заказчик договорились о том, что модули CRM расшираются за счёт плагинов в DLL-формате и BIN-формате для плагинов-контейнеров.

    Допустим, разработчик и заказчик договариваются о том, что драйвер 3D-принтера должен запускаться как под определенной версией Linux Mint, но основная работа под Windows, а само устройство должно прежде всего понимать G-код и работать с программами ArtCAM и далее по списку. Да, это буквально мой недавний заказ. 

    Допустим, разработчики и заказчик договорились о том, что сайт разрабатывается под HTML5, используют любую удобную развёртку, а сервер исполняет роль файлового хранилища с минимальным кодом страниц, запускается под Windows Server 2012 или Fedora Linux / CentOS / Debian не меньше определенной версии. 

    Допустим, заказчик хочет сделать несколько расширений на C#, а ваши программисты предпочитают C++. Мне, конечно, очень интересно, кто из них предпочтёт короткую соломинку. 

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

    Допустим, заказчик какой-то банк, что маловероятно, учитывая как банки нанимают программистов, ему нужно сделать что-то на SpringBoot под Oracle JVM 17 - надеюсь, вы уже поняли куда отправили этого наглого HR-менеджера и в каких вежливых выражениях. 
  •  
  • "Наличие у специалистов опыта реализации подобных проектов". Строка, говорящая больше о человеке, который её написал, нежели имеющая хоть сколько близкий к реальному положению дел смысл. 

Словом, вы меня порадовали. Никогда ещё не получал столько удовольствия от комментирования статей на E-xe. 

Инженер, Омск

Небольшой десерт: 

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

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

Как всегда, душа автора расскрывается в выводе. 

"Не должно быть разночтения и договоренностей". Прям в резюме себе запишите, отличная строка. 

Партнер, Москва
Александр Ковалёв пишет: Как всегда, душа автора расскрывается в выводе.  "Не должно быть разночтения и договоренностей". Прям в резюме себе запишите, отличная строка. 

Александр Ковалев, у вас точно сегодня тяжелый день. Выволочку от менеджера получили и хочется самоутвердиться в инете?

1 2 4
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Владелец «Л’Этуаль» полностью выкупил сеть магазинов косметики «Подружка»

В России работает 287 магазинов сети «Подружка».

Стать предпринимателем пробовал каждый третий в мире

Доля заинтересованных в развитии своего бизнеса выше в странах Латинской Америки и в Индии, ниже — в Японии, Нидерландах, Бельгии, Швеции.

Названы самые дефицитные профессии в промышленности

Спрос на представителей некоторых специальностей за полгода вырос на 58%.

Пожар на складе Ozon: ущерб в 10 млрд рублей, компания выплатит компенсации продавцам

Основная версия пожара – поджог. Склад в Подмосковье уже не спасти.