{"id":13800,"url":"\/distributions\/13800\/click?bit=1&hash=494bcf8595527c8c9e734d9291ef1b1692fb7de6e7f241fd1532d02dbe17011c","title":"\u041b\u0430\u0439\u0444\u0445\u0430\u043a\u0438 \u0434\u043b\u044f \u0442\u043e\u0440\u0433\u043e\u0432\u043b\u0438 \u043d\u0430 \u00ab\u041c\u0430\u0440\u043a\u0435\u0442\u0435\u00bb ","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"fb0a50bc-0a7b-535f-b137-b58b2208d639","isPaidAndBannersEnabled":false}

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

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

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

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

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

1. Попытка купить софт

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

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

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

Поэтому совет номер 1 — не путайте заказ с покупкой. От вас тоже потребуются некоторые усилия, иначе ничего хорошего не получится.

2. Задержка выплат

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

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

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

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

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

3. ТЗ как точка зрения

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

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

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

Совет 3. Не пытайтесь поменять ТЗ, тем более в одностороннем порядке. Соблюдайте договоренности, это в ваших интересах.

4. Руководителя проекта нет или он отвлекается

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

  • Получение необходимой информации
  • Доступ к компетентным сотрудникам заказчика
  • Физический доступ в ЦОД и на предприятие, при необходимости
  • Доступ «к телу» ЛПР (лиц, принимающих решения)
  • Популяризацию проекта в команде заказчика, чтобы избежать саботажа инноваций

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

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

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

  • Собственник бизнеса. Понимает системную выгоду от автоматизации управления, располагает полномочиями принимать решения. И не располагает временем. А также видит десятки других направлений, куда тоже нужно потратить бюджет. Он непрерывно комбинирует, перестраивает схемы и планы. Очень сложно удержаться от соблазна «подвинуть» один проект в пользу другого.
  • Наемный сотрудник. Казалось бы, может сфокусироваться. Должен. Только он ведь не РП одного внедрения. Наоборот, у человека есть основные служебные обязанности, и они другие. Конечно, вариативность меньше, чем у гендира или акционера. Но и ресурсов меньше, точнее возможности ими распоряжаться.

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

Совет 4. Обязательно назначьте руководителя проекта со своей стороны, дайте ему необходимые ресурсы, полномочия и мотивацию. А также выделите проект разработки как приоритетный. Иначе не стоит начинать — будет напрасно потрачено много ресурсов.

5. Медленные согласования

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

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

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

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

Совет 5. Держите темп. Разработка как теннис — если мяч надолго остался на вашей половине поля, значит вы проиграли. Сначала очко, потом сет, партию, матч.

6. Вне зоны доступа

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

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

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

  • Ваш «пушер» или РП (иногда это разные люди) назначает встречу с гендиром заказчика. А тот ее срывает. Неважно почему, может по веским причинам. От этого не легче.
  • Вы договорились об интервью с ключевыми сотрудниками заказчика для прояснения бизнес-процессов. Но они-то не мотивированы! Им скучно, неинтересно. Возможно, даже опасаются, что их заменят роботом или скриптом.
  • Попросили дистрибутивы софта, который используется компанией заказчика, доступы к их облачным хранилищам и платформам. Но безопасники против, бухгалтерия тоже, профсоюз уборщиков выдвинул встречные требования.

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

7. Не жадничайте на собственном проекте

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

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

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

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

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

Резюме

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

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

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

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

  • Вложитесь в выбор подрядчика. Внушительное портфолио говорит больше о маркетинге, чем об IT. Красивый офис тоже построили не программисты. Важно смотреть на процессы, стандарты, команду разработки. В идеале заручитесь поддержкой спецов в теме, тем более что они пригодятся вам на следующих этапах тоже.
  • Здраво оцените ТЗ и планы. В широком смысле. Какие IT-технологии задействовать, какие роли нужны в проектной команде, какую часть «хотелок» лучше вычеркнуть или отложить, что нужно сделать в первую очередь, как контролировать, как запускать, тестировать, отлаживать. Чтобы составить полезный план, нужно уже знать про IT достаточно много.
  • Тащите свою лямку на проекте. Будьте надежным партнером, который выполняет свои обязательства. Предоставьте все что нужно, отвечайте быстро и по существу, реагируйте адекватно. Никакой подрядчик не сможет повысить вашу конкурентоспособность, если вы сами боретесь против него.
  • «Женитесь» на IT-подрядчике. Стройте продолжительные отношения, условно целясь на всю жизнь вперед. Потому что программное обеспечение устаревает за пару лет, и ваши бизнес-процессы тоже будут обновляться. Разработка может начинаться как проект, но она должна переходить в регулярный процесс. Иначе выгода от внедрения будет не полной, если вообще будет.

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

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

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

0
Комментарии
Читать все 0 комментариев
null