Если у вас есть свой бизнес или вы работаете в бизнес-подразделении более-менее крупной компании, особенно на руководящей позиции, вы, скорее всего, сталкивались с заказной разработкой программного обеспечения или столкнетесь с ней, когда захотите улучшить свои результаты. Под заказной разработкой я подразумеваю не только контрактные отношения с подрядной организацией, но ваших собственных штатных IT-шников.

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

— Два месяца? На простейший функционал? Это неприемлемо! — вы пытаетесь давить, пугать, просить, торговаться; разработчики явно нервничают, но сроки не двигают. В итоге вы приходите к какому-то компромиссу, который не нравится никому, злые и недовольные. 

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

Как было дело

К нам обратилась компания, которой была нужна система, предполагающая некоторое взаимодействие между пользователями разных ролей. Функционала было много, развивать платформу предполагалось итерационно. Для того, чтобы начать работу, мы договорились, что в первый релиз войдет несколько основных бизнес сценариев и ряд вспомогательных функций вроде email уведомлений. Мы составили календарный план с разбивкой на промежуточные этапы и представили это заказчику.

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

Схематично наш план выглядел примерно так:

Несколько функций планировалось закончить по окончанию 1 этапа (этапы были длиной в один месяц, такие спринты-переростки), остальные планировалось завершить позднее.

И далее у нас состоялся очень показательный диалог примерно следующего содержания (очень сокращенно):

— Коллеги, я правильно понимаю, весь первый месяц у вас уйдет только на регистрацию и авторизацию?

— Нет, не совсем так, у нас будет фаза проектирования, мы проработаем модель данных, базовые механизмы, кучу сопутствующих вещей и начнем реализацию больших блоков, которые завершатся позднее

— Но мы увидим только регистрацию?

— В качестве завершенных функций - да

— Так не пойдет. Мы хотим по итогам первого этапа увидеть весь основной функционал, а все остальное давайте делать позднее. Целый месяц делать одну регистрацию - слишком долго

— Мы делаем НЕ ТОЛЬКО регистрацию, мы стартанем и другие задачи, которые просто завершатся позднее установленной даты. Выкинуть все остальное - не получится, это скелет платформы. Если не спроектировать модель данных, некуда будет сохранять регистрационные данные и неоткуда будет брать данные для других функций

— Я просто не понимаю, почему так сложно? Регистрация — это ведь стандартная функция? Давайте возьмем готовый модуль и просто прикрутим его, например из WordPress. Можем так сделать?

— Из WordPress? Нет

— Почему? Давайте соберем систему из стандартных компонентов. В моем представлении это просто форма, пару кнопок и поле в базе данных!?

И так несколько раз по кругу. Я пытался рассказать о том, как строятся системы, почему не бывает “стандартной регистрации” и в чем риск строить mission critical систему в конструкторе сайтов, но особого эффекта это не возымело. В итоге мы нашли тяжелое, но компромиссное решение, скорректировав срок и очень сильно порезав скоуп, но было видно, что заказчик остался недоволен и, возможно, с ощущением, что его обманывают.

Разбор полетов

Проблема первая. “Эффект морковки”

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

В действительности корреляции практически нет - большую, но “тупую” форму на 40 атрибутов для создания объекта вместе с механизмом сохранения этого объекта сделать обычно проще, чем одно маленькое поле “Поиск по сайту”, потому что потребует добавления в систему поискового движка или разработки собственного. 

Проблема вторая. “Свеча или лампочка”?

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

Разработчики действительно пользуются готовыми компонентами, но это именно программные компоненты, “сухие смеси”, а не готовые изделия. Бизнес заказчики часто считают, что можно скачать и “прикрутить” целую бизнес функцию, но это почти всегда не так.

К сожалению, это так не работает. Нельзя в строительном магазине купить коробку с горячим водоснабжением - можно купить отдельно трубы, краны и котел, все смонтировать, настроить, и закрыть плиткой. Разработчики давно не пишут код полностью с нуля (как и строители не занимаются трубопрокатом или обжигом керамики) и на этом действительно экономится куча времени. Когда бизнес-заказчик решает, что тут можно сэкономить, добавив что-то стандартное и готовое, разработчик уже это сделал, оценив свою работу с учетом того, что он и так будет строить решение из готовых модулей настолько, насколько это возможно.

Проблема третья. “Золотая клетка”

Современный интернет проделал огромный путь от простых сайтов с информацией к сложным информационным системам, выполняющим различные функции, которые, тем не менее, взаимодействуют с пользователем так же, как и раньше, через браузер. Для пользователя при этом все остается простым и понятным - вот текст, вот изображения, вот какие-то кнопки. Граница между “просто сайтом” и “информационной системой” очень нестрогая и размытая, но все же она есть. Никто ведь не называет интернет-банк сайтом? Есть отдельно сайт банка, а есть - интернет банк. Также сложно назвать просто сайтом Gmail или какой-нибудь онлайн редактор - обычно говорят “веб версия” такого-то сервиса. Примеров много, общего между ними то, что сайты это больше про “почитать”, а системы или сервисы - про “что-то сделать”.

И есть особый вид систем (или сервисов), задача которых - помогать быстро делать сайты. Их много - Тильда, 1С.Битрикс, WordPress, Joomla и другие. Некоторые доступны только в качестве онлайн сервисов, другие можно установить на свой сервер и доработать, так как есть исходный код. Но задача всех подобных систем - быстро и просто создать информационные сайты. При этом то, что мы называем “сайтом, сделанном на таком-то движке”, является по-прежнему сложной информационной системой, которая позволяет через специальный интерфейс быстро и просто настраивать некоторый небольшой набор страниц, организованных в логическую группу “Сайт компании N”.

Движки для создания сайтов хороши и удобны, когда ваша задача лежит в границах их стандартных возможностей - а это почти всегда просто информационные сайты с контентом, новостями, формой обратной связи и т.п. Вам не нужно писать код, вы пользуетесь готовыми механизмами и через web интерфейс просто добавляете нужные функции.

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

Так что, нельзя ничего переиспользовать?

Можно, но не готовые бизнес-функции, а программные компоненты, библиотеки и модули, ускоряющие разработку. Если вы слышали такие слова, как React JS, Angular, Spring, Laravel, Hibernate - это как раз они. Хорошая информационная система, даже маленькая, строится по определенным правилам, имеет стройную архитектуру, а ещё, что не маловажно, спроектирована так, чтобы ее можно было дорабатывать и развивать. Бизнесу кажется, что это все не так важно, главное - функционал, но представьте себе автомобиль, у которого капот приварен к кузову. Да, быстрее и дешевле, чем делать замки и механизм подъема, но чтобы поменять масло, нужно болгаркой разрезать капот, потом просверлить отверстие в корпусе двигателя.. думаю, можно не продолжать.

Часто системы представляют в виде набора “кирпичиков”, добавил еще один - получилась новая функция. Действительно, можно представить в виде кирпичиков, выглядеть будет так:

И это не преувеличение: одинаковые с виду функции могут сильно различаться по внутренней организации.

Заключение

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