7 ошибок малого бизнеса при заказе software на заказ

Большинство малых компаний, обжёгшихся на проекте ПО на заказ, обожглись вовсе не о плохих программистов. Они обожглись за недели до начала любой разработки — на стартовой встрече, в переписке, при рукопожатии — из-за решения, которое тогда казалось пустяковым. К моменту, когда приходит код, ошибка уже встроена в проект. Хорошая новость в том, что эти ошибки скучно однотипны, а значит, их можно избежать, если знать, как они выглядят.

Я наблюдал множество таких проектов изнутри, по обе стороны стола. Одни превратились в инструменты, без которых компания уже не мыслила работы. Другие обернулись наполовину готовым экраном входа, напряжённым спором о счёте и владельцем, клянущимся никогда больше не связываться с разработкой на заказ. Огорчает, как мало разделяло эти два исхода. Технология редко была проблемой. Решения вокруг технологии — почти всегда.

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

Ошибка 1: Покупать решение, не разобравшись в проблеме

Самая дорогая ошибка случается первой, и звучит она безобидно: «Нам нужно приложение, которое делает X». К моменту, когда кто-то произносит это вслух, он обычно уже определил форму решения — дашборд, портал, мобильное приложение — а реальную проблему простыми словами так никто и не записал. Тогда разработка добросовестно поставляет не то, что нужно, и делает это красиво.

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

Ошибка 2: Пытаться построить всё сразу

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

Компании, у которых получается, делают наоборот. Они выбирают один самый болезненный кусок проблемы и строят сначала именно его — реальную, работающую вещь в продакшене за пару месяцев. Затем позволяют реальному использованию подсказать, что дальше. Это не только дешевле; это безопаснее. Вы узнаёте, работает ли идея, пока ставка ещё мала, а не обнаруживаете спустя полгода и крупный счёт, что спроектировали не то.

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

Ошибка 3: Выбирать только по цене

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

Низкая сумма часто сигналит об одном из нескольких: подрядчик занизил объём, потому что задал мало вопросов; он рассчитывает взять свою маржу позже на правках; либо он неопытен и пока не знает, чего не знает. Ни один из вариантов не кончается для вас хорошо. Заголовочная цена — наименее полезное число в предложении. Важно, ясно ли подрядчик понимает вашу проблему, задаёт ли неудобные вопросы и честен ли в том, что в смету не входит.

Ошибка 4: Забывать, что ПО — не разовая покупка

ПО на заказ часто преподносят и покупают как мебель: заплати один раз, владей вечно. Это не так. ПО живёт в подвижном мире — операционные системы обновляются, браузеры меняются, выходят патчи безопасности, ваш бизнес сдвигается, инструменты, к которым вы подключены, меняют свои правила. Инструмент, который никто не сопровождает, медленно перестаёт работать, а затем ломается в самый неподходящий момент.

Это больно бьёт по малым фирмам, потому что стоимость сопровождения невидима при подписании. Вы сравниваете два предложения по цене разработки и так и не задаёте более важный вопрос: во что обходится поддержание этого живым и здоровым каждый год? Хостинг, обновления, мелкие правки, периодические изменения по мере роста бизнеса — закладывайте это как обычную постоянную статью расходов, как страховку или бухгалтерию. Обычно она скромная, но лишь если вы её ожидаете.

Ошибка 5: Оставлять требования расплывчатыми и без хозяина

«Вы эксперты, просто сделайте что-нибудь хорошее» звучит щедро. На деле именно так проекты сбиваются с курса. Люди, которые лучше всех понимают ваш бизнес, — это вы и ваша команда, а не разработчики. Если вы передадите размытое задание и исчезнете, подрядчик заполнит пробелы своими лучшими догадками, а эти догадки вы обнаружите в худший момент: при сдаче, когда менять их дороже всего.

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

Ошибка 6: Не спросить, кому принадлежат код и данные

Это тихая ошибка, и именно она ранит больнее всего годы спустя. Вы платите за ПО на заказ и полагаете, что оно ваше. Потом отношения с подрядчиком портятся, или он поднимает цены, или просто исчезает — и вы обнаруживаете, что не можете сдвинуться с места. У вас нет исходного кода. Данные живут в системе, доступ к которой есть только у него. Вся ваша работа теперь зависит от компании, которой вы больше не доверяете, а рычагов влияния у вас нет.

Ничего из этого не требует юриста, чтобы предотвратить. Требуются три простых вопроса, заданных до старта, пока у вас ещё вся переговорная сила: Кому принадлежит исходный код, когда это будет готово? Могу ли я выгрузить все свои данные в пригодном формате, когда захочу? И если мы разойдёмся, с чем именно я уйду? Достойный партнёр отвечает на это не моргнув глазом. Колебание здесь — самый большой тревожный сигнал во всём процессе.

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

Ошибка 7: Считать запуск финишной чертой

ПО сдано, оно работает, все вздохнули с облегчением. Проект объявляют завершённым. Полгода спустя половина команды тихо вернулась к старой таблице, а дорогим новым инструментом пользуются два человека для одной задачи. Разработка удалась. Внедрение провалилось — а это два совершенно разных вопроса.

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

1. 1
   Сначала запустите на малой группе

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

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

   Первый месяц кто-то берёт на себя глупые вопросы. Трение на первой неделе убивает внедрение навсегда.
4. 4
   По-настоящему отключите старый способ

   Пока старая таблица существует, люди будут ею пользоваться. Как только инструмент работает, уберите запасной путь — мягко, но чётко.

Собираем воедино: мышление покупателя

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

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

Частые вопросы