Почему софт «под себя» сложно купить, легко загубить и невозможно починить

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

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

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

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

Но коробочные решения типизированы. Они автоматизируют средние процессы по рынку, причем даже не объективно общие — а на усмотрение разработчика. Возможно, вашему бизнесу подойдет 10% от функционала. Может 20% или даже больше. Суть в том, что этот продукт делали вообще не для вас. Это как одежда в супермаркете. Вроде брюки, пиджак, галстук. Только в таком и ходить разве что за картошкой. Костюм не сидит, в нем все выдает ширпотреб.

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

С точки зрения заказчика, финансирование проекта лучше придержать до результатов.

Для разработчика любые действия до получения денег и (важно) подписания акта о сдаче-приемке — инвестиция в бизнес заказчика. Фактически, авансируя свой проект, компания заказчика даже не оплачивает его. Она делает депозит. И он важен не только в финансовом смысле.

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

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

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

Зато после начала разработки, когда возникает необходимость регулярно заниматься темой, да еще в контакте со специалистами — начинают приходить озарения и инсайты. Хочется «уточнить» ТЗ. То есть переделать его, иногда радикально.

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

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

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

Поэтому отсутствие назначенного РП (руководителя проекта) со стороны заказчика не просто мешает или повышает риски. Вакуум управления приводит к выходу адекватного подрядчика из проекта.

Более того. Допустим РП есть по обе стороны, у заказчика тоже. Кто это может быть? Два основных варианта:

В результате получается, что РП заказчика почти неизбежно становится тем самым «слабым звеном». Не потому, что не хватает мотивации или знаний. Просто ему объективно сложно заниматься проектом приоритетно.

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

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

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

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

Хорошо, как все ускорить? Бывают сознательные заказчики с ясным видением ситуации. Они назначают толкового РП, внимательно подходят к этапу разработки и согласования ТЗ. Все запускается как надо, колесики крутятся.

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

Ответственные сотрудники заказчика болеют, уезжают в командировки. У них происходят завалы на каких-то других направлениях. А главное, коллеги могут не разделять энтузиазма и понимания значимости. Например:

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

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

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

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

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

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

Если вы собираетесь заказывать серьезный софт — спасибо что прочитали эту статью. Это говорит о том, что вы действительно хотите разобраться в вопросе. Отлично, значит бонусный чек-лист попадет в правильные руки.

Итак, что конкретно можно сделать:

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

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

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