Импортозамещение, подпитываемое волной патриотизма, наверно, стимулирует отечественный рынок высоких технологий, но хочется понять, как бы это сделать мудро, не попадаясь в сети разгильдяев.
К сожалению степень соответствия современной прикладной системы (далее я буду использовать слова "ПО", "продукт", "решение" - это все одно и то же) потребностям реального бизнеса ~40% (я умышленно не называю о каком ПО идет речь и предполагаю упреки читателя, что без определения предметной области рассуждения ни на чем не базируются, однако, пост не претендует на конкретную инструкцию к исполнению, его цель, как и большинства остальных, - заставить подумать о проблеме, возможно, подумать иначе, чем раньше).
Из этих 40% надо сделать следующие выводы:
1. ПО еще дорабатывать и дорабатывать до получения желаемого результата, т.е. еще требуется немало инвестиций в это ПО.
2. Теме не менее элементарные потребности (наиболее значимые, определяющие соответствие этого ПО назначению и, собственно, своему названию :) ) ПО закрывает и, поставив его "из коробки", уже будет несколько лучше, чем вовсе без него.
Желание получить все-таки весь желаемый функционал наводит на следующие возможные стратегии:
1. "все сами" - берем наши требования, ставим задачу программистам, они пишут ровно то, что нам нужно. Решение подходит для софтверной компании, где есть свой штат программистов, способных выполнить весь комплекс последующих работ по развитию продукта.
2. "купили готовую коробку" - берем наши требования и выбираем на рынке коробку, которая в большем объеме покрывает потребность, а с разработчиком проводим переговоры о "стратегическом партнерстве" суть которого в том, что в дорожной карте развития продукта будет учитываться наша потребность в функционале. В качестве гарантии (~"вилами по воде") можно попросить с разработчика дорожную карту реализации запрашиваемого нами функционала в их коробочном (доступном на широком рынке) продукте.
3. "купили нашу коробку" - комбинация предыдущих двух, когда разработчик берет наши требования и делает для нас кастомизированную ветку своего продукта.
С моей точки зрения, варианты №1 и №2 - приемлемы, вариант №3 - откровенно проигрышный для заказчика, поскольку мы получаем нерыночный, эксклюзивный продукт, следствием чего является - нерыночная эксклюзивная цена дальнейшей поддержки и развития. Поэтому, выбирая решение, в обязательном порядке следует внимательно обдумывать выбор продукта, не удовлетворяющего потребности в полном объеме и развитие которого возможно только на условиях единственного поставщика.
Лично мне нравится вариант №2, когда мы покупаем исключительно лицензии доступного на рынке продукта. Риск того, что разработчик не будет дорабатывать свой продукт в соответствии с нашими потребностями компенсируется тем, что, если продукт будет развиваться в принципе, он будет дорабатываться в соответствии с потребностями рынка и в этих условиях лучше мне подстроиться под рынок, чем требовать "эксклюзива" за нерыночную стоимость.
Ну а если есть риск, что продукт не будет развиваться вообще (== рынка для него не будет), то лучше идти про сценарию №1 и самому обрасти зрелой функцией разработки и сопровождения ПО.
К сожалению степень соответствия современной прикладной системы (далее я буду использовать слова "ПО", "продукт", "решение" - это все одно и то же) потребностям реального бизнеса ~40% (я умышленно не называю о каком ПО идет речь и предполагаю упреки читателя, что без определения предметной области рассуждения ни на чем не базируются, однако, пост не претендует на конкретную инструкцию к исполнению, его цель, как и большинства остальных, - заставить подумать о проблеме, возможно, подумать иначе, чем раньше).
Из этих 40% надо сделать следующие выводы:
1. ПО еще дорабатывать и дорабатывать до получения желаемого результата, т.е. еще требуется немало инвестиций в это ПО.
2. Теме не менее элементарные потребности (наиболее значимые, определяющие соответствие этого ПО назначению и, собственно, своему названию :) ) ПО закрывает и, поставив его "из коробки", уже будет несколько лучше, чем вовсе без него.
Желание получить все-таки весь желаемый функционал наводит на следующие возможные стратегии:
1. "все сами" - берем наши требования, ставим задачу программистам, они пишут ровно то, что нам нужно. Решение подходит для софтверной компании, где есть свой штат программистов, способных выполнить весь комплекс последующих работ по развитию продукта.
2. "купили готовую коробку" - берем наши требования и выбираем на рынке коробку, которая в большем объеме покрывает потребность, а с разработчиком проводим переговоры о "стратегическом партнерстве" суть которого в том, что в дорожной карте развития продукта будет учитываться наша потребность в функционале. В качестве гарантии (~"вилами по воде") можно попросить с разработчика дорожную карту реализации запрашиваемого нами функционала в их коробочном (доступном на широком рынке) продукте.
3. "купили нашу коробку" - комбинация предыдущих двух, когда разработчик берет наши требования и делает для нас кастомизированную ветку своего продукта.
С моей точки зрения, варианты №1 и №2 - приемлемы, вариант №3 - откровенно проигрышный для заказчика, поскольку мы получаем нерыночный, эксклюзивный продукт, следствием чего является - нерыночная эксклюзивная цена дальнейшей поддержки и развития. Поэтому, выбирая решение, в обязательном порядке следует внимательно обдумывать выбор продукта, не удовлетворяющего потребности в полном объеме и развитие которого возможно только на условиях единственного поставщика.
Лично мне нравится вариант №2, когда мы покупаем исключительно лицензии доступного на рынке продукта. Риск того, что разработчик не будет дорабатывать свой продукт в соответствии с нашими потребностями компенсируется тем, что, если продукт будет развиваться в принципе, он будет дорабатываться в соответствии с потребностями рынка и в этих условиях лучше мне подстроиться под рынок, чем требовать "эксклюзива" за нерыночную стоимость.
Ну а если есть риск, что продукт не будет развиваться вообще (== рынка для него не будет), то лучше идти про сценарию №1 и самому обрасти зрелой функцией разработки и сопровождения ПО.
No comments:
Post a Comment