Человек А: «Давайте использовать эту зависимость для наших требований».
Человек Б: «Нет, мы можем сделать лучше».
Человек А: «Для нашего проекта есть облегченный фреймворк. Мы можем использовать это».
Человек Б: «Мы не должны его использовать. Что, если в нем есть ошибки?»
Если вы когда-либо участвовали в подобных технических соревнованиях, вы сталкивались с «синдромом не изобретённого здесь». Другими словами, вы встречаете человека, который снова и снова хочет изобретать велосипед.
Итак, начнем с синдрома «чего тут не придумать». NIH — это поведение сопротивления идеям, проектам и т. д., созданным кем-то другим. Причин такого сопротивления много. Доверие, исследования и разработки, цели с открытым исходным кодом, коммерческие причины могут быть одними из них. NIH может происходить во многих областях. В этом посте мы обсудим разработку программного обеспечения и ИТ.
В разработке программного обеспечения и информационных технологиях нет абсолютной правды или абсолютной неправильности. Так что это справедливо и для NIH. NIH - двусторонняя ситуация. Один из них противоположен NIH, а другой поддерживает.
В случае поддержки у вас может быть сильная и уверенная в себе команда разработчиков для создания проектов для нужд вашего домена. Таким образом, вы можете разрабатывать функции, которые точно соответствуют требованиям. Также команда может просто делать корректировки на изменения в домене. Эти разработки дают вам полный контроль над продуктом, а ИТ-команда знает каждую деталь процесса. Когда есть ошибка или исключение, команда развернет исправление ошибки в более короткие сроки. У команды есть ноу-хау по проекту. Знать, как равно сила.
В противном случае у вас нет команды и времени для покрытия требований. Рядом есть множество решений, проверенных другими пользователями. Если вы разрабатываете новый продукт, он пройдет такие этапы, как тестирование, тестирование, исправление ошибок, документация и т. д. Лучше всего использовать передовое решение. В этом случае вы можете сэкономить деньги, как и при использовании открытого исходного кода. Вы не будете изобретать велосипед с самого начала, но у вас есть шанс улучшить его.
Вам и команде решать, сталкиваться с NIH или нет. Оба пути имеют плюсы и минусы. Такие критерии, как время, деньги, требования к домену, команда и т. д., повлияют на ваше решение. Это не предмет гордости, потому что в разработке ПО для гордости нет места.
Спасибо за прочтение.
