Добавить две кнопки — почему так дорого?

  • 19 августа, 07:52
  • 4096
  • 0

Автор: Алексей Журавлев, системный архитектор

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

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

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

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

Как было дело

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

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

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


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

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

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

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

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

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

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

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

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

— Из WordPress? Нет

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

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

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

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

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

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

Иллюстрация в дополнительных комментариях не нуждается. Так бывает не всегда, но чаще, чем могло бы.
Иллюстрация в дополнительных комментариях не нуждается. Так бывает не всегда, но чаще, чем могло бы.

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

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

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

Как в глазах заказчиков иногда выглядит набор “стандартных решений”
Как в глазах заказчиков иногда выглядит набор “стандартных решений”

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

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

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

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

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

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

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

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

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

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

Компоненты и аспекты системы, обеспечивающие “стандартный функционал”
Компоненты и аспекты системы, обеспечивающие “стандартный функционал”

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

Заключение

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



0 комментариев
Сортировка:
Добавить комментарий

IT Новости

Смотреть все