Как гибкая разработка и планируемый бюджет помогают нам поддерживать и развивать сайты клиентов. Опыт IT-компании

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

Чтобы занимать лидирующие позиции в своей отрасли, бизнесу нужно постоянно развиваться. Уже недостаточно просто сделать сайт и ждать клиентов.

Настоящих лидеров отличает то, что они нацелены на регулярный апгрейд своего представительства в сети: пробуют новое, тестируют гипотезы и хотят воплощать идеи в жизнь за минимальное время.

Если вы нацелены на масштаб, мало ставить фрилансеру задачи из разряда «поменять картинку на главной». Нужно доверить развитие своего интернет-проекта тем, кто будет поддерживать его в рабочем состоянии и параллельно улучшать.

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

Наша задача не просто поправлять мелкие недостатки — мы заинтересованы в долгосрочном развитии сайта клиента. Ради этого мы столько лет в IT.

Мы — Initlab. Крутая команда специалистов с опытом от двадцати лет в web-разработке и от 15 лет в Drupal. Нас зовут, когда сделано простое и осталось сложное. Когда все отказались или всё сломали. Когда масштабные проекты, которые заказчик хочет развивать.

В 2020 году наш клиент PNEVMOTEH получил премию «E-COMMERCE» как лучший интернет-магазин среди малого бизнеса. В 2022 компания сменила весовую категорию и стала вторым лучшим интернет-магазином Беларуси, уступив место только МТС. Есть над чем работать и к чему стремиться.

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

RASTL.RU — интернет-магазин, который уже более 10 лет на рынке текстильных товаров. Их сайт — один из основных инструментов продаж, над которым мы также постоянно работаем. В 2021 году государство потребовало маркировать текстиль и одежду по системе «Честный ЗНАК», что повлекло за собой ряд проблем с онлайн-торговлей. Благодаря тому, что наш разработчик до этого написал и внедрил на RASTL.RU специальный модуль для отправки чеков по 54-ФЗ, мы смогли без труда доработать его архитектуру так, чтобы нужная информация уходила теперь и в систему ЧЗ. Об этом мы писали здесь.

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

Мы не скажем ничего нового тем, кто слышал про Agile или Канбан. Но если вы хотите узнать про очевидную пользу такого подхода, оставайтесь на линии.

В классической поддержке сайта сценарий такой:

заказчику говорят цену за час работы→ подписывается договор→ задачи дают исполнителям→их выполняют.

В случае с гибкой разработкой, после обращения клиента, происходит следующее:

1. Рассчитываем примерное время, которое уйдёт на всё запланированное. Ключевое слово — примерное. Мы не даём точную оценку на доработку сайта в случаях: 1) если сайт делали не мы и не знаем, как он написан; 2) если нам предстоит делать нечто новое и мы пока не понимаем, что и сколько займёт. Мы даём ориентировочную оценку по запросу клиента, исходя из нашего опыта.

2. Согласовываем оптимальный бюджет в месяц. В классической ситуации клиент получает счёт в конце месяца/квартала по факту выполненных работ. Для гибкой разработки нужно, чтобы клиент определил сумму, которую готов вкладывать в поддержку и развитие сайта в месяц, а мы рассчитали, хватит ли её для занятости нужного состава команды и планируемых задач. Для чего это служит, расскажем ниже. Когда бюджет согласован, мы подписываем договор.

3. Расставляем приоритеты по задачам. Что нужно сделать срочно, что пока терпит, а что делаем на оставшийся бюджет? Чаще всего распределяет задачи по важности клиент, особенно если проект большой и дел там невпроворот. Со своей стороны мы даём список задач, о которых клиент с его позиции может не задумываться: тестирование сайта, устранение технического долга и т.п.

4. Распределяем бюджет между всеми задачами, которые планируем. Самому важному пункту — отдельный раздел.

Все проекты разные и одного рецепта нет, поэтому в качестве примера мы опишем типовой вариант того, куда уходят средства. Итак,

1. Контроль состояния сайта с помощью ручных и автоматических тестов. Работает ли корзина? Какой результат даёт поиск по сайту? Не поехала ли вёрстка? Всё это нужно проверять после каждого изменения/обновления. На маленьких проектах хватает человеческих сил, на крупных уже нужна автоматизация.

На постоянное тестирование уходит примерно 20% бюджета.

2. Проблемы, баги, оперативные задачи — из разряда «всё бросить и бежать чинить корзину». На это мы выделяем примерно 30% бюджета.

3. Технический долг — устранение накопленных ошибок и недоделок. Прошлые разработчики не всегда оставляют сайт в идеальном состоянии. Мелкие недочёты могут замедлять сайт и усложнять разработку. На устранение технического долга уходит около 10% бюджета.

4. Обновление до актуальных версий ПО сайта. Например, апгрейд Drupal с 7 до 9 версии. На это закладываем около 10%

5. Новые бизнес-функции. Мы с заказчиком составляем road-map: каким будет сайт через год-два и какие функции он хочет там видеть. Для большого бизнеса это едва ли не самая необходимая часть работы, поэтому на неё уходит порядка 30% бюджета.

Если «дожать» смысл, то всё вышесказанное помогает нам держать на проекте баланс: решать срочные задачи, параллельно гармоничного развивать проект. Грубо говоря, тушить пожар и одновременно сажать новые деревья — это и есть гибкая разработка.

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

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

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

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

Мы даём клиенту доступ к трекеру и учим им пользоваться. Здесь можно следить за всеми процессами. Но в первую очередь вместе с заказчиком мы заводим нужные задачи в систему и расставляем их приоритеты. В любой момент можно добавить, изменить или уточнить то, что нужно.

Задачи распределяются между прикрепленными к проекту специалистами в порядке приоритета по их специализации (фронт, бек, администрирование и т.д.)

Мы вносим правки на сайт по готовности, а не дожидаясь конца месяца, очередной итерации или оплаты за задачу. Для нас, как и для нашего клиента, результат первичен.

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

— Давайте когда будут задачи, тогда и оплатим.

Суть планирования бюджета в резервировании времени разработчика. Если специалист не занят вашим проектом, скорее всего он занят другим и выдернуть его оттуда сложно — он своё время распределяет там, где есть план работ и понятный заработок. Как только на него упадут задачи с внепланового проекта, скорее всего он будет очень долго до него добираться, потому что график забит. Если заказчик готов ждать месяцами, то такой формат работы в принципе возможен.

— А если задач не будет/их будет мало/у бизнеса будут трудности, а бюджет уже оплачен?

Здесь всё просто: если задач мало — мы перераспределяем время на то, что не связано с бизнесом напрямую: рефакторинг кода, настройка тестирования и т.д. То есть на имеющийся бюджет готовим сайт к будущему росту, чтобы ускорить и упростить будущие процессы.

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

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

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

Некоторых заказчиков всё равно пугает неопределённость. Им кажется, что выделенный бюджет расходуется неправильно и хочется конкретики: скажите точно, сколько уйдёт на эту задачу.

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

Звучит справедливо: оценили — делайте за столько, на сколько оценили. Но давайте попробуем переложить такой подход на другую работу.

Допустим, вы говорите электрику, что у вас сломалась розетка. Он называет цену за эту работу и начинает работать. В процессе осмотра выясняется, что проблема в проводке. Справедливо ли требовать от электрика, чтобы он менял проводку за то же время, что и розетку и за ту сумму, что он назвал изначально?

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

Когда заказчик просит конкретную стоимость этапа или задачи, а за превышение хочет штрафовать, из этого вытекает ряд проблем:

1. Мы можем брать в работу только полное ТЗ. Опишите до молекул, что конкретно и где нужно починить. Со стороны заказчика нужен либо грамотный специалист, который в состоянии дать подробное техзадание, либо нужно оплатить время нашего менеджера, который будет уточнять/дополнять/выяснять, что вам нужно. А если окажется, что заказчик не то хотел или хотел не так, то взятки гладки: ТЗ согласовано, мы работали строго по нему. Плюс не получится никаких правок по пути. Простая просьба заодно перекрасить/передвинуть кнопку потребует новых согласований и нового ТЗ.

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

3. Мы не заинтересованы в доработке задач. Поймите правильно: если разработчик делает задачу и по пути находит проблему, он не станет её решать в ущерб времени, которое отведено на основную часть работы. Даже если «побочный квест» быстро решается. Теперь он просто скажет, что такая проблема есть и будет ждать согласованного с заказчиком ТЗ.

В итоге мы согласовываем, формализуем, уточняем, оформляем, считаем и прикидываем. А могли бы работать. Куда лучше начать, получить 80% результата, уточнить и доделать.

Гибкая разработка подразумевает:

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

Резюмируем: в таком формате работать можно, но для этого нужно:

Гибкая разработка + отлаженные годами процессы работы = решение масштабных задач наших клиентов:

и при этом оставаться в рамках понятного бюджета.

Завершим мыслью, с которой начали: сайт — это процесс. Процесс, который должен работать как часы или быть как непрерывный танец, если хотите. Будущее за слаженным союзом бизнеса и команд разработчиков, нацеленных на помощь этому самому бизнесу. Мы в Initlab в этом уверены и всю нашу работу строим на этой основе.