Мифы и легенды разработки ПО

В разработке ПО, как и в каждой отрасли бизнеса есть свои мифы и даже легенды 🙂 Некоторые мифы появляются на стороне клиентов, другие создаются внутри сообществ разработчиков. Зачем нам всем это нужно? Попробуем разобраться!

Миф №1 (со стороны клиента) - Заказывая кастомную разработку я привязываюсь к разработчику со всеми вытекающими из этого последствиями.

Наверное, это самый распространенный миф. Сегодня я в очередной раз с ним столкнулся, консультируя нового Клиента по вопросу - какую CRM использовать - коробочную с рынка, или разрабатывать свое ПО. “Вы же понимаете, что если я закажу кастомную разработку, то я буду привязан к разработчику? Поэтому мне нужна коробка. Разубедите меня!”. Я не очень люблю уводить консультацию в честный ответ на подобные вопросы, но сегодня, скрепя сердце и с кофе в зубах, мы все-таки туда заглянули. Оставлю свои размышления и здесь.

Я считаю, что эту “привязку” клиент сам создает для себя, т.к.

1. Любой продукт можно доработать. Чем отличается готовый код коробки от готового кода кастомного решения? Да, под коробку больший выбор специалистов, но хорошо ли это? Как вы проверите качество кода для коробки, если Вам даже исполнителя выбрать трудно? Количество специалистов, готовых работать с кастомным кодом гораздо меньше. Но не кажется ли Вам, что эта воронка уже более качественных разработчиков. Если команда может прочитать любой код - то и качество доработок будет в разы выше.
2. 80% работы разработчика - это чтение кода. В любой непонятной ситуации нужно читать код. Даже если у продукта есть документация, все равно приходится читать код, а документация является скорее приятным бонусом. В случае с кастомным решением - кода скорее всего будет меньше, т.к. коробки как правило содержат в разы больше избыточных элементов интерфейса, структура БД в них более раздута. Ну и кода приходится читать в разы больше.
3. Клиент ленится идти в поиск разработчиков, ему там не уютно, он не понимает этот мир. Почему же так происходит? Моя гипотеза в том, что чем хуже мы разбираемся в чем-либо - тем больше боимся это менять. Работает? Ну и ладно. Не трогай - будет хуже! Я проверял, один раз, или мне кто-то сказал. Уже и не помню - говорит внутренний голос Клиента. И этот миф порождает кейсы, когда бизнес годами может ждать разработчиков, терпя убытки. Потому что с убытками более менее бизнес может разобраться, а вот с ПО - нет.

Что делать и кто виноват?

Рассматривать IT в своем бизнесе - как на одну из основных компетенций (маркетинг, продажи, продукт и т.п.) и начать прокачивать эту компетенцию своими менеджерами внутри. Конечно же - в большинстве случаев нет смысла держать inhouse штат, сопоставимый с небольшой web-студией. Это практически никогда не будет выгодно, т.к. чтобы окупить их ФОТ нужно вести 5-10 проектов одновременно. Я говорю о том, что каждой компании, которая разрабатывает кастомное ПО для себя должен быть как минимум 1 менеджер, который отвечает за разработку и постоянно прокачивает свои компетенции в этом, каким бы малым не был ваш бизнес.

Что делать, если поиск менеджера затягивается и доставляет боль? Брать на вырост, отстраивая этот процесс - наравне с другими, которыми вы занимаетесь. Если нет временных ресурсов у руководителей - попробовать обратиться в агентства и воспользоваться “арендой” менеджера или стажера на 6-12 месяцев, параллельно закрывая эту позицию внутри компании.