Поделиться
Как снизить риски «долгой» разработки для своей компании
Чтобы бизнес имел больше шансов на успешное развитие, его руководителям важно обращать внимание не только на отточенность бизнес-процессов, но и на соответствие компании технологическому прогрессу. Однако по-настоящему уникальные решения, как правило, не купить «на рынке» — обычно они создаются по индивидуальному заказу, иногда — в течение долгого времени. Как не «промахнуться» при заказе кастомного ПО и получить от него максимум пользы?
Когда стоит отдавать предпочтение кастомной разработке
Как полагают в IDC, в нынешнем «цифровом» мире корпоративное программное обеспечение должно постоянно обновляться, чтобы бизнес не отставал от современных требований к производительности, масштабу и надежности. Согласно прогнозу IDC, выручка производителей корпоративных приложений, составлявшая в 2022 г. $279,6 млрд вырастет до $385,2 млрд в 2026-м., увеличиваясь в среднем на 8%, что весьма неплохо с учетом общей стагнации мирового ИТ-рынка.
Однако, чем крупнее компания или чем более специфичен бизнес, тем выше ее запросы по кастомизации. С учетом опыта 2022 г., когда тысячи российских бизнесов были вынуждены срочно искать замену иностранному ПО среди отечественных аналогов, вопрос о вложениях в собственную цифровую инфраструктуру перестал выглядеть капризом собственников и стал весьма насущным.
При этом нежелание заказчика втягиваться в покупку цифровых «долгостроев» вполне объяснимо. Даже если подрядчик применяет передовые методики управления, проект может тянуться в лучшем случае полгода-год, иные сделки закрываются только через несколько лет. За это время и актуальные технологии могут измениться, и сама компания может попасть в кризис из-за изменившихся внешних обстоятельств. А высокий уровень кастомизации в готовом решении увеличивает расходы в разы. Так что неудивительно, что первый вопрос, которым заказчики, даже самые передовые, встречают разработчиков с новыми продуктами всегда один и тот же: «А где это внедрено?»
Но если у бизнеса есть цель стать инновационным лидером в отрасли, нужно решаться на риски. Однако есть несколько способов их минимизации и, как следствие, более выгодного приобретения продукта с долгим циклом разработки и окупаемости.
Выберите подходящий формат сделки
Если речь идет именно о покупке решения под конкретные цели бизнеса, стоит доверять продукту, который существует хотя бы как MVP (Minimum Viable Product, минимально жизнеспособный продукт) или в рабочей версии, хотя бы и 1.0. В этом случае есть понимание, что именно вы приобретаете, ведь эти решения можно предварительно протестировать.
Кроме того, с продуктами на начальных циклах руководителям необходимо четко для себя сформулировать, что в итоге бизнес хочет получить: какие параметры и функции должны быть в конечном продукте, в каком объеме и т. д. Чем более детальный запрос, чем больше полезных для своего бизнеса функций прописано в договоре, тем больше вероятность получить то, что нужно.
Если же бизнес принимает решение купить продукт до стадии MVP, когда есть лишь прототип или просто слайды и эскизы, то лучше проводить сделку через инвестиционный комитет, а не через закупочную процедуру. Конечно, закупщики проверяют финансовое состояние производителя или продавца, отсутствие у будущего подрядчика крупных судебных дел, возможно, историю поставок. Но к большим вендорам, которые выходят с новыми продуктами на рынок, такой подход не применим, а размер компании совершенно не означает, что ее продукт сразу же заработает, особенно если речь идет о разного рода прикладных системах. Оценить потенциал такого чернового продукта закупочная процедура не способна. В отличие от закупочной процедуры, инвестиционный комитет — это более широкий орган, в который входят и технические эксперты, и финансисты, и юристы, и сами закупщики, возможно, и специалисты по безопасности. За счет широкого охвата направлений специалисты комитета просчитывают большее количество рисков, что увеличивает шансы на успешное внедрение продукта в будущем.
Контролируйте процесс разработки
Каким бы авторитетным ни был поставщик решения, результатом разработки будет пользоваться именно ваш бизнес. Поэтому от компании-покупателя должен быть проектный менеджер, который будет участвовать в регулярных звонках и встречах с подрядчиком по технологическому решению и контролировать ход работ.
«Правильный» состав участников встречи, посвященной разработке ПО должен включать менеджера от компании-покупателя; сейлз-менеджера разработчика; руководителя отдела разработки или продуктолога от разработчика.
В таком составе легче и быстрее решать технические вопросы, в которых продавец в силу недостатка профессиональных знаний ответить не сможет.
Не так важно, насколько частыми будут встречи: раз в месяц или раз в неделю. Частота будет зависеть от специфики решения и договоренностей с подрядчиком. Принципиально следить за сроками: когда компания претендует на звание новатора, отставание в технологическом плане от конкурентов или, что еще неприятнее, появление у других игроков схожего нового продукта.
И, конечно, обратная связь решает все. Даже правильно заданные вопросы могут помочь разработчику увидеть, с чем возникают сложности, и предложить другие варианты решения. И наоборот, молчаливое недовольство и нежелание «стеснять лишними вопросами» может обернуться большими проблемами в будущем.
Обеспечьте непрерывность процессов в своем бизнесе
Когда дело касается покупки высокотехнологичного решения, нужно всегда держать в уме, что такая сделка должна завершаться только после полного внедрения готового продукта в бизнес покупателя. Этот пункт обязан быть в договоре, иначе компания может столкнуться с тем, что готовое решение не сможет состыковаться с ранее установленными системами.
Кроме того, работа текущего бизнеса должна продолжаться даже во время внедрения новых решений. К сожалению, есть примеры, когда CTO покидали свои должности именно потому, что на переходном этапе не уделили должного внимания этому фактору. Но непрерывность работы — ответственность как подрядчика, так и покупателя.
Также полезно держать в голове Закон Мерфи: если что-нибудь может пойти не так, оно пойдет не так. Поэтому не стоит полагаться на то, что проект 100% закончится в срок, или ставить полный перенос данных на новую систему, когда у текущей остается всего несколько дней до окончания лицензии и хранения данных по договору. Должен быть временной промежуток, который позволит поддерживать и налаживать обе системы без спешки и суеты.
Долгий цикл разработки покупаемого решения несет за собой большие затраты, однако в перспективе может значительно повысить эффективность бизнеса. Условия для такого повышения — четкий и понятный запрос компании-подрядчику, контроль за ходом работ и максимальная подготовка бизнеса к «переезду» на новые системы.
Короткая ссылка
